001 期AI 遇见科研 · 论文深读PLoS Comput. Biol.

科研中使用AI辅助编程的十二条实用建议

设想你让AI按组统计，代码跑完了，空白值却被当成0；请它优化程序，原本正确的处理又被改掉。怎样让AI真正帮上科研的忙？这篇指南把任务说明、分步实现和结果检查放进同一套协作过程。

代码跑完了，为什么还不敢用结果？

假设你手里有一张实验记录表，想按组算均值，再画一张图。你把表交给AI，写下：“帮我整理一下，算出各组的平均值。”代码有了，结果表也出来了。你顺手抽查一组：三个测量值是2、4、6，另有一个空白。自己算出的均值是4，表里却写着3。

问题藏在空白里。你把它理解成“这次没有测到”，AI写的程序却先把它补成了0，随后计算四个数的平均值。程序没有报错，计算也严格遵照代码执行，只是代码里的处理方式偏离了你的意思。这个便于手算的小例子是本文构造的情境；换成成百上千行真实数据，类似偏差就未必这么容易被看见。

用AI写科研代码时，很多精力其实花在这里：把自己的意思交代清楚，看懂它做了什么，再确认结果能不能用于研究。少写了几行代码，未必就少走了弯路。要让这次协作真正省力，得有办法把这些容易被略过的决定留住。

Bridgeford等人在PLOS Computational Biology发表的《科研中使用AI辅助编程的十二条实用建议》，讨论的正是这件事。它来自研究团队的使用经验和相关文献，尤其面向那些还会再用、还要交给同伴的科研程序：先把问题和判断标准准备好，让AI完成一小步，检查这一小步，再带着确认过的结果继续。十二条建议围绕这个过程展开。

你不必先成为软件工程师，才能从中受益。读完以后，更实际的收获是知道怎样提一个能落实的请求、怎样看出“测试通过”有没有分量，以及怎样在AI越改越乱时把工作收回来。论文也提醒，AI带来的效率变化取决于使用者、任务和代码库，已有研究并没有给出整齐一致的答案。

准备与理解：先让AI明白你在做什么

01 动手之前，先认清自己的数据

回到那张实验表。要避免均值从4变成3，第一步不需要更复杂的提示词，而是先想清楚：空白为什么出现？一行是一份独立样品，还是同一样品的又一次测量？这一列的单位有没有中途换过？这些信息常常没有写在数字旁边，却决定后面该怎样算。

论文的第一条建议，是在实现前补足与任务有关的背景。你可以先让AI解释现成软件怎样处理某类数据，帮你寻找领域里常用的分析方法，再打开它给出的文献和文档核对。这样做的目的很具体：等代码交回来，你至少知道哪些处理必须出现、哪些结果需要追问。遇到没把握的方法，就在写代码之前把这个疑问解决掉。

02 把“帮我分析”说得再具体一点

“帮我分析数据”听起来很自然，但其中藏着一串尚未作出的决定。是按样品还是按测量次数统计？缺失值忽略、补齐，还是另行分析？要的是每组均值，还是还要估计差异？如果这些选择没有说明，助手仍可能写出一段完整程序，只不过其中一些处理办法，是助手替你选的。

同样一件事，可以改成：“表中每行是一份独立样品，按group分组。value为空时记作缺失，不补0；输出每组的有效数、缺失数、均值和样本标准差。先解释你准备怎样处理数据，等我确认后再写代码。”这时，你已经把研究对象、处理规则和需要交回的东西说清了。AI接到的任务，也从“猜我想做什么”变成了可以逐项核对的实现要求。

这对应第二条建议中的重要区分：怎样把研究问题变成可计算的问题，与怎样把它写成程序，是两件相关但不同的工作。选择分析对象和方法，需要你的领域判断；AI可以协助讨论，也能承担大量实现工作。逐渐掌握一门语言的基础、读懂与课题有关的代码，会让你更有能力参与这些决定。

03 选工具时，想想自己希望怎样参与

任务清楚以后，再选合作方式就容易一些。只想把分析思路讨论明白，聊天界面便于来回解释；拿到一段代码后，通常还要由你保存、运行，再把报错带回来。若已经在编辑器里维护项目，内置助手能对照现有文件补全和修改。能调用工具的编程智能体还可以读取多个文件、运行命令、查看输出，把这些动作连续做下去。

