8.3
深览指数
产品人人都是产品经理·Zoe产品手记··AI 生成
把 5 个 Skill 串成需求流水线，关键不是调用顺序
本文提出多AI Skill串联的痛点不在于单个节点能力，而在于节点间的“交接契约”。作者以一次75分钟完成三节点（PRD→时序图→评审材料）的实践为例，指出即使每个节点产出合格，整条链仍可能因信息状态失真而翻车。核心贡献是定义了“交接包”与“开工闸”两个机制：交接包明确上游交什么、什么状态、版本号；开工闸让下游先验收再开工，可输出“可开工/需补充/退回上游”。作者强调工作流的最小单位是“Skill + 交接约定”，而非单点调用，并给出了5个Skill的非线性地图（主干、分支与汇合）。适合已实践过AI协作、正在搭建多步骤工作流的从业者阅读。原文 ↗
核心观点
- ▍串联多个AI Skill的关键不是调用顺序，而是让上一环交出下一环敢接的东西——即建立“交接包”与“开工闸”机制，把信息状态（已确认/待确认/推断/不适用）和验收条件显式化。
- ▍工作流的最小单位不是“一个Skill”，而是“一个Skill + 它与下一环的交接约定”。节点间的接缝是错误传播的主要通道，而非节点本身。
- 01作者以“A品牌80万会员合并”需求为例，75分钟完成三节点（PRD 40分钟、时序图 15分钟、评审材料 20分钟），效率提升约12倍，但后来发现链路未验证“上一环交给下一环的信息状态是否一起交过去”。
- 02作者在脱敏后的PRD中故意放入一条待确认项“同一手机号同时存在两个会员账户时，等级与余额优先级待确认”，用于观察交接失真。在无显式状态传递的情况下，时序图Skill和评审材料Skill会分别加工该信息，导致“待确认”状态消失，错误被当成正确流程继续画下去。
- 03作者定义了三种最常见的交接失真：信息状态丢失（已确认→待确认→推断）；信息与任务不匹配（下游需要角色/事件/异常，但收到全文）；版本不一致（下游引用的是旧版PRD）。
- 04作者提出“交接包”的四个前置问题：谁交给谁？必须交什么？什么状态才能继续？错了回哪里？并将PRD→时序图段的交接包拆解为8个字段：角色、系统、触发事件、主流程结果、异常范围、待确认项、来源版本、输出状态（含状态标注）。
- 05“开工闸”三道检查：必需项是否齐全；是否存在会改变主流程的待确认项（阻断项）；来源版本是否一致。只允许输出三种状态：可开工、需补充、退回上游。
- 065个Skill（PRD、系统对接、时序图、沟通材料、SVG）不应排成一条直线，而应按任务依赖形成主干、分支与汇合。简单内部改造只需PRD→时序图→沟通材料；跨系统改造需加入系统对接Skill并与时序图来回校验，SVG仅在信息关系复杂时插入。
反方 / 局限
- — 作者承认，当前“交接包”和“开工闸”仍处于个人实践框架，未经过大规模团队或跨企业验证，在复杂依赖（如多团队并行、异步交付）中的适用性尚未讨论。
- — 文章未讨论“待确认”项在跨角色协作中如何被有效确认和状态更新——这需要项目管理工具或协作者介入，而非仅靠Skill自身机制解决。
12 分钟 · 4 卡片 · 9 资料
读原文 →