当 AI 答不上＂PubMed 怎么查＂:一次为科研工作流定制一个 Skill 的全过程

一个看起来很简单的问题

那天，我问了 AI 一个问题：

"我需要从 PubMed 进行文献检索和获取。有没有现成的工具可以让我使用？"

这个问题不大不小。说它小，是因为 PubMed 检索是科研日常——文献综述、查证引用、追踪进展，每周都会用上几次。说它不小，是因为我心里其实没底：我不知道 2026 年的工具生态里，有没有人为此做过专门的解决方案；也不知道如果有，水平到了哪一步。

如果你也是科研人员，应该对"让 AI 帮忙查文献"这件事有过类似的复杂感受。它看起来是 AI 最该擅长的事——理解我的问题、检索海量文献、提炼要点。但真正用过几次之后，就会发现并非如此：

你让它"找近 3 年关于某类药物和心血管结局的 RCT"，它给你写一段听起来挺像那么回事的综述，引用了五个文献编号。你顺手查第一个，发现编号根本不存在。

它倒是认真地列了文献，每条都有作者、年份、期刊，但年份对不上，期刊也错。

最隐蔽的是——编号是真的，论文也是真的，但论文里压根没说它声称的那个结论。

科研人员对这类问题的容忍度比一般用户低得多。因为我们写的东西最终会进入论文、基金申请，以及交到同行审稿人手里的稿子。一个编造的引用，轻则被审稿人挑出来打脸，重则被认为是学术不端。这绝不是"AI 偶尔会出错，凑合用一下"能敷衍过去的问题。

所以，真正要解决的核心问题，并不是"AI 能不能帮我查文献"，而是 "AI 在帮我查文献这件事上，能否从'差点意思'变成'严谨可信'" 。本文记录的，就是我和 AI 围绕这个问题展开的五轮对话，以及最终共同构建出的解决方案。

如果你不熟悉文中所提的"Skill"这个概念也没关系，它本质上就像一份给 AI 看的、"这类任务该怎么干"的标准作业流程。读完这篇文章，你不仅能理解它，还会知道如何在自己的科研工作流里用起来。第一轮：先看看有没有现成的

很多教程会跳过这一步，直接进入"我们来构建一个 X"。这其实是个被忽略的关键环节。任何协作都应该从"先搜一下"开始——不只是为了节省时间，更是为了校准你对这个领域的认知。如果已经有人为你的需求做好了工具，强行重造轮子就是浪费；如果没人做，这个空白本身就值得深思。

我让 AI 搜索了一圈。它扫遍了目前最大的 Skill 聚合目录，又做了几个针对性搜索。结果是：

通用目录里没有找到专门针对 PubMed 的。最相关的也只是一些科学计算工具。

但在社区中，搜到了三个专门做 PubMed 的 Skill：

一个属于"科研全家桶"中的一员

一个是独立的 PubMed 检索工具

另一个是面向医学研究全流程的，里面包含了文献检索

这就是所谓的"校准认知"——既不是"完全没人做过"，也不是"已经做好了"。三个候选方案都有，但似乎都不是为我量身打造的。这反而是个好消息：意味着这件事值得做（有人投入了精力），但还没做完（没有一个明显的赢家）。

做科研的人对这种感觉应该很熟悉：当你做完背景调研，发现这个方向"有人在做，但还没做透"时，正是动手的最佳时机。第二轮：把三个候选拆开看

光知道"有三个方案"没用，得真的去研读它们的内容。我让 AI 把这三个 Skill 的核心文件全部读完，然后做一个对比评估。

读完之后的发现很有意思——三个 Skill 的强项几乎完全正交。

第一个像一个《PubMed 检索教科书》。它把官方接口、所有字段标签、布尔逻辑、专业词表、检索模板，全部塞进了核心文件里。AI 学完，理论上能写出非常专业的查询语句。

第二个像一个生态位。PubMed 只是它一百多个科学数据库 Skill 中的一个，强项在于"这套调用模式可以无缝切换到其他生物信息学数据库"。如果你做的是跨数据库的工作，这是首选。

