4 石头做的汤和煮熟的青蛙

用可见原型降低参与门槛，同时用全景指标和停止条件防止渐进改造失去方向。

学习目标

能把“4 石头做的汤和煮熟的青蛙”拆成愿景、可见原型、参与、增量变化和全景复核
能用“提示6：做推动变革的催化剂”设计一个可丢弃、可观察且能降低参与成本的最小展示
能用“提示7：牢记全景”监测范围漂移、用户影响、系统风险和团队负担，并在越界时停止或回退

为什么 4 石头做的汤和煮熟的青蛙要一起学习

“石头做的汤”讲的是如何让变化开始：先做一个看得见的最小成果，让参与者能够讨论具体行为，而不是围绕抽象愿景争论。“煮熟的青蛙”讲的是变化开始后如何不丢失全景：小步累积并不天然安全，范围、成本和风险可能在没有一次明显故障的情况下持续上升。

两种寓言合在一起，形成一个完整协议：先用小而可丢弃的原型催化协作，再用全景指标检查增量是否仍服务目标。原型不是承诺，增量不是默认正确，参与者的兴奋也不能替代用户结果和停止条件。

Catalyst Prototype 的价值是启动对话和学习，不是偷偷把试验变成既成事实。

Participation Cost 越高，团队越可能只让少数人掌握变化，后续阻力和误解也越大。

Scope Drift 不一定表现为一个大故障，可能表现为“顺便再加一个字段”“先给另一个团队复用”或“临时旁路变成正式流程”。

Panorama Check 不是让所有人参加所有会议，而是定期问局部优化改变了谁的工作、哪项风险和哪条依赖。

Stop Rule 让“保持灵活”有可执行的边界，尤其适用于数据、权限、合规和不可逆迁移。

从愿景到可见原型

愿景必须有观察点

愿景不能只写“让团队更敏捷”或“提高协作”。它要说明谁的哪项工作会改变，用户结果是什么，当前痛点如何被观察，以及什么结果会让团队拒绝当前方向。

原型要可丢弃

提示6：做推动变革的催化剂不是让某个人偷偷替团队决定，而是先做一个足够小的 Catalyst Prototype。原型可以是模拟流程、一次非关键数据试验、一个可回滚的工具链或一张真实决策板；它必须有范围、所有者、到期时间和回退。

降低参与成本

邀请参与者时要提供上下文、操作路径和反馈方式。Participation Cost 包括学习新工具、迁移旧数据、暴露风险和承认不确定性的成本。原型越容易观察和退出，越有机会得到真实反馈，而不是礼貌同意。

先预测：一个原型演示很受欢迎，最可能仍然隐藏的是范围漂移、维护成本、用户影响还是权限风险？写下优先级，再安排第一次 Panorama Check。

从增量到全景复核

识别慢变化

提示7：牢记全景要求观察那些不会在单次演示中出现的变化：依赖数量增加、手工步骤扩张、数据保留时间变长、用户群扩大、团队疲劳或回滚变难。

让范围变化可见

每次增量都记录原始范围、新增范围、受影响者、成本、依赖、用户承诺和 Stop Rule。没有这张记录，团队很容易把“只是顺手”当成没有决策的决定。

全景复核要能改变方向

Panorama Check 不是展示成果的庆功会。发现 Scope Drift、用户价值下降、风险转移或参与成本上升时，应缩小试验、暂停扩展或回退，即使局部指标仍然好看。

催化原型与全景边界

提示6要求用可见、可丢弃的原型催化真实参与，而不是用演示替别人批准变化。

可见原型的链条是 愿景 → Catalyst Prototype → 低成本参与 → 真实反馈 → 下一步增量。每个节点都要有退出方式。一个原型如果只有成功路径，没有用户拒绝、权限失败或数据恢复，就不是催化学习，而是在提前承诺。

三步渐进变化路径

分步1 / 3

先把愿景缩成可见原型

定义用户目标、成功信号、可丢弃范围和所有者，制作 Catalyst Prototype，并写出 Participation Cost、用户拒绝条件和到期时间。

提示6要求用可见、可丢弃的原型催化真实参与，而不是用演示替别人批准变化。

一个可丢弃的变革原型

提示6要求用可见、可丢弃的原型催化真实参与，而不是用演示替别人批准变化。

