夜雨聆风
摘要
专业科研软件的开发历来成本高昂、耗时漫长，但大语言模型(LLMs)在代码生成方面已足够成熟，能够从根本改变这一局面。我们阐述了 LLM 辅助编程如何颠覆这一格局——它使研究者无需软件工程师的支持即可构建工具；我们以一名 LLM 辅助开发者迅速构建的实例加以说明，并讨论了其中的机遇与风险。
图1：科研软件开发的转型
图2：MOSS：面向显微图像的监督式分割(Microscopy Oriented Segmentation with Supervision)
引言
软件如今在生物医学研究的几乎每个阶段都不可或缺，然而构建与维护软件所需的工作量却常被严重低估。研究软件工程师在学术界依然稀缺；尽管诸如陈·扎克伯格倡议(Chan Zuckerberg Initiative)的 Essential Open-Source Software for Science(科学必备开源软件)计划已为关键科研软件提供了专门的资助，生物医学实验室仍常常受困于熟练人员的匮乏。传统上，只有少数技术精湛的个人或资金充裕的团队，才能将一个软件构想从萌芽推进到产品阶段——即能够被学界使用的形态，这导致科研软件领域构想众多、可用程序却寥寥无几(图1a)。
生物图像分析领域很好地体现了这一问题。最广为使用的工具——例如 ImageJ/Fiji、ilastik、napari、Amira(赛默飞世尔科技，Thermo Fisher Scientific)和 Dragonfly——都需要专门的学术或商业团队经年累月的持续开发。它们在各自的设计范围内表现良好，但显微模态、文件格式、数据类型与分析需求的多样性，意味着许多研究者面临的是没有合适工具可用的工作流。传统上，构建定制解决方案要么需要深厚的软件工程专业知识，要么需要与计算机科学团队展开长期合作，而后者往往对科学问题本身并不那么上心。尽管一些资金充裕的机构得以建立高效且专注的生物信息学核心设施，但这仍是例外而非常态。
理论上可行的软件解决方案与单个研究者实际可触及的方案之间的鸿沟正在扩大。这一点在突触分辨率连接组学领域可见一斑：一些实验室仍在使用人工神经元追踪，而另一些实验室则受益于几乎全自动的分析流程。BioImage Model Zoo 这类社区仓库、Microscopy SAM 这类基础模型，以及 napari 和 BiaPy 这类框架，已使这些方法更易获取，但它们往往仍难以处理大量边缘情况，需要可观的资源与专业知识。
过去几年间，LLM 已成为出色的代码生成器；2023 年发布的 GPT-4 标志着语言模型在编写、调试与重构代码能力上的大幅跃升。Cursor(Anysphere)这类开发环境将这些模型直接嵌入编程环境，消除了早期 LLM 使用者所经历的繁琐复制粘贴。随着近期的进一步改进，并赋予 LLM 在智能体(agentic)框架下自行执行代码(工具)的能力，诸如 Anthropic 的 Claude Opus 等模型已能在 SWE-bench Verified 基准上解决约四分之三的真实 GitHub 问题。这要求模型能够阅读多文件代码库、编写补丁并通过测试套件。
一些初步实验已开始量化这一生产力效应。例如，一项在微软(Microsoft)和埃森哲(Accenture)约 2,000 名开发者中开展的实地实验发现，使用 GitHub Copilot 使每周完成的拉取请求增加了 13%–22%。尽管对于维护既有代码库的专业开发者而言，这似乎只是温和的收益，但我们发现，智能体式编程的引入赋予了构建新工具的领域科学家以巨大能力，实质性地消除了入门壁垒(图1b)。对于几乎或完全没有编程经验的科学家来说，大量涉及文档查阅、用户界面样板代码编写、简单不兼容性与语法特性的调试工作，如今都可得以自动化。这或将催生大量定制化工具，并从根本改变科研软件格局(图1c)。
这并不意味着科研软件开发已变得轻而易举，因为 LLM 辅助编程或许只是将瓶颈从实现转移到规范制定、构思与实验之上。Andrej Karpathy 创造了"氛围编程"(vibe coding)一词，用来描述这样一种做法：以自然语言表述意图，并通过评估结果而非逐行阅读来迭代 LLM 生成的代码。尽管这一术语较为随意，但它所捕捉到的观察却颇为深刻：那些在自身领域是专家、理解数据与工作流，却可能缺乏工程训练的科学家，恰恰非常适合这种开发模式。
我们以 MOSS(Microscopy Oriented Segmentation with Supervision，面向显微图像的监督式分割)为例说明这一转变。这是一款交互式分割工具，由一名软件开发经验有限的领域专家，主要通过 LLM 辅助编程(Claude Opus 4.6，以及后续的 4.8)，在数周内构建而成。MOSS 提供了一个通过直接标注与实时反馈在显微图像上训练 U-Net 模型的环境。用户绘制分割掩膜、训练模型，并在紧凑的交互循环中看到预测结果叠加于其数据之上(图2a)。该工具支持面向体数据的多种模型架构、掩膜编辑工具(画笔、橡皮擦、填充)，以及通过局域网进行分布式协同标注的多用户模式。尽管此前已有具备类似功能集的科研软件(例如 ilastik、napari、Microscopy SAM、Ais)，MOSS 仍针对手头的分割问题量身定制，并帮助我们在一个新兴模式生物(缓步动物，即水熊虫；图2b)的体数据中分割出特征。我们并不期望 MOSS 必定会征服分割软件世界。相反，我们相信，与过去相比，此类软件的创造已变得如此轻松，以至于未来许多问题都将通过即时创建的定制软件来解决。与 MOSS 一样，这些解决方案将建立在成熟的开放源代码库之上(例如 PyQt6、PyTorch 等)，它们组合起来便能产生具有新颖行为的工具。这曾经需要整个团队倾注专门的工程努力。
然而，随着 LLM 编程能力持续提升，学术软件或将面临若干可预见的后果。工程人力一直是科研软件创造的主要约束。随着这一约束的松弛，我们预计会出现大量针对特定工作流、用途狭窄的专用工具，而既有生态系统与平台则会日渐式微。例如，一位研究心肌细胞线粒体形态学的显微学家，或许会发现，与其改造或使用一个可能带有种种妥协的通用工具，不如自行构建一套定制化的分割与分析流程更为快捷。
我们认为，在 LLM 辅助开发中，最重要的技能是明确软件应当做什么，以及检验它是否正确做到了这一点——这与科学家提出假设并通过实验加以检验并无二致。编程经验对于关键应用似乎依然价值不菲，并在引导 LLM 智能体时有所帮助，但为科研编写可用代码的入门壁垒已大幅降低。重要的是，这种从实现到规范制定的转变，并未消除专业知识的价值。相反，它要求一种不同的能力组合：科学领域知识与精准传达技术意图的能力二者的结合。
与人类编写的代码一样，LLM 生成的代码同样包含缺陷，且常被形容为高度冗长、时而冗余。氛围编程方法弱化了逐行审查，而这对于科研软件本身便是一项挑战——在科研软件中，准确性至关重要，计算错误可能扩散至已发表的结果之中。有人辩称，科学中的 AI 工具存在制造"理解错觉"的风险，这一点同样适用于 AI 生成的代码：一个能运行的界面并不保证计算的正确性。无论代码是如何产生的，基于已知结果开展测试、在留出数据(held-out data)上验证，以及对方法进行同行评审，都是应对这些问题的既有且必要的途径。这或许构成了领域专家的一项优势：他们能够比软件开发人员更早地发现问题——尤其是与底层生物学不一致的结果。在实践中，对这些氛围编程工具的验证，目前是通过在构建过程中与工具进行迭代式、交互式的接触来完成的，而领域专家恰好擅长这种测试模式。
编程领域的这一转变，与生物学相关的其他进展相交汇：强大的 AI 基础模型(如 AlphaFold 与 Segment Anything)、日益标准化的模型共享平台，以及可复用 LLM 能力或"技能"(skills)的实现。如今，研究者可以拿一个预训练模型，通过一个由 LLM 辅助构建的定制界面在自己的数据上对其进行微调，并在数日内完成部署。这在五年前还难以实现。
尽管我们正处于 AI 革命之中，但要预测科研软件的质量最终是否会提升，仍为时尚早。LLM 辅助开发使既有代码的更新与扩展更为容易，但与此同时，由单个研究者构建的大量小工具的涌现，可能催生出一个由无人维护的软件组成的碎片化生态系统。更早出现的一个风险在于开发之初：由于许多团队向相似的前沿模型发出提示，由此产生的实现可能会趋同，造成同质化，从而使成果归属的追溯变得复杂，并可能限制新颖解决方案的出现。
新常态将是什么？
如今工具得以被创造的速度，引发了一个独立的担忧。当一种方法可以在数日内被重新实现时，开发它的竞争优势便会迅速消蚀。一个在会议上分享的构想，或在预印本中以充分细节描述的构想，可能在原作者完成同行评审之前，就被任何具备领域知识与 LLM 的人实现。然而，若以乐观的眼光看待，这一能力同样有益于可重复性：被详细描述的方法如今能够被更快地重建与独立验证，而实现方式已随时间湮没的代码也能够更容易地被重新实现。以月为单位衡量评审周期、作为成果归属主要载体的传统发表方式，在这种环境中或许需要调整。学界将需要考量，当构想与实现之间的鸿沟崩塌时，预印本、代码仓库或其他机制是否足以保护与认可方法学贡献。在我们看来，这与其说是损失，不如说是一种转变——持久的归属正朝向构想与生物学洞见转移。
在实践中，当前的生态系统已然碎片化。真正的问题或许不在于存在过多工具，而在于向既有平台贡献代码需要应对基础设施约束、API 约定与大量文档。我们的实例之所以被构建，恰恰是因为从零开始构建的成本，往往被认为低于使用既有框架的成本。倘若这一经验具有普遍性，未来或许会更青睐专用工具而非平台。随着工具数量的增长，BioImage Model Zoo 所倡导的互操作性社区标准将变得愈发重要，但组织原则可能会从共享平台转向共享格式。我们强调，这使得这些平台所确立的互操作性标准变得更加重要，而非更不重要。然而，在工具不断激增的情况下维持这些标准，需要有意识的社区努力。有趣的是，这一理念与 UNIX 世界的哲学颇有相似之处——在 UNIX 世界中，为解决单一问题而设计的小型专用工具，能够通过命令行实现高效运作。
展望
尽管当代的 LLM 与编程智能体仍在应对超大规模代码库，以及训练数据中代表性不足的算法时举步维艰，但每一代 LLM 都在缩小这一差距。这指向这样一种软件格局：这些挑战或许很快便能被克服，而学术科学界应当为此做好准备。
科研软件的存在，是为了从数据中提取洞见。降低其开发成本，能让研究者自由地专注于科学本身。这究竟会带来整体上更优质的科研软件，还是仅仅带来更多软件，将取决于在软件创造壁垒持续下降的过程中，学界所采纳的实践。这些实践包括：善用(harness)工程、以组合替代从零开发、针对成熟工具的差异测试、形式化验证、对智能体友好的平台接口，以及既有的测试、文档与维护规范。就目前而言，我们对科研软件的未来保持乐观，因为 LLM 辅助编程降低了软件开发的摩擦，使科学家能够将更多注意力投向其研究初衷所要回答的问题。
代码可用性
MOSS 以 MIT 许可证公开提供，地址为 https://github.com/StructuralNeurobiologyLab/MOSS。
作者： Nelson D. Medina, Joergen M. R. Kornfeld
