这两年我身边做大模型应用的朋友陆续发现一个现象代码榜上的分数还在涨但用起来的手感并没有跟着变好。更准确地说某个模型在某个编程排行榜上又涨了几个点团队把它接进每天要用的代码评审流程结果它给出的建议里仍有一批是“看起来很有道理仔细一比较根本不能用”。编译不过、类型对不上、忽略了上下文里明确写过的约束……这些问题没有因为榜单分数上涨而彻底消失。于是“代码榜逐渐饱和”这句话开始有了另一种解释不是模型的编程能力真的到顶了而是现有榜单已经很难测出真实差距。榜单还在分数还在涨但继续卷同一套评测集的收益越来越低。这是任何评估基准都会遇到的阶段高分不再是稀缺能力高分背后的泛化能力却仍不稳定。也正因为这样行业开始把目光转向更复杂的任务——AI科研。AI科研也被称作AI for Science目标是用大模型来加速科研流程中的某个环节甚至推进整个科研闭环。单从难度来看科研任务确实比写代码更贴近“智能”的本义。写代码是在一个定义相对清晰的系统里寻找可行解而科研是提出新问题、设计实验、解释意外结果、修正假设然后再进入下一轮循环。但这里要先给一句可能和直觉不太一样的话大模型在AI科研上真正卡住的一步不是“不会提假设”而是没有能力独立完成“验证假设”的闭环。下面我会从代码榜的饱和讲起拆开“AI科研”这个方向里最关键的瓶颈最后聊聊从工程角度现在能做什么、不能做什么以及什么样的实践路径是当前真正可以落地的。1. 代码榜不是“做完了”而是“测不出差距了”1.1 从HumanEval到SWE-bench评估任务在变难如果回顾大模型编程评估的演变能看出一条清晰的脉络。早期HumanEval这类基准主要考察“给一个函数描述生成完整实现”题目短、约束少、验证方式简单只要输出和隐藏测试用例一致就算通过。后来出现了SWE-bench把任务难度拉到“给定一个真实GitHub仓库里的issue模型要定位问题并生成完整补丁”。这已经不是函数级补全而是仓库级修复要求模型理解跨文件依赖、调用关系、历史代码风格还要让补丁通过测试。再往后又出现了一批更强调“过程正确性”和“长期任务”的评测集。整个趋势很明显评估从“能不能写出这一段代码”走向“能不能在复杂代码库中完成一个真实任务”。这个方向是对的。但问题也出在这里随着榜单分数不断上涨评测集的区分度在下降。当一个任务被反复纳入训练数据又使用了公开可见的评测集时模型对“这个题型的做题模式”的记忆往往比“对真实代码任务的理解”更强。1.2 分数上涨背后是数据效应和评估局限代码榜分数上涨并不是一个纯粹的“模型变聪明了”的故事这里面至少有两部分。一部分是数据效应。各家模型在训练时会把大量公开代码库、开源项目、常见题解都纳入数据集。评测集如果也是公开的模型很容易在训练阶段接触到相似的题目。这不是说模型完全没有能力而是说“这个分数”反映的并不全是“解决问题的能力”。另一部分是评估局限。现有代码评测大多以“单元测试通过率”或“补丁是否修复Issue”为准。但真实工程需求远不止这些还涉及边界情况、兼容性、可维护性、性能约束、错误提示友好度以及面对一个模糊需求时的多轮澄清能力。这些在当前评测框架里很难量化。所以你会看到一种很常见的矛盾现象某个模型在榜单上排名靠前但在真实项目里给出的接口设计建议却很“教科书”。单看每一步都对放到整个系统里就漏洞百出。1.3 饱和的真正信号不是“能力到顶”而是“收益递减”代码榜逐渐饱和的准确信号不是“模型不再进步”而是“继续用当前方法卷榜单的收益在递减”。当榜首分数从75涨到80从80涨到82每一步都需要投入更多的训练算力、更长的高质量数据清洗周期但带给普通开发者的体感变化却越来越小。原因很简单大家日常使用的代码任务并不是榜单最难的“临界题”而是大量处在“会与不会”边缘的普通任务。这些任务的瓶颈往往不在生成能力而在上下文理解、长链路执行、工具调用和回归验证。从这个角度看代码榜饱和不算坏事。它把行业从“卷单项分数”里逼了出来去寻找更复杂的下一站。AI科研就是这个被反复点名的新方向。2. 为什么AI科研是下一个前沿而不是又一个测评游戏2.1 科研任务与代码任务的核心差异科研和代码最本质的区别在于“正确性”的定义。在代码任务里正确性通常是可判定的测试通过了就说明这一版实现是有效的至少在这个测试集上是有效的。科研任务则完全不同。一篇论文里的结论“正确”与否不是一个静态测试集能判定的它需要实验支撑、重复验证、同行评议甚至需要经过几年时间才能确认。科研流程里最关键的一环不是“生成一个看起来合理的答案”而是“设计一个能区分不同假设的实验”。这个实验可能涉及物理设备、化学反应、临床试验、传感器读数、数值模拟。对模型来说它要处理的不是一段文字到另一段文字的映射而是在一个物理世界或复杂系统里做决策。另一个差异是开放性。代码任务里有明确的问题边界科研任务经常没有清晰的问题定义。“这个现象为什么会这样”“哪个变量真正起作用”这些问题的答案不是现成的。2.2 已有进展大多来自“特定任务突破”而不是“通用科研能力”过去几年AI在科学研究中的应用确实有关键突破。比如AlphaFold在蛋白质结构预测上取得的进展让生物领域研究者第一次体会到“模型不是辅助工具而是核心方法”。类似的还有材料科学中的候选材料筛选、气象预测中的大模型预报等。但这些进展有一个共同特征它们都是“窄而深”的任务任务目标、输入输出格式、评估指标都高度明确。模型在大量结构化数据上训练然后解决一类被定义得很清楚的预测问题。一旦把任务从“蛋白质结构预测”扩展到“请你帮我设计一个研究方案并告诉我在这个方案里哪些假设最值得验证”模型的能力就立刻变得模糊。它可以生成读起来像模像样的研究设计但它没有办法在真实世界里执行这个设计更无法通过实验反馈来迭代自己的判断。2.3 真正稀缺的不是生成能力是“科研判断力”现在大模型的生成能力已经很可观。给一个研究方向它可以写出大量候选假设、调研摘要、实验设计初稿。很多研究者已经在用大模型做这些事也确实节省了不少时间。但科研难的不是“想不出来”而是“判断哪个想法值得真正投入资源去验证”。科研判断力至少包含三层对已有文献的解释和归纳是否可靠对候选假设的新颖性、可测试性、成本与收益的判断是否准确对实验结果的解读是否能在“支持结论”和“可能只是巧合”之间保持清醒。这三层能力大模型目前都不具备真正的稳定实现。它可以模仿判断的外形但没法承担判断的后果。这也是为什么“AI科研”目前更像“AI辅助科研”而不是“AI自动科研”。3. 大模型最卡的那一步从“生成”到“验证”的闭环3.1 “会提假设”不等于“会做科研”很多人对大模型参与科研的第一联想是让模型提出新假设。这个联想没有错大模型确实能基于已有文献提出一些假设有时候还相当有启发性。但科研的真正引擎不是假设生成而是假设验证。一个完整科研循环大致是观察现象 → 提出假设 → 设计实验 → 执行实验 → 分析结果 → 修正假设 → 进入下一轮。在这个循环里假设生成只是第一步。后面每一步都要和真实世界发生交互。哪怕你设计了一个很漂亮的模拟实验模拟器本身的参数、边界条件、误差来源都需要人来判断。模型可以帮你写代码但代码跑出来的结果是不是符合物理意义、有没有收敛问题、误差是否在可接受范围这些判断仍然依赖人的经验。大模型的强项是模式匹配。它在海量文本和数据上训练能够提取出“这类问题通常长什么样”的统计规律。但科学结论要求的是因果解释和可重复的验证。统计规律可以帮助寻找候选但不能替代因果验证。3.2 验证环节的大模型弱点缺乏真实世界反馈通道如果仔细拆解大模型的工作方式会发现它在“生成”这一步极其高效在“验证”这一步近乎失明。生成假设时模型只需要把输入和输出之间建立概率关系。只要训练数据够多它就能生成看起来合理的假设。但验证假设需要的是外部反馈跑一次实验观察结果把结果和预期对比再决定下一步。当前大模型没有这个反馈通道。你让模型回答“如果这样设计实验可能会得到什么结果”它能给你一个流畅的回答但这个回答不是来自真实实验而是来自它对世界文本分布的统计。问题在于科学中大量真正的知识不在文本里而在实验数据和物理规律里。所以大模型在AI科研上最卡的一步不是“模型不够大”“数据不够多”而是“它无法独立获得真实世界的反馈因此无法对自己的假设负责”。3.3 AI幻觉在科研场景中的放大效应“AI幻觉”这个词大家不陌生但科研场景下的幻觉代价比代码场景高得多。代码场景里如果模型生成了一段有误导性的代码通常立刻会报错或者测试用例失败。错误是显性的发现成本低。科研场景里如果模型给出一个有误导性的文献解读、一个看似合理的实验设计或一个貌似支持某种结论的数据分析思路错误往往藏在论证链条深处。没有足够的专业背景甚至看不出哪里可疑。更麻烦的是大模型可以用自信的语态包装不确定性。它会用“根据已有研究表明”“现有证据支持”这类句式把可能不存在的引用、不准确的发现、站不住脚的推理包装成严谨结论。这在通用对话里只是“回答不够准”在科研流程里却可能直接影响实验设计方向。这也是我坚持认为当前AI科研最现实的落地路径不是“全自动科研”而是“科研Copilot”——让模型负责生成、整理、初筛、编撰让研究者负责验证、决策、承担责任。4. 从工程角度看现在能做什么4.1 先把目标定为“科研Copilot”而不是“全自动科研”如果你正准备在大模型基础上做科研辅助系统我建议先冷静一下评估自己手里的真实资源和目标。做一个“全自动科研系统”意味着要处理真实实验环境、设备接口、数据采集、误差分析、异常处理、伦理审查等大量问题。这些问题没有一个是大模型能单独解决的。短期内一个可行的工程目标是“科研Copilot”模型擅长什么就让它做什么人的判断留在关键节点上。科研Copilot适合承担的任务包括文献检索和摘要整理对多篇论文进行结构化归纳生成候选假设列表并对每个假设给出可测试性的评估辅助设计实验草稿和数据分析方案把研究者的口述想法转成规范文档生成代码或数据处理脚本来做初步分析。这些任务共同点是输出可以被人工快速校验错误成本受控并且可以反复迭代。4.2 一个最小闭环假设生成 → 人审 → 工具执行 → 结果记录这不是一个完整科研系统而是一个可以落地的流程框架。你可以按这个顺序搭第一版准备输入收集结构化文献摘要、项目文档或研究笔记作为模型上下文。假设生成让模型基于输入生成一批候选假设并附上理由和可能的验证方法。人审过滤研究者对候选项做第一轮筛选标记出值得继续验证的项。工具执行针对筛选出的假设调用代码脚本、数据分析工具或模拟器跑一轮初步验证。结果记录把模型输出、人审意见、工具执行结果、最终结论统一记录到日志或实验管理系统里。这个闭环的核心不是“让模型做科研”而是“让模型参与科研流程中的信息处理环节并确保每一步都可追溯、可复查”。4.3 一个简化示例模型生成候选假设假设你已经有了一个支持OpenAI兼容接口的模型服务。下面这段代码可以作为一个非常简化的框架展示如何把“假设生成”变成一个可复用的流程。注意这只是一个通用示例实际使用时需要根据你的环境和接口文档调整。import json from openai import OpenAI # 通用写法请根据你的服务地址、模型名和密钥调整 client OpenAI( base_urlhttp://your-model-server:8000/v1, api_keyyour-api-key ) def generate_hypotheses(research_notes: str, temperature: float 0.7): messages [ { role: system, content: 你是一个科研助理。请基于给定的研究笔记生成候选假设。 每个候选假设需要包含假设描述、理论依据、可测试性评估、 建议的初步验证方式。 }, { role: user, content: f研究笔记\n{research_notes} } ] response client.chat.completions.create( modelyour-model-name, messagesmessages, temperaturetemperature, max_tokens2000, top_p0.9, seed42 ) return response.choices[0].message.content if __name__ __main__: notes 你的研究笔记或文献摘要。 print(generate_hypotheses(notes))这里有几个参数值得解释。temperature控制生成随机性。科研场景建议从0.7开始偏高可以让模型提出更多样化的假设但如果你发现输出太发散可以降到0.3到0.5。top_p和temperature一起控制采样多样性。一般保持默认0.9左右即可不需要频繁调整。max_tokens限制输出长度。生成结构化假设建议给足2000太小会截断理由和验证建议。seed设置随机种子能在一定程度上提高多次运行的可复现性。但要注意不同服务商对seed的支持程度不同不是所有模型都严格保证seed生效。注意不要把seed当作完整可复现性的保证。真正保证可复现的方式是记录完整的输入、模型版本、参数、环境依赖和输出结果。4.4 落地时最容易踩的坑先说数据清洗。科研Copilot的输入质量直接决定输出质量。文献摘要如果本身不完整、格式不统一模型给出的假设可能会偏离真实研究重点。建议先做数据清洗至少统一字段格式、去重、过滤明显无关内容。再说上下文长度。科研文档通常很长。如果一次性全部塞进模型上下文既不经济又可能丢掉关键信息。建议先做检索或切分把最相关的段落提取出来再传给模型。还有版本管理。模型迭代很快不同版本在同一问题上的表现差异明显。科研辅助系统一定要记录每次结果对应的模型版本。否则一个月后你想复现当时的某个候选假设会发现自己根本不知道当时用的是哪个模型、哪个prompt。最后是结果审查。模型生成的每一个假设都要有一个人审节点。不要让模型产出的内容直接进入实验阶段。还要提醒一句科研数据的权限管理不能省。一旦实验记录和模型调用日志混在一起后续想追查某个结论的来源会非常痛苦。4.5 排查链路从“模型没输出”到“结果不可复现”如果跑科研Copilot流程时遇到问题建议按这个顺序排查。看现象是请求失败、输出为空、输出截断还是结果明显偏离主题看输入研究笔记是否为空格式是否正确有没有超过上下文长度特殊字符是否破坏了JSON结构看环境模型服务是否正常API地址是否可达依赖库版本是否匹配看参数temperature是否过高导致发散max_tokens是否过小导致输出被截断seed是否影响了结果重复性看工具边界当前模型是否支持足够长的上下文是否支持结构化的JSON输出在科研任务上的表现是否稳定排查时不要急着改参数。先把输入、环境、日志这三项看清楚很多时候问题根本不在参数而是输入里混入了一个空文件或者服务端返回了一个你没注意到的错误信息。5. 边界、瓶颈与下一步5.1 哪些科研任务适合AI介入哪些不适合适合AI介入的科研环节通常具备这些特征信息密度高、有比较明显的模式、输出可以被快速校验、失败成本低。根据这些特征下面这份表格可以作为一个参考任务类型适合AI参与程度说明文献检索与摘要高模型擅长结构化归纳人工复核成本低候选假设生成中高模型可以提供候选但筛选和判断仍靠人数据清洗与特征初筛高规则与模型结合能明显提效实验设计与参数搜索中模型可以给方案但真实实验仍需人工执行物理/化学/生物实验执行低设备接口、安全、伦理限制多当前不适合全自动科研结论的最终判断低目前应由人承担判断责任不适合AI介入的场景不是“模型没有能力”而是“错误成本太高”。比如医疗方案、药物研发、涉及人身安全的实验设计这些场景即使模型给出了80%正确的输出剩下20%的错误代价也可能不可接受。5.2 如果要长期投入还需要补哪些工程化能力如果你打算把科研Copilot从实验项目做成可持续使用的系统下面这几项能力需要优先建设。知识库和检索不能每次都把整个文献库塞进模型要有分层索引和向量检索。实验记录与版本追踪每次模型输出、人工意见、实验参数、结果数据都要绑定记录。评估与回归定期用一组固定问题评估模型在科研辅助任务上的表现防止升级后能力回退。权限和审计科研数据通常敏感需要控制访问权限保留操作日志。异常处理模型服务可能超时、返回异常、截断、甚至被误触发拒绝回答。系统要能优雅降级。这些能力会决定系统能不能长期运行。一个只跑通一次Demo的科研助手很容易做但如果没有日志、版本和评估它很快会变成“不可控的黑箱”。5.3 长期判断从“模型能力”到“科研贡献度”代码榜饱和这件事本质上是一个信号评估方式需要从“单项生成能力”转向“真实任务中的长期贡献”。对应到AI科研未来一定会出现更复杂的评估框架。不是单纯问“模型能不能生成一个像样的研究计划”而是问“在模型参与下一个科研团队的探索效率是否明显提升”“模型能不能帮助研究者更早排除错误假设”“模型产出的结果能不能被独立验证”。到那时衡量一个AI系统价值的指标可能就不再是排行榜分数而是它对真实科研进程的贡献度。这个贡献度很难用一个数字概括但它比任何一个“分数”都更有意义。对普通开发者和研究者来说现在最值得做的不是等待“全自动科研系统”出现而是先把科研Copilot这条路走通。从一个最小的闭环开始一个靠谱的模型服务、一批干净的数据、一个人工确认流程、一套完整日志。让模型承担它擅长的部分把判断和验证留在人这边。回过头来看“代码榜饱和”和“AI科研”其实是同一件事的两个侧面。代码榜饱和说明基于静态评测集的进步已经接近边际收益为零继续卷分数不再是衡量智能的好方法。AI科研之所以被视为下一个前沿是因为它真正挑战的是大模型的验证能力而验证能力恰好是目前大模型最薄弱的地方。大模型最卡的那一步不是继续扩大参数而是学会“在真实反馈面前修正自己”。这一步没有靠刷训练数据就能完成的捷径只能靠更扎实的工程流程和更谨慎的人机分工一小步一小步往前走。如果你正在考虑把大模型引入科研工作流我的建议很简单先跑一个最小闭环把输入、输出、工具调用、人工审核和日志留好。跑通之后你会发现“AI科研”这个宏大的词落到地面上其实是每一天的流程改进。