第 12 章 让结果长期可靠：评测、治理与组织协同
最小闭环跑通后，下一步是让它在真实组织环境中持续稳定运行，而不是用一段时间后逐渐失效。 本章提供可直接执行的方法，覆盖三个关键问题：如何持续评测效果、如何做基础治理、如何推动必要的组织协同。
一、建立简单有效的评测机制
没有评测，就无法判断工作流是否在变好还是在变差。
1. 必做的基础评测（每周一次，15–20 分钟）
针对已上线的最小闭环，固定记录以下数据：
| 评测项 | 记录内容 | 建议目标（基于实践经验） |
|---|---|---|
| 通过率 | 本周总次数中，一次通过验证清单的比例 | ≥80% |
| 平均总耗时 | 生成+人工检查的平均时间 | 比原方式下降≥30% |
| 主要失败类型 | 本周最常见的 1–2 个问题 | 每周下降或保持稳定 |
| 实际采用率 | 最终被直接使用或小改后使用的比例 | ≥75% |
用共享表格记录即可，不必上复杂系统。
2. 每月一次的深度回顾（30–45 分钟）
每月固定时间回答以下问题：
- 本月通过率、耗时、采用率是否达到目标？
- 失败案例中，哪些是 Prompt 问题，哪些是知识/数据问题，哪些是 Skill 定义、流程或 Agent 运行问题？
- 是否需要更新 Prompt、Skill 卡、上下文包、检查清单、知识内容、记忆、状态逻辑、工具/连接器或权限配置？
- 最近是否发生模型、工具、连接器、知识、上下文、记忆、权限或 Agent 运行逻辑变更；是否需要回归评测？
把结论写成简短记录，作为下月改进依据。
3. 评测结果的使用规则
- 通过率连续两周低于 70%：立即暂停扩大范围，先修复当前闭环。
- 耗时下降不明显：检查是否验证环节过重，或提示词产生了过多需要修改的内容。
- 采用率低：说明输出虽然“能过检查”，但业务上仍不好用，需要补充业务侧标准。
二、基础治理动作（必须落地的部分）
治理不需要一开始就做得很重，但以下五项必须明确并执行。
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
每个被 AI 调用的核心知识内容应指定知识 Owner；每个正式上下文包、持久记忆和工具/MCP/连接器还应指定相应的上下文、记忆或技术 Owner。一个人可以兼任多个角色，但不能让“大家都负责”替代明确责任。
| Owner | 最低职责 |
|---|---|
| 知识 Owner | 确认权威来源、业务规则、生效范围、冲突和失效；业务规则变化后完成更新与影响说明。 |
| 上下文/记忆 Owner | 维护来源白名单、选择逻辑、排除来源、记忆类别、隔离、保留期、失效和纠错规则。 |
| 工具/连接器 Owner | 维护用途、接口、参数、返回量、身份权限、日志、异常、禁用和退出方式。 |
| 用例/Skill/Agent Owner | 确保上述资产与业务边界、评测、审批、回退和发布决策保持一致。 |
4. 变更与回归责任
规则、上下文包、检索、记忆、工具/连接器、模型、权限或状态逻辑发生变化时，应由对应 Owner 发起影响分析；用例 Owner 确认业务边界；技术与风险角色按影响参与评测、审批、发布或回退。低风险内部改动可以轻量记录，高影响或跨系统变化必须使用附录A的上下文、工具和回归资产。
5. 问题升级路径
当出现以下情况时，必须升级处理：
- 连续出现同类严重错误
- 输出可能影响客户或正式决策
- 有人绕过验证清单直接使用结果
升级对象和建议处理时限提前写清楚。
三、组织协同的具体推进方法
美团的经验也印证了这一点：从无序全员尝试，到事业部成立 AI 组织、赛马梳理方法，再到流程中真正跑通，用了约半年时间，最终确认必须把业务、组织、技术同步推进，而不能只寄望于产研团队。 稳定产出最终需要跨角色配合。以下是可执行的推进步骤。
步骤 1：找到最小支持联盟（1 周内完成）
识别三类人并获得明确支持：
- 业务侧使用者（真正跑任务的人）——至少 1 名
- 内容/知识责任人（能更新相关材料的人）——至少 1 名
- 有资源决策权的人（能支持时间或工具的人）——至少 1 名
与他们分别沟通一次，确认他们愿意在当前最小闭环上投入时间。
步骤 2：用数据而不是感受推动
每周把评测表格的关键数字同步给支持联盟。只同步数字和主要问题，不扩展讨论。 当数据连续表现稳定时，再提出下一步（增加场景或减少人工检查比例）。
步骤 3：明确各方的具体责任
用一页纸写清楚：
| 角色 | 每周固定动作 | 出问题时应做的事 |
|---|---|---|
| 使用者 | 按模板或 Skill 卡执行并完成检查 | 记录失败案例，必要时转人工 |
| 知识责任人 | 响应知识更新请求 | 在约定时间内完成更新，并确认影响范围 |
| 上下文/记忆责任人 | 维护来源、选择逻辑、隔离、失效和纠错 | 处理过期、冲突、越权、污染或状态异常 |
| Skill/流程责任人 | 查看质量、采用、耗时与变更记录 | 决定修复、回退或暂停当前能力 |
| 技术/工具责任人（如适用） | 维护工具、连接器、权限、日志、熔断与运行状态 | 处理运行异常，验证人工接管与恢复 |
| 支持决策人 | 查看周度数据和重要风险 | 决定是否扩大、提高自主等级或调整资源 |
步骤 4：控制推进节奏
- 当前闭环通过率稳定在 80%以上，再增加第 2 个场景。
- 同一时间只推进 1–2 个闭环，避免同时铺开多个导致无法兼顾。
- 任何新场景都必须先完成第 6 章的最小闭环步骤，再进入本章的评测与治理。
四、从单个闭环到多个用例的最小组合治理
当团队只有一个最小闭环时，周度记录、明确责任人与问题升级路径已经足够。当正式或试运行用例达到 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 | 定义业务问题、成功/停止条件、范围、优先级和最终业务决定 | 把业务判断、数据责任或风险接受永久外包给交付团队。 |
| 知识 Owner | 确认权威来源、更新时效、冲突处理与知识变更影响 | 让 FDE 自行解释企业规则或在缺少授权时决定口径。 |
| 上下文/记忆 Owner | 确认允许来源、选择逻辑、记忆目的、隔离、失效与纠错 | 把全量资料、完整会话或未经确认的推断默认为可复用记忆。 |
| FDE / AI COE | 共创工作流、资产化经验、搭建评测与控制、辅导第二人复现 | 在没有客户授权或接棒条件时把原型直接推入生产。 |
| 技术/工具 Owner | 管理集成、连接器、权限、数据流、配置、日志、熔断、运行与回退 | 代替业务 Owner 决定业务范围、对外承诺或价值判断。 |
| 风险/安全/法务等适用角色 | 对高影响数据、动作、对象和例外提供适用的审查与约束 | 为业务目标或模型选择作无边界的“全盘背书”。 |
3. 验收不是演示成功
演示中一次顺利运行不等于可以验收。验收应同时检查五类证据：业务问题与范围是否仍成立；Golden Set、回归和真实试运行是否达到约定的质量/采用/效率标准；上下文来源、记忆、工具/连接器、数据和权限是否受控且可追溯；人工接管和回退是否已验证；客户方是否完成第二人复现、能定位资产并独立处理基础变更和异常。
如果质量达标但接棒角色未准备好，应视为附条件接收，保留限量范围和支持窗口；如果业务 Owner、知识 Owner 或回退流程缺失，则不应通过正式移交。
4. 移交与退出的可验证标准
交付团队应以“客户能够做什么”而非“已交付多少文档”判断是否可以退出。最低标准包括：客户能定位用例立项卡、风险/影响评估、工作流合约、Skill/Agent 资产、上下文包、记忆合约、工具/连接器控制卡、事实卡、Golden Set、回归/发布记录和证据索引；指定 Owner 已完成实际任务、回退和基础变更的演练；客户能在不依赖交付团队口头解释的情况下完成一次运行与一次异常升级；遗留问题、支持边界和退出后联系机制已经书面说明。
六、本章行动清单
请在本周内完成以下动作：
- 为已跑通的最小闭环建立周度评测表格，并开始记录。
- 给正式使用的 Prompt、Skill 卡、上下文包、记忆合约、工具/连接器控制卡、检查清单和知识材料加上版本号。
- 明确该闭环的使用者、业务/Skill 责任人、修改权限人、知识 Owner、上下文/记忆 Owner 和技术/工具 Owner；如含 Agent，再明确暂停/恢复权限人。
- 找到至少一名业务使用者和一名支持决策人，同步当前数据和下一步计划。
- 写出问题升级路径（什么情况找谁，多长时间内响应），并为 Agent 补齐来源冲突、工具异常、记忆错误、熔断与人工接管的回退说明。
- 当正式或试运行用例达到 3 个以上时，建立用例组合台账，并为每个用例记录业务 Owner、当前阶段和下一次决策日期。
- 约定第一次月度组合评审：使用质量、采用、成本、风险和共享依赖信息，决定扩大、修复、暂停或退役。
完成以上动作后，最小闭环才具备长期运行的基础条件；多个用例也开始具备可持续经营的基础。
七、本章小结
长期可靠依赖三件事的同步到位：持续评测、基础治理、必要的组织协同。 评测提供客观依据，治理防止过程失控，组织协同确保问题和改进有人承接。先把当前闭环做稳，再考虑扩大范围。