AIPOCH开源科研工作台1.0：从Vibe Coding走向Vibe Research

2025年，Vibe Coding在科技圈被反复提起，柯林斯年度词汇也把它收了进去：用户把想法用自然语言讲给AI听，由模型帮忙写代码、跑代码、改代码。到了2026年，这套做法开始往科研里渗透——查文献、理数据、做分析、出图表，研究者把其中一部分交给智能体去干，自己腾出精力琢磨提什么问题、怎么判断结果。

有人给这种变化起了个名字，叫Vibe Research。说的是一种人机配合的形态：方向和研究者的关键判断由人给，具体执行归AI。工具操作越来越不难上手，研究者能更直接地围着问题来安排活儿。

不过，操作门槛降下来，仅仅是开头。

科研应用跟搭个原型不是一回事，它得扛住方法、证据和复现这三关的检验。代码能跑通、图能顺利画出来，不等于结论就站得住。更要紧的是，一次性对话撑不起长期研究：一个项目动辄跨周跨月，中途要换数据版本、调整分析方法、答复合作者和审稿人——这些都得靠文件、环境、工具调用和过程记录一块儿存着，不能散在聊天记录里。

Vibe Research能走多远，一看模型本事，二看支撑执行、记录与验证的那层基础设施。

近日，AIPOCH团队把自家开源AI科研工作台AIPOCH Open-Science推到了1.0版本。项目采用Apache-2.0协议开源，macOS、Windows和Linux桌面端都能用，另外还配了命令行工具。

按官方说法，产品设计、软件开发与研发推进由AIPOCH团队担纲，参与试用和验证的合作作者来自全球76家院校及机构，涵盖复旦大学附属中山医院、阿姆斯特丹大学医学中心（Amsterdam UMC）、哈佛医学院教学医院贝斯以色列女执事医疗中心（Beth Israel Deaconess Medical Center）等医学中心，北京大学、上海交通大学、浙江大学、伊利诺伊大学厄巴纳-香槟分校、以色列理工学院等高校，以及商汤科技、艾德生物等企业。预印本链接：https://arxiv.org/abs/2610.17110。

Open-Science产品演示

它一方面是个帮研究者干活的科研工作台，另一方面也把模型、数据、工具和过程记录串起来，充当科研操作系统。

有了.science包，AI的使用过程能跨系统、跨机器带走，形成可检查、可交接的存档。它既方便人与人协作，也让专家经验有机会留下来继续用——这兴许会成Agent时代的一种新工作方式。

AIPOCH Open-Science官网案例库

想具体体会.science的价值，可以把它看作一份能翻阅的研究档案：别人分享的研究包打开后，顺着选定的对话分支、文件版本、Notebook记录和验证证据，就能看清一个问题是怎么被提出、分析和复核的。拿来学专家如何组织假设、挑数据、调工具、核结果都合适，团队交接前想弄明白一项工作的来龙去脉也用得上；导入之后内容保持只读，本机不会跑代码，也不会恢复凭据。

AIPOCH在Hugging Face和官网上持续维护案例仓库，里面的研究实例可以直接浏览：数据、代码、证据和对话怎么连成可检查的产出，一看便知。这些内容可通过Hugging Face案例库和官网Use Case Gallery访问。

.science包的组织思路跟RO-Crate等开放标准也能对上：研究数据、代码、作者、许可和provenance合在一起，构成一个可交换的“研究对象”，研究记录不必再困在某个软件界面里。

一、越攒越多的工具，越切越碎的流程

文献管理、数据分析、绘图排版、流程编排，科研的不少环节早就有了趁手的工具。可选的东西多了，工具之间怎么接上，还是得研究者自己动手。

文献躺在文献管理器里，原始数据散落在文件夹和数据库中，分析要在Python、R与命令行之间来回切换，图表导出后才能进报告。跨工具干活时，研究者常常得重新捋一遍背景：数据哪来的，变量什么意思，上一步用了什么处理方法。

这当中重复的文件搬运、环境配置和信息核对，会额外吃掉精力，还可能带来版本混淆和操作遗漏。对刚踏入某个研究领域的人来说，熟悉工具、准备环境，甚至可能变成开始分析前先要迈过的一道坎。

自然语言交互让发起任务更直观，但对话本身并不会自动把这些衔接问题抹平。AI写的代码在哪儿跑，输入文件怎么管，图表怎么对应到具体分析步骤，还是得有一套明确的工作机制。

从“能对AI提要求”到“能持续做一项研究”，中间还差一层活儿要接上。

二、把研究任务，组织进同一个项目

AIPOCH Open-Science的做法是以项目为单位，把资料整理、计算分析和产物管理收拢到同一个工作区。

