第七章 变更与评估驱动
7.4 变更协商
承前：harness 与棘轮管住了技术侧的变更——改动跑评估，回退进不来。但变更的另一半战场在商务侧：评估拦得住代码，拦不住需求。新总监的"自动执行"只是开始：试点成功后，各干系人看到 Agent 真的好用，需求开始从四面八方涌来——运营要加话术风格，店长要加库存查询，副总裁要加预测报表……每一个听起来都"很小"。这一节讲 To B 项目的生命线：变更协商——怎么接需求不失控、不白干、也不伤关系。
7.4.1 需求膨胀是 AI 项目的宿命
先认清规律：AI 项目的需求膨胀不是意外，是系统性的。原因有三：
其一，AI 的能力边界模糊。传统软件"做不了"是技术事实（这个系统没有这个功能）；AI 系统"试试也行"是常态（改改 prompt 说不定就能做）。于是每个需求都显得触手可及，"顺便"成了最高频的需求开头词。
其二，demo 效应。试点成功展示了可能性，每个人都会立刻想到自己场景的版本——这是好现象（第 4 章 demo 内循环的目的就是激发它），但激发出来的每一分热情最终都会转化成工单。
其三，新干系人的政治需求。空降的数字化总监需要快速产出证明自己；各部门负责人要在新系统里留下自己的印记。政治动机驱动的需求，技术评估是拦不住的——要靠商务机制。
青禾沙盘在试点成功后的六周里收到了 23 条新增需求。不加管理的结果可以预见：交付范围失控、团队疲于奔命、SOW 里的核心目标（复购率）反而没人管——最后烂尾，且甲方乙方互相埋怨。变更协商就是防止这个结局的机制。
7.4.2 变更单：把"口头需求"变成"结构化对象"
第一件武器是变更单（Change Order）。任何想进入交付范围的新需求，无论多小，都要走一张单子：
变更申请单（青禾沙盘 · 示例）
变更编号：CO-2026-007
提出人：店长代表（15 家门店联名）
需求描述：Agent 支持库存查询——"查一下 3 号店鸡蛋还剩多少"
业务动机：店长晚班补货决策，现在要开另一个系统查，麻烦
─────────────────────────────────────────────
影响评估（乙方填写）：
数据边界：新增库存系统数据源，需过字段级分级（6.1 节流程）
评估影响：黄金集 +8 用例，异常集 +4，对抗集 +2；约 3 人天建用例
开发影响：新工具注册+权限矩阵加列，约 5 人天
回归风险：工具数量从 6→7，工具选择用例存在选择偏移风险，全量回归必跑
总代价：约 9-10 人天 + 一次全量评估
─────────────────────────────────────────────
处理选项：A 并入本月迭代（需置换：话术风格优化延后）
B 下一迭代（排队第 3 位）
C 商务加购（SOW 外新增，按人天计价）
决策：____（甲方数字总监签字）这张单子有四个设计意图：需求必须写清楚动机（"店长觉得麻烦"和"店长每天损失销售"是两个不同量级的需求——写动机的过程本身就是一次需求审视）；影响评估量化到人天和评估用例数——这是 7.2/7.3 节的直接产出，评估集让"影响"从形容词变成数字；给出处理选项而非只有接受/拒绝——置换（trade）是核心机制，详见下节；甲方签字——变更一旦被记录和签署，就不再是"你们当初不是答应过吗"的罗生门。
7.4.3 核心机制：免费需求的三种合法出口
变更单拦住需求之后，真正的协商发生在处理选项上。FDE 手里合法的出口有三种，缺一个都会失控：
出口一：置换（Scope Trade）。 迭代容量是固定的，新需求进来，旧需求出去。这是管理"免费新增"最有力的机制：不是拒绝，是让提出人看见机会成本——"可以加库存查询，那话术优化延后两周，选哪个？"大多数"顺便"级需求在这一问面前会自动退场，因为提出人第一次被迫为自己的需求排了优先级。注意置换要在迭代会上公开进行，让机会成本被全员看见——私下的置换会退化成人情交易。
出口二：排队（Backlog）。 真实但不紧急的需求进正式需求池，按业务价值排序，在下一次迭代规划时竞争容量。排队不是拖延话术：要给排队项一个明确的再评估时间（"下次迭代规划会是 10 月 20 日"），否则它会从后门变成怨恨。
出口三：商务加购（Paid Change）。 需求真实、紧急、但超出合同容量——那就按 SOW 的变更条款走付费。这不伤关系，恰恰是专业：第 3 章 SOW 模板里我们预留过变更流程条款（变更触发条件、计价单位、双方签字），现在兑现。白送才是伤关系的：白送的需求质量没保障（没有评估用例预算），且建立了"哭闹就能免费加"的先例——第二次你就没法收费了。
这三种出口合起来构成一个原则：每个需求都有去处，但没有需求可以免费插队。协商的艺术不在拒绝，在于让"代价"可见。
7.4.4 协商五步法：影响→方案→代价→选项→决定
把日常协商动作固化成五步，避免被现场热情裹挟：
- 评估影响（用 harness 和评估集说话）：这个变更动哪些用例、预计跑几轮回归、几人天。绝不在没有影响数字的情况下答复任何需求——"我回去评估一下"不是推脱，是纪律。
- 提出方案：给出实现路径，包括更便宜的替代（店长要库存查询，也许一个"库存快照卡片推送到企业微信"比 Agent 对话工具便宜十倍——需求背后的动机往往有比字面需求便宜的解法）。
- 报出代价：人天、评估影响、排期挤压，透明到让甲方能做决策。
- 给出选项：置换/排队/加购三选一，附你的建议排序。
- 甲方决定并签字：变更单归档，进 SOW 附件。
五步法里最容易被跳过的是第 1 步和第 4 步。跳过第 1 步（当场答应"可以做"），你就把影响评估的权力送了出去——等发现工作量是预估三倍时已经无法回头；跳过第 4 步（只报代价不给选项），协商退化成"贵不贵"的讨价还价，而你失去的是把需求导入健康出口的机会。
7.4.5b 变更协商的心理战：三种难缠场景的标准接法
五步法是骨架，真实协商里还会遇到三类高压场景，各有标准接法：
场景一：高层当众拍板。 月度会上副总裁当着所有人的面说"下个月我要看到报表功能"。当场反驳是灾难（权力面前唱反调），当场答应也是灾难（跳过影响评估）。标准接法一句话："没问题，会后我们出影响评估，周五给您两个可选方案。"——把"承诺结果"和"承诺评估"分开，前者你没资格当场给，后者你永远可以给。会后走完五步法，方案呈上，决策权还给对方，但要附上你的建议。九成情况下高层要的是"这事有人管、有节奏"，而不是"这个月必须上"。
场景二：哭诉式加需求。 一线对接人私下找你："哥，这个功能不加我们真没法用，帮帮忙，很小的改动。"情面压力极大，且"很小"往往是错觉。标准接法：共情+通道引导——"理解，这个需求听起来真实。我把它记进变更单，今天给你排进评估，本周五告诉你代价和排队位置。"关键是不承诺做，但承诺认真对待。被认真对待的需求提出者，多数能接受排队结果；偷偷白送才是对其他排队者的不公平。
场景三：需求伪装成 bug。 "这个不算新需求，是你们系统没做好——我要的是它本来就该有的能力。"这是最难缠的，因为 SOW 边界解释权在打架。标准接法：回到 SOW 验收标准逐条对照——写进验收标准的，是 bug，无条件修（进异常集，防复发）；没写的，按"合理期望"判断：明显合理的低代价期望（话术里日期格式统一）当 bug 顺手修掉攒信用；大代价的（全新报表能力）走变更单。这条边界要事先和客户项目经理对齐裁量尺度，否则每次现场扯皮都在消耗信任。
三个场景的共性：协商不靠嗓门也不靠忍让，靠把压力转译进流程。流程接得住压力，关系就保得住。
7.4.6 沙盘高潮：与新总监的"自动执行"最终协商
回到本章主线——新总监的"自动执行"指令，现在用五步法正式走一遍，作为收口：
影响评估：放开外呼全自动执行，对抗集需新增"误外呼熔断""投诉后停止""时段管制"三类共 14 条用例；黄金集外呼链路用例权重上调；预估 12 人天建设+两轮全量回归。风险项（据 7.1 节演示）：当前系统在异常外呼场景存在真实失败用例，直接放权等于把已知缺陷推向真实客户。
方案：分三阶段放权——第一阶段"高置信度会员全自动+每日额度上限"，第二阶段扩大人群并加实时熔断，第三阶段才到总监要的全无人值守。每阶段的进入条件绑定 7.2 节的升级门。
代价：除开发人天外，一阶段需要安全部门单独审批外呼策略变更（6.5 节的变更流程），预计两周流程时间。
选项：A 按三阶段走（乙方建议）；B 直接全放开，乙方书面提交风险备忘录后执行（技术上有这条路，但对抗集现状不达标，需走例外流程并报备双方高层）；C 暂缓。
总监选了 A，但要求把每阶段的通过率周报直接发他。三个月后二阶段达标，他在周报上批复"三阶段提前启动"——注意最终结局：他要的"自动执行"拿到了，且比强推的版本早拿到（B 方案大概率在第一次客户投诉事故后被全公司叫停）。这就是变更协商的真相：它不是给客户踩刹车的，是帮客户把油门踩得更稳的。
7.4.8 常见坑
- 变更口头化："会上说好了"不算变更，没进变更单的需求一律视为未发生。
- 影响评估拍脑袋：当场答应的工作量预估，90% 低估——大模型系统的改动有全局副作用，这是 7.3 节棘轮存在的原因，影响评估必须跑数据。
- 只报代价不给出口：把协商变成涨价谈判，赢了单次输了关系；永远带着置换/排队/加购三个选项进场。
- 白送买关系：免费加的需求没有评估预算，质量事故反噬信任；先例一开，后续所有需求都免费。
- 忘了内部变更也是变更：模型升级、数据源变更同样影响客户承诺——7.3 节已讲，对客户都是变更事件，要走沟通。
7.4.9 要点总结
- AI 项目需求膨胀是宿命（能力边界模糊、demo 效应、政治动机），变更协商是生命线而非官僚流程。
- 变更单把口头需求变成结构化对象：动机、影响评估（人天+评估用例数）、处理选项、甲方签字。
- 免费新增的三个合法出口：置换（让机会成本可见）、排队（给明确再评估时间）、商务加购（兑现 SOW 变更条款）——每个需求都有去处，但没有需求能免费插队。
- 协商五步：评估影响→提出方案（含更便宜的替代）→报出代价→给出选项→甲方签字决定。
- 变更协商不是踩刹车，是帮客户把油门踩稳：分阶段放权+升级门绑定，让"自动执行"以更安全的方式更快落地。
参考资料
- OpenAI 官方：Morgan Stanley uses AI evals — 分阶段建立信任、评估先行再扩大授权的一手案例（7.5 节详述）
- OWASP Top 10 for LLM Applications 2025 — 变更影响评估中安全侧（对抗集扩容）的参照
- openai/evals（GitHub） — 变更触发全量回归的工程支撑参照
- Anthropic 官方客户故事：Novo Nordisk — 强监管场景下分阶段扩大 AI 职权、人保留签署权的对照案例（第 6 章 6.5 节）