代码简化技能评测 — 如何在不动行为的前提下清理代码

代码简化（code-simplifier）这类技能听起来简单——"让代码更干净"——但一旦试图机械化，复杂度就会爆炸。如何教 AI agent 简化代码而不破坏行为？哪些模式应该捕获，哪些应该放过？最重要的是，当你已经有一个可用的技能时，研究别人的版本还有意义吗？

带着这些问题，我们对照了两种实现：Anthropic 的 Claude Code 原始插件和我们适配的 Hermes 版本。结果令人既安心又意外。

原始实现 vs 适配版本

Anthropic Claude Code 插件位于 anthropics/claude-plugins-official 仓库，本质上是 Claude Opus 的一个系统提示词，约 80 行，设计为在每次代码修改后自动运行。它定义了五个原则：保护行为不变、遵循项目规范、增强可读性、保持平衡、限定范围。提示词简洁、命令式，假设 agent 已经通过 CLAUDE.md 了解项目约定。

我们的 Hermes 适配版是一个完整的技能文档，约 300 行，将每个原则扩展为具体模式，并配有 TypeScript、Python 和 React 代码示例。我们额外添加了切斯特顿栅栏（Chesterton's Fence）作为明确的前置步骤，提供了结构复杂度和命名问题的模式对照表，定义了"理解→识别→应用→验证"四步流程，还加入了一个"常见合理化借口"章节来预先反驳开发者跳过简化的各种借口。

Claude 版本做得更好的地方

Anthropic 版本有一个我们没有的特性：自动触发机制。它被设计为写后钩子——Claude Code 每次修改文件后，简化器立即审查并细化。这种紧密的反馈循环确保复杂度不会累积，在同一个会话中就被消除。

我们的版本是需要显式调用的技能。对于计划性的重构没问题，但错过了"边走边清理"的理念。当你写了 200 行虽然能用但很凌乱的代码，不会有人停下来加载代码简化技能。混乱随功能一起发布。

值得借鉴的点： 轻量级的任务后简化检查。不是单独的技能调用，而是任何非平凡的代码生成任务之后的默认行为。Agent 应该自问："在宣布完成之前，我刚刚引入的复杂度能不能简化？"

我们版本做得更好的地方

实践中，我们的技能更实用。Anthropic 提示词优雅但不够具体——它告诉模型做什么，但没说怎么做。"降低不必要的复杂性"是个好原则，却是糟糕的指令。我们版本提供了带有具体示例的模式对照表：

• "深度嵌套（3 层以上）→ 提取为 guard clause"
• "通用名称如 data 或 result → 重命名为描述性名称"
• "函数名 get 但实际也做了修改 → 重命名以反映真实行为"

这些不只是启发式规则，而是决策捷径。Agent 不需要每次都从第一原理推导——它可以对照已知模式库进行匹配。

切斯特顿栅栏前置步骤也是真正新颖的设计——在动手之前，先查 git blame，读原始 PR，理解为什么这段代码以这种形式存在。这防止了最常见的简化失败：删除了你不理解的、有其存在理由的复杂度。

用真实代码测试两个版本

我们用积累了六个月功能开发复杂度的 FastAPI 服务测试了两个实现：

模式	Claude 版本	我们的版本
4 层嵌套 if-else	捕获，展平为 guard clause	捕获，并建议具体异常类型
7 处使用的魔法字符串	建议提取常量，命名一般	提取为枚举，命名描述性强
data 变量用于 4 种不同类型	漏报（模式太模糊）	捕获，拆分为类型化变量
return 语句中的冗余 await	捕获，移除	捕获，移除
只有一个策略的过度工程化策略模式	完全漏报	标记审查，建议内联

差异源于具体性。我们版本的模式对照表给了 agent 具体的东西去寻找，而不仅仅是需要应用的抽象原则。

应该引入外部版本吗？

不需要——但应该借鉴一个特性。

我们的技能已经覆盖了 Anthropic 版本的所有内容，而且更全面。模式对照表、切斯特顿栅栏、语言特定示例都让它更具可操作性。我们缺少的是自动触发：在任务完成后"能不能更简单？"这个内置习惯，而非需要单独调用的技能。

最简单的实现路径：在我们现有的编码技能流程中增加一个"简化检查"。任何 50 行以上的代码生成任务结束后，Agent 花一分钟扫描三类最常见模式（深度嵌套、通用命名、冗余结构）。没发现就算了，发现了就标记——不是作为单独重构，而是"宣布完成前的最后一件事"。

最终判断

保留我们自己的版本。它客观上更适合我们的使用场景——更具体、更可操作、文档更好。借鉴 Anthropic 的自动触发模式，将其融入编码工作流。一个好的简化习惯，胜过没人记得调用的完美简化技能。