双AI协作578次提交零手写：ERP项目Vibe Coding管理术

当AI写代码不再是新鲜事，真正的挑战变成了：如何确保AI写出的代码可靠、可维护，并且真正符合业务需求？一位B站UP主用29天时间，让两个AI模型协作完成了ERP财务模块的开发，全程零手写代码，累计578次提交。更关键的是，这套方法在借贷必平的会计严格场景下依然稳住了。

为什么选择ERP作为试验场

ERP财务模块堪称Vibe Coding的“困难模式”。借贷分录必须逐位平衡，关账后不能再挤，挤错了只能冲销不能删除；并发操作同一月份时，结果必须完整不能只完成一半；数据库升级时，空库上升不代表老数据也能平滑迁移。UP主直言：“我拿它来说来证明这套方法扛得住，这种项目都能稳住，你手上的项目只会更轻松。”

这个名为Redmi的项目从科目表做到年结，被拆分成40个工作包，AI被开了32份整改任务书，按1920和768两种宽度规则拍了767张截图，被打回重做再验收。每一步都留在Git里，一条一条查得到。

ERP财务模块的复杂性不仅体现在借贷平衡上，还涉及会计期间（如月度关账）的概念。关账后，该期间的账务被锁定，任何调整都需要通过冲销或追加分录来实现，而不能直接修改历史记录。这种设计是为了保证审计线索的完整性和财务数据的不可篡改性。此外，并发操作要求系统具备事务隔离机制，确保多个用户同时操作同一会计期间时，数据的一致性不会遭到破坏。数据库迁移则需考虑空库升级与已有数据升级的差异，后者往往涉及数据转换和兼容性处理，是实际项目中的常见痛点。这些特性共同构成了Vibe Coding的“困难模式”，使得AI协作开发面临严峻考验。

双模型分工：一个写，一个验

核心方法只有一句话：一个模型写，一个模型验，中间全靠文档交接，最后拿证据说话。两个AI从不直接对话，所有交接都写成Markdown提交进Git。

具体角色分三个：

• PM模型：拆需求、写任务书、独立验收，不合格就开整改单。
• 执行模型：找任务书写代码、跑测试、交证据。
• 你自己：定方向、做取舍、负责传话。

在UP主的例子里，PM模型是Codex，执行模型是Claude Code（简称CC）。这套分工不挑工具，任何两个模型或工具都能这样分。说个细节，10月2日起代码改由Codex写，但规则没变——578次提交中，406次带Claude署名，103次是PM测文档与合并，69次出自Codex。

Git提交署名（如“Claude署名”）是指在版本控制系统中，每次提交都会记录作者信息。在本项目中，通过提交信息中的署名可以区分代码是由哪个AI模型生成的，以及哪些提交是PM模型进行的文档更新或合并操作。这种实践有助于追溯代码来源，并在出现问题时快速定位责任方。同时，提交署名也反映了协作流程的透明度，所有操作都留有痕迹，便于后续审计和复盘。

文档体系：八份文件构建协作骨架

项目第一天就定下了分工，随后形成了八份核心文档：

1. Redmi项目：第一天的分工地图。
2. CLAUDE.md：执行方每次开工先读的门牌。
3. 协作规则：谁当PM、谁动手、怎么验收。
4. 路线图：把大需求拆成一个个包。
5. 任务书：PM写给执行方的施工单。
6. PM Task入口：一把开工的钥匙。
7. 执行记录：跑了什么、结果怎样，全写下来。
8. 审查记录：PM的结论。

每份文件旁边都标了是谁写的。协作规则里明确：Codex不直接编写产品代码，执行方不能宣布自己的工作已经通过最终验收。验收只准用三个词：ACCEPTED（通过）、Changes Required（退回修正）、Blocked（卡住了，缺业务决策或外部条件）。

任务书：一份289行的合同

任务书是整个协作的核心。以Wave C的外币任务书为例，全文289行，第三节必须完整读取后执行，不得只按命令摘要行动；第五行授权基线钉死到一个提交号（SHA），预计4到6小时但时长不是完成标准。任务书在9月15日上午10点24分提交进Git，这就是签发——签发以后，大家说的任务书就只能是这一版。

任务书十节内容，每节都针对一种真实的失败模式：

• 授权与目标：写死“不要写完规格后停下询问，连续做完C01到C05”，防止执行方每走一步都来问。
• 开工闸门：动手前只读核对六项，任一项不成立立即停止并报告，不得自行修复。
• 必读事实和权威顺序：本任务书的PM裁决排第一，然后是治理架构、上一包真实代码，Oracle资料排最后。
• 会计规则：PM先定死，执行方不再讨论。
• 测试成本预算：禁止用反复全跑代替诊断测试。
• 硬停止条件：要靠猜才能算出外币余额时必须停下交给PM。
• 修改边界：禁止改迁移和所有已验收的记录。
• 交付与报告：只能本地提交，不得自行写ACCEPTED，结尾二选一：Submitted或Blocked。

“289行我作业都没这么长，每一节我都只能选择一种真实的失败写长一次，审下的是后面好几轮反攻。”

SHA（Secure Hash Algorithm）是Git中用于唯一标识提交对象的哈希值。每个提交都有一个唯一的SHA值，任何对提交内容的修改都会导致SHA变化。在任务书中钉死授权基线SHA，意味着执行方必须基于该特定提交进行开发，确保代码版本的一致性。开工闸门中的校验包括确认磁盘上的任务书与签发版本一致，以及SHA的上一个提交精确等于业务基线，这防止了因文件被篡改或版本错位导致的开发偏差。

开工令与技能：如何让AI照章办事

