brooks-lint：把十二本经典书变成代码审查的判决依据

它解决的不是风格问题，而是腐烂问题

这个工具的服务对象是那些已经厌倦了模板化审查意见的工程团队。它想让你在 PR 讨论里看到的不是“建议提取函数”这种空话，而是“Fowler 在《重构》里把这种情况称为 Divergent Change，你的 loyalty 公式改动会波及邮件通知”。它把书里的智慧变成具体的、可引用的判决。

六类衰变风险：从认知负荷到领域模型扭曲

brooks-lint 的诊断框架是六类生产代码衰变风险。认知负荷衡量理解代码所需的心智努力，来源包括《代码大全》和《重构》。变更传播检查一次修改会弄坏多少无关事物，引用了《重构》和《清洁架构》。知识重复检查同一个决定是否在多个地方出现，依据是《程序员修炼之道》。意外复杂度判断代码是否比问题本身更复杂，来源里有《人月神话》。依赖混乱检查依赖方向是否一致，依据包括《清洁架构》和《Google 的软件工程》。领域模型扭曲评估代码是否忠实表达业务领域，来源是《领域驱动设计》。每一类都有明确的诊断问题和对应的书。测试套件还有另外六类风险，来源包括《单元测试的艺术》和《xUnit 测试模式》。这个分类不是拍脑袋，每个风险都对应书里的具体章节或概念。

一次审查的产物：症状、来源、后果、补救

这种结构化的输出意味着你不必再自己从一堆模糊建议里猜问题。它把书里的原则翻译成了可执行的动作。但它也意味着输出会很长，一个方法就能产生八条以上的发现。你要有心理准备，审查结果可能比代码本身还长。

六种分析模式：从快速审查到全量自动修复

你需要自己试一下才能知道 /brooks-sweep 的自动修复到底改了什么。从仓库结构看，它依赖 skills 目录下的定义，每个命令对应一组 skill。这种设计让它能适配多个 AI 平台，而不只是锁定在某一个。

安装与运行：一条命令接入多个平台

这种安装方式的好处是低门槛，坏处是你得信任一条从 GitHub 拉下来的脚本。在你把它跑进 CI 之前，最好先读一遍 install.sh 的内容，确认它只做它声称的事情。

局限与误用场景：它不会替你思考

另一个明显的局限是它依赖 AI 平台来执行。它本身不是一个独立的 linter，而是一组 skill 定义。这意味着它的行为会随着底层模型的变化而变化，同一个代码库在不同平台上跑，结果可能不一致。如果你追求的是确定性的、可重复的静态分析，这个工具不是那个东西。它更适合作为人工审查的辅助，而不是替代。

替代方案：从传统 linter 到通用 AI 审查

代价是它的覆盖面窄。它只关心那六类衰变风险，不会检查代码风格、性能问题或者安全漏洞。SQL 注入在例子里被提到了，但那是因为它属于依赖混乱或意外复杂度的范畴，不是专门的安全扫描。如果你需要安全审查，你还是得用专门工具。

维护成本与许可证

从仓库布局看，核心逻辑都在 skills 目录下，这意味着你可以直接阅读和修改那些 skill 定义。如果你发现某个风险分类不适合你的项目，你可以调整它。这是 MIT 许可证给你的自由，但也意味着你得自己维护 fork。

编辑结论

brooks-lint 适合那些已经受够了泛泛而谈的 AI 审查意见、希望每个发现都能追溯到具体工程原则的团队。它不适合把审查当作走过场的人，因为它的输出要求你认真对待 Symptom、Source、Consequence、Remedy 四段结构，并且要接受它可能误报的现实。在采用之前，先确认你的代码库能被它支持的平台正确加载，跑一次 /brooks-sweep 看看误报率是否在可接受范围内，再决定是否把它接入 CI。它不会替代人的判断，但它能把《重构》和《代码大全》里的老教训，变成每次提交时都在场的监督者。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes