AI小说工厂(七)：多AI协作——人类当调度器

项目中期出现了一种新的工作形态：外部审查用两个模型对抗生成报告，朋友带着另一个 AI 按报告修复，我在自己的分支上开发新功能，最后由我合并验证三方成果。人类写代码的比例越来越低，但人类的裁判权和调度权越来越重。这篇记录这套协作流程的完整实践。

背景：一次外部交叉审查

项目在 GitHub 私有仓库稳定迭代到 v2.3.0 后，我安排了一次外部审查：两个不同厂商的模型（grok 和 fable5）各自独立审查代码库，再对抗合成一份报告——两个模型互相挑对方结论的毛病，最后收敛出 12+6 条双方都认可的问题。

对抗的价值在于过滤模型幻觉：单模型审查会自信地报一些似是而非的问题（比如把有意的防御代码判成冗余），两个不同知识源的模型交叉质疑后，存活下来的问题基本都是真的。最终报告的重点五条：SPA 路径穿越、Vue 导入断链、打磨误降 draft 状态、蓝图无备份覆盖、epub 解析域外读文件——每一条都值得修。

分工：三个人类、三个 AI、三条线

审查报告出来后的分工很自然：

• 协作方（朋友）：带着他惯用的 AI 按审查报告修复，走正常的 PR 流程
• 我（本会话）：继续开发排期里的新功能——AI 痕迹检测 + 书影库文风画像
• 审查报告：作为两边的共同事实基础

这个分工的关键是改动域隔离：修复线和功能线理论上不重叠（一个改既有代码的 bug，一个加新代码），git 上各自推进互不阻塞。

重叠：合并时盯三处

理论上不重叠，实际上重了三处——这是这次实践最有价值的部分。合并前的预判清单：

1. Issue4 导入断链：我从后端修好了粘贴路径（create 顺带 save_text），朋友大概率从前端改（create 后补调 text 接口）——兼容，但 Sources.vue 可能有文本冲突
2. Issue15 saveLlm 展开顺序：我的 ai_trace_llm 开关改了同一个函数——双方改法都要保留
3. Issue10 _finalize 重构：朋友把”逐项落盘”改成”算完一次性落盘”，我的 ai_trace 挂钩在函数尾部——合并后必须确认挂钩还在新流程的末尾

实际 rebase 结果：冲突恰好 2 处，全部在预告清单里（Settings.vue 的 saveLlm、main.py 的 import 块）。合并冲突不是意外，是预告过的路口——提前列出重叠点，冲突来了就知道每一行该保留谁的什么。

我还追加了一个朋友修复引出的衍生需求：打磨改写正文后，旧的质量报告证据作废，需要重算 ai_trace——这是”修复改变了我功能的前提条件”的典型案例，只有同时理解两边改动的人才能发现。

验证清单：合并不是 git 的结束，是工程的开始

合并后我跑的验证清单（这个清单本身就是资产）：

① 安全回归:curl --path-as-is 各种穿越变体(/%2e%2e、../../..%2f)
   → 必须回退 SPA index,不能泄出 settings.json
② 修复项验证:粘贴导入正文落盘;epub 上传解析(旧代码必 ValueError)
③ 行为保护:已有蓝图再点「生成蓝图」(force=false) → 卡数内容逐字不变
④ 数据卫生:jobs.db 退出 git 跟踪
⑤ 我的功能回归:mock E2E(ai_trace 全链路/文风画像/双端 UI/smoke)
⑥ 交界确认:打磨 keep_final 改写后 ai_trace 重算逻辑(代码级验证)

第③条特别值得说：修复”蓝图无备份覆盖”时，最怕修过头变成”该重新生成时也不生成”。验证不是跑一遍新功能，是把”修好了”和”没修坏”分开证明。

发布纪律：15 个本地提交攒一个版本

这个项目后期的发布节奏演化成一套固定纪律：

• 本地提交随便打，发布版本用户拍板。功能开发期间 5-15 个 commit 在本地攒着（骨架切换、爽点度量、反伪爽文、套餐三件套……），用户说”发”才 bump 版本号构建推送
• 版本单一事实源：APP_VERSION 定义在 config.py 一处，API、界面显示、Docker 镜像标签三处自动一致——发版只改一行，不会出现”页面显示 2.4.0 镜像还是 2.3.x”的错位
• 发版前五项核验：全量语法+构建检查 / diff 密钥扫描 / 用户项目只读健康检查 / mock 一条龙 / 冒烟回归——一套 shell 下来十分钟，拦过不止一次”忘了提交文件”
• 隐私双查：推送前扫代码无真实 key、gitignore 挡住运行时数据（settings/projects/sourcelib），推完再对远端文件清单复查一遍零敏感项

这套纪律的核心理念：频繁提交保安全（丢不了代码），节制发布保质量（用户看到的每个版本都过过闸）。commit 和 release 是两个节奏，不要绑死。

人类的新角色：调度器 + 裁判 + 上下文持有者

回看这个流程，人类（我）实际干的事：

1. 调度：决定哪条线谁做、什么顺序、何时合并
2. 预判重叠：只有同时读了两边改动的人能列出”合并时盯三处”
3. 裁定冲突：saveLlm 双方改法怎么共存——理解双方意图后做技术裁决
4. 发现衍生需求：修复改变功能前提（打磨改写正文 → 报告证据作废）这种跨域影响，AI 各自都看不见
5. 验证设计：把”修好了”和”没修坏”拆开证明的验证清单

没有一行代码是我手写的，但没有一步决策能绕开我。代码生产的自动化程度高了，但工程判断的浓度反而更高了——这是 AI 时代个人开发者角色的真实演化方向：从”写代码的人”变成”对代码负全责的人”。

踩坑小结

• 对抗式审查过滤幻觉：两个异源模型互评后收敛的报告，比任何单模型的报告可信度高一个档
• 合并前先写重叠预判清单：把可能的冲突路口列出来，真冲突时每行都有预案；冲突本身不是风险，没预判的冲突才是
• 验证要拆”修好了”和”没修坏”两半：只验前者会把防御修成故障
• commit 与 release 解耦：本地勤提交、发版走闸门，两个节奏各自最优
• 跨线衍生影响只有全局视野能发现：多线并行时，”A 的修复改变了 B 的前提”这类问题需要一个通读全部改动的角色——这个角色只能是人

小结

这轮协作跑通后，项目的开发模式基本定型：我提需求和验收、AI 写代码和测试、外部 AI 做对抗审查、朋友的 AI 处理修复线——最后所有产出汇到我这儿合并、验证、发布。下一篇讲这个项目最”表面”但翻车最多的一段：前端三部曲。