ai4s-research/open-science

Open Science 是一个为科研人员设计的 AI 工作台桌面应用，它不是一个聊天机器人，而是一个将文献、代码、图表、报告和审阅整合进一个可审计、可复现工作流的工具。它的目标用户是需要严谨、可追溯研究过程的科学家和工程师。

今天，一个科研人员若想借助 AI 辅助研究，典型路径是：在 Claude Science 或类似商业产品中描述问题，获取文本建议和代码片段；然后手动将这些代码复制到 Jupyter Notebook 或本地 IDE 中运行；生成的图表需要手动保存，并与对应的代码、数据和对话历史建立关联。整个过程是割裂的：AI 对话在一个界面，代码执行在另一个环境，数据管理又依赖本地文件夹，最终要拼凑出一份可复现的报告，需要大量手工整理和记录。

真正的卡点在于“关联断裂”。当 AI 生成了一段数据分析代码并输出了一个图表时，几天后研究者可能已经忘记这段代码对应哪个数据版本、由哪次对话触发、使用了哪个模型参数。商业工具如 Claude Science 虽然提供了集成环境，但其闭源性和云端处理让科研人员对数据隐私、计算过程黑箱以及长期可复现性心存疑虑。自己用脚本拼接开源工具（如 LangChain + Jupyter + Git）理论上可行，但很快会陷入工具链配置、API 兼容、状态管理和审计日志记录的繁琐工程中，偏离了科研本身。

Open Science 切入的是 **工作流封装层** 和 **可复现性管理层**。它没有发明新的模型或算法，而是将科研人员已有的、但分散的工具和动作（提问、编码、执行、绘图、记录）封装进一个以“项目”和“可追溯工件”为中心的桌面环境。其核心是使用 MCP 来连接外部工具和数据源，确保每一步操作都能被记录和链接。

旧方案不够好，正是因为 Claude Science 等商业方案是“黑箱云端服务”，而自己搭建开源工具链则“工程负担过重”。科研工作流对透明性、数据主权和长期可复现性的要求，与当前主流 AI 工具的“一次性对话生成”模式存在根本冲突。

这个项目现在成立，直接源于几个具体条件的变化：首先，**MCP 的普及** 为桌面应用标准化接入外部工具（如代码解释器、数据库、绘图库）提供了协议基础，使得构建一个功能丰富且可扩展的工作台成为可能。其次，**开源生态出现可拼装方案**，如 Tauri 让构建高性能跨平台桌面应用更简单，OpenRouter 等模型路由服务简化了多模型接入。再者，**AI 从聊天转向执行任务**的趋势明显，科研正是需要多步骤、有状态、产生产出物的典型场景，市场呼唤超越聊天框的“工作台”形态。

它透露出一个变化：AI 辅助专业工作的重点，正从“生成内容”转向“管理生成过程”。当任务变得复杂、周期变长、协作方增多时，过程的透明性、工件的可追溯性、以及环境的可控性，其价值开始超过单纯的生成质量或速度。这预示着下一批工具的机会在于为垂直领域（如科研、法律、金融）封装具备审计和复现能力的 AI 工作流，而不仅仅是提供更聪明的聊天机器人。

对于 Builder 而言，今天可以将其作为一个本地优先、注重隐私的 AI 科研伴侣原型来试用，尤其适合处理敏感数据或需要严格记录实验过程的项目。最值得学习的不是其某个具体功能，而是它 **以“可追溯工件”为核心的数据模型设计**。它将每次 AI 交互、生成的代码、运行的输出、产生的图表都作为相互链接的“工件”来管理，并绑定环境上下文，这巧妙地解决了科研中“知其然，不知其所以然（来自哪次实验）”的痛点。这种将线性对话树升级为网状工件图谱的设计思路，可以迁移到任何需要版本化、可审计 AI 产出的领域，例如 AI 辅助的法律文件起草、合规代码审查或创意设计迭代，在这些场景中，产出的演变过程和决策依据与最终结果同等重要。