夜雨聆风一、为什么科研需要一个专属的 AI 应用
过去两年，通用大模型在科研场景中的角色始终有一个明显的天花板：它们能和研究者讨论生物学问题、解释论文、帮忙写代码片段，但一旦涉及"跑一条真实的分析流水线""连接实验室自己的数据库""在集群上调度计算任务""记住上一次会话到底做了什么"，通用聊天助手就显得力不从心。
Anthropic 在 2026 年 6 月 30 日发布的Claude Science，正是针对这个断层给出的答案。需要明确的一点是：Claude Science不是一个新模型，而是一款独立的桌面应用，运行在用户现有 Claude 套餐（Pro、Max、Team、Enterprise）所包含的模型之上——目前包括 Opus 4.8 等。它的核心思路是把科研流程中分散的工具、数据库、文件格式和计算资源，整合进一个统一的工作环境，让研究者可以在其中完成从数据整理、分析、检索到论文撰写的全部阶段。
这也延续了 Anthropic 从 2025 年 10 月上线的 "Claude for Life Sciences" 连接器套件一路走来的产品逻辑：先让 Claude 具备科学协作能力，再把这些能力封装成一个真正意义上的科研操作环境。有评论将其类比为 Claude Code 之于软件工程——如果说 Claude Code 重塑了编程这门手艺的协作方式，Anthropic 显然希望 Claude Science 能在生命科学等领域复刻同样的路径。
二、核心能力拆解
2.1全链路可追溯的"科学证据链"
Claude Science 最强调的特性是可复现性。应用生成的每一份图表、表格或 Notebook，都会附带：
生成该结果所用的具体代码 运行代码时所处的环境（依赖、版本等） 一段用自然语言撰写的过程说明 促成这一结果的完整对话记录
这意味着几个月后，团队中的任何人都可以回溯某个图是怎么画出来的、某个数字是怎么算出来的，并原样复现。这种"结果 -> 代码 -> 环境 -> 对话"四位一体的留痕机制，本质上是把科研中长期依赖口口相传或零散笔记的"隐性知识"，转化成了结构化、可审计的记录。
2.2后台评审代理（Reviewer Agent）
在分析流水线运行过程中，系统会有一个独立的评审代理持续检查输出内容，包括：
引用是否有据可查 数字是否能追溯到源头 图表是否真的对应其底层代码
一旦发现无法验证的说法，评审代理会标记出来并推动自我修正，而不是等到人工审校阶段才暴露问题。这一机制针对的正是 AI 辅助科研中最容易被诟病的风险：模型"言之凿凿"但结论无法溯源。
2.3计算环境的按需编排
Claude Science 会为不同的分析专长各自管理独立的计算环境，并支持接入研究者已有的算力资源：
本地内核（笔记本、实验室 Linux 主机） 通过 SSH 连接的 Slurm 集群 或者 Modal 账户提供的按需云计算
在需要更多算力时，系统会先起草计划、征得用户同意后再申请资源，用户可以在任务提交前审查或撤销任何决策——从单个 GPU 扩展到数百个都遵循同样的确认流程。数据处理强调"本地优先"：应用可以安装在用户的算力所在地（笔记本、实验室服务器、HPC 登录节点或云主机），原始数据集和计算保留在本地，仅有提示词与模型回复部分按标准数据保留政策由 Anthropic 处理。
2.4 60+ 科学数据库与领域模型的原生连接
应用内置多个面向具体学科的分析专长，覆盖基因组学、单细胞分析、蛋白质组学、结构生物学、化学信息学等方向，并且可以原生连接 60 余个科学数据库（例如 PubMed、UniProt 等）。此外，Claude Science 还借助 NVIDIA BioNeMo Agent Toolkit 中的能力，接入 BioNeMo 生态下的生命科学模型和工具库，包括 Evo 2、Boltz-2 和 OpenFold3 等蛋白质/序列建模工具。
2.5原生科学制品渲染
不同于普通聊天窗口的纯文本输出，Claude Science 可以在应用内直接查看和交互：
3D 蛋白质结构 基因组浏览器轨道（genome browser tracks） 化学分子结构 各类 PDF 与实验记录文件
研究者甚至可以直接在图表上做批注请求修改，系统会读取生成该图的代码并据此直接编辑，而不需要研究者手动调整绘图脚本。写作阶段则支持 Markdown 与 LaTeX 的实时预览，让分析与成稿在同一环境中完成。
2.6连接器（Connectors）
针对实验室已有的信息系统，Claude Science 支持接入内部 API、电子实验记录本（ELN）以及自定义流水线，使其能够嵌入现有工作流，而不是要求团队推倒重来。
三、产品定位与发布细节
项目 | 内容 |
产品性质 | 桌面应用（非新模型），公开测试版 |
支持系统 | macOS、Linux（暂未提及 Windows 支持） |
适用套餐 | Pro、Max、Team、Enterprise（不含免费用户） |
底层模型 | 沿用用户所在套餐包含的 Claude 模型 |
发布时间 | 026 年 6 月 30 日 |
在发布会上，Anthropic CEO Dario Amodei 谈到，人类此前理解生物学复杂性主要依靠"用大脑硬啃"；虽然生物学不像代码那样简洁规整，但他认为 AI 在这一领域同样可以成为一种通用赋能技术，帮助人类更好地驾驭这种复杂性——不过他也坦言，这一路径能否真正成功尚属未知。
值得一提的是，Anthropic 同时开放了 "AI for Science" 项目申请：面向最多 50 个科研项目提供支持，单个项目最高可获得约 3 万美元额度外加 Modal 计算资源，重点面向生物医学方向的博士后与研究生。申请截止日期为 2026 年 7 月 15 日，结果将于 7 月 31 日公布，项目执行周期为当年 9 月至 12 月。有意申请的团队应以 Anthropic 官方页面公布的信息为准，因为窗口期具有时效性。
四、简要点评
从产品逻辑上看，Claude Science 延续了 Anthropic 近两年"围绕模型能力打造垂直工作流"的打法：Claude Code 解决了软件工程师的日常协作问题，Claude Science 则试图解决科研人员长期忍受的"工具链割裂"问题——在几十个数据库、编程语言、集群终端和文件格式之间来回切换的效率损耗。
它的差异化并不在于模型本身更聪明，而在于三点：可复现性（结果与代码环境绑定）、可信度（评审代理主动纠错）和基础设施灵活性（本地优先、多种算力接入方式）。这恰好回应了当前 AI 辅助科研最常被质疑的问题——"AI 给出的结果到底能不能被验证、被复现"。
至于实际效果如何，仍需要在真实实验室场景中检验：跨学科的分析专长是否足够专业、评审代理的纠错能力边界在哪里、以及在处理超大规模基因组或结构生物学数据时的性能表现，都是值得持续跟踪的问题。
五、AI 能在“软件工厂”体系里扮演什么角色
把视野拉回到 AI 辅助工程这条主线：软件工厂本质上是一套"强治理、强留痕"的工程体系，这与提到的 Claude Science 在科研场景中强调的"结果可追溯到代码与环境"的理念是相通的——两者面对的都是同一类问题：当过程变得越来越自动化、越来越依赖 AI 辅助生成代码或分析结论时，如何保证每一步都留有可审计的证据链。
在装备软件工程场景中，AI 辅助工具如果要真正融入这类高治理要求的软件工厂流水线，大概率需要具备三个特征：
变更留痕：AI 生成或修改的每一段代码，都应当自动关联到对应的提交记录、评审意见与安全扫描结果，而不是作为一个不透明的"黑箱贡献"进入代码库； 策略可控：AI 工具的行为边界（例如可以访问哪些仓库、可以调用哪些外部服务）应当由平台层统一治理，而不是由单个开发者的本地配置决定； 持续验证友好：AI 辅助产出的代码变更，应当天然适配持续集成中的自动化测试与安全扫描节奏，成为 cATO 式持续验证链条上的一环，而不是游离在外的例外情况。
这也是为什么"软件工厂"和"AI 辅助工程平台"这两个原本分属不同讨论语境的话题，正在装备与国防信息化领域逐渐交汇——两者共同指向的，是一种更结构化、更可验证的软件交付方式。
六、"软件工厂"到底是什么
"软件工厂"最初是一个略带误导性的名字——它容易让人联想到"标准化流水线批量产出代码"的画面。但在装备与国防信息化语境下，业内更倾向于把它理解为一套组织级的 DevSecOps 能力底座：把开发（Dev）、安全（Sec）、运维（Ops）三个环节，通过统一的平台、工具链和治理规则，嵌入到装备软件从需求到交付的全生命周期中。
以美国空军 2017 年成立的 Kessel Run 为例，它对外常被称作"软件工厂"，但其内部人员更愿意强调自己是一个"DevSecOps 作战单元"——差别在于：软件工厂提供的是场地、工具和开发能力，而 DevSecOps 单元的目标是持续交付能真正解决作战/保障任务的能力。这个区分背后是一个关键认知：软件工厂不是目的，而是让团队更快、更安全地把能力送到一线的手段。
另一个具有代表性的案例是美国空军的 Platform One，成立于 2018 年，定位是为其他软件工厂提供公共底座能力，包括协作与网络安全工具、源代码仓库、制品仓库、以及"DevSecOps 即服务"，让具体的任务团队可以专注于业务应用本身，而不必各自重复建设基础设施。
七、支撑软件工厂运转的几个工程支柱
7.1 CI/CD 与 GitOps：让变更可控、可回滚
装备软件的迭代节奏和商业互联网软件有相似之处，也有本质区别——任何一次发布都必须留下完整、可审计的变更记录。这正是 GitOps 理念在国防软件工厂中被广泛采纳的原因：所有基础设施与应用配置都以代码形式声明并纳入版本控制，任何变更都可观测、可追溯、必要时可一键回滚，从而在提升发布频率的同时保住可靠性与安全性的底线。
7.2安全左移与持续授权（cATO）
传统装备软件的安全合规流程，往往是在开发完成后统一进行安全评估与"运行授权"（Authority to Operate, ATO），周期动辄数月甚至更久，这与敏捷交付的节奏是天然矛盾的。软件工厂模式的核心突破之一，就是把安全检查前移并常态化：代码在每一次提交时就经过多重扫描（静态代码分析、依赖漏洞扫描、镜像合规检查等），安全团队与产品团队共同对流水线的合规状态负责，而不是把安全当作交付前的最后一关。
在此基础上演进出的"持续授权"（Continuous ATO, cATO）理念，进一步把"一次性审批"变成"持续验证"：只要流水线本身能够持续证明其安全基线没有被破坏，软件就可以在获批的边界内保持持续交付能力，而不必每次改动都重新走一遍完整的审批流程。像 Platform One 旗下的 Iron Bank（经过安全评估的容器镜像仓库）与 Big Bang（集成化 DevSecOps 工具套件）就是围绕 cATO 理念构建的典型基础设施：前者保证"进入生产环境的每一个容器都是可信的"，后者负责在部署后持续监控、执行安全策略。
7.3容器化与云原生架构
现代装备软件工厂普遍采用容器化与 Kubernetes 为代表的云原生技术栈，原因和商业领域类似：环境一致性、弹性伸缩、便于在不同算力环境（本地数据中心、边缘节点、云）之间迁移部署。但国防场景多出一层要求——软件往往需要在断网、弱网或高对抗电磁环境下依然可用，这要求架构设计从一开始就要考虑边缘部署与分布式韧性，而不能假设持续在线的中心化云环境。
7.4统一平台降低重复建设成本
装备研制体系通常涉及多个军种、多个承包商、多条产品线，历史上容易出现"每个项目各自建一套工具链"的重复投入。软件工厂模式试图通过提供标准化的公共能力层（源码托管、制品仓库、CI/CD 流水线模板、安全扫描服务等），让不同任务团队可以"拎包入住"，把精力集中在业务应用本身的开发上，而不是反复造轮子。Platform One 与 Kessel Run 之间通过正式的协作协议共享失败经验与可复用组件，也是这种"减少重复建设"思路的体现。
八、落地过程中的现实挑战
软件工厂模式在装备与JG领域的推广并非一帆风顺，几个反复出现的挑战包括：
遗留系统与新架构的融合：大量存量装备信息系统建设于云原生理念普及之前，如何在不推倒重来的前提下，把这些系统纳入统一的 DevSecOps 治理框架，是许多软件工厂团队面临的长期任务。 组织文化的转型阻力：从瀑布式的长周期集中交付，转向持续迭代、快速反馈的工作方式，涉及的不仅是工具变化，更是团队协作方式、绩效评估标准乃至采购流程的系统性调整。 安全与速度的动态平衡：即便有 cATO 等机制加持，"更快交付"与"更严安全审查"之间依然存在张力，需要靠流水线自动化程度的持续提升来缓解，而不是靠放松标准。 跨机构协同的复杂度：装备研制往往涉及政府方、多个承包商、不同安全等级的系统集成，公共平台层的接口标准、身份认证与权限治理需要在更大范围内达成一致。