表1把这些差别放在一起。集成开发环境（Integrated Development Environment，IDE）就是把写代码、运行和调试放在同一个界面的软件；表中最后一类进一步把智能体能力整合进去。读这张表时，可以想象自己下一次要做的动作：是讨论一个方法，修改已有程序的一小部分，还是让助手完成跨文件的任务？选择能让你看懂并检查这个过程的工具，比先追求自动化程度更实用。

源自论文 Table 1｜表1｜按交互方式比较AI编程工具

这些类别会交叠，产品能力也在变化。论文因此建议，先学会所选工具的用法，再拿自己熟悉的一小项任务试用。你知道输入、知道大致答案，才容易看出它在哪些环节帮了忙，哪些地方仍需要你介入。

上下文与交互：让每一步都接得上

04 一个大任务，分几次交出去

如果一开始就请AI“清理数据、统计、检验、绘图，再生成完整报告”，出错时很难知道该从哪里找起。那张小表可以先只做一件事：读入文件，确认列名、单位和缺失记录。检查无误后，再实现分组汇总；最后才处理图形。每一步都有可以打开看、可以独立核对的结果。

这就是第四条建议中的分阶段计划。动手前，先想清数据怎样从一部分传到另一部分，各自接收什么、交回什么。完成一小步便保存一个正常版本，后面改坏时就有路可退。Git这类版本管理工具能够记录每次改动；刚开始用AI协作时，也应先学会保留一个确定可用的状态。

05 给下一次对话留一份项目说明

工作分成几次做，一个新问题就出现了：你明明讲过“空白不能补零”，下一次打开对话，助手却又要重新确认。即使没有换对话，聊得很长以后，早先的细节也可能被遗漏。这里说的“上下文”，就是AI当前能看到、据此完成任务的材料，包括你的要求、代码、数据说明和之前作出的决定。

重要的决定值得从聊天里拿出来，放进项目文件。一份简短说明就可以写成：“每行是一份独立样品；原始表只读；空白不补零；已完成表头和单位检查；下一步只实现分组汇总。”新会话开始时，让助手先读这份文件，你也能快速想起工作停在哪里。它保存的是下一步用得上的信息，不必把全部聊天记录堆进去。

补充材料S2进一步区分了两种用途：有的文件记录项目结构、当前进度和已经学到的教训；有的文件写下长期遵守的规则，例如不改原始数据、不擅自更换统计方法。随着项目推进，前一类内容要及时更新，后一类规则也要明确而一致。每阶段把相关资料准备齐，助手才能在已有决定上继续工作。

测试与验证：怎样知道它真的算对了

06 绿色对勾，要看它究竟检查了什么

程序交回来以后，助手告诉你：“测试全部通过。”这当然是个好消息，但还需要看一眼它检查了什么。完成一个具体步骤的一段程序，叫作函数。测试会给它输入、运行它，再把输出与事先确定的答案比较。若只检查文件有没有生成，里面的均值即使错了，也可能照样通过。

论文特别提醒一种“纸面测试”：检查的外观很完整，却没有触及真正需要验证的功能。模型可能用占位的假实现替代实际计算，也可能在出错后改掉测试中的预期答案，让现有代码得到通过。读这种测试时，沿着三个东西看下去就有帮助：喂进去的是什么数据，实际运行了哪一个函数，输出凭什么应当等于这个答案。

对于前面的小表，均值4是你先用2、4、6算出的判断依据。测试应该把含一个空白的输入交给待检查的汇总函数，再检查它返回4。如果函数错误地算出3，测试又调用它取得“预期答案”，两边都是3，检查仍会通过。

07 先把“算对”的样子摆出来

作者在补充材料S3给了一个更能说明问题的教学例子。研究者比较不同脑区的活动，把每一对脑区的关联程度填进一张方表。正值表示活动变化倾向同向，负值表示倾向反向；数字离0越远，关联越强。于是，−0.7虽然比0.5小，代表的关联却比−0.2更强。

任务要求用0.5筛选关联，保留较强的正、负关联。如果只请AI“按阈值筛选脑区关联”，没有交代强弱要看绝对值，它就可能直接比较数值大小：0.3被清零，−0.7也被清零。若测试里只有正数，这段程序看起来就能正确工作。问题是在交任务时，“小”到底指数字小，还是离0近，没有说清。

把标准先写出来，歧义就容易暴露：阈值为0.5时，0.3应清零，−0.7应保留，−0.2应清零；比较的是绝对值，也就是数字离0有多远，还要保留数值原来的正负号。在这个阈值函数中，表格的对角线表示脑区与自身的关联，需要保持不变；表格把同一对脑区记了两遍：A与B的关联，也就是B与A的关联，对应的两个位置应相等。

