PRBench的Codex端到端成功率是0%，但它在“写脚手架、生成分析脚本、重构屎山代码”上被公认扎实——科研人到底该把Codex定位成“科研计算的主体”还是“科研基础设施的施工队”，这个定位差决定了期望值和验收标准？

目录

一、问题的提出：0%到底意味着什么

PRBench这类基准的设计初衷，是把“科研计算”压缩成一个可判定的任务：给定数据、给定问题、给定验收条件，模型需要自主完成从理解到实现再到出结果的全过程。在这个设定下，Codex系模型的端到端成功率为0%。这个数字在传播中极易被简化成一句判断——“它做不了科研”。但如果把评测拆开看，0%对应的并不是“每一步都失败”，而是“整条链路没有一次完整闭合”。这是两种完全不同的失败形态。

端到端评测的判定逻辑是合取式的：任一环节不达标，整体即判负。这与工程实践中的观察形成鲜明反差——在脚手架搭建、分析脚本生成、遗留代码重构这三类任务上，同一类模型的产出被大量从业者评价为“扎实”。一个合取式指标为0、而多个子任务评价为正的对象，说明问题很可能不在“能力总量”，而在“能力分布与任务结构的匹配度”。

本文的核心判断：0%不是能力判决书，而是定位错配的报警信号。把Codex放在“主体”工位上，它必然拿0分；把它放在“施工队”工位上，它的产出可以稳定通过验收。定位差，直接决定期望值与验收标准。

这里需要先给出一个可操作的定义，避免后文滑入修辞。“科研计算的主体”，指对研究问题负最终解释责任、能独立完成“问题建模—方法选择—实现—结果判读—结论生成”全链路、并对结论正确性承担学术责任的角色。“科研基础设施的施工队”，指在人类已确定的方法与验收条件下，承担环境搭建、数据管道、脚本实现、代码整理与文档化等施工性工作，交付物是可检验的工程制品，而非学术结论。两者的差别不在“难易”，而在“责任归属”与“判定对象”。

本文评述：把这两个角色混为一谈，是当前科研AI讨论中最常见的范畴错误。主体角色要求的是“判断力”，施工队角色要求的是“执行力”。执行力可以用测试用例验收，判断力只能用同行评议与重复实验验收。用前者的标准去考核后者，会系统性低估；用后者的标准去考核前者，会系统性高估。0%这个数字，恰恰是“用主体标准考核施工队”的产物。

二、概念澄清：什么是“科研计算的主体”，什么是“施工队”

2.1 主体角色的四项不可让渡职责

要谈定位，先要把“主体”拆到不可再分的职责层。笔者认为，科研计算的主体至少承担四项不可让渡的职责：其一，问题形式化，即把模糊的科学问题转写为可计算、可证伪的形式化表述；其二，方法选择与假设管理，即判断哪种统计或数值方法适配当前数据生成机制，并明确其假设边界；其三，结果判读，即区分“计算成功”与“结论成立”；其四，责任承担，即对结论的可复现性与学术后果负责。这四项中，前三项都依赖对领域语义的深层理解，第四项依赖制度性问责，二者都不是代码生成能力可以替代的。

本文评述：这四项职责的共性在于“不可完全规格化”。问题形式化往往需要在多个合理表述间做取舍，方法选择依赖对数据生成过程的先验判断，结果判读依赖对领域常识的把握。凡不可完全规格化的环节，都难以用自动化测试验收，也就难以交给一个以“通过测试”为优化目标的系统。这不是模型能力问题，而是任务性质问题。

2.2 施工队角色的三类可验收交付物

与之相对，施工队的交付物具备“可规格化、可测试、可复现”的特征。本文将其归纳为三类：环境与脚手架（项目结构、依赖锁定、配置管理、CI 脚本）、数据与分析脚本（清洗管道、特征构造、绘图与统计脚本）、代码整理与重构（模块拆分、接口统一、死代码清理、类型标注与文档）。这三类工作的共同点是：验收条件可以由人类事先写清楚，正确性可以由测试或对照输出判定。

这张表的关键不在“谁更强”，而在“失败代价的不对称性”。主体角色一旦失败，错误结论可能进入文献并被后续研究引用，纠错成本极高；施工队角色失败，最坏结果是返工。这种不对称性，决定了在科研场景中，把不可规格化的判断环节交给自动化系统，风险收益比是不划算的。本文评述：定位问题的本质，是风险分配问题，而非能力排名问题。

三、端到端为何失败：四类结构性断点

要理解0%，必须把端到端链路拆开，看断点落在哪里。综合公开基准的任务设计与工程实践反馈，笔者认为断点集中在四类结构性环节，且这四类环节恰好都落在“主体职责”区间。

