为什么 70% 是推出来的，不是喊出来的
同一个目标，「要求大家用 AI」和「降低 Review 成本」，前者推了半年没动，后者三个月到了 70%。
一个说不清的失败
我们团队推 AI 代码，2025 年 2 月开始。当时的做法很标准：开会、发文、树典型、周会通报进度。
第一个月的数字很好看。到了第五个月，AI 代码占比卡在 15% 上不去。
加压没用。 发了三次通报，两次专项检查，开会强调了三遍"这是公司级战略"。
第七个月，我们换了个做法：给 AI 生成的代码加 Review 门禁 + BadCase 归因闭环。
三个月后，AI 代码占比到了 70%。
同一个团队，同一个目标，同样的工具。为什么？
这个问题我憋了很久，直到最近重学系统思维才想明白。
线性思维的陷阱
我们当时的因果链是这样的：
公司要求 → 团队推广 → 大家使用 → AI 代码占比提升四步全是正向。看起来只要执行到位就行。
但现实中第③步卡住了。而且不是"大家不努力"，是用得越多，阻力越大：
- AI 生成的代码看不懂，Review 变慢
- Review 变慢，提交就更谨慎，AI 使用量下降
- 使用量下降，AI 的上下文越少，生成质量越差
- 质量越差，Review 更不敢放行
这条路是走不通的。 但我们当时看不到，因为整条链上没有一条"负"的边。
先把图画出来
系统思维的第一件事不是分析，是画。
下面这张图是当时真实情况的因果回路图（复盘时补的）：
读图方法：因果回路图（CLD）里，每条箭头上的符号表示极性。
+：同向。左边涨，右边跟着涨-：反向。左边涨，右边反而跌
⭐ 判定法则：沿着回路数负号的个数。
偶数个负号 = 增强回路 R（正反馈，越滚越大）
奇数个负号 = 调节回路 B（负反馈，会自我稳定）
图里有两条回路：
| 回路 | 类型 | 走一圈会发生什么 |
|---|---|---|
| B1 | 调节回路（负反馈） | AI 占比↑ → 缺陷↑ → 信任↓ → 不敢用 → AI 占比↓ |
| R1 | 增强回路（正反馈） | Review 基建 → 返工成本↓ → 用量↑ → 基建更值 → 基建投入↑ |
⭐ 关键发现：我们的做法正好压在 B1 上
看清结构之后，事情就明白了。
我们做的"开会 + 通报 + 检查"，全部作用在 B1 的上半段 —— 想把"AI 代码占比"直接推上去。
而 B1 的性质是自我稳定。你推得越用力，反弹越大：
「愈用力推，系统的反弹力愈大」—— Senge 法则第 2 条
补偿性反馈的机制很直白：团队发现"用了 AI 反而更麻烦"，就会自然退回手写。 你在推的对面，系统自己在拉。
而我们真正该做的 R1 完全没有启动。 那条回路是自增强的，只要建立起"Review 成本下降 → AI 更值 → 愿意继续投基建"的循环，AI 占比会自己涨。
这就是「转移负担」基模的活标本：
表面解法（推症状）：要求必须用 AI → 短期指标达标 → 长期副作用（能力退化、依赖）
根本解法（调结构）：降低 Review 成本 → 从源头减小 B1 的"缺陷↑"环节
我们的 3 个月，就是把解法从左边换到了右边。
4 步画出这张图
这次复盘我用的方法，是系统思考的 4 步法。我自己加了一步：
| 步骤 | 关键问题 | 这次的收获 |
|---|---|---|
| ① 确定目标 | 要什么？可度量 | 目标一开始写错了 —— 我们量的是"占比"，但真正该量的是"Review 成本" |
| ② 找元素 + 画连接 | 系统里有什么，怎么连 | 找出 6 个变量：AI 占比、Review 通过率、信任度、缺陷密度、基建投入、使用量 |
| ③ 找延迟 ⭐ | 哪些是因，哪些是果 | ⚠️ 这一步最容易漏。 门禁上线到指标变化，隔了 8 周 |
| ④ 可视化 | 画成回路图 | 画完才看出 B1 是自我稳定的 |
| ⑤ 抓主要矛盾 + 找杠杆点 | 在哪下手 | 断在"缺陷密度"这一环上，而不是"使用量" |
为什么第 ③ 步要单独拎出来
因果在时空上并不紧密相连。 —— Senge 法则第 7 条
门禁上线之后，前 8 周几乎看不到任何指标变化。那个阶段最容易做的事是"以为方向错了，开始改"。
我们前 5 个月就是干这个的。如果当时知道有 8 个月的延迟期，我们会等，会观察，不会加压。
三条能带走的
① 推不动的时候，先看结构，别加力
指标不涨有两种可能：执行力不够，或者你在推一个自我稳定的回路。
后者加力只会触发补偿性反馈。判断方法：数负号。
② 真正的杠杆点不在你想要的地方
我们想要"提高 AI 占比"，所以所有动作都围着占比转。
但占比是果，不是因。因是"Review 成本"，果是"团队敢不敢用"。
「寻找小而有效的高杠杆解」—— Senge 法则第 8 条
Senge 特别强调：杠杆点往往不在压力最大或症状最明显的地方。 而在我们的图里，压力最大的地方（占比）恰恰是果。
③ 度量指标的时候，先问"这是因还是果"
我们盯了半年"AI 代码占比"，盯的是一个果。真正该盯的是"单次 Review 耗时"和"Review 一次性通过率"。
换成因之后，同样的问题在第三个月就解了。
这套因果回路图的画法来自 Peter Senge《第五项修炼》（1990），图里的 B1/R1 结构判定、4 步法、11 条法则，都出自这本书。Senge 师从系统动力学奠基人 Jay Forrester，这套东西的根是系统动力学，不是管理鸡汤。
写在最后
这件事我复盘了挺久。最扎心的不是"我们方法错了"，是"我们用了一年多才意识到自己在推一个自我稳定的回路"。
系统思维的价值不在于画图本身，而在于：它能让你在事情失败的时候，分清楚是"没执行好"还是"结构不对"。
而这两种情况，需要的动作是完全相反的。
图用 matplotlib + Noto Sans CJK 生成，脚本在 src/images/gen_sys_thinking_figs.py，改文字可直接重新跑。