详细内容
1. 生产力的底层约束：维护成本
作者将“新增功能开发”和“维护活动”分开讨论。维护包括：
- 修 Bug
- 清理设计问题
- 升级依赖
- 处理历史实现带来的连锁修改
关键判断是：每一行新代码都在给未来持续记账。
不是“写完即完结”，而是“写完即进入长期维护期”。
作者给出一个示意性估计（强调数字可讨论，但趋势稳定）：
- 每投入 1 个月开发，在第 1 年会额外消耗约 10 天维护；
- 之后每年还要持续消耗约 5 天维护。
这意味着，随着代码存量增长，维护占比会逐步侵蚀新功能时间。示意曲线中，团队在大约 31 个月后，新功能时间占比跌破 50%。
2. 为什么这个模型“粗糙但有用”
作者承认模型并非现实的精确镜像，但认为方向上非常可靠：
- 创业公司早期速度快，中后期会明显变慢；
- 5-9 年后常见“团队很忙但产出变少”；
- 组织会通过延后修复、不断加人、重写系统等方式“掩盖”问题，而不是消除问题。
所以争论小数点意义不大，核心是：维护成本是长期生产力的主导变量。
3. AI 变量如何改变曲线
作者把 AI 引入为两个变化：
- 变化 A：单位时间写出更多代码（产出倍率 > 1）
- 变化 B：每单位代码的维护成本变化（可能升高、持平或下降）
核心关系可写成：
长期维护压力倍率 ≈ 产出倍率 × 维护成本倍率
情景一：AI 让产出翻倍，维护成本也翻倍
- 产出倍率 = 2
- 维护成本倍率 = 2
- 维护压力倍率 = 4
短期会看到明显提速，但很快被维护吞没。文中图示给出的是：大约几个月后收益被吃完，随后长期低于不用该 AI 的基线。
情景二：AI 让产出翻倍，维护成本“仅持平”
- 产出倍率 = 2
- 维护成本倍率 = 1
- 维护压力倍率 = 2
很多人会直觉认为“已经很好了”。作者指出这仍然不够：
- 短中期依然有收益；
- 但随着代码存量累积，维护负担继续加速；
- 在更长周期可能变成净负收益。
也就是说，“可维护性不变”并不能支撑“长期提效”。
情景三：AI 让产出翻倍，同时把维护成本减半
- 产出倍率 = 2
- 维护成本倍率 = 0.5
- 维护压力倍率 = 1
这是作者认为“数学上成立”的可持续区间：
- 你拿到提速红利；
- 又不会把未来维护债务放大；
- 即使未来停止使用该 AI，也不会留下明显的结构性后遗症。
4. “停用 AI 也回不去”的锁定效应
文章特别强调了一个常被忽视的点：
- 你停掉 AI 后，新增提速会立刻消失；
- 但过去由其产生的高维护代码存量不会自动消失。
因此会出现“收益可撤销、负担不可撤销”的不对称：
- 上车容易；
- 下车后仍要为历史代码付费。
这也是作者用“Hotel California（能入住，难离开）”隐喻的原因。
5. 作者不是反 AI，而是反“单指标提速”
作者在附言中明确：这不是简单反 AI 立场。
他给出的方向是：
- 可以继续追求编码速度；
- 但必须同等投入去压低维护成本；
- 也可以用 AI 提升维护任务本身的效率（而不只是写更多新代码）。
换句话说，真正要优化的是系统级生产力，不是“本周提交行数”。
文章的管理启发（面向团队落地）
1. 重设 KPI：从“输出速度”改为“净生产力”
建议把以下指标放进同一看板，而不是只看交付速度：
- 新增功能交付周期
- 缺陷回流率（发布后修复比例）
- 代码评审平均时长与有效意见密度
- 依赖升级滞后天数
- 历史模块变更成本（同类需求耗时趋势）
2. 评估 AI 时必须做“双轴对照”
至少对照 2 组数据：
- 短期轴：需求吞吐是否提升
- 中长期轴：维护工时占比是否抬升
如果只有短期轴改善，不能判定“成功上线”。
3. 在流程上抑制“AI放大技术债”
可执行做法：
- 对 AI 产出代码提高评审门槛（不是降低）
- 强制关键模块补齐可读性说明与测试
- 对“快但难懂”的实现增加返工预算
- 设立“维护预算”上限，触发即暂停扩张开发
4. 决策阈值可以用一个简化规则
若 AI 带来 X 倍编码产出，则目标应接近：
单位维护成本 <= 1/X
示例：
- 产出 2 倍 -> 维护成本需降到 1/2
- 产出 3 倍 -> 维护成本需降到 1/3
做不到这条时，应把 AI 使用范围限制在低耦合、低寿命或可快速替换的代码域。
一句话结论
AI 时代真正稀缺的不是“写得更快”，而是“写得更快且更容易维护”。
只拿前者，你得到的是短期兴奋；同时拿到后者，才是长期复利。