代码不再稀缺之后（二）：从 AI 写代码，到 AI 参与交付

不知不觉，离开前东家已经一年了。这一年学到了很多，也经历了很多之前没办法想象的事情。

很多人觉得我的选择难以理解，我自己也很难精确解释。归根结底，我只是想做点有趣的事情。

这篇文章写的就是其中一件：我们在 AI 时代尝试搭建的一套新的交付工作流。八月写过初版，最近不少人来找我们了解这套做法，所以把这几个月的实践更新到了这里。

最近开源大佬 yetone 也公布了他的工作流。我们对照后发现，核心理念基本殊途同归。我们的金融业务额外要求一些非加不可的人为审查和测试，这也决定了我们能把自动化推进到哪里。我们把适合自动化的执行交给 Agent，把关键业务判断和发布授权留给人。

现在这套工作流的核心是 Claude Code 和 Claude Opus 5.5。Codex 参与排查、开发和验收，Grok Bot 负责独立 CR 和验证。规则、步骤和证据都留在工程系统里，别的执行者也能接着用。但能接手不等于能做出同样的效果。就我们目前的使用体验看，换成其他模型和 Agent，未必能达到同样的效果。

我们维护的是一套跨多个仓库的金融业务系统，一个需求可能穿过前端、中台、领域服务和外部渠道。在这里，模型写出一段代码不难。难的是找到该改的位置，守住业务约束，再证明改完结果仍然正确。

按 8 月至 10 月三个主要仓库的记录粗略统计，约 1,900 个变更 PR 进入 release，其中约 1,800 个可追溯到成功的生产部署。同期已交付版本的业务与测试源码快照新增约 63 万行、删除约 6 万行，其中新增测试源码约 29 万行。代码量按期初、期末快照比较，不累加每次 PR 的改动。这些数字记录了实际交付规模。新增源码里接近一半是测试，这体现了我们对验证的投入。

下面这张图是我们现在的交付全貌。

图里画的是我们围绕交付建立的分工与反馈关系。人在起点明确目标和验收标准。开发、评审、修复和复评由 Agent 持续推进。改动先在测试环境验证，再由人授权合并与发布。所有阶段共用同一批规则、工具和记录。

人留在这几处，是我们有意的取舍。资金语义、权限边界和发布时机一旦判断错，可能影响用户的资金，回滚代码也未必能撤销已经发生的交易。这些判断的依据也常常不在仓库里。Agent 可以把证据摆齐，把风险标出来。验收标准是否成立、业务取舍能否接受、什么时候进入生产，这些由人决定，也由人负责。

不换平台，在已有的工程现场上组织

做 Agent 化时，一个自然的冲动是换平台：把需求搬进更好看的看板，再接一个能派发任务的控制台。我们看过几种能把 Issue、本地 Agent 和执行状态串起来的方案，最后还是保留 GitHub Issue，继续在本地用 Claude Code 和 Codex。

这类执行者和工程师在同一个地方工作，用同一个仓库、同一套 CLI、同一批测试和部署脚本。需求、决定、评审和 CI 结果本来就在 GitHub 里。再引入一个平台复制这些事实，就要处理同步和冲突。

它们的长处在于能把读取现场和执行动作连起来。有一次 UAT 发布停在了 Progress Deadline Exceeded，按过去的分工，要从值班同事、平台同事一路交接到后端。那次我们把仓库、目标环境和故障现场直接交给了 Codex。它沿着 Deployment、Pod 和启动日志往下查，确认集群没有问题，真正的原因是一个回调处理器没有被 Spring 加载。它完成修复和验证，提了 PR，另一个模型独立审过，最后由工程师做 CR。

所以补一项自动化时，我们通常先提供可靠的执行入口和清楚的规则，不必先为每个异常分支设计专用流程。前提是 Agent 的判断要接受验证，工具权限和任务范围要清楚。

分工也可以按任务调整。十月有一次跨仓库审查，修复交给 Claude，验收交给 Codex，两边用的是同一套规则和同一批 PR。

规则、步骤和状态都留在工程系统里

人和人协作时，很多背景靠一句“上次那个问题”就能补齐。Agent 没有这种默契，新开一个会话，之前的背景不一定跟过去。不解决这一点，工程师就会变成上下文的搬运工。

我们的做法叫 X as Code（XaC）：规则能版本化，步骤能执行，事实和状态留在工程系统里。Issue 和 PR 记录需求与决定，AGENTS.md 和专题规范记录约束，Skill 和脚本承载重复步骤，CI 做确定性检查，基础设施用 Terraform 描述。业务取舍仍然是文字，比如渠道已成功、本地失败时该怎么处理。这类文字写在 Issue 或代码注释里，能被找到、被引用，过时了也能被发现。

