科学家用 LLM 做科研为什么反而“做得更多、做得更差”最近有一项建模研究的预测在学术界引起了不小的讨论科学家使用 LLM 做研究最终会“做得更多但做得更差”do more, less well。这个结论听起来有点反直觉。毕竟 2023 年以来几乎所有关于 LLM 的讨论都在强调“效率提升”“成本降低”“生产力解放”。代码补全、文献总结、实验设计、论文润色大语言模型似乎正在把科研人员从繁琐的重复劳动中解放出来。怎么突然有人预测说用了 LLM科研质量反而会下降我个人的判断是这个预测不是危言耸听它指出的问题恰恰是当前 AI 辅助科研最大、也最容易被忽视的风险——LLM 提高的是“产出速度”而不是“判断质量”。如果科研工作流中的关键判断环节被自动化科学家确实会发表更多论文但每篇论文的平均价值和创新含量可能都会下降。这篇文章不打算重复“AI 会取代科学家”之类的宏大叙事而是想从技术角度拆开这件事这项模型研究为什么做出这个预测它的依据在科研工作流中对应哪些真实环节我们这些实际使用 LLM 做研究、做开发、做工程的普通技术人员应该怎么避免“做得多、做得差”1. 这篇文章真正要解决的问题先聊一个很多科研人员和工程师都正在经历的场景。以前写一篇论文从文献调研到实验设计再到跑实验、分析数据、写初稿一套流程走下来少说几个月。现在有了 LLM文献综述可以交给 ChatPDF 类的工具实验代码可以有 Copilot 辅助生成初稿可以让模型先出一个版本甚至审稿意见都可以让 LLM 先帮忙分析一遍。看起来一切都在加速。但问题是速度上来了判断跟上了吗举个最常见的例子。让 LLM 帮你设计一个对比实验它会非常流畅地给出方案数据集选什么、模型选什么、评估指标是什么。但如果你追问一句“为什么这两个方法适合放在一起对比”“为什么控制变量只控制这三个”“这个基线选择会不会引入不公平的比较”模型给出的答案往往是基于训练语料中被高频写入的“标准做法”而不是基于你对这个具体问题的深入理解。也就是说很多科研环节被 LLM“自动化”掉的同时原本需要在执行过程中沉淀下来的领域判断力也被跳过了。这篇文章要解决的核心问题就是在科研和工程场景中使用 LLM哪些环节可以自动化哪些环节必须保留人的判断如何判断 LLM 辅助是否真的提升了科研质量而不是仅仅提升了产出数量如果你是科研人员、算法工程师、技术团队负责人或者只是正在写毕业论文、准备投稿的学生这篇文章都值得读完。因为“用 LLM 加速工作”这件事本身没有问题问题出在多数人根本没有意识到加速的代价是什么。2. 建模研究说了什么一个值得认真对待的结论先说明一点我不掌握这篇建模研究论文的完整原文以下分析基于项目标题提供的信息以及我对科研工作流和 LLM 行为的理解。如果你手头有完整论文建议以原文为准。从标题Scientists using LLMs will do more, less well, modelling study predicts来看这项研究的核心结论是一个预测而不是已经发生的事实。它通过建模方法模拟了科学家在引入 LLM 辅助工具之后科研系统整体的产出变化。“做得更多”容易理解。LLM 确实能大幅减少文献阅读、代码编写、文本生成等环节的时间成本单位时间内能产出的论文数量、实验数量、代码量都会上升。“做得更差”则是建模研究的核心发现。为什么会更差我推断这背后包含两个层面2.1 选择性问题做得多意味着选择标准被稀释学术研究天然是一个“宽度优先”的过程。一个科学家同时推进多个课题用 LLM 把每个课题的初稿、代码、数据处理都加速之后他会倾向于启动更多课题、写更多论文。但问题在于发表机会是有限的而高水平期刊和会议的容量更是有限的。当每个科学家都更“多产”时筛选标准不可避免地会被推高或者反过来被稀释。如果一个科学家原本一年做 2 个课题每个课题花 6 个月深入打磨现在用 LLM 辅助一年做了 10 个课题每个课题只有 6 周时间和 0.2 个科研人员的深入投入。那么每个课题的完成度、异常分析、对照实验的严谨性大概率都会下降。2.2 同质化问题LLM 不是随机探索者而是模式追随者这一点在技术层面更关键。LLM 的训练目标是“基于已有文本预测下一个 token”所以它的输出本质上是训练语料中高频模式的复现。当大量科学家都用 LLM 来做同样的事情——让模型帮忙提出假设、设计方案、分析原因——结果会倾向于收敛到训练语料中已有的“标准答案”。比如你让 LLM 提出“提升模型鲁棒性的方法”它大概率会给出数据增强、对抗训练、正则化、集成学习这些经典方案。这些方案当然有效但它们不是新的。当所有人都从同一个“平均答案”出发科研探索的多样性会显著下降。这才是这项建模研究最值得关注的地方LLM 提高的是样本内任务的执行效率牺牲的是样本外的创新探索。在一个以创新为核心的系统中这可能会导致整体科研产出的“质量坍缩”。3. 为什么这个预测有道理LLM 正在改变科研的认知分工要理解“做得更多、做得更差”为什么可能成为现实需要先看清 LLM 在科研工作流中真正改变的是什么。传统科研工作流中科学家承担着一个完整的认知闭环提出假设 - 设计实验 - 执行实验 - 分析结果 - 修正假设 - 新一轮这个闭环的每一个环节都包含两类认知动作执行和判断。执行跑代码、查文献、写文本、整理数据。判断选择什么问题值得研究、选择什么基线合理、判断实验结果是否符合预期、决定是继续深挖还是放弃。LLM 真正擅长的是第一类——执行。它可以在毫秒级完成文献筛选、代码补全、文本生成。但第二类——判断LLM 目前做得并不好。因为它缺乏对具体问题的深刻理解也缺乏科研场景中的“代价意识”。问题在于当执行速度被无限加速时判断环节会被迫压缩。这不是某个人的选择而是工作流中的必然结果。就像流水线传送带变快了工人在每个工位上停留的时间就变短了质检环节能检查的时间也变短了。具体来说LLM 改变科研认知分工有三个关键机制。3.1 问题选择被外包以前科研人员确定研究课题需要大量阅读文献、反复判断“什么问题是值得解决的”。这个过程慢但它塑造了科学家的品味。现在很多研究者直接问 LLM“帮我列出这个领域值得研究的问题。”模型给出的答案大概率是训练语料中已经被讨论过的热门话题的重新组合。这会导致一个问题大家研究的都是模型“认为值得研究”的问题而不是基于真实世界观察和深度思考得出的问题。3.2 假设多样性下降一个健康的科研生态应该允许大量不同的假设被同时检验哪怕其中很多最终被证伪。但 LLM 参与假设生成后情况变了。模型的输出基于统计规律它倾向于给出“看起来最合理”的假设而不是“最有探索价值”的假设。当几十个研究组同时用同一个模型生成假设时他们提交给期刊的论文在假设层面就趋于同质化。3.3 错误容忍度上升这个机制比较容易理解但后果往往被低估。用 LLM 生成代码、分析和文本时不可避免会引入模型幻觉hallucination。当研究者对这些内容没有足够仔细地审查小错误就会被带进实验、论文和数据中。再加上 LLM 生成的文本表达流畅、格式规范天然带有一种“看起来正确”的光环反而容易让研究者放松核查。结果就是错误率虽然不变但错误被发现的概率下降了。于是系统中累积的错误越来越多整体科研质量随之下降。4. 从 AI 辅助到 AI 替代科研工作流中的危险滑梯经常看到一种论调“LLM 只是辅助工具最终决定权在科学家手里。”这个说法理论上没错但现实是辅助和替代之间并没有一条清晰的界线而是一个危险的滑梯。4.1 辅助阶段人在环上Human-in-the-loop在这个阶段LLM 负责生成草稿、提供建议人类负责把关和决策。比如用 LLM 整理文献时研究者会自己读一遍关键论文自己判断哪些是重要文献。这个阶段通常不会出大问题因为人的判断仍然覆盖了所有关键环节。4.2 半自动驾驶阶段人只在关键节点介入随着工具越来越顺手一些人开始只对 LLM 的输出做“抽样检查”。比如实验代码跑通了就不再逐行审查论文初稿词句通顺就直接提交数据分析结果不深究每个指标的来源。这实际上是很多科研团队现在的真实状态。不是他们不认真而是当 LLM 把执行端缩短到分钟级之后逐项审查的机会成本太高了。4.3 自动驾驶阶段人彻底退出判断真正危险的是这个阶段。当某些团队开始完全依赖 LLM 设计实验、分析数据、撰写稿件甚至投稿回复时人的判断就被彻底绕过了。这时候LLM 不再是一个“辅助工具”而是变成了事实上的“科研自动机”。有人可能会说现在没有哪个正经科研团队会这样干。但看看工程领域就知道这个滑梯是非常自然的。最初大家只是让 AI 补全几行代码后来发现它能生成一个完整的函数再后来发现它能生成一个完整的模块于是人的 code review 变成了 merge review最后变成了“测试过了就行”。科研领域也一样实验报告可以自动生成数据可视化可以自动完成文献综述可以自动整理。如果每一步都“省掉”了人的判断那么最终提交的论文中哪些部分真正经过了科学家的思考就很难说了。4.4 危险的不是幻觉而是“判断力外包”我们总担心 LLM 产生幻觉、给出错误答案。但在科研场景中真正值得警惕的不是错误本身而是科学家把“判断什么是对的”这个任务也外包给了模型。举个例子。假设你给 LLM 一段实验数据问它“这个结果是否支持我们的假设”。模型可能给出一个语气非常肯定的回答“从数据来看验证组的性能提升显著支持原假设。”但实际上模型并没有真正理解统计检验的假设条件也没有意识到你的实验可能存在混杂变量。如果研究者接受这个“AI 生成的结论”而不是自己重新审视数据、检查实验设计那么整个科研过程的认知闭环就被打破了。这就是“做得更差”的真正机制——不是模型不够聪明而是人类放弃了自己最不可替代的能力。5. 落到工程实践如何让 LLM 只加速、不降质前面说了那么多“趋势”和“风险”可能有读者会觉得那我干脆别用 LLM 做科研了这当然不是这篇文章的目的。LLM 确实是当前最强大的生产力工具关键是如何用。下面从工程实践角度给出一些具体的建议和方法。5.1 建立 LLM 辅助科研的“检查点机制”把科研工作流拆成多个阶段每个阶段设置一个必须由人类完成的判断节点。这些节点是“不可外包”的。以论文实验为例阶段建议交给 LLM 的任务必须由人类完成的判断文献调研收集候选论文、生成摘要归纳判断哪些文献真正相关、哪些是领域基石假设生成提供多个候选假设方向选择值得验证的假设判断可行性实验设计生成实验方案表格、辅助选择指标判断基线选择是否公平、控制变量是否合理代码实现生成数据预处理、模型训练代码审查关键逻辑、验证数据泄漏风险实验分析生成图表、输出代码、整理统计结果从领域角度判断结果是否有意义论文写作生成初稿、润色语言、整理参考文献检查论证逻辑、确认每个结论都有数据支撑这个表的重点不是告诉你哪一步能用 LLM而是提醒你你要清楚地意识到自己在哪个环节放弃了判断。5.2 双轨验证让 LLM 辅助生成但让二手来源交叉验证科研工作流中LLM 最常见的错误来源是幻觉和引用捏造。尤其是文献引用模型经常编造看起来真实但实际不存在的论文。一个比较可靠的工程化做法是在关键结论上强制要求双轨验证。比如让 LLM 总结某篇论文的观点时要求它同时提供论文中的原文段落和页码。或者当你需要引用一个重要数据时不要直接引用 LLM 的输出而是让它给出数据来源论文的 DOI 和标题然后回到原文核对。这里有一个最小可行脚本可以用 Python 快速核验 LLM 生成的参考文献是否真实存在。你可以把它做成一个本地小工具每次让模型生成参考文献列表后自动跑一遍。# 文件路径verify_refs.py # 用途核验 LLM 生成的参考文献是否真实存在于 arXiv 或 Crossref # 用法将 LLM 生成的参考文献列表存为 refs.txt运行 python verify_refs.py import re import requests import sys def extract_title(line: str) - str: 从一行参考文献中粗略提取标题。 # 去掉末尾的年份、页码等信息取中间最长的连续字符串 candidates re.findall(r[A-Z][^.:]{20,}, line) if candidates: return max(candidates, keylen).strip() return line.strip() def check_crossref(title: str) - bool: 调用 Crossref API 检查标题是否真实存在。 url https://api.crossref.org/works params {query.title: title, rows: 1} try: resp requests.get(url, paramsparams, timeout10) if resp.status_code ! 200: return False items resp.json().get(message, {}).get(items, []) if not items: return False # 取返回第一个结果的标题做简单相似度比较 real_title items[0].get(title, [])[0] return len(title) 10 and (title[:20].lower() in real_title.lower() or real_title.lower()[:20] in title.lower()) except Exception: return False def main(): with open(refs.txt, r, encodingutf-8) as f: lines [line.strip() for line in f if line.strip()] print(f共检测到 {len(lines)} 条参考文献开始核验\n) for i, line in enumerate(lines, 1): title extract_title(line) ok check_crossref(title) mark [OK] if ok else [WARN] print(f{mark} 第{i}条: {line[:80]}) if not ok: print(f 提取标题: {title[:80]}但在 Crossref 中未匹配到请人工核对。) print(\n核验完成。WARN 条目需要人工逐条确认不要直接相信 LLM 的输出。) if __name__ __main__: main()使用步骤把 LLM 生成的参考文献列表粘贴到refs.txt。运行python verify_refs.py。关注输出为[WARN]的条目逐条人工核验。这只是个最小示例实际项目中可以把它接入 CI做成自动化检查。核心思路是让机器去检查机器让人类只关注必须由人类做的判断。5.3 版本化你的实验决策记录工程领域有 Git有代码 review。科研领域其实更需要类似的机制——不是给代码做版本控制而是给“决策过程”做版本控制。具体来说建议科研团队维护一份DECISIONS.md或者使用类似 ADRArchitecture Decision Records的方式来记录实验中的关键决策为什么选这个基线为什么放弃这个方向为什么修改了评价指标这份记录不是给导师看的而是给你自己看的。因为在 LLM 辅助的环境中很容易出现“昨天改了一个预处理今天忘了为什么改”的情况。没有决策记录你只能让 LLM 帮你“重新推理”当初的意图——这样很容易引入潜意识中的偏差。模板参考# 决策记录 ## 2025-01-15为什么对比实验中选择了 B 模型作为基线 - 背景需要验证新增模块的有效性 - 考虑过的方案 - A 模型公开 benchmark 成绩更好但训练成本高 - B 模型同领域论文中广泛使用的基线参数量适中 - 决策选择 B 模型 - 原因可以复用该论文的公开训练配置减少自研代码引入的变量 - 这个决策和 LLM 的关系LLM 建议选择 C 模型理由是在某 benchmark 上 SOTA。 人工判断后认为 C 模型和我们的问题域不匹配C 模型是面向长文本生成的 而我们的场景是短文本分类。→ 未采纳这样做的好处是当你回头看实验记录时能清晰区分哪些决策来自你的判断哪些决策是「LLM 建议 你草率接受」。长期来看这会让你对自己科研工作的自主性有更准确的认知。5.4 调用 LLM 时要求它“给出不确定度”现在的 LLM 产品默认输出都太“自信”了。这不是模型的 bug而是对齐方式和用户习惯叠加的结果。模型被训练得倾向于给出一个流畅、确定的答案。一个反直觉但很有效的做法是在 prompt 中显式要求 LLM 给出不确定度或者替代方案。例如请回答以下问题并在回答末尾给出 1. 你对这个结论的置信度高/中/低 2. 可能存在的反例或边界情况 3. 如果需要验证建议用什么方法这个做法的价值在于它把模型从“结论生成器”变成了“假设生成器”减少你把模型输出当成既定事实的概率。研究者在阅读模型输出时也会带着更强的批判性。5.5 在 Agent 工作流中加入“人工审批节点”如果你正在用 LLM Agent 做自动化科研任务比如自动跑实验、自动分析结果、自动生成报告那么请在 Agent 关键节点之间加入“人工审批”。不要把整个工作流全部变成无人值守的自动化流水线。常用的模式是human-in-the-loop模式Agent 执行到某些关键动作时停下来生成一个 pending 状态等待人类确认后再继续。在 LangChain、LangGraph、AutoGen 等框架中这通常通过工具调用的权限控制实现。例如在 LangGraph 中你可以在图graph中插入一个interrupt_before节点# 文件路径agent_with_approval.py # 说明在 Agent 执行最终生成科研报告和自动提交到日志之前加入人工审批 from langgraph.graph import StateGraph, END from typing import TypedDict, Literal class State(TypedDict): research_result: str report: str def run_experiment(state: State): # 模拟 Agent 执行实验代码返回结果 result experiment done, metric0.73 return {research_result: result} def draft_report(state: State): # 模拟 LLM 根据实验结果生成报告 report fDraft report based on {state[research_result]} return {report: report} def human_approval(state: State) - Literal[published, needs_revision]: # 这里会暂停 Agent询问人类是否批准报告 user_input input(请审阅报告草稿输入 approve 或 revise: ) return published if user_input.strip() approve else needs_revision def publish(state: State): print(报告已发布:, state[report]) return state def revise(state: State): print(报告打回修改请人工修改后重新进入流程) return state graph StateGraph(State) graph.add_node(experiment, run_experiment) graph.add_node(draft, draft_report) graph.add_node(approval, human_approval) graph.add_node(publish, publish) graph.add_node(revise, revise) graph.set_entry_point(experiment) graph.add_edge(experiment, draft) graph.add_edge(draft, approval) graph.add_conditional_edges( approval, lambda state: state, {publish: publish, needs_revision: revise} ) graph.add_edge(publish, END) graph.add_edge(revise, draft) app graph.compile()这个示例的精髓在于不要让 Agent 自动化掉“人在环上”的审查机制。实验结果可以被自动生成报告草稿可以被自动写作但“是否可以发表”这个判断必须由人来按下开关。5.6 关注 LLM 的精度问题技术细节影响科研数据质量在做科研场景的应用开发时还有一个很容易被忽视的工程细节LLM 推理时的数值精度问题。如果读者关注过 LLM 推理性能优化应该知道 FP16、BF16、FP32 这些浮点数精度的区别。在普通文本生成任务中这些精度差异对最终结果影响不大。但在科研数据分析场景中如果用 LLM 辅助计算、汇总数据、判断统计显著性精度问题就可能累积成错误结论。简单对比一下精度类型内存占用数值范围适用场景FP324 字节/参数大科学计算、对精度要求高的任务FP162 字节/参数较小容易出现数值溢出普通推理加速BF162 字节/参数与 FP32 相同深度学习训练和推理更稳定建议如果你在使用 LLM 处理科研数据且数据量不大优先使用 FP32 精度的推理如果必须用 FP16/BF16 加速至少对比几次关键计算的结果确认精度损失没有改变结论。6. 如果已经“做得多、做得差”了如何判断和纠偏关于如何判断当前自己的科研工作流是否已经进入了“多做差做”的状态这里列几个值得留意的问题。你可以把它当作一次自查。6.1 检查你的研究问题是否在收敛回看你近半年的研究课题是否出现明显的“同质化”趋势比如是否频繁出现“因为 LLM 建议这么做所以这么做”的情况是否多个课题使用的实验框架、基线方法甚至分析套路高度相似是否很难找到半年前那个“为什么做这个课题”的原始直觉如果答案大多是“是”说明你可能已经被 LLM 的“平均答案”带向了一个安全的、标准化的、但创新性不足的科研轨道。6.2 检查你对实验结果的熟悉程度一个真正深入研究的科学家应该能预判实验结果大致长什么样。不是精确到小数而是大概知道哪个方向可能成立、哪个方向会崩。如果你发现自己经常是“第一次看到实验结果”——因为数据分析的代码和可视化全部由 LLM 自动完成——那就是一个危险信号。对过程中间状态的熟悉度决定了你对最终结论的掌控力。6.3 检查你拒绝 LLM 输出的频率这是一个非常简单但很有效的指标如果你用 LLM 生成内容时几乎从来不拒绝它的输出或者总是用“改改措辞”的方式接受它的结果说明你很可能已经陷入“自动化偏见”automation bias。应对方法很直接给自己定一个硬性规则——每次 LLM 输出必须找出至少一个点需要修改否则就重新审视是不是自己审查得太草率了。这个规则听起来有些刻意但它能逼着你的大脑维持在“主动思考”的状态。7. 常见问题与排查思路在实际使用 LLM 辅助科研的过程中很多问题其实是可以提前预见和排查的。下表整理了几类高频问题。问题现象可能原因排查方式解决方案LLM 给出的参考文献不存在模型幻觉编造了看似真实的文献用 Crossref 或 arXiv API 核验建立引用自动核验工具强制要求模型提供 DOI实验代码能跑但结果异常数据处理步骤有逻辑错误但报错被掩盖检查数据预处理阶段的中间输出对每个数据处理步骤单独设置断言不直接跑完整流程不同 LLM 对同一数据给出不同结论模型训练数据和上下文敏感性不同固定使用同一种模型并记录模型版本科研项目中锁定模型版本和参数不做随机切换LLM 生成的实验结论与图表不一致模型只看到了摘要数据没有理解完整图表将图表摘要信息和原始统计结果同时提交给模型验证数字时让模型只能引用你提供的具体数值不允许自行扩展论文写完发现核心假设不成立假设生成阶段依赖了 LLM 的“平均建议”缺少独立思考回看假设提出时的讨论记录维护决策记录文档识别问题来自哪个环节Agent 自动化流程漏掉关键检查点Agent 图设计时没有插入人工审批节点检查 Agent 流程图中的控制节点在提交、发布、对外输出等关键动作前设置中断这些问题的共同特征是人把判断环节委托给了机器而机器不一定具备判断所需的上下文。遇到这些问题先不要急着换一个更强的模型而是先检查工作流中你是否保留了足够的“人之眼”。8. 最佳实践与工程建议LLM 时代科研工作的护城河与其恐惧“AI 替代科学家”不如认真思考一个问题在 LLM 能把执行类任务无限加速的时代科学家的核心竞争力是什么我认为答案是三个词品味、判断、责任。品味知道什么问题值得解决。这是模型无法从训练数据中学到的因为它依赖于对领域长期浸润、对现实世界观察的独特感知。判断即使让 LLM 生成假设也能评价哪些假设是真正有价值的并敢于放弃看起来很合理但实际无关紧要的方向。责任对论文的每个结论负责对实验的每个环节负责。模型可以辅助完成实验但“这个结论是否成立”的最终责任必须由人类科学家承担。从工程实践角度我给出以下几条具体可操作的建议。8.1 区分“自动化”和“增强”不要把 LLM 当成一个“全自动科研流水线”而是当成一个“放大器”。它的目标不是替代你的思考而是放大你的思考效率。换言之用 LLM 加速文献筛选但自己决定读哪几篇精读。用 LLM 生成代码框架但自己审查核心逻辑。用 LLM 起草论文初稿但自己重写创新贡献章节。用 LLM 辅助答复审稿人但自己确认每条回复都真实回应了审稿意见。8.2 建立个人和团队的“LLM 使用规范”团队协作时建议把 LLM 使用规范写进项目文档。至少明确以下几件事哪些任务可以使用 LLM 生成如代码辅助、文献初筛、文本润色。哪些任务禁止使用 LLM 直接生成如实验数据结果分析、统计显著性判断、最终结论表述。哪些任务必须人工复核如参考文献列表、数值结果、实验设置。使用 LLM 生成的内容是否需要标记建议在项目文档中标注“此部分由 LLM 辅助起草已由人工审核”。8.3 为“人和模型”的分工建立一个反馈回路这是一个工程思维的建议把科研工作流作为一个系统来对待为“人的判断”和“模型的输出”之间建立反馈回路。具体做法是定期回顾你之前拒绝或修改 LLM 输出最多的场景。这些场景通常就是你最有判断力的地方也是你最不应该外包判断的地方。反过来如果你某类任务几乎从不修改 LLM 输出说明这类任务已经可以完全自动化节约出来的时间应该重新投入那些需要深度思考的问题上。8.4 控制并行课题数量保持每篇论文的实际投入时间前面说的“做得多”其实不是问题真正的坑是“摊薄”。如果你用 LLM 加速之后时间预算不变但课题数量翻倍那么每个课题的实际投入深度必然下降。比较好的做法是把 LLM 节约出来的时间重新投入到深度思考、实验细节和论文论证上而不是投入到更多并行课题上。这也是建模研究给我们的最大启示LLM 替代的是各个工作环节的“机械时间”但如果被替代的时间没有被用于恢复“思考时间”那么总体质量就会下降。9. 总结与后续学习方向关于科学家使用 LLM 的研究预测这篇文章做了几件事解释了“做得多、做得少、做得差”作为一个系统性预测的内在机制指出了 LLM 真正改写的不是效率而是科研认知分工给出了落地工程化的方法从参考文献核验脚本、决策记录模板到 Agent 工作流中的人工审批节点再到精度问题和团队规范最后讨论了如何自查是否陷入了“多做差做”的状态。写到这里我并不是想让读者对 LLM 产生抗拒。恰恰相反我认为 LLM 是科研工具史上最有潜力的工具之一。但我始终觉得工具的意义不在于替代思考而在于把我们从重复劳动中解放出来让人类能去做那些真正需要人类的判断力和创造力的事情。下一篇可以继续深入的方向包括LLM Agent 在科研数据收集和实验管理中的实战部署如何用 RAG 把个人文献库变成真正可靠的科研知识库以及如何为自己的团队制定一份可落地的“AI 辅助科研规范化清单”。如果你对这些方向感兴趣建议先收藏本文并在下一次尝试用 LLM 生成实验报告或者论文初稿的时候回来看一眼第 5 节和第 7 节——那可能刚好是你需要停下判断的时刻。