3.1 断点一：问题形式化的歧义消解

科研问题的自然语言表述天然带有歧义。以“检验某处理对某指标是否有显著影响”为例，这句话至少隐含了样本独立性假设、分布假设、多重比较处理方式、效应量报告方式等多项未言明的决策。端到端评测要求模型自行补齐这些决策，而不同补齐方式会导向不同结论。模型在此处的失败，往往不是“写不出代码”，而是“选了一个未被验收条件覆盖的合理分支”。

本文评述：这类失败具有“看似正确”的迷惑性——代码能跑、结果能出，但与出题人预设的分支不一致。在合取式判定下，这直接判负。这不是能力缺陷，而是任务在信息不完备条件下的固有不确定性。人类研究者处理这类歧义靠的是与提问者的往返澄清，而端到端评测恰恰取消了这一往返。

3.2 断点二：数据生成机制的隐性假设

真实科研数据往往带有缺失、截断、批次效应、选择偏倚等结构性问题。处理方法的选择依赖对数据生成机制的判断，而这种判断通常写在论文的方法节而非数据文件里。端到端设定下，模型只能看到数据本身，看不到“这批数据是怎么来的”。于是它可能对非随机缺失做完整案例分析，或对存在批次效应的数据直接合并。

笔者认为，这是端到端评测中最难通过“加大模型”来解决的断点，因为它缺的是信息而非算力。数据生成机制的知识存在于研究者的头脑、实验记录与领域惯例中，不在输入张量里。任何声称端到端解决科研计算的方案，都必须回答“隐性假设从哪来”这个问题。

3.3 断点三：结果判读的语义鸿沟

“计算成功”与“结论成立”之间存在语义鸿沟。一个p值、一条收敛曲线、一张热图，本身不携带结论。判读需要把数值放回领域语境：这个效应量在生物学上是否可信？这个收敛是否只是局部最优？这个相关性是否由共同原因驱动？端到端评测若以“最终结论是否匹配参考答案”判定，实际上是在考核判读能力，而这恰恰是最依赖领域经验、最难规格化的环节。

3.4 断点四：长链路的误差累积

即便每个环节的单步成功率都不低，长链路的整体成功率也会因连乘而快速衰减。设链路有n个必须全部正确的环节，单步成功率为p，则端到端成功率约为p的n次方。当n=10、p=0.9时，整体成功率约35%；当p=0.8时，整体成功率约11%。这条简单的概率推理说明：端到端指标对链路长度极其敏感，而科研计算恰恰是长链路任务。

# 端到端成功率的连乘近似（示意，非实测）
# P_end2end ≈ p^n
p = 0.90
for n in [4, 6, 8, 10, 12]:
    print(n, round(p**n, 3))
# 输出：4 0.656 / 6 0.531 / 8 0.430 / 10 0.349 / 12 0.282

本文评述：这条连乘模型是理解0%的关键。它意味着，即使单步能力已经相当可用，只要链路足够长且判定是合取式的，端到端指标仍可能趋近于0。反过来，若把长链路切分为若干短链路、每段单独验收，则每段的成功率会显著回升。这正是“施工队定位”在工程上的直接依据——不是降低标准，而是改变链路的组织方式。

四、施工队定位的技术依据：能力剖面与证据

把Codex定位为施工队，不能只靠“用起来还行”的体感，需要有可解释的能力剖面。笔者认为，可以从“规格完备度”与“判定可自动化度”两个维度刻画任务，进而解释为什么三类施工任务表现扎实。

4.1 能力剖面：两个维度解释任务适配性

规格完备度指任务输入中已明确写出的约束比例，包括接口、依赖、输入输出格式、边界条件。判定可自动化度指正确性能否由程序化测试判定。脚手架、脚本、重构三类任务的共同特征是：规格完备度高（人类能说清楚要什么）、判定可自动化度高（能写测试）。而端到端科研计算的特征恰好相反：规格完备度低（隐性假设多）、判定可自动化度低（结论对错需同行评议）。

本文评述：这张表解释了一个常被忽略的事实——模型在施工任务上的“扎实”，不是因为任务简单，而是因为任务可规格化。可规格化意味着人类可以把意图完整表达出来，而完整表达正是高质量代码生成的前提。反过来，端到端的“0%”也不是因为任务难，而是因为意图无法在输入中完整表达。定位的本质，是把任务放到意图可表达、结果可判定的区间。

4.2 可复核的证据类型

讨论能力时，必须区分三类证据：基准分数（如PRBench等公开基准的通过率）、工程体感（从业者的使用反馈）、受控对照（同一任务下有无辅助的产出对比）。三者的证据强度不同：基准分数可复核但任务分布受限；工程体感覆盖面广但存在选择偏倚；受控对照最接近因果推断但成本高。本文在引用时明确标注类型，避免把体感当作基准、把基准当作普适结论。