主要仓库的 CLAUDE.md 直接链接到同目录的 AGENTS.md。如果给不同执行者各维护一份，规则迟早会分叉。

规则放在哪，也决定了要读多少。早期我们出一次问题就往 AGENTS.md 里加一条。几轮之后，改一个前端小组件也得先读一堆资金和事务背景，关键规则反而被淹没了。后来我们改成按任务逐层读取。

Agent 先读全仓约束和工作入口，改动进入哪个目录，就读那个目录的边界。然后通过专题索引，只进入这次涉及的金额、事务、租户或契约专题。最底层是代码、测试和运行证据，用来校验前面的理解。核实已实现的行为时，代码优先于注释，注释优先于文档。

所以文档只写代码里读不出来的东西，包括角色、边界、资金语义、设计取舍和踩过的坑，不复制类清单和字段表。复制代码结构的文档迟早过期，Agent 和新同事都会照着它得出错误结论。我们清理过描述与实际实现不符的文档，也把用不上的 Skill 移出了加载目录。上下文不需要填满，够准就行。

主要仓库的规则把“简单优先”放在第一条：能复用就不新增抽象，新增状态前要证明它代表独立的业务语义。评审时我们常问：删掉这项设计，需求还能满足吗？能，就删。AI 很容易把小需求写成顺手的重构。这条规则控制了交付体量，也控制了下一个接手者要理解的东西。

规则随实践更新，审查者也要说明自己实际检查了哪些路径。

独立评审，和不需要人催的跟进

八月之后最大的变化，是 CR 和独立验证交给了 Grok Bot。实现者仍然自测，CI 仍做确定性检查，人负责关键业务判断。

需要独立审查，是因为实现者的自测容易沿用实现时的假设。Grok Bot 从需求和仓库规则出发，检查实现者没有证明的部分，这些部分常在 diff 之外。比如一个出金动作，不能只看提交接口有没有做幂等，还要沿调用链看补偿任务、人工重试和 Webhook：渠道已成功、本地写入失败时，再执行一次会怎样？

验证方式按任务决定。有时核验代码、测试和 CI 证据，有时在测试环境实际跑接口、页面并检查部署结果。报告要分清哪些实际执行过，哪些只核对了已有证据，哪些还没验证。独立评审、CI 和人工判断各自承担一部分验证责任。实现者收到意见后要回到代码核对：成立的就修，不采纳的说明理由，涉及资金、权限或业务语义的决定交给人。

接入 Grok Bot 之后，人身上还剩一类活：等评审、看意见、修复、等 CI、再看有没有新问题。如果每一步都要人回来说一句“继续”，等待和切换上下文的成本就还在。PR watch 负责持续跟进，Autopilot 在当前会话里推动 PR 达到可合并状态。每一轮都从 GitHub 读取最新状态，处理范围内的冲突、评审意见和 CI 失败，修完再交给评审复评。PR 达到可合并状态后，合并与发布遵循人的授权。

发布对上运行结果，问题回到工程资产

从 Issue 走到生产，先要在测试环境验证改动，再由人授权发布。Grok Bot 按任务执行测试环境验证，结论要和实际部署的版本、实际运行的结果对得上。发布前后的运行证据由相应的 Skill 核对。读不到运行环境或数据库时，结论就是“缺证据”，不能因为代码一致就宣布可以发布。

“绿色”能证明什么，也要说清楚。CI 通过只说明预设的检查通过了，不能说明外部渠道、页面交互和生产链路都没问题，更不等于业务验收。我们禁止用删断言、放宽条件或跳过失败的办法让测试变绿。修 Bug 先写一个在旧实现下会失败的用例，证明测试确实能识别原来的错误。

早期每次事故都往规则里追加一段，文件越写越像检讨书，却很少拦住同类问题。现在发现问题后，我们先判断它该以什么形式留下来：能稳定复现的留回归测试，能机械识别的做成检查，只有业务背景才能解释的写进代码注释，跨模块的约束进专题规范，重复执行的流程做成 Skill。

开发验证使用隔离环境，并根据共享数据库和外部渠道沙箱的依赖安排并行任务。

我们现在的判断

工程资产要能迁移，执行者的能力也有门槛。单一规则源、可调用的 Skill 和对得上版本的证据，让 Claude Code 和 Codex 能在同一批 PR 上分工，以后也能接入新的执行者。这些资产决定了接手的起点，能做到多深还要看执行者本身。我们现在把主线放在 Claude Code 和 Opus 5.5 上，依据是目前的实际使用。

人的注意力放在三件事上：目标和验收标准对不对，关键的业务取舍对不对，什么时候允许改动进入生产。剩下的部分每个月都在变。我们继续把需要人转述、催办和重复核对的环节交给 Agent，看看还能往前走多远。这也是这件事让我觉得有趣的地方。