# Reclaim Code Entropy

> 用证据驱动的仓库级减法识别并收敛死代码、无消费者表面、重复事实、投机抽象、额外路由、生命周期重复、错位防御与迁移残留。用户要求代码化简、清理冗余、删除死代码、减少过度设计、回收代码熵、在连续若干 PR 后做全仓收敛，或明确调用 $reclaim-code-entropy 时使用；审计请求只读，只有明确要求实施、修改或删除时才改代码。不要用于单纯格式化、性能分析或以减少行数为目标的重写。

- Skill: `gaixianggeng/reclaim-code-entropy` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add gaixianggeng/reclaim-code-entropy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gaixianggeng/reclaim-code-entropy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: gaixianggeng (https://skillmd.com/u/gaixianggeng)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/gaixianggeng/reclaim-code-entropy

---


# 代码熵回收

在功能持续叠加后，用可验证的减法恢复清晰边界。目标是减少需要维护的概念、状态、路由和兼容负担，不追求任意 LOC 指标，也不把大规模重写包装成“简化”。

## 选择模式与范围

先根据用户授权选择模式：

- **审计模式**：用户说“检查”“审计”“找出”“给建议”时，只读调查并输出候选，不修改文件、分支或外部系统。
- **实施模式**：只有用户明确说“处理”“简化”“删除”“直接改”“实施”时才修改；优先实施一个证据最强、可独立验证的边界。

同一请求同时包含调查和修改时，遵循用户最终表达的明确授权；指令矛盾或无法判断时保持只读，并请求确认后再实施。

按以下顺序确定范围：

1. 用户指定的文件、模块、提交、PR 或时间窗口。
2. 当前分支相对基线的改动及其直接依赖边界。
3. 用户要求周期性全仓回收时，使用上次审计后的合并记录；没有记录时，以最近 5–8 个已合并 PR 作为线索窗口，但以仓库当前状态作为事实。

范围会实质改变结果且无法从仓库判断时再询问。不要擅自把局部请求扩大为全仓重构。

## 先建立仓库事实

1. 完整读取当前目录适用的 `AGENTS.md` 和项目文档，沿用仓库技术栈、验证命令、分支约定与权限边界。
2. 检查 Git 状态、当前分支、基线和已有改动。用户改动默认受保护；不要清理、回滚或顺手格式化无关文件。
3. 找到生产入口、测试入口、代码生成、配置、脚本、插件/反射、平台生命周期与持久化边界。
4. 记录当前可执行的最小验证；必要时先跑一次基线，避免把已有失败归因于本次减法。

优先使用仓库已有搜索、语言服务器、编译器、测试和静态分析工具。工具只负责找线索，不能替代证据判断。

## 生成候选

从以下类别寻找高价值候选：

| 类别 | 常见信号 | 需要证明 |
| --- | --- | --- |
| 无消费者表面 | 导出符号、参数、配置或接口没有调用方 | 不存在动态、外部或兼容消费者 |
| 重复事实 | 同一版本、状态、映射或策略在多处维护 | 能收敛到一个权威所有者 |
| 投机抽象 | 单实现接口、只服务一个调用方的通用层 | 移除后不会关闭近期已确认扩展点 |
| 额外路由或层级 | 纯转发 wrapper、重复 adapter、无决策 coordinator | 边界不承担权限、隔离或生命周期职责 |
| 生命周期重复 | 多个对象同时拥有连接、任务、缓存或重试状态 | 可明确唯一 owner 和清理时机 |
| 错位防御 | 深层静默兜底、吞错、重复校验掩盖非法状态 | 校验能放回可信入口且失败语义更清楚 |
| 手写基础设施 | 自制缓存、重试、解析或调度与现有能力重叠 | 替代方案更小且不增加依赖负担 |
| 迁移与支持残留 | 旧适配器、临时 flag、双写、旧 fixture 或文档 | 迁移已经完成且无回滚/兼容义务 |
| 加入后废弃 | 近期提交加入但后续不再接线的类型或路径 | Git 历史确认意图已被替代或放弃 |

不要把文件很长、命名不喜欢、代码不够“优雅”单独当作候选。复杂度信号必须落到真实维护成本和可删除边界。

## 为候选建立证据

对每个候选依次完成四项检查：

1. **消费者证据**：搜索定义、静态引用、构造入口、测试、配置、脚本、文档示例和生成代码。
2. **动态与兼容证据**：检查反射、序列化、路由注册、插件发现、公开 API、持久化格式、迁移、跨版本和平台回调。
3. **历史与所有权证据**：使用 `git log`、`git blame` 和相关提交确认为什么存在、是否仍在迁移，以及哪个边界应拥有职责。
4. **验证证据**：明确删除或合并后能运行的最小测试、构建、类型检查、静态检查或手工路径。

据此分级：

- **高置信**：四项证据闭环，风险边界清楚；实施模式可以处理。
- **中置信**：方向合理但仍有一个关键未知项；只报告未知项和补证方式。
- **低置信**：主要依据命名、行数或单次搜索；丢弃，不用噪声填充报告。

## 保护不可误删的边界

以下代码即使显得重复，也必须先证明其安全职责可以被等价保留：

- 鉴权、信任边界、权限检查、隐私和敏感数据处理。
- 数据丢失防护、事务、幂等、崩溃恢复和资源释放。
- 并发、任务取消、连接关闭、订阅解绑和平台生命周期。
- 无障碍、国际化、输入校验和用户可见错误语义。
- 公开 API、持久化/序列化格式、数据库迁移和跨版本兼容。
- 生成代码、外部协议、插件/反射入口和发布流程。

不通过删除测试、削弱安全检查、吞掉错误或引入更重依赖来制造“净减法”。这些边界需要产品或兼容性决定时，列出 tradeoff 并请求用户确认。

## 实施一个最小闭环

1. 按“维护概念减少量、证据强度、用户价值、验证成本”排序，选择一个高置信边界。
2. 写出一句话不变量：什么行为必须保持，哪个 owner 在修改后负责它。
3. 端到端删除过时契约：定义、接线、调用方、配置、fixture 和文档一起收口；不要只留下另一种半迁移状态。
4. 更新测试来保护保留行为。只有功能本身被证明移除时才删除对应测试，并保留相邻用户结果的覆盖。
5. 避免顺手重命名、全仓格式化和无关抽象调整，使 diff 能独立审查和回滚。
6. 若实施中暴露第二个独立边界，先记录为后续候选，不自动扩大本次变更。

成功标准是所有权更单一、状态和路由更少、兼容负担下降且行为被验证；原始增删行数只作为辅助信息。

## 分层验证

按成本从低到高执行：

1. 重新搜索已删除符号、旧配置和旧文档引用。
2. 运行修改边界的定向测试、类型检查或编译。
3. 运行仓库要求的更广回归检查。
4. 执行 `git diff --check`，检查 `git status --short` 和完整 diff，确认没有越界文件、调试残留或敏感信息。
5. 对运行时、平台或兼容路径，完成仓库要求的手工/设备验证；未执行的专项必须明确标记，不能用其他测试替代。

验证失败时先判断是基线失败还是本次回归。不要为了让检查通过而扩大修改范围。

## 输出结果

审计模式按优先级报告最多 3 个候选：

```text
候选：用户可感知或维护者可理解的边界
证据：消费者、动态/兼容、历史、验证入口
预期减法：会消失的概念、状态、路由或兼容负担
风险/未知项：尚未闭环的事实
建议：实施 / 补证 / 放弃
```

实施模式先给完成结果，再报告：

- 收敛了哪个边界，保持了什么不变量。
- 删除或合并了哪些概念，不只罗列文件名。
- 运行了哪些验证及结果，哪些专项未运行。
- diff 范围和剩余的中置信候选。
- 需要用户决定的兼容性或产品 tradeoff。

## 来源与改编

方法受到 DeepSeek Harness 的 `dsh-find-simplifications` 工作流和 `Yevanchen/reclaim-code-entropy` 通用化版本启发。本 Skill 重新组织为适用于 Codex 的中文、项目无关、权限敏感工作流；使用时仍以目标仓库事实和约定为准。

- <https://github.com/deepseek-ai/deepseek-harness/tree/master/.agents/skills/dsh-find-simplifications>
- <https://github.com/Yevanchen/reclaim-code-entropy>