第三个像一个严谨到有洁癖的研究员做的工具。它对检索语法本身没那么在意，却死磕一件事：AI 引用的文献必须真实存在，且摘要真支持它说的话。它有专门的验证流程，能输出明确的审计状态：已验证 / 元数据不匹配 / 未找到 / 已编造。

这一刻我意识到一件重要的事：这三个 Skill，在解决完全不同的问题。

第一个解决"AI 不会用 PubMed 的高级语法"

第二个解决"我需要在多个生物数据库之间切换"

第三个解决"AI 会编造文献"

对一个科研人员来说，这三件事都是真问题，但严重程度完全不一样。

最致命的是第三个。一个查不到结果的 AI 是没用的 AI，但一个会编造结果的 AI 是危险的 AI。我可以容忍一个不够专业的检索工具——大不了我自己再去网页上核实一下；但我绝不能容忍一个可能让我把虚假引用写进论文的工具。

这个认知非常关键：在科研场景里，"防幻觉"比"查得好"更基础。如果幻觉问题没解决，查得越好反而越危险——给你列出 100 篇看起来完美无瑕的文献，里面掺杂着 10 篇编造的，比只给你 10 篇全对的要糟糕得多。

那么，直接选第三个不就完了？我确实考虑过，但它绑定了一个固定的医学研究流程。它假设你在写特定结构的临床论文，假设你要检查某些特定的报告规范，假设你最后会用特定的统计软件做分析。这些假设对一个放射科医师做诊断准确性研究是对的，但对一个研究分子生物学的科学家来说就是负担。

于是，问题演变成了第三个：能不能把三个 Skill 各自的闪光点融合起来，构建一个纯检索 + 强溯源 + 不绑定具体场景的新 Skill？第三轮：架构决策——融合不是大锅烩

我跟 AI 说："集大家之所长，构建一个全新的围绕 PubMed 的 Skill。"

AI 在动手之前，先停下来问了我四个问题。这是它做对的事——融合三个设计哲学冲突的 Skill，不是简单地把代码复制粘贴拼起来。三个 Skill 在四个关键决策上相互矛盾。

融合时这些关键点必须做出明确选择，否则就是一锅乱炖。AI 问我的四个问题，正好对应这四个分叉：

你主要在哪个环境用？ —— 决定 Skill 假设有什么工具可用

你的主要使用场景是？ —— 决定要不要绑定医学

防幻觉做到哪一层？ —— 决定验证层投入多少资源

执行代码这件事，你的环境支持吗？ —— 决定执行策略

我的回答是：命令行环境 + 场景不固定 + 摘要级溯源（成本高但可靠） + 让 Skill 自己灵活降级。

这四个答案合在一起，勾勒出一个相当具体的设计蓝图：

一个纯粹的检索工具，不绑定特定科研场景

能使用真实的文件系统做缓存

不止验证文献编号真假，还要能回答"AI 引用某文献时说的论点，原文真的说了吗"

自适应：发现专业工具就用，发现只有基础命令就降级，什么都没有就使用最基础的功能兜底

请注意，"摘要级溯源"这一条会强制要求另一件事：必须有摘要缓存。因为每次验证都重新去网上抓摘要，成本和速度都难以接受。这是个推导出来的需求，我一开始没意识到，AI 在设计时把它明确提了出来。

这种"由一个需求推导出另一个需求"的过程，正是设计科研工作流时最容易丢失的环节。你提了需求 A，落地时还需要支撑设施 B 才能让 A 成立。让 AI 在动手之前先把这些理清楚，比写完一堆代码才发现 B 没做要省事得多。第四轮：被密钥事件打断的那一刻

设计定下来之后，我犯了个错。我把自己的一个数据库访问密钥贴在了对话里。

AI 没有顺势接收并使用，而是停了下来，告诉我：

这个密钥现在已经留在了对话历史里

虽然它不算最高级别的机密，但配额绑定在我账号下，泄露后可能被滥用

建议我立刻去后台作废这个密钥，重新生成一个