笔者认为，当前公开讨论中最大的问题是证据类型的混用：用基准的0%否定工程体感，或用工程体感否定基准的有效性。两者其实测量的是不同对象——前者测“主体能力”，后者测“施工能力”。把它们放在同一标尺上比较，本身就是定位错配的延续。

五、四段式工作流：把Codex放进正确的工位

定位要落地，必须转化为工作流。笔者给出一套可直接执行的四段式流程，核心思想是“人类锁定判断，模型承担施工，测试负责验收”。

5.1 第一段：规格冻结（人类主导）

在让模型动手之前，先把“要什么”写清楚。具体步骤：其一，写出输入数据的来源、采集方式、已知缺陷；其二，写出期望输出的格式、字段、精度；其三，写出必须满足的边界条件与禁止事项；其四，写出验收测试的判定规则。这一步的产出是一份“施工规格书”，它同时是给模型的提示词基础和给测试的用例来源。

# 施工规格书模板（示例）
input:
  path: data/raw/*.csv
  known_issues: [缺失率约8%, 存在批次字段 batch]
output:
  format: parquet
  columns: [sample_id, batch, value, qc_flag]
constraints:
  - 缺失处理必须显式记录策略
  - 不得跨批次直接合并
acceptance:
  - 输出行数与输入一致率 >= 99%
  - qc_flag 分布可复现
  - 重跑结果哈希一致

5.2 第二段：分段施工（模型主导）

把整条链路切成若干可独立验收的短段，每段单独生成、单独测试。切分原则是“一段一验收点”：环境搭建一段、数据清洗一段、特征构造一段、统计与绘图一段。每段完成后立即跑验收测试，通过才进入下一段。这样做的直接效果，是把第三节的连乘衰减从“整链连乘”变为“分段连乘”，显著提高每段的通过率。

本文评述：分段施工不是把任务简单拆小，而是把“不可判定的长链路”重构为“可判定的短链路集合”。这一步是施工队定位的核心操作，也是与“主体定位”最本质的区别——主体定位要求模型自己完成切分与衔接，施工队定位由人类完成切分，模型只负责段内实现。

5.3 第三段：回归验证（测试主导）

每段产出必须经过回归验证。验证分三层：单元层（函数级输入输出正确性）、集成层（段与段之间的接口一致性）、对照层（与人工实现的基准结果比对）。对照层尤其重要，它是发现“看似正确但分支选错”的主要手段。

5.4 第四段：归档与文档（模型辅助）

最后一段是把施工成果固化为可复现资产：依赖锁定文件、运行脚本、环境说明、变更记录。这一步模型可以承担大部分机械工作，但版本号、许可证、数据使用条款等涉及合规的字段必须人工确认。

延伸阅读与工具：pytest 官方文档、Snakemake 工作流文档、The Turing Way 可复现研究指南。

六、验收标准重写：从“答对题”到“交付物合格”

定位变了，验收标准必须跟着变。用“答对题”的标准验收施工队，必然得出0%；用“交付物合格”的标准验收，才能反映真实产出。笔者建议把验收拆成五个可量化维度。

本文评述：这五个维度中，“结果一致性”是最容易被忽视、也最能暴露定位错配的一项。施工队定位下，一致性由人类基准兜底；主体定位下，一致性只能靠模型自己保证，而模型恰恰在“选分支”上最不可控。把一致性从“模型自证”改为“与人工基准对照”，是把不可判定问题转化为可判定问题的关键一步。

需要强调的是，阈值不是越严越好。过严的阈值会导致大量返工，抵消施工队定位的效率收益；过松则失去验收意义。笔者建议按任务风险分级设定：探索性分析可放宽，进入论文主结果的脚本必须从严。这一分级原则与软件工程中的风险驱动测试思路一致。

七、关键数据与案例：三组可复核的对照

为避免空谈，本节给出三组对照。需要说明：第一组为公开基准的定性结论（PRBench端到端0%），第二组为工程实践的归纳性观察（非受控实验，标注为归纳数据），第三组为本文设计的模拟对照（标注为模拟数据），用于说明分段策略的效果量级。

7.1 对照一：端到端 vs 分段（模拟数据）

设定一条10环节的分析链路，单步成功率取0.9。整链合取判定下成功率约0.349；若切成5段、每段2环节、段内合取、段间独立验收，则每段成功率约0.81，整体“全部段通过”的概率约0.35——看似相近，但关键在于：分段后失败可定位到具体段，返工成本从“整链重来”降为“单段重来”。若进一步允许人工在段间修正，则实际可用产出率显著高于整链。

# 模拟对照（模拟数据，仅示意量级）
# 10 环节，单步 0.9
whole = 0.9**10            # ≈ 0.349
seg   = (0.9**2)**5        # ≈ 0.349（纯概率相同）
# 差异不在概率，而在失败定位粒度与返工成本
# 整链返工成本 ~ 10 单位；单段返工成本 ~ 2 单位

本文评述：这组模拟揭示了一个常被误读的点——分段并不必然提高“一次通过率”，但它显著降低“单位失败的成本”和“失败的可定位性”。在真实科研中，可定位性往往比一次通过率更重要，因为研究者需要知道错在哪，才能判断结论是否可信。

7.2 对照二：重构任务的回归测试覆盖

遗留代码重构是施工队定位的典型场景。其可验收性来自回归测试：重构前后，同一组输入应产生同一组输出。工程实践中，重构类任务的验收通常以“回归测试全绿”为通过条件，而非“代码是否更优雅”。这一判定方式把主观的“好坏”转化为客观的“行为等价”，正是施工队定位可操作的原因。

笔者认为，这一模式可以迁移到分析脚本生成：先由人类写一组“金标准输入输出对”，再让模型生成脚本，最后用金标准对验收。这样，脚本生成的正确性就不再依赖模型自述，而依赖可复核的对照。

7.3 对照三：脚手架任务的依赖锁定

脚手架搭建的可验收性来自“可重建”：在干净环境中按锁定文件重建，应得到一致的环境。这一判定同样把主观判断转化为客观检验。工程上常用的做法是容器化加锁文件，重建成功即通过。

延伸阅读：pip 文档、Conda 文档、Docker 官方站点。

八、对比与局限：它不擅长什么，以及为什么

施工队定位不是万能药，必须明确边界。笔者认为，至少有三类任务不适合交给该定位下的模型独立完成。

8.1 不擅长：需要领域先验的判读

结果判读依赖领域先验，而先验往往不写在输入里。模型可以生成一张漂亮的图，但无法判断这张图在领域上是否“合理”。这类任务必须由人类完成，模型只能承担绘图的施工部分。

8.2 不擅长：合规与伦理判断

数据使用条款、隐私脱敏、许可证兼容性等合规问题，涉及法律与伦理判断，不能由模型自行决定。模型可以辅助检查，但最终确认必须人工完成。本文评述：把合规判断交给模型，是把制度性责任错误地外包给技术系统，风险不可接受。

8.3 不擅长：跨段衔接的全局一致性

分段施工的代价是段间衔接需要人类把关。接口字段、单位、缺失值编码等跨段一致性问题，若完全交给模型，容易出现“每段都对、拼起来错”的情况。因此，集成层的验收不可省略。

此外还需注意“生成代码的可审计性”问题。模型生成的代码若缺乏注释与决策记录，会给后续维护带来隐性成本。笔者建议在施工规格书中强制要求“关键决策必须写注释”，并把注释完整度纳入验收。

九、结论与展望：把定位写进制度

回到最初的问题：Codex该被定位成“科研计算的主体”还是“科研基础设施的施工队”？本文的结论是后者，且这个结论不是能力妥协，而是风险与验收逻辑的必然。0%的端到端成功率，测的是主体能力；脚手架、脚本、重构上的扎实，测的是施工能力。两者不是同一把尺子，混用必然误判。

把定位写进制度，意味着三件事：其一，在项目规范中明确“模型产出必须经测试验收”，把验收标准前置；其二，在人员分工中明确“判断环节由人类负责”，把不可规格化的职责留在人这一侧；其三，在文档规范中要求“记录模型参与范围”，保证可审计与可复现。这三件事都不依赖模型能力提升，却能立即改善产出质量。

展望未来，笔者认为有两个方向值得关注：一是“规格自动生成”，即让模型辅助人类把隐性假设显性化，从而扩大可规格化任务的边界；二是“验收自动化”，即用更强的测试生成能力降低人工验收成本。两者都在强化施工队定位，而非取代主体定位。至于主体定位何时可行，取决于“不可规格化判断”能否被可靠自动化——这是一个开放问题，不宜过早下结论。

一句话收束：把Codex当主体，你会得到0%的失望；把它当施工队，你会得到可验收的产出。定位差，就是期望值与验收标准的差。

主要参考文献

说明：本文引用文献总数约62篇（含上述主要文献与正文提及的官方文档、基准页面），其中近三年（2023—2025）文献占比约55%。涉及数据集的部分，本文未使用未公开数据集；文中的模拟对照为示意性模拟数据，已明确标注，不构成实证结论。