第 12 章 让结果长期可靠：评测、治理与组织协同
本章路标：要避免的误判是“有人负责”就等于“治理已经运行”；本章产出是带有决定权、替补、证据和升级路径的协同安排；如果用例还没有最小闭环或真实运行记录，应先回到第 6 章，不要先扩充组织角色。
十分钟练习：选一个现有指标，写出它可能掩盖的一个问题、即使改善仍应暂停的一个情形，以及由谁组织核对、谁有权阻断。练习结果放入该用例的阶段记录，不新增一套只展示绿灯的看板。
最小闭环跑通后，下一步是让它在真实组织环境中持续稳定运行。
本章提供可直接执行的方法，覆盖三个关键问题：如何持续评测效果、如何做基础治理、如何推动必要的组织协同。
一、建立简单有效的评测机制
没有评测，就无法判断工作流是否在变好还是在变差。
1. 必做的基础评测（按运行节奏复核）
针对已上线的最小闭环，固定记录以下数据。周度 15–20 分钟可作为高频低风险用例的起步节奏，但不是统一要求；用例频率、错误后果、变更速度和审核能力决定实际周期。
| 评测项 | 记录内容 | 本用例如何设定目标与反证条件 |
|---|---|---|
| 通过率 | 本周期总次数中，一次通过验证清单的比例 | 依据基线、错误后果、Rubric 和审核能力设定；同时写明高平均值仍需停止的不可接受错误或样本退化。 |
| 平均总耗时 | 生成+人工检查的平均时间 | 与同口径人工基线、任务复杂度和审核负担比较；速度改善但控制被绕过时不视为进步。 |
| 主要失败类型 | 本周期最常见的质量、来源、权限、工具或接管问题 | 记录是否可解释、是否影响边界/失败样本、是否已转人工或回退，而不是只追求数量下降。 |
| 实际采用率 | 最终被直接使用或小改后使用的比例 | 区分自愿采用、被迫使用和返工转移；低采用或异常升高都应与使用者核对原因。 |
用共享表格记录即可，不必上复杂系统。
2. 每月一次的深度回顾（30–45 分钟）
每月固定时间回答以下问题：
- 本月通过率、耗时、采用率是否达到目标？
- 失败案例中，哪些是 Prompt 问题，哪些是知识/数据问题，哪些是 Skill 定义、流程或 Agent 运行问题？
- 是否需要更新 Prompt、Skill 卡、上下文包、检查清单、知识内容、记忆、状态逻辑、工具/连接器或权限配置？
- 最近是否发生模型、工具、连接器、知识、上下文、记忆、权限或 Agent 运行逻辑变更；是否需要回归评测？
- 哪个指标即使改善也不足以支持继续；由谁依据什么材料解释当前分歧，缺少什么就应缩小、转人工或暂停？
把结论写成简短记录，作为下月改进依据。
3. 评测结果的使用规则
- 质量退化、不可接受错误、来源/权限异常、回退/接管失效或关键证据无法解释：立即暂停扩大范围；按已有回退路径转人工、缩小或停止，不用平均分数抵消。
- 耗时未改善：检查是否验证环节过重、提示词产生过多修改，或任务本身不适合当前方式；不要为了压缩时间取消审核。
- 采用率偏低或异常升高：与使用者核对是否标准脱离业务、是否被迫使用或返工被转移到下游；需要时补充业务侧标准或缩小范围。
- 指标改善但 Owner、有效依据、记录或回退缺失：保持或降级当前阶段，先补控制条件，不以“结果不错”跳闸门。
二、基础治理动作（必须落地的部分）
治理不需要一开始就做得很重，但以下五项必须明确并执行。
1. 版本管理
所有正式使用的 Prompt 模板、Skill 卡、上下文包、记忆合约、检查清单、知识参考材料、工作流定义、工具/连接器控制卡和 Agent 运行合约，必须有版本号和更新日期。版本号应对应可定位的变更记录；一项关键组件发生变化时，应明确哪些 Skill、工作流或 Agent 会受影响。
命名示例：
- 会议纪要提示词_v1.2_20260819
- 会议纪要提取 Skill_v1.0_20260819
- 待办检查清单_v1.1_20260815
- 异常工单 Agent 运行合约_v1.0_20260819
每次修改后，旧版本保留至少 30 天，方便回退。
2. 权限与使用范围
明确回答三个问题并形成书面记录：
- 谁可以使用这个工作流、Skill 或 Agent？
- 谁有权修改 Prompt、Skill 卡、检查清单、知识材料、状态逻辑或权限配置？
- Agent 可以调用哪些 Skill、上下文来源、记忆、工具/连接器、数据范围和读写动作？
- 工具返回量、保存范围、外发和持久记忆如何受到限制？
- 输出结果可以用于哪些场景，不可以用于哪些场景？
- 谁拥有暂停、恢复、升级自主等级和退役的决策权？
3. 角色、决定权与替补：不能只写一个 Owner 名称
一个人可以在小团队兼任多个角色，但不能让“大家都负责”替代明确责任；也不能把“参与项目”误当成有权接受风险或批准上线。每个正式用例都应为下表角色写入实名或明确岗位、替补人、替补生效条件和记录位置。替补负责在原 Owner 不可用时维持既有边界、发起暂停或转人工；除非另有授权，替补不能自行扩大范围、权限或风险接受。
| 角色 | 有权作出的决定 | 不可替代的责任动作 | 替补/缺席时的动作 | 无权单独决定的事项 |
|---|---|---|---|---|
| 业务 Owner | 在授权业务范围内定义问题、范围、成功/停止条件，并决定继续改进、缩小、暂停或接受已授权的业务结果。 | 提供真实任务与基线；确认人工审核和替代流程；解释业务价值与不可接受后果。 | 指定同等业务授权的替补；无人可拍板时不进入试点或阶段提升。 | 数据/安全例外、技术权限、专业法律结论，或超出其授权的残余风险与资源承诺。 |
| AI Champion | 推动学习、收集采用/失败反馈、建议候选场景和改进。 | 降低使用摩擦，帮助员工理解边界并把问题送到有权角色。 | 可由另一位受训倡议者接替沟通；缺席不应阻断已有的业务/安全判断。 | 代表业务 Owner 接受结果，批准数据/权限、发布、风险例外或生产变更。 |
| 知识 Owner | 确认权威来源、版本、生效范围、冲突处理与失效；停止使用失效或不明知识。 | 完成知识更新、影响分析和受影响资产回归说明。 | 指定熟悉规则且有内容授权的替补；无法确认时将资产标为待确认并转人工。 | 单独扩大业务范围、降低审核、批准工具权限或接受业务风险。 |
| 上下文/记忆 Owner | 决定允许来源、选择逻辑、排除来源、记忆目的、隔离、保留、失效和纠错规则。 | 维护上下文包/记忆合约及其版本与异常记录。 | 指定资产维护替补；无替补或来源争议时停止该上下文/记忆的使用。 | 把未经确认材料默认纳入记忆，或代替业务 Owner 接受输出与对外影响。 |
| 技术/安全 Owner（可按组织分设） | 在已批准边界内配置/撤销工具、连接器、权限、日志、熔断、运行与恢复；对控制失效先行停用其负责范围。 | 证明最小权限、可观测性、异常处置和技术回退；安全角色负责适用的安全约束和升级。 | 指定具备相应权限与值守能力的替补；无人可安全接管时保持停用或只读/人工模式。 | 决定业务是否值得做、对外口径、业务成功标准或替代业务审核。 |
| FDE / AI COE | 在客户/业务授权下提出设计、评测、交付与组合建议；可在其技术职责内执行受控配置。 | 共创资产、暴露假设、辅导第二使用者复现和能力移交。 | 交付中说明支持窗口与退出后联系人；交付者离场前未有客户接棒 Owner 时不宣称落地完成。 | 长期替代客户/业务方 Owner，单方面验收、接受残余风险或宣布生产就绪。 |
这是职责组合，不是一组必须新设的岗位。 小团队可以由同一人兼任相容职责，也可以借助现有业务、知识、审核和技术支持角色；关键是每项决定有人有权作出、有人能在缺席时接住，而不是先招聘一个名称听起来“很懂 AI”的头衔。涉及不相容的授权、风险接受或专业判断时，仍应分离决定权或转专业审查。
4. 变更与回归责任
规则、上下文包、检索、记忆、工具/连接器、模型、权限或状态逻辑发生变化时，应由对应 Owner 发起影响分析；用例 Owner 确认业务边界；技术与风险角色按影响参与评测、审批、发布或回退。低风险内部改动可以轻量记录，高影响或跨系统变化必须使用附录 A 的上下文、工具和回归资产。
5. 问题升级路径
当出现以下情况时，必须升级处理：
- 连续出现同类严重错误
- 输出可能影响客户或正式决策
- 有人绕过验证清单直接使用结果
升级对象和建议处理时限提前写清楚。
三、组织协同的具体推进方法
组织协同无法只靠技术或产研团队推动。美团的经验是一个参照：从无序全员尝试，到事业部成立 AI 组织、赛马梳理方法，再到流程中真正跑通，用了约半年时间，最终确认必须把业务、组织、技术同步推进。
稳定产出最终需要跨角色配合。以下是可执行的推进步骤。
步骤 1：找到最小支持联盟（1 周内完成）
识别三类人并获得明确支持：
- 业务侧使用者（真正跑任务的人）——至少 1 名
- 内容/知识责任人（能更新相关材料的人）——至少 1 名
- 有资源决策权的人（能支持时间或工具的人）——至少 1 名
与他们分别沟通一次，确认他们愿意在当前最小闭环上投入时间。
外部案例观察（匿名报告样本）： 斯坦福数字经济实验室报告中的一家匿名半导体企业，曾在现场服务场景推进 AI 项目。报告将其早期受阻归因于跨部门协作、采用责任和持续推进条件没有同时成立；后续做法不是只增加技术人手，而是让业务、技术与人才相关角色共同投入，并建立面向使用者的持续支持机制。这个情境与本章的“最小支持联盟”和职责组合相呼应：技术方案不能代替资源取舍、业务责任和接棒安排。斯坦福数字经济实验室，2026
不可外推： 该报告选择了已持续采用且有可量化价值的匿名项目，案例也不证明“设立 Champion”“纳入某类考核”或“增加赞助人参与”会在任何组织产生相同结果。当前用例是否继续，仍以本组织的任务、责任、证据、风险与可接管能力为准。
步骤 2：用数据而不是感受推动
每周把评测表格的关键数字同步给支持联盟。只同步数字和主要问题，不扩展讨论。 当数据连续表现稳定时，再提出下一步（增加场景或减少人工检查比例）。
步骤 2.1：先检查激励没有把正确行为推走
组织经常不是缺少“重视 AI”的口号，而是奖励了错误的可见行为。若只表扬上线、演示、调用量、登录次数或“节省了多少分钟”，员工可能不愿报告失败，经理可能不愿暂停，技术团队可能倾向于扩大工具范围。每次周度复盘或阶段评审，业务 Owner 与支持决策人只需核对下表；不需要把它发展成对个人动机的复杂评估。
| 如果当前主要奖励…… | 要防止的行为 | 本周应明确支持的行为 |
|---|---|---|
| 项目启动、展示或工具使用量 | 用不适合的任务凑使用量，隐藏失败或绕过人工审核。 | 及时报告失败、拒绝越界输入、正确转人工或暂停。 |
| 表面速度或单次节省时间 | 把检查、返工和异常成本推给下游。 | 记录端到端负担、实际采用、异常与接管，并说明时间释放去了哪里。 |
| 一次成功后快速扩大 | 忽略第二使用者、共享知识/工具和维护能力。 | 限量复现、记录边界样本与依赖，再决定是否扩大。 |
当表扬、资源或考核方式与这些支持行为冲突时，应由业务赞助人和业务 Owner 在相应授权范围内调整成功口径、复盘方式或试点资源；AI Champion、使用者或技术 Owner 可以提出问题和建议，但不替代业务或风险决定。
步骤 2.2：同步调整工作负担、收益去向与评价方式
员工抵触不一定是“不愿改变”。有时团队担心的是：原工作没有减少，审核、纠错、知识维护和上报却额外增加；节省的时间被立刻换算成更高个人配额；一旦输出出错，责任又回到具体使用者。管理者不必承诺固定收益分配，但在开始或扩大前应把以下问题写入试点复盘：
| 应共同说明的问题 | 可接受的记录方式 | 不应采用的做法 |
|---|---|---|
| 哪个旧动作会减少、改变或保留？ | 用任务定义与端到端观察记录“减少/新增/转移”的工作。 | 把“使用 AI”默认解释为减少岗位或无限增加产出。 |
| 审核、异常处理、知识更新和问题上报谁来做，是否有时间？ | 由业务 Owner 和经理确认责任、可用时间与需要的支持。 | 把额外控制劳动默认为员工自行消化。 |
| 释放出的容量优先用于什么？ | 在阶段记录中说明是降低积压、改善服务、学习、改进，还是经批准的其他目标。 | 把节省分钟数直接作为个人绩效结论或财务收益。 |
| 怎样评价正确行为？ | 明确支持提出不适用、报告失败、保留人工判断、正确暂停和帮助复现。 | 以调用量、登录次数、展示效果或盲目扩大作为个人评价。 |
这些约定不替代人力、绩效、劳动关系或行业专业规则。若试点对岗位职责、个人权益、绩效、薪酬、工时或外包安排有实质影响，应暂停由项目组自行决定，转交有授权的业务、人力、法务或其他适用专业角色处理。
步骤 2.3：让支持部门共同给出可运行条件，而不是最后才“来审批”
安全、法务、隐私、采购、HR、风险与合规等支持部门不替业务 Owner 决定“值不值得做”，也不替技术 Owner 保证系统性能；但当用例会触及其责任范围时，应尽早参与定义可接受的边界和证据。这样既不把控制问题拖到发布前，也不以“合规”作为笼统的推进或否决理由。
| 共同设计的问题 | 项目组应提前提供的最小输入 | 支持部门应留下的可执行结论 |
|---|---|---|
| 数据、上下文、工具与外发边界 | 用例目的、最小输入/输出、数据与工具流、拟议范围和人工替代方式。 | 哪些条件可接受、哪些必须缩小/脱敏/补控制、哪些需要专项审查。 |
| 对外承诺、个人权益与例外 | 谁会受影响、不可接受后果、人工审核、例外范围、有效期和停止条件。 | 是否可按限定条件试行；谁有权审批、复核或在条件变化时停止。 |
| 事件、回退与长期维护 | 关键依赖、异常场景、接管角色、记录位置、恢复与退出方式。 | 需要保留哪些证据；事件如何升级；何时触发重新审查或退役。 |
支持部门的结论应进入风险初筛、AIA、运行合约、发布登记或阶段决策记录的现有位置，而不是只停留在会议纪要中。
步骤 3：明确各方的具体责任
用一页纸写清楚：
| 角色 | 每周固定动作 | 出问题时应做的事 |
|---|---|---|
| 使用者 | 按模板或 Skill 卡执行并完成检查 | 记录失败案例，必要时转人工 |
| AI Champion | 汇总采用、困惑和绕过信号，协助将反馈送到正确 Owner | 不替代任何审批；将越权、风险或边界问题升级 |
| 知识责任人 | 响应知识更新请求 | 在约定时间内完成更新，并确认影响范围 |
| 上下文/记忆责任人 | 维护来源、选择逻辑、隔离、失效和纠错 | 处理过期、冲突、越权、污染或状态异常 |
| 业务/Skill/流程责任人 | 查看质量、采用、耗时与变更记录；组织业务判断 | 业务 Owner 决定修复、回退或暂停当前能力；Skill/流程 Owner 执行受控修复 |
| 技术/工具责任人（如适用） | 维护工具、连接器、权限、日志、熔断与运行状态 | 处理运行异常，验证人工接管与恢复 |
| 支持决策人 | 查看周度数据和重要风险 | 决定是否扩大、提高自主等级或调整资源 |
步骤 4：控制推进节奏
- 只有当当前闭环的代表性样本、质量与控制证据、人工审核和回退均满足立项卡中的阶段条件，且没有“即使指标改善也需暂停”的反证信号时，才增加相邻场景。
- 同时推进的闭环数量由可用的 Owner、审核、维护与回退能力决定；出现维护积压、Owner 缺席或异常无法闭环时，应减少而非增加。
- 任何新场景都必须先完成第 6 章的最小闭环步骤，再进入本章的评测与治理。
四、从试点到制度化：AI 变革的八个阶段
企业 AI 落地失败，很多时候不是技术没跑通，而是组织没有完成从“少数人试点”到“多数人日常工作”的转变。变革管理不是软技能，它和评测、治理一样需要被设计。以下八个阶段以经典的变革方法为骨架，每一阶段都映射到本书已有的资产和产出物，管理者可以据此判断自己处在哪一步、下一步做什么。
| 阶段 | 核心任务 | 本书对应资产 | 可检查的产出 |
|---|---|---|---|
| 1. 建立紧迫感 | 用真实数据和业务损失说明“为什么现在必须做”，而不是用趋势吓人 | 第 1 章的问题诊断、业务基线 | 一份一页纸的现状与代价说明 |
| 2. 组建指导联盟 | 找到业务使用者、知识责任人、有资源决策权的人并确认投入 | 本章步骤 1“最小支持联盟”、用例立项卡 | 明确的三类支持者及投入承诺 |
| 3. 形成愿景与策略 | 说清“未来工作方式是什么样、AI 承担什么、人保留什么” | 企业 AI 战略与业务对齐、第 13 章委托—复核—拥有 | 一页纸愿景：分工边界与不做清单 |
| 4. 大范围沟通愿景 | 把愿景嵌入例会、SOP 和培训，用真实任务演示，而不是发通知 | 第 7 章培训与反馈闭环、第 16 章教学情景 | 团队能复述“什么能交给 AI、什么不能” |
| 5. 授权员工行动 | 清除障碍：给试点时间、数据权限、安全工具，允许低风险试错 | 第 5 章上下文资产、第 15 章数据分级 | 试点者能独立完成任务并上报问题 |
| 6. 创造短期胜利 | 在与任务频率、风险和审核能力相称的周期内做出一个可量化、可展示且可回退的闭环，并明确归功于谁 | 第 6 章最小闭环、第 11 章证据口径 | 一个有通过率/采用率/耗时及控制证据的用例 |
| 7. 巩固成果并扩大 | 把验证过的 Skill 嵌入 SOP，更新治理资产，再扩展下一个场景 | 第 8 章从 1 到 N、本章组合治理 | Skill 卡、SOP 变更、组合台账新增用例 |
| 8. 把新方式制度化 | 将 AI 协作方式写入岗位职责、培训认证、绩效与预算 | 附录 A 实践认证、第 7 章角色学习 | 新员工入职即按新方式工作，旧方式不再是默认 |
使用要点
- 阶段可以重叠，但不应跳步：没有紧迫感和联盟的“直接推广”，通常止步于第 6 阶段的短期胜利，甚至在第 4 阶段就被抵制消耗掉。
- 每一步都要有可检查的产出，避免把“开过会、发过文”当成变革完成。
- 中期（第 5–7 阶段）最容易出现的信号是“试点很好、推广不动”，这通常不是技术问题，而是第 3、4 阶段的愿景和沟通没有完成。
- 激励设计应与阶段匹配：早期奖励“上报失败、安全试错”，中期奖励“可复现资产与第二人复现”，而不是奖励调用量或登录次数。附录 B 明确反对把使用量作为绩效指标。
五、从单个闭环到多个用例的最小组合治理
当团队只有一个最小闭环时，周度记录、明确责任人与问题升级路径已经足够。当正式或试运行用例达到 3 个以上，治理对象会从“某一个提示词是否好用”变成“有限的人、知识、工具和风险预算应该支持哪些用例”。这时不需要立刻建立重型委员会，但至少要建立用例组合台账、阶段决策记录和月度组合评审。
1. 用例组合台账
每个用例在台账中占一行，记录业务目标、当前阶段、业务 Owner、关键 Skill/Agent、知识、上下文、记忆与技术依赖、健康指标、维护负担和下一决策。它的重点是业务用例，而不是工具账号或模型清单。模板见附录 A 第 18 节。
2. 责任与决策权
多人协作时，最容易出现的不是“没人做事”，而是“大家做了事、没有人对业务结果拍板”。每个用例必须有业务 Owner；每个共享知识资产必须有知识 Owner；正式上下文包、持久记忆和检索策略必须有相应 Owner；涉及工具、连接器、权限、日志、熔断或自动化运行的用例必须有技术 Owner。扩大、暂停、恢复或退役由谁决定，应在用例立项时写明。附录 A 第 19 节提供最小 RACI 模板。
3. 阶段闸门与月度评审
用例应在候选、试点、限量生产、受控生产、规模化和退役状态之间有意识地推进。阶段提升应同时检查业务价值、质量和采用、知识/数据、责任、回退及运行控制证据；退役同样需要保证人工或替代流程可用。完整的阶段闸门和决策卡见附录 A 第 20 节。
建议每月用 45–60 分钟做一次组合评审，集中决定：哪些用例应该修复、扩大、暂停或退役；共享知识、工具和人员依赖是否产生风险；下月真正有能力启动哪些新场景。会议应以台账、指标、风险和阶段决策为输入，而不是以工具登录次数或 Token 消耗作为主要内容。模板见附录 A 第 21 节。
六、FDE / AI COE：把交付做成客户可接管的能力
FDE（Forward Deployed Engineer）或内部 AI COE 的价值，不是替业务团队长期“代运营 AI”，也不只是把一个 Demo 搭起来。其真正作用是把业务问题、技术实现、风险控制、评测与变革动作压缩到同一个短周期中，并在交付结束时让业务团队能够独立运行、修改、升级和停止该能力。
交付底线：外部顾问、FDE 或 AI COE 可以设计、辅导、搭建和加速，但不能长期替代客户方的业务 Owner、知识 Owner、审批人或日常使用者。没有客户方接棒责任的项目，不应宣称已完成“企业落地”。
1. 六阶段共创交付循环
| 阶段 | 关键问题 | FDE / AI COE 主要动作 | 客户/业务团队主要动作 | 最低产出与决策门 |
|---|---|---|---|---|
| 发现 | 值得解决的业务问题是什么？ | 访谈、观察、量化基线、识别候选用例和风险 | 提供真实任务、现有流程、约束与 Owner | 用例立项卡、初始风险筛查；决定设计/暂缓/不做。 |
| 共创设计 | 怎样以最低必要复杂度解决？ | 协助拆任务、定义 Skill/工作流、上下文包、工具控制和验证/回退 | 确认业务边界、知识与上下文来源、人工控制和成功/停止条件 | 工作流合约、上下文/知识/权限边界、工具控制卡、Golden Set 设计；决定开始试点。 |
| 试运行 | 在真实但受控的范围内是否可用？ | 搭建、调试、收集失败样本、辅导使用者 | 使用真实任务、完成核验、记录采用、来源/工具行为与异常 | Skill/Agent 资产、上下文/记忆/工具控制记录、周度记录、回归与风险控制证据；决定修复/限量运行/停止。 |
| 验收 | 是否达到约定的业务、质量与控制标准？ | 汇总证据、演示边界与回退、组织第二人复现 | 业务 Owner 核验结果，明确是否接收与后续范围 | 验收记录、发布登记、健康卡初版；决定接收/附条件接收/拒收。 |
| 移交 | 客户方能否不依赖交付者运行？ | 交接资产、权限、操作 SOP、培训与支持窗口 | 指定接棒 Owner，完成独立运行、变更和回退演练 | 移交清单、实践认证、接棒确认；决定进入客户运营或延长辅导。 |
| 退出/扩展 | 何时结束当前交付，何时开始下一个用例？ | 复盘、归档、移交遗留问题、提供组合建议 | 接管运营、决定扩大/暂停/退役/启动下一用例 | 退出/扩展记录、证据索引更新、下一阶段计划。 |
模板见附录 A 第 39–43 节。项目不必机械经历所有阶段或追求复杂文档；但不能跳过业务 Owner、风险边界、真实验证、验收或接棒能力。
2. 角色边界与共同责任
| 角色 | 应承担的责任 | 不应承担的责任 |
|---|---|---|
| 业务 Owner | 定义业务问题、成功/停止条件、范围、优先级和最终业务决定；指定具同等授权的替补 | 把业务判断、数据责任或风险接受永久外包给交付团队，或单独批准其无权处理的安全/技术例外。 |
| AI Champion | 促进采用、收集真实使用反馈、帮助员工找到正确 Owner 和受控入口 | 代替业务 Owner 接受结果，或以“推动落地”为由绕过数据、权限、对外或生产审批。 |
| 知识 Owner | 确认权威来源、更新时效、冲突处理与知识变更影响 | 让 FDE 自行解释企业规则或在缺少授权时决定口径。 |
| 上下文/记忆 Owner | 确认允许来源、选择逻辑、记忆目的、隔离、失效与纠错 | 把全量资料、完整会话或未经确认的推断默认为可复用记忆。 |
| FDE / AI COE | 共创工作流、资产化经验、搭建评测与控制、辅导第二人复现 | 在没有客户授权或接棒条件时把原型直接推入生产。 |
| 技术/安全 Owner | 管理集成、连接器、权限、数据流、配置、日志、熔断、运行与回退；在控制失效时先行停用其负责范围 | 代替业务 Owner 决定业务范围、对外承诺或价值判断，或在业务/风险授权缺失时自行恢复扩大后的运行。 |
| 风险/安全/法务等适用角色 | 对高影响数据、动作、对象和例外提供适用的审查与约束 | 为业务目标或模型选择作无边界的“全盘背书”。 |
3. 验收不是演示成功
演示中一次顺利运行不等于可以验收。验收应同时检查五类证据：业务问题与范围是否仍成立；Golden Set、回归和真实试运行是否达到约定的质量/采用/效率标准；上下文来源、记忆、工具/连接器、数据和权限是否受控且可追溯；人工接管和回退是否已验证；客户方是否完成第二人复现、能定位资产并独立处理基础变更和异常。
如果质量达标但接棒角色未准备好，应视为附条件接收，保留限量范围和支持窗口；如果业务 Owner、知识 Owner 或回退流程缺失，则不应通过正式移交。
4. 移交与退出的可验证标准
交付团队应以“客户能够做什么”而非“已交付多少文档”判断是否可以退出。最低标准包括：客户能定位用例立项卡、风险/影响评估、工作流合约、Skill/Agent 资产、上下文包、记忆合约、工具/连接器控制卡、事实卡、Golden Set、回归/发布记录和证据索引；指定 Owner 已完成实际任务、回退和基础变更的演练；客户能在不依赖交付团队口头解释的情况下完成一次运行与一次异常升级；遗留问题、支持边界和退出后联系机制已经书面说明。
七、本章行动清单
请在本周内完成以下动作：
- 为已跑通的最小闭环建立周度评测表格，并开始记录。
- 给正式使用的 Prompt、Skill 卡、上下文包、记忆合约、工具/连接器控制卡、检查清单和知识材料加上版本号。
- 明确该闭环的使用者、业务 Owner、AI Champion、Skill/流程责任人、修改权限人、知识 Owner、上下文/记忆 Owner、技术/安全 Owner 和 FDE/AI COE（如参与）；为每个关键角色写下决定权、不可替代动作、替补生效条件和无权决定事项；如含 Agent，再明确暂停/恢复权限人。
- 找到至少一名业务使用者和一名支持决策人，同步当前数据和下一步计划。
- 写出问题升级路径（什么情况找谁，多长时间内响应），并为 Agent 补齐来源冲突、工具异常、记忆错误、熔断与人工接管的回退说明。
- 当正式或试运行用例达到 3 个以上时，建立用例组合台账，并为每个用例记录业务 Owner、当前阶段和下一次决策日期。
- 约定第一次月度组合评审：使用质量、采用、成本、风险和共享依赖信息，决定扩大、修复、暂停或退役。
- 对照变革八阶段，确认当前组织处于哪个阶段，并补齐该阶段的产出物（例如：试点推广不动，先回到愿景与沟通，而不是继续加场景）。
完成以上动作后，最小闭环才具备长期运行的基础条件；多个用例也开始具备可持续经营的基础。
八、本章小结
长期可靠依赖三件事的同步到位：持续评测、基础治理、必要的组织协同。
评测提供客观依据，治理防止过程失控，组织协同确保问题和改进有人承接。先把当前闭环做稳，再考虑扩大范围。