从 AI 写作到科研工作台，Textira 正在重新连接论文从实验到投稿的流程

简介：Textira 是面向研究生、科研人员与课题组的 AI-native 科研工作台。它尝试把知识库、文献、实验、数据分析、科研绘图、论文写作、Visual + LaTeX 编辑、会刊模板与投稿准备连接到同一项 Research 中，让 AI 不只参与“写论文”，而是进入一项研究从实验到投稿的完整过程。

过去两年，AI 进入科研的速度非常快。从论文润色、摘要生成，到文献阅读、代码辅助、实验分析和论文写作，研究者已经越来越习惯在科研过程中调用大模型。写到一半，把一段论文交给 AI 修改；实验代码报错，让模型一起排查；面对几十篇相关工作，让 AI 先做一轮整理，这些都已经成为很常见的使用方式。

但另一个问题也越来越明显：AI 已经越来越会写论文，科研工作本身却没有因此变得完整。文献可能放在 Zotero 或 EndNote，实验跑在服务器和本地代码里，数据分析发生在 Python、R 或其他环境中，图表生成以后再放进 Word 或 LaTeX，需要 AI 时，又把其中一部分复制到聊天框里。到了投稿前，还要重新寻找会议模板、检查格式、确认 Deadline、处理匿名版本和最终文件。

于是很多研究者实际上形成了一条很长的工具链：

这些工具本身都没有问题，甚至在各自领域都已经非常成熟。真正的问题是，一项 Research 天然会穿过所有这些边界，而负责把它们连接起来的人，仍然是研究者自己。AI 加入了科研，却往往只是这条链路上的又一个窗口。

Textira 正是在这个背景下出现的。它并不是从“怎么再做一个 AI 写论文工具”开始，而是试图重新定义科研软件应该围绕什么工作。它给出的答案是：Research。

AI 会写论文以后，真正困难的是维护一项研究

如果只是让 AI 生成一段学术文字，现在已经不算困难。给一个题目，大模型可以生成大纲；给一组研究背景，可以尝试写 Introduction；输入实验结果，也可以整理成 Results；论文写完以后，还可以继续修改语言、压缩摘要、调整结构。

但科研论文和普通内容生成有一个本质区别：论文并不是从文字开始的。在真正开始写正文之前，研究者通常已经完成了大量工作，看过一批论文，做过多轮实验，淘汰过一些失败方向，留下了一组确认过的数据，画出了最终使用的图表，并逐渐形成了对研究问题的判断。论文只是这些研究过程最终被组织出来的一种表达形式。

因此，真正困难的问题并不是“AI 能不能帮我写这一段”，而是“AI 是否知道这一段为什么应该这么写”。一个数字来自哪次实验，一张图对应哪组数据，一个结论有没有足够证据，某篇引用是否真的和当前论点有关，已经确认过的结果在后续修改中是不是应该保持不变，这些问题都依赖同一件事：系统必须理解论文背后的研究状态。

现在很多 AI 工作流并没有真正维护这层状态。研究者通常是在不同阶段，把当前需要的一部分上下文重新交给模型。实验完成以后，把结果复制进去；要写 Related Work 时，再上传文献；改 Discussion 时，又重新解释前面的实验。模型可能拥有越来越大的上下文窗口，但“能一次读取很多内容”和“真正持续理解一项研究”仍然不是同一件事。

一项 Research 可能持续几个月，甚至几年。它有自己的研究问题、文献、实验、数据、图表、论文版本和投稿目标，这些信息之间还会不断发生变化。实验结果变了，论文里的数字和讨论可能需要一起改变；目标会议变了，篇幅、版式和匿名要求也会改变；新的关键文献加入以后，论文的研究定位甚至可能需要重新调整。

这也是为什么 Textira 没有把最核心的工作对象定义成 Conversation，也没有只定义成 Document，而是把基本单位定义成一项 Research。

Textira 想做的，不是再加一个聊天框，而是把 Research 接起来

