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

GitHub Actions 示例：

name: Quality Gate

on:
  pull_request:

  push:
    branches:
      - main

jobs:
  verify:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 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