用 MCP 把文献库接到写作工作流
不要把 MCP 当成又一层插件目录。先固定「检索 → 摘录 → 引用」三条接口，写作时才接得上文献库。
研究里最常见的断裂不是「没有工具」，而是文献在一个软件里，笔记在另一个地方，写作又在第三处。MCP（Model Context Protocol）有用的前提，是你先承认这件事：模型不该去「逛」你的整个硬盘，它只该在你指定的三个动作上有权限。
先定三条接口，再选服务器
把工作流收成三条，比装一堆 MCP 服务器更重要：
- 检索：按题目、方法、数据集或任务问文献库，返回少量高相关条目，而不是一百条摘要。
- 摘录：对指定论文取出方法段、实验设置和限制，并保留页码或章节锚点。
- 引用：写作时插入已经核对过的条目，而不是让模型现场编一个 APA。
Zotero、本地 Markdown 库、论文 PDF 目录都可以成为后端。差别在于：有没有稳定的条目 ID，以及你能不能把「已读 / 未核」标出来。没有 ID 的摘录，写 Related Work 时几乎无法回查。
Skill 和插件放在哪一层
编辑器里的 Skill、斜杠命令和 MCP 不要叠成三套入口。一个比较稳的分层是：
- MCP：只负责连外部系统（文献库、实验日志、仓库）。
- Skill / 命令：负责你重复在做的研究动作，例如「对比两篇方法的假设」「把实验记录收成一段」。
- 插件：只管编辑体验，不管研究状态。
如果同一个动作既有斜杠命令又有 MCP 工具，最后你一定记不住该用哪个。宁可少，让一条路径被走顺。
一个最小可运行的接法
不必一上来就自动化整条流水线。第一周只做这件事就够：
- 文献库里给每篇论文一个稳定 key（citekey 或自己的 slug）。
- 让检索接口只返回
key / 标题 / 年份 / 一句话贡献。 - 写作时只允许插入已有 key；新论文必须先入库，再被引用。
这会显得笨，但它挡住了最贵的错误：模型写出一段漂亮综述，你却无法指出每一句来自哪篇。工具栈的价值不在目录有多长，而在引用链是否还在你手里。