reducing-entropy

reducing-entropy 技能概览

reducing-entropy 是一个仅限手动触发的重构辅助技能，核心目标是有意识地让代码库变小。它不是通用的 cleanup 提示词，也不应该自动触发。只有当你的真实目标是**减少系统中的活动部件、压低总代码量，并且比普通重构更偏向“删代码”**时，才适合使用它。

什么人最适合用这个技能

reducing-entropy 特别适合以下这类人：

• 正在重构一个已经很成熟、而且还在持续膨胀的代码库
• 在评审“cleanup”方案，但怀疑方案其实偷偷引入了更多抽象
• 正在判断某个功能、分层或 helper 到底还有没有存在必要
• 目标是简化架构本身，而不只是把现有结构重新整理一遍

它尤其适合 reducing-entropy for Refactoring 这种场景，因为这类任务里最常见的错误直觉，就是新增结构，而不是移除已有结构。

它真正解决的是什么问题

这个技能回答的，不只是“我该怎么改代码”这么简单。它会逼你先回答更难的问题：

• 这次修改完成后，代码库最终应该长什么样
• 最终状态是否真的更小
• 哪些东西应该被删除，而不是被保留下来

所以，如果你想要的是一种对“净减少”有明确偏向的分析方式，它会比泛泛的“帮我简化这段代码”提示词更有用。

reducing-entropy 的核心区别是什么

reducing-entropy 最关键的区别，在于它衡量成功的标准是：最终代码量，而不是实现过程有多省事。

这意味着它会优先选择类似下面的结果：

• 写一个小型迁移脚本，但借此删掉一个很大的子系统
• 用更简单的数据结构替代自定义类型
• 直接删掉可选行为，而不是把它进一步抽象和泛化
• 否决那些“看起来更干净”、但会让总代码变多的设计

采用前必须知道的约束

这不是每个任务都可以安全默认启用的技能。仓库里明确说明了：reducing-entropy 是 manual-only，只适用于用户有明确意图的时候。如果你的团队在某个任务上更看重可扩展性、面向未来的设计，或接口稳定性，而不是代码缩减，那这个技能的删除倾向可能会过头。

决定是否使用前，先读哪些文件

先读这几个文件：

• skills/reducing-entropy/SKILL.md
• skills/reducing-entropy/README.md
• skills/reducing-entropy/references/simplicity-vs-easy.md

然后根据你的具体情况，再补读一到两个参考心智模型文件：

• references/data-over-abstractions.md
• references/design-is-taking-apart.md
• references/expensive-to-add-later.md

这些 reference 很重要，因为这个技能默认你在动手之前，至少要基于一种“简化”视角来做判断，而不是凭感觉删改。

如何使用 reducing-entropy 技能

reducing-entropy 的安装与准备

如果你使用这个仓库里的 Skills CLI 方式，可以用下面的命令安装：

npx skills add softaworks/agent-toolkit --skill reducing-entropy

安装后，先打开对应技能目录，第一次使用前务必读一遍 SKILL.md。这不是一个装完就能自动跑起来的 plug-and-play 自动化技能，它更像是一个需要你主动调用的决策框架。

先加载必需的 reference mindset

很多用户会忽略一个很关键的细节：reducing-entropy 要求你在继续之前，先从 references/ 里加载至少一个文件。一定先做这一步，并明确说明你选了哪一个。

比较合适的搭配方式：

• 当某种熟悉的模式看起来顺手、但其实很重时，用 simplicity-vs-easy.md
• 当代码里到处都是 wrapper、manager 或自定义类型时，用 data-over-abstractions.md
• 当职责纠缠在一起时，用 design-is-taking-apart.md
• 当“现在删掉”可能和“以后补回来代价很高”发生冲突时，用 expensive-to-add-later.md

这一步能明显提升输出质量，因为它给模型的是一个具体的“简化镜头”，而不是模糊的“把它搞得更干净”。

reducing-entropy 需要什么输入

如果想得到真正有用的输出，不要只丢一个 repo 链接，或者直接甩一堆文件。reducing-entropy 最适合在你明确提供以下信息时使用：

• 用户已经确认的目标
• 当前必须保留的行为
• 本次分析的代码范围
• 对 API、迁移、发布时间等方面的约束
• 是否允许跨文件、模块或功能做删除

一个强输入示例：

