有研究提过一个观点在科研圈里讨论度很高AI 可能让科学家做得更多但做得更差而不是更少但更好。我第一次看到这句话时第一反应是它和主流的“AI 提效论”正好相反所以值得认真拆一拆。用了一段 AI 编程、AI 写分析脚本、AI 帮做文献整理之后我越来越觉得这个判断没有想象中那么反直觉。AI 真正改变的不是“单位时间能做的事变多了”这么简单而是把“产出”的成本压得极低却没有同步压低“验证”的成本。结果是脚本多了、版本多了、草稿多了但每一样都被验证过、能拿出去交给别人的也许只增加了一小部分。科学家看起来更忙了真正往前推进的工作却未必更多。下面我想做三件事第一把这个观点到底在说什么拆明白第二用工程工作流的视角分析它为什么成立第三给出一些我自己在用的操作办法让 AI 帮我“少做、快验、交得出去”而不是“多做、错验、最后返工”。既适合科研人员参考也适合日常用 AI 写代码、写材料的开发者。这两类人看起来场景不同踩的坑几乎一模一样。1. 先拆清楚这句话里的“更多”“更差”“更少但更好”到底指什么这个观点要成立首先得把几个关键词落到具体可观察的现象上否则讨论很容易变成站队。1.1 “做得更多”指的是什么是很容易看到的“做得更多”最直接的体现是产出数量的变化。以前写一篇论文从文献阅读到实验设计再到初稿可能要按周算。现在用大模型辅助初稿、代码框架、图表描述、回复审稿意见的草稿都能在小时级别内生成。我见过不少团队用 AI 辅助之后同一段时间里能拿出来的版本数量翻了几倍。这个现象不只在科研里存在。在软件开发中AI 编程助手把样板代码、接口封装、单元测试、文档生成的成本压得很低一个人能够提交的代码量明显上升。在内容创作里AI 能快速生成选题大纲和多个草稿。这些都是“做得更多”的典型表现。它本身不是坏事但要看产出质量是否跟得上。1.2 “做得更差”为什么不容易被及时看见“做得更差”是很多 AI 辅助项目里最隐蔽的问题因为质量问题往往不会在产出那一刻暴露。AI 生成的文字、代码、数据分析结果天然呈现出一种“完整”感。代码能跑文档能读图能画出来统计结果看起来也正常。但“能跑”不等于“正确”“看起来正常”不等于“经得起复现”。代码可能只覆盖了常见路径没处理边界情况统计结果可能用错了检验方法或者对缺失值处理不当文献综述可能引用了不存在的文献或者把作者观点理解偏了。这些问题很少在生成当天被发现往往要等到别人复现、代码上线、论文送审之后才暴露。到那时候你付出的返工成本可能比从头自己做还要高。“做得更差”还有一层含义是团队层面的同质化。当大家都依赖同一个模型、同一套提示词模板去生成假设、代码和文本时研究方向和方案设计的多样性会下降。不是说一定会发生但风险是真实存在的尤其当一个团队把 AI 生成的结果当成“起点”而不是“待验证的原材料”时。1.3 “更少但更好”为什么听上去对做起来难“更少但更好”是很多批评者在对比里提出的理想状态少生产一些低质量结果把时间和精力集中到少数几个高质量问题上。这个方向我完全同意但它对个人和组织的要求非常高。它要求你有能力“不做什么”不做无意义的扩展不追热点式的重复产出不为了凑数量去跑一堆雷同实验。它要求你有勇气删掉不成熟的中间结果而不是因为“生成成本低”就全部保留。它要求考核机制不看产出数量而看可复现的结果和被验证的结论。现实里很多科研人员所在的评价体系仍然以论文数量、项目数量、代码贡献量作为重要指标。当考核的是数量时AI 自然会成为“多做”的加速器。这不是某个人偷懒而是激励结构的问题。所以“更少但更好”不是一句口号它需要一套相匹配的验收标准和工作流。后面几节我会把工作流展开说。2. 用工程视角拆科学家的工作流AI 改变了哪一段把科研流程想象成一条流水线可以粗略分成三段输入准备、方案产出、结果验证。2.1 三段流水线输入、产出、验证输入准备包括读文献、整理数据集、梳理背景、明确问题。方案产出包括写假设、设计实验、写代码、跑模型、生成图表、撰写论文。结果验证包括检查数据是否干净、复现结果、检查统计假设、做边界测试、同行评审、代码审查。AI 在每一段都能帮忙但帮忙的深度完全不同。在输入准备阶段AI 可以做文献速读、提炼摘要、整理术语表。这个阶段花的是“理解”时间AI 的产出是辅助信息你有能力判断它对不对。在方案产出阶段AI 尤其擅长生成初稿、代码框架、实验脚本和表格。这里的问题在于AI 生成的是“看起来可行”的东西而不是“已验证可行”的东西。在结果验证阶段AI 也能帮忙写检查脚本、做一致性测试、生成模拟数据。但关键的判断比如“这个统计模型适不适合这组数据”“这个效应量有没有实际意义”“这个结论能不能泛化到其他场景”仍然需要人来负责。2.2 最容易失守的环节验证为什么“做得更多但更差”会成立核心原因在于AI 把“产出”的边际成本几乎降到了零却没有降低“验证”的边际成本。以前你花三天写一个脚本你会很自然地反复检查边界条件、异常输入、数据类型错误因为你不想把三天的工作量浪费在一个低级 bug 上。现在 AI 两分钟生成一个脚本你反而容易陷入一种心理节奏它看起来专业测试也通过了可能没问题吧。问题就在这里。测试通过不等于验证充分尤其当测试用例是 AI 配套生成的时候。AI 生成的测试和 AI 生成的代码往往共享同一个“思维惯性”它们会掉进同一个坑。我们在软件开发里常说的“测试也有幻觉”在科研场景里同样存在。我一般在验证阶段会盯三件事数据是否干净、方法是否适用、结论是否可复现。第一件看数据缺失值、异常值、单位、时间范围第二件看统计假设、模型限制、样本量第三件看随机种子、版本号、运行日志、计算环境是否记录清楚。这三件事AI 可以辅助但不能代替人做最终确认。这也是为什么把多个 AI Agent 串成全自动流程时要格外谨慎产出越多需要验证的点越多自动链路里只要有一个环节是幻觉后面所有结果都会被污染。2.3 为什么“看起来完成度高”的 AI 输出会骗人大语言模型本质上是最大化“文本合理性”的生成器它不是在执行“找到正确答案”的程序。它会生成一段逻辑通顺、结构完整、引用规范的文字但内容可能包含不存在的文献、错误的推导、过时的标准。这就是我们常说的“AI 幻觉”。在科研工作流里幻觉的可怕之处在于它被包装得很好。你很难在读第一遍的时候发现问题因为所有句子都是合理的结构是标准的。但当你拿原始数据去核对或者按它引用的文献去找原文时就会发现对不上。我在用 AI 辅助写分析报告时有一条习惯凡是 AI 给出的具体数字、文献、标准、版本号都必须回溯到原始来源。AI 可以帮我提出“需要查什么”但不能充当“我已经查过了”。这个习惯适用于写论文也适用于写代码。AI 告诉我某个 API 的用法我会去官方文档确认AI 告诉我某个库已弃用我会去 changelog 里找记录。3. 省下的时间不会消失它只是换了一个地方花很多人对 AI 提效有一个朴素期待原来要三天的任务用 AI 后可能一天就完成剩下两天可以做更重要的事。但实际操作下来很多人发现省下来的时间并没有变成“思考时间”而是变成了“盯 AI 的时间”。3.1 省下的时间被什么吃掉了被吃掉的时间主要有四个去向。第一审查 AI 输出。生成一段文字很快但你要逐句核对它是否准确、有没有遗漏、观点是否适合你的上下文。这个核对过程并不比从零开始轻松尤其当 AI 输出很长时。第二调试 AI 生成的内容。AI 生成的代码如果出现 bug你面对的不是自己写逻辑时能回忆起来的代码而是一段“别人的思路”。你需要先在脑子里重建它的逻辑再修改再把新逻辑加进去。这个过程经常比从零写还慢。第三处理 AI 带来的额外产物。AI 生成多个版本之后你需要合并、筛选、删减。版本管理做得不好时光是搞清楚“哪一版是最终版”就能耗掉不少时间。第四为 AI 的错误善后。数据跑错了要重跑文章引文错了要改代码上线出问题要紧急修复。善后成本往往是最高的因为它发生在你信任了 AI 输出之后。3.2 判断质量的三个指标可复现、可解释、可维护如果你想避免“多做但差做”我给 AI 结果设了三道质量门槛。不是“它能跑”“它能读”而是三个更硬的指标。第一可复现。把输入、参数、环境、随机种子、版本全部记录换一台机器跑出来的结果应该一致。不可复现的结果不管看起来多漂亮都不能作为最终依据。第二可解释。AI 的每一步分析、每一段代码、每一个模型选择都要能说清楚“为什么这么做”。如果解释不清这个结果就有隐藏风险。第三可维护。如果是代码要能继续改如果是论文要能继续迭代如果是图表要能更新数据重新生成。AI 生成的一次性结果如果接不住后续修改价值就大打折扣。3.3 我常用的守门标准单次、重复、换输入具体操作上我一般会用三个动作给 AI 输出“上强度”。第一个动作跑单条任务。先拿一条最小样例跑通确认输入输出格式都对日志正常。这一步能筛掉大部分流程问题。第二个动作连续跑多次。让 AI 对同一个任务生成五到十次看结果是否稳定。同一段提示词不同时间生成的代码可能完全不同。如果几次结果差异很大说明它的输出方差比较高这时候不能直接用于批量场景。第三个动作换输入再试。把样例换成更复杂、更极端、包含边界条件的数据看输出是否仍然合理。如果只是在常见输入上表现好一到异常情况就报错或给出误导性结论那这个 AI 工作流还需要加固。这三步做完才轮到“批量跑”和“交付”。很多问题不是 AI 能力不够而是我们没有给它设置质量门槛直接拿第一次生成的结果去交付了。4. 让 AI 帮我“少做快验”而不是“多做错验”的实操方式下面这部分是我最想分享的。原则只有一条先定验收标准再让 AI 动手。顺序不能反。4.1 先写验收标准再打开 AI 工具在科研或开发中让 AI 帮我们生成任何内容之前先明确“什么样的结果算合格”。比如写数据分析脚本你要先说清楚输入数据有哪些字段缺失值怎么处理输出要包含哪些统计量结果文件是什么格式每次跑是否记录种子。有了这些约束AI 生成的代码才有方向你验收时才有一个明确清单。比如写文献综述你要先说清楚要覆盖哪些年份、哪些主题、哪些来源每条观点是否需要附原始出处引用格式是什么。AI 在这个框架下生成的综述你验证时才有据可查。这实际上是把“验收标准”从人脑搬到了文档里。AI 不是面对一个模糊任务而是面对一个明确的任务说明。这个过程本身也是你理清思路的过程。很多“AI 输出乱”的问题根源在于任务描述太模糊。4.2 单条、小批、批量三步节奏不要跳我见过不少团队第一天用 AI 跑通一个样例第二天就开几十个并发任务第三天发现一半结果需要返工。这个顺序应该反过来。第一步单条任务。用最典型的输入跑通流程确认 AI 输出的格式和质量。第二步小批任务。跑 5 到 10 条覆盖不同情况包括边界和异常。观察失败率、输出差异、运行时间。这时候是调整提示词和参数的最佳时机。第三步批量任务。在小批验证稳定后再扩大到完整数据集。同时要有输出目录规划、失败重试、日志记录、命名规则。不要一上来就开最大并行。AI 服务的限流、token 消耗、结果不一致都会在批量阶段被放大。先把小批跑稳批量才有意义。做科研和做工程在这件事上逻辑完全一致。注意不要一上来就开最大并行。AI 服务的限流、token 消耗、结果不一致都会在批量阶段被放大。先把小批跑稳批量才有意义。4.3 强制检查点哪些环节绝不能完全交给 AI基于我自己的经验有几个环节即使 AI 看起来能做也应该保留人工确认或至少做独立交叉验证。第一个涉及最终结论的统计分析。统计方法选择、显著性判断、效应量解释、敏感性分析这些直接决定论文的核心结论不能由 AI 自动完成。AI 可以帮忙生成分析代码但应该由熟悉统计方法的人审查代码和结果。第二个涉及安全、合规、伦理的判断。研究是否涉及合规要求数据使用是否符合约定结论是否会误导政策或临床决策这些责任在人不在模型。AI 的建议只能作为参考不能作为依据。第三个涉及对外交付的最终版本。论文投稿版本、开源代码发布版本、项目中使用的最终模型这些“出口”必须有人负责。你可以让 AI 产出候选版本但最后的发布动作和确认应该由明确的责任人来做。给 AI 交付的“出口”版本必须有人工确认。这是不可省略的一步尤其在涉及对外发布、决策支持或安全场景时。4.4 把 AI 参与的过程记录下来形成可回溯链路想让“更多但不更差”的目标成立最重要的一件事是把 AI 参与的过程记录清楚。不要只留最终结果。我会使用版本控制工具管理 AI 生成的代码和文本。每次保存记录都写清楚提示词是什么、有哪些关键参数、生成了什么、我修改了什么、为什么修改。这样做有三个好处。第一出了问题能回溯。一个看似正确的结论如果之后发现数据输入错了或者提示词有歧义你能看到问题出在哪一层。第二方便复现。别人看到你的结果时能知道这是怎么来的。如果只是把 AI 输出原样贴进论文而不留过程别人无法判断哪些是验证过的。第三减少重复劳动。你改了三版的新结果和初始版本如果没有记录过两天会忘。有了版本记录你可以对比差异找到最合理的中间状态。我一般在项目根目录放一个说明文件记录 AI 辅助生成的模块、使用的模型和版本、生成时间、人工审查状态。这不是额外负担而是科研诚信和数据管理的基本要求。5. 哪些场景适合“多做”哪些场景必须“更少但更好”“做得更多”不等于坏“更少但更好”也不一定处处适用。关键在于判断场景和风险。5.1 适合用量换质的环节有些场景多生成确实有好处。用于理解背景时AI 批量生成文献摘要、术语解释、方法论对比能加快你对一个陌生领域的入门速度。这些内容只供自己消化不对外发布错了也有纠错余地。用于头脑风暴时AI 生成多个实验方案、多个选题方向、多套代码设计思路。你不需要每个都验证只需要从中挑选值得深挖的方向。这种“多”是低成本的发散对最终质量有帮助。用于格式化工作时比如把参考文献转成统一格式、写通讯稿、生成会议纪要、做图表配色AI 多生成几个候选方便你挑选。这些任务本质上是低风险、高重复、质量边界清晰。5.2 必须“更少但更好”的环节反过来有些场景必须严格控制产出数量优先保证每个产出都经得起检验。比如要向核心期刊投稿的论文。数量不重要数据和结论的可靠性才重要。你宁可一年打磨一篇可复现、逻辑扎实的论文也不要一年投出十篇被审稿人一眼看穿问题的论文。比如要做临床、工程、政策决策支持的输出。这些结果会直接影响人的健康、安全或重要资源。在这里AI 的建议只能作为参考材料必须有人工复核和风险控制。出错的成本太高所以“多产”在这里没有意义。再比如要发布成开源软件工具包、API 服务、模型权重。任何外部用户都可能依赖它。这时候代码质量、文档准确性、边界处理、向后兼容性比“功能数量”重要得多。少做一个模块没关系做的每一个模块都必须稳定。5.3 一张可复用的判断清单如果拿不准某个任务应该让 AI“多做”还是“少做”我会用下面五个问题过滤。这个输出会被谁使用只有我自己还是会被同事、审稿人、用户、决策者使用如果结果错了最坏后果是什么需要返工还是会影响安全、决策、声誉别人会不会复现我的工作会的话过程记录和版本管理是否完整这个任务的价值是在于数量还是在于深度是发散找方向还是收敛出结论我有没有足够的验证能力覆盖它的风险如果没有就应该减速、减量、加强验证。前三个问题决定风险级别后两个问题决定资源分配。风险越高越要压数量、保质量风险越低越可以放开让 AI 多做几版再人工挑最优。6. 我最后想说的话把 AI 当“会说话的实习生”而不是当专家我在很多场合说过一个看法把 AI 当专家是“多做但更差”的根源把 AI 当“会说话的实习生”才是比较稳妥的思路。6.1 为什么“实习生”比喻能避免判断错位一个实习生产出通常非常积极但经验不足。你会给他明确的验收标准会告诉他“这个结论需要原始数据支撑”会在他把结果交给你之前仔细核对。你不会直接把他的初稿投出去也不会因为他的代码能跑就直接上线。AI 大模型和实习生很像表达能力极强知识面很宽但容易自信地犯低级错误对上下文的理解不完整对风险没有感知。如果你把它当成专家你会减少核对、增加信任结果就是质量滑坡。如果你把它当成实习生你会保持检查习惯反而能让它的产出真正为你所用。这个比喻不是贬低 AI而是提醒我们正确分配责任。AI 负责把“可能的方向”快速生成出来人负责通过验证把“可能的”变成“可靠的”。责任在人工具在 AI。6.2 具体落地姿势怎么和这个“实习生”协作我自己的协作方式可以总结成四句话。第一先给任务边界。不要让 AI 自由发挥给出输入、输出、约束和验收标准。第二要求它给依据。凡是具体数字、文献、API 用法、模型参数都要求它说明来源然后人工回溯确认。第三抽查它的薄弱环节。不同输入多跑几次换数据、换边界条件观察输出是否稳定。第四保留自己的判断权。AI 说“可以的”“建议的”不等于就是对的。最终的判断、责任、发布动作永远由人来完成。如果项目比较重要我会在流程上再加一层让 AI 生成方案 A再让另一个不同的 AI 生成方案 B或者请同事对结果做独立复核。交叉验证能明显降低单一模型幻觉带来的风险。记住一句话AI 给出的是“可能的方案”不是“正确的结论”。中间的差距由验证来填。6.3 问题不在 AI 的“多”而在我们的“验”回到最初那个观点AI 可能让科学家做得更多但做得更差而不是更少但更好。我同意前半句描述的现象但我不认为这是一个必然结局。它更像是一个默认倾向取决于我们怎么设计工作流。如果我们的流程只有“生成”没有“验证”那 AI 一定会把我们推向更多、更差。如果我们的流程里生成之后还有强制检查、独立复核、过程记录、边界扩展那 AI 就能帮我们承担低风险高重复的部分让我们真正把精力放在难点判断上。我没法保证每个人都能做到“更少但更好”但至少可以做到一件事让 AI 的每一项产出在被当作成果之前都过一遍我们自己设定的验收关。这件事没有多复杂但需要刻意维持。踩过几次“多做差做”的坑以后我发现真正的瓶颈从来不在工具而在流程是否守得住。