gaixianggeng 代码熵回收
在功能持续叠加后，用可验证的减法恢复清晰边界。目标是减少需要维护的概念、状态、路由和兼容负担，不追求任意 LOC 指标，也不把大规模重写包装成“简化”。
选择模式与范围
先根据用户授权选择模式：
- 审计模式：用户说“检查”“审计”“找出”“给建议”时，只读调查并输出候选，不修改文件、分支或外部系统。
- 实施模式：只有用户明确说“处理”“简化”“删除”“直接改”“实施”时才修改；优先实施一个证据最强、可独立验证的边界。
同一请求同时包含调查和修改时，遵循用户最终表达的明确授权；指令矛盾或无法判断时保持只读，并请求确认后再实施。
按以下顺序确定范围：
- 用户指定的文件、模块、提交、PR 或时间窗口。
- 当前分支相对基线的改动及其直接依赖边界。
- 用户要求周期性全仓回收时，使用上次审计后的合并记录；没有记录时，以最近 5–8 个已合并 PR 作为线索窗口，但以仓库当前状态作为事实。
范围会实质改变结果且无法从仓库判断时再询问。不要擅自把局部请求扩大为全仓重构。
先建立仓库事实
- 完整读取当前目录适用的
AGENTS.md和项目文档，沿用仓库技术栈、验证命令、分支约定与权限边界。 - 检查 Git 状态、当前分支、基线和已有改动。用户改动默认受保护；不要清理、回滚或顺手格式化无关文件。
- 找到生产入口、测试入口、代码生成、配置、脚本、插件/反射、平台生命周期与持久化边界。
- 记录当前可执行的最小验证；必要时先跑一次基线，避免把已有失败归因于本次减法。
优先使用仓库已有搜索、语言服务器、编译器、测试和静态分析工具。工具只负责找线索，不能替代证据判断。
生成候选
从以下类别寻找高价值候选：
| 类别 | 常见信号 | 需要证明 |
|---|---|---|
| 无消费者表面 | 导出符号、参数、配置或接口没有调用方 | 不存在动态、外部或兼容消费者 |
| 重复事实 | 同一版本、状态、映射或策略在多处维护 | 能收敛到一个权威所有者 |
| 投机抽象 | 单实现接口、只服务一个调用方的通用层 | 移除后不会关闭近期已确认扩展点 |
| 额外路由或层级 | 纯转发 wrapper、重复 adapter、无决策 coordinator | 边界不承担权限、隔离或生命周期职责 |
| 生命周期重复 | 多个对象同时拥有连接、任务、缓存或重试状态 | 可明确唯一 owner 和清理时机 |
| 错位防御 | 深层静默兜底、吞错、重复校验掩盖非法状态 | 校验能放回可信入口且失败语义更清楚 |
| 手写基础设施 | 自制缓存、重试、解析或调度与现有能力重叠 | 替代方案更小且不增加依赖负担 |
| 迁移与支持残留 | 旧适配器、临时 flag、双写、旧 fixture 或文档 | 迁移已经完成且无回滚/兼容义务 |
| 加入后废弃 | 近期提交加入但后续不再接线的类型或路径 | Git 历史确认意图已被替代或放弃 |
不要把文件很长、命名不喜欢、代码不够“优雅”单独当作候选。复杂度信号必须落到真实维护成本和可删除边界。
为候选建立证据
对每个候选依次完成四项检查：
- 消费者证据：搜索定义、静态引用、构造入口、测试、配置、脚本、文档示例和生成代码。
- 动态与兼容证据：检查反射、序列化、路由注册、插件发现、公开 API、持久化格式、迁移、跨版本和平台回调。
- 历史与所有权证据：使用
git log、git blame和相关提交确认为什么存在、是否仍在迁移，以及哪个边界应拥有职责。 - 验证证据：明确删除或合并后能运行的最小测试、构建、类型检查、静态检查或手工路径。
据此分级：
- 高置信：四项证据闭环，风险边界清楚；实施模式可以处理。
- 中置信：方向合理但仍有一个关键未知项；只报告未知项和补证方式。
- 低置信：主要依据命名、行数或单次搜索；丢弃，不用噪声填充报告。
保护不可误删的边界
以下代码即使显得重复，也必须先证明其安全职责可以被等价保留：
- 鉴权、信任边界、权限检查、隐私和敏感数据处理。
- 数据丢失防护、事务、幂等、崩溃恢复和资源释放。
- 并发、任务取消、连接关闭、订阅解绑和平台生命周期。
- 无障碍、国际化、输入校验和用户可见错误语义。
- 公开 API、持久化/序列化格式、数据库迁移和跨版本兼容。
- 生成代码、外部协议、插件/反射入口和发布流程。
不通过删除测试、削弱安全检查、吞掉错误或引入更重依赖来制造“净减法”。这些边界需要产品或兼容性决定时，列出 tradeoff 并请求用户确认。
实施一个最小闭环
- 按“维护概念减少量、证据强度、用户价值、验证成本”排序，选择一个高置信边界。
- 写出一句话不变量：什么行为必须保持，哪个 owner 在修改后负责它。
- 端到端删除过时契约：定义、接线、调用方、配置、fixture 和文档一起收口；不要只留下另一种半迁移状态。
- 更新测试来保护保留行为。只有功能本身被证明移除时才删除对应测试，并保留相邻用户结果的覆盖。
- 避免顺手重命名、全仓格式化和无关抽象调整，使 diff 能独立审查和回滚。
- 若实施中暴露第二个独立边界，先记录为后续候选，不自动扩大本次变更。
成功标准是所有权更单一、状态和路由更少、兼容负担下降且行为被验证；原始增删行数只作为辅助信息。
分层验证
按成本从低到高执行：
- 重新搜索已删除符号、旧配置和旧文档引用。
- 运行修改边界的定向测试、类型检查或编译。
- 运行仓库要求的更广回归检查。
- 执行
git diff --check，检查git status --short和完整 diff，确认没有越界文件、调试残留或敏感信息。 - 对运行时、平台或兼容路径，完成仓库要求的手工/设备验证；未执行的专项必须明确标记，不能用其他测试替代。
验证失败时先判断是基线失败还是本次回归。不要为了让检查通过而扩大修改范围。
输出结果
审计模式按优先级报告最多 3 个候选：
候选：用户可感知或维护者可理解的边界
证据：消费者、动态/兼容、历史、验证入口
预期减法：会消失的概念、状态、路由或兼容负担
风险/未知项：尚未闭环的事实
建议：实施 / 补证 / 放弃
实施模式先给完成结果，再报告：
- 收敛了哪个边界，保持了什么不变量。
- 删除或合并了哪些概念，不只罗列文件名。
- 运行了哪些验证及结果，哪些专项未运行。
- diff 范围和剩余的中置信候选。
- 需要用户决定的兼容性或产品 tradeoff。
来源与改编
方法受到 DeepSeek Harness 的 dsh-find-simplifications 工作流和 Yevanchen/reclaim-code-entropy 通用化版本启发。本 Skill 重新组织为适用于 Codex 的中文、项目无关、权限敏感工作流；使用时仍以目标仓库事实和约定为准。