从“让它干活”
到“让它在轨道上干活”
过去几个月，我持续用 AI 参与几个复杂工程项目。
一开始，我对 Agentic Coding 的理解也很简单：
让 AI 读代码、改代码、跑测试、修 bug、写文档。
人只需要提需求，AI 负责执行——听起来像是终极自动化。
但真正做下来以后，我发现这个理解是错的，甚至是有害的。
这条生产线里，AI 当然重要。
但它不是最高决策者。
它更像一台速度极快、产量极高，但没有任何内在判断力的引擎。
如果你只给它一个模糊的目标，它会生成一堆看起来合理的代码。
如果你给它边界、流程、证据、验收标准和拒收条件，它才有可能稳定交付真正可用的工程结果。
这就是我现在对 Agentic Coding 最核心的判断：
正确性不再隐含于程序员的直觉里，它必须被显式地外化。这是一场工程知识的表达革命。
一、最大的错觉：代码生成了，项目就推进了
AI 写代码最容易制造一种进度错觉。它太快了。
以前一个模块要写半天，现在几分钟就能生成一版；以前一份测试不想写，现在让 AI 一次生成十几个；以前一段文档要整理很久，现在 AI 能立刻输出完整说明。
表面上看，项目推进速度变快了。
但复杂工程里，真正消耗时间的从来不只是“把代码打出来”。
真正难的是：
- 需求有没有被正确理解；
- 模块边界有没有被守住；
- 输出格式有没有被破坏；
- 历史行为有没有退化；
- 测试是不是在验证真实行为；
- 修复是不是只解决了表面报错；
- 结论有没有证据支撑；
- 当前阶段通过，是否真的代表整体完成。
这些问题，不会因为 AI 写得快就自动消失。
相反，AI 写得越快，验收压力越大，因为它会一次性制造大量“看起来已经完成”的结果。
这些结果里，有一部分是真的完成了；有一部分只是能跑；还有一部分逻辑已经偏了，但表面上仍然很顺，像结构中的内伤，所有测试绿灯反而成了最好的伪装。
这才是 AI 编程最危险的地方：
编译失败、测试失败、命令失败，都是清晰反馈。AI 甚至很擅长根据这些反馈反复修。
真正麻烦的是：
代码能跑，测试也过，报告也写了，但语义是错的。
比如它为了让测试通过，顺手改了测试；为了修一个局部问题，重构了无关模块；为了减少重复代码，抽象出一个并不成立的公共函数；为了完成任务，补了一堆你没有要求的能力；为了让结果看起来完整，生成了证据并不支持的结论。
这时候，项目不是推进了。
只是工程债变得更像工程成果了。
二、AI 编程的核心瓶颈，从实现能力转移到了验收能力
传统开发里，人自己写代码时，很多判断是在脑子里完成的：
你知道这个地方不能改，你知道这个异常不能吞，你知道这个模块不能顺手重构，你知道这个测试只是保护历史问题，不能为了新实现而改掉，你知道这个需求只到这里为止，不能继续发散。
这些判断是隐性知识，不需要写在文档里，但存在于人的工程经验里。
AI 参与以后，问题就变了。
AI 不知道你脑子里的边界。它只知道当前上下文里显式出现了什么。
如果边界没有写出来，它就会自己猜；如果验收标准没有写出来，它就会自己定义完成；如果拒收条件没有写出来，它就默认“能跑就是完成”；如果历史约束没有写出来，它就可能把已经冻结的东西重新打开。
所以 Agentic Coding 的核心工作，不是写一句更神奇的提示词。
而是把过去藏在人脑里的工程判断，显式变成 AI 必须遵守的硬性约束——这就是“约束即代码”的工程实践。
这包括：
- 当前只解决什么问题；
- 当前不解决什么问题；
- 哪些文件允许修改；
- 哪些文件绝对不能碰；
- 哪些行为不能退化；
- 哪些测试必须通过；
- 哪些输出必须完全一致；
- 哪些原始证据必须提交；
- 哪些情况直接拒收。
自觉是意图，约束是结构。在复杂系统中，只有结构才能可靠地传递意图。
我之所以反复强调“硬性约束”，不是因为流程洁癖，而是因为复杂工程不能靠 AI 自觉。
三、自由 Agent 的问题：它会把“完成任务”变成“讲完一个故事”
很多 Agentic Coding 演示都喜欢呈现一种场景：
给 AI 一个目标，它自己规划、自己写代码、自己跑测试、自己修复，最后告诉你任务完成。
这个画面很有吸引力，但在真实工程中，自由 Agent 最大的问题是：
AI 的生成机制本质上是一种叙事补全，它的奖励函数倾向于文本的连贯性和完整性，而非客观事实的可证伪性。
所以它会告诉你：我发现了问题，我修改了实现，我补充了测试，我运行了验证，现在任务完成。这套叙事很完整。
但工程验收不能看叙事，工程验收要看：
- 它到底改了哪些文件；
- 有没有改出范围；
- 有没有新增不该新增的能力；
- 有没有修改测试来适配错误实现；
- 原始命令输出是什么；
- 失败样本是否真的归零；
- 历史结果是否保持不变；
- 差异是否真的消除；
- 有没有留下新的边界问题。
自由 Agent 很容易把“说服你相信它完成了”当成“完成”。
这不是它故意欺骗，而是它的运作方式天然倾向于补全一个合理故事，把内部自洽当成外部正确。
所以复杂工程里，不能让 AI 自己决定轨道。
必须先有轨道，再让 AI 在轨道上跑。
这个轨道，就是任务拆分、阶段门禁、白名单、硬性约束、验证命令、原始证据和拒收条件。
没有这些东西，AI 不是在工程系统里工作，它只是在开放空间里生成内容。没有轨道的列车不是交通工具，只是一堆移动的铁块。
四、真正有效的模式：人定义生产线，AI 执行其中的受控环节
在安全自动化项目里，这个问题会被放大得更明显。
安全研究不是普通增删改查，它涉及：
- 目标是否在授权范围内；
- 接口线索是否真实存在；
- 参数语义是否有证据；
- 身份状态是否明确；
- 请求是否可控；
- 响应差异是否稳定；
- 漏洞假设是否成立；
- 验证动作是否会产生副作用；
- 报告结论是否可复核。
如果让 AI 自由发挥，它很容易把一个普通接口解释成高风险接口；也可能把一个没有身份上下文的请求说成越权风险；还可能在证据不足的情况下，生成一份看起来很完整的漏洞报告。
所以这类项目的关键，不是让 AI “更像黑客”，而是把 AI 放进一条受控研究流程里。
更合理的中文流程应该是这样的：
先从页面、脚本文件、接口文档、历史请求和源码映射文件中提取线索。
再把这些线索整理成结构化的接口研究对象。
然后让 AI 解释接口路径、参数名称和业务含义。
接着让 AI 基于已有证据提出验证思路——但这个验证思路只是草稿，不能直接执行。
草稿必须先经过规则检查，确认没有越界、没有危险动作、没有脱离授权范围。
通过检查后，执行器只能按照白名单动作发送请求。
所有响应、状态变化和差异结果都要被记录成可回放证据。
最后，验证器根据证据判断是否形成高置信候选。
报告可以由 AI 整理，但结论必须由证据支撑。
这里最重要的分工可以总结为四句话：
程序负责事实，AI 负责解释。
程序负责执行，AI 负责建议。
程序负责证据，AI 负责表达。
程序负责验收，AI 不能自证完成。
一旦这个边界反过来，系统就会陷入自我指涉的失控：如果 AI 负责事实，它可能幻觉；如果 AI 负责执行，它可能越界；如果 AI 负责验收，它可能自我合理化；如果 AI 负责最终证明，它可能把假设写成结论。
所以，AI 在复杂工程里的正确位置，不是“全自动大脑”，而是受控生产线里的高能力执行模块。
五、为什么流程必须能用中文讲清楚
我现在越来越反感一种架构写法：
堆一串英文术语，看起来很专业，但没人能说明它运行时到底怎么工作。
比如一个系统写成：静态种子、语义解释、实验计划、运行时、观察结果、验证器、证据报告。
这些词本身没错，但如果不能继续说清楚每一步的输入、输出、责任边界和拒收条件，那么这套架构依然是虚的。
真正可落地的流程，必须能翻译成清楚的中文：
谁从哪里提取线索？线索如何变成结构化对象？
AI 只能解释哪些信息？AI 生成的计划为什么不能直接执行？
执行器能做什么，不能做什么？响应结果如何保存？
验证器根据什么判定？报告里的每个结论如何追溯到证据？
能讲清楚这些，说明系统真的被理解了。
讲不清楚，AI 执行时就会替你解释——而 AI 替你解释的部分，最后往往就是工程风险最大的部分。
模糊的自然语言是 AI 随机补全的温床。如果设计者自己都无法用无歧义的母语定义流程，那就意味着系统的核心逻辑仍是混沌的，AI 只会让这个混沌加速膨胀。
所以，复杂项目里写中文流程不是降低专业性，相反，它是逼迫架构落地。
如果一个流程不能用中文讲清楚，它大概率也不能被 AI 稳定执行。 概念上的模糊，无论用多少英文术语包装，依然不可落地。
六、测试不是质量本身，测试只是验收系统的一部分
AI 很擅长写测试，这确实提升了效率。以前很多该写的回归测试，因为麻烦，最后没有写，现在 AI 可以快速补上。
但测试数量变多，不等于工程质量变高。
很多 AI 写的测试，只是在覆盖代码形状，不是在验证真实行为。
更糟糕的是，如果没有约束，AI 可能为了让任务通过，直接修改测试——这就相当于让被审查者同时修改审查标准，形成自我验证的死循环。
所以复杂工程里，测试必须回到一个核心问题：
有验收价值的测试，不是为了追求覆盖率，而是为了保护关键行为，且其自身必须具有不可变性——关键测试的修改权必须从 AI 手中剥离。
我更相信几类验证：
第一，行为测试。它验证系统对外表现是否符合预期。
第二，回归测试。它确保历史上已经出现过的问题不会再次出现。
第三，一致性测试。它验证两套实现、两个版本、两条链路之间的输出是否严格一致。
第四，证据测试。它不只验证结果，还验证结果是否来自可追溯证据。
复杂工程不缺测试代码，缺的是能作为外部裁判的验收系统。
好的测试体系本质上是系统的独立建模，它根据规格而不是实现来断言。如果测试本身也被 AI 随意改写，那么测试就彻底失去了裁判意义。
七、AI 时代的软件工程，不是不要人，而是更需要人定义边界
很多人讨论 AI 编程时，会问：AI 会不会替代程序员？
这个问题太粗。
更准确地说，AI 会压缩低层实现工作的价值，但会急剧放大高层工程判断的重要性。
如果一个人的主要价值是复制模板、搬运接口、写样板代码、补简单页面，那 AI 的替代压力确实很大。
但如果一个人的价值在于：
- 理解真实需求；
- 识别模糊边界；
- 控制系统复杂度；
- 判断抽象是否成立；
- 设计可回归流程；
- 定义验收标准；
- 发现似是而非的结果；
- 判断证据是否支撑结论；
那么 AI 反而会放大他的能力。因为 AI 可以让实现变得极其便宜，但它永远不会自动告诉你什么是正确。
这也是为什么我认为，AI 编程时代最重要的资产，不只是代码。
更重要的是围绕代码形成的一整套约束系统：
任务书、白名单、禁止事项、验证命令、回归样本、差异报告、原始输出、状态流转、证据结构、拒收规则。
这些东西过去也重要，只是过去很多东西可以存在人的脑子里。现在不行了。AI 看不见你脑子里的边界，你不写出来，它就会猜。而每一次猜测，都是一次潜在的风险引入。
隐性知识显式化的能力，正在成为工程师的核心竞争力。你定义约束的精度，决定了 AI 输出的上限。
八、结论：AI 写代码的边界，就是你能否建设一条可验证生产线
Agentic Coding 真正的价值，不是让人完全不管代码。
它的价值是让有工程判断的人，把实现成本压低，把验证压力前移，把复杂项目拆成可执行、可验收、可回归的流程。
所以我现在不再把 AI 编程理解成：“我给 AI 一个需求，它帮我完成项目。”
我更愿意把它理解成：
这两者差别巨大。
前者依赖 AI 自觉，后者依赖工程约束。
前者容易产生看起来完整的故事，后者要求每一步都有可复核证据。
前者适合小工具和低风险任务，后者才适合复杂工程和安全自动化。
因此，AI 写代码的边界并不在于它能不能生成更多代码。
而在于：
你能不能定义什么叫正确；
你能不能限制它不要做什么；
你能不能验证它到底做了什么；
你能不能在它跑偏时及时拒收；
你能不能把一次成功沉淀成下一次可复用的规则。
AI 的本质是把执行成本推向极限，而人的本质是把正确性定义推向极致。
两者相乘，才是 Agentic Coding 的全部。
真正的智能编程，不是让 AI 自由奔跑，而是先把轨道铺好，再让它以最高速度运行。