记住一句话，还没得到一个方法
短句好记，是因为省略了条件。把它当成处处适用的命令，可能把维护提醒变成删代码竞赛。这里每张卡都补齐五层：原话、本站译意、解决的问题、适用条件与下一步。
维护成本：写得快，责任仍在
Maintaining code is not cheap
本站译意：维护代码并不便宜。
— Matt Pocock
它提醒我们看交付后的工作：需求变了谁来改，错误出现谁来查，重复行为是否要改多处。生成便宜，不会自动消除这些责任。
解决什么问题
只按生成速度估计成本，忽略后续修改。
适用条件
正在判断功能或实现是否值得保留时。
下一步
找一处无用功能或重复实现，先列出删改前后的行为证据。
代码负担：先找能证明的简化
All code is debt.
本站译意：所有代码都带着未来要承担的负担。
— Matt Pocock
这是一种警醒，不是删光代码的指令。有价值的校验、清楚的命名和必要抽象，同样需要代码来表达。回到核心理念，看修改成本，而非只看行数。
解决什么问题
不加判断地保留每一段生成结果。
适用条件
已经知道预期行为，能够检查改动前后结果时。
下一步
选一个重复分支做简化，同时验证合法与异常路径。
能力成长：练习判断，不只练习发指令
Your skill level acts as a ceiling for the agent
本站译意：你的技能水平会成为 agent 能发挥到哪里的上限。
— Matt Pocock
把它读作个人经验判断，不能据此给人的潜力设限，也不能当成实验定律。更实用的问题是：我现在能读懂改动、定位失败、解释状态、指出评审风险吗？
练习：少了行数，谁承担复杂度？
假设结算代码把「是否会员、是否到期、是否可退款」压进一个嵌套表达式。行数减半，报错时却说不清命中了哪个条件。先写出你会如何评审，再展开参考思路。
为简化提出证据要求
- 任务：说明上面三句短话中，哪句最容易被误用来支持这次压缩。
- 产出：写一个保留或修改建议，附一条可读性理由和一条行为检查。
- 检查：另一个人能否找到已到期会员的退款分支？
参考思路
代码负担提醒不能单独证明压缩合理。可以拆出有意义的条件名，并用到期、未到期的退款场景验证。比较理解与修改成本，再决定是否保留。
换一个反例再试：清晰的错误提示增加了代码，却让排错更快。若一句口号不能解释为何值得保留这些代码，就需要补上场景和取舍。
怎样才算完成？
你的答案需要同时谈到可读性、行为与维护成本，并指出一句话无法替你做出的判断。若理由只有「代码更短」，还没有解释谁能维护它。
速查
维护成本
生成之后，还有修改与排错。
代码负担
证明简化有效，再减少实现。
能力成长
补上自己尚不能核实的那一环。
来源
非官方、非商业的学习整理，与 Matt Pocock 无隶属或背书关系。所引作品版权归原作者；MIT 复用内容另附版权与许可声明。