传统科研工具的边界其实非常清晰。Zotero、EndNote 围绕文献和引用工作，Word、LaTeX、Overleaf 围绕论文文档工作，通用 AI 更自然地围绕对话和任务工作。它们分别解决了科研中的重要问题，但一项真实研究并不等同于其中任何一个对象。

Textira 的思路，是让原本分散的内容尽可能继续围绕同一个 Research 存在。研究者不一定要从一个空白 Introduction 开始，可以先整理自己的资料，也可以从已有文献开始；如果实验已经做了一部分，也可以直接从实验和结果继续；当数据逐渐稳定以后，再让图表、论证和论文正文进入同一条研究线上。

这里真正重要的变化，不是“功能更多”，而是上下文不再需要不断被重新建立。研究者自己的论文、课题资料、实验说明和长期积累的文献，可以进入个人知识库，在后续研究中继续检索和使用。今天整理 Introduction 时使用过的一批文献，之后写 Discussion 时仍然可以继续参与当前 Research；过去记录的实验信息，也不需要每一次重新从头解释。

对于长期科研任务来说，这种连续性往往比“模型一次能读多少 PDF”更重要。一个真正有价值的科研 Agent，不应该只知道用户刚刚说了什么，还应该知道这项研究已经做了什么、哪些结果已经确认、哪些问题还没有解决。

实验和论文之间也是一样。很多传统流程里，实验结束以后，研究者需要手动把数据、图表和结论搬到论文环境中，再把部分结果复制给 AI，让模型重新理解。Textira 更希望让实验、数据分析、科研绘图和论文写作本身处于同一个 Research 中，这样 AI 的作用就从“收到一段结果以后帮我生成文字”，变成“基于当前已经存在的研究结果继续表达”。

这背后有一个很简单的原则：数字应该来自实验，论文负责表达实验。 尤其是在生成式 AI 进入科研以后，这个顺序反而越来越重要。模型非常擅长补全一段“看起来像论文”的文字，但科研工具真正应该做的，不是让这种补全更自然，而是尽可能让表达继续依赖真实存在的研究事实。

从资料、实验到论文，Research 应该是一条连续链路

如果把 Textira 的产品逻辑放在一条完整科研链路里，会更容易理解它为什么会同时包含知识库、实验、LaTeX、模板和 Deadline。

这样来看，很多原本看起来彼此独立的功能，其实都围绕一个问题展开：一项研究如何逐渐成为一篇可以投稿的论文。

例如论文模板，如果把产品理解成一个普通编辑器，它只是“格式功能”；但如果把对象理解成 Research，目标会议本来就应该更早进入研究过程。准备投 NeurIPS、ICML、CVPR，和准备写中文期刊、硕士论文、博士论文，面对的篇幅、版式和最终交付方式都不同。Textira 目前提供 50 套会刊、学位论文与预印本模板，覆盖 NeurIPS、ICML、CVPR、中文期刊、硕士论文、博士论文和 Preprint 等场景，目的并不是让论文写完以后再去“套模板”，而是让目标会刊从更早阶段参与论文形成。

Deadline 也是同样的逻辑。表面上看，学术会议订阅和截稿提醒似乎只是日历能力，但真正做过会议论文的人都知道，Deadline 会直接决定实验什么时候停止、初稿什么时候必须完成、什么时候需要让合作者 Review，以及什么时候进入匿名和最终投稿阶段。因此，“写什么”“投哪里”“什么时候完成”本来就是同一个 Research 的三个方面。

论文完成以后，还必须能够离开平台。科研成果不是聊天记录，研究者可能需要 Word 给导师修改，需要 PDF 参加投稿，需要匿名盲审 PDF，也可能需要保留 LaTeX 源码或者进一步整理成汇报 PPT。Textira 支持这些输出形式，本质上也是因为 Research 的终点不是得到一句 AI 回复，而是形成一份可以继续修改、协作、投稿和归档的研究成果。

为什么还要做 MCP 和 API

如果 Textira 已经试图把更多科研环节放进一个 Research，为什么还需要 MCP 和 API？

