第 4 章 从单次生成到可复现工作流
在校准了 AI 的能力边界之后，下一步是解决实际使用中最常见的问题：如何让输出从“偶尔可用”变成“可重复、可验证、可迭代”。
多数人的使用方式停留在单次对话——输入一段提示，获得一段结果，满意就采用，不满意就重新生成或放弃。这种方式在简单任务上有效；一旦进入需要多人协作、多步骤执行或长期维护的企业场景，稳定性会迅速下降。
本章讨论如何把单次生成升级为可复现工作流，并说明 Prompt、Skill、工作流与 Agent 在其中分别承担什么角色。
一、单次生成的局限
单次生成的核心特征是：提示词临时编写，结果即时判断，过程缺乏记录与约束。
它在个人探索、临时灵感、低风险任务上完全够用。但一旦进入企业正式场景，就会暴露出三个问题。
结果波动大，标准无法统一。 同一任务在不同时间、不同表述下，输出质量差异明显。团队成员之间难以形成一致标准，最终变成“谁生成的谁负责改”。
经验无法沉淀，组织不积累。 有效的提示方式和判断标准停留在个人脑海中，无法被同事复用，也无法在组织内积累。
错误难以追溯与隔离。 当输出出现问题，很难快速定位是提示词、输入信息、知识材料、工具调用还是模型本身的原因，修复成本高。
这些局限在个人临时任务中可以接受，在企业正式流程中会直接转化为不稳定。可以把它总结为一句话：单次生成适合“我自己用得爽”，可复现工作流才适合“组织能长期用”。
二、可复现工作流的五个基本要素
一个能够稳定产出的工作流，通常包含以下五个要素。
1. 明确的任务定义
清楚说明目标、输入要求、输出格式、质量标准与禁区。模糊的任务描述是波动的最大来源。很多团队觉得“大家心知肚明就行”，结果每个人理解都不一样。
场景例子：周会纪要提取。如果只写“帮我整理会议纪要”，输出可能天马行空。如果明确“只记录已达成的决议；每条待办必须包含负责人、具体行动、截止日期；格式固定为表格”，波动会大幅降低。
2. 结构化的提示与约束
把角色、上下文、步骤、输出格式、示例固化下来，而不是每次重新组织语言。约束越清晰，结果越可控。
关键点：不是把提示词写得越长越好，而是把“必须遵守的规则”和“禁止出现的内容”写清楚，并配上 1–2 个正确示例。
3. 固定的验证环节
对输出进行事实检查、逻辑检查、格式检查或业务规则检查。验证标准需要事先定义，并尽量可执行，最好是检查清单。
没有验证环节的工作流，本质上还是“碰运气”。很多团队把验证完全交给“感觉”，结果错误悄悄流入下游。
4. 版本与记录
对有效的提示词、工作流步骤、输入输出样本进行版本管理，便于回溯、对比与改进。
没有版本管理，就无法回答“这个提示词到底改了什么”“上次为什么突然变差了”。企业级使用必须把这个习惯养成。
5. 错误处理与回退机制
预设当输出不符合标准时的处理路径：重新生成、人工接管、降级处理或终止流程。
没有回退机制的工作流，一旦出错就会卡住或把错误放大。真正的稳定，是提前想好“出问题了怎么办”。
这五要素共同构成可复现的基础。缺少其中任何一项，稳定性都会受到影响。
从“五要素”到工作流合约
当一个流程进入跨人协作、持续维护或正式业务使用阶段，团队不应只保存提示词、检查清单和零散说明，而应将上述五要素连同业务目标、适用边界、责任、依赖、变更、发布、回退与记录要求固化为一份工作流合约（Workflow Contract）。它是面向整个流程的运行说明书：Skill 卡定义单项能力，工作流合约定义多项能力和人工节点如何协作完成一个业务用例。
工作流合约不是增加文书负担。对低风险、小范围试点，它可以是一页表；对涉及多个 Skill、外部沟通、工具调用或正式生产流程，它应成为发布、回退、移交和审计的共同依据。附录 A 第 25 节提供用例立项卡，第 26 节提供通用工作流合约；两者分别回答“为什么做、在什么边界内做”和“怎样以受控方式运行”。
这五要素缺一不可的反例：
- 只有任务定义和提示词，没有验证 → 输出看起来漂亮，但错误率居高不下。
- 有验证但没有版本管理 → 改了提示词后无法回退，团队陷入“越改越乱”。
- 有前面四项，但没有回退机制 → 遇到边界情况就彻底中断，业务受影响。
这五要素直接对应企业里最常见的三种失败模式：波动、失传、不可追溯。
三、从 Prompt 到 Skill：把个人经验封装为可运营能力
“Prompt 已经过时，Skill 才是未来”是一种容易误导企业的说法。更准确的关系是：Prompt 是任务指令组件；Skill 是对一类任务的可运营封装；工作流负责安排多个步骤；Agent 只在需要动态选择步骤、上下文和工具时才负责有限编排。 它们不是相互替代的版本关系，而是不同层级的能力单元。上下文资产贯穿所有层级：Prompt 需要当前任务信息，Skill 需要可复用的权威知识与示例，工作流需要受控的数据传递和状态，Agent 还需要在每一步按权限选择来源、工具结果和必要记忆。
| 层级 | 它解决的问题 | 核心组成 | 典型例子 | 最低控制 |
|---|---|---|---|---|
| Prompt | 这一轮模型怎样完成任务 | 角色、目标、规则、格式、少量当前任务信息与示例 | “把会议转写整理成纪要” | 模板、变量、输出格式检查 |
| Skill | 这类任务怎样稳定、可复用地完成 | 触发条件、输入输出、Prompt、上下文包、知识、工具、验证、回退、Owner、版本 | “会议纪要提取与核验” | Skill 卡、上下文包、样本、验证清单、版本、责任人 |
| 工作流 | 多个固定步骤怎样可靠协同 | 步骤顺序、状态、受控的数据/上下文传递、控制点 | 转写 → 纪要 Skill → 待办校验 → 人工发布 | 流程图、状态、日志、SOP、工作流合约 |
| Agent | 在受限范围内怎样动态选择 Skill、来源或工具 | 目标、状态、上下文来源、工具、记忆、权限、预算、审批、熔断 | 在只读系统中调查异常工单并形成建议 | 上下文/动作白名单、最小权限、人工审批、熔断、审计 |
1. Prompt：仍然必要，但不应是唯一资产
提示词负责把单个模型调用的目标、规则和输出形式表达清楚。它仍然是稳定产出的组成部分，但企业不应把一段“神奇提示词”当成完整解决方案。
正式使用的 Prompt 应作为 Skill 的一个受控组件保存，而不是散落在个人聊天记录、笔记软件或即时通信群中。Prompt 改动可能影响质量、成本和风险，因此也需要版本、样本验证和回退。Prompt 不是全部上下文：其外部资料、检索规则、工具结果和记忆同样需要在第 5 章定义来源、范围、权限与失效条件。
2. Skill：企业应重点沉淀的最小能力单元
本书所说的 Skill，不是某个平台专有的功能名称，也不是一段更长的提示词。它是针对一类重复业务任务的、可以被发现、调用、测试、版本化、授权、观测和退役的能力包。
一个可进入团队正式使用范围的 Skill，至少应说明以下内容：
- 业务目的与适用边界：它解决什么问题；什么情况不得使用。
- 触发条件与输入输出契约：何时启动；需要什么输入；输出给谁、以何种格式交付。
- 受控组件：所用 Prompt、上下文包、知识材料、工具、模型或规则。
- 质量与验证：什么是合格输出；由规则、人工或系统如何验证。
- 人工控制与回退：谁在什么节点审核；失败、超时、信息缺失或规则冲突时怎么办。
- 责任与版本：业务 Owner、知识 Owner、修改权限人、当前版本和变更记录。
- 运行指标：通过率、采用率、总耗时、失败类型、成本或其他场景特定指标。
附录 A 第 11 节提供可直接复制的 Skill 卡模板；第 25、26 节分别提供用例立项卡和工作流合约。建议先用立项卡确认业务问题与边界，再把已经跑通的提示词和检查清单整理成 1–2 个 Skill；需要多人、多步骤协作时，再用工作流合约连接这些资产，最后才讨论更复杂的自动化。
3. 工作流：让经过验证的 Skill 按固定方式协作
工作流把一个或多个 Skill 与确定性步骤连接起来。对大多数企业场景而言，最稳定的形式不是让模型自由决定全过程，而是把顺序、数据传递和人工控制点预先设计好。
例如，“客户回复交付”工作流可以是：问题分类 → 检索知识 → 客户回复草拟 Skill → 合规检查 Skill → 人工确认 → 发送。即使其中两步使用 AI，流程本身仍应保持清楚、可追踪、可回退。
4. Agent：只负责编排通过认证的能力，不替代控制
Agent 适合处理步骤无法完全预先固定、但又必须根据中间结果选择下一步的任务。它不应从零开始“自由发挥”，而应在受限状态下，调用已经定义清楚、经过验证的 Skill、上下文来源和工具。Agent 每一步可见的信息与可执行的动作都必须被约束：来源白名单、排除来源、工具权限、返回量、记忆和停止条件属于同一控制面。
因此，推荐的企业路径是：先稳定 Prompt，再封装 Skill；先连接固定工作流，再评估是否真的需要 Agent。 如果一个任务可以用确定性规则、固定工作流或人工决策完成，就不应为了“更智能”而增加 Agent 自主性。第 9 章将进一步说明 Agent 的适用条件、运行合约和治理要求。
四、单次生成、Skill、工作流与 Agent：如何选择
| 你面对的情况 | 优先选择 | 原因 |
|---|---|---|
| 一次性、低风险、个人探索任务 | 单次 Prompt | 成本最低，快速获得思路即可 |
| 高频、单类、可验证的任务 | Skill | 把经验、知识、验证和责任沉淀为可复用能力 |
| 多步骤但顺序明确的任务 | 固定工作流 | 可控性高，便于追踪和设置人工节点 |
| 步骤依赖中间结果，且具备长期治理能力 | 受限 Agent | 仅在动态编排确有额外价值时使用 |
这个选择顺序体现的是“复杂度后置”，而不是技术保守。企业真正需要的不是最高的自主性，而是在满足业务目标的前提下，以最低必要复杂度获得稳定结果。
五、从单次到可运营能力的升级路径
实际操作中，可以按以下六步逐步升级。每一步都有明确产出物，方便团队检查进度。
第一步：固化有效 Prompt
把已经验证过的提示词整理成模板，明确必填变量与可选参数。避免每次从零开始编写。
产出物：可直接复制的 Prompt 模板，含变量说明和 1–2 个正确示例。
第二步：定义任务与输出契约
明确触发条件、输入来源、输出格式、质量标准、禁止事项和人工责任。不要等系统完成后再讨论“这个结果到底能不能用”。对于个人探索或最小试点，任务定义足以起步；一旦流程需要共享、多人协作、持续维护或正式使用，就必须升级为工作流合约，并关联对应的用例立项卡。
产出物：任务定义；进入正式试点后，为用例立项卡和工作流合约。
第三步：加入验证与回退
在关键输出后设置检查点。简单任务可用规则校验，复杂任务保留人工确认；同时定义重新生成、补充信息、转人工和终止的条件。
产出物：验证清单和回退说明。
第四步：封装为 Skill
将 Prompt、上下文包、知识、工具、验证、回退、Owner 与版本记录放入同一张 Skill 卡。此时，其他同事应能在不依赖原作者口头解释的情况下使用它。
产出物：Skill 卡 v1、上下文包、成功/失败样本、责任人与修改权限。
第五步：连接为固定工作流并持续评测
把经过验证的 Skill 接入固定顺序的流程，记录通过率、采用率、总耗时和主要失败类型。任何改动都应保留版本并进行必要的回归检查。
产出物：工作流合约、工作流图、周度记录、版本记录和问题升级路径。
第六步：仅在必要时评估 Agent
只有当步骤无法固定、动态选择确实创造额外价值，并且团队具备上下文管理、评测、权限、监控、熔断、人工接管和审计能力时，才考虑让 Agent 编排多个 Skill、来源与工具。
产出物：Agent 运行合约、上下文包、记忆合约、工具/MCP 控制卡、权限矩阵、评测集、熔断与回退 Runbook。
完成以上步骤后，单次生成就转变为可被团队共享、可被重复执行、可被持续改进的工作流和能力资产。
六、常见实施误区
在升级过程中，有几类做法会削弱稳定性：
- 把 Skill 理解为“把提示词写得更长”。正确做法是同时封装边界、输入输出、知识、验证、责任、版本和回退。
- 在没有稳定 Skill 的情况下直接做 Agent。这样会把不稳定的单步能力放大为不稳定的多步系统。
- 提示词不断叠加规则，最终变得冗长且相互冲突，无人敢删改。正确做法是定期做“减法”，只保留真正有效的约束。
- 只关注生成速度，忽略验证成本，导致错误流入下游环节。验证不是额外负担，而是稳定产出的必要成本。
- 把所有步骤都交给模型自动执行，缺少关键节点的人工把关。尤其在高风险或不可逆场景，人工确认必须保留。
- 没有对 Skill 和工作流本身进行效果评估，无法判断改进是否真正有效。没有数据就没有改进，周度简单记录比不做强。
这些问题的共同特征是：把“能跑起来”等同于“能稳定产出”。真正的可复现，需要把控制点前移，并把验证变成流程的一部分。
七、本章小结
单次生成适合探索与临时任务；Skill 适合把高频、可验证任务沉淀为团队可复用能力；固定工作流适合安排多个受控步骤；Agent 只适合在动态编排确有价值且控制条件齐备时使用。
实现升级的关键不是追求更复杂的技术，而是明确任务、固化约束、设置验证、进行版本管理，并预设错误处理路径。先把 Prompt 和 Skill 做稳，再连接工作流，最后才谨慎提高自主性，才能把个人有效经验转化为团队可共享的稳定能力。
下一章将讨论支撑这些工作流、Skill 与 Agent 的运行底座——数据、知识与上下文的管理。