simbajigege Skill 转 Workflow
把一个面向 Agent 的 Skill 转换为可实现的 Workflow 规格。转换的目标不是照抄原文中的编号，而是恢复它的真实执行图，并让每个节点都具有明确责任、结构化输入输出、工具权限、停止条件和失败处理。
输入与默认交付
- 输入可以是 Skill 目录、
SKILL.md、Prompt、SOP、操作手册或用户描述的 Agent 流程。 - 用户指定目标平台时，使用该平台支持的节点、变量、分支和子工作流能力；未指定时输出平台无关规格，不猜测 Dify、Coze、n8n、LangGraph 等具体实现。
- 用户只要求概括时，先给阶段数、主链路和关键回路；用户要求设计或转换时，再给完整节点规格。
- 未明确要求实现、创建文件或部署时，只交付设计，不修改原 Skill，也不创建平台配置。
需要输出完整 Workflow 规格时，读取 references/workflow-spec-template.md。
开始前
- 完整读取源 Skill 及其声明的必读 references；不要只根据
SKILL.md的表层编号拆解。 - 检查源 Skill 使用的 scripts、schema、模板、校验器和正式产物路径。只需读取会改变流程设计的资源。
- 区分三类信息：
- 业务语义与判断规则；
- 执行机制与工具操作；
- 输出格式与验收约束。
- 记录原 Skill 的授权边界、隐私边界、禁止事项和不可破坏的事实来源。
- 不执行源 Skill 的业务任务，除非用户同时要求运行或验证转换后的 Workflow。
转换流程
1. 建立源 Skill 契约
提取：
- 触发条件与不适用范围；
- 必需输入、可选输入和输入选择规则；
- 最终产物及其消费者；
- 事实来源、数据契约和质量门槛；
- 禁止行为、权限限制和人工确认点；
- 可复用历史产物与幂等要求。
这些约束必须在 Workflow 中找到承接位置，不能因拆节点而消失。
2. 恢复真实执行图
不要把原文的“七步”机械转换成七个节点。先识别：
- 批次级步骤与单对象循环；
- 串行依赖和可并行任务；
- 条件分支、回退、补充调研和重试；
- 阻断失败、允许继续的部分完成和正常空结果；
- 中间分析状态与正式交付物。
用一句主链路和必要的回路表示真实执行图，再决定节点数量。
3. 划分节点
一个节点应完成一种稳定责任，并产生可验证的状态变化。满足任一条件时优先拆开：
- 判断依据、工具权限或失败策略不同；
- 结果需要单独缓存、复用、人工检查或重试；
- 下游只依赖其中一部分输出；
- 确定性处理与模型判断混在一起；
- 一个节点同时在找事实、做业务判断、评分和写最终报告。
不要拆分纯粹的格式搬运、无法独立验收的思维碎片，或只会增加上下文传递成本的微小步骤。
4. 给节点分类
为每个节点选择主要执行类型：
- **确定性节点：**解析、清洗、计算、字段映射、文件生成、Schema 校验；优先使用代码或平台原生节点。
- **LLM 判断节点：**分类、推理、提炼、取舍和结构化写作；必须约束输入证据与输出 Schema。
- **工具节点：**搜索、网页读取、数据库查询、API 调用或文件解析；只授予本节点需要的工具。
- **人工节点：**需要业务授权、主观定案或高风险外部变更时使用。
- **路由节点：**根据显式状态或规则选择下一步，不承担额外业务分析。
能由确定性逻辑可靠完成的计算、组装和校验，不交给 LLM。
5. 抽取共享能力子工作流
当两个或以上节点重复使用同一种外部机制，并且能够形成稳定输入输出契约时，将机制抽成共享子工作流。例如：
- 搜索规划 → Web Search → URL 去重 → Web Open → 证据提取；
- 文件解析 → 格式规范化 → 字段质量检查；
- 结构化产物组装 → 构建 → 正式校验；
- 通知发送、审批或外部系统写入。
分析节点只提交“需要回答什么”，共享子工作流负责“如何调用工具并返回材料”。共享的是获取或处理机制，不是不同节点的业务结论。
共享子工作流至少定义：请求类型、问题或目标、已知上下文、工具与来源偏好、预算、停止条件、返回数据、未解决问题、限制、缓存键和错误状态。
不要在以下情况强行抽象：
- 只有工具名称相同，但输入语义、权限或失败风险完全不同；
- 共用后会让子工作流直接替业务节点作结论；
- 一次性操作没有稳定复用价值；
- 抽象会隐藏人工授权或高风险副作用。
6. 设计状态与数据契约
优先传递结构化状态，不把自然语言报告当作节点间接口。至少区分：
- 原始输入；
- 规范化输入；
- 来源或证据账本；
- 中间判断与置信度；
- 限制和未解决问题；
- 正式产物；
- 运行状态与错误。
推荐基础状态为 complete | partial | failed，但应按业务语义补充 skipped、needs_human 或其他状态。正常空结果不能误判为失败。
每个节点的输出只能包含下游需要的数据。Workflow 内部字段在生成正式产物前必须过滤，不得污染原 Skill 的正式 Schema。
7. 设计提示词
采用“共享约束 + 节点任务”的提示词结构：
- 共享 System Prompt 保存事实边界、来源规则、禁止事项、表达与结构化输出要求；
- 节点 Prompt 只说明本节点目标、输入变量、判断顺序、输出字段和停止条件；
- 工具调用策略放在工具节点或共享子工作流，不让每个业务节点重复维护；
- 输出使用 JSON Schema 或平台结构化输出，不依赖模型自觉遵守自然语言格式。
提示词必须说明：哪些是事实、哪些允许有限推断、证据不足如何处理、不得新增什么、何时停止。评分节点只能消费已建立的证据，不应重新搜索并引入新事实。
8. 设计分支、循环与失败处理
每个回路都定义：
- 触发条件；
- 回到哪个节点；
- 允许补充或修改哪些字段；
- 最大次数、时间或成本预算；
- 停止后是
partial、failed还是转人工。
区分：
- 技术失败：超时、解析失败、API 错误；
- 数据失败：缺必需字段、Schema 不合法；
- 证据不足：允许部分完成或转人工；
- 业务冲突：保留冲突并按规则降置信度；
- 高风险操作：执行前请求授权，不用自动重试绕过审批。
9. 把生成与验收确定性化
如果源 Skill 已有构建器、校验器或唯一事实源，Workflow 必须继续使用。推荐结构：
中间分析状态
→ 标准事实源组装
→ Schema 校验
→ 确定性生成交付物
→ 正式校验器
校验失败时优先修正标准事实源并重新生成，不让 LLM 直接分别修改多个派生产物。无法依据现有证据修复时，路由回真正缺失信息的上游节点。
10. 交付并做覆盖检查
完整规格至少说明：
- 主链路、节点数量和节点图；
- 每个节点的目标、类型、输入、输出、工具、提示词和验收；
- 共享子工作流及请求/响应契约；
- 状态、缓存、来源、分支、回路和重试；
- 正式产物、构建方式和端到端完成条件；
- 从源 Skill 到 Workflow 节点的规则覆盖表。
最后逐条核对源 Skill 的必需步骤、核心边界和完成检查，确保没有规则只存在于原文、却在 Workflow 中无人承接。
关键设计原则
- 节点数由稳定责任和状态边界决定，不由源文档的标题数量决定。
- 共享工具机制可以抽象，业务判断不能因工具复用而被混合。
- 搜索、读取和证据提取负责提供材料；分析节点负责形成领域结论。
- 先建立事实和任务，再评分或决策；不要让模型边搜索边凭印象评分。
- 中间状态可以丰富，正式数据契约必须保持干净和兼容。
- 可观测性不是额外报告：节点状态、来源、限制、重试原因和产物路径应成为运行状态的一部分。
- 没有用户授权时，设计 Workflow 不等于执行、部署或触发外部副作用。