第 6 章 场景落地：最小闭环设计

前面章节解决了认知边界、工作流设计和数据基础问题。从本章开始，进入真正可执行的落地环节。 目标只有一个：选择一个边界清楚的小场景，在一个足以获得代表性证据的短周期内跑通可重复、可验证的最小闭环，并产生可观察的结果。

本章的“最小”指范围最小，而不是跳过业务目标、责任、风险和回退。任何准备进入团队试点的场景，都应先填写附录 A 第 25 节的用例立项卡；当流程开始跨人协作、持续维护或进入正式使用时，再补齐附录 A 第 26 节的工作流合约。这样，后续的 Skill、评测、知识变更、发布和组合决策才能关联到同一个业务用例。

一、选择最小闭环场景的标准

先用以下标准快速筛选场景，避免一开始就做大而全的项目。 必须同时满足的条件：

1. 任务以足够频率重复出现，能够积累同口径样本
2. 输入信息相对完整、可获取，且数据边界能够确认
3. 输出有明确的业务质量标准，能够由规则或人工验证
4. 当前人工流程存在可观察的整理、核验、等待或返工负担
5. 失败成本可控，能够人工纠正、停止或回退，不会产生不可接受后果

优先推荐的起步场景：

• 会议纪要整理+待办提取
• 客户/内部邮件的标准回复起草
• 周报/日报初稿生成
• 简单数据的结构化汇总与异常标记
• 产品/政策问答的标准答案生成（基于已有文档）

暂缓的场景：

• 需要跨多个系统实时写回的操作
• 涉及最终决策或对外正式承诺的内容
• 输入信息严重缺失或高度依赖个人经验判断的任务

二、最小闭环的完整操作步骤

按以下 7 步执行。第一轮的周期和样本量应由任务频率、错误后果、审核能力和风险边界确定；关键在于获得足以支持下一次阶段决策的证据，而不是追求固定天数。

前置动作：填写用例立项卡（30–45 分钟）

在写提示词或搭建工具前，先使用附录 A 第 25 节确认：你要解决的业务问题是什么、当前基线在哪里、谁是业务 Owner、哪些结果不可接受、人工保留哪些判断、试点结束后要依据什么证据继续或停止。立项卡不能替代后续设计，但能防止团队“先做技术，再寻找价值”。

若用例涉及对外沟通、敏感数据、关键决策、写入操作或不可逆后果，应在进入测试前同步完成第 15 章的数据分级和附录 A 第 34 节的风险初筛；按 R2/R3 处理或发生重大变化的用例，还应完成附录 A 第 35 节的 AI 影响评估。无法明确边界、Owner、人工回退或控制要求时，缩小场景或暂缓试点。

步骤 1：明确任务定义和工作流边界（30 分钟）

用下面的模板写清楚： 任务名称： 触发条件： （什么情况下启动这个任务） 输入： （需要哪些信息，从哪里获取） 输出： （最终要交付什么，格式要求） 质量标准： （怎样算合格） 当前人工耗时： （平均每次多少分钟） 目标： （希望降到多少分钟，或提升什么指标） 示例：

• 任务名称：周会会议纪要与待办提取
• 触发条件：周会结束后
• 输入：会议录音转写文本或完整聊天记录
• 输出：结构化纪要+待办列表（负责人、截止日期）
• 质量标准：关键决议无遗漏、待办可执行、格式统一
• 当前人工耗时：35–50 分钟
• 目标：控制在 12 分钟以内（含人工检查）

任务定义应与立项卡保持一致：范围、禁止事项、目标用户和人工控制点不得在两份资产中相互矛盾。进入多人试点前，将该定义扩展到附录 A 第 26 节的工作流合约，明确步骤、执行者、验证和异常处理。

步骤 2：准备最小上下文包与代表性样本

不要先收集“尽可能多”的资料。先为当前任务建立最小上下文包：它应说明本次任务的目标、允许使用的来源、排除内容、知识版本、数据边界、人工责任和停止条件。上下文包模板见附录 A 的相关资产；第 5 章说明了为何资料正确仍不等于上下文正确。

最小资产	要求	现场检查问题
任务事实	当前对象、范围、输入字段、输出要求和不可接受后果	这是否足以支持当前任务，而不是泛泛背景？
权威知识	已批准的规则、版本、生效日期、适用范围和来源	它是否仍有效，是否适用于当前对象/地区/产品？
示例与反例	少量正常、边界和历史失败样本	是否同时说明“应如何做”与“绝不能怎样做”？
排除与权限	不应读取、保存、外发或作为依据的内容	是否存在敏感、过期、无 Owner 或超出目的的资料？
回退与 Owner	信息不足、冲突、过期或异常时的人工路径	谁确认来源，谁审核输出，谁有权停止？

若需要检索或工具调用，第一轮应只允许少量、职责清楚且可追溯的来源或工具；空结果、冲突结果、权限拒绝或超时必须转人工或停止，而不是让模型猜测。

步骤 3：固化提示词模板

