这是「AI 协作」系列二第 9 篇，也是这一轮的暂时收尾。前八篇从跑通一次 AI 协作，写到单个 Skill 的适配、控制和诊断；这一篇把视线移到 Skill 之间，看多个节点怎样交接、验收和回退。

读完这篇，你不需要先集齐 5 个 Skill。先拿一条最近真正跑过的三节点链路，写清两次交接要交什么、下一环什么时候能开工、出错后退回哪里，再看它能不能拒收一次不合格交接。

75 分钟交付三份材料，不等于工作流已经可靠

在第 2 篇里，我写过一次让我很有成就感的实践。

A 品牌要在双 11 前合并 80 万会员。会员中心接口不能动，积分余额合并必须可回滚。我把这个需求依次交给三个 Skill：

过去同样一套活，我大约要花 2 天，也就是 16 小时。75 分钟完成，效率差不多提升了 12 倍。

这个结果到现在依然成立。但我最近重新看这条链，发现它只证明了两件事：三个 Skill 都跑出了结果，我也拿到了三份可以继续加工的材料。

它没有证明另一件更重要的事：上一环交给下一环的信息，状态有没有一起交过去。

跑完只能证明每个节点会干活，不能证明它们之间交得对。

一次故意做坏的交接

为了复现这个问题，我在脱敏后的“会员合并”材料里，故意放入一条待确认项：

[待确认] 同一手机号同时存在两个会员账户时，等级与余额优先级待确认。

先说明边界：这不是当年项目的事故，也不是对历史过程的还原。它是一条专门用来观察“交接失真”的复现样本。

如果我只把 PRD 正文复制给下一个 Skill，没有把“待确认”作为独立状态交出去，这条信息可能会这样变化：

这里并不是某个 Skill 突然“不会做了”。时序图 Skill 仍然在补齐动作顺序，评审材料 Skill 也仍然在提炼方案。问题在于，它们收到的是一句没有状态的内容，于是只能继续加工。

这条信息的主题几乎没变，真正消失的是它的状态。

三份产出都可以写得很完整，错却是在两次交接中长出来的。

当时最让我兴奋的是效率。现在回头看，最该补的不是第 4 个 Skill，而是中间两次交接。

串联不是按顺序调用，而是让上一环交出下一环敢接的东西。

三个 Skill 单点都合格，为什么整条链还是会翻车

单独检查这三个 Skill，它们都可能合格。

PRD 有完整章节、字段表和异常场景；时序图有参与角色、正常流程和异常分支；评审材料有背景、方案和决策项。每一份产出内部都能自洽。

但如果时序图拿到的前提已经错了，它会把错误画得更清楚；评审材料拿到的结论已经越过状态，它会把这个结论整理得更像正式方案。

Skill 决定节点会不会做；交接契约决定整条链会不会把错误传下去。

第 8 篇检查的是一份失败输出应该往哪里查。到了这一篇，检查对象换了：我不再只看成品，还要看两份成品之间那条平时看不见的接缝。

我最常查三种失真：

这三种问题都不是靠“再检查一遍文案”就能解决。它们要求我在每次交接时额外确认：这是什么信息、现在是什么状态、来自哪个版本、下游能不能据此开工。

所以，下一步不是把每个 Skill 的规则再写长几百字，而是先把上一环交给下一环的东西单独拿出来设计。

别把全文塞给下一环：先做一份交接包

以前我串 Skill，最顺手的动作就是复制全文。

PRD 写完以后，整篇丢给时序图 Skill；时序图出来，再连同 PRD 一起丢给评审材料 Skill。这样做几乎不需要额外整理，也很符合一个直觉：上下文给得越多，下一环越不容易漏。

但回到 A 品牌这个需求，一份 4000 字 PRD 里，除了角色、系统、触发事件和异常规则，还有背景说明、字段细节、文案、排期，以及不同状态的开放问题。