Open-Science界面：一项催化剂研究简报的证据评估

研究者在项目里写清目标，引论文和数据，排好分析任务，再看生成的报告、表格与图表。相关文件和讨论记录都会留下，给后续工作提供上下文。执行层支持Python与R计算环境，运行中的内核能保住变量和分析状态，方便连着处理任务；耗时长的工作可以扔到后台跑。本地算力不够时，还能用配置好的SSH远程主机或Slurm集群。

项目文件和工作区记录默认存在本地。不过有件事得说清楚：一旦调用云模型、网络搜索或远程科研连接器，提示词、必要的上下文或者任务输入，就可能被发往对应的服务。为了管住这些操作，工作台准备了多种权限模式，研究者可以按具体任务来定，哪些动作需要自己点头确认。

模型这块，Open-Science 接入了多家模型服务，也支持兼容的自定义网关。用哪个模型，研究者可以按会话挑，推理设置也能在支持范围内调。配置换完之后别急着跑，工具调用和任务执行是否符合预期，还是得再查一遍。

除了连工具，工作台还留了方法复用的口子。内置科研连接器覆盖科学文献、生物医学等方向，精选技能则对应文献综述、计算生物学这些场景。常用的流程，研究者可以整理成技能包，通过技能市场浏览、安装和更新；也能配置专家智能体，把它的角色和可用工具定清楚。

Open-Science 概念工作流：从研究任务、执行与复核到研究者接续

三、AI 做的分析，怎样留下可检查的依据

可复现性这个话题，其实早就被反复讨论了。2016 年《自然》做过一项调查，收集了 1500 余名研究者的回答，其中超过 70% 的受访者说，自己试过重复别人的实验，但没成功。十年过去，AI 开始接手越来越多的分析步骤，怎么检查过程、怎么解释差异，又冒出了一批新的实际问题。

在 Open-Science 里，研究产物会和系统已经抓到的记录挂上钩。报告、图表、表格这类文件，工作台会留下产物版本，供研究者回头翻看。至于内置编辑器里改动支持的脚本或文本类产物，一保存就会生成新版本，前后有什么变化，比较起来方便。

和版本绑在一起的是溯源机制。某个产物关联到的代码、输入文件、执行历史、环境信息以及对话上下文，只要系统记录过，研究者都能点开查看。碰上拿不到或者没法核实的证据，系统会提示尚不可用，不会把缺失的信息当成已经确认的事实。

研究者还可以按需打开复核功能。系统会对照已有的对话、执行记录和产物，把缺乏支撑的结论、前后矛盾的说法或者证据缺口提示出来。它给的只是辅助检查的线索，替代不了对研究方法和科学结论的独立验证。

这些记录有什么用？导师能查看分析步骤，合作者能核对某个数字，研究者为投稿整理方法时，也不用从零开始翻找。但边界要讲清楚——记录和 .science 包能降低核对与重用的成本，想完整重放，还得看输入、执行配方、软件依赖、权限和可用环境。

过程可追溯，意思是结果有线索可查；至于能不能复现、结论可不可靠，那要结合数据、方法和执行条件来验证。研究判断这件事，仍然归研究者。

四、从工具连接，走向方法共享

从 Vibe Coding 到 Vibe Research，最先变的是任务怎么提出来、工具怎么被调起来。可要让这种工作方式持续服务科研，还得有几层支撑。

第一层，是降低操作门槛。用自然语言把任务组织起来，研究者调动已有工具会更容易，精力也能更多放在问题、方法和判断上。

第二层，是连接工作环节。文献、数据、代码、计算环境与研究产物被组织进同一个项目，重复搬运少了，做完的工作也能为下一步所用。

第三层，是支持开放复用。项目代码用 Apache-2.0 许可证公开，研究者和开发者可以按许可条款查阅、修改和分发。技能包、工具配置以及可检查的过程记录，让方法交流有了更具体的基础。

开源软件不等于研究资料自动公开。分享什么、分享给谁，决定权仍在研究者手里；方法能不能套用到新数据上，接收者也得自己检查。在这个前提下，开放的工具加上可携带的方法，才有机会让跨团队的复用和验证更容易做起来。

Open-Science 要做的，不是又一个更会答题的 AI 工具。它想回答的是：研究者把一部分操作交给 AI 之后，中间那层把文件、工具、环境和证据串起来的基础设施，到底该是什么样子。

项目官网上写着一句话，“Science, Open to All”。落到具体工作里，就是工具更易用，过程更易查，团队攒下的方法有机会被更多人看懂、改进。至于研究问题怎么提、方法怎么选、结论怎么判，这些还是研究者自己的事。