新密钥不要再贴给它，放进本地环境变量

它不会使用我刚才贴的这个密钥

这件事值得记下来。让 AI 在关键时刻抵抗"用户给了就用"的诱惑，是工程化 AI 协作里最难、也最重要的能力之一。它本可以"配合"我，假装没看到风险，直接拿密钥去写代码。但它选择了打断。

后来我说"我不喜欢把密钥放到系统文件里"。AI 没有强迫我接受它最初的方案，而是重新给了我几个选项，并清晰解释了每个方案的利弊。我选了最平衡的那个。这套方案的精髓在于：完全不污染你的系统配置，想删除的时候一个命令就彻底消失，不留痕迹。

我把这件事单独拿出来讲，是因为它是科研人员日常容易忽略的工程素养之一。我们习惯把"能跑就行"当成标准，但当 AI 工具开始接管真实凭据、真实数据、真实产出时，"能跑"只是起点，"安全可靠"才是底线。第五轮：动手交付

四个问题确认完毕、密钥问题妥善处理后，AI 开始工作。最终交付的是一套清晰的三层结构：

L1 检索层：教会 AI 写出专业的 PubMed 查询。它继承了第一个 Skill 的精华，但设计成了渐进式加载——简单查询无需加载厚重的参考文档，复杂查询时才调取语法大全和模板库。

L2 抓取与缓存层：真正去数据库抓取数据，并将结果永久缓存在本地。每条文献一个独立文件，包含标题、作者、年份、期刊、摘要全文、关键词、文献标识符等。重复查询不再联网，这是让"摘要级溯源"在成本上可行的前提。

L3 溯源验证层：具备两种模式。

文献核对模式：给一个文献列表，逐条核对数据库，输出审计报告。状态清晰分为：已验证 / 元数据不匹配 / 未找到 / 已编造。这一层借鉴了第三个 Skill 的设计。

声明验证模式：给一个文献编号和一段声称该论文支持的话，判断摘要是否真支持。这是我们新加入的。它通过关键词重叠匹配和数字集合匹配来工作。如果声明里有数字而摘要里完全没有，会自动判为不支持——这是抓"数据编造"的有效信号。

最终输出三档结果：支持 / 弱支持 / 不支持，并总是附上摘要原文让用户自己判断。AI 在实现这一部分时特别强调：

"启发式验证不等于人类判断。这一层能抓住明显的捏造和明显的不匹配。它无法捕捉到那些微妙地扭曲了结论的声明。对于高利害关系的写作（如发表论文、基金申请），请务必让用户亲自阅读任何弱支持以上声明的摘要原文。"

这种"清楚知道自己几斤几两"的设计哲学，是衡量 AI 工具好坏的分水岭。不清楚自己边界的工具最危险——它会让用户产生"我已经用工具验证过了"的虚假安全感。

在交付前，我们用构造的假数据做了测试，其中一个测试用例没有完全达到预期，原因是数字匹配采用了集合算法，导致了巧合的命中。我们没有掩盖这个问题，而是把它写进了工具的已知局限性部分，并注明："对于高利害关系的数字声明，请务必阅读摘要原文。"

坦然承认局限，本身就是工具质量的一部分。这一点科研人员应该特别能理解——一篇论文的局限性部分写得越诚实，整篇论文就越可信。AI 工具同理。退一步：这件事告诉我们什么

如果你只关心这个工具的下载和使用，到这里就够了。

但我想请你跟我一起退一步，看看这个过程真正在示范什么。这是一系列方法论上的判断——它们和 PubMed 无关，却和你做任何 AI 协作都有关。一、"先看看有什么"比"马上开始构建"重要得多

我们这一代研究者很容易跳过文献综述直接动手，AI 时代这个毛病会更严重，因为构建的门槛降低了。但门槛降低不等于必要性降低。如果没有第一轮彻底的市场扫描，我可能会做出一个并不比现有方案更好的工具，浪费两天时间还不知道。

