核心用法
Reducing Entropy 是一种以"代码熵减"为核心的工程思维技能，将最终代码行数作为唯一成功指标，而非开发工作量或代码"优雅度"。激活后提供系统化的删除优先检查清单：在重构、新增功能、PR 评审、技术债清理时，强制回答三个核心问题——"解决该问题的最小代码库是什么？""改动后总代码是否减少？""能删除什么？"
显著优点
- 量化决策：以代码行数前后对比消除主观争论，用客观数据对抗"更灵活""更好组织"等模糊辩护
- 对抗复杂性累积：内置 8 条"红线禁令"（如禁止少于 3 个用例的抽象、禁止单函数文件），直接针对常见过度工程反模式
- 实用主义哲学基础：整合了 Rich Hickey 的 Simple Made Easy、Grug Brain 极简主义、Out of the Tar Pit 等经典资源，提供可引用的理论支撑
- 结构化执行流程：从加载思维模式 → 三问评估 → 红旗警示 → 删除清单 → 快速获胜模式，形成完整决策闭环
潜在缺点与局限性
- 指标单一风险：代码行数并非万能，可能误伤必要防御性代码（如边界检查、日志、监控）、强类型安全代码，或合规要求的审计追踪
- 维护性悖论：过度追求行数最小化可能导致内联过度、魔法字符串、隐式依赖，反而降低可读性——技能本身承认" genuinely unmaintainable"是罕见例外，但未给出判定标准
- 协作摩擦："删除优先"心态可能与团队既有代码情感、"沉没成本"心理冲突，需配套团队文化建设
- 框架生态限制：明确警告在强约定框架中"不要对抗"，适用范围受限
适合人群
- 技术债严重的遗留系统维护者
- 极简主义信奉的资深工程师/架构师
- PR 评审中频繁遭遇过度抽象的 Tech Lead
- 明确获得用户"简化代码"指令时的执行助手
常规风险
- 过度删除：可能移除实际有依赖的"死代码"、测试覆盖率要求的边界 case、或未来确实需要的扩展点（YAGNI 误判）
- 隐性复杂度转移：行数减少但认知负荷转移（如硬编码替换配置、内联替换显式接口）
- 安全/合规盲区：技能将"监管/合规要求"列为例外场景，但未提供识别方法，存在误删风险
建议：作为人工决策的辅助框架使用，最终删除操作需配合测试套件、静态分析与团队 review，避免自动化执行。