name: reducing-entropy description: 仅限手动使用的技能，用于最小化总代码库大小。仅在用户明确请求时激活。通过最终代码量衡量成功，而非努力。偏向删除。
减少熵
更多代码滋生更多代码。熵累积。此技能偏向于最小的可能代码库。
核心问题： “代码库在之后看起来如何？”
开始之前
从references/加载至少一种心态
- 列出参考目录中的文件
- 阅读frontmatter描述以选择适用的
- 加载至少一个
- 说明加载了哪一个及其核心原则
在完成此操作之前不要继续。
目标
目标是最终代码库中的总代码更少 – 不是现在写更少的代码。
- 编写50行代码删除200行代码 = 净收益
- 保留14个函数以避免编写2个 = 净损失
- “无变更”不是目标。更少的代码才是目标。
衡量最终状态，而非努力。
三个问题
1. 解决这个问题的最小代码库是什么？
不是“最小的改变是什么” – 而是最小的结果是什么。
- 这能否是2个函数而不是14个？
- 这能否是0个函数（删除功能）？
- 如果我们这样做，我们会删除什么？
2. 提议的更改是否导致总代码减少？
计算更改前后的行数。如果之后 > 之前，拒绝它。
- “更好组织”但更多代码 = 更多熵
- “更灵活”但更多代码 = 更多熵
- “更清晰的分离”但更多代码 = 更多熵
3. 我们可以删除什么？
每次更改都是删除的机会。问：
- 这使什么变得过时？
- 什么只是因为我们在替换的东西才需要的？
- 我们最多能移除什么？
红旗警示
- “保留现有的” – 现状偏见。问题是总代码，而非变更。
- “这增加了灵活性” – 灵活性为了什么？YAGNI（你不需要它）。
- “更好的关注点分离” – 更多文件/函数 = 更多代码。分离不是免费的。
- “类型安全” – 值得多少行？有时运行时检查以更少的代码获胜。
- “更容易理解” – 14个东西不比2个东西更容易。
何时不适用
- 代码库已经对其功能最小化
- 您处于有强约定的框架中（不要对抗它）
- 监管/合规要求强制某些结构
参考心态
见references/以获取哲学基础。
要添加新心态，见adding-reference-mindsets.md。
偏向删除。衡量最终状态。