从 /simplify 到绝地委员会:如何与 Kent Beck、Martin Fowler 和 Mike Acton 一起进行代码审查

Claude Code 提供了一个名为 /simplify 的 slash command,可以自动审查你的代码。我用它检查了一个大幅变更——大约 8 个文件、500 行代码——结果让人有些意外。它确实发现了些我可能漏掉的点,但也带来了不少无用信息,让我浪费了不少时间。 所以我把它拆解了,然后又重新像拼图一样组装回来。 /simplify 是如何工作的 这是 Claude Code 内置的一项功能(无需额外安装)。它会并行运行三个代理,分别从三个不同的角度来审查代码变更: 代码复用(Code Reuse) —— 是否有可以替换新代码的现有工具? 代码质量(Code Quality) —— 冗余状态、复制粘贴、不良抽象、stringly-typed code 等。 效率(Efficiency) —— 不必要的 I/O、未充分利用的并发、内存泄漏等。 这三个代理会各自给出发现的问题,之后系统尝试直接修复它们。 找到的亮点 代码复用代理发现我在测试代码的两处重复了一个完全相同的辅助函数:相同的名字、相同的代码内容,但分布在两个不同的文件中。我把它提取到一个共享模块里,干净利落。 效率代理指出了一个处理循环中不必要的磁盘操作:每次迭代都加载状态、修改后存储、读取数据、重新加载、再存储。写操作重复了两次,而实际上只需要一次。我没注意到这些隐患,但工具发现了。 还发现了一个内存缓冲区在错误路径中没有清除。如果在分配和释放之间发生错误,会产生内存泄漏。这种问题在主路径上已经被处理到了,但显然 copy-paste 草率遗漏了某些细节。 到这里为止,还算满意。三个发现,全都合法且可操作。但 /simplify 的问题并不在于它发现了什么,而是在于它发现了太多不重要的东西。 存在的缺陷 低级别的问题噪音过多。 它建议我删除一个 struct 的字段,因为 “它与一个计算属性是重复的”。这个字段占用 8 个字节,但被代码和测试中的十多处引用使用。做这个改动带来的代码修改工作量,远远超过了省下这几个字节的好处。 缺乏对项目上下文的理解。 它标记了一个并发模式为 HIGH 严重性,并且的确指出这是一个潜在风险。这一点没错,书面上看是合理的。但实际上,这个问题已经在项目的 CLAUDE.md 文档中记录了,工具链中专门配置了 lint 来应对,并且项目内还有一个相关的 issue 在处理。而 /simplify 并不知道这些,因为它只能基于代码变更的 diff 操作,缺乏项目整体的视角。 无法分辨“错误”和“可优化”。 上文提到的双磁盘操作的确效率低下,但并不是错误。而并发模式的问题就是真正的潜在炸弹。这两者的严重性却都被标记为 MEDIUM,优先级看上去一样,这种扁平的优先级划分很难起到实际帮助。 对外部数据强行推荐 enums。 它建议把某些 DTO 中的字段从字符串转换为枚举,但这些字段只是从外部 API 拉取后用于显示。把它们改成枚举需要自定义解码逻辑,却提供不了任何实际好处——如果对方 API 增加了新值,这样的枚举反倒会导致解析出错。枚举在这种情况下,不如保持字符串更稳妥。 ...

2026年3月9日 · Fernando