通用方法 · 熟练
让 AI 先问一句「这行代码非得存在吗」
七级阶梯走一遍，代码量砍掉一半
AI 写代码最贵的不是写错，是写多 —— 多出来的每一行都要被读、被审、被维护，而且它会一直在那儿。有人把「房间里最懒的资深工程师」的做法整理成了一个可直接装的技能：动手之前先跑一遍七级阶梯 —— 这东西需要存在吗、本仓库里已经有了吗、标准库能做吗、平台原生能力能做吗、已装的依赖能做吗、一行能写完吗；第七级才轮到「写最小能跑的实现」。同 agent 开/关该技能的 git diff 对照显示：代码量平均降 54%（极端情况 −94%）、token 成本降 20%、执行时间降 27%。关键动作只有一个：阶梯必须跑在「理解问题之后」，而不是代替理解 —— 先读要改的代码、跟一遍真实流程，再挑该上哪一级。
方法 · 一图看懂
1
先分清「写多了」和「写错了」 — 前者更贵，因为它不会报错，只会一直留在那里
2
七级阶梯，从下往上问 — 要不要存在 → 已有 → 标准库 → 原生 → 依赖 → 一行 → 最小实现
3
阶梯跑在理解之后 — 先读代码、跟一遍真实流程，再决定停在哪一级
4
别把校验也砍掉 — 减法只减「多余」，验证 / 错误处理 / 安全 / 无障碍一律不动
原理 · 为什么有效
为什么「写多了」比「写错了」更贵。写错会被测试、被报错、被 review 抓住，它有反馈回路；写多不会 —— 它编译通过、测试通过、看起来还挺周全，然后以「当时为什么会加这个」的形式，在半年后的每一次改动里收利息。第二条原理是阶梯的顺序。这七级不是并列的选项，是一个漏斗：上面六级全否，才有资格问第七级。真正省下来的量不来自「写得简洁」，来自在第六级之前就把大部分问题解决掉了。第三条是它的边界。这条方法的官方说明里有一句很容易被忽略：「永远不削减验证、错误处理、安全与无障碍」—— 也就是说，阶梯减的是「多出来的功能」，不是「必要的保障」。把它们也砍掉，你得到的不是最懒的资深工程师，是一个偷懒的实习生。
适用场景
适用：你在用 AI 写代码或改代码，而且发现它给的方案总比实际需要的大一圈；或者你在维护一个已经有年头的仓库，最怕 AI 顺手引进一个新框架。也适用：你不写代码，但你想把同一条思路用在别处 —— 让 AI 出方案、写文案、做周报时，先问「这一节需要存在吗」「公司上一个版本里已经有了吗」。不适用：你说的本来就是「从零搭一个原型」—— 那时候探索本身就是目的，过早收敛会锁死方案；也不适用于你还没搞清楚要改什么的时候 —— 阶梯的前提是「问题已经被理解了」。
自测 · 5 问
我是先读懂了要改的那段代码，还是上来就把需求丢给 AI 了？
AI 给的方案里，有没有哪个文件是它「顺手新建」的 —— 仓库里其实已经有一个差不多的？
它引进来的新依赖，标准库或已装的依赖真的做不到吗？
减下来的部分里，有没有混进本该保留的校验与错误处理？
我是在用什么判断「这一级可以停」—— 是它说可以，还是我读过代码后自己判断的？
怎么上手 · 验证步骤
照这个顺序上手：第一步先把阶梯写进你的规则 —— 无论是项目里的 AGENTS.md、工具的常驻指令，还是每次对话开头粘贴一段，只要它每轮都能看到。第二步挑一个你熟悉的改动试一次 —— 最好是那种「你大概知道该怎么改」的小需求，这样你才有能力判断它停在哪一级是不是合理。第三步主动逼它走上面几级 —— 第一次它多半直接跳到第七级，你要追问「仓库里有没有现成的」「标准库能不能做」，把它往回推。第四步把这轮结果记一行 —— 改了多少行、有没有新文件、有没有新依赖，攒够十次你就知道这条规则对你的项目值多少。
做完这一轮，自己对照三件事：① 拿这轮和上一轮同类需求的 git diff 比，新增行数是否明显下降 ② diff 里有没有出现新文件或新依赖，如果有，我能不能说清为什么不能用已有的 ③ 有没有哪一处本该有的校验被减掉了 —— 这三条里第三条一票否决：出现即说明我把「减法」用错了地方。