“Use reducing-entropy on our billing retry flow. Goal: preserve current retry behavior for Stripe failures, but reduce total code in services/billing/ and workers/retry/. You may remove dead configuration paths and duplicate helper layers. Do not change public API responses or database schema this week.”

这会比下面这种描述好得多：

“Refactor billing to be simpler.”

把模糊目标改写成高质量的 reducing-entropy 提示词

一个好的 reducing-entropy usage 提示，通常包含五个部分：

1. 明确激活这个技能
2. 指定目标范围
3. 说明哪些行为必须保留
4. 明确允许删除的边界
5. 规定输出格式

示例：

“Apply the reducing-entropy skill. Load one reference mindset first and tell me which one you chose. Analyze src/cache/ and src/session/ for the smallest codebase that still supports current login/session behavior. Prefer deletion over reorganization. Reject options that increase total code even if they look cleaner. Give me:

• the smallest end-state design
• what to delete
• what to merge
• risks
• rough before/after code footprint”

适合真实重构工作的建议流程

一个比较稳妥的工作流是：

1. 先读 SKILL.md
2. 选择一个 reference mindset
3. 检查当前模块边界
4. 列出必须保留下来的行为
5. 提出技能要求的三个核心问题
6. 产出 2–3 个候选终态方案
7. 按净代码缩减效果比较这些方案
8. 实施其中最小、但可行的结果
9. 再回头检查是否还残留多余抽象和死路径

这样做能避免一个非常常见的失败模式：还没想清楚“最终最小可存活设计”是什么，就直接开始动手改代码。

每次运行都要强制问的三个问题

这个仓库把 reducing-entropy 建立在三个检查点上。实际使用时，最好把它们直接写进提示词里：

• What is the smallest codebase that solves this?
• Does the change result in less total code?
• What can we delete?

如果不把这三个问题强制摆到台面上，输出很容易又滑回普通重构建议。

reducing-entropy 最擅长的场景

最适合的任务包括：

• 把重复模块收拢成一条更简单的实现路径
• 移除 wrappers、factories、managers，以及很薄的一层抽象
• 用普通数据加函数，替换自定义结构
• 删除低使用率功能或过度可配置能力
• 在新增需求之前，先把一个纠缠复杂的子系统简化掉

这也是为什么 reducing-entropy for Refactoring 适配度最高：它关注的重点，不是局部代码风格打磨，而是重新定义“最终状态”应该长什么样。

哪些情况下不要用 reducing-entropy

如果任务的主要目标是以下这些，就不建议使用这个技能：

• 新增某种能力，而且未来需求还不明确
• 需要为第三方稳定保留扩展接口
• 正在设计后期补救代价很高的基础能力
• 只是想提高代码可读性，但没有权限删除或合并行为

在这些场景下，它的删除偏向就不再是优势，反而会变成错配。

仓库里最值得先读的文件

如果你想最快建立正确理解，建议按这个顺序读：

1. SKILL.md
2. README.md
3. references/simplicity-vs-easy.md
4. references/design-is-taking-apart.md
5. references/data-over-abstractions.md

只有当你想进一步理解作者是如何看待这些哲学支撑文件时，再去读 adding-reference-mindsets.md。

能显著提升输出质量的几个技巧

影响最大的三个策略是：

• 先要求给出“最小终态架构”，再要求具体代码改动
• 要求明确列出删除项，而不只是说“简化一下”
• 让模型估算究竟会消失什么：文件、函数、类、分支、配置

这样，reducing-entropy 才会从一种风格层面的提醒，变成真正的“减量练习”。

reducing-entropy 技能 FAQ

reducing-entropy 比普通的 refactor 提示词更好吗？

通常是的，前提是你的目标真的是“净简化”。普通提示词往往会建议更清晰的分层、更好的命名，或更可复用的抽象。可如果这些动作会让代码库继续变大，而你又希望模型克制这种倾向，那 reducing-entropy 会更合适。

reducing-entropy 适合新手吗？

适合，但有一个前提：这个新手至少得足够理解当前系统，能说清楚哪些行为必须保留、范围在哪里。这个技能的框架本身不复杂，但想得到好结果，关键在于你要知道哪些东西可以安全删除。

reducing-entropy 是不是就等于删代码？

不是。只要最终能换来更大规模的删除，它也可能建议你先写一些代码。判断标准始终是最终状态。少量新增是可以接受的，只要它能替代更大、更重的结构。

