第 16 章 公开案例、教学情景与完整案例集
本章使用两类材料。公开案例来自可追溯的裁决、机构公开信息或媒体报道，用于说明控制问题为何真实存在；教学情景则用于演练任务定义、风险、评测、发布和回退资产。两类材料不能混用。
证据边界： 公开案例只支持其来源所记载的特定事实，且必须说明其时间、辖区、来源等级和不可外推事项。除非明确链接到可复核来源或受控运行证据，教学情景中的组织、任务、时间、比例、成本和结果均为去标识化或抽象化设定，不构成任何企业的效果承诺、行业基准或生产验收结论。真实项目应使用
evidence/目录和附录 A、B 的资产记录实际样本、审核、风险、发布和运行证据。
读者应借鉴控制逻辑而非复制数字：先明确任务和责任，再按自身业务、数据、专业风险和制度进行验证、回退与决策。案例来源等级、完整事实边界和复核规则见附录 D。
一、公开案例：为什么控制链不可省略
| 案例 | 已核验的有限事实 | 对手册的控制启示 | 不可外推事项 |
|---|---|---|---|
| Air Canada 聊天机器人信息错误 | 加拿大卑诗省民事纠纷审裁处在特定纠纷中认定，航空公司应对其网站聊天机器人提供的错误丧亲票价信息负责。1 | 对外回复需管理权威知识、版本/生效范围、承诺边界、人工升级和纠错证据。 | 不是全球通用的法律规则。 |
| 纽约市 MyCity 商业信息聊天机器人 | 调查报道发现该机器人给出与纽约市规则不一致的劳动、住房和现金支付信息；后续报道记录纽约市长承认系统存在问题，且网站强化了“不得作为法律或专业建议使用”的提示。2 3 | 高影响问答不能仅依赖免责声明；应设定来源定位、拒答/转人工、风险样本、发布门和事件闭环。 | 不是对所有公共服务系统的质量结论。 |
| 三星公共工具数据边界事件 | CNBC 报道称三星确认出现误用后，暂时限制员工在公司个人电脑上使用相关生成式 AI；具体敏感数据输入来自其他媒体的转述。4 | Shadow AI 治理应同时提供数据分类、批准路径、受控替代方案、培训和事件响应。 | 不证明数据被训练或向其他用户泄露。 |
| Morgan Stanley 内部知识助理 | 官方公告称其研究助手支持带链接的检索、综合和邮件草稿，供员工修改后分享；共同案例描述了评测与人工审核机制。5 6 | 从检索、摘要和草稿等可限定任务起步；将评测、引用和人工定稿视为产品能力。 | 当事方自述的采用率或效率不能作为一般企业目标。 |
| GSA 与美国劳工部用例库存 | 官方库存区分预部署、试点和已部署的 AI 用例及其用途。7 8 | 用例台账应区分项目意图、试点、部署与已验证价值。 | 政府分类和公开义务不自动适用于私营组织。 |
| PocketOS AI 编码 Agent 事故报道 | Guardian 根据创始人陈述报道其生产数据和备份被删除；报道说明厂商未立即回应置评。9 | 破坏性动作应依靠最小权限、隔离、独立授权、异地备份和恢复演练控制，而非提示词禁止语。 | 未公开完整独立技术复盘，不能推导特定工具或模型的一般行为。 |
二、教学情景一：周会纪要与待办提取（个人/小团队起步场景，非实际运行记录）
1. 背景
某产品团队每周五召开例会，时长 60–90 分钟。会后由产品经理整理纪要和待办，平均耗时 40 分钟。常见问题包括：决议遗漏、待办描述模糊、负责人或截止日期缺失、格式不统一。
2. 目标
- 以当前人工流程为基线，观察端到端整理与核验时间是否改善。
- 确保关键决议、待办、责任人和截止时间可由会议参与者核验。
- 输出遵循固定结构，并能在人工确认后进入协作文档。
3. 具体执行步骤
步骤 1：任务定义
- 触发：周会结束后
- 输入：完整会议转写文本
- 输出：结构化纪要+待办列表（负责人、行动、截止日期）
- 质量标准：无关键决议遗漏、待办可直接执行、格式统一
步骤 2：准备材料 收集了近 4 次会议的人工纪要作为示例，并整理了一页「必须包含的字段」和「禁止把讨论建议写成决议」的规则。 步骤 3：提示词模板（最终版核心部分）
角色：产品团队会议纪要助手
任务：根据提供的会议转写，生成结构化纪要和待办列表。
规则：
- 只记录明确达成的决议；讨论中的建议不写入决议。
- 每条待办应包含负责人、具体行动和截止日期；信息未明确时标记为“待确认”。
- 按以下格式输出；不要增加未定义章节。
输出格式：
- 会议基本信息：日期、参会角色。
- 关键决议：编号列表。
- 待办事项：
| 待办事项 | 负责人 | 行动描述 | 截止日期 |
| --- | --- | --- | --- |步骤 4：验证清单
- [ ] 所有明确决议已记录
- [ ] 待办均有负责人
- [ ] 行动描述具体可执行
- [ ] 无把建议误写为决议
- [ ] 格式完全符合模板
步骤 5：测试与迭代 在情景化试运行中，团队先用少量历史会议材料测试，发现模型会把“建议”误写为决议。随后补充反例与验证规则，并以相同口径的样本重新比较。真实项目应记录样本范围、版本、审核结论、端到端耗时和未通过原因，而不应直接套用本案例中的数字。
4. 结果
在该情景的扩大前，团队需要先在单一会议类型中积累足以判断的样本与审核记录，并确认格式、关键字段、人工负担和回退流程可接受。不同会议类型的参会角色、决策结构和敏感边界可能不同；扩展到新会议前应重新评估并回归受影响样本。
5. 可复制要点
规则中明确“什么不能写”比只说“写什么”更有效；验证清单必须包含业务侧易错点；先在单一会议类型跑稳，再扩展。
6. 从工作流升级为 Skill 资产
当该场景已连续稳定运行后，团队不应只保留一段 Prompt 和一张检查清单，而应先以 UC-PROD-001 作为用例主键记录业务问题、基线、边界、Owner 与下一次决策，再将它升级为“产品周会纪要提取与核验 Skill”。附录 A 第 13 节的已填写 Skill 卡和第 28 节的产品周会纪要工作流合约分别固化了能力与流程层的适用边界、输入输出、受控组件、验证、人工控制、回退、责任人、指标和变更记录。
这一升级带来三个实际收益。第一，第二位同事可以依据同一张卡独立运行，不再依赖原作者口头交接。第二，团队可以在规则、示例、模型或知识变化后，知道应该回归哪些历史会议样本。第三，若后续把纪要生成、待办检查和发布前确认连接为自动化流程，系统也只能调用这张已验证的 Skill，而不是重新使用未经治理的自由 Prompt。
本案例不需要 Agent：会议纪要、待办提取与人工确认的顺序明确，使用固定工作流即可获得更高可控性。若仅为“更自主”而加入动态规划，通常难以证明其额外价值足以覆盖新增的治理成本。只有在固定步骤无法满足业务需要，且额外收益、权限、验证、回退和运行证据都已明确时，才应评估是否引入更高自主性。
三、教学情景二：客户咨询标准回复起草（业务团队场景，非实际运行记录）
1. 背景
客服与销售支持团队每天处理大量重复性咨询（物流、退换货、活动规则等）。平均每次回复耗时 8–15 分钟，存在口径不统一、遗漏关键提示的问题。
2. 目标
- 以当前人工回复流程为基线，观察端到端处理时间和审核负担是否改善。
- 使草稿可定位到当前适用的规则、版本和生效范围。
- 保留人工对采用、修改、转人工和发送的最终决定。
3. 具体执行步骤
步骤 1：场景选择与范围控制 只选择高频、规则清晰的 6 类问题作为第一期，明确排除涉及补偿决策和投诉升级的内容。 步骤 2：知识准备 由业务负责人整理《当前标准答复要点》（按问题类型分类，每类不超过 300 字），并标注生效日期。过时内容全部移除。 步骤 3：工作流设计
- 使用者粘贴客户原话+选择问题类型
- 模型根据对应要点生成回复草稿
- 人工对照检查清单确认后发送
步骤 4：提示词关键结构
- 强制引用对应问题类型的标准要点
- 要求回复中必须包含指定的关键提示语
- 输出分为“回复正文”和“使用的要点来源”两部分，便于检查
步骤 5：验证清单（部分）
- [ ] 使用了正确问题类型的最新要点
- [ ] 包含必须提示的关键信息
- [ ] 无额外承诺
- [ ] 语气符合团队规范
4. 结果
在情景化试运行中，团队会将限定类别的草稿、审核、修改、转人工和知识版本记录在同一证据链中。是否扩大到更多类别，应由实际的 Golden Set、知识时效、人工审核能力、风险控制和观察期证据决定；不应以本案例的时间或比例作为通用门槛。
5. 可复制要点
严格控制第一期范围，只用规则最清晰的问题；知识必须有责任人和生效日期；输出中要求模型自报“使用了哪些要点”，方便快速验证。
6. 从回复草稿升级为业务类 Skill
当这六类问题已经稳定运行后，团队应先填写 UC-CS-001 用例立项卡，确认外部沟通边界、知识时效风险、人工保留决策和停止条件，再将其升级为“客户咨询标准回复草拟与核验 Skill”。附录 A 第 27 节提供已填写的用例立项卡，第 16 节提供关联 Skill 卡：两者共同补齐了适用边界、禁止事项、知识版本、来源展示、自动与人工验证、异常转人工、回退、责任人和运行指标。
这一类 Skill 与会议纪要 Skill 的关键差异在于：它面向外部客户，业务规则具有时效性，且错误可能被理解为承诺。因此，生成结果只能是草稿，必须由经培训人员核对问题类型、知识来源、版本、生效日期、关键提示和禁止承诺后，才可发送。即使一次通过率较高，也不应因为追求效率而跳过发送前确认。
7. 知识变更到限量发布的闭环
在一次知识规则变更情景中，活动规则发生更新。团队没有直接替换知识库内容，而是先由活动运营负责人确认新规则的权威来源和生效时间；知识责任人将活动规则条目升级为新版本，并标注旧版本失效范围；Skill 责任人据此列出受影响的问题类型、Prompt、正确示例、错误示例和验证字段。
随后，团队选择正常咨询、活动已结束、不符合参与条件、曾遗漏截止日期的历史失败样本，以及要求例外补偿的转人工样本进行回归。回归不仅检查回复正文是否流畅，还检查是否引用最新要点、是否正确展示截止日期、是否会把例外请求转人工。通过后，团队仅向已培训的小范围使用者开放活动类咨询，并维持每条草稿的人工确认；观察期内一旦发现日期、适用商品或承诺口径错误，立即回退到上一稳定知识版本和人工回复流程。
这个闭环的价值不在于增加流程，而在于让团队清楚知道“规则变了以后，究竟影响了什么、如何证明修复有效、出问题后如何停止”。对应的 Skill 卡、变更记录与发布安排见附录 A 第 16 节和第 17 节；附录 A 第 33 节给出了应覆盖正常、边界、历史失败和转人工情形的 Golden Set 示例，实际比较结果应记录在第 31 节的回归报告中，并通过第 32 节的发布登记限定观察范围。附录 A 第 38 节进一步示范了此类对外沟通用例如何完成 R2 风险初筛、影响评估与控制证据连接。第 5 章第六节提供了按知识变更风险分层的通用方法。
四、教学情景三：周报初稿生成与数据异常标记（运营场景，非实际运行记录）
1. 背景
运营团队每周一需提交周报，包含核心指标、异常说明和下周计划。人工从多个表格取数、写描述，平均耗时 70 分钟。异常经常被遗漏或描述不准确。
2. 目标
- 以当前人工周报流程为基线，观察端到端准备与核验时间。
- 确保由规则命中的异常可追溯，并由人工确认原因。
- 记录数据来源、版本和异常判断依据。
3. 具体执行步骤
步骤 1：输入标准化 要求所有数据源在周五下班前按固定模板更新到指定表格（指标名称、本周值、上周值、目标值）。 步骤 2：工作流拆分
- 数据汇总与异常自动标记（模型处理）
- 异常原因初稿生成（模型处理）
- 人工确认数据与补充原因
- 生成完整周报结构
步骤 3：异常判断规则（写入提示词）
- 波动超过±15%且绝对值超过设定阈值→标记为需说明
- 连续两周朝同一方向偏离目标→标记为需说明
步骤 4：验证重点
- 数据与原始表格一致
- 所有被规则命中的异常均有说明
- 无编造未提供的原因
4. 结果
在情景化试运行中，团队应先核验输入表结构和异常规则，再比较人工流程与候选工作流的端到端耗时、异常发现、误报、漏报和人工修改。确认规则在目标范围内可用后，再将其沉淀为共享标准，并为规则变化保留回归机制。
5. 可复制要点
- 先统一输入格式，再让模型处理。
- 用可解释的异常规则降低主观性，并定期检查规则是否仍适用。
- 将“数据一致性检查”放在验证清单的优先位置。
五、教学情景四：合同条款风险审查（选错场景的典型，非实际运行记录）
1. 背景
设想一个法务团队希望用 AI 自动标记合同风险条款。团队若因“AI 能读合同”的演示而直接启动项目，却未先评估漏检后果、验证成本和专业责任，就可能面临范围选择错误。
2. 目标
- 协助识别合同中可能需要进一步审查的条款，例如自动续约、责任限制或单方解除限制。
- 在不降低法务专业审查责任的前提下，评估该辅助是否减少可验证的重复工作。
3. 执行过程
第一阶段（第 1–2 周）：提示词与测试 模型确实能“识别”风险条款——输出格式工整，每条都标注了风险等级和依据。团队一度非常乐观。 第二阶段（第 3–4 周）：问题浮现 在情景化复核中，资深法务可能发现：
- AI 标记了约 40%的条款为“有风险”，其中大量是标准商业条款（法务称“每份合同都有，不需要标记”）
- 真正的高风险条款（如隐藏的自动续约条款），AI 时有遗漏——第 4 周测试的 8 份合同中有 2 份漏掉了关键条款
- 更麻烦的是，AI 给出的“风险依据”看起来专业且合理，但经常是对条款含义的误读。这迫使法务必须逐条重读原文，而无法只看 AI 摘要
第三阶段（第 5–6 周）：尝试修复 团队按本书第 3、5 章的方法迭代了三轮提示词，增加了大量正反例。标记准确率有提升，但漏检率始终无法降到可接受水平——法务的结论是：“只要还可能漏，我就必须全文重读，那 AI 就没帮我省任何时间。”
4. 回退决策
第 6 周末，项目停止。判断依据非常清晰：
| 判断项 | 实际情况 | 是否满足第 5 章场景标准 |
|---|---|---|
| 失败成本可控 | 漏检高风险条款可能导致重大法律损失 | 不满足 |
| 输出可验证 | 验证需要完整法律专业能力，无法快速检查 | 不满足 |
| 单次任务耗时 15–90 分钟 | 合同审阅平均 90 分钟以上，且不可分割 | 边缘不满足 |
若在真实评估中出现上述组合情形，团队应暂停将其作为自动标记优先场景，并重新界定可辅助的低风险子任务；这不等于 AI 不能参与合同工作，而是说明当前任务边界、验证与责任设计不适合直接扩大。
5. 教训
- “AI 能做”不等于“这个场景应当这样做”。即使模型能生成看似专业的分析，团队仍需根据漏检后果、专业责任和回退能力决定参与边界。
- 验证成本可能抵消生成收益。若人工仍需以接近原流程的成本完成完整审查，团队应重新评估价值假设和可辅助的子任务。
- 当出现持续的依据误读、关键漏检或无法解释的差异时，应回到用例选择、风险和验证设计，而不是只在提示词上反复加规则。
六、教学情景五：跨系统自动周报（过早追求全自动的典型，非实际运行记录）
1. 背景
设想一个运营团队在周报场景中跑通了单任务闭环后，决定一步到位升级为“全自动”：让 AI Agent 登录多个内部系统拉取数据、生成图表、撰写分析并发送邮件，且不设置人工确认。该情景用于说明多步骤自动化新增的依赖、权限和错误传播风险。
2. 目标
- 在明确范围内减少重复的数据整理与初稿撰写工作。
- 仅在数据、异常、权限、发送边界和人工接管均可验证后，评估是否提高自动化程度。
3. 执行过程
第一阶段（第 1–3 周）：搭建多步流程 搭建了“登录系统 A 拉数据→登录系统 B 拉数据→汇总计算→生成图表→撰写分析→发送邮件”的六步自动化链路。 第二阶段（第 4–6 周）：错误沿链条放大 问题很快暴露：
- 系统 B 的页面改版导致数据拉取失败，流程在第二步中断，但周一的邮件已经按“空数据”发出了两期——收件人看到了一份指标全部为零的“正常格式”周报
- 某次系统返回了错误数据（数据端重算未完成），Agent 如实汇总，生成了一份数字全错但格式完美的周报，团队基于这份周报做了错误决策
- 定位一次失败原因平均需要 60–90 分钟：问题可能在六个环节中的任何一处，且没有环节级的日志
第三阶段（第 7–8 周）：尝试加固 给流程加了数据校验节点和失败重试，失败率下降，但每加一层防护，维护成本就上升一截。团队两个人的维护时间，已经超过了原本每周 70 分钟的人工周报耗时。
4. 回退决策
第 8 周，团队放弃全自动方案，回退为两段式结构：
- 数据拉取：退回使用各系统自带的定时导出（系统原生功能，零维护成本）
- 分析撰写：保留已跑通的 AI 单任务闭环（案例三模式），人工确认后发送
回退后的两段式方案保留数据准备与人工确认，将 AI 限定在已验证的分析撰写步骤。真实团队应比较端到端耗时、维护、错误发现、人工接管和业务影响，而不应以“零人工”或单一时间节省作为唯一目标。
5. 教训
- 单任务表现不等于多步骤链路表现。每增加一个依赖、状态转换或动作，都需要重新评估错误传播、观测和回退；链路可靠性不能只由单步骤通过率简单推算。
- 上游数据、工具或权限异常可能被后续格式化掩盖，因此应在关键节点设置数据验证、停止条件和可定位日志。
- “零人工”不是唯一目标。对外发送、关键数据或高影响决定通常需要与风险相称的人工确认和接管能力。
- 在引入 AI 或 Agent 前，先评估系统已有的导出、规则、校验和人工流程是否已能以更低复杂度解决问题。
- 自动化的价值应计入维护、审核、事件、回退和人员成本，并与业务结果一起判断。
七、使用建议
- 选择一个与自身边界、数据和风险相近的情景，先补齐任务定义、规则、验证、回退和证据，再决定是否试运行。
- 重点借鉴“任务定义 → 规则与清单 → 样本测试 → 迭代与决策”的过程，而不是只复制提示词或数值。
- 验证清单、人工审核和失败处理方式应按业务影响调整；高风险场景还需接入风险初筛、AIA、发布和 Runbook。
- 启动新场景前，先用风险初筛、用例立项卡和工作流合约判断范围；计划做多步自动化前，先验证固定工作流和系统原生能力是否已满足业务需要。
本章中的教学情景用于说明常见模式与控制链，公开案例则说明为何需要这些控制。读者应按同一结构记录本组织的真实闭环过程，包括未通过、回退和修复过程，并在受控位置保存相应证据；不得将教学情景中的时间、比例、成本或结果转写为真实项目结论。