简介：Textira 是面向研究生、科研人员与课题组的 AI-native 科研工作台。它尝试把知识库、文献、实验、数据分析、科研绘图、论文写作、Visual + LaTeX 编辑、会刊模板与投稿准备连接到同一项 Research 中，让 AI 不只参与“写论文”，而是进入一项研究从实验到投稿的完整过程。
过去两年，AI 进入科研的速度非常快。从论文润色、摘要生成，到文献阅读、代码辅助、实验分析和论文写作，研究者已经越来越习惯在科研过程中调用大模型。写到一半，把一段论文交给 AI 修改；实验代码报错，让模型一起排查；面对几十篇相关工作，让 AI 先做一轮整理，这些都已经成为很常见的使用方式。
但另一个问题也越来越明显：AI 已经越来越会写论文，科研工作本身却没有因此变得完整。文献可能放在 Zotero 或 EndNote，实验跑在服务器和本地代码里，数据分析发生在 Python、R 或其他环境中，图表生成以后再放进 Word 或 LaTeX，需要 AI 时，又把其中一部分复制到聊天框里。到了投稿前，还要重新寻找会议模板、检查格式、确认 Deadline、处理匿名版本和最终文件。
于是很多研究者实际上形成了一条很长的工具链：
| 科研阶段 | 常见工作方式 | 容易出现的问题 |
|---|---|---|
| 文献积累 | Zotero、EndNote、PDF 文件夹 | 文献与后续实验、论文上下文分离 |
| 研究讨论 | ChatGPT、Claude 等通用 AI | 每次需要重新提供研究背景 |
| 实验与数据 | Python、R、本地代码、服务器 | 结果需要手动搬运到写作环境 |
| 科研绘图 | Python、Matplotlib、Origin 等 | 图表与对应数据、论文段落缺少持续关联 |
| 论文写作 | Word、LaTeX、Overleaf | 正文和前面的实验过程割裂 |
| 投稿准备 | 会议官网、模板、日历、投稿系统 | 模板、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 中的阶段 | Textira 对应的工作方式 |
|---|---|
| 研究资料 | 使用个人知识库保存和检索已有论文、课题资料与研究文档 |
| 文献阶段 | 文献继续围绕当前 Research 组织，而不是成为一次性的附件 |
| 实验阶段 | 可以从实验设计、已有实验或研究结果继续推进 |
| 数据与图表 | 对数据进行分析、整理，并生成科研图表 |
| 论文形成 | 围绕同一 Research 继续生成、修改和精修正文 |
| 专业编辑 | 使用 Visual + LaTeX 处理正文、公式、引用与版式 |
| 目标投稿 | 使用会刊、学位论文和预印本模板进入对应写作环境 |
| 时间节点 | 通过会议订阅和 Deadline 提醒管理投稿节奏 |
| 最终交付 | 导出 PDF、盲审 PDF、Word、LaTeX、PPT 等材料 |
| 外部连接 | 通过 MCP 与 HTTP API 接入第三方工具或科研 Agent |
这样来看，很多原本看起来彼此独立的功能，其实都围绕一个问题展开：一项研究如何逐渐成为一篇可以投稿的论文。
例如论文模板，如果把产品理解成一个普通编辑器，它只是“格式功能”；但如果把对象理解成 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 Writing | 生成、润色论文文字 | “帮我改一下这段” |
| AI Assistant | 阅读、分析、写代码、讨论实验 | “帮我分析这个结果” |
| AI Workspace | 持续理解同一项研究 | “基于当前 Research 继续完成论文” |
| Research Agent | 根据研究状态主动调用工具并推进任务 | “这项研究下一步还缺什么？” |
这里真正发生变化的，不只是 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 真正进入科研工作流以后，更值得关注的一步。
