用 AI 做工程，但不交出控制权

关于编码 Agent，有意思的问题已经不是它能不能写出代码，而是一个团队能不能把这种能力转化成可靠的交付。

给 Agent 一个有边界的任务#

「优化一下这个服务」不是一条可执行的指令。一个足够强的任务描述会指明：要改变的行为、仓库与分支、必须保持成立的约束，以及完成时需要提交的证据。

这本来就是工程纪律。AI 只是让含糊的需求失败得更快、规模更大。

把探索和变更分开#

面对陌生系统，第一遍应当是只读的：追踪真正生效的代码路径、配置、部署状态和数据归属。之后工作流才应该提出变更。

在生产系统周围，这种切分尤其重要。一个看起来合理的猜测不是证据，而一次自动化的写入仍然是一次生产写入。

把验证当作交付物#

Agent 应该交回的不只是一份 diff。有用的证据包括：

• 针对本次行为变化的定向测试；
• 必要时的完整构建或类型检查；
• 面向用户的改动需要的视觉核对；
• 部署健康状况和一次生产侧回读；
• 明确写出哪些部分没有被验证。

这样评审者面对的是一条紧凑的证据链，而不用去重建整个会话过程。

在后果发生变化的地方保留人工闸门#

有些边界值得确认：写生产数据、对外发布、授予新权限、改动被其他服务共用的基础设施。目标不是给每条命令都加审批，而是让「后果变重的那一刻」变得显眼。

最好的 AI 工作流不是处处自治，而是处处可预期。