时序图 Skill 真正需要的，只是其中一部分。全文能保证“内容都在”，却不能保证下游知道哪些必须使用、哪些只是参考、哪些还不能进入流程。

下游需要的不是更多文字，而是和自己任务相关、状态清楚、能追溯来源的交接包。

先用四个问题把包收好

我现在会在两个 Skill 之间先问四个很口语的问题：

1. 谁交给谁？ 上游是什么，下游要完成什么任务。
2. 必须交什么？ 少了哪些信息，下游就不能开工。
3. 什么状态才能继续？ 哪些未知可以带着走，哪些会改变主流程，必须先确认。
4. 错了回哪里？ 回到哪条业务规则、哪个异常节点，而不是笼统地“重做一遍”。

这四个问题合起来，就是我说的“交接包”。再正式一点，也可以叫输入输出契约。

我先把 A 品牌链路里的第一段——PRD 到时序图——重新拆了一次。它至少需要下面八项：

八个字段看起来比“复制全文”多了一步，实际是在替下一环省判断成本。

这里还有一个容易忽略的细节：交接包里的每一项，都要带上已确认、待确认、推断、不适用中的一个状态。空白不是“没有问题”，它只代表下游不知道这条信息有没有被判断过。

允许未知继续存在，并不会让工作流变得不严谨。真正不能往下传的，是没有标状态的推断、会改变主流程却尚未确认的策略，以及已经过期的版本。

包收好了，也不代表下一环就应该马上开工。它还需要先决定：这件东西，我现在到底能不能接。

下一环先验收，再开工

第 5 篇里，我写过 Skill 应该先检查用户输入，再决定继续还是停下。多 Skill 串联后，这个动作又往前走了一步：下游检查的，不再是用户随手发来的一段话，而是另一个 Skill 交来的结构化产物。

结构化不等于可信。字段都在，也可能有阻断项；版本写了，也可能和引用文档对不上。

好的下游 Skill 不是拿到内容就生成，而是先验收上一环交来的东西。

先把全文变成交接包，再让下游判断要不要收件。这两步不能拆开。

交接包解决交什么，开工闸解决什么时候能继续。

三道开工检查

我给下游保留三道检查，数量不多，但每一道都能直接拦住一种链路失真：

1. 必需项齐不齐。 角色、系统、触发事件、主流程结果和异常范围，是否满足这个下游任务的最低输入。
2. 有没有阻断项。 待确认内容是否会改变主流程、系统边界或关键结果；如果会，就不能让下游自己补一个答案。
3. 版本对不对。 交接包记录的来源版本，是否和下游实际引用的 PRD、时序图一致。

检查结束后，只允许出现三种结果：

“需补充”和“退回上游”不能混在一起。前者是还缺一块信息，后者是现有信息已经不能作为当前输入。

放回会员合并的复现样本里，“同一手机号存在两个会员账户时，等级与余额优先级待确认”会直接改变冲突合并的时序，属于阻断项。

此时时序图 Skill 应该输出“需补充”，并指出需要产品经理确认合并优先级；它不应该自己选择“高等级优先”，再继续把整张图画完。

我会把下面这段检查直接写进下游 Skill：

收到交接包后，先不要生成。

请先检查：

1. 必需字段是否齐全；
2. 是否存在会改变主流程的待确认项；
3. 来源版本是否一致。

只输出一种状态：可开工 / 需补充 / 退回上游。

不能开工时，列出缺口或冲突，并标明应该补到哪里。

表面上看，能拒收的 Skill 比“收到就出图”慢了一步。但我现在更愿意保留这一步：它把返工拦在了最便宜的位置。

等两次交接都有了包和闸门，才值得把那条 75 分钟的三节点主干重新摊开。

把 A 品牌的三节点重新串一次

回到 A 品牌会员合并，三个真实节点没有变：PRD 40 分钟，时序图 15 分钟，评审材料 20 分钟。

