Repomix 多 Agent 代码评审闭环review-loop 迭代评审与修复工作流深入解析【免费下载链接】repomix Repomix is a powerful tool that packs your entire repository into a single, AI-friendly file. Perfect for when you need to feed your codebase to Large Language Models (LLMs) or other AI tools like Claude, ChatGPT, DeepSeek, Perplexity, Gemini, Gemma, Llama, Grok, and more.项目地址: https://gitcode.com/GitHub_Trending/rep/repomix导读.agents/commands/code/review-loop.md是 Repomix 仓库为 AI 编码代理Agent定义的一套迭代式评审-修复闭环命令规范以当前分支相对main的改动为对象并行拉起 6 个专职评审 Agent代码质量、安全、性能、测试覆盖、规范一致性、全局视角由主代理orchestrator对评审结果进行 Triage 过滤仅修复确凿缺陷并用npm run lint与npm run test验证回归循环直至无待修项或达到 3 轮上限。读完本文你将掌握这套多视角评审 人类式裁决 最小修复 回归验证的完整工程方法论并能结合仓库中的 6 份评审 Agent 定义文件理解每个评审维度背后的检查清单、严重度分级与输出规范。一、工作流全景五步循环的骨架命令文档review-loop.md将整个流程定义为对当前分支相对main的改动循环执行以下 5 步最多 3 轮迭代步骤动作关键约束1. Review并行拉起 6 个评审 Agent每个 Agent 面向单一专业维度不预先过滤发现2. Triage主代理人工式裁决丢弃低置信度/低严重度项区分 Fix 与 Skip改动前先展示表格3. Fix只修复 Fix 类条目保持改动最小化禁止顺手重构4. Verify运行npm run lint和npm run test修复回归后重复本步直至全部通过5. Re-review只复审新改动的行不重新翻旧账不重复提出已 Skip 的条目循环的终止条件有两个满足其一即停止不再存在任何 Fix 类条目已达到 3 轮迭代上限。停止后必须打印一份总结说明修复了什么、跳过了什么what was fixed and what was skipped。这套设计的关键思想是评审 Agent 负责广撒网不预过滤全部上报主代理负责做裁决你是过滤器。文档原文明确写道The agents do not pre-filter: they report everything with a severity and a confidence level, andyou are the filter.Agent 不做预过滤它们上报一切并标注严重度与置信度你才是过滤器。这与传统AI 直接按评审意见改代码的模式有本质区别把最终判断权保留在编排者手中。二、Review 阶段六个并行专职评审 Agent命令要求同时拉起 6 个评审 Agent它们在 .agents/agents/ 目录下均有独立定义文件。注意该目录实际包含 8 份 Agent 定义多出的reviewer-cross-platform.md与reviewer-docs-i18n.md面向跨平台与文档国际化场景可按需替换进工作流而 review-loop 默认启用的 6 个专职角色如下。2.1 reviewer-code-quality代码质量评审定义文件reviewer-code-quality.md职责是审查 bug、逻辑错误、边界情况与代码坏味道code smells。严重度四级划分Critical会导致崩溃、数据丢失或静默数据损坏合并前必须修复High在真实条件下行为不正确、资源泄漏、竞态条件合并前应修复Medium防御性改进、潜在未来问题、可维护性隐患建议处理Low不影响正确性的建议作者可自行取舍。其检查清单覆盖 8 大关注域是判断代码质量缺陷时最实用的操作手册Bug 与逻辑错误off-by-one、不可达代码、switch 穿透、空值解引用、用||给0/这类合法但为假的值做默认值应优先用??、宽松相等导致的类型强转问题异步与并发浮动 Promise未await/未.catch()/未void标注、共享可变状态竞态、TOCTOU、Promise.all与Promise.allSettled误用、循环中不必要的串行await资源管理流/文件句柄/套接字在错误路径未关闭、监听器未移除、定时器未清理、缺少try/finally或usingSymbol.dispose错误处理空catch吞错、捕获unknown后未收窄类型即按特定类型处理、回调式与 Promise 式错误处理混用API 契约违背前置条件假设不成立、后置条件被破坏、循环/类/模块不变量被破坏TypeScript 类型安全any泄漏、无运行时校验的as断言、对合法可空值使用!、联合类型分支不完整且无穷尽检查代码坏味道过长的函数、超长参数列表超过 3~4 个参数提示应改为 options 对象、功能嫉妒、霰弹式修改、死代码、重复逻辑测试质量当 diff 含测试时断言实现细节而非行为、同义反复断言、mock 复制实现。输出格式为每条发现按[SEVERITY] 标题 Location / Confidence / Issue / Risk / Suggestion五要素组织并按严重度分组Critical 在前。2.2 reviewer-security安全评审定义文件reviewer-security.md专注 TypeScript/Node.js 场景的安全漏洞与不安全模式每条发现都标注 CWE 编号。严重度分级Critical可被利用且影响大RCE、数据泄露、认证绕过需立即修复、High中等影响或需特定条件、Medium可利用性/影响有限纵深防御层面、Low当前用法下风险极小但违背安全最佳实践。关注域覆盖 11 类注入CWE-78/94/79child_process.exec()传未净化输入应改用execFile()/spawn()参数数组、eval()/Function()构造器、模板注入、XSS路径穿越与文件系统CWE-22用户可控路径直接进fs操作、未校验解析后路径是否落在预期基目录内、符号链接逃逸、不安全的临时文件创建原型污染CWE-1321递归对象合并/克隆未拦截__proto__、constructor、prototype键不安全反序列化CWE-502JSON.parse未信任输入喂给递归合并、YAML/XML 解析开启不安全选项SSRFCWE-918用户提供的 URL 未校验、未拦截私网 IP 段127.0.0.0/8、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.169.254、未防 DNS rebinding密钥暴露CWE-798/532硬编码凭据、密钥被写入日志、经命令行参数传递密钥、.env未进.gitignoreReDoSCWE-1333嵌套量词、重叠交替导致灾难性回溯、new RegExp(userInput)未转义密码学弱点CWE-327/328MD5/SHA1 用于安全目的、而非crypto.timingSafeEqual()、Math.random()代替crypto.randomBytes()错误处理的安全面CWE-209/755错误响应泄露堆栈与内部路径、fail-open 模式、未处理的 Promise rejection供应链与依赖无理由新增依赖、依赖的postinstall生命周期脚本、未固定的依赖版本资源耗尽CWE-770/400缺少请求体大小限制、无界内存分配、同步/CPU 密集任务阻塞事件循环。输出格式按 7 要素Severity → Confidence → Category CWE → Location → Finding → Attack scenario含前置条件→ Mitigation尽量附代码建议。安全评审还强调优先级排序RCE 数据外泄 提权 拒绝服务 信息泄漏。2.3 reviewer-performance性能评审定义文件reviewer-performance.md只报告**越过 Flagging Threshold标记阈值**的发现明确把微优化排除在范围之外。标记阈值至少满足其一才上报比必要复杂度更差如 O(n²) 而 O(n) 可行在热路径上阻塞事件循环相当长的时间在长驻进程中导致无界内存增长造成资源泄漏文件句柄、监听器、定时器、连接在可证明的热路径上触发已知的 V8 去优化。检查清单包括算法复杂度循环内concat()构建数组、用Array.includes()做重复查找应换Set/Map、事件循环与并发热路径同步 I/O、独立操作应Promise.all、CPU 密集任务应交给worker_threads、process.nextTick递归应改setImmediate、资源泄漏、内存与 GC 压力热循环内大对象分配、无界增长、应流式而非整文件读入内存、不必要的展开拷贝、正则安全ReDoS、V8 优化提示多态函数参数、delete操作符、创建后修改对象形状、缓存机会重复昂贵计算未记忆化、重复 I/O。性能评审的输出每项包含 SeverityCritical导致 outage/OOMHigh可度量影响Medium规模放大Low改进机会、Confidence、Location、Issue、Impact尽量量化如O(n*m) per request、Fix。阈值判断以真实规模的冲击为准而不是以置信度为准——有证据但无法量化的成本也应带置信度标注上报。2.4 reviewer-test-coverage测试覆盖评审定义文件reviewer-test-coverage.md采用基于风险的优先级排序来寻找缺失测试并给出具体测试用例建议而非笼统的多写测试。优先级矩阵从高到低优先级类别示例Critical数据完整性、认证、安全敏感逻辑校验、净化、访问控制、密码学High复杂条件逻辑3 分支、嵌套条件解析器、状态机、规则引擎、分发器High错误处理与恢复路径catch 块、重试、回退、清理Medium公共 API 面与契约导出函数、CLI 标志、配置 schema、事件处理器Medium状态转换与副作用状态变更、资源生命周期、缓存行为Low逻辑直白的内部辅助函数纯工具函数、简单转换Skip不太可能藏缺陷的琐碎代码简单委托、类型定义、常量、属性访问该 Agent 还内置了一整套测试设计技法用于寻找缺失用例等价类划分有效/无效输入、空/单元素/多元素集合、正/零/负数、ASCII/Unicode/特殊字符、边界值分析0、1、-1、MAX_SAFE_INTEGER、端口 0/65535、off-by-one、状态转换覆盖合法转换、非法转换、终态可达性、决策逻辑覆盖每个布尔条件独立翻转、短路求值不掩盖 bug、错误路径分析失败模式是否被区分、清理/回滚是否被验证。在既有测试质量评估上它引入变异测试心智模型对每条断言自问如果在产品代码中埋一个小 bug翻转操作符、删掉条件、改动边界这个测试能抓住吗抓不住即为假信心。需要标记的测试坏味道包括无意义断言、Assertion Roulette多断言无描述消息、Eager Test、魔法数字、Mystery Guest依赖外部状态、实现耦合、测试内条件逻辑、Sleepy Test用 setTimeout 代替假定时器、冗余断言、过度 mock。2.5 reviewer-conventions规范一致性评审定义文件reviewer-conventions.md聚焦lint/格式化工具抓不到的语义一致性问题语义一致性、架构模式、API 设计连贯性、命名清晰度。评审方法论分三步发现规范基线先读项目规则文件.agents/rules/、CLAUDE.md、CONTRIBUTING.md找显式约定再看同模块既有代码找隐式模式并记录项目的依赖注入方式、错误处理风格、文件组织与命名惯用法检查语义一致性命名是否如实描述行为返回null的getUser应叫findUser、同类概念命名是否统一别混用remove/delete/destroy、布尔命名是否自然isValid/hasPermission/shouldRetry而非valid/permission、新函数参数顺序与既有代码是否一致、错误上报风格是否统一throw vs return null vs Result、新文件是否放在合适的特性目录、JSDoc 注释与改动后代码是否仍一致警惕描述旧行为的过期注释、barrel 文件index.ts是否同步更新评估一致 vs 改进的张力当改动引入了客观上更好的新模式时应标注为讨论点而非缺陷建议如果团队认可新方案考虑更新约定并迁移既有代码不应用风格改进阻塞 PR。输出格式每项包含 Typedeviation破坏既有约定 /discussion更好但不一致、Severity、Confidence、Convention注明来源、Location、Finding、Suggestion。权重排序为错误处理不一致 公共 API 不一致 命名不一致 文件组织不一致 注释风格不一致。2.6 reviewer-holistic全局视角评审定义文件reviewer-holistic.md定位是只见森林不见树——只报告其他专职评审大概率漏掉的跨切面问题不重复它们的发现。六大关注域设计连贯性抽象层级是否恰当、模块单一职责是否被破坏、是否引入向上/循环依赖、质量属性权衡性能 vs 可维护性是否被作者忽略变更影响分析系统化追踪传播链——直接依赖者、传递依赖者、共享状态全局变量、单例、缓存、配置对象、环境变量、事件/回调链的时序变化、配置 schema 改动的下游消费者如果变更封装良好、涟漪极小这本身就是一条有价值的正向发现契约与兼容性结构性变化移除/重命名导出、函数签名变更、CLI 标志/配置键被删与行为性变化同接口不同输出、错误类型/消息/条件改变、默认值改变、输出排序或时序变化并据此判断语义化版本号该走 patch/minor/major用户与运维影响升级体验是否需要迁移步骤、走查 2~3 条受影响用户工作流、新失败模式的报错是否清晰可执行、文档是否失准Premortem 预演分析借鉴 Gary Klein 的 premortem 技术假设变更已上线并引发事故反推 1~3 条具体失败故事上线两周后用户报告 X根因是 Y团队没发现是因为 Z并评估严重性数据丢失 错误输出 体验降级 外观问题、可能性、检测难度、爆炸半径范围/可逆性/恢复时间跨切面关注日志与可观测性、错误处理模式一致性、并发与排序、平台/环境敏感性Windows/macOS/Linux、Node 版本、CI 环境、仓库规模。输出每项含 Severity、Confidence、Area上述 6 节之一、Finding、Evidence具体模块/函数/工作流、Recommendation并按影响优先排序。三、Triage 阶段编排者才是过滤器六路并行评审会产生大量候选发现命令文档为编排者也就是运行此命令的主 Agent制定了明确的裁决纪律不盲从只保留自己也认为值得注意的条目丢弃低置信度或低严重度的项——除非你能对着代码亲自确认它unless you can confirm them against the code yourself二分法分类幸存条目必须归类为Fix明确缺陷必须修或Skip风格问题、吹毛求疵、范围蔓延透明呈现动手改动任何代码之前先展示一张简明的决策表格。这套 Triage 机制与各评审 Agent 定义中的不预过滤约定是配套的Agent 端明确写着Do not pre-filter borderline findings -- the orchestrator triages your report and drops what it disagrees with, so a finding you suppress is lost while one it rejects costs a line不要预过滤边缘发现——编排者会裁决并丢弃它不同意的项被你压下的发现会丢失而被它否决的发现只损失一行文本。也就是说Agent 隐瞒发现是信息损失编排者否决发现只是成本开销两者权衡之下鼓励有疑必报、有据必审。Skip 类的典型内容在多个 Agent 的 Guidelines 中也有明确定义格式、样式、导入顺序、命名约定除非真的误导、TODO 注释除非指向未完成代码路径、自动生成代码、小集合上的循环风格偏好、冷路径上的微分配等。这为跳过什么提供了仓库内的判断依据。四、Fix 与 Verify最小改动与回归门禁4.1 Fix只修该修的命令规定Fix only the Fix items. Keep changes minimal.只修 Fix 条目保持改动最小化。这意味着一轮循环内不得顺手重构、不得扩大范围避免评审引起的二次回归。4.2 Verify两级质量门禁修复完成后必须运行两个验证命令全部通过才能进入下一轮npm run lint npm run test这两个命令在根目录 package.json 中有精确定义值得拆开看它们的实际构成npm run lint是一个组合命令依次执行lint-biomebiome check --write风格与格式化检查Biome 配置见 biome.jsonlint-oxlintoxlint --fix静态规则检查lint-tstsc --noEmitTypeScript 全量类型检查不做产物输出lint-secretlintsecretlint **/* --secretlintignore .gitignore密钥/敏感信息扫描与安全评审 Agent 的 Secret Exposure 关注域呼应。npm run test即vitest仓库测试体系庞大与src/目录结构镜像对应见 tests/ 下的core/、config/、cli/、mcp/、shared/等子目录覆盖文件收集、git 集成、metrics 统计、输出样式、tree-sitter 解析、MCP 工具等核心模块。命令还要求Fix any regressions and repeat this step until all checks pass before continuing.修复任何回归并重复本步直到所有检查通过再继续。也就是说 Verify 内部同样是一个小的收敛循环。4.3 Re-review只审增量进入下一轮 Review 时范围被严格限定为上一轮新改动的行Re-review only the newly changed lines且不得重新提出已 Skip 的条目Do not re-raise skipped items。这保证了迭代的单调收敛每一轮只针对增量引入的新风险做检查而不会因为反复翻炒旧账导致死循环或评审疲劳。五、终止条件与总结输出循环在无 Fix 剩余或达到 3 轮迭代时终止。需要特别说明两点工程语义3 轮上限是硬约束即使仍有遗留的 Fix 条目也不得无限循环。这避免了对同一处代码反复修改引入的新风险失控是一种务实的成本控制总结必须显式输出最终要打印修复了什么、跳过了什么这既是对本轮工作的可审计留痕也为后续的 PR 评审见下文提供了上下文。从该命令所在目录 .agents/commands/code/ 还能看到它的近亲变体codex-review-loop.md同一套五步循环但 Review 阶段改为拉起单个 codex 评审 Agent而非 6 个并行 Agent适用于评审预算有限或使用 codex 工具链的场景pr-review.md 与 pr-prepare.md可视为本闭环的前后延伸——review-loop 产出的修复/跳过总结可以直接喂给 PR 评审与 PR 创建流程。六、与项目规则的衔接评审结论如何落地review-loop 中的conventions 评审和 Fix 阶段的改动都应当对齐 .agents/rules/base.md 中沉淀的核心工程约定否则 Verify 阶段可能直接失败编码规范由 Biomebiome.json强制执行文件保持单一职责约250 行作为审视文件内聚性的信号注意是审视信号而非拆分命令单一内聚主题的长文件可保持不变提交信息遵循 Conventional Commits 规范格式为type(scope): Description如feat(cli): Add new --no-progress flag正文遵循contextual-commitskill 的指引可测试性依赖通过deps对象参数注入以便测试替身替换仅当依赖注入不可行时才用vi.mock()export const functionName async ( param1: Type1, param2: Type2, deps { defaultFunction1, defaultFunction2, } ) { // 使用 deps.defaultFunction1() 而非直接调用 };平台差异意识根目录npm run lint并不对 website client 做类型检查改动website/client需在该目录单独验证配置 JSON schemawebsite/client/src/public/schemas/由脚本生成禁止手改面向用户的功能变更需同步更新全部 15 个语言目录的文档。这些规则与 review-loop 的对应关系很直接代码质量/规范评审 Agent 的发现往往对应 base.md 的编码与依赖注入约定性能评审与测试覆盖评审的发现则对应为新特性提供单元测试的硬性要求而 Verify 步骤恰好验证每次变更都通过npm run lint与npm run test这一仓库级红线。七、适用前提与使用限制基于当前仓库内容使用本工作流需要注意以下前提与边界运行环境Verify 步骤依赖 Node.js 环境与根目录依赖安装完成package.json声明engines.node 22.0.0lint-ts使用 TypeScript 7、测试框架为 Vitest需先执行依赖安装对比基线循环针对当前分支相对main的改动评审要求仓库存在main分支且分支间有可 diff 的改动首次运行前请确认分支状态多 Agent 场景默认 6 个评审 Agent 并行对上下文窗口与 token 预算有较高要求预算有限时可改用 codex-review-loop.md 的单 Agent 变体评审范围纪律Re-review 只覆盖新增行、Skip 条目不翻案、Fix 保持最小化——这三点共同保证循环在 3 轮内收敛实践中应避免扩大评审范围裁决责任文档明确把最终判断权交给编排者所有 Agent 结论都需经过自己确认代码这一步不可直接照单全收。结语review-loop 提供的不只是一条命令而是一套可复用的多 Agent 协作评审范式专职 Agent 广撒网保证召回率编排者 Triage 保证精确率最小化修复与控制迭代上限保证收敛性linttest双门禁保证安全性。配合仓库中 6 份评审 Agent 定义中详尽的检查清单从 O(n²) 复杂度到 CWE 注入、从等价类划分到 premortem 预演这套工作流既是 Repomix 自身工程的实践沉淀也可以作为任何 Node.js/TypeScript 项目搭建 AI 驱动评审闭环的参考蓝本。若要在自己的分支上立即体验只需在改动就绪后让 AI 代理读取 review-loop.md 并按其中的五步循环执行即可。【免费下载链接】repomix Repomix is a powerful tool that packs your entire repository into a single, AI-friendly file. Perfect for when you need to feed your codebase to Large Language Models (LLMs) or other AI tools like Claude, ChatGPT, DeepSeek, Perplexity, Gemini, Gemma, Llama, Grok, and more.项目地址: https://gitcode.com/GitHub_Trending/rep/repomix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Repomix 多 Agent 代码评审闭环：review-loop 迭代评审与修复工作流深入解析
Repomix 多 Agent 代码评审闭环review-loop 迭代评审与修复工作流深入解析【免费下载链接】repomix Repomix is a powerful tool that packs your entire repository into a single, AI-friendly file. Perfect for when you need to feed your codebase to Large Language Models (LLMs) or other AI tools like Claude, ChatGPT, DeepSeek, Perplexity, Gemini, Gemma, Llama, Grok, and more.项目地址: https://gitcode.com/GitHub_Trending/rep/repomix导读.agents/commands/code/review-loop.md是 Repomix 仓库为 AI 编码代理Agent定义的一套迭代式评审-修复闭环命令规范以当前分支相对main的改动为对象并行拉起 6 个专职评审 Agent代码质量、安全、性能、测试覆盖、规范一致性、全局视角由主代理orchestrator对评审结果进行 Triage 过滤仅修复确凿缺陷并用npm run lint与npm run test验证回归循环直至无待修项或达到 3 轮上限。读完本文你将掌握这套多视角评审 人类式裁决 最小修复 回归验证的完整工程方法论并能结合仓库中的 6 份评审 Agent 定义文件理解每个评审维度背后的检查清单、严重度分级与输出规范。一、工作流全景五步循环的骨架命令文档review-loop.md将整个流程定义为对当前分支相对main的改动循环执行以下 5 步最多 3 轮迭代步骤动作关键约束1. Review并行拉起 6 个评审 Agent每个 Agent 面向单一专业维度不预先过滤发现2. Triage主代理人工式裁决丢弃低置信度/低严重度项区分 Fix 与 Skip改动前先展示表格3. Fix只修复 Fix 类条目保持改动最小化禁止顺手重构4. Verify运行npm run lint和npm run test修复回归后重复本步直至全部通过5. Re-review只复审新改动的行不重新翻旧账不重复提出已 Skip 的条目循环的终止条件有两个满足其一即停止不再存在任何 Fix 类条目已达到 3 轮迭代上限。停止后必须打印一份总结说明修复了什么、跳过了什么what was fixed and what was skipped。这套设计的关键思想是评审 Agent 负责广撒网不预过滤全部上报主代理负责做裁决你是过滤器。文档原文明确写道The agents do not pre-filter: they report everything with a severity and a confidence level, andyou are the filter.Agent 不做预过滤它们上报一切并标注严重度与置信度你才是过滤器。这与传统AI 直接按评审意见改代码的模式有本质区别把最终判断权保留在编排者手中。二、Review 阶段六个并行专职评审 Agent命令要求同时拉起 6 个评审 Agent它们在 .agents/agents/ 目录下均有独立定义文件。注意该目录实际包含 8 份 Agent 定义多出的reviewer-cross-platform.md与reviewer-docs-i18n.md面向跨平台与文档国际化场景可按需替换进工作流而 review-loop 默认启用的 6 个专职角色如下。2.1 reviewer-code-quality代码质量评审定义文件reviewer-code-quality.md职责是审查 bug、逻辑错误、边界情况与代码坏味道code smells。严重度四级划分Critical会导致崩溃、数据丢失或静默数据损坏合并前必须修复High在真实条件下行为不正确、资源泄漏、竞态条件合并前应修复Medium防御性改进、潜在未来问题、可维护性隐患建议处理Low不影响正确性的建议作者可自行取舍。其检查清单覆盖 8 大关注域是判断代码质量缺陷时最实用的操作手册Bug 与逻辑错误off-by-one、不可达代码、switch 穿透、空值解引用、用||给0/这类合法但为假的值做默认值应优先用??、宽松相等导致的类型强转问题异步与并发浮动 Promise未await/未.catch()/未void标注、共享可变状态竞态、TOCTOU、Promise.all与Promise.allSettled误用、循环中不必要的串行await资源管理流/文件句柄/套接字在错误路径未关闭、监听器未移除、定时器未清理、缺少try/finally或usingSymbol.dispose错误处理空catch吞错、捕获unknown后未收窄类型即按特定类型处理、回调式与 Promise 式错误处理混用API 契约违背前置条件假设不成立、后置条件被破坏、循环/类/模块不变量被破坏TypeScript 类型安全any泄漏、无运行时校验的as断言、对合法可空值使用!、联合类型分支不完整且无穷尽检查代码坏味道过长的函数、超长参数列表超过 3~4 个参数提示应改为 options 对象、功能嫉妒、霰弹式修改、死代码、重复逻辑测试质量当 diff 含测试时断言实现细节而非行为、同义反复断言、mock 复制实现。输出格式为每条发现按[SEVERITY] 标题 Location / Confidence / Issue / Risk / Suggestion五要素组织并按严重度分组Critical 在前。2.2 reviewer-security安全评审定义文件reviewer-security.md专注 TypeScript/Node.js 场景的安全漏洞与不安全模式每条发现都标注 CWE 编号。严重度分级Critical可被利用且影响大RCE、数据泄露、认证绕过需立即修复、High中等影响或需特定条件、Medium可利用性/影响有限纵深防御层面、Low当前用法下风险极小但违背安全最佳实践。关注域覆盖 11 类注入CWE-78/94/79child_process.exec()传未净化输入应改用execFile()/spawn()参数数组、eval()/Function()构造器、模板注入、XSS路径穿越与文件系统CWE-22用户可控路径直接进fs操作、未校验解析后路径是否落在预期基目录内、符号链接逃逸、不安全的临时文件创建原型污染CWE-1321递归对象合并/克隆未拦截__proto__、constructor、prototype键不安全反序列化CWE-502JSON.parse未信任输入喂给递归合并、YAML/XML 解析开启不安全选项SSRFCWE-918用户提供的 URL 未校验、未拦截私网 IP 段127.0.0.0/8、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.169.254、未防 DNS rebinding密钥暴露CWE-798/532硬编码凭据、密钥被写入日志、经命令行参数传递密钥、.env未进.gitignoreReDoSCWE-1333嵌套量词、重叠交替导致灾难性回溯、new RegExp(userInput)未转义密码学弱点CWE-327/328MD5/SHA1 用于安全目的、而非crypto.timingSafeEqual()、Math.random()代替crypto.randomBytes()错误处理的安全面CWE-209/755错误响应泄露堆栈与内部路径、fail-open 模式、未处理的 Promise rejection供应链与依赖无理由新增依赖、依赖的postinstall生命周期脚本、未固定的依赖版本资源耗尽CWE-770/400缺少请求体大小限制、无界内存分配、同步/CPU 密集任务阻塞事件循环。输出格式按 7 要素Severity → Confidence → Category CWE → Location → Finding → Attack scenario含前置条件→ Mitigation尽量附代码建议。安全评审还强调优先级排序RCE 数据外泄 提权 拒绝服务 信息泄漏。2.3 reviewer-performance性能评审定义文件reviewer-performance.md只报告**越过 Flagging Threshold标记阈值**的发现明确把微优化排除在范围之外。标记阈值至少满足其一才上报比必要复杂度更差如 O(n²) 而 O(n) 可行在热路径上阻塞事件循环相当长的时间在长驻进程中导致无界内存增长造成资源泄漏文件句柄、监听器、定时器、连接在可证明的热路径上触发已知的 V8 去优化。检查清单包括算法复杂度循环内concat()构建数组、用Array.includes()做重复查找应换Set/Map、事件循环与并发热路径同步 I/O、独立操作应Promise.all、CPU 密集任务应交给worker_threads、process.nextTick递归应改setImmediate、资源泄漏、内存与 GC 压力热循环内大对象分配、无界增长、应流式而非整文件读入内存、不必要的展开拷贝、正则安全ReDoS、V8 优化提示多态函数参数、delete操作符、创建后修改对象形状、缓存机会重复昂贵计算未记忆化、重复 I/O。性能评审的输出每项包含 SeverityCritical导致 outage/OOMHigh可度量影响Medium规模放大Low改进机会、Confidence、Location、Issue、Impact尽量量化如O(n*m) per request、Fix。阈值判断以真实规模的冲击为准而不是以置信度为准——有证据但无法量化的成本也应带置信度标注上报。2.4 reviewer-test-coverage测试覆盖评审定义文件reviewer-test-coverage.md采用基于风险的优先级排序来寻找缺失测试并给出具体测试用例建议而非笼统的多写测试。优先级矩阵从高到低优先级类别示例Critical数据完整性、认证、安全敏感逻辑校验、净化、访问控制、密码学High复杂条件逻辑3 分支、嵌套条件解析器、状态机、规则引擎、分发器High错误处理与恢复路径catch 块、重试、回退、清理Medium公共 API 面与契约导出函数、CLI 标志、配置 schema、事件处理器Medium状态转换与副作用状态变更、资源生命周期、缓存行为Low逻辑直白的内部辅助函数纯工具函数、简单转换Skip不太可能藏缺陷的琐碎代码简单委托、类型定义、常量、属性访问该 Agent 还内置了一整套测试设计技法用于寻找缺失用例等价类划分有效/无效输入、空/单元素/多元素集合、正/零/负数、ASCII/Unicode/特殊字符、边界值分析0、1、-1、MAX_SAFE_INTEGER、端口 0/65535、off-by-one、状态转换覆盖合法转换、非法转换、终态可达性、决策逻辑覆盖每个布尔条件独立翻转、短路求值不掩盖 bug、错误路径分析失败模式是否被区分、清理/回滚是否被验证。在既有测试质量评估上它引入变异测试心智模型对每条断言自问如果在产品代码中埋一个小 bug翻转操作符、删掉条件、改动边界这个测试能抓住吗抓不住即为假信心。需要标记的测试坏味道包括无意义断言、Assertion Roulette多断言无描述消息、Eager Test、魔法数字、Mystery Guest依赖外部状态、实现耦合、测试内条件逻辑、Sleepy Test用 setTimeout 代替假定时器、冗余断言、过度 mock。2.5 reviewer-conventions规范一致性评审定义文件reviewer-conventions.md聚焦lint/格式化工具抓不到的语义一致性问题语义一致性、架构模式、API 设计连贯性、命名清晰度。评审方法论分三步发现规范基线先读项目规则文件.agents/rules/、CLAUDE.md、CONTRIBUTING.md找显式约定再看同模块既有代码找隐式模式并记录项目的依赖注入方式、错误处理风格、文件组织与命名惯用法检查语义一致性命名是否如实描述行为返回null的getUser应叫findUser、同类概念命名是否统一别混用remove/delete/destroy、布尔命名是否自然isValid/hasPermission/shouldRetry而非valid/permission、新函数参数顺序与既有代码是否一致、错误上报风格是否统一throw vs return null vs Result、新文件是否放在合适的特性目录、JSDoc 注释与改动后代码是否仍一致警惕描述旧行为的过期注释、barrel 文件index.ts是否同步更新评估一致 vs 改进的张力当改动引入了客观上更好的新模式时应标注为讨论点而非缺陷建议如果团队认可新方案考虑更新约定并迁移既有代码不应用风格改进阻塞 PR。输出格式每项包含 Typedeviation破坏既有约定 /discussion更好但不一致、Severity、Confidence、Convention注明来源、Location、Finding、Suggestion。权重排序为错误处理不一致 公共 API 不一致 命名不一致 文件组织不一致 注释风格不一致。2.6 reviewer-holistic全局视角评审定义文件reviewer-holistic.md定位是只见森林不见树——只报告其他专职评审大概率漏掉的跨切面问题不重复它们的发现。六大关注域设计连贯性抽象层级是否恰当、模块单一职责是否被破坏、是否引入向上/循环依赖、质量属性权衡性能 vs 可维护性是否被作者忽略变更影响分析系统化追踪传播链——直接依赖者、传递依赖者、共享状态全局变量、单例、缓存、配置对象、环境变量、事件/回调链的时序变化、配置 schema 改动的下游消费者如果变更封装良好、涟漪极小这本身就是一条有价值的正向发现契约与兼容性结构性变化移除/重命名导出、函数签名变更、CLI 标志/配置键被删与行为性变化同接口不同输出、错误类型/消息/条件改变、默认值改变、输出排序或时序变化并据此判断语义化版本号该走 patch/minor/major用户与运维影响升级体验是否需要迁移步骤、走查 2~3 条受影响用户工作流、新失败模式的报错是否清晰可执行、文档是否失准Premortem 预演分析借鉴 Gary Klein 的 premortem 技术假设变更已上线并引发事故反推 1~3 条具体失败故事上线两周后用户报告 X根因是 Y团队没发现是因为 Z并评估严重性数据丢失 错误输出 体验降级 外观问题、可能性、检测难度、爆炸半径范围/可逆性/恢复时间跨切面关注日志与可观测性、错误处理模式一致性、并发与排序、平台/环境敏感性Windows/macOS/Linux、Node 版本、CI 环境、仓库规模。输出每项含 Severity、Confidence、Area上述 6 节之一、Finding、Evidence具体模块/函数/工作流、Recommendation并按影响优先排序。三、Triage 阶段编排者才是过滤器六路并行评审会产生大量候选发现命令文档为编排者也就是运行此命令的主 Agent制定了明确的裁决纪律不盲从只保留自己也认为值得注意的条目丢弃低置信度或低严重度的项——除非你能对着代码亲自确认它unless you can confirm them against the code yourself二分法分类幸存条目必须归类为Fix明确缺陷必须修或Skip风格问题、吹毛求疵、范围蔓延透明呈现动手改动任何代码之前先展示一张简明的决策表格。这套 Triage 机制与各评审 Agent 定义中的不预过滤约定是配套的Agent 端明确写着Do not pre-filter borderline findings -- the orchestrator triages your report and drops what it disagrees with, so a finding you suppress is lost while one it rejects costs a line不要预过滤边缘发现——编排者会裁决并丢弃它不同意的项被你压下的发现会丢失而被它否决的发现只损失一行文本。也就是说Agent 隐瞒发现是信息损失编排者否决发现只是成本开销两者权衡之下鼓励有疑必报、有据必审。Skip 类的典型内容在多个 Agent 的 Guidelines 中也有明确定义格式、样式、导入顺序、命名约定除非真的误导、TODO 注释除非指向未完成代码路径、自动生成代码、小集合上的循环风格偏好、冷路径上的微分配等。这为跳过什么提供了仓库内的判断依据。四、Fix 与 Verify最小改动与回归门禁4.1 Fix只修该修的命令规定Fix only the Fix items. Keep changes minimal.只修 Fix 条目保持改动最小化。这意味着一轮循环内不得顺手重构、不得扩大范围避免评审引起的二次回归。4.2 Verify两级质量门禁修复完成后必须运行两个验证命令全部通过才能进入下一轮npm run lint npm run test这两个命令在根目录 package.json 中有精确定义值得拆开看它们的实际构成npm run lint是一个组合命令依次执行lint-biomebiome check --write风格与格式化检查Biome 配置见 biome.jsonlint-oxlintoxlint --fix静态规则检查lint-tstsc --noEmitTypeScript 全量类型检查不做产物输出lint-secretlintsecretlint **/* --secretlintignore .gitignore密钥/敏感信息扫描与安全评审 Agent 的 Secret Exposure 关注域呼应。npm run test即vitest仓库测试体系庞大与src/目录结构镜像对应见 tests/ 下的core/、config/、cli/、mcp/、shared/等子目录覆盖文件收集、git 集成、metrics 统计、输出样式、tree-sitter 解析、MCP 工具等核心模块。命令还要求Fix any regressions and repeat this step until all checks pass before continuing.修复任何回归并重复本步直到所有检查通过再继续。也就是说 Verify 内部同样是一个小的收敛循环。4.3 Re-review只审增量进入下一轮 Review 时范围被严格限定为上一轮新改动的行Re-review only the newly changed lines且不得重新提出已 Skip 的条目Do not re-raise skipped items。这保证了迭代的单调收敛每一轮只针对增量引入的新风险做检查而不会因为反复翻炒旧账导致死循环或评审疲劳。五、终止条件与总结输出循环在无 Fix 剩余或达到 3 轮迭代时终止。需要特别说明两点工程语义3 轮上限是硬约束即使仍有遗留的 Fix 条目也不得无限循环。这避免了对同一处代码反复修改引入的新风险失控是一种务实的成本控制总结必须显式输出最终要打印修复了什么、跳过了什么这既是对本轮工作的可审计留痕也为后续的 PR 评审见下文提供了上下文。从该命令所在目录 .agents/commands/code/ 还能看到它的近亲变体codex-review-loop.md同一套五步循环但 Review 阶段改为拉起单个 codex 评审 Agent而非 6 个并行 Agent适用于评审预算有限或使用 codex 工具链的场景pr-review.md 与 pr-prepare.md可视为本闭环的前后延伸——review-loop 产出的修复/跳过总结可以直接喂给 PR 评审与 PR 创建流程。六、与项目规则的衔接评审结论如何落地review-loop 中的conventions 评审和 Fix 阶段的改动都应当对齐 .agents/rules/base.md 中沉淀的核心工程约定否则 Verify 阶段可能直接失败编码规范由 Biomebiome.json强制执行文件保持单一职责约250 行作为审视文件内聚性的信号注意是审视信号而非拆分命令单一内聚主题的长文件可保持不变提交信息遵循 Conventional Commits 规范格式为type(scope): Description如feat(cli): Add new --no-progress flag正文遵循contextual-commitskill 的指引可测试性依赖通过deps对象参数注入以便测试替身替换仅当依赖注入不可行时才用vi.mock()export const functionName async ( param1: Type1, param2: Type2, deps { defaultFunction1, defaultFunction2, } ) { // 使用 deps.defaultFunction1() 而非直接调用 };平台差异意识根目录npm run lint并不对 website client 做类型检查改动website/client需在该目录单独验证配置 JSON schemawebsite/client/src/public/schemas/由脚本生成禁止手改面向用户的功能变更需同步更新全部 15 个语言目录的文档。这些规则与 review-loop 的对应关系很直接代码质量/规范评审 Agent 的发现往往对应 base.md 的编码与依赖注入约定性能评审与测试覆盖评审的发现则对应为新特性提供单元测试的硬性要求而 Verify 步骤恰好验证每次变更都通过npm run lint与npm run test这一仓库级红线。七、适用前提与使用限制基于当前仓库内容使用本工作流需要注意以下前提与边界运行环境Verify 步骤依赖 Node.js 环境与根目录依赖安装完成package.json声明engines.node 22.0.0lint-ts使用 TypeScript 7、测试框架为 Vitest需先执行依赖安装对比基线循环针对当前分支相对main的改动评审要求仓库存在main分支且分支间有可 diff 的改动首次运行前请确认分支状态多 Agent 场景默认 6 个评审 Agent 并行对上下文窗口与 token 预算有较高要求预算有限时可改用 codex-review-loop.md 的单 Agent 变体评审范围纪律Re-review 只覆盖新增行、Skip 条目不翻案、Fix 保持最小化——这三点共同保证循环在 3 轮内收敛实践中应避免扩大评审范围裁决责任文档明确把最终判断权交给编排者所有 Agent 结论都需经过自己确认代码这一步不可直接照单全收。结语review-loop 提供的不只是一条命令而是一套可复用的多 Agent 协作评审范式专职 Agent 广撒网保证召回率编排者 Triage 保证精确率最小化修复与控制迭代上限保证收敛性linttest双门禁保证安全性。配合仓库中 6 份评审 Agent 定义中详尽的检查清单从 O(n²) 复杂度到 CWE 注入、从等价类划分到 premortem 预演这套工作流既是 Repomix 自身工程的实践沉淀也可以作为任何 Node.js/TypeScript 项目搭建 AI 驱动评审闭环的参考蓝本。若要在自己的分支上立即体验只需在改动就绪后让 AI 代理读取 review-loop.md 并按其中的五步循环执行即可。【免费下载链接】repomix Repomix is a powerful tool that packs your entire repository into a single, AI-friendly file. Perfect for when you need to feed your codebase to Large Language Models (LLMs) or other AI tools like Claude, ChatGPT, DeepSeek, Perplexity, Gemini, Gemma, Llama, Grok, and more.项目地址: https://gitcode.com/GitHub_Trending/rep/repomix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考