多AI协作开发如何避免“自己写、自己审”：Codex、Claude Code与工程验收闭环

多 AI 协作开发如何避免“自己写、自己审”：Codex、Claude Code 与工程验收闭环

多 AI 协作真正解决的，不是让更多模型同时写代码，而是重新建立需求、执行、审查、测试和验收之间的职责边界。

前言

我叫张智博，就读于石家庄邮电职业技术学院。

过去一段时间，我使用 AI 参与个人网站、评级币运营工具、企业内容系统和项目材料整理。

一开始，我也尝试过把一句很长的需求直接交给一个模型：

请帮我把整个项目全部做好， 功能完整、界面高级、没有Bug， 并且自动部署。

这种方式看起来省事，但结果往往会出现几个问题：

• AI 自己补充了没有确认的需求；
• 功能很多，但核心流程不好用；
• 页面视觉被修改后，原有逻辑被破坏；
• 工具完成实现后，又自己宣布“全部正常”；
• 修复一个问题时引入另一个问题；
• 多轮对话后，项目约束逐渐丢失。

后来，我开始把不同 AI 拆成不同角色，并增加工程验收门槛。

一、核心原则：执行者不能成为唯一验收者

我目前常用的角色划分是：

这并不是因为某个工具只能完成某一种任务，而是为了避免：

同一个模型 → 自己解释需求 → 自己完成实现 → 自己证明没有问题

二、建立一个项目事实源

多轮 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 compileall

GitHub 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 build

AI 可以解释测试结果，但不能替代命令的真实执行。

七、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.md

AI 每次只读取必要文件和相关代码。

对于大型仓库，还可以明确：

先定位相关模块 不要遍历无关构建产物 不要重复读取锁文件 不要在未确认前安装新依赖

十一、数据库变更必须单独审查

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