通用方法 · 熟练
先爬七级台阶，再决定要不要写这行
每一级都在问「上一级办得了吗」，七级爬完还非写不可，才允许落笔
上一页给的是那一句反问 ——「这行代码非得存在吗」。这一页把它补成一条完整的阶梯：写之前先逐级往上问七次，每一级问的都是「上一级已经能办了吗」。从「这东西真需要存在吗」一路问到「一行够不够」，只有七级都答不上来，才允许落笔写最小实现。它的关键限定有三条：阶梯跑在 agent 已经读懂问题之后（不是用它代替理解）· 它砍的是多余的量，不是校验、错误处理、安全与可访问性 · 效果得用真实 git diff 来量，不是拿模型自述的篇幅差来量。最后一条尤其值得抄走 —— 它同时是「怎么判断一个效果数字是真是假」的现成样本。
方法 · 一图看懂
1
这功能真需要存在吗 — 不需要就整段跳过，这是唯一一级允许什么都不做的
2
代码库里已经有了吗 — 有就复用，⛔ 不平行重写一份
4
平台原生能力能办吗 — 浏览器 / 系统 / 框架内建的优先
5
已经装上的依赖能办吗 — 手上有的先榨干，⛔ 不新增
6
一行够吗 — 到这一级才开始考虑写，先想最短的形态
原理 · 为什么有效
为什么「少写」会变成「更对」：代码量与需要被审阅、被测试、被理解、被维护的面积成正比。agent 越强，瓶颈越从「写得出来吗」挪到「写出来的东西守得住吗」—— 每多一个文件、多一层抽象、多一个依赖，就多一处将来会静默失效的地方。而这条阶梯真正反直觉的地方在它的位置：它跑在理解之后，不是理解之前。它不省「读懂问题」这一步（那一步反而要读透、要追清真实调用链），它省的只是读懂之后顺手多写的那一部分。
适用场景
适用：让编码 agent 改真实仓库的场合 —— 尤其是它习惯性加抽象层、加辅助函数、加「以后可能用得上」的接口的时候；一个人维护的小项目收益最直观。不适用：⛔ 它砍不到校验 · 错误处理 · 安全与可访问性（这些在七级之外，属「必须写」那一档）· ⛔ 不适用于本来就要立新模块的场合（那时「要不要存在」的答案就是「要」）· ⛔ 也不是「越短越好」，它是「先证明长的没必要」。
自测 · 5 问
这一次要它做的事，我能一句话说清「不写会怎样」吗？
改之前，我让它先找过代码库里已有的同类实现没有？
它新引入的依赖，标准库或平台原生真的办不到吗？
它砍掉的那部分里，有没有混进校验 · 错误处理 · 安全？
这次的「少了多少」，我是拿 git diff 量的，还是听它自己说的？
怎么上手 · 验证步骤
第一次用不要整仓铺开，挑一个你熟的小改动。先把目标写成一句话（「把导出按钮从灰变亮」这种量级），然后让 agent 按七级逐级回答一遍，要求它每一级都写出「为什么上一级办不了」 —— 写不出理由的那一级，就是它想多写的那一级。通过七级之后再让它动手，动完拿 diff 数一遍：新增了几个文件、几个函数、几行。把这组数字记下来。第二次做同类改动时对比一次，你就有了属于自己的判据，不必再引用别人的百分比。
做完对着这一句自检：「如果我把这次新增的那几行删掉，功能还成立吗？」成立 ⇒ 那几行本来就该在第 1 到第 6 级被挡下来；不成立 ⇒ 那几行确实非写不可，阶梯这次跑对了。