假设团队想把发布流程从手工审批改成可追踪的发布清单。第一版不应直接接管全部服务，而可以选择一个非关键服务、一个发布窗口和一组明确角色。原型展示提交、批准、回滚和审计路径，参与者可以在真实但可控的边界中指出误解。

记录至少包含：原始愿景、实验范围、参与者、Participation Cost、成功和拒绝条件、数据处理方式、回退路径、反馈和下一步。若参与成本高到只有工具熟悉者能完成，原型没有真正催化协作，应先降低门槛。

全景指标与停止条件

提示7让全景复核能够真正改变方向，发现范围漂移时及时停止而不是被投入绑架。

Panorama Check 同时查看局部和全局：

维度	观察信号	需要警惕的变化
用户	完成率、误解、支持请求、恢复	用户承担了团队内部复杂性
范围	服务数、数据量、依赖和承诺	Scope Drift 超过原始边界
系统	失败率、延迟、权限、可回滚性	局部优化转移系统风险
团队	学习时间、交接、疲劳、参与分布	只有少数人能维护变化
成本	迁移、运维、审批和返工	Participation Cost 持续上升

Stop Rule 应事先绑定这些信号。例如，数据权限越界立即暂停；回滚演练失败就不扩大服务范围；用户误解连续上升则回到原型重新澄清。停止不是失败，而是保护全景和用户的控制动作。

change_protocol:
  unit: tpp20-topic-04-stone-soup-boiled-frogs
  vision: 发布流程更可追踪、更容易恢复
  catalyst_prototype: 一个非关键服务的一次可回滚发布清单
  participation_cost: 学习清单、角色协作、迁移和回滚演练
  panorama_check: 用户、范围、系统、团队、成本
  scope_drift: 从一个服务扩展到全部服务前必须重新批准
  stop_rule: 权限越界、回滚失败、用户误解上升或成本超过预算
  decision: 继续增量、缩小、回退或暂停

选择与拒绝矩阵

评审问题	可以接受的证据	应拒绝当前判断的信号
愿景	目标、用户结果和拒绝条件可观察	只有“变敏捷”“提高协作”等口号
原型	Catalyst Prototype 可丢弃、有范围和回退	原型直接变成无批准的生产承诺
参与	Participation Cost 有角色、时间和退出路径	只有少数熟悉者能参与
全景	Panorama Check 同时看用户、范围、系统、团队和成本	只看局部速度或演示成功
漂移	Scope Drift 有记录、复核和重新批准	顺手加范围但没有新决策
停止	Stop Rule 可触发暂停、缩小或回退	团队因为已经投入而继续扩大

常见误区

本章回顾

掌握 4 石头做的汤和煮熟的青蛙，不是让变化看起来轻松，而是能按提示6用 Catalyst Prototype 降低 Participation Cost，再按提示7用 Panorama Check 发现 Scope Drift、用户影响和系统风险，并以 Stop Rule 决定继续、缩小、回退或暂停。渐进式改造只有在全景仍被看见时才是务实的。

可验证练习

练习

本组练习覆盖 4 石头做的汤和煮熟的青蛙、提示6：做推动变革的催化剂 和 提示7：牢记全景，要求提交原型范围、参与记录和全景复核。

问题 1： 如何设计一个真正可丢弃的变革原型？

问题 2： 如何实践“提示6：做推动变革的催化剂”而不是替别人做决定？

问题 3： 增量指标很好看，但用户误解和回滚失败，如何实践“提示7：牢记全景”？

名词解释

本章出现的专业名词，用大白话再讲一遍。

Catalyst Prototype: 用于启动协作和学习、可观察且不必直接投入生产的最小成果。
Participation Cost: 参与试验所需的理解、时间、迁移、风险和心理成本。
Scope Drift: 增量变化逐渐超出原始范围、承诺、依赖或风险协议的状态。
Panorama Check: 把局部成果放回用户、系统、组织、依赖、成本和风险中复核。
Stop Rule: 规定何时暂停、缩小、回退或升级的事先条件。

前后导航

来源与改写范围

Pragmatic Programmer 作者页面：核对 Topic 4、提示6和提示7的版本位置与主题范围。
中文目录页面：核对 4 石头做的汤和煮熟的青蛙、提示6：做推动变革的催化剂、提示7：牢记全景的公开目录范围。
出版社书目信息：交叉核对中文译本的出版信息与版次边界。