我可以把 reducing-entropy 用在 greenfield 场景吗？

通常不建议把它作为主要指导方式。它更擅长给已有代码库做修剪和简化，而不是从零开始设计一个全新的系统。

reducing-entropy 和普通 cleanup 工作有什么区别？

普通 cleanup 往往优化的是局部可读性或组织方式。而 reducing-entropy skill 优化的是：更少的概念、更少的结构、以及更少的总代码。这些目标有重叠，但并不相同。

安装前最需要注意的风险是什么？

主要风险包括：

• 删掉了你其实真的需要的灵活性
• 为了眼前简化而过度牺牲未来需求
• 过于机械地用行数衡量价值
• 去掉了那些出于真实运行或业务原因才存在的结构

这也是为什么 expensive-to-add-later.md 很重要。它为“不要一味删除”提供了一个有原则的例外视角。

reducing-entropy 适合所有仓库吗？

不适合。它最适合“代码增长本身已经成问题”的仓库。对于强监管、公共平台型，或者高度可扩展的系统，它就没那么适合，因为在这些系统里，显式结构本身可能就是产品要求的一部分。

如何改进 reducing-entropy 技能

给 reducing-entropy 设定更清晰的边界

想提升 reducing-entropy usage，最快的方法就是先定义清楚“哪些东西绝对不能变”。否则，模型可能会把真正有价值的行为也一起删掉。

实用的边界表达包括：

• “Preserve API shape.”
• “No schema changes.”
• “Keep test coverage expectations.”
• “User-visible behavior must stay identical.”

边界越清楚，技能就越能在安全前提下保持足够激进。

不要只要一个答案，要求终态方案对比

与其只问一个推荐方案，不如直接要求给出两到三个候选终态，并按以下维度排序：

• 代码总量减少多少
• 迁移成本
• 破坏现有行为的风险
• 后续维护负担

这样你能更清楚地看到取舍，也更容易否掉一个“理论上最小、但当前风险太高”的设计。

提供能暴露熵增的代码信号

如果你能主动指出哪些地方已经表现出膨胀迹象，reducing-entropy 的效果会明显更好，例如：

• 模块之间有重复逻辑
• wrapper class 几乎不包含实际行为
• 配置分支服务于早就不用的模式
• helper 层只是简单转发调用
• 明明普通数据结构就够了，却用了自定义类型

这些线索能帮助模型瞄准真正的简化机会，而不是做一些表面上的美化改动。

留意几类常见失败模式

最常见的不佳输出包括：

• 把代码重新组织成更多文件
• 为“将来扩展”新增抽象
• 保留已经没有意义的兼容路径
• 只改命名、但不减少结构
• 把“少折腾”误当成目标本身

一旦看到这些苗头，就要重新强调核心指标：最终代码库的总代码更少。

有策略地使用 reference 文件

选对心智模型，结果会好很多：

• 用 data-over-abstractions.md 去挑战 class 很重的设计
• 用 design-is-taking-apart.md 去拆开职责混杂的问题
• 用 simplicity-vs-easy.md 处理“熟悉方案其实耦合太重”的情况
• 用 expensive-to-add-later.md 守住那些少数确实值得保留的东西

这是这个仓库最有价值的部分之一，值得你显式使用，而不是被动略过。

按类别要求列出删除候选项

一个产出很高的提示词模式是：

“List deletion candidates by category: feature, abstraction, config, compatibility path, helper, type, and file.”

这种结构会逼着模型跳出局部代码修改，去寻找更大范围的减量机会。

第一轮输出后继续追问

拿到第一轮结果后，可以继续追问这类问题：

• “What remains that exists only to support the old design?”
• “Which abstractions are now redundant?”
• “What can be merged further without changing behavior?”
• “What would you remove if you had to cut this module by 30%?”

很多真正的收益，恰恰是在第二轮问题里才会浮现出来。

不只看行数，要验证净复杂度是否下降

在这里，行数确实重要，但不能机械地只盯着它。最好的改进，通常还会同时减少：

• 需要理解的概念数量
• 追踪行为时跨模块跳转的次数
• 特殊分支和例外情况
• 条件分叉路径
• 依赖面

如果代码库虽然变小了，但依然纠缠难懂，那也只能算部分胜利。最佳的 reducing-entropy guide 用法，是把“删减”与“解耦”结合起来。