Codex还是Claude Code：总体接纳率高，不代表每类任务都赢

Codex在历史开源拉取请求中取得更高的总体接纳率，修复任务也表现较强；Claude Code则在文档和功能开发类别领先。分任务PR研究筛选了7156个拉取请求：Codex与Claude Code的总体合并率分别为77.9%和71.9%，Codex在修复类别为83.0%，Claude Code在文档和功能类别分别为92.3%和72.6%；不过Claude Code总共只有139个PR，文档类别不足20个，而论文摘要把Cursor的80.4%称作修复领先，与正文所列Codex的83.0%不一致。

如果工作主要是修复现有代码，这组记录给Codex较强的优先考虑理由；如果交付重心是新功能或文档，Claude Code值得纳入比较。两者都能在终端读取项目、修改文件并运行命令，但历史PR的合并结果没有把相同任务交给两款工具，也没有比较它们在相同权限和CI环境下的耗时与代码质量。

修复、功能、文档：排序为什么改变

修复类别中，Codex的合并比例高于Claude Code，也高于论文正文列出的Cursor数值。摘要与正文对修复领先者的表述冲突，因此稳妥的结论是：在这批经过筛选的PR里，Codex的修复记录较强；不能把它写成对所有缺陷难度都成立的胜负判断。修复可能是一处明确的错误，也可能牵涉多个模块和回归风险，任务标签没有把这些差别消除。

功能开发的方向相反：Claude Code在该类别取得较高合并比例，而且功能PR在它自身样本中占了更大份额。它面对的项目、需求和审查者并未与Codex逐项配对，所以这个结果显示的是历史提交的接受情况，而非同题竞赛的胜率。对以新增功能为主的团队，它足以说明不能直接沿用总体排名，却不足以保证下一项需求也会由Claude Code做得更好。

文档类别的差距看起来醒目，证据却更薄。Claude Code在这一格的PR数量很少，少量合并或拒绝就能明显改变比例；文档任务本身也可能从拼写修订延伸到需要与代码行为一致的使用说明。若团队大量维护接口文档和示例，类别结果可以提出一个值得比较的候选工具，却不宜当成稳定的交付成功率。

其他任务进一步说明总体分数会掩盖差别。论文正文把重构列为Codex领先的类别；在测试任务上，它列出的领先者是Cursor，而非这两款工具。筛选后的Claude Code样本没有CI类别PR，这只说明该类别缺少可比较的观察值，不能据此推断Claude Code不能处理CI配置，或Codex更适合无人值守运行。

PR被合并，衡量的究竟是什么

这项统计把已关闭且最终合并的PR计为“接纳”。原始数据来自有一定关注度的GitHub仓库，研究又只保留采用MIT或Apache-2.0许可证、关闭前收到作者以外的人审查或评论的PR。筛选让记录更接近有人参与的开源协作，同时也排除了大量私人仓库、小项目以及代理生成后从未提交的改动。

合并是项目维护者在特定时点作出的决定。它可能受到需求是否仍然需要、维护者的审查标准、提交者后续修改及仓库当前状态影响。一个被合并的补丁仍可能留下未被测试覆盖的问题；一个被拒绝的PR也可能只是偏离项目计划。接纳率因而不能直接换算成代码正确率、安全性或节省的开发时间。

任务构成还会推高或拉低总体数字。在同一批样本中，文档PR通常比功能PR更容易被合并；如果两款工具收到的任务类别不同，汇总比例就混入了任务分配的影响。按类别比较能看清这层差异，却仍无法控制仓库审查习惯、使用者经验、模型更新和观察时段。论文中的严格成对检验只发现少数显著差异，也提醒读者不要把每一处百分点差距都解释为稳定能力差距。

本地终端：共同能力之外看控制方式

Codex CLI说明列出本地仓库检查、文件修改、运行已安装工具和查看修改差异等能力，并允许用户选择模型、推理强度及权限。开发者可以在交互式终端中跟随执行过程，也可以把重复任务交给命令行调用。对需要保留现有构建工具和测试命令的项目，关键在于代理能否在被允许的目录与命令范围内完成整个修改过程。

Claude Code工作方式说明描述了从搜索文件、编辑代码到运行测试的循环。它也提供权限模式、项目指令文件和文件修改检查点；检查点覆盖本地文件变更，不能撤回已经作用于远端系统的操作。这些机制关系到开发者何时审批命令、如何让代理沿用仓库约定，以及发现问题后能否退回文件状态。

因此，“会用终端”并不是两者的分水岭。真正会影响日常体验的是代理找到相关文件所需的交互、修改后呈现的差异、测试失败时的调整，以及哪些操作需要人批准。历史PR统计只记录流程末端是否合并，没有记录这些步骤的人工介入次数；产品文档说明可用功能，也不替具体项目保证执行效果。比较时还应区分产品层级：样本中的Codex PR结果不能直接归因于Codex CLI的某个权限设置。

接入CI后，比较对象变成整条工作流

Codex CLI支持用codex exec运行可重复的脚本和流水线任务。对于已有固定构建、测试及审查步骤的团队，它提供把代理放进现有流程的入口。任务是否适合自动运行，仍取决于执行环境、可访问文件、允许的命令，以及产出由谁审查；交互式终端里的顺畅体验不会自动延续到无人值守的CI任务。

Claude Code的GitHub Actions说明列出两种触发方式：在议题或PR中提及@claude，或者在工作流中提供提示词让任务随GitHub事件运行。配置还涉及认证密钥、仓库权限和工作流文件；交互触发与自动触发对工具授权的要求不同。对于主要围绕GitHub议题和PR协作的团队，这些入口直接影响任务怎样发起、结果出现在哪里、谁可以触发运行。

两种CI路径都需要评估修改进入主分支前的审查方式，但不能用研究中的PR合并率替代这项判断。样本没有让两款代理使用相同的流水线、触发事件和访问范围，也没有测量凭据暴露或自动运行中的错误恢复。更有用的区分是团队希望代理响应讨论中的具体请求，还是在既有流水线里执行固定任务；随后再看相应的权限配置和人工审查成本。

哪款更适合自己的任务组合

维护缺陷占主要工作量的仓库，可以把Codex列为优先比较对象；功能与文档交付较多的团队，则有理由把Claude Code放入同一轮评估。这里的依据是分任务的历史合并记录，而不是对下一项任务结果的预测。若仓库的文档工作大多是小幅修订，或修复任务普遍跨越多个服务，它与研究样本的任务标签也未必对应。

实际选型要把任务结果和运行方式放在一起看：相同需求下，关注测试与审查后的代码、需要的人为修改、命令审批是否合适，以及终端或CI触发能否接进现有流程。这属于团队自己的比较标准，不是该PR研究已经完成的同题测试。总体接纳率提供一个起点；真正决定工具是否合适的，是团队经常交付的那类改动及其审核条件。

相关阅读：

• Google Workspace还是Microsoft 365：同价套餐差在工作方式
• PaddleOCR还是EasyOCR：中文支持广，不代表复杂照片更准
• Docker还是Kubernetes：容器能跑起来，不代表需要集群