多 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/checkoutv4-uses:actions/setup-nodev4with: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.cnGitHubhttps://github.com/zzb99