前言
最近我想得越来越多的一件事是 —— AI 时代，软件开发的思维范式也在悄悄变化。
过去我们衡量好代码的七个维度：可维护性、可读性、可扩展性、灵活性、简洁性、可复用、可测试性（参考 《设计模式之美》）。
但现在不一样了 —— 以后的代码，绝大多数是 AI 在写，也绝大多数是 AI 在看。人类程序员的角色，正在从"代码作者"悄悄变成"需求描述者"和"架构判官"。
当代码的主要读者从"人"变成"AI"之后，很多过去神圣的工程原则都值得重新审视。我按《设计模式之美》里那七个维度，一条一条重新过了一遍。
七个维度，逐一重估
1. 可维护性 —— 降权
"维护者"从人变成了 AI。AI 读 10k 行代码的成本，远低于人读 100 行。
真正要维护的也不再是代码本身，而是项目的上下文 —— README、架构图、决策记录、测试用例，这些才是 AI 的"记忆锚点"。
新结论：维护好文档和上下文，比维护好代码本身更重要。
2. 可读性 —— 重心迁移
AI 不需要 self-documenting 的命名，它看上下文就懂。
"人类可读性"降权，但**“意图可读性"升权** —— 注释从"解释 how"转向"解释 why”。
新结论：好注释不再解释代码在做什么，而是解释为什么这么做。
3. 可扩展性 —— 显著降权
过去我们怕"大改"，所以提前留扩展点。现在 AI 可以在几分钟内做一次大规模重构，只要测试够全。
过度设计的惩罚变小了，YAGNI 原则的价值被进一步放大。
新结论：别为想象中的未来留口子，真的需要时让 AI 重写一遍就好。
4. 灵活性 —— 显著降权
"灵活性"的本质是用复杂度换未来的适应性。
AI 时代，这种适应性可以按需召唤，不必提前付出复杂度的代价。很多 DI 容器、复杂 config 体系，本质是"多人协作的妥协产物"，单人 + AI 时 ROI 明显下降。
新结论：别再为"可能的变化"建造宫殿，AI 能在几分钟里盖一座新的。
5. 简洁性 —— 略微降权
人不怎么看了，都是让 AI 看，简不简洁对阅读效率的影响变小了。
当然简洁一点肯定更好 —— 它能降低 AI 的上下文消耗，也能降低误解的概率。
新结论：简洁依然有价值，但不再是第一优先级。
6. 可复用 —— 显著降权
能复用当然最好，不能复用感觉也不用强求 —— 因为 AI 可以根据上下文随时生成新的实现。
过去"抽一层通用能力"是一件功德无量的事，现在可能只是制造了一个未来会被 AI 绕过的抽象。
新结论：DRY 原则需要重估，过去的 “Rule of Three”（三次重复才抽象）可以变成 “Rule of Five”（五次以上再抽象）。
7. 可测试性 —— 唯一显著升权
这是七个维度里唯一被显著升权的。
AI 改完代码之后，你怎么知道它没改错？答案只有一个 —— 测试。测试覆盖率直接决定了 AI 能否在没有人类盯着的情况下放手重构。
不过也要警惕 AI “context anxiety” 的问题 —— AI 有时会为了让测试通过，用欺骗的手段（改断言、mock 掉关键逻辑）绕过。需要人工在这一环卡一道。
新结论：测试从"质量保障"升级为"AI 放手改代码的安全绳"。
一张图总结
| 维度 | 过去权重 | AI 时代权重 | 变化 |
|---|---|---|---|
| 可维护性 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ↓↓（迁移到"上下文"） |
| 可读性 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ↓（迁移到"意图"） |
| 可扩展性 | ⭐⭐⭐⭐ | ⭐⭐ | ↓↓ |
| 灵活性 | ⭐⭐⭐⭐ | ⭐⭐ | ↓↓ |
| 简洁性 | ⭐⭐⭐ | ⭐⭐⭐ | → |
| 可复用 | ⭐⭐⭐⭐ | ⭐⭐ | ↓↓ |
| 可测试性 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ↑↑ |
最后的话
一句话总结：过去，好代码 = 对人友好；现在，好代码 = 对"人 + AI"这个协作系统友好。
评价维度并没有消失，而是从七维坍缩成三维 —— 简洁 + 可测试 + 意图清晰。其他维度，都可以交给 AI 在需要时重塑。
这不是说工程质量不重要了 —— 而是评价一段代码好坏的标准，正在从"人类维护友好"悄悄往"AI 能否理解并扩展"偏移。
这个时代最稀缺的能力，不再是"把代码写得漂亮"，而是：
- 把需求讲清楚
- 把测试设计好
- 把架构想明白
代码本身，反而是最不稀缺的东西了。