一 人 工 坊 · E
E · 协同差：一个人 + n 个 AI 该怎么分工
高频用上两个以上的 AI 之后，瓶颈不再是"哪个更强"，而是它们之间怎么交接。本篇把这两天跑通的两条链路拆开，抽象出三条硬机制和一个分工矩阵，并给出我们对"再一次提速"的建议——含一条明确的异议。
2026-10-10 · 创业陪跑Lab · 特稿 023
素材来自 2026-10-08 ~ 10-10 现场
阅读约 10 分钟
关键词：协同差 / 文件即接口 / 单一数据源 / 边界清单
本 篇 提 要
多工具时代真正的损耗不在工具本身，而在
交接：重新讲一遍背景、口径在两个端之间漂移、凭证散落在各处、两个会话同时改同一个文件。解法不是换更强的工具，而是三条硬机制——
文件即接口、
单一数据源、
边界清单。本篇给出分工矩阵、五个已踩过的坑，以及"若只能保三件事"的答案。
01现场：两条链路，同一天跑通
先看两条真实链路，它们把这个问题说得比任何框架清楚。
链路一 · 内容回流闭环（两天内完成）
- AI 侧改六份结构化的内容分块；
- 合并成一份明文包，并把文件本体发到人手上（这一步曾漏过）；
- 人在自己的设备上解锁、导入、导出加密包；
- 包回到 AI 侧，做五项交叉校验（结构、盐值、时间戳、明文字节比对、备份）；
- 校验通过才部署，再走两个域名分别验证；
- 最后用真实浏览器解锁一次，确认人看到的就是新内容。
这条链路的关键不在加密，在第五步的"先判再部署"。此前有一次踩坑：文件变了、时期戳没变、内容一字未改——因为按错了一个按钮（导出而非导入）。从那以后，这一环的判据被写死：数据指纹相同 + 长度相同 + 时间戳未变 = 判定失败。
链路二 · 三张表同源
- 排期只存在一个文件里，是唯一数据源；
- 改一处，跑一个脚本，同步出三张表：线上全貌表、打印版记录表、可打勾的电子表；
- 人在手机上照着发表，靠封面上的编号认顺序，不靠列表顺序（列表会随时间变化）。
两条链路共同的骨架是：状态存在文件里，交接靠校验，判断留给人。
02分工矩阵：按"确定性"而不是按"能力"分
常见的分法是按工具擅长什么——写文案的、写代码的、画图的。这个分法在多工具时会失效，因为擅长会重叠。更稳的分法是看任务的确定性：
| 任务类型 | 特征 | 交给谁 | 交接物 |
|---|
高确定性
批量 | 有明确验收标准，可复算 | 擅长代码的那一端（如 Codex），可并行多个 | 改动 + 自检结果 |
高上下文
需判断 | 要知道前因后果、口径、历史约定 | 带长期记忆的那一端（如 WorkBuddy） | 方案 + 待你裁决的选项 |
| 对外承诺 | 发出去就收不回 | 只能人 | 你的签字 |
第一条 · 确定性高的活，交给能并行的那一端
批量改名、跨文件替换、跑测试、批量生成图片、按模板批量出稿——这类活的标准是可复算：跑两遍结果一样。它们的正确分工是丢给擅长代码执行的那一端，一次开多个，你在最后验收。
第二条 · 需要上下文的活，交给记得住前情的那一端
"这个数据口径上次定过""这篇 GEZ 引用过不能改""封面编号不许漂移"——这类约束不在任务里，在历史里。丢给没有记忆的那一端，它一定会重蹈覆辙。
第三条 · 对外承诺永远不外包
发表、发出授权函、对读者承诺时间——这类动作不可逆。我们的规矩是：AI 可以推到草稿箱，但最后一个按钮由人按。这不只是谨慎，是责任可以追溯。
03三条硬机制
机制一 · 文件即接口
- 两个 AI 之间不要靠聊天记录传状态，要靠文件：一份排期、一份台账、一份约定；
- 每个任务开工前先读这些文件，收工后把结论写回文件；
- 好处是可验证、可回滚、可换工具——明天换任何一端，另一端不受影响。
机制二 · 单一数据源
- 同一件事只允许有一处真相：排期只有一份，{/，}不是一张公认表加三个副本；
- 其余全是生成物——跑脚本同步，永不手工改；
- 这一条最反人性，因为改副本当下更快。它的代价会在第三次修改时连本带利讨回来。
机制三 · 边界清单（明确"不做什么"）
- 每条边界都要能一句说完，例如"不代笔本人经历""不许凭工具的内存回答历史问题""会-timeout 的数字必须先算不许估"；
- 边界要写成可检查的动作，而不是写成口号；
- 每出一次事故，就往清单里加一条，并把这条写进能复用的地方。
分工不是把活切开，是把责任切开：机器对可复算的部分负责，人对不可逆的部分负责，中间那一段靠文件交接。
—— 行动笔记
04五个坑（都已踩过，不是想象）
坑 1上下文腐烂：越长的会话越容易丢细节，最后一次提到的口径会覆盖最初的约定。解法是把约定落进文件，每段会话开头读一遍。
坑 2并行写冲突：两端同时改同一文件，后写的覆盖先写的。解法是同一时间只有一个端持有写权限，其余产出到新文件。
坑 3假成功：命令返回成功但实际没变（删除、上传、导入都遇到过）。解法是"做完必复查"——不看返回值，看结果本身。
坑 4数字漂移：同一件事在不同地方写法不同（大小写道 article_state:"published" vs "not_published"、数词、日期格式）。解法是数字口征单一来源，别处引用不算数。
坑 5凭证扩散：钥匙复制越多，泄漏面越大。解法是凭证集中放置、能轮换就轮换，且不在对话里反复粘贴。
05关于"再一次提速"，我们的三条建议
建 议 一 · 先立"一个记忆源 + 多个执行端"，别再增加执行端
眼下最容易的提速动作是再开一个更强的工具，但它会把"重新想起"的成本重新加上去。真正的提速是让所有端共享同一份记忆：同一份项目约定、同一份排期、同一份边界清单。
具体做法：一个文件写清"这个项目是什么、口径是什么、哪些不许做"；每一端开工前先读它。
建 议 二 · 确定性高的活并行，有上下文的活串行
批量、可复算、互不依赖的任务，同时开多个（写稿、出图、改文件名、跑校验）；涉及口径与承诺的活，一次只做一件，由人确认。
很多人把顺序搞反：重要的事并行推进，琐碎的事反而一件件盯——那会同时失去质量与效率。
建 议 三 · 给注意力设预算，而不是给时间设预算
一天真正能高质量拍板的次数是有限的。把它当成配额：今天只下达 N 个判断，其余全部由旁路处理（自动校验、模板生成、批量复核）。
我们已经在用的形式是"若只能保三件事"——先承认做不完，再决定保哪三件。它看似在限制，实际是唯一能保住质量的方法。
如果只能保三件事（我们的答案）
- 单一数据源——没有它，多端协同必然漂移；
- 先判后部署——每一不可逆动作之前，都有一道可验证的判据；
- 边界清单写在文件里——让下一次换工具、换会话、换助手时，规矩还在。
06一条明确的异议
近期常见的一种说法是"用某几个工具搭一套个人工作平台"，听起来像只要工具配齐，系统就自然成立。我们不同意这个次序。
从过去一年的现场看，顺序恰好相反：先有了要沉淀的东西（台账、承诺、口径、复核判据），工具才变得有用。顺序反过来时，会发生一件很典型的事——平台搭得很漂亮，两周后就没人往里放真东西了，因为没有什么值得放。
这一点对我们尤其要紧，因为我们已经有过一次教训：活教材申请在校内第一轮 PK 中落选，之后才转向把这些东西建设为独立的数字资产。结构不是先画的图纸，是被人一次次教出来的形状。
所以如果要给"再一次提速"一个可执行的起点，我们的建议不是先搭平台，而是先做一件小事：挑一件你最怕忘记的事，把它从脑子里搬到一个文件里，并规定以后只改那个文件。剩下的事会自己长出来。
写 在 最 后
A 说看不见，B 说交错了，C 说结构要一天天攒，D 说注意力是被归还的，这一篇说的是它们的咬合方式：一个人加多个 AI，拼的不是工具好不好，是交接清不清。
交接清了，加一个端就多一份能力；交接不清，加一个端就多一处缝隙。