古法编程

Code Reviewer、Build Error Resolver 与 Doc Updater 是 Everything Claude Code 插件体系中保障代码质量、构建可靠性与文档同步的三个核心自动化 Agent。它们通过标准化的工作流与 AI 执行相结合，解决了直接使用编程助手时审查不全面、修复易过度、文档易过时的痛点。本文将分别深入解析其工作机制、协作模式与最佳实践。

核心开发 Agent 全景：Code Reviewer、Build Error Resolver 与 Doc Updater 的工作原理

在 AI 辅助编程的工程化实践中，仅仅依赖编程助手的即时对话能力往往不足以构建可靠、可维护的生产级软件。Everything Claude Code 体系引入了多个专职 Agent，将关键开发活动封装为标准化的自动化流程。其中，Code Reviewer、Build Error Resolver 与 Doc Updater 构成了保障开发闭环质量的铁三角，分别负责代码质量守门、构建错误修复与文档实时同步。

Code Reviewer：多维度审查与结构化报告

Code Reviewer Agent 的目标是在代码变更后自动或手动执行高标准的质量、安全性与可维护性审查。它的工作原理并非简单地让大模型“看代码”，而是一套集成的系统流程。

工作流程与核心机制：

  1. 自动上下文收集：Agent 首先会收集完整的变更上下文，包括 git diff --staged、git diff、git log 等，避免只审查片段导致误判。
  2. 多维度检查清单执行：基于预定义的清单进行扫描，涵盖：
    • 安全：硬编码密钥、SQL注入、XSS、认证缺陷等。
    • 代码质量：函数/文件过大、嵌套过深、死代码、缺少测试。
    • 框架专项：如 React 的依赖数组、Next.js 的数据获取。
    • AI 代码生成风险：特别关注行为回归、安全假设、架构漂移。
  3. 置信度过滤与分级输出：只报告置信度高于80%的问题，并严格按 CRITICAL（必须立即修复）、HIGH（建议修复）、MEDIUM（可选优化）、LOW（仅供参考）四级分类。每个问题都包含文件、行号、问题描述与修复建议。
  4. 项目规范适配：自动读取 CLAUDE.md 或项目规则文件，使审查标准与团队约定保持一致。

与直接对话 Claude 的本质区别在于其流程的标准化和结构化。开发者无法确保每次手动提问都涵盖所有安全点，也难以将杂乱的对话输出集成进 CI/CD。Code Reviewer 的结构化报告可以被后续自动化流程解析。

Build Error Resolver：最小变更修复策略

当项目构建失败时，Build Error Resolver Agent 被激活。它的核心哲学是 “只修复阻断构建的最小必要变更”，坚决避免“过度修正”。

工作原理与约束：

  1. 错误归类与优先级排序：Agent 会解析构建命令（如 npx tsc --noEmit、npm run build）的输出，将错误归类为类型错误、依赖缺失、配置问题等，并按照阻断构建的严重程度排序。
  2. 执行最小化修复：严格遵循以下原则：
    • 只修复，不重构：不调整架构、不添加新功能、不优化风格。
    • 每次只修一个错误：迭代修复，每修复一个错误就重新验证构建状态，直到通过。
    • 修复模式固定：例如，对隐式 any 添加类型注解，对可能为 undefined 的对象添加 ?. 或 if 判断，修正错误的导入路径。
  3. 自动验证与迭代：修复后立即运行构建命令进行验证。如果仍有错误，重复上述步骤。这个过程是自动且迭代的。
  4. 边界清晰：它不会补充测试、不会进行安全扫描、也不会做业务逻辑层面的修改。这些需求应交由其他 Agent（如 TDD Guide 或 Security Reviewer）处理。

典型修复示例：面对 Type 'undefined' is not assignable to type 'User' 和 Cannot find module 两个错误，Agent 会先为 user 属性添加类型守卫或可选标记，再检查并修正模块导入路径，而非重写整个组件。

Doc Updater：基于代码的文档自动化

Doc Updater Agent 解决了文档与代码脱节的经典难题。它不基于记忆或上下文“生成”文档，而是以代码库为唯一信源进行分析和映射。

核心工作机制：

  1. 代码结构分析：利用 AST（抽象语法树）、依赖分析工具（如 madge）解析项目，真实掌握模块、入口、API、数据库模型等结构。
  2. Codemap 自动生成：在 docs/CODEMAPS/ 目录下生成结构化的 Markdown 文件，如 INDEX.md、frontend.md、backend.md。每份 Codemap 控制在 500 行以内以保证可读性，并包含依赖关系图和数据流 ASCII 图。
  3. 变更感知与触发：当检测到新增/删除主要模块、API 路由或架构调整时自动触发。也可通过 /update-codemaps 等命令手动调用。
  4. 质量保障与交叉引用：输出带时间戳的文档，自动校验文档中的路径、代码片段和链接是否有效，并在相关文档间建立交叉引用。

与让 Claude 直接写 README 相比，Doc Updater 保证了信息的绝对准确性和实时性，避免了因上下文有限而产生的“猜测性”错误。

协作与工作流集成

这三个 Agent 并非孤立工作，而是与 Everything Claude Code 中的其他组件构成闭环：

  • 典型工作流：Build Error Resolver 确保构建通过 → Code Reviewer 进行质量审查 → Doc Updater 同步文档变更。
  • 与 Hook 体系集成：可以配置在 pre-commit 或 post-merge 等 Hook 中自动触发 Code Reviewer 或 Doc Updater，实现流程的强制执行。
  • 扩展协作：Code Reviewer 发现的安全问题可派发给 Security Reviewer Agent；测试覆盖不足可联动 TDD Guide Agent。这种多 Agent 编排能力，使得从代码生成到交付的全程质量控制成为可能。

FAQ

Q: Code Reviewer Agent 会不会自动修复它发现的问题？ A: 不会。Code Reviewer 只负责发现、分级和报告问题。自动修复需要结合 Build Error Resolver（针对构建/类型问题）或人工介入。

Q: Build Error Resolver 能否处理业务逻辑 Bug？ A: 不能。它严格限定于修复阻断构建的类型、依赖和配置错误，不会触碰业务逻辑。业务逻辑问题应由人工评审或其他专项 Agent 处理。

Q: 如何让 Doc Updater 知道要生成哪些文档？ A: Doc Updater 基于代码结构自动生成标准化 Codemap。如果需要更新 README 等特定文件，它会从代码注释（如 JSDoc）中提取信息进行更新。自定义内容区域需妥善保留，Agent 不会覆盖。