第 8 章 从 1 到 N：多场景扩展与优先级管理
第 6 章帮你跑通了第一个最小闭环。恭喜——这是最难的一步。
但接下来很多团队会陷入一个新的困境：第一个场景能稳定运行了，下一步扩展什么？是并行推进多个场景，还是深耕一个？怎么判断哪个场景值得投入？扩展过程中如何避免让已有的稳定闭环被破坏？
这一章回答“从 1 到 N”的问题。
一、为什么“从 1 到 N”比“跑通第 1 个”更难
跑通第一个闭环，成功的关键因素往往是：有一个愿意推动的负责人、场景足够简单、团队处于试点阶段因此容错空间较大。
扩展到多个场景时，情况完全不同：
- 没有了试点的宽容度：第一个场景是探索，第二第三个场景开始被当成“正式的”，对稳定性要求更高
- 资源开始分散：同时维护多个工作流，时间和注意力被分摊
- 依赖关系变复杂：不同场景可能共用知识库、检索器、上下文模板、工具/连接器或记忆策略，一处改动可能影响多处
- 成功经验不能直接复制：第一个场景的成功路径，在新场景中不一定适用
因此，扩展需要一个有意识的策略，而不是“第一个成了就赶快推第二个”。
二、扩展前的检查：第一个闭环是否真正稳定
在考虑扩展之前，先诚实回答以下问题：
| 检查项 | 判断标准 | 你的情况 |
|---|---|---|
| 一次通过率 | 连续 4 周，每周 ≥ 80%（建议目标） | |
| 实际采用率 | 最终被直接或小改后使用的比例 ≥ 70% | |
| 维护负担 | 每周花在维护上的时间 ≤ 2 小时 | |
| 知识与上下文责任 | 有明确的人负责知识、上下文包、提示词、检索或工具描述的更新 | |
| 回退能力 | 出问题时能在 10 分钟内切回人工流程 | |
| 文档完整 | 新人可以凭文档独立操作，不需要原始搭建者讲解 |
如果有两项以上不达标：不要扩展，先加固第一个闭环。一个真正稳定的闭环，比三个“勉强能用”的闭环更有价值。
三、场景优先级矩阵：下一个扩展什么
通过了上面的检查，可以开始评估候选场景。用以下三个维度进行评分（各 1~5 分）：
维度 1：业务价值（每周能节省多少时间/提升多少质量）
| 分数 | 标准 |
|---|---|
| 5 | 每周节省 5 小时以上，或直接影响收入/客户满意度 |
| 4 | 每周节省 3~5 小时，或显著提升高频工作的质量 |
| 3 | 每周节省 1~3 小时，或在特定场景改善质量 |
| 2 | 节省时间少于 1 小时，或价值难以量化 |
| 1 | 价值主要是便利性，对业务结果影响极小 |
维度 2：实施难度（任务定义是否清晰，知识是否就绪）
| 分数 | 标准 |
|---|---|
| 5（难度最低） | 任务规则明确，知识材料完整，有现成模板可参考 |
| 4 | 规则基本清晰，知识材料需要小幅整理 |
| 3 | 规则有一定模糊性，需要设计验证机制 |
| 2 | 规则复杂或存在争议，知识材料需要大量准备 |
| 1（难度最高） | 规则高度依赖人工判断，或需要大量定制化开发 |
维度 3：知识就绪度（所需知识是否已经整理完毕）
| 分数 | 标准 |
|---|---|
| 5 | 现有文档完整、准确、已有负责人 |
| 4 | 文档基本完整，需要小幅补充和整理 |
| 3 | 文档存在但需要较多整理和更新 |
| 2 | 知识主要存在人员脑海中，需要大量提炼 |
| 1 | 知识缺失严重，需要从头建立 |
优先级计算
综合得分 = 业务价值 × 0.5 + 实施难度 × 0.3 + 知识就绪度 × 0.2
得分越高，越应该优先扩展。
实用规则：
- 得分 ≥ 4：优先扩展，可以立即启动
- 得分 3~4：等当前场景更稳固后启动
- 得分 < 3：暂缓，重新评估是否值得投入
四、扩展节奏控制
同时进行不超过 2 个新场景
这是最容易被忽视的约束。同时推进太多场景的常见后果：
- 每个场景都没有足够的关注度，无法快速发现和解决问题
- 当问题出现时，无法判断是哪个场景的问题，排查困难
- 团队精力分散，维护负担在不知不觉中超出承受能力
建议节奏： 第一个闭环稳定运行满 4 周后，启动第二个。第二个进入稳定期后，再考虑第三个。不要在第二个还在磨合期时就启动第三个。
新旧场景的资源隔离
在新场景的前 3 周，应该将它和已有稳定场景的资源（知识库、负责人时间）做一定程度的隔离：
- 使用独立的知识库或知识库分区，避免新场景的调试影响旧场景
- 新场景有专门的负责人，不要让同一个人同时负责维护旧场景和搭建新场景
- 在新场景稳定前，明确标注它处于“试运行”状态，出错走手工回退
五、跨场景的知识与上下文复用策略
当有多个场景在运行时，知识的复用和隔离是最关键的架构决策。对于 Skill 和 Agent，还必须决定哪些上下文资产可以共享：权威知识、术语、检索器、上下文包模板、工具描述、连接器、记忆策略和评测集都可能成为组合级依赖。共享不等于默认开放；每个用例仍应通过自己的上下文包明确来源、权限、用途、版本和失效条件。
三类知识的处理方式
通用型知识（所有场景共用）
例如：公司基本信息、品牌声音和措辞风格、通用格式规范。
处理方式：放入“共享知识库”，所有场景的提示词直接引用。更新时所有场景同步更新（注意：这也意味着更新错误会影响所有场景，更新前必须充分测试）。
场景专属知识（仅某场景使用）
例如：客服场景的常见问题库、合同场景的审核规则。
处理方式：放入该场景的独立知识库，独立维护，不与其他场景混用。
半共用知识（部分场景共用）
例如：产品知识可能被客服场景和销售场景共用，但两个场景的使用方式不同。
处理方式：在共享知识库中维护核心事实，在各场景的提示词中加入“如何使用这些知识”的具体指令。避免在每个场景的知识库中各自维护一份，否则会出现内容不同步的问题。
共享上下文与工具资产的处理方式
共享上下文资产通常包括：统一术语与实体定义、检索索引、来源分级规则、上下文包模板、工具/MCP 描述、可复用的只读查询、记忆策略和 Golden Set。它们应被当作产品化的公共能力维护，而不是散落在各 Agent 的系统提示中。
| 资产 | 可共享的前提 | 不应共享的情形 | 最低控制 |
|---|---|---|---|
| 权威知识与术语 | Owner、版本、生效范围和数据边界已明确 | 不同部门的规则含义、适用对象或保密级别不同 | 来源登记、版本、访问范围和变更回归 |
| 检索器与上下文模板 | 返回字段、过滤条件、权限与用途可配置 | 同一检索会暴露跨客户、跨区域或敏感资料 | 用例级上下文包、过滤、返回量与审计 |
| 工具/MCP/连接器 | 身份、最小权限、动作、错误处理和退出方式已验证 | 写入、发送、代码执行或外网访问风险不同 | 工具控制卡、环境隔离、审批、熔断与回退 |
| 记忆与工作笔记 | 明确对象、目的、保留期、隔离与删除规则 | 跨用户、跨客户或未经确认的推断 | 记忆合约、来源定位、纠错和失效 |
| 评测集与 Rubric | 任务质量标准具有可比性 | 业务决策标准、数据权限或风险后果不同 | 样本分级、去标识化、用例级补充与版本管理 |
知识变更的影响评估
每次更新共享知识库时，先做影响评估：
- 列出所有使用这部分知识、上下文包、检索器、工具/连接器或记忆的用例、Skill、工作流和 Agent。
- 根据变化风险选择回归样本：至少覆盖正常、边界和历史失败样本；对外、高影响或高自主性用例还应验证来源选择、转人工、回退、权限、工具异常和记忆行为。
- 更新版本号，记录变更内容、受影响资产、回归结果和发布决定。
- 如果有任何场景出现无法解释的退化、规则冲突或高影响风险，立即回退或限量运行，单独排查。
附录 A 第 15 节提供通用变更影响记录；客户沟通类知识变更可参照附录 A 第 17 节。
六、从多个场景到用例组合运营
当团队同时运行多个 Skill、工作流或 Agent 时，管理对象不再是“几个独立小项目”，而是一个共享资源、共享知识和共享风险的用例组合。此时，最危险的做法是只统计“做了多少个 Agent”或“有多少人使用工具”；真正应被经营的是每个用例的业务价值、控制状态、维护负担和下一步决策。
1. 用例组合的六种状态
建议为每个用例标记候选、试点、限量生产、受控生产、规模化或退役状态。状态不是成熟度竞赛，而是告诉组织该用例目前可以承担什么范围的工作、还缺哪些证据、何时需要再次决策。
| 状态 | 管理重点 | 常见误区 |
|---|---|---|
| 候选 | 问题是否真实、是否值得投入、谁愿意负责 | 从工具能力或高管灵感倒推场景 |
| 试点 | 最小闭环能否稳定、失败是否可解释和可回退 | Demo 成功一次就宣布上线 |
| 限量生产 | 在受控人群、范围或问题类型中验证真实价值 | 不记录人工审核、异常和维护成本 |
| 受控生产 | 责任、版本、知识、评测和回退是否持续有效 | 把“上线”误认为项目结束 |
| 规模化 | 跨团队复用后能否保持质量、共享依赖是否可控 | 复制 Prompt 却不复制责任和验证机制 |
| 退役 | 价值、风险、成本或替代方案是否仍支持继续运行 | 将低价值用例长期留在生产环境无人维护 |
完整进入条件、退出证据和决策卡见附录 A 第 20 节。任何用例都可以因风险、价值或维护问题从较高状态降级、暂停或退役；这不是失败，而是组合管理正常发挥作用。
2. 组合运营的三个最小资产
当正式或试运行用例达到 3 个以上，至少建立以下三项资产：
| 资产 | 解决的问题 | 最低使用方式 |
|---|---|---|
| 用例组合台账 | 现在运行什么、谁负责、依赖什么、处于什么状态 | 每个用例一行；阶段、Owner、关键指标和下一决策必须最新 |
| 阶段决策记录 | 为什么扩大、暂停、回退或退役 | 每次阶段变化、重大事件或高影响变更后更新 |
| 月度组合评审 | 有限资源优先投向哪里；哪些风险和共享依赖需要协调 | 用数据决定投入、修复、停止或延后，而不是汇报工具使用量 |
| 共享上下文与工具登记 | 哪些来源、检索、工具、连接器、记忆和评测资产被哪些用例复用 | 记录 Owner、范围、版本、权限、变更影响与退出方式 |
附录 A 第 18、20、21 节提供可直接复制的台账、决策卡和月度组合评审模板。
3. 规模化前必须问的四个问题
第一，业务价值是否已被验证，而不只是有人觉得好用？ 第二，知识、上下文包、检索、工具/连接器、记忆、权限、模型或平台变化时，是否知道影响哪些用例并能回归验证？ 第三，第二个团队能否在不依赖原始搭建者的情况下运行和维护？ 第四，停止或回退时，业务是否仍有可用的人工或替代流程？
若其中任一问题没有明确答案，就不应把“扩展到更多部门”视为当前优先事项；应先修复用例本身或共享资产的薄弱点。
七、跨部门场景的协调机制
当 AI 工作流扩展到多个部门时，往往会出现：各部门各自为政、重复建设、或者相互冲突的情况。以下是避免这些问题的实用机制：
建立场景登记制度
简单来说：任何部门启动新的 AI 场景时，需要在一个共享的文档中登记：
- 场景名称和负责人
- 使用的知识库、上下文包、检索器、工具/连接器和记忆（是否与其他场景共用）
- 当前状态（试运行/稳定运行）
- 主要的 Prompt、上下文包、工具和模型版本号
这个登记不是为了审批，而是为了让各部门能了解彼此在做什么，避免重复建设。
知识库责任人制度
对于跨部门共用的知识（如产品信息、政策文件），明确指定一个知识责任人（通常来自最依赖这份知识的部门），其他部门如需修改，通过该责任人协调。
季度场景健康检查
每季度做一次跨部门的场景健康检查：
- 各场景的一次通过率和采用率
- 哪些场景在退化，原因是什么
- 哪些知识库、上下文包、检索器、工具/连接器或记忆需要更新、限量或退役
- 下个季度计划新增哪些场景，是否有资源支撑
八、何时该停止扩展、回头加固
扩展不是目的，稳定才是。以下信号提示你应该暂停扩展、回头加固：
警示信号 1：维护时间超过使用时间 如果团队每周花在“修复 AI 问题”上的时间，超过了“使用 AI 节省的时间”，说明系统正在变成负担。
警示信号 2：知识债务积累 提示词越来越长，规则越来越多，新加的规则和旧规则开始冲突。这是知识债务积累的典型表现。需要停下来做一次“提示词重构”（精简、消除冲突、重新测试）。
警示信号 3：一次通过率持续下降 某个场景的一次通过率连续 3 周下降，且找不到明显原因（没有业务规则变化，没有提示词修改）。这通常是知识库过期或模型行为变化的信号，需要深入排查。
警示信号 4：团队失去对系统的掌控感 如果团队成员开始说“不知道为什么 AI 有时候这样输出，有时候那样输出”，说明系统已经超出了团队的可管理范围。不要继续扩展，先让系统变得可理解、可预测。
九、本章行动清单
启动扩展之前：
- [ ] 完成“第一个闭环是否真正稳定”的 6 项检查，确认全部达标
- [ ] 列出所有候选场景，用优先级矩阵评分
- [ ] 确认有足够的人力资源支撑新场景（不能全靠现有负责人兼顾）
扩展过程中：
- [ ] 同时在运行中的新场景不超过 2 个
- [ ] 新场景使用独立知识库，3 周稳定后再考虑知识共用
- [ ] 每周记录新场景的一次通过率，与第一个场景对比
跨部门协调：
- [ ] 建立场景登记文档，所有部门的 AI 场景统一登记
- [ ] 对跨部门共用的知识库、上下文资产和工具/连接器，指定相应 Owner 与变更影响分析责任人
- [ ] 计划第一次季度健康检查的时间
本章小结
从 1 到 N 的关键不在于扩得多快，而在于每一个新场景都能达到和第一个一样的稳定水平。
优先级矩阵帮你选择下一个扩展什么；节奏控制帮你避免资源分散；知识复用策略帮你减少重复建设；警示信号帮你在系统失控之前及时刹车。
最后要记住：5 个稳定运行的场景，比 15 个勉强能用的场景更有价值。