当用户明确要求压缩代码库时，用删除优先审查最小化最终代码总量

适用于用户明确要求减少代码膨胀或最小化最终代码库规模时，以最终代码量而非当前改动量衡量成功。

适用场景

解决思路

1. 仅在用户明确要求时手动启用本技能，不要自动激活。
2. 前提：更多代码会催生更多代码，熵会累积；让方案偏向尽可能小的代码库。
3. 始终问核心问题：“代码库在改动之后长什么样？”
4. 开始前，列出 `references/` 目录中的文件。
5. 阅读这些文件的 frontmatter description，挑选至少一个适用的 mindset。
6. 至少加载一个 mindset。
7. 说明你加载了哪个 mindset 及其核心原则。
8. 在完成上述加载和说明前，不要继续执行后续步骤。
9. 明确目标：减少最终代码库中的代码总量，而不是减少当前要写的代码量。
10. 用净变化判断：写 50 行但删除 200 行是净收益；保留 14 个函数只为避免写 2 行是净损失。
11. 不把“无 churn/无改动”当目标；把“更少代码”当目标。
12. 衡量最终状态，而不是投入的努力。
13. 问第一个问题：解决这个问题的最小代码库是什么？关注最小结果，而不是最小改动。
14. 追问：能否用 2 个函数替代 14 个函数？
15. 追问：能否变成 0 个函数（删除该功能）？
16. 追问：如果这样做，我们会删除什么？
17. 问第二个问题：所提议的改动是否让总代码变少？
18. 改动前后统计代码行数；如果之后 > 之前，拒绝该改动。
19. 拒绝“组织更好”但代码更多，因为那是更多熵。
20. 拒绝“更灵活”但代码更多，因为那是更多熵。
21. 拒绝“关注点分离更干净”但代码更多，因为那是更多熵。
22. 问第三个问题：我们能删除什么？
23. 把每次改动都当作删除机会，追问：这使什么变得过时？
24. 追问：什么只是因为我们要替换的东西才需要？
25. 追问：最大能移除多少？
26. 将“保留现有东西”视为红旗：这是现状偏见；要看总代码，不看 churn。
27. 将“这增加了灵活性”视为红旗：为什么需要这种灵活性？应用 YAGNI。
28. 将“更好的关注点分离”视为红旗：更多文件/函数 = 更多代码；分离不是免费的。
29. 将“类型安全”视为红旗：它值多少行代码？有时更少代码的运行时检查更优。
30. 将“更容易理解”视为红旗：14 个东西不比 2 个东西更容易理解。
31. 参考 `references/` 获取哲学基础；要新增 mindset，见 `adding-reference-mindsets.md`。
32. 结尾执行：偏向删除；衡量最终状态。

适用边界 · 注意事项

• 代码库对其功能而言已经最小。
• 处于有强约定的框架中（不要对抗框架约定）。
• 监管/合规要求强制某些结构。