任务书写好了，怎么交到执行方手里？靠一把只有16行的钥匙——PM Task入口文件。它描述里写着“仅在用户明确输入本命令时使用”，正文第一件事是“允许并完整执行这份任务书”，然后钉死两个提交号。

UP主的操作很简单：在CC里新建一个任务，输入斜杠加命令名，回车，剩下的AI自己去读任务书。CC做的第一件事不是写代码，而是核对闸门——确认磁盘上的任务书和签发那一版一致。如果签发提交对不上，入口写得很清楚：立即停止，不猜测也不自行修复，状态写Blocked等PM裁决。

9月29日以后，入口升级到53行，长出来的全是校验：盯死签发提交SHA，要求SHA的上一个提交精确等于业务基线，三份证文各自的文件指纹都盯死。读任务书也不读磁盘，而是用git show从签发提交里直接取——就算磁盘上的文件被改过，读到的也一定是签发那一版。

执行方还要装上指定的技能。UP主用了Superpowers插件（版本6.3.0），两个AI都装了同一版本。最常要求的技能包括：写需求写规格、按计划执行、先红后绿（TDD）、完成前验证。技能里的原话很硬：“没有先失败的测试，就不许写产品代码”“没有新鲜的验证证据，就不许宣称完成”。如果技能和任务书打架，听任务书的——任务书宪法和PM裁决高于技能。

独立验收：最值钱的一步

执行方交审之前先自己审一遍，但文件头明确写着“这是事实记录，不是验收结论”。主agent派出两个只读的子agent：审查A只看会计公式、数据库权限和锁；审查B只看接口、前端和可访问性。两份报告没有一条重叠，但有一个缺陷两个人都没读出来——是跑浏览器跑出来的。“同一事实的两份副本，靠阅读不容易发现它们已经分叉，靠运行会。”

PM验收时只信证据。有一次CC自己报出测试行比0.966超标，PM没有豁免，直接退回。退回不是口头说一句改一下，而是一份新的整改任务书，基线就是被退回的那个候选版本，每一项整改都绑定审查里的一条结论，还写死了“不许靠sleep运气，要亲眼看到真实的阻塞”。

最后一关，PM没有只看报告，而是在验收里确认了变异测试：故意把代码改坏，看测试能不能抓到。这些都做完，才写下ACCEPTED。

整套流程下来，PM结论统计：退回24次，通过18次（含部分接受和有限接受）。退回原因排第一的不是业务逻辑，而是证据不够硬——截图缺失、报告写错、测试其实没起作用。

变异测试（Mutation Testing）是一种评估测试用例有效性的方法。它通过故意在代码中引入小错误（变异），然后运行测试套件，检查测试是否能发现这些错误。如果测试未能捕获变异，则说明测试用例存在不足。在本项目中，PM在验收时确认了变异测试，以确保测试不仅能通过，还能真正检测出潜在缺陷。这比单纯依赖测试通过率更能保证代码质量，尤其是在财务这种对准确性要求极高的场景中。

代码铁律与门禁：59行的硬约束

项目宪法里有一条“反北极星”——页面数量、代码量、空壳模块、测试绿色都不能冒充真实交付。但UP主坦言：“这份宪法到今天还是草案，真正生效的是我一条条补下的专项裁决。”

管住AI写法的是59行代码铁律：一个手写文件最多300行有效代码，一个函数最多50行，分支不超过10，嵌套不超过三层，参数不超过5个。禁止压缩代码多语句挤一行来规避限制。财务专属规则包括：金额禁止用浮点（0.1加0.2不等于0.3），同一会计事件同一账簿只记一次账，已过账凭证不得直接改删、只能冲销或追加。

铁律是文字，门禁是代码。300这个数字直接写进脚本，超过300行质量门禁直接失败。WFC自己就撞上了——两个迁移文件太长被拦下，拆成了四个，它没有放宽门禁，而是按自然接缝拆开。

所有检查只有一个入口：Verify脚本，后端、前端、端到端、质量四个目标，任何一个失败就返回非零退出码。门禁每次运行还会报告自己的盲区，比如用纯数字写的审批门槛、税率、科目号，静态扫描扫不出来——注释写着“这样绿灯就不会被误当成完全合规的证明”。

三档配置：从个人项目到ERP级

这套方法不必全套照搬。UP主给出了分档建议：

• ERP级：长任务书钉死文件指纹，PM复算和变异测试，11道门全开。
• 普通业务项目：30到60行任务书，一条Verify命令，再让另一个模型看一遍改动和测试结果。
• 个人小项目：同一个开两个对话也行，关键是写下来别省。10到20行任务书写清目标、不做和完成标准。

最小起步包一共六个文件：入口文件（谁写谁验先读什么）、铁律（五条以内）、任务书模板（目标、不做、能改不改的文件、结尾状态）、执行记录（跑了哪些命令几次结果）、审查记录（结论三选一）、一条验证命令。任何一步失败就返回非零。

“AI会犯错，这一个月里它犯了很多次，我能做的是让查出来的错在合入主线之前就被拦下。Vibe coding不是放手不管，而是换一种方式把关；两个AI不是为了互相替代，而是为了互相看住。”

双模型协作的代价与启示

这套方法并非没有成本。Wave C一天退回三次，约13小时；财务相关任务书文件64份，执行记录188份；两个AI不直接对话，每一轮都靠人传话。但UP主认为值得：“退回三次CC不会崩溃，PM也会写漏写错，规则也是边做边补的，大家都在边干边学。”

对于任何正在尝试Vibe Coding的开发者，这套方法提供了一个可操作的框架：从最小起步包开始，项目变复杂再一档一档往上加盐。先写一份任务书试试，可能是比让AI直接写代码更好的起点。