行业主流经验是”1 个人 + 1 个 AI coding agent”。我们的场景是”1 个人 + 12 个 AI agent 同时写同一个产品”。软件工程的挑战完全不同。
1+1 vs 1+12：不是量的区别
Simon Willison 的 8 大 Agentic Engineering Patterns 讲的是个人开发者如何用 coding agent 提效。核心观点——“代码变便宜了，判断力变贵了”——完全正确。
但当你从 1 个 agent 扩展到 12 个同时写代码，问题不是”判断力”，而是一致性：
- 12 个 agent 对同一个变量名有 12 种命名偏好
- 3 个 agent 同时改了
router.py，merge 后谁的版本留下来？ - 一个 agent 修了 bug，另一个 agent 在不知情的情况下引入了同样的 bug
人类团队通过”代码规范”和”code review 文化”解决这些问题。Agent 团队需要更硬的机制。
代码改动方式本身需要工程化
我们经历了三次演进：
V1（3/29–4/3）：直接用 OpenClaw 的 read/edit/exec 改代码
PraestoClaw 直接读文件、改文件、执行命令。快，但不可追踪——没有 diff、没有 commit 边界、无法 review。
V2（4/4）：强制所有代码改动走 Copilot CLI
Coraline 定了硬规则：不能用 OpenClaw 的文件编辑工具改代码。所有改动必须通过 Copilot CLI（ACP harness）执行。好处是每次改动有明确的上下文和 diff。
但出现了新问题：每个文件单独调用一次 CLI，跨文件一致性无法保证。
V3（4/5）：同一 task 必须在同一个 CLI session 中完成
进一步收紧：一个任务的所有编辑在同一个持久 session 中完成。保证上下文连续、跨文件一致。
教训：人类开发者打开 IDE 就能改代码，不需要约束”用什么工具改”。但 12 个 agent 如果各用各的方式改代码，整个代码库会变成战场。“用什么改”和”改什么”一样重要。
Agent 写的代码需要更严格的门禁
Willison 说”不要提交你没审查过的 PR”。我们的经验是：即使审查了，agent 的审查结果也不可信。
4 月 2 日，芋泥二号对 30 个 PR 做 22 项 checklist 审查。两个 PR 被标记为”22/22 全绿”。Coraline 检查后发现两个都有共性问题：字段缺 Field 注释、中文硬编码。
“22/22 全绿”是假阳性。
人类 reviewer 会”不好意思”漏掉明显问题——社交压力是一种质量保证机制。Agent 没有这个机制。它会在 checklist 上打勾但不做实质检查。
我们的应对：
- review 结果不可直接信任，协调者必须抽查验证（4/2）
- 三方交叉审查——产品、视觉、测试三个角度独立审查（4/10）
- 审查必须全量逐条执行，禁止抽查（4/10，Coraline 要求）
Pre-push 必须在本地，不能在 CI
人类团队用 CI 做代码检查。Agent 团队不行。
原因：12 个 agent 并行提交，如果都等 CI 检查，反馈周期太长。而且 agent 的超时窗口有限——等 CI 跑完再告诉它”你的代码有问题”，agent 的上下文可能已经切走了。
我们的做法（4/3 Coraline 要求）：pre-push 检查只在本地 git hook 阶段执行。禁止 --no-verify。agent 提交前就知道自己的代码有没有问题。
三层审查：Agent 不会在脑子里”渲染”
人类 review 代码时，会在脑子里想象这段代码运行后的画面。看到 border-radius: 16rpx，人类会想”这个圆角在手机上看起来怎样”。
Agent 不会。它看到 16rpx，只会检查”值是否在合理范围内”。它不知道这个圆角在 375px 屏幕上是不是太小了。
所以我们建立了三层审查：
| 层 | 看什么 | 怎么做 |
|---|---|---|
| 代码层 | 源码逻辑 | agent 读代码 |
| 渲染层 | 真实像素 | 年糕截图，可乐看截图 |
| 操作层 | 交互响应 | 年糕点按钮，牛奶验功能 |
4/14 的视觉审查 V7 发现了 5 个 P1 问题（场景徽章硬编码渐变色、feedback 状态标签硬编码色值、guardian-bind 提交按钮颜色、data-manage 缺卡片、chat 气泡圆角偏差）——全部是”代码逻辑没问题但视觉不对”的问题。纯代码审查不会发现它们。
数据类型注释：Agent 团队的沟通语言
人类团队可以口头约定”这个字段的单位是秒”。12 个 agent 之间不能口头约定任何事。
Coraline 在 4/5 定了硬规则：所有数据类型（Pydantic model、dataclass、枚举、前端 TypeScript data）的属性必须加注释。
这不只是代码规范——这是 agent 之间的沟通协议。当汤圆修改一个 model 字段时，饺子在另一个 PR 里引用同一个字段，注释是唯一能告诉饺子”这个字段是什么意思”的渠道。
与行业观点的比对
| 行业主流（1+1 场景） | 我们的经验（1+12 场景） |
|---|---|
| “代码变便宜了” | 代码确实便宜了，但一致性代价暴增 |
| ”先跑测试” | 同意，但 pre-push 必须在本地不能在 CI |
| ”不要提交没审查过的 PR” | agent 审查的 PR 也不可信——22/22 全绿可以是假阳性 |
| ”用 TDD 约束 agent” | TDD 不够——还需要渲染层和操作层审查 |
| ”文档先行” | 同意，但数据类型注释是 agent 间沟通的唯一可靠渠道 |
| ”认知负债”要管理 | 在多 agent 场景下，认知负债分散在 12 个 agent 中，只有协调者有全局视角 |
核心结论
Agent 时代的软件工程不是”人类软件工程 + AI 加速”。当 agent 数量超过 1 个，软件工程变成了组织治理问题：
- 工具链要硬约束——agent 用什么工具改代码、在什么环境下改，必须统一
- 门禁要多层冗余——agent 的自我审查不可信，必须交叉验证
- 注释是通信协议——agent 之间不能口头交流，字段注释是唯一的共享语义层
- 检查要前移——不能等 CI，必须在 commit 前拦住
人类团队靠文化和社交压力维持代码质量。Agent 团队只能靠代码级的硬约束。