第 6 章 场景落地：最小闭环设计
前面章节解决了认知边界、工作流设计和数据基础问题。从本章开始，进入真正可执行的落地环节。 目标只有一个：选择一个边界清楚的小场景，在一个足以获得代表性证据的短周期内跑通可重复、可验证的最小闭环，并产生可观察的结果。
本章的“最小”指范围最小，而不是跳过业务目标、责任、风险和回退。任何准备进入团队试点的场景，都应先填写附录 A 第 25 节的用例立项卡；当流程开始跨人协作、持续维护或进入正式使用时，再补齐附录 A 第 26 节的工作流合约。这样，后续的 Skill、评测、知识变更、发布和组合决策才能关联到同一个业务用例。
本章职责：把一个已选定的候选用例变成可验证、可回退的最小闭环，并产生“限量运行、继续迭代、缩小范围或停止”的阶段证据。本章不替代组织级用例组合取舍（见开篇与第 8 章），也不替代完整的价值核算方法（见第 11 章）。若无法确认业务 Owner、数据边界、人工审核或回退路径，本章的正确动作是暂缓，而不是开始搭建。
本章每个关键控制点都用同一组问题落地，避免把“治理”“闭环”写成抽象口号：谁判断、依据什么、记录什么、缺什么就停止。 这四问不要求每一步新增一张表；只要在立项卡、任务定义、验证记录或工作流合约中能找到明确答案即可。答案缺失时，默认动作是缩小范围、转人工或暂缓，不是由使用者自行补猜。
先区分：探索轨不是受控运行的简化版
企业不必在验证一个想法前就完成完整的生产治理，也不能把“先探索”理解为可以无边界接入资料或直接影响真实业务。探索轨用于判断一个任务、方法或上下文组合是否值得继续学习；受控运行轨用于在真实工作中持续交付可复核、可维护、可接管的结果。两条轨道的目的不同，所需证据也不同。
| 维度 | 探索轨：为学习设计 | 受控运行轨：为可靠交付设计 |
|---|---|---|
| 目的 | 验证任务是否有价值、方法是否有潜力、哪些失败值得研究。 | 在明确边界内持续完成真实工作，并为扩大、缩小或停止留下证据。 |
| 允许输入与动作 | 公开、合成、脱敏或已明确批准的有限材料；默认只读、草稿、沙箱或本地演算。 | 有 Owner、来源、范围、版本、权限和人工路径的最小必要上下文；按运行合约执行受限动作。 |
| 最小控制与记录 | 明确发起人、任务假设、输入类别、时间/成本上限、禁止动作、失败或惊喜和下一步决定。 | 用例立项、任务定义、验证、人工接管、运行记录与阶段证据；关键决定回答四问。 |
| 不允许的捷径 | 不上传未获准的敏感资料，不对外发送，不写入生产系统，不把探索结论写成权威规则或已验证效果。 | 不以“正在试用”为由绕过审批、来源/权限边界、审核、回退或事件记录。 |
出现以下任一情形时，探索必须切换为受控运行设计，而不是继续沿用临时做法：开始使用真实且受限的数据；输出将对外发送、写入系统或影响人员、财务、客户和关键决策；接入跨系统工具或持久记忆；计划由多人复用、持续运行或声明收益。此时应回到本章的用例立项、任务定义、验证和回退步骤，并按风险条件取用附录 A 的资产。反过来，受控测试发现目标、输入或价值假设尚不成立时，也可以退回探索轨重写问题，而不是用更多模型、提示词或流程掩盖不确定性。
证据边界： 本章沿用附录 D 的正文就地标记规范。统一证据边界仍是：探索中的顺利输出、教学演练或个人体验，不是业务效果证据，也不能单独支持扩大、提高自主性或对外主张；只有有相称的样本、审核、版本、风险/回退与阶段记录的
〔受控证据〕，才进入下一步判断。
先看答案：首轮先留下三项产出
第一次设计受控闭环时，不必把本章的七步和附录 A 的全部资产一次做完。首轮的目标是留下能支持下一步决定的三项内容：
| 首轮产出 | 用现有资产完成什么 | 此刻还不需要做什么 |
|---|---|---|
| 1. 用例立项 | 用附录 A 第 25 节写清业务问题、范围、Owner、不可接受结果和停止条件。 | 不需要先建设完整平台、知识库或 Agent。 |
| 2. 任务定义 | 用附录 A 第 2 节写清触发、输入、输出、质量标准、禁止事项与人工控制。 | 不需要先把所有历史资料整理完；只确认本轮允许的最小输入。 |
| 3. 验证与回退 | 用附录 A 第 4 节验证清单，加上任务定义中的人工控制与回退字段，写清谁审核、依据什么、失败后回到哪条人工路径。 | 不需要先承诺真实收益、全员推广或更高自主性。 |
这三项是开始设计第一个受控闭环的最小路径，不是所有场景都可直接运行的许可。涉及对外、写入、敏感数据、跨系统工具、持久记忆或多人复制时，仍须按风险条件补齐附录 A 的相应资产；若业务 Owner、允许输入、审核人或回退路径缺失，正确产出是“暂停或缩小”，而不是一张看似完整的表。
会让试点越做越乱的五种做法
- 在未写清任务、审核人和不可接受结果前，先比较模型、堆 Prompt 或搭 Agent；
- 以演示中的顺利输出替代正常、边界、信息不足和历史失败样本；
- 资料、权限或责任不清时，仍让使用者用个人账号、临时导出或猜测继续；
- 把生成时间当作全部效率，遗漏人工审核、接管、返工、错误处理和维护负担；
- 一次低风险成功后，就扩大到对外、写入、敏感数据或无人能接手的流程。
出现任何一项时，先停止扩大：记录是哪个假设、输入、审核、工具或回退条件失效；恢复人工原流程或缩小到可控范围；再决定是修复后复测、退回探索还是停止。不要把“越做越乱”自动解释为模型不够强。
若需要把可观察信号进一步映射到可能根因、受控处置和复验要点，可查阅附录 G：AI Failure Casebook。案例库用于帮助定位与学习，不替代本章的业务边界、人工回退和阶段决定。
一、选择最小闭环场景的标准
先用以下标准快速筛选场景，避免一开始就做大而全的项目。 必须同时满足的条件：
- 任务以足够频率重复出现，能够积累同口径样本
- 输入信息相对完整、可获取，且数据边界能够确认
- 输出有明确的业务质量标准，能够由规则或人工验证
- 失败成本可控，能够人工纠正、停止或回退，不会产生不可接受后果
优先推荐的起步场景：
- 会议纪要整理 + 待办提取
- 客户/内部邮件的标准回复起草
- 周报/日报初稿生成
- 简单数据的结构化汇总与异常标记
- 产品/政策问答的标准答案生成（基于已有文档）
暂缓的场景：
- 需要跨多个系统实时写回的操作
- 涉及最终决策或对外正式承诺的内容
- 输入信息严重缺失或高度依赖个人经验判断的任务
〔研究观察〕
RA-001；外部案例观察（匿名报告样本）： 斯坦福数字经济实验室报告记录了一家匿名技术服务企业的安全运营中心场景：面对高频告警，团队把 AI 的范围收窄为规则性初步分流；需要经验判断、信息冲突或风险更高的告警仍升级给分析师。可借鉴之处不在于“自动化了多少”，而在于把任务缩小到可验证的一段，并把例外、升级和人工判断留在流程里。斯坦福数字经济实验室，2026 具体研究边界与不可外推事项见附录 D §匿名报告观察案例的使用边界。不可外推： 该匿名案例来自已持续采用且有可量化价值的项目样本，不提供给其他组织的安全、质量、人员配置或自动化程度结论。高频不等于低风险；任何团队仍须按自身数据、错误后果、审核能力和回退条件决定能否试点。
按后果选择监督方式，而不是把“人审”写成同一种动作
人工参与并不只有“每次都审批”这一种形式。应由错误后果、监管或合同约束、结果可验证性、可恢复性和已有运行证据共同决定监督方式；任何方式都不取消业务 Owner、记录和人工回退。
| 当前条件 | 适合先采用的监督方式 | 人要做什么 | 不应据此推出什么 |
|---|---|---|---|
| 目标仍需共同澄清，质量高度依赖情境判断，或使用者还在学习任务边界。 | 协作式复核：人和 AI 共同完成，关键判断保留在人。 | 定义任务、补足信息、比较方案、判断采用或转人工。 | 不能因使用频率上升，就自动减少人工判断。 |
| 对外沟通、监管/合同约束、高影响决定，或一次错误难以补救。 | 逐项审核：输出或动作进入下一步前逐次确认。 | 查看依据、适用范围和拟执行动作；修改、拒绝或停止。 | 不能把“AI 已通过自动检查”当作批准。 |
| 高频、范围窄、成功标准明确、错误可被及时发现和恢复，且已在受控运行中证明接管/回退有效。 | 例外升级或风险相称抽检：AI 处理常规项，人集中处理例外和抽检。 | 维护例外规则、查看抽检与运行信号；在异常时扩大人工介入或降级。 | 不代表可以取消日志、停止条件、人工备用或后续复核。 |
监督方式可以随任务、证据和风险变化而升降级。若无法解释为什么可以减少逐项审核，或例外被不断扩大为常态，就回到协作式复核或逐项审核，而不是继续提高自主性。
二、最小闭环的完整操作步骤
按以下 7 步执行。第一轮的周期和样本量应由任务频率、错误后果、审核能力和风险边界确定；关键在于获得足以支持下一次阶段决策的证据，而不是追求固定天数。
前置动作：填写用例立项卡（30–45 分钟）
在写提示词或搭建工具前，先使用附录 A 第 25 节确认：你要解决的业务问题是什么、当前基线在哪里、谁是业务 Owner、哪些结果不可接受、人工保留哪些判断、试点结束后要依据什么证据继续或停止。对“范围、质量、发布/停止”三个关键决定，立项卡至少要写出：谁作判断、依据哪些样本/规则、记录保存在哪里、缺少哪些条件就不启动或暂停。立项卡不能替代后续设计，但能防止团队“先做技术，再寻找价值”。
同时只选取 1–3 个当前阶段要看的指标，并写清基线、口径、样本范围、记录责任人和下一次决策阈值。例如，会议纪要试点可以记录“关键决议一次通过率”“含人工审核的端到端耗时”和“最终采用率”。完整指标定义见第 11 章；这里的要求是先把测量设计写入试点，不能等到试点结束后再寻找证明价值的数字。
若用例涉及对外沟通、敏感数据、关键决策、写入操作或不可逆后果，应在进入测试前同步完成第 15 章的数据分级和附录 A 第 34 节的风险初筛；按 R2/R3 处理或发生重大变化的用例，还应完成附录 A 第 35 节的 AI 影响评估。无法明确边界、Owner、人工回退或控制要求时，缩小场景或暂缓试点。
步骤 1：明确任务定义和工作流边界（30 分钟）
用下面的模板写清楚： 任务名称： 触发条件： （什么情况下启动这个任务） 输入： （需要哪些信息，从哪里获取） 输出： （最终要交付什么，格式要求） 质量标准： （怎样算合格） 当前人工耗时： （平均每次多少分钟） 目标： （希望降到多少分钟，或提升什么指标）
关键控制点（可按需要列 1–3 项）：
谁判断：谁确认范围、质量与是否可进入下一步？替补是谁？
依据什么：使用哪些来源、样本、Rubric、规则或审批？
记录什么：结论、版本、异常与人工修改写到哪里？
缺什么就停止：缺少 Owner、输入、有效来源、审核人或回退时，如何转人工、缩小或暂缓？ 示例：
任务名称：周会会议纪要与待办提取
触发条件：周会结束后
输入：会议录音转写文本或完整聊天记录
输出：结构化纪要+待办列表（负责人、截止日期）
质量标准：关键决议无遗漏、待办可执行、格式统一
当前人工耗时：35–50 分钟
目标：控制在 12 分钟以内（含人工检查）
任务定义应与立项卡保持一致：范围、禁止事项、目标用户和人工控制点不得在两份资产中相互矛盾。进入多人试点前，将该定义扩展到附录 A 第 26 节的工作流合约，明确步骤、执行者、验证和异常处理。
在进入下一步前，业务 Owner 应能对以下一句话签字确认：“本轮只在____范围内，用____输入生成____输出；达到____证据后才考虑下一阶段；若出现____，立即转人工、缩小或停止。” 无法写清这句话，说明最小闭环还没有准备好。
步骤 2：准备最小上下文包与代表性样本
不要先收集“尽可能多”的资料。先为当前任务建立最小上下文包：它应说明本次任务的目标、允许使用的来源、排除内容、知识版本、数据边界、人工责任和停止条件。上下文包模板见附录 A 的相关资产；第 5 章说明了为何资料正确仍不等于上下文正确。
| 最小资产 | 要求 | 现场检查问题 |
|---|---|---|
| 任务事实 | 当前对象、范围、输入字段、输出要求和不可接受后果 | 这是否足以支持当前任务，而不是泛泛背景？ |
| 权威知识 | 已批准的规则、版本、生效日期、适用范围和来源 | 它是否仍有效，是否适用于当前对象/地区/产品？ |
| 示例与反例 | 少量正常、边界和历史失败样本 | 是否同时说明“应如何做”与“绝不能怎样做”？ |
| 排除与权限 | 不应读取、保存、外发或作为依据的内容 | 是否存在敏感、过期、无 Owner 或超出目的的资料？ |
| 回退与 Owner | 信息不足、冲突、过期或异常时的人工路径 | 谁确认来源，谁审核输出，谁有权停止？ |
若需要检索或工具调用，第一轮应只允许少量、职责清楚且可追溯的来源或工具；空结果、冲突结果、权限拒绝或超时必须转人工或停止，而不是让模型猜测。
对每类输入或来源，至少留下“确认人、依据版本、确认日期、异常后的动作”之一的可追溯记录。若无法辨认来源是否被批准、是否仍适用，或无人能决定冲突版本，应停在输入校验，不进入生成。
步骤 3：固化提示词模板
使用固定结构，不要每次重新写。推荐模板如下：
角色：你是[具体角色]，负责[具体任务]。
任务目标：
[用一句话说明要完成什么，以及不得替代的人工判断]
输入信息：
[在这里粘贴或描述经批准的输入；标注知识版本、来源或适用范围]
必须遵守的规则：
- [规则 1]
- [规则 2]
- [规则 3]
信息不足、来源冲突、超出范围或不确定时：
[说明应询问、标记待确认、转人工或停止]
输出格式：
[明确结构，优先使用可审核的 Markdown 或 JSON]
参考示例：
[放入少量正常或边界示例]把这个模板保存为文件，后续只替换“输入信息”部分。
步骤 4：设置验证检查清单
每次输出后，必须按清单检查，不要凭感觉判断。 示例检查清单（会议纪要场景）：
- [ ] 所有明确决议都已记录
- [ ] 待办包含负责人
- [ ] 待办包含可执行的行动描述
- [ ] 没有把讨论中的建议误写成决议
- [ ] 格式与模板一致
- [ ] 无明显事实错误
只有全部勾选通过，才进入使用环节。任何一项不通过，就返回修改或人工重做。
验证前还应写明：由谁对每次“通过/不通过”作最终判断，检查依据是输入、规则还是 Rubric，结果记录到哪里；审核人缺席、依据过期或无法判断时，应按人工原流程处理，而不是默认为通过。
步骤 5：执行第一轮受控测试
使用少量具有代表性的真实或经批准的去标识化任务测试，至少覆盖正常、边界、信息不足或历史失败等情形。记录以下数据：
| 次数 | 生成耗时 | 人工检查耗时 | 审核/判断人 | 使用的依据/版本 | 是否通过验证 | 主要问题与停止/回退动作 | 最终是否采用 |
|---|---|---|---|---|---|---|---|
| 1 | 2 | ... |
步骤 6：根据测试结果快速迭代
重点检查并优先修复以下问题：
- 任务定义、禁止事项或人工责任不清晰
- 上下文包中的来源、版本、适用范围、权限或排除条件缺失
- Prompt、检查清单或工具/检索返回无法支持审核
- 输入信息不足、冲突、过期或无 Owner
每次变更应记录原因、受影响资产和需要回归的样本。低风险改动可以小范围复测；涉及规则、数据范围、工具、权限或对外行为的变更，应按第 5 章和附录 A 的影响分析、回归和发布资产处理。
如果无法说明本次变更由谁决定、基于哪些失败证据、将在哪份记录中留下结论，或无法安排回归与回退，就不要把变更带入下一轮试点。
步骤 7：固化并小范围共享
当试点样本已覆盖预定场景，质量、人工审核负担、风险控制和回退表现均达到用例立项卡中约定的阶段条件后，做以下固化：
- 把最终提示词模板、检查清单、示例保存到共享位置。
- 写一份不超过 1 页的使用说明（什么时候用、怎么用、出问题怎么办）。
- 为该能力建立或更新 Skill 卡；如存在多个步骤或多人交接，同步填写工作流合约。
- 将用例编号写入 Skill 卡、工作流合约、周度评测和后续变更记录。
- 让至少一名非设计者按同一资产独立完成受控运行、审核和异常处理，记录其反馈与接棒证据。
- 回到用例立项卡，基于质量、采用、效率、风险和维护负担决定进入限量试运行、继续迭代、缩小范围或停止。
三、常见失败点与应对方法
| 失败现象 | 可能原因 | 立即处理方式 |
|---|---|---|
| 输出经常漏关键信息 | 提示词未明确“必须包含”的字段 | 在规则中逐条列出必含内容 |
| 格式每次都不一样 | 输出格式约束不够严格 | 改用 JSON 或固定 Markdown 标题 |
| 检查通过但业务上不可用 | 质量标准定义太宽松 | 补充业务侧的具体判断条件 |
| 越用越不稳定 | 提示词不断追加规则导致冲突 | 回退到上一版可用模板，重新精简 |
| 同事用不起来 | 使用说明不清楚或步骤太碎 | 简化成“复制模板→粘贴输入→检查清单”三步 |
四、最小闭环成功的判断标准
同时满足以下条件，即可视为第一阶段成功：
- 试点样本覆盖了用例立项卡定义的正常、边界和高风险或历史失败情形
- 输出质量、人工审核负担、处理时效和采用情况已按预定义口径记录
- 关键错误、信息不足、来源冲突、权限异常和工具故障能被识别、停止、转人工或回退
- 至少一名非设计者能依据同一上下文包、Skill 卡和工作流合约独立完成受控运行
- 用例立项卡中定义的价值、风险、维护与停止假设已有相称证据，并已记录下一次阶段决策
达到标准后，再考虑扩大场景或增加自动化程度。未达到标准，继续在当前场景迭代，不要急于铺开。
暂停条件：如果试点多轮后仍无法稳定定义质量、合法获取代表性输入、安排人工审核或提供可行回退，则应停止或重新选择任务，而不是用更多 Prompt、模型、Agent 或工具掩盖前置条件的缺失。停止记录同样是组合决策的重要证据。
五、本章行动清单
请立即执行：
- 用“选择标准”选出 1 个最小场景，并填写附录 A 第 25 节的用例立项卡。
- 填写任务定义，明确范围、输入、输出、禁止事项和人工控制点。
- 对范围、质量和阶段决定分别写下“谁判断、依据什么、记录什么、缺什么就停止”。
- 建立最小上下文包，选择具有代表性的正常、边界和失败样本；如场景存在明显风险，先完成第 15 章的数据分级和相关审查。
- 写出第一版提示词模板、来源展示方式和检查清单。
- 用受控任务测试并记录输入范围、知识/工具版本、审核结果、异常和回退。
- 达到小范围共享条件后，建立 Skill 卡；涉及多步骤或多人协作时，补齐工作流合约。
完成本章行动后，你就拥有了一个可运行、可追溯并可进入下一次阶段决策的最小闭环。这是后续扩大范围和提升稳定性的基础。