夜雨聆风遇到产品问题时，很少有人愿意从第一页开始读文档。因为大家通常带着一件具体的事而来：能不能只延长某个 track 的截稿时间？审稿人临时忙不过来，能否请自己的博士后协助评审？还有哪些录用论文没有作者完成注册？
这时，用户想要的不是一份“完整的产品说明”，而是一个能马上解决问题的答案。
PaperFox 有近百页使用文档，许多问题其实早已写得很清楚。真正的麻烦是：用户未必知道那一页叫什么。
你带着疑问而来，搜索框却只认识关键词
产品文档通常按照角色和功能分类。熟悉系统的人知道该去哪里找，新用户却很容易卡在第一步。
比如，用户想知道：
“怎样让审稿人把论文交给自己的博士后协助评审？”
相关页面的标题是 Delegating Reviews to Sub-Reviewers。
如果已经知道 PaperFox 把这种做法称为“Sub-Reviewer”，搜索并不困难。问题是，大多数人恰恰不知道这个词。他们只有一个来自真实工作场景的问题，却没有产品内部使用的标准术语。
传统搜索擅长匹配关键词，却不擅长理解这两种说法其实在问同一件事。于是便出现一个很常见的困境：必须先知道答案叫什么，才能找到解释答案的文档。
解决办法：用自己的话提问，得到有出处的答案
现在，PaperFox Docs 的每个页面右下角都有一个 Ask AI 入口。
用户可以按照自己的习惯提问，不必特意把问题改写成产品术语。PaperFox 的 AI 助手 Foxy 会搜索相关文档，整理出可以照着操作的步骤。这件事看起来只是把“搜索框”换成了“对话框”，实际改变的却是查找答案的方式。
以前，用户需要猜测关键词，在搜索结果中逐页排查，再把分散的信息拼成一套操作方法。现在，用户只需说清楚自己要做什么，剩下的查找和整理交给 Foxy。
不过，PaperFox 并不希望用户只看 AI 给出的结论。Foxy每次回答都会附上来源。点击相应链接，就能直接回到具体的文档页面，查看完整说明。对于会影响投稿、审稿、会议配置或邮件发送的重要操作，这一步尤其有必要。
AI 可以帮人少走弯路，但不应该让信息来源变得更模糊。
使用时，有三点需要留意：
第一，需要登录。Ask AI 按钮会出现在每个文档页面上，但向 Foxy 提问需要一个免费的 PaperFox 账户。
第二，这项功能免费。系统设有较为宽松的合理使用额度，主要是为了保证所有人的使用速度，并不会另外收费。
第三，重要信息仍要核对原文。Foxy 的回答以 PaperFox Docs 为依据，但它仍然是 AI。遇到会影响会议配置、投稿、审稿或通知发送的操作，最好点击引用链接，再看一遍对应的文档页面。
想了解原理：它是如何工作的？
下面聊一点实现原理。
让 AI 根据指定资料回答问题，常见的做法叫 RAG，也就是“检索增强生成”。简单来说，先从资料库里找出与问题有关的内容，再让模型根据这些内容组织答案。这样可以尽量把回答限制在文档范围内，而不是依赖模型记忆。
许多 RAG 系统会预先把文档切成小段，再将每一段转换成 embedding，存进向量数据库。用户提问时，系统找出语义上最接近的几个片段，交给模型回答。
Ask Foxy 走了另一条路。
PaperFox Docs 目前不到一百页，这个规模并不需要一套庞大的向量检索系统。Foxy 使用的是普通关键词索引，但搜索过程由模型自己掌控。收到问题后，它会先组织一组查询词，查看搜索结果。如果找到的内容不够准确，就换一种说法继续查，直到搜集到足够的信息，再整理成回答。这更接近人查资料的过程。第一次没搜到，并不意味着资料不存在，可能只是关键词不合适。换个说法、缩小范围、再查一次，往往就能找到答案。
技术上，这种方式属于 agentic RAG。它的关键不在于使用了多复杂的搜索工具，而在于模型能够根据搜索结果决定下一步：是直接回答，还是调整查询后继续寻找。
对 PaperFox 来说，这也是更合适的工程选择。
文档更新后，关键词索引可以随部署重新建立，不需要额外维护向量数据库，也没有 embedding 成本，更不会多出一条可能失去同步的数据链路。规模合适时，简单的工具加上合理的使用方式，往往比复杂架构更可靠。
试试看
打开 PaperFox Docs，登录后点击页面右下角的 Ask AI。把那个原本打算发邮件询问的问题直接交给 Foxy，然后看看它给出的答案，以及答案所依据的文档。
PaperFox docs链接：https://www.paperfox.ai/docs