多AI协作开发如何避免“自己写、自己审”：Codex、Claude Code与工程验收闭环
多 AI 协作开发如何避免“自己写、自己审”：Codex、Claude Code 与工程验收闭环
多 AI 协作真正解决的，不是让更多模型同时写代码，而是重新建立需求、执行、审查、测试和验收之间的职责边界。
前言
我叫张智博，就读于石家庄邮电职业技术学院。
过去一段时间，我使用 AI 参与个人网站、评级币运营工具、企业内容系统和项目材料整理。
一开始，我也尝试过把一句很长的需求直接交给一个模型：
请帮我把整个项目全部做好， 功能完整、界面高级、没有Bug， 并且自动部署。这种方式看起来省事，但结果往往会出现几个问题：
- AI 自己补充了没有确认的需求；
- 功能很多，但核心流程不好用；
- 页面视觉被修改后，原有逻辑被破坏；
- 工具完成实现后，又自己宣布“全部正常”；
- 修复一个问题时引入另一个问题；
- 多轮对话后，项目约束逐渐丢失。
后来，我开始把不同 AI 拆成不同角色，并增加工程验收门槛。
一、核心原则：执行者不能成为唯一验收者
我目前常用的角色划分是：
| 角色 | 工具 | 主要职责 |
|---|---|---|
| 需求与最终决策 | 人工 | 目标、边界、事实、取舍 |
| UI方案 | Stitch | 布局、视觉参考、组件结构 |
| 工程执行 | Codex | 编码、修复、测试、部署 |
| 产品与代码审查 | Claude Code | 流程审查、缺陷分析、风险检查 |
| 自动验证 | CI与脚本 | 构建、类型、测试、链接、产物检查 |
这并不是因为某个工具只能完成某一种任务，而是为了避免：
同一个模型 → 自己解释需求 → 自己完成实现 → 自己证明没有问题二、建立一个项目事实源
多轮 AI 协作最容易发生“上下文漂移”。
因此，项目根目录应该有一个稳定的事实文件：
PROJECT_CONTEXT.md内容包括：
# 项目目标 构建一个评级币运营工具，核心流程是： 输入闲鱼主页 → 读取商品 → 预览 → 导入飞书 # 当前必须保留 - 现有SQLite数据 - 永久商品编号 - 商品图片关联 - 飞书字段映射 - 同步日志 # 明确删除 - Excel导出 - 无用批量导入 - 重复入口 # 不允许 - 未确认直接覆盖成本和库存 - 为了重构删除现有可用功能 - 使用模拟数据冒充真实接口成功 # 完成标准 - 构建通过 - 现有测试通过 - 核心流程可手动验证 - 失败状态有明确提示任何 AI 开始任务前，先阅读这个文件。
它比依赖聊天记录更加稳定。
三、每个任务使用任务契约
一个可执行任务至少需要：
目标 允许修改的范围 禁止修改的范围 验收标准 输出要求示例：
# 任务：修复飞书附件导入 ## 目标 解决多附件记录只保存第一张图片的问题。 ## 允许修改 - 飞书附件解析模块 - 附件关联表写入逻辑 - 对应测试 ## 禁止修改 - 商品编号生成规则 - 库存状态 - 页面整体视觉 - 数据库已有记录 ## 验收标准 1. 一条记录包含3个附件时，保存3条附件关联； 2. 顺序与来源一致； 3. 重复同步不产生重复附件； 4. 测试通过； 5. 输出改动文件和验证结果。任务越明确，AI 越不容易“顺便重构整个项目”。
四、先让审查模型找问题，不要直接修改
当需要产品审查时，我会把任务分成两个阶段：
阶段一：只审查，不改代码 阶段二：把审查结果交给执行模型修改审查结果应当包含：
问题 证据 影响 优先级 建议 验收方式示例：
| 问题 | 证据 | 影响 | 优先级 | 验收方式 | |---|---|---|---|---| | 同步失败无具体原因 | UI只显示“失败” | 用户无法判断如何重试 | P0 | 模拟超时并检查错误提示 | | 重复导入无预警 | 未显示来源记录状态 | 可能产生重复商品 | P0 | 连续导入同一记录 |这种方式可以避免审查模型直接大规模改动，导致无法区分“原问题”和“新改动”。
五、执行模型必须提交可审查的差异
AI 完成修改后，不应只返回：
已全部完成，程序运行正常。而应返回：
修改了哪些文件 每个文件为什么修改 运行了哪些命令 哪些测试通过 哪些内容没有验证 是否存在遗留风险推荐输出模板：
## 改动文件 - `src/feishu/attachments.py` - `tests/test_attachments.py` ## 实现内容 - 支持遍历全部附件； - 使用来源Token去重； - 保存sort_order； - 补充重复同步测试。 ## 验证 - `pytest`：通过 - `python -m compileall`：通过 - 真实飞书环境：未验证 ## 遗留风险 - 超大附件下载仍需增加大小限制。明确写出“未验证”，比没有证据地宣布“全部正常”更有价值。
六、自动检查应当成为合并门槛
前端项目常见门槛：
{"scripts":{"lint":"eslint .","typecheck":"tsc --noEmit","test":"vitest run","build":"next build","check":"npm run lint && npm run typecheck && npm run test && npm run build"}}Python 项目可以使用：
ruff mypy pytest compileallGitHub Actions 示例：
name:Quality Gateon:pull_request:push:branches:-mainjobs:verify:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-uses:actions/setup-node@v4with:node-version:20cache:npm-run:npm ci-run:npm run lint-run:npm run typecheck-run:npm run test-run:npm run buildAI 可以解释测试结果，但不能替代命令的真实执行。
七、UI修改需要建立视觉不变量
AI 修改页面时，经常会“优化”掉原本正确的设计。
因此，可以明确视觉不变量：
首屏背景不变 导航结构不变 品牌名称不变 字体层级可以调整 项目卡片内容可以优化 移动端必须可用还可以为关键页面保存截图基线：
首页桌面端 首页移动端 导航展开状态 项目详情首屏 错误状态修改完成后，应逐项对照，而不是只看某一个局部页面。
八、不同模型负责不同层次的审查
同一份代码可以经过三层审查：
第一层：编译和自动测试 第二层：代码与安全审查 第三层：真实用户流程验收例如评级币同步工具：
自动测试 → 是否正确去重 代码审查 → 是否存在事务和异常处理问题 人工验收 → 用户是否看得懂预览、跳过和失败状态三层关注的问题不同，不能互相替代。
九、限制一次任务的改动半径
任务过大时，AI 容易在多个模块之间产生连锁修改。
建议约束：
一次任务只解决一个主问题 修改文件数量必须能够解释 数据库迁移单独审查 UI和后端逻辑尽量分开提交 部署变更单独验证Git 提交也应保持清晰：
fix: preserve all Feishu attachments test: add idempotent import coverage docs: update synchronization workflow不要把大量修改统一提交成：
update project十、控制Token的关键是减少重复上下文
多 AI 协作并不意味着把整个项目每次都重新解释一遍。
更节省上下文的方式是：
项目长期事实 → PROJECT_CONTEXT.md 本次任务 → TASK.md 审查结果 → REVIEW.md 验收记录 → ACCEPTANCE.mdAI 每次只读取必要文件和相关代码。
对于大型仓库，还可以明确：
先定位相关模块 不要遍历无关构建产物 不要重复读取锁文件 不要在未确认前安装新依赖十一、数据库变更必须单独审查
AI 修改数据库时，风险通常高于普通 UI 修改。
迁移任务至少需要回答：
新增了什么字段 旧数据如何兼容 是否允许为空 是否有默认值 回滚方案是什么 是否会覆盖原数据示例迁移说明：
## 数据库变更 新增字段： - `source_platform` - `source_record_id` - `sync_status` 兼容策略： - 历史数据的`source_platform`默认为`local`； - `source_record_id`允许为空； - 不修改现有商品编号； - 不覆盖成本、库存和利润字段。 回滚方式： - 删除新增索引； - 删除新增字段； - 恢复迁移前备份。数据库迁移不能只写“已自动升级”。
十二、部署完成不等于任务完成
一个完整的部署验收应包括：
构建是否成功 部署流程是否成功 线上首页是否可访问 二级页面是否可访问 静态资源是否加载 关键交互是否正常 Canonical是否正确 接口是否连接真实环境可以将验收结果保存为：
# 发布验收 ## 自动检查 - 构建：通过 - 类型检查：通过 - 测试：通过 - 链接检查：通过 ## 线上检查 - 首页：HTTP 200 - 项目页：HTTP 200 - 移动端导航：正常 - 表单提交：正常 ## 未验证 - 低速网络下的视频加载 - 旧版Safari兼容性十三、我的完整协作闭环
目前我更倾向于使用以下流程：
1. 人工确定真实目标 2. 写清任务契约 3. 执行模型定位并修改 4. 自动运行质量门槛 5. 审查模型检查产品与代码 6. 执行模型根据审查修复 7. 人工完成真实场景验收 8. 合并、部署并记录结果对应产物：
需求有文档 修改有差异 测试有结果 审查有证据 验收有记录 部署可追溯十四、总结
多 AI 协作真正解决的，不是让更多模型同时写代码，而是把软件工程中的职责分离重新建立起来：
需求不等于实现 实现不等于正确 测试不等于好用 审查不等于验收 上线不等于结束我在个人网站、企业内容系统和数据同步工具中逐渐形成的原则是：
AI 可以承担大量执行工作，但项目事实、边界、验收标准和最终责任必须掌握在人手中；执行者不能成为唯一验收者，任何“已完成”都应该有可以复现的证据。
关于作者
张智博，石家庄邮电职业技术学院学生，主要关注 AI 工具应用、产品设计、网站建设、项目运营与工程化实践，持续使用 Codex、Claude Code、Stitch 等工具探索多 AI 软件开发流程。
个人作品集：张智博的思考空间
个人官网：https://www.zzb9.cn
GitHub：https://github.com/zzb99