
关于
基于经典软件工程著作的 AI 代码审查器,用于捕捉设计异味、耦合问题和架构风险。
name: brooks-lint description: "基于经典软件工程书籍的 AI 代码审查工具,用于捕获设计异味、耦合问题和架构风险。" category: development risk: safe source: community source_repo: hyhmrright/brooks-lint source_type: community license: "MIT" license_source: "https://github.com/hyhmrright/brooks-lint/blob/main/LICENSE" date_added: "2026-04-29" author: hyhmrright tags: [code-review, architecture, software-design, refactoring, claude-code] tools: [claude, codex, cursor, gemini]
Brooks Lint
概述
Brooks Lint 是一个 Claude Code 技能,通过 12 本经典软件工程书籍的视角来审查你的代码。它不检查样式规则,而是问:"《程序员修炼之道》、《代码整洁之道》和《数据密集型应用系统设计》的作者会怎么评价这段代码?"
它将里程碑式工程书籍中的原则综合为可操作的结构化反馈 —— 捕获设计异味、紧耦合、缺失的抽象和架构风险,这些是 linter 和 AI 工具通常遗漏的。
以 Fred Brooks 命名,他是《人月神话》的作者 —— 因为最难的 bug 是概念性的,而非语法性的。
12 本书
| 书籍 | 应用的关键原则 | |------|----------------------| | 《程序员修炼之道》 | DRY、正交性、曳光弹 | | 《代码整洁之道》 | 命名、函数大小、注释清晰度 | | 《人月神话》 | 概念完整性、第二系统效应 | | 《数据密集型应用系统设计》 | 数据一致性、容错、可扩展性 | | 《软件设计的哲学》 | 深模块、信息隐藏、复杂性 | | 《重构》 | 代码异味、提取方法、封装 | | 《修改代码的艺术》 | 接缝、特征测试、依赖打破 | | 《领域驱动设计》 | 通用语言、限界上下文、聚合 | | 《发布!》 | 稳定性模式、超时、舱壁、断路器 | | 《计算机程序的构造和解释》 | 抽象、递归、元语言抽象 | | 《UNIX 编程艺术》 | 模块化、可组合性、最小惊讶原则 | | 《解析极限编程》 | YAGNI、简单设计、集体所有权 |
何时使用此技能
- 当你需要超越 linter 提供的架构反馈时使用
- 在重大重构前使用以识别结构性债务
- 当审查"能工作但感觉不对"的代码时使用
- 当加入新代码库时使用以快速映射风险区域
- 在开始新模块或服务前用于设计审查
工作原理
Brooks Lint 将每本书的核心原则作为审查视角:
- 异味检测:标记违反 DRY、SRP、迪米特法则等的情况
- 耦合分析:识别紧密依赖和缺失的抽象层
- 命名批评:将《代码整洁之道》的命名规则应用于变量、方法、类
- 架构审查:检查 DDIA 风格的数据一致性和容错差距
- 稳定性模式:标记缺失的超时、重试和断路器(《发布!》)
- 复杂度评分:应用 APOSD 复杂度指标识别过度工程化的部分
安装
# Install via Claude Code plugin marketplace
# Search: "brooks-lint" in Claude Code > Extensions
# Or install via NPX (Antigravity)
npx antigravity-awesome-skills --claude
# Then invoke: @brooks-lint
示例
示例 1:审查服务类
@brooks-lint review src/services/PaymentService.ts
Brooks Lint 输出:
[Pragmatic Programmer] DRY violation: payment validation logic duplicated in 3 places
[Clean Code] Method processPayment() does 4 things — violates Single Responsibility
[Release It!] No timeout on external payment gateway call — risk of cascade failure
[DDIA] No idempotency key — retry on network error will double-charge
[APOSD] PaymentService knows too much about UserRepository — high coupling
示例 2:全代码库架构审查
@brooks-lint analyze the overall architecture of this codebase
示例 3:重构前审查
@brooks-lint what are the biggest design smells in this module before I refactor it?
审查类别
| 类别 | 应用的书籍 | 捕获的内容 | |----------|--------------|-----------------| | DRY / 重复 | PP, Refactoring | 复制粘贴代码、未提取的共享逻辑 | | 命名 | Clean Code, DDD | 不清晰的名称、领域语言违规 | | 耦合 | APOSD, PP | 紧密依赖、缺失的接口 | | 稳定性 | Release It! | 缺失的超时、无重试逻辑、无断路器 | | 数据完整性 | DDIA | 竞态条件、非幂等操作 | | 复杂性 | APOSD, SICP | 过度工程化、不必要的抽象 | | 遗留债务 | WELC | 难以测试的代码、缺失的接缝 | | 领域清晰度 | DDD, XP | 贫血模型、缺失的限界上下文 |
最佳实践
- 在 PR 审查中运行 Brooks Lint 以获得超越样式检查的反馈
- 将其与传统 linter 结合使用(ESLint、Prettier 等处理格式,Brooks Lint 处理设计)
- 关注高严重度发现并优先修复
- 使用输出作为团队讨论架构决策的起点
限制
- 仅在任务明确匹配上述范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家审查的替代品。
- 如果缺少必需的输入、权限、安全边界或成功标准,请停下来要求澄清。