但我现在看这条链，注意力已经不再只放在三个节点用了多久、交了什么，而是放在中间两段：PRD 凭什么可以交给时序图，PRD 和时序图又凭什么可以一起进入评审材料。

先把事实边界说清楚：三节点与用时来自第 2 篇的真实记录；下面两张交接契约，是我现在按前文方法重新拆出来的，不倒签成“当时就是这样跑的”。

工作流的最小单位不是“一个 Skill”，而是“一个 Skill + 它与下一环的交接约定”。

现在把这条 75 分钟的三节点主干重新摊开，你会发现最值得放大的是中间两段。

三个 Skill 没有变，变的是它们之间终于有了可验收的约定。

交接 A：PRD → 时序图

这次交接的目标，不是让时序图 Skill “读懂整篇 PRD”，而是让它能回答：谁在什么事件下调用哪个系统，成功后发生什么，至少有哪些异常，哪些分支现在还不能画。

在当前复现样本里，“等级与余额优先级待确认”会改变冲突合并的动作顺序，所以这张交接单还不能放行。它应该回到 PRD 的“合并冲突规则”，补完后再重新验收。

交接 B：PRD + 时序图 → 评审材料

第二次交接换了任务。评审材料不需要把 PRD 和时序图再讲一遍，它要分清：这次会议用于同步什么、需要拍板什么、已经确认什么、还有什么风险必须暴露。

这两张契约真正省下来的，不是填写表格的时间，而是出错以后还能知道该修哪一段。

如果业务规则改了，就只更新对应 PRD 节点和受影响的时序分支；如果只是评审目标跑偏，就留住已经确认的事实与流程，只重做沟通材料。

5 个 Skill 不是排队，而是主干、分支与汇合

三节点跑通以后，很容易顺着惯性再加两个节点，画成一条五步直线：PRD、系统对接、时序图、沟通材料、SVG，一个接一个全部跑完。

这张图适合介绍“我手里有什么”，却不适合决定“这次需求应该怎么走”。因为不是每个需求都涉及跨系统，也不是每份材料都需要单独做一张信息图。

是不是工作流，不看每次是否把所有 Skill 都跑一遍，而看它们是否按任务依赖进入正确位置。

下面的五 Skill 地图是方法示意。A 品牌已公开的真实证据仍然只覆盖 PRD、时序图和评审材料三个节点；系统对接和 SVG 在图中的位置，不写成当年的项目经历。

当我把五个 Skill 都放回来，它们也不该排成一条五步直线。

工作流的节点数不是固定的，只有依赖关系必须是清楚的。

简单内部改造：走最短主干

如果需求只改系统内部规则，没有新增外部依赖，路径可以很短：

PRD 需求基线 → 时序图 → 沟通材料

PRD 先把业务规则和范围定住；时序图验证角色、事件与异常；沟通材料再汇总已定方案、待决策项和风险。系统对接 Skill 不需要为了“凑齐五个”强行进入。

跨系统改造：先补边界，再汇合

如果需求涉及多个内部系统、三方能力或接口约束，路径会多一段：

PRD 需求基线 → 系统对接 ↔ 时序图 → 沟通材料

系统对接先补谁负责什么、哪些能力已存在、哪些接口不能动，再和时序图来回校验调用关系与异常路径。两边达成一致后，才汇入沟通材料。

SVG 信息图也不是固定终点。只有当系统边界、异常链路或决策关系靠文字很难看懂时，它才从当前节点抽取必要信息，生成一张图，再回填评审材料。

同一组 Skill，在简单需求里可能只跑三节，在复杂需求里会出现分支、往返和汇合。少跑一个节点不代表不完整，跑错依赖才会让整条链白忙。

这张网现在已经会往前选路，下一步还要给它补上向后的箭头：下游发现错误时，到底应该退回哪里。

AI 系列，暂时告一段落

从第一篇到第九篇，这一轮关于 AI 协作的记录先写到这里。

这不是最终结论，只是一次阶段性整理。等有了新的实践和更值得分享的内容，再继续写。