这些小例子给了AI明确的实现目标，也给了研究者独立的验收依据。后来发现新的错误，就把能重现它的输入留下，加入测试。下次再修改代码，这个例子会帮你检查老问题有没有回来。第七条建议讲的“用测试规定行为”，落实下来就是这样的动作。

08 再拿几份难处理的数据试一试

正常样例通过以后，可以让AI帮你想一想：什么输入最容易让这个函数出问题？对小表来说，可能是空文件、少了一列、同一样品编号重复出现，某组只有一个有效值，或极端数值让计算不稳定。对脑区关联表来说，还要检查形状是否正确、对应位置是否对称，以及不合要求的输入会怎样报错。

这些情况不用一次全部猜中。把现有函数和测试交给AI，请它指出遗漏、解释哪些与当前任务有关，你再决定应有的行为，让它补上检查。项目以后要由多人持续维护时，还可以请它协助设置自动运行的测试流程。每次合入修改便检查一次，日常使用中少一些靠记忆补救的环节。

代码质量：把越来越多的代码掌握在手里

09 越改越乱时，先把问题收回来

另一个作者教学情境很熟悉：一次报错带来一次修补，补完又出现新问题，对话里逐渐塞满失败方案。补充材料S3用神经影像处理举例：这类数据像按时间连续保存的立体脑影像：每一帧有三个空间方向，整组还多了时间这一维。如果只笼统地说“影像数据”，程序可能按三维来写。输出还要接入已有分析流程，而这个要求讲得太晚，前面的代码又得返工。

这种时候，重开一个对话之前，值得先问：“刚才哪些信息没有交代清楚？”把输入维度、已有程序需要的输出格式、缺失数据规则写进项目说明，再从正常版本开始这一小步。新对话接到的已经是改进过的任务，前一次失败才变成了有用的经验。若助手开始修改无关文件、遗漏你的要求，发现时便停下来核对，也比任它继续扩展更容易收拾。

10 把代码放回科研问题里审一遍

测试覆盖得再多，也得回答一个更贴近课题的问题：这个程序做的分析，是否就是你原本要做的分析？例如，小表的均值可以算得分毫不差，但如果三行其实来自同一样品的三次测量，把它们当成三份独立样品继续做组间比较，方法仍可能有问题。测试不知道这些行来自哪里，研究者需要把数据与研究设计的关系补上。

第十条建议因此强调独立审查：读懂实际实现，把它与最初的计划、领域惯例逐项对照。特别是数据筛选、单位换算和统计方法，最好还能交给熟悉课题的同伴看一遍。AI可以帮忙找代码问题，同伴则可能从研究问题出发，看见一个“写得没错、选得不合适”的分析决定。

11 “优化一下”，为什么容易改掉原来的意思

程序能够正常工作以后，很容易顺手再请AI“优化一下，写得简洁些”。S3的另一个例子恰好展示了这种风险：一段用于计算脑区关联的程序，原来会在计算一对脑区的关联时，使用两边都有观测值的记录。AI整理代码时，换成了更简洁的常规计算函数。干净数据上看不出差别，遇到缺失值，相关结果却可能也变成缺失值。

“更简洁”与“计算行为不变”并不天然是同一个目标。如果这次只是想把相关计算抽成一个独立函数，就把这个目标说清，并约定保留原有步骤、算法和输入输出。先检查这一次提取有没有改变结果，再讨论下一项改进。若真正想提升速度，也先定好比较办法，在相同输入下核对结果和耗时。

12 让半年后的自己，也能接着用

到这里，程序已经能完成任务。把它发给同伴，对方很可能还会问：“哪个文件是入口？需要装什么？这几个参数该填多少？跑完应该看到什么？”这些问题今天对你很清楚，隔一段时间未必还记得。把它们写下来，代码才更容易从一次性的成果变成能继续使用的工具。

论文给出的收尾材料包括：记录使用的AI工具、版本、协作方式和项目说明文件；说明函数的输入、输出及重要方法选择；保存记录软件包及版本的环境文件；写一份介绍用途、安装与运行方法的README；提供至少一个能运行、有预期输出的例子。AI很适合协助起草这些说明，再由你按说明走一遍，检查交出去的材料能否把程序真正运行起来。

十二条建议，怎样连成一次完整协作

