多 AI 协作必须设计交接机制而非仅靠上下文

ChatGPT、Claude、Codex 并用，能做的事确实变多了。

但有时候加了 AI 之后，人类的工作量并没有减少。

原因之一不在于模型能力，而在于工作的传递。

在 ChatGPT 上查到的内容，要重新讲给 Claude。Claude 敲定的规格，要交给 Codex。Codex 实现完代码之后，还要再确认一遍「到底做到什么程度了」。

每个 AI 单独看都很快，但如果每次交接都还得靠人，流程就会在那里卡住。

持续性存在，但状态不会自动迁移到另一个 AI

现在的 AI 工具已经有支撑持续作业的机制。

ChatGPT 的 Projects 可以把项目内的对话、文件、指令等汇总起来，作为持续作业的上下文使用。

Claude Code 也有 CLAUDE.md 等项目记忆，以及 continue / resume 对话的功能。

但 ChatGPT 的状态不会原封不动地传给 Claude，Claude 的状态也不会原封不动地传给 Codex，实现结果更不会自动以相同含义传递给外部服务。

跨负责人、跨会话、跨执行环境时，需要把状态降级为可共享的形式。

交接时常见的做法是把历史对话拉得很长来摘要。

但下一任负责人真正需要的并不是全部历史。

「写了文章」是 DONE。「在 note 上确认了公开 URL」是 VERIFIED。

「写了代码」是 DONE。「在 Production 上确认了运行正常」是 VERIFIED。

「开了 Checkout」是 DONE，但并不是 Purchase。

不区分这个，AI 的自我报告就会直接流转到下一道工序，途中状态容易被当成完成状态。

Handoff 之外还要有 Acceptance

因为交出方也有可能出错。

WORK → HANDOFF → ACCEPTANCE → WORK

接收方在读完交接内容后，不要马上开始新工作，而是要确认重要文件、URL、测试结果等。

ACCEPTED WITH CORRECTIONS

加上这一层之后，就不容易仅因为「之前的 AI 这么说了」而接受状态。

GitHub 不是对话存放处，而是实现证据的交接点

不需要把和 AI 的全部对话都存到 GitHub。

Revenue 本身由 Stripe 等 Commerce 侧担当 Source of Truth。

回流给 GitHub 的，是「改了什么、产生了什么市场反应」这种可学习的差分。

市场
↓
GitHub / 实现
↓
外部行为
↓
Buyer
↓
Revenue
↓
Evidence
↓
GitHubへ学习可差的分
↓
下次外部行动
↺

AI 多了之后会怎样

AI 活用中，很容易想加入新模型、新 Agent、新自动化工具。

但如果现有 AI 之间的工作没有正确交接，增加人数只会让交通整理变得更复杂。

先把这套设计做好，再按需添加必要的 AI，会更容易驾驭。

关联资源

现有 Vector 有料 note 中已经把本文思路落到实践的例子：

Codex → ChatGPT / MARKET 例

状态不一致的 Correction Rule

已有文章：https://note.com/deft_eel6718/n/ncaff8351e529

模板不需要的话，只用这篇 Ghost 文章的思路也足够起步。

OpenAI Projects：https://help.openai.com/en/articles/10169521-projects-in-chatgpt

Claude Code memory：https://docs.anthropic.com/zh-CN/docs/claude-code/memory

Claude Code CLI：https://docs.anthropic.com/en/docs/claude-code/cli-usage

Claude Code handoff request：https://github.com/anthropics/claude-code/issues/11455 https://github.com/anthropics/claude-code/issues/59492