具体怎么做？让 AI 在动手前先去主流聚合目录和社区里做关键词组合搜索，最后真的去读完一两个候选方案的源代码——而不是只停留在项目简介。二、对比评估不是罗列功能，是看清"它们各自在解决什么问题"

我让 AI 做候选评估时，它一开始想列一张大表格——功能 A、功能 B、活跃度、受欢迎程度……我让它换个角度：别看功能，看"它们各自把哪件事当作核心矛盾"。

这一换视角，立刻看出三个方案是正交的而不是重叠的。这对融合策略至关重要——如果它们是重叠的，融合就是挑一个最好的；如果是正交的，融合是把它们叠加起来。

这件事在你做工具选型时几乎永远适用。两个看起来在解决相同问题的工具，它们的核心矛盾可能完全不同——一个在优化速度，一个在优化正确性。看清这点比看评测榜单重要得多。三、"先回答关键问题，再动手"

AI 接到"构建一个全新的 PubMed Skill"的请求后，没有立刻开始写代码，而是问了我几个针对性问题。这是 AI 协作里最容易被低估的一步。

这几个问题在结构上是最小信息集——少一个，最终的 Skill 就会有一个隐含假设；多一个，就是在浪费用户的时间。决定最小信息集是个技术活，它要求提问者真的理解候选方案之间的分叉点在哪里。

这件事的反面是：很多 AI 工具一上来就让你"详细描述你的需求"，结果你说了半天，它还是按它的默认假设干。好的提问不是"详细描述需求"，而是"在 A 和 B 之间你选哪个"——把决策权明确地还给用户。四、防御性设计比功能性设计更重要

回到密钥那件事。AI 完全可以接住我的密钥直接用，但它选择中断流程、解释风险、给出替代方案。这种"在用户犯错时主动刹车"的能力，是衡量一个 AI 系统是否真的为你着想的关键指标。

在设计你自己的 AI 工具时，请把"防误用"写进工具的核心指导原则里。一句明确的硬约束禁令，是成本最低的安全护栏。五、"知道自己几斤几两"的工具最值得信赖

在声明验证那一层，我们没有用大语言模型来做，而是用了关键词重叠加数字集合匹配这种朴素方法。这肯定不如让一个顶尖 AI 来读摘要做语义判断精准，但它有两个好处：

离线、确定性、可解释：用户可以看到具体哪些关键词命中、哪些数字命中

诚实地知道自己会失败：我们在多处明确告诉用户"这是启发式，不是证明，弱支持的意思就是请你自己去读摘要"

我见过太多 AI 工具的反面例子：背后是一个并不那么可靠的模型，但界面上却用一个绿色对勾告诉你"已验证通过"。这种"虚假的确定感"比工具能力本身的不足更危险。

希望你做工具时始终记得：一个会说"我不确定，请你自己核实"的 AI 工具，远比一个永远自信满满的 AI 工具要好。给科研人员的具体建议

如果你看完想试试这个 Skill：

花几分钟去官网申请一个免费的 API key

装好它，按照说明配置好密钥文件，运行自检脚本

用你最近一次真实的检索需求去测试它，比如"过去 3 年关于 X 的 RCT"

最关键的一步：用它去验证一下 AI 上次给你写的那段综述里的文献编号——你会获得比看任何测评都更直观的感受

如果你看完想构建自己的 Skill：

先做市场扫描，至少读完几个候选方案

用"它们各自在解决什么问题"而不是"它们有哪些功能"来做对比

在动手前列出关键决策点，逐个和用户确认

把防误用和承认局限写进 Skill 的核心指导文件里

如果你看完只想理解发生了什么：

Skill 不是一个 AI 工具，它是一种把"专业作业流程"灌输给 AI 的方式。任何你每周都做几次的、有明确步骤的、对正确性有要求的工作流，都值得做成 Skill。文献检索是这样，数据清洗是这样，实验记录整理也是这样。

这一代 AI 的核心瓶颈，正在从"模型能不能做"转向"我们能不能告诉模型该怎么做"。Skill，正是这个转向中一种非常具体、非常工程化的解决方案。