Reducing Entropy 说明文档

# 降低熵 这是一种仅限手动操作的技能，旨在通过衡量最终代码量（而非工作量）来最小化代码库总大小。偏向于删除和激进的简化。 ## 目的 此技能旨在对抗代码库随时间增长的自然趋势。它提供了一个评估变更的框架，基于这些变更是否能**减少最终代码库中的代码总量**，而不仅仅是最小化当前所需的工作量。 更多的代码意味着更多的熵。更多的熵意味着更多的 Bug、更多的维护工作和更多的认知负荷。此技能旨在对抗这种趋势。 ## 何时使用 在以下情况使用此技能： - 重构现有代码并希望最小化结果 - 评估功能请求（我们应该添加这个吗？） - 清理技术债务 - 在不同的实现方法之间做决定 - 用户明确要求“降低熵”或“最小化代码” - 你需要偏向于删除而非添加 **请勿自动使用。** 这是一个仅限手动操作的技能，需要用户明确请求。 ## 工作原理 ### 核心哲学 **衡量最终状态，而非工作量。** - 编写 50 行代码删除了 200 行 = 净收益（-150 行） - 保留 14 个函数以避免编写 2 个 = 净损失（+12 个函数） - “无变动”不是目标。更少的代码总量才是目标。 ### 三个问题 每个变更都必须回答： 1. **解决此问题的最小代码库是什么？** - 不是“最小变更”，而是最小的*结果* - 这可以是 2 个函数而不是 14 个吗？ - 这可以是 0 个函数（删除该功能）吗？ 2. **这是否导致了更少的代码总量？** - 计算变更前后的行数/函数数 - 如果变更后 > 变更前，拒绝它 - “组织得更好”但代码更多 = 更多的熵 3. **我们可以删除什么？** - 这使得什么变得过时了？ - 什么是因为我们正在替换的东西才需要的？ - 我们最多能移除多少？ ### 参考思维模式 在开始之前，**你必须从 `references/` 目录中加载至少一种思维模式**。这些为激进简化提供了哲学基础： 1. 列出 `references/` 中的文件 2. 阅读前言以查看哪种适用 3. 加载至少一种 4. 说明你加载了哪种及其核心原则 **在未加载思维模式前，请勿继续。** ## 关键特性 - **删除偏好**：默认操作是移除，而不是添加 - **代码总量指标**：成功与否由最终代码库大小衡量 - **反模式检测**：标记添加代码的常见借口 - **思维模式驱动**：加载哲学