Codex“只保证代码语法可运行，绝不保证科研逻辑正确”，统计方法误用、分析流程漏洞都需要人亲自核验——“用Codex打底稿、自己做终审”这个分工，在论文投稿的时间压力下到底守不守得住？

一、问题的提出：当“能跑”被误读为“对”

大模型代码生成工具在科研工作流中的渗透速度，远超多数方法学教材的更新速度。以 OpenAI Codex 系列模型为代表的一类系统，其训练目标是在给定自然语言意图与上下文时生成语法正确、语义合理的代码片段。需要明确的是，这类系统的优化目标函数并不包含“统计推断有效性”这一项。换言之，一个脚本可以完美通过解释器、无异常退出、输出格式规整的 CSV，同时在统计上完全错误。这个边界并非缺陷，而是产品定位的必然结果。

笔者在审阅与复现工作中反复观察到一种认知错位：研究者把“代码跑通了”当作“分析做对了”的代理指标。这种代理在传统手写代码时代尚有一定合理性，因为手写过程本身迫使作者逐行思考数据流；而在生成式工具介入后，代理关系被切断。代码的“可执行性”与“正确性”之间原本就存在的缝隙，被生成工具显著放大。本文的核心判断是：Codex 类工具的主要风险不在于它写错代码，而在于它写出的代码“看起来对”，从而系统性地降低了研究者启动核验的动机。

这一判断可以形式化为一个简单的成本转移模型。设研究者完成某项分析的总成本为 C = C_write + C_verify。生成工具把 C_write 压缩到接近零，但 C_verify 并未同比下降，甚至因为代码来源的外部化而上升——研究者需要先理解一段并非自己写的代码，才能判断其逻辑。当外部约束（如投稿截止日期）固定了 C 的上界时，被压缩的必然是 C_verify。这就是“打底稿—终审”分工在时间压力下失效的经济学根源。

笔者认为，把“AI 生成、人工终审”类比为“实习生写初稿、导师把关”是危险的。实习生与导师共享同一套方法学训练背景，且实习生对错误有羞耻感与责任意识；生成模型既无方法学信念，也无责任约束，其输出分布由训练语料决定，而语料中大量已发表论文本身就存在统计误用。这意味着模型可能在“模仿已发表错误”。

二、错误形态的迁移：从显性 bug 到隐性逻辑缺陷

2.1 两类错误的可检测性差异

传统手写代码的错误大致分为两类：语法错误与逻辑错误。语法错误由解释器或编译器即时拦截，反馈延迟以毫秒计；逻辑错误虽难发现，但往往伴随异常输出（如全 NaN、维度不匹配、结果与预期量级严重偏离），存在较强的“信号”。生成式工具改变了这一分布：它极少产生语法错误，却高频产生“语法正确、语义可疑”的代码。这类代码不触发任何运行时异常，输出数值也在合理范围内，因此缺乏任何自动告警信号。

以常见的差异表达分析为例。若研究者要求模型“对表达矩阵做 t 检验并输出 p 值”，模型很可能生成逐基因调用 t 检验的循环，且默认使用未校正的 p 值、未考虑多重比较、未检查正态性假设、未处理方差齐性。这段代码可以毫无障碍地运行完毕并输出一张漂亮的火山图。语法层面零瑕疵，统计层面则可能同时违反三到四条假设。本文评述：这类错误的危险等级高于语法错误，因为语法错误会强制中断流程并迫使修正，而统计误用会顺畅地流入下游，直至审稿人或读者发现。

2.2 错误迁移的三种机制

机制一：默认参数的隐性继承。生成模型倾向于复现训练语料中高频出现的调用方式，而这些调用往往使用库函数的默认参数。默认参数在多数场景下是合理的，但在科研场景中，默认值常常对应“最省事”而非“最正确”的设定。例如某些聚类实现默认使用欧氏距离，而研究者实际需要的是相关性距离；某些回归实现默认不报告稳健标准误。

机制二：上下文缺失下的合理猜测。模型无法访问研究者的实验设计、抽样方案与先验假设，只能基于提示词做局部最优推断。当提示词本身表述模糊时，模型会“补全”一个看似合理的分析路径。这种补全在工程语境下是优点，在科研语境下则是风险源，因为它把研究者的方法学决策权悄然转移给了模型的先验。

