thinking-archetypes

系统原型

概述

系统原型（Peter Senge，《第五项修炼》）是反复出现的结构模式。就像软件中的设计模式一样，一旦识别出某种模式，就能预测它会导向何处，以及可以从哪里着手干预。大多数顽固、反复出现的问题并非独一无二，而是已知模式的一个实例；模式的名称指出了杠杆点。

核心原则： 反复出现的问题通常有其结构模式。识别出模式，干预方式也就随之明确。

触发卡

当同一个问题在多次修复后仍反复出现时：

1. 中性地描述问题——症状、已尝试过的方法，以及反复出现的情况。
2. 匹配一种原型，使用下方的快速参考卡（修复失效、转移负担、增长极限、公地悲剧、升级、成功者愈成功、增长与投入不足）。
3. 干预结构，而非症状——使用该原型对应的关键问题。

如果经过认真审视后仍没有合适的原型，就不要强行套用——改用 thinking-systems，从头梳理。对于首次出现、只发生一次的问题，直接修复即可。

适用场景

• 同一个问题在多次“修复”后仍反复出现
• 快速修复随时间推移反而造成更糟的结果
• 增长停滞，原因却不明显
• 共享资源（CI、暂存环境、缓存、服务配额）持续退化
• 两项工作彼此升级对抗（服务重复、警报／阈值军备竞赛）

Problem keeps recurring despite fixes?  → match an archetype
Quick fix made it worse?                → match an archetype
Growth hit an invisible ceiling?        → match an archetype
Shared resource degrading?              → match an archetype

不适用场景

• 你需要从头梳理系统（组件、交互、涌现行为）——改用 thinking-systems。原型是用于识别反复出现的结构模式的快捷方式；如果系统尚不熟悉，先梳理系统，再判断是否符合某种原型。
• 你已找到模式，需要确定从哪里着手干预——使用 thinking-leverage-points（Meadows 的层级）。原型用于指出结构；leverage-points 则告诉你在该结构中的何处采取行动，才能产生最大效果。
• 首次出现、只发生一次且原因明确的问题 → 直接修复；无需匹配反复出现的结构。
• 经过认真审视后，没有合适的候选原型 → 不要强行套用。改用 thinking-systems，从头梳理实际结构。
• 你需要定位特定的错误代码路径 → 使用假设差异分析，而不是模式匹配。

快速参考卡

根据症状匹配模式；关键问题指出了着力点。

原型	结构	识别特征	关键问题（着力点）
修复失效	快速修复缓解了症状，但延迟出现的副作用使问题恶化	“我们上季度修好了，怎么又出现了？”；修复措施需要越来越大的剂量	“这项修复会造成什么副作用？”
转移负担	使用针对症状的变通方案，而非根本性修复，进而产生依赖	永久性的变通方案；“我们知道根本的修复办法，但没时间”；真正的能力正在萎缩	“依赖这个变通方案，让我们放弃了培养什么能力？”
增长极限	强化增长循环遇到平衡约束	增长强劲后陷入停滞；投入更多，回报递减；某种资源达到上限	“规模扩大到 10 倍时，什么会限制我们？”
公地悲剧	每个参与者都能从使用共享资源中获益；集体过度使用会耗尽资源	共享的 CI／暂存环境／缓存／配额状况恶化；人人只优化局部；没有明确的负责人	“谁负责维护这项资源的长期健康？”
升级	双方对彼此的举动做出反应，陷入竞争螺旋	“他们做了 X，所以我们必须做 Y”；军备竞赛式的动态；双方都觉得自己是在防守	“我们能否改变游戏规则，而不是把竞争推得更激烈？”
成功者愈成功	初期成功带来更多资源，优势不断累积，其他方案则被挤压	过去的成功是获得新投资的主要预测因素；为了供养现有方案，实验项目得不到资源	“我们是否在牺牲未来的成功，来供养当前的成功？”
增长与投资不足	需求增长并逼近上限；容量投资被推迟，直到性能下降并演变为危机	事故发生后才被动投资；长期处于“眼下够用”的状态	“如果现在不增加容量，增长 50% 后会有什么问题？”

软件示例（按原型分类）

• 修复失效： 增加服务器来掩盖内存泄漏 → 成本不断攀升，泄漏依然存在。屏蔽告警 → 系统持续退化，直到发生故障。
• 转移负担： 运维人员永远手动介入，而不是实现自动化；用功能标志掩盖始终得不到修复的缺陷。
• 增长极限： 随着代码库增长，开发速度下降（复杂度达到上限）；增加工程师并不能加快交付（协调开销增加）。
• 公地悲剧： 各团队让共享 CI 超负荷运行 → 所有人的构建都变慢；无人清理资源，导致云成本飙升。
• 升级： 微服务团队相互跟进，重复实现功能；各方不断收紧告警阈值，彼此追逐。
• 成功者愈成功： 所有精力都投入到旧的单体架构，新架构因此始终无法成熟。
• 增长与投资不足： 数据库直到负载过高而崩溃才升级；只有发生安全漏洞后才投入安全建设。

诊断流程

1. 中立地描述问题 — 包括症状、涉及的人或事、已尝试的措施，以及反复出现的情况。不要归咎于任何人。
2. 勾勒循环 — 说明因果关系；标出强化（放大）循环、平衡（限制）循环，以及延迟所在之处。
3. 使用快速参考卡匹配原型。如果符合两种原型，系统可能存在多层结构——请一并注明。
4. 针对结构进行干预，而不是症状 — 利用关键问题找出根本解决方案、需要解除的约束，或需要补充的缺失／延迟反馈。如果都不匹配，请停止并使用 thinking-systems。

验证清单

• 对问题的描述没有归咎于任何人
• 已勾勒循环（强化循环、平衡循环、延迟）
• 已匹配到具体原型（如果都不匹配，则转交 thinking-systems）
• 干预针对的是结构，而不是反复出现的症状
• 已考虑干预措施的副作用

Senge 的智慧

“我们未曾察觉的结构将我们禁锢。一旦看清它们，它们便不再能像从前那样束缚我们。”

这种模式会持续下去，直到有人看清它，并改变驱动它的结构——不是改变行为，而是改变产生这些行为的根源。