更换编程 AI，如何保住项目决策

项目做到第三周，换个 AI，代码能带走，决策却可能丢掉：某个方案为什么被否决、客户提过什么限制、新模型都不知道。原文给出的解法，是把迁移拆成提取决策、按工作流交接、接收端核验和缺口审计，而不是复制聊天记录。

这套流程依赖 Zambo 保存的项目记录，也带有明确的产品推广目的。对程序员更有用的，是它划出了一条边界：资料已经交过去，不等于新 AI 已经理解，更不等于交接已经完成。

换 AI 时，最容易丢的是决策理由

聊天记录适合还原对话经过，却不适合直接充当项目决策表。几千行讨论里，有试探、有废案，也有最终结论。新 AI 即使读到了，也未必分得清哪些可以重新讨论，哪些已经受到客户约束。

作者要求把每条决策单独提取为一条记忆事实，遵守 500 字符限制，包含决定、理由、日期，以及排除了什么方案。示例项目持续三周，有八条关键决策，就保存为八条事实，而非压成一段摘要。这样做的价值，是让否决理由也能被找回。

不过，保存事实只是第一步。原文强调，记忆按调用方隔离，不会自动跨 AI 迁移。因此，这八条事实还必须原样写进交接正文；只留在发送端的记忆里，新 AI 依然拿不到。

这里的关键前提是：项目至少近期通过 Zambo 工作，记录已经存在于带凭据的线程中。更早的工作只能补录为事实，审计时还要承认这部分记录不完整。它不是对任意聊天历史都能直接套用的迁移方案。

交接需要五步，最后两步才决定能否继续工作

第一步是捕获项目状态。在持有记录的发送端，用 continuity_list_threads 列出线程，用 continuity_open_thread 打开承载当前状态的两个线程，再用 continuity_get_recent 读取活跃线程中带凭据的工作，并通过 handover_list 查看已有交接。

第二步提取决策。第三步按工作流打包。示例把 data、build、docs 分成三份交接，每份包含摘要、目标、后续步骤、步骤凭据，以及该工作流的决策事实。比起一个巨型上下文包，三份独立交接更容易逐项检查。

第四步由接收端核验。新 AI 免费领取交接后，先通过 pdf_extract 打开六份随交接携带的凭据，读取对应 run link 的记录，确认收到的内容与发送端保存的内容一致。

第五步审计缺口。通过三次 zambo_universal 路由检查，追问旧 AI 能回答的三个问题：否决过什么方案、客户有什么限制、还存在哪个未解决风险。新 AI 无法从交接正文回答的部分，就记为缺口，在接收端汇总成一条记忆事实，再交回发送端补提取。

发现缺口并交回，不等于缺口已经修复。

原文反复强调，补救仍要等发送端领取回传交接。接收端记录的是「待补」，不能提前写成「完成」。这条约束很实用：很多交接失败，恰恰发生在发现问题之后，大家却误以为问题已经处理。

为什么第 20 次调用还不能算迁移完成

作者给这次示例迁移计算了 33 次计费调用，接收端领取交接免费。前六个阶段共花 20 次，完成捕获、决策提取、工作流打包与发送；第 21 次调用才开始接收端核验。

所以，免费额度用完时，项目处在一个尴尬位置：已经发出，但尚未检查。

免费方案是第一天完成第 1 至 20 次调用，通过免费的每日收尾保存迁移状态，然后停止项目工作；第二天再做六次凭据检查、三次缺口提问，以及回传和收尾等剩余操作。后半程合计 13 次调用，也不包含缺口的实际修复。

恢复时使用原文指令 Continue my Zambo session，并提供收尾返回的领取信息。领取本身不占第二天的 20 次免费调用。文案同时写有 STEP 20 OF ~33，而预算段给出的是 33 次；这仍是特定示例的预算，不能视为所有项目的固定成本。

付费选项则是 Day Pass：一次支付 $0.99，24 小时内不限调用。另有 $29 的 30 天 Pass、$290 年度价格，以及 $ZAMBO 持有者 $19 的价格。作者称这些都是单次支付，不自动续费。它们解决的是额度等待问题，不能替代核验流程。

接入层面，所有入口共用 MCP 端点 https://zambo.dev/mcp。原文列出 Claude、Cursor、ChatGPT、Windsurf 和 VS Code，并要求切换两端都配置端点，再把随文工作流文件交给代理。框架入口如下：

入口	安装命令	原文版本
CrewAI	pip install crewai-zambo	v0.1.9
LangChain	pip install langchain-zambo	v0.1.10
OpenAI Agents	pip install aer1-openai-agents	v0.1.20
AutoGen	pip install aer1-autogen	v0.1.16
Agno	pip install agno-aer1	v0.1.2
LlamaIndex	pip install aer1-llamaindex	v0.1.15
npm / Node	npm install aer-1	v0.1.27

这些入口使用同一记录格式 AER-1。原文称其为开放的 IETF 草案 draft-zambo-aer1-26，不能把「草案」理解为已经定稿的标准。

我的判断

我认同它把「传输完成」和「交接验收」分开。新 AI 能复述摘要，只能说明它读到了一些内容；能解释否决方案和客户限制，才更接近具备继续工作的上下文。

但原文没有给出真实迁移的逐项结果，也没有提供与聊天复制、仓库文档或其他交接方式的对照数据。八条决策、六份凭据、33 次调用，是示例流程的配置与预算，不能当成已经证明「一个决策都没丢」的实验结果。标题的承诺比正文证据更强。

凭据的证明范围也要收窄。按作者的描述，它证明保存后的记录没有变化，不证明最初提取正确，更不证明决策合理。漏掉的限制不会因为有凭据就自动出现；三道审计题也无法覆盖全部遗漏。所给原文没有展开凭据的技术校验机制，读者无法据此判断其完整性保证有多强。

对普通前端或 Node 团队，仓库里的决策文档、任务记录和交接说明也是替代方案：工具依赖更少，但需要团队自己维护来源、状态和验收步骤。Zambo 把这些操作收进共同端点，代价是迁移流程依赖其记录体系，33 次预算又以项目已经使用该体系为前提。

最后，作者自述是 Zambo 的 AI 运营负责人，价格与购买引导属于产品方叙述。可以借鉴流程，但不能把它当作独立评测。

能拿来做什么

• 切换 AI 编程工具前，把关键决策逐条写入仓库文档，每条保留理由、日期和被否决的方案，并检查它们是否真正进入新 AI 的交接内容。
• 项目同时涉及数据、构建和文档时，分别写清当前状态、下一步和相关决策，让新 AI 可以按工作流核对，减少大摘要中的遗漏。
• 新 AI 接手后，先让它回答否决方案、客户限制和未解决风险，并指出答案来自哪份记录；回答不出来就补交接，再继续开发。
• 如果准备采用 Zambo，先确认现有记录能被捕获，再按实际工作流估算调用量。免费路径要预留次日核验时间，缺口修复则单独跟踪到发送端处理完成。