因为科研工作本身不可能真正被一个产品全部包下来。

不同学科已经有自己的实验环境、数据库、代码工具、分析软件和专业科研系统。计算机研究可能依赖代码仓库和 GPU 服务器，生物医学研究可能有完全不同的数据来源和实验工具，文献又有自己的数据库和管理系统。试图重新实现所有能力，并不现实。

因此，更可能出现的科研 AI 形态不是“一个超级软件完成一切”，而是不同工具之间开始被 Agent 连接。

Textira 提供 MCP 与 HTTP API，也是基于这样的判断。第三方工具、科研 Agent 或实验室自己的系统，可以进一步接入相关能力。未来一个 Research Agent 可能同时调用文献检索工具、实验环境、代码执行、数据分析和论文工作台，再把这些结果持续写回同一项 Research 的状态中。

这和目前 AI 编程工具的发展有些相似。早期代码生成只是给出一段代码，后来 AI 开始读取项目文件、修改多个文件、运行命令、检查错误，再根据执行结果继续工作。它从“代码生成器”逐渐进入真正的软件项目。

科研工具也可能经历类似变化。

如果 AI 永远只能看到研究者最后复制给它的几段内容，它承担的仍然主要是 Writer；如果它可以持续进入 Research，理解文献、实验、数据、图表和论文之间的关系，它才有可能进一步成为 Research Agent。

AI 科研软件正在从 Writer 走向 Workspace

过去几年，很多 AI 科研产品的竞争重点都集中在 Writer。谁生成得更快，谁写得更长，谁的学术语言更自然，谁能够一次生成更多章节，这些能力都非常直观。

但随着基础模型本身越来越强，纯文字生成正在快速变成一种基础能力。真正难以被模型单独解决的，是科研过程中的状态和关系。

一个数字来自哪里，一张图和哪组数据对应，一条结论有什么证据，哪些实验已经确认，哪些结果发生了变化，哪篇论文准备投到哪里，这些都不是单纯的文本生成问题，而更接近 Research Management。

这也是为什么 Textira 更愿意把自己定义成 AI-native Research Workspace，而不是另一个 AI Writer。

Writer 的核心任务是生成内容，Workspace 的核心任务则是让一项研究能够持续发生。它需要承载研究的历史，也需要跟随研究状态变化，并最终把资料、实验、数据和论文收敛成可以交付的成果。

如果把科研 AI 的演进简单概括，可以理解成这样：

这里真正发生变化的，不只是 AI 能力，而是 AI 所看到的对象变了。

从一句 Prompt，到一次 Conversation，再到一份 Document，最后可能是一项持续存在的 Research。

这也是 Textira 目前正在尝试的位置。

结语

AI 已经越来越会写论文，这件事本身可能很快就不会再成为科研软件最重要的差异。

真正值得继续解决的问题，是如何让 AI 理解论文背后那项持续发生的研究。研究不是一次 Prompt，也不是一份孤立文档，它包含文献、实验、数据、图表、判断、论文版本和投稿目标，而且这些内容会在很长时间里不断变化。

Textira 选择把一项 Research 作为基本工作对象，把个人知识库、文献、实验、数据分析、科研绘图、Visual + LaTeX、会刊模板、Deadline、投稿准备和最终导出逐渐连接起来，同时通过 MCP 和 API 保留与外部工具协作的可能。

这些能力单独来看，都不是科研领域从未出现过的新功能。真正值得关注的是，它们开始被重新组织到同一项 Research 里。

当 AI 只是 Writer 时，我们关心的是它能不能写出一段论文；当 AI 进入 Workspace 后，我们开始关心它知不知道这些内容来自哪里；而当 Research Agent 真正出现以后，问题可能进一步变成：它是否知道这项研究已经完成了什么，现在缺少什么，以及下一步应该继续做什么。

从“帮我写论文”，到“继续我的研究”。

这可能才是 AI 真正进入科研工作流以后，更值得关注的一步。