图1把前面的细节串成了三段。A是动手前的准备：认识问题、定义任务、选择工具、拆分计划。B是每一个阶段都要经历的循环：准备相关材料，规定并检查测试，观察执行，审查结果。需要修正时，就带着新发现补充材料，再走一遍。C是在工作稳定以后，做有目标的整理，并留下复用所需的说明。

源自论文 Fig. 1｜图1｜准备、分阶段开发和收尾组成的AI辅助编程流程

这张图里很有用的是B中的回箭头。审查后回去改说明，并不表示前面的工作白做了；它把新发现放回了下一次执行的起点。作者也坦率地说，即使遵循这些建议，从头到尾都顺利的交互仍不常见。这套流程让你在卡住时知道该查需求、上下文、测试，还是实现本身。

科研代码最后连着研究结论。与论文合作者讨论方法一样，你需要能够解释为什么这样分析、结果成立需要什么条件。使用能执行操作的智能体时，还应说清可访问的项目范围、哪些动作要先确认，并保存可恢复的版本。涉及患者信息、未公开成果或受限制的材料，按机构规则确认可以使用的工具与处理方式。原文也讨论了资源消耗和知识产权等更广泛的问题。

保存项目时，有一件事尤其容易漏掉：提示词记录与最终代码都要留。模型会更新，同样的提示也可能生成不同程序。把最终确认过的代码、环境、测试和示例一起归档，同伴拿到的才是这次结果实际依赖的那一份。想进一步补基础，原文还推荐了可复现计算、软件设计和测试驱动开发等读物。

回到那张小表，做出一个能交给同伴的项目

如果想照着试一次，可以继续用开头那张表，把一次小协作完整走完。下面采用VS Code中的GitHub Copilot作为操作例子，功能依据是2026年11月3日核对的官方文档；这是本文整理的尝试路径，尚未在该界面实测。电脑需要有可用的Python环境，以及已经登录Copilot的VS Code。

先放入一份自己能核对答案的数据

新建一个项目文件夹，用VS Code打开。里面放一份CSV文件，也就是表格软件能打开的纯文本数据表，列名为sample_id、group、value、unit。给A组四个不同样品编号，数值依次填2、4、6、空白，单位都写mg/L。这个练习先约定每行是一份独立样品，空白代表缺失。

你已经知道这组数据的均值应为4。若还要样本标准差，答案是2：三个数分别离均值−2、0、2，平方后相加为8，除以有效数减1，也就是2，再开平方得到2。它反映这些样品测量值的离散程度。先留下这两个答案，后面就有东西可与程序输出对照。

把已经决定的事放进项目说明

在项目根目录建立.github文件夹，里面新建copilot-instructions.md。官方文档支持用这个文件向Copilot提供项目指令。可以先写：“原始CSV只读；按group汇总；空白不补零，同时报告有效数和缺失数；编号重复或单位不一致时停下并说明；有效数不足2时，样本标准差留空；先给计划和验收样例，确认后再实现。”

打开侧边聊天，选用Copilot会话，输入 /plan，接着说：“读取项目说明与CSV，先列出输入检查、分组计算、输出文件三个步骤，说明各自怎么验收，暂不修改文件。”你期待看到的是一份能检查的计划：它有没有按有效值计算、有没有单独报告缺失、有没有把生成物与原始文件分开。漏了哪一条，就在计划阶段补上。

每完成一步，都打开结果看一眼

计划确认后，先请它把验收样例和预期答案写出来，再分步实现。A组的预期结果是：有效数3｜缺失数1｜均值4｜样本标准差2。再单独准备几份坏输入：重复一个样品编号、混入不同单位、只留一个有效数。检查程序是否按事先约定报错或留空。

让助手运行测试，把实际命令与输出展示出来；你再打开汇总文件核对数字，并在编辑器的修改视图里查看它改了哪些内容。若测试失败，保留失败的输入，让它修正程序后重跑。最后请它补上运行命令、环境和README，再把这个小项目交给同伴，看看对方能否照着得到同样的汇总。

换成自己的课题时，样品是否独立、缺失该怎样处理、统计量是否合适，都要重新按研究设计确认。但此时你已经带走了一套可以使用的办法：把任务讲具体，先确定几个自己能判断的答案，再让AI逐步实现和检查。下一次面对那句“帮我分析数据”，你会更清楚该补上哪些信息，也更知道该怎样判断交回来的程序。

本文为第三方学术解读，包含AI辅助整理。作者图表与演示材料保留来源；文中事实与数据请以原文为准。编辑解释不代表作者、所属机构或期刊立场。