Humanize：用 Codex 独立评审约束 Claude Code 的迭代循环
From Automated Idea Factory to Realization
秒懂
- 它是什么？
- Humanize 是一个 Claude Code 插件，把「Claude 实现、Codex 评审」拆成两个独立角色，用 ralph-loop 反复迭代直到验收标准满足。它解决的是单模型自审自改的盲区问题，代价是引入外部 CLI 依赖和一套 .humanize 目录约定。
- 适合谁用？
- Humanize 适合已经在用 Claude Code、并且愿意额外装 codex CLI 的团队，尤其是那些被单模型自审自改坑过的人：让另一个模型看代码质量，比让同一个模型给自己打分更接近真实的评审。它不适合只想让 AI 一把生成完整功能的用户，RLCR 的前提是你先有一份能写进 docs/plan.md 的计划，README 也明确要求人先理解自己要执行的计划。
- 能商用吗？
- 未经许可不能。GitHub 在这个仓库里没有找到许可证文件；没有许可证，默认即「保留所有权利」：你可以阅读代码，但不能复用。使用前请看看 README，或先征得作者同意。
- 还在维护吗？
- 在维护。仓库最近一次提交在 19 天前。
- 用什么语言写的？
- 主要是 Shell（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
Humanize 要解决的是自己审自己的问题
让一个模型写完代码再让它自己检查，评审和实现共享同一套上下文，它很难对自己刚才的判断提出异议。Humanize 的做法是把这两个角色拆开：Claude 负责实现，Codex 负责评审，README 把它概括为 One Build + One Review，并直接写了 No blind spots 这句判断。
它的目标用户不是想一句话生成整个项目的人，而是已经接受「代码需要被反复改」这个前提的开发者。README 的第一条核心理念是 Iteration over Perfection，明确放弃了一次成型的期待。另一条是 Begin with the End in Mind，在循环开始之前，Humanize 会先验证你自己是否理解即将执行的计划，文档里对应 usage.md 的同一小节，并强调人必须留在架构师的位置上。
这两条理念决定了它的形态：它不是一个代码生成器，而是一套把生成、评审、修正串成闭环的流程外壳。
RLCR 的两个阶段与 Codex 的严重级别标记
RLCR 是 Ralph-Loop with Codex Review 的缩写，README 说明它受官方 ralph-loop 插件启发，并加上了独立的 Codex 评审。这个名字还有第二层读法：Reinforcement Learning with Code Review，对应 AI 生成的代码被外部评审意见持续打磨的循环。
按照 README 的描述，循环分两个阶段。实现阶段 Claude 干活，Codex 评审的是摘要；代码评审阶段 Codex 检查代码质量，并带有严重级别标记。发现的问题回流到实现阶段，直到解决为止。这里有一个容易被忽略的细节：第一阶段 Codex 看的是摘要而不是完整代码，所以摘要在多大程度上忠实反映改动，直接决定了这一轮评审的有效性。README 没有说明摘要由谁生成、如何校验，这是文档里比较薄的一块。
循环还有一个可选的 Swarm 模式，README 的表述是 optionally parallelize with Agent Teams，用于并行化迭代。文档没有给出并行度上限、冲突处理方式或 Agent Teams 的具体配置项，想用这个模式的人需要自己去翻 docs/usage.md。
从一句模糊想法到可执行计划的命令序列
安装走的是 Claude Code 的插件市场机制。README 给出的命令是先添加市场再安装：
/plugin marketplace add PolyArch/humanize /plugin install humanize@PolyArch
如果要用开发分支上的实验特性，把第一条换成 /plugin marketplace add PolyArch/humanize#dev。评审依赖 codex CLI，README 明确写了 Requires codex CLI for review，完整前置条件在 docs/install-for-claude.md 里。
上手流程是四步。第一步可选，把松散的想法扩成草稿：
/humanize:gen-idea "add undo/redo to the editor"
输出默认落在 .humanize/ideas/<slug>-<timestamp>.md。如果传入一个 .md 路径，它会去扩写你已有的粗略笔记。--n 控制并行探索该想法的方向数量，默认 6，这个值越大，前期发散的成本越高。
第二步从草稿生成计划：/humanize:gen-plan --input draft.md --output docs/plan.md。第三步在评审者加了批注后精修计划，批注格式支持三种：CMT: ... ENDCMT、<cmt> ... </cmt> 和 <comment> ... </comment>，命令是 /humanize:refine-plan --input docs/plan.md。第四步才真正跑循环：/humanize:start-rlcr-loop docs/plan.md。
另外还有一条 /humanize:ask-gemini，用于深度网络调研，需要 Gemini CLI。这条命令和 RLCR 主循环是两回事，没装 Gemini 也不影响评审流程。
监控面板必须开在另一个终端里
README 对监控的使用方式给了一个很具体的约束：在另一个终端里跑，不要在 Claude Code 内部跑。先 source 脚本，或者干脆加进 .bashrc / .zshrc：
source <path/to/humanize>/scripts/humanize.sh
然后按需要选择视图：humanize monitor rlcr 看 RLCR 循环，humanize monitor skill 看全部技能调用（codex 加 gemini），humanize monitor codex 只看 Codex 调用，humanize monitor gemini 只看 Gemini 调用。
这个设计说明循环的状态是进程外的，而不是活在 Claude Code 的会话上下文里。好处是你能在一个干净的终端里观察长时间运行的迭代，坏处是它把「看进度」变成了一件需要额外开窗口的事。README 只给了截图 docs/images/monitor.png，没有说明面板的刷新频率、日志保留策略，也没有说明循环中断后状态如何恢复。这几个点在上生产前值得自己确认。
依赖链和许可证是采用前的两道门槛
Humanize 本身是 Shell 写的，主要语言一栏就是 Shell，但它的实际运行依赖不止一个外部 CLI。评审要 codex CLI，网络调研要 Gemini CLI，宿主是 Claude Code。也就是说，一次完整的 RLCR 循环至少牵扯三个供应商的工具链。任何一环的登录态、配额或者版本变动，都会直接打断循环。README 没有给出 codex CLI 的版本要求，也没有说明评审失败时循环是重试、跳过还是中止。
许可证方面，README 末尾写的是 MIT。但仓库元数据里的 License 字段是空的，也没有检索到任何 release。这两处不一致本身就是一个需要动手核实的信号，采用前请打开仓库里的 LICENSE 文件确认，而不是只看 README 最后一行。
维护成本上，README 提到 Humanize2 正在活跃开发并征集反馈，还提到项目现在有了一个主页。这意味着当前版本 1.16.0 处在一个还在演进的位置，命令签名和目录约定在未来版本中调整的可能性是存在的。文档结构本身倒是齐全的，usage、install-for-claude、install-for-codex、install-for-kimi、bitlesson 都有独立页面，但仓库里没有 release 记录，所以无法从版本号判断升级的破坏性。
什么时候该换用别的做法
Humanize 最明显的不适用场景是任务本身很短。如果你只是想让 Claude 改一个函数、补一段测试，那么先 gen-idea 再 gen-plan 再 start-rlcr-loop 的开销远大于收益，直接用 Claude Code 本身更划算。RLCR 的价值来自反复迭代，一次性任务没有可迭代的空间。
另一个边界是评审独立性并不等于评审正确性。Codex 看的是摘要和代码，它和 Claude 不共享上下文，这确实消除了自审的盲区，但也意味着 Codex 缺少 Claude 在实现时积累的推理过程。它可能提出一个在局部看合理、在整体设计上不成立的修改意见。README 把 Codex 的评审描述为带严重级别标记，但没有说明这些标记由谁裁决、人能否覆盖。如果你的团队没有人在循环里做最终判断，迭代可能在两个模型之间来回震荡。
如果你要的是纯粹的测试驱动开发，那 Humanize 的定位不同：它的验收标准写在计划文档里，由模型判断是否满足，而不是由一套可执行的测试套件判断。这两者的严格程度不在一个量级。
一个可对比的替代方案：GAAC
README 第一段就写明 Humanize 派生自 GAAC（GitHub-as-a-Context）项目，链接指向 SihaoLiu/gaac。这是最直接、也最有信息量的对照对象，因为两者的血缘关系是公开的。
从名字可以看出方法论上的分歧。GAAC 把 GitHub 当作上下文来源，也就是让 issue、PR、讨论这些仓库内的协作产物成为模型的信息输入。Humanize 的重心不在这里，它把精力放在循环本身：谁实现、谁评审、问题怎么回流、什么时候停。一个偏向「信息从哪来」，另一个偏向「过程怎么走」。
这个差别会落到日常使用上。GAAC 式的思路更依赖你已经在 GitHub 上积累了足够的讨论和需求描述；Humanize 则要求你先产出一份结构化的计划文档，也就是 docs/plan.md 这个位置，然后围绕它转圈。如果你团队的协作痕迹主要在 issue 里，GAAC 的取向可能更贴合；如果你更想要一个能反复打磨的本地计划文件，Humanize 的路径更直接。README 没有提供两者的迁移说明，派生关系只体现在这一句来源标注上。
编辑结论
Humanize 适合已经在用 Claude Code、并且愿意额外装 codex CLI 的团队，尤其是那些被单模型自审自改坑过的人：让另一个模型看代码质量，比让同一个模型给自己打分更接近真实的评审。它不适合只想让 AI 一把生成完整功能的用户，RLCR 的前提是你先有一份能写进 docs/plan.md 的计划，README 也明确要求人先理解自己要执行的计划。上手前先确认三件事：codex CLI 是否可用，Gemini CLI 是否可用（只有用到 ask-gemini 才需要），以及仓库根目录能否接受新增 .humanize/ 目录。最后提醒一句，README 里 License 一栏写的是 MIT，但仓库元数据中的许可证字段为空，正式采用前请在仓库里核对 LICENSE 文件本身。
社区笔记