Repomix 项目中的 Codex 迭代式代码审查闭环codex-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导读本指南围绕 Repomix 仓库中的命令文档 .agents/commands/code/codex-review-loop.md 展开系统讲解如何用 OpenAI Codex 作为评审 Agent对当前分支相对main的改动执行审查—分流—修复—验证—复审五步闭环最多 3 轮迭代。读完本文你将掌握该工作流每一步的落地细节Triage 的 Fix/Skip 分类、最小化修复原则、npm run lint与npm run test的真实校验内容、只复审新改行的边界控制并能对照仓库内 6 个专业 Reviewer Agent 定义把同样的闭环方法论迁移到自己的项目里。一、工作流全景一个可重复的 5 步闭环codex-review-loop命令定义的是一条针对当前分支相对main的改动的迭代式审查与修复流程核心是一个最多执行 3 次的循环Review审查—— 派生出 Codex Reviewer AgentTriage分流—— 开发者亲自过滤 Agent 的发现只保留自己也认为值得注意的项并逐一归类为Fix明确缺陷必须修复或Skip风格、吹毛求疵、范围蔓延Fix修复—— 只修复标为 Fix 的项且保持修改最小Verify验证—— 执行npm run lint与npm run test修复回归并使所有检查通过后再继续Re-review复审—— 只针对新改动的代码行重新审查不再重复提出已被跳过的项。循环终止条件二选一没有剩余的 Fix 项或达到 3 次迭代上限。最终打印一份总结说明修复了什么、跳过了什么。这条流程的本质是让 Agent 穷尽报告、让人来做最终裁决——它刻意把发现问题与决定改什么两个职责分离避免 AI 自行大改代码导致不可控的范围蔓延同时用main作为基线确保审查范围始终聚焦在本次分支改动上。二、Review 阶段派生 Codex Reviewer Agent第一步是让 Codex 以评审者身份介入。命令原文是Spawn codex reviewer agent——即在 Codex CLI 中派生一个专门负责审查的 Agent 会话输入当前分支相对main的 diff让它产出审查报告。该命令本身采用单 Agent 模式一条 codex-review-loop 命令对应一个 Codex Reviewer。与之对照的是仓库中的姊妹命令 review-loop.md后者同时派生6 个专业 Reviewer Agent 并行审查覆盖代码质量、安全、性能、测试覆盖、规范、整体架构六个角度对应 .agents/agents/ 下的 6 份定义文件Reviewer Agent定义文件关注领域reviewer-code-qualityreviewer-code-quality.md缺陷、逻辑错误、边界情况、代码坏味道reviewer-securityreviewer-security.md注入、路径穿越、原型污染、SSRF、密钥泄露等reviewer-performancereviewer-performance.md算法复杂度、事件循环阻塞、资源泄漏、内存压力reviewer-test-coveragereviewer-test-coverage.md缺失测试、未覆盖边界、测试质量reviewer-conventionsreviewer-conventions.md命名一致性、API 设计一致性、项目结构规范reviewer-holisticreviewer-holistic.md设计一致性、变更影响分析、契约兼容性、用户影响如果想让 codex-review-loop 走单 Agent 但多视角的路线可以直接复用 reviewer-code-quality.md 的评审框架作为 Codex Reviewer 的提示词底子。该文件中确立的两条关键约定值得沿用不预过滤Do not pre-filterAgent 必须报告每一个有具体证据的发现并标注严重级别Critical / High / Medium / Low与置信度High / Medium / Low。理由写得很直白——你压下的发现会永久丢失而编排者拒绝一条发现只浪费一行。低置信度的发现也要报告只是附上它依赖什么假设。输出结构化每条发现包含 Location文件与行/函数、Confidence、Issue、Risk、Suggestion按严重级别分组Critical 优先。codex-review-loop 的 Triage 步骤正是消费这种结构化输出所以 Agent 报告越规范人工分流越省力。此外reviewer-holistic.md 还定义了premortem 分析技巧——假设变更已上线并引发事故倒推 13 个具体失败故事评估严重度、可能性、检测难度与爆炸半径blast radius。这可以作为单 Agent 审查的补充视角让 Codex 不止盯着 diff 里的每一行也评估整次改动对系统的整体影响。三、Triage 阶段开发者是过滤器命令明确要求Review agent findings and keep only what you also deem noteworthy——Agent 的结论不能直接照单全收开发者必须亲自复核只留下自己也认为值得注意的项。这是整个闭环防止AI 过度干预的关键闸门。分流操作分三步筛选剔除低置信度、低严重度的发现除非你能对照代码亲自确认其真实性。Agent 的置信度标注High / Medium / Low在这里就是排序依据。分类把幸存项归入两类——Fix明确的缺陷必须修复Skip风格问题、吹毛求疵、范围蔓延scope creep。公示在动手改任何代码之前先展示一张简要的分类表格项、级别、Fix/Skip 决策。先公示再动手这条约束的价值在于它强制你在修改前把决策显式化避免边改边夹带私货同时为最终的修复/跳过总结留下了可回溯的记录。Skip 并不是无理由丢弃——复审阶段第 5 步明确规定不得重新提出已跳过的项这保证了 3 轮迭代的收敛性防止同一批风格争论在每轮循环里反复消耗预算。四、Fix 阶段只修 Fix 项保持最小化第三阶段的铁律是Fix only the Fix items. Keep changes minimal.——只动被标记为必须修复的项其余一律不碰。在 Repomix 的工程语境下最小化修改有一套具体约束可依循全部记录在 .agents/rules/base.md编码规范遵循 Biomebiome.json强制的代码标准每个文件保持单一职责约 250 行是值得审视内聚性的信号而非强制拆分线。依赖注入模式新依赖一律通过deps对象参数注入以便测试测试中用测试替身test doublemock 依赖仅在无法注入时才用vi.mock()。修复代码时若不遵守这一模式后续npm run test很可能在现有测试模式下暴露问题。提交信息遵循 Conventional Commits 规范type(scope): Description如feat(cli): Add new --no-progress flag。修复若涉及提交scope 应对应受影响区域cli、core、website、security 等。由于 Fix 集合来自人工分流本身数量有限配合最小化原则每轮迭代对代码库的扰动被控制在可审计范围内——这正是该工作流与让 AI 直接大改的本质区别。五、Verify 阶段lint 与 test 的真实内涵第 4 步要求用npm run lint和npm run test验证出现回归就继续修复并重复本步直到全部通过才进入下一轮复审。理解这两条命令的真实构成才能预判验证会覆盖什么、不会覆盖什么。查看根目录 package.jsonnpm run lintpackage.json实际是四条子命令的串联lint-biomebiome check --writepackage.json——代码风格与静态检查lint-oxlintoxlint --fixpackage.json——lint 与自动修复lint-tstsc --noEmitpackage.json——TypeScript 全量类型检查这是运行时正确性最硬的防线lint-secretlintsecretlint **/*package.json——扫描密钥泄露与 reviewer-security.md 中Secret Exposure (CWE-798, CWE-532)的审查焦点呼应。npm run testvitestpackage.json即 Vitest 测试运行器仓库测试规模庞大tests/目录完整镜像src/结构覆盖 CLI 动作、配置加载、文件收集、Git 处理、指标计算、输出样式、安全扫描、tree-sitter 解析等模块。另外 .agents/rules/base.md 特别提醒两个验证盲区根目录npm run lint不对 website 客户端做类型检查改动website/client时必须在website/client目录内用npm run docs:build验证配置 JSON Schemawebsite/client/src/public/schemas/是npm run website-generate-schema生成的CI 在合并到main后会重新生成绝不能手工编辑。也就是说Verify 步骤的通过标准在不同改动区域有不同的完整形态改src/就靠lint test改网站文档还需追加 docs 构建验证。在实战中这提醒我们要把验证命令当作按改动面裁剪的组合而不是一成不变的两条命令。六、Re-review 阶段与循环收敛第 5 步规定只重新审查新改动的行不要重新提出已跳过的项Re-review only the newly changed lines. Do not re-raise skipped items。这条规则同时约束了两个维度范围上复审对象从整个分支 diff收窄为上一轮修复引入的新改动行避免对未改动代码做重复劳动也防止 Agent 在新一轮里重提旧问题决策上Skip 决策在本循环内是终局性的保证 3 轮迭代必然收敛。循环出口某轮 Triage 后没有剩余 Fix 项 → 立即停止达到 3 次迭代上限 → 强制停止无论哪种出口最后都要打印总结修复了什么、跳过了什么。这份总结既是本轮工作的审计记录也可以直接写入 PR 描述让维护者看到AI 建议了什么、人决定修了什么、为什么跳过其余项。七、实战落地清单把codex-review-loop的 5 步闭环套用到 Repomix或任何 Node.js 项目的开发流程中建议按以下清单执行准备基线确保本地main已同步确认git diff main范围即本轮审查对象。Review启动 Codex派生 reviewer agent输入git diff main要求输出带 Severity Confidence 的结构化报告单 Agent 模式下可参考 reviewer-code-quality.md 组织评审视角如涉及整体架构风险叠加 reviewer-holistic.md 的 premortem 视角。Triage逐条核对只保留你也能在代码里确认的发现输出 Fix/Skip 表格后再动手。拿不准的项宁可标 Low 置信度保留也不要随手丢弃——正如 Reviewer Agent 定义所言压下的发现就永久丢失了。Fix只修 Fix 项遵循 .agents/rules/base.md 的编码规范、单一职责与 deps 依赖注入约定保持改动最小、可审阅。Verifynpm run lintbiome oxlint tsc secretlintnpm run testvitest若改动涉及website/client额外在该目录执行npm run docs:build。任何回归都必须修复后重新验证直到全绿。Re-review 与收尾只复审新改行不重提 Skip 项无 Fix 项或达到 3 轮即停输出修复了什么、跳过了什么的总结作为 PR 说明的一部分。八、方法论迁移与 review-loop 的取舍对比 codex-review-loop.md 与 review-loop.md 可以发现两者共享完全相同的骨架——TriageFix/Skip 分类 先表格后动手、最小化修复、npm run lintnpm run test验证闭环、只复审新改行、3 次迭代上限与总结输出。唯一的差异在第一步review-loop并行派生 6 个专业 Reviewer各管一个维度报告自动带 severity confidence且 Agent 不做预过滤codex-review-loop只派生 1 个 Codex Reviewer依赖 Codex 自身能力完成多维度审查编排成本更低、token 开销更小。选择建议分支改动横跨安全、性能、测试、文档等多个维度时review-loop的多 Agent 并行能带来更强的覆盖保证改动面小而集中、或希望控制 LLM 调用成本时codex-review-loop的单 Agent 模式更轻量。两条命令的可移植性都很强——因为它们依赖的分级报告 → 人工分流 → 最小修复 → 命令验证 → 定点复审模式与具体项目解耦只要项目提供lint与test脚本即可迁移。结语codex-review-loop 表面上只是一条 5 步循环命令但它体现了 Agent 辅助开发中一个重要设计原则AI 负责穷尽式发现问题人负责做出修改决策两者各司其职并用最小化修改 定点复审 迭代上限把 AI 的介入范围牢牢锁住。结合 .agents/agents/ 下 6 份 Reviewer Agent 定义、.agents/rules/base.md 的工程规范与 package.json 中的验证脚本这套方法论在 Repomix 仓库中已经具备完整的可落地土壤——你也完全可以将同样的闭环原样迁移到自己的项目让每次分支合并前的代码质量审查都变得可重复、可审计、可收敛。【免费下载链接】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），仅供参考