使用固定结构，不要每次重新写。推荐模板如下：

角色：你是[具体角色]，负责[具体任务]。

任务目标：
[用一句话说明要完成什么，以及不得替代的人工判断]

输入信息：
[在这里粘贴或描述经批准的输入；标注知识版本、来源或适用范围]

必须遵守的规则：
- [规则 1]
- [规则 2]
- [规则 3]

信息不足、来源冲突、超出范围或不确定时：
[说明应询问、标记待确认、转人工或停止]

输出格式：
[明确结构，优先使用可审核的 Markdown 或 JSON]

参考示例：
[放入少量正常或边界示例]

把这个模板保存为文件，后续只替换“输入信息”部分。

步骤 4：设置验证检查清单

每次输出后，必须按清单检查，不要凭感觉判断。 示例检查清单（会议纪要场景）：

• [ ] 所有明确决议都已记录
• [ ] 待办包含负责人
• [ ] 待办包含可执行的行动描述
• [ ] 没有把讨论中的建议误写成决议
• [ ] 格式与模板一致
• [ ] 无明显事实错误

只有全部勾选通过，才进入使用环节。任何一项不通过，就返回修改或人工重做。

步骤 5：执行第一轮受控测试

使用少量具有代表性的真实或经批准的去标识化任务测试，至少覆盖正常、边界、信息不足或历史失败等情形。记录以下数据：

次数	生成耗时	人工检查耗时	是否通过验证	主要问题	最终是否采用
1	2	...

步骤 6：根据测试结果快速迭代

重点检查并优先修复以下问题：

1. 任务定义、禁止事项或人工责任不清晰
2. 上下文包中的来源、版本、适用范围、权限或排除条件缺失
3. Prompt、检查清单或工具/检索返回无法支持审核
4. 输入信息不足、冲突、过期或无 Owner

每次变更应记录原因、受影响资产和需要回归的样本。低风险改动可以小范围复测；涉及规则、数据范围、工具、权限或对外行为的变更，应按第 5 章和附录 A 的影响分析、回归和发布资产处理。

步骤 7：固化并小范围共享

当试点样本已覆盖预定场景，质量、人工审核负担、风险控制和回退表现均达到用例立项卡中约定的阶段条件后，做以下固化：

1. 把最终提示词模板、检查清单、示例保存到共享位置。
2. 写一份不超过 1 页的使用说明（什么时候用、怎么用、出问题怎么办）。
3. 为该能力建立或更新 Skill 卡；如存在多个步骤或多人交接，同步填写工作流合约。
4. 将用例编号写入 Skill 卡、工作流合约、周度评测和后续变更记录。
5. 让至少一名非设计者按同一资产独立完成受控运行、审核和异常处理，记录其反馈与接棒证据。
6. 回到用例立项卡，基于质量、采用、效率、风险和维护负担决定进入限量试运行、继续迭代、缩小范围或停止。

三、常见失败点与应对方法

失败现象	可能原因	立即处理方式
输出经常漏关键信息	提示词未明确“必须包含”的字段	在规则中逐条列出必含内容
格式每次都不一样	输出格式约束不够严格	改用 JSON 或固定 Markdown 标题
检查通过但业务上不可用	质量标准定义太宽松	补充业务侧的具体判断条件
越用越不稳定	提示词不断追加规则导致冲突	回退到上一版可用模板，重新精简
同事用不起来	使用说明不清楚或步骤太碎	简化成“复制模板→粘贴输入→检查清单”三步

四、最小闭环成功的判断标准

同时满足以下条件，即可视为第一阶段成功：

1. 试点样本覆盖了用例立项卡定义的正常、边界和高风险或历史失败情形
2. 输出质量、人工审核负担、处理时效和采用情况已按预定义口径记录
3. 关键错误、信息不足、来源冲突、权限异常和工具故障能被识别、停止、转人工或回退
4. 至少一名非设计者能依据同一上下文包、Skill 卡和工作流合约独立完成受控运行
5. 用例立项卡中定义的价值、风险、维护与停止假设已有相称证据，并已记录下一次阶段决策

达到标准后，再考虑扩大场景或增加自动化程度。未达到标准，继续在当前场景迭代，不要急于铺开。

五、本章行动清单

请立即执行：

1. 用「选择标准」选出 1 个最小场景，并填写附录 A 第 25 节的用例立项卡。
2. 填写任务定义，明确范围、输入、输出、禁止事项和人工控制点。
3. 建立最小上下文包，选择具有代表性的正常、边界和失败样本；如场景存在明显风险，先完成第 15 章的数据分级和相关审查。
4. 写出第一版提示词模板、来源展示方式和检查清单。
5. 用受控任务测试并记录输入范围、知识/工具版本、审核结果、异常和回退。
6. 达到小范围共享条件后，建立 Skill 卡；涉及多步骤或多人协作时，补齐工作流合约。

完成本章行动后，你就拥有了一个可运行、可追溯并可进入下一次阶段决策的最小闭环。这是后续扩大范围和提升稳定性的基础。