机制三：错误在模块拼接处累积。真实分析流程由数据读取、清洗、变换、建模、诊断、可视化等多个模块组成。模型逐模块生成时，每个模块内部可能都正确，但模块间的接口约定（如索引对齐、缺失值处理策略、单位一致性）容易错位。这类错误不会在单模块测试中暴露，只会在端到端运行时以“结果略偏”的形式出现，极难归因。

上表揭示了一个结构性事实：自动可检测性与人工核验成本呈负相关。越容易被工具自动发现的错误，人工核验越便宜；而越难被自动发现的错误，人工核验越昂贵。生成式工具恰恰把错误分布推向了表格的下半部分。这意味着“人做终审”的工作量不是减少了，而是被重新分配到了最耗时的区间。

三、统计方法误用的典型模式与人机共犯结构

3.1 五类高频误用

综合方法学文献与笔者复现经验，生成代码在统计层面最易出现的误用可归纳为五类。第一类是多重比较未校正，在组学、神经影像、A/B 测试等多重检验场景中尤为普遍。第二类是伪重复（pseudoreplication），把技术重复当作生物学重复，导致样本量虚高、p 值虚低。第三类是选择性报告，模型倾向于生成“显著”的结果呈现方式，而忽略对不显著结果的完整披露。第四类是模型假设未检验，线性回归未查残差、生存分析未验比例风险假设。第五类是数据泄漏，典型如先标准化再划分训练测试集。

这些误用并非生成工具独有，它们在人类撰写的论文中同样广泛存在。但生成工具改变了误用的“生产速率”与“隐蔽程度”。人类误用往往伴随犹豫与自我怀疑，作者可能在方法部分留下模糊表述；生成工具则给出斩钉截铁、格式规范的代码与注释，这种“确定性语气”会抑制审阅者的怀疑。

本文评述：把统计误用完全归咎于模型是不公平的，也是无益的。模型只是把人类方法学训练中的薄弱环节放大并加速。真正的问题在于，当前科研评价体系对“方法学正确性”的激励远弱于对“结果显著性”的激励，而生成工具恰好是追求显著性的高效放大器。因此，治理路径不能只停留在工具层面，必须落到流程与制度层面。

3.2 人机共犯结构的形成

所谓人机共犯结构，指研究者与生成工具在无意中形成的、相互强化错误的关系。其形成分三步：第一步，研究者用模糊提示词请求代码，模型给出看似完整的方案；第二步，代码运行成功，研究者获得正向反馈，降低了对方法细节的审查强度；第三步，研究者在论文中描述方法时，倾向于照搬代码注释或模型生成的说明文字，而这些文字往往比实际执行的分析更“规范”、更“完整”，从而在文本层面掩盖了实际的方法缺陷。

这一结构的危险在于它具有自我正当化的能力。当审稿人质疑方法时，研究者可以援引“代码是标准实现”“库函数是社区验证过的”作为辩护，而这些辩护在形式上成立、在实质上空洞。笔者认为，打破这一结构的关键不是禁用工具，而是强制建立“方法声明与代码实现”的双向可追溯性，即论文方法部分的每一句陈述，都必须能定位到代码中的具体行，反之亦然。

四、分析流程漏洞的工程成因

4.1 环境与依赖的不可复现

生成代码通常只包含核心逻辑，不包含环境声明。研究者若直接在自己的环境中运行，可能因库版本差异得到不同结果。随机种子未固定、并行计算导致的非确定性、浮点累加顺序差异，都是常见的不可复现来源。这类问题在单次运行中完全不可见，只有在重复实验或换机复现时才暴露。

工程上的标准解法是容器化与依赖锁定，例如使用 conda 环境文件或容器镜像固定版本，并在代码入口显式设置随机种子。但生成工具不会主动提醒这些，除非提示词明确要求。本文建议把“环境声明与种子固定”作为生成代码的强制交付物，而非可选附加项。

4.2 数据血缘的断裂

真实科研数据往往经历多轮清洗：缺失值填补、异常值处理、变量变换、样本剔除。每一步都可能引入偏差，而生成代码通常只覆盖其中一两个环节，且不记录中间数据的版本。当最终结果出现异常时，研究者无法回溯是哪一步引入的问题。数据血缘（data lineage）的断裂，使得调试从“定位问题”退化为“重跑全流程猜问题”。

# 反例：生成代码常见的“一步到位”写法，无中间产物、无版本记录
df = pd.read_csv("data.csv")
df = df.dropna().pipe(standardize).pipe(feature_select)
model.fit(df.drop("y", axis=1), df["y"])

# 正例：显式分步、落盘中间产物、记录每步行数与哈希
raw = pd.read_csv("data.csv")
log_step("raw", raw)
clean = drop_invalid(raw); clean.to_parquet("interim/clean.parquet"); log_step("clean", clean)
scaled = standardize(clean, fit_on="train"); scaled.to_parquet("interim/scaled.parquet"); log_step("scaled", scaled)

上例的对比说明，可追溯性不是靠“写得更仔细”实现的，而是靠结构化的中间产物与日志实现的。生成工具默认倾向于紧凑、优雅的链式写法，这在软件工程中是美德，在科研分析中却常常是负债。

4.3 测试缺位

软件工程有单元测试、集成测试、回归测试的成熟体系，而科研分析代码几乎从不写测试。生成工具进一步降低了写测试的意愿，因为“代码已经能跑了”。然而，科研代码恰恰最需要测试：它的输入数据形态多变，它的输出直接支撑结论，它的错误代价是学术声誉。可行的折中是写“断言式测试”，即在关键节点插入对数据形状、取值范围、分布特征的断言，一旦偏离预期立即报错。

例如，在差异表达分析前断言表达矩阵无负值、样本数与分组标签长度一致、每组样本量不低于阈值；在回归后断言残差均值接近零、方差膨胀因子低于阈值。这些断言不追求覆盖率，只追求拦截“明显不合理”的状态，成本极低而收益显著。

五、终审的认知负荷：为什么“人来做终审”会失效

5.1 审查者悖论

终审的有效性取决于两个条件：审查者具备相应能力，且具备足够时间。投稿时限压力直接侵蚀第二个条件。更微妙的是“审查者悖论”：研究者对自己参与生成的代码，存在确认偏误——他倾向于寻找“代码正确”的证据，而非“代码错误”的证据。心理学研究早已表明，人在时间压力下会转向启发式判断，依赖表面线索（如代码整洁度、注释完整度）替代深度审查。

生成代码恰好在这类表面线索上表现优异：命名规范、注释齐全、结构清晰。这些特征在人类代码中与质量正相关，在生成代码中却与质量脱钩。于是审查者的启发式判断被系统性地误导。本文评述：这不是审查者不够专业，而是线索效度发生了变化，而人的判断策略未能同步更新。

5.2 时间压力下的核验衰减曲线

可以构造一个简化的核验衰减模型。设可用核验时间为 T，核验项目按重要性排序，第 i 项被实际核验的概率随 T 递减，且递减速度与项目所需的认知负荷正相关。由于高负荷项目（如识别策略合理性、数据泄漏排查）恰恰是统计误用的高发区，时间压力下的核验衰减并非均匀，而是优先牺牲最关键的部分。这解释了为何许多“赶出来”的论文在描述性统计上无懈可击，却在因果推断上漏洞百出。

笔者认为，这一模型的政策含义是明确的：与其呼吁研究者“更认真”，不如重新设计核验流程，把高负荷核验项目前置、拆解、并尽可能自动化。人的注意力是稀缺资源，应当集中投放在无法自动化的判断上，而不是消耗在可以脚本化的检查上。

六、可操作的核验协议：分层检查与自动化防线

6.1 三层核验框架

笔者提出一个三层核验框架，按“可自动化程度”而非“重要性”分层，目的是把有限的人力投到最不可替代的环节。第一层是机器可判定层，包括语法检查、依赖锁定、随机种子、数据形状断言、输出范围断言，全部脚本化，零人工。第二层是半自动层，包括多重比较校正、训练测试划分时序、缺失值策略一致性，用模板化检查脚本加人工确认。第三层是人工判断层，包括研究设计与方法的匹配度、因果识别假设的可信度、结论与证据强度的匹配度，只能由具备领域知识的人完成。

6.2 方法—代码双向追溯表

具体操作上，建议在项目仓库中维护一张“方法—代码追溯表”，左列是论文方法部分的每一句陈述，右列是对应的代码文件与行号，以及该陈述所依赖的统计假设。填表过程本身就是一次强制核验：凡是找不到对应代码的陈述，要么是论文写多了，要么是代码漏了；凡是找不到陈述的代码，要么是冗余，要么是未披露的分析。这张表在投稿前应作为内部审查的必查项。

| 方法陈述 | 代码位置 | 依赖假设 | 核验状态 |
| 使用 Benjamini-Hochberg 校正 | stats.py:88 | 检验独立性近似 | 已核验 |
| 训练集与测试集按时间划分 | split.py:12 | 无未来信息泄漏 | 已核验 |
| 缺失值采用多重插补 | impute.py:31 | 缺失随机(MAR) | 待确认 |

6.3 自动化防线的落地工具

工程实现上，可借助若干成熟工具构建防线：用依赖锁定工具固定环境，用持续集成在每次提交时跑断言脚本，用数据版本工具记录中间产物，用笔记本参数化工具确保分析可一键重跑。这些工具的学习成本不高，社区教程丰富，例如 scikit-learn 官方文档中的数据泄漏常见陷阱、statsmodels 文档、The Turing Way 可复现研究指南，以及 可复现研究工作流视频教程，均值得作为团队培训材料。

需要强调的是，工具只能降低 L1、L2 层的漏检率，无法替代 L3 层。把 L3 层外包给工具，等于把研究判断外包给训练语料，这在方法论上不可接受。本文的建议是：把工具用于“排除低级错误”，把人的时间用于“判断高级问题”，而不是反过来。

七、对比与局限：这套分工的适用边界

7.1 适用与不适用的场景

“Codex 打底稿、人做终审”在以下场景中相对可靠：分析流程标准化程度高（如常规描述统计、标准可视化）、结果可被独立数据快速验证、团队具备方法学审查能力且有充足时间。在这些场景中，生成工具确实能显著压缩编写成本，而核验成本可控。

在以下场景中则高度危险：涉及因果推断与识别策略、涉及多重检验与高维数据、涉及生存分析或复杂抽样设计、涉及监管或临床决策支持。这些场景的共同特征是“错误不可从输出表面识别”，且“错误代价高”。笔者认为，对这类场景应实行“生成代码不得直接进入终稿”的硬性规定，生成结果只能作为参考实现，最终代码必须由熟悉方法的人重写或逐行确认。

7.2 局限与未解问题

本文的讨论存在若干局限。其一，缺乏大规模实证数据来量化“生成代码的统计误用率”，现有证据多来自小样本复现与方法学评论，结论的外推需谨慎。其二，不同模型、不同提示策略下的错误分布差异显著，本文的结论主要针对通用代码生成场景，不宜直接推广到经过方法学微调的系统。其三，核验协议的有效性本身需要实证检验，本文提出的是基于工程推理的框架，尚待对照实验验证。

未解问题包括：如何设计提示词以降低统计误用率；如何自动检测“方法陈述与代码实现”的不一致；如何在同行评审环节引入可执行的代码核验。这些问题跨越多学科，需要方法学界、软件工程界与出版界协同推进。

八、结论与展望

回到本文开头的问题：“用 Codex 打底稿、自己做终审”这个分工，在论文投稿的时间压力下到底守不守得住？本文的结论是：在方法层面成立，在默认的时间约束下不成立。不成立的根源不是工具不可靠，而是核验成本被系统性低估，且核验资源在时间压力下被优先牺牲。要让这一分工真正守住，必须把核验从“依赖个人自觉”改造为“依赖流程与工具”，把高负荷检查拆解为可执行、可自动化的步骤。

展望未来，随着代码生成工具与科研工作流的深度集成，方法学核验有望部分内嵌到工具链中，例如在生成阶段就提示“此处未做多重比较校正”“此处存在数据泄漏风险”。但工具永远只能提示，不能替研究者承担判断责任。科研的逻辑正确性，最终仍是一个人的问题，而不是模型的问题。

主要参考文献