记录一下这个五月最后一篇文章，后续慢慢的就换点别的博客内容记录了。
之前这套博客 AI 问答虽然已经能跑起来了，但实际用下来有一个问题一直很明显：
AI 知道这个站里有文章，却不一定真的知道用户此刻正停留在哪一页、正在看哪一段、是想问当前文章，还是想顺着专题继续追问。
这个问题在文章详情页里尤其明显。
有时候我明明就在一篇文章里面，点击预设 tips 去问 AI，总觉得它像是“看了全站一眼就开始回答”，回答内容并不总是贴着当前文章走。更典型一点的情况是：我在当前文章已经看到了某个技术点，继续追问一句“这里为什么这样设计”，AI 却没有稳定理解“这里”到底指的是哪一段、哪一节、哪一篇文章。
所以这次我继续把它往前推进了一步，不是简单再补几条提示词，而是把 博客前端上下文、用户交互意图、Cloudflare 侧检索范围、RAG 重排与回退逻辑 一起重新梳理了一遍，让这套问答真正更像博客的一部分，而不是挂在博客旁边的一个泛化聊天框。
之前的问题到底出在哪
如果只看表面，会觉得像是“模型不够聪明”。但实际拆开以后，会发现更多是上下文链路不完整。
旧版本大概是这样一条路径：
- 用户在页面里点击一个 tips，或者直接输入一句问题。
- 前端把这句自然语言发给 AI。
- Cloudflare RAG 再根据这句自然语言自己猜：用户现在到底想问当前文章、当前专题，还是全站内容。
这套方式不是完全不能用，但它有两个天然短板。
第一，前端明明知道用户在哪，但没有把这个信息完整、稳定、结构化地传给后端。
第二，后端虽然有知识库，但如果没有明确的作用域提示，就只能靠自然语言去猜。
一旦问题本身比较短，比如：
- “帮我总结一下”
- “这个方案有什么限制”
- “这里为什么不用另一种做法”
- “和之前那篇有什么关系”
那它就很容易丢失“当前页面”这个最关键的语义锚点。
这次优化的核心思路
这次我没有去大改知识库主结构，也没有推倒重建 Cloudflare 侧的数据模型，而是继续沿着已有的博客系统往里深挖：让博客前端主动告诉 RAG，用户现在在哪里、在做什么、应该优先查哪里。
也就是说，原来更像：
用户提一个问题，RAG 自己猜上下文。
现在更像：
博客先把当前页面上下文和提问意图整理好，再把“问题 + 页面位置 + 检索范围”一起交给 RAG。
这样一来，AI 的回答就不再只是“会不会搜”，而是“先去哪里搜、优先回答什么、如果当前文章命中不够再怎么往外扩”。
博客前端这边补了什么
前端现在不再只给 AI 发一条裸问题，而是增加了一层更明确的结构化提问意图。
比如在文章详情页里，用户点的是“帮我总结这篇文章”，和在搜索结果里点“问问小Y关于这个结果”，这两者虽然最终都会进入同一个 AI 对话框，但它们背后的意图其实完全不一样。
所以现在前端会把这些信息一并发出去：
- 当前问题本身
- 问题来源
- 当前页面类型
- 当前文章
postId/slug - 当前专题
topicId/topicName - 当前分类和标签
- 如果是划词提问，还会带上选中文本、所在小节、锚点位置
- 如果是搜索结果追问，还会带上命中的结果文章信息
这一步非常关键，因为它让“AI 在当前页面提问”从一种模糊的 UI 体验，变成了一种可以被后端明确消费的结构化信号。
Cloudflare RAG 侧怎么配合
有了前端补过来的上下文之后，Cloudflare 侧就不再需要从头猜测，而是可以按页面类型来走不同的检索策略。
现在的整体思路是分层作用域检索。
最典型的文章详情页场景，会按这样的顺序来查：
- 先查当前文章
- 当前文章命中不够，再查当前专题
- 还不够，再扩展到全站
如果是划词提问，则会更进一步：
- 先查当前文章里的当前小节
- 再回到当前文章整体
- 再扩展到当前专题
- 最后才是全站补充
这样做的好处是，AI 回答的“第一落点”更稳定了。它会先尽量围绕当前阅读上下文回答，而不是一上来就把全站相关内容混在一起。
为什么这一步能明显改善“AI 不知道用户在问什么”
因为之前丢掉的，恰恰就是“用户此刻正在这个页面里问这个问题”这层语义。
现在这层语义是被显式传递的。
换句话说，以前 AI 面对的是：
- 一句问题
- 一整个知识库
现在 AI 面对的是：
- 一句问题
- 当前页面上下文
- 当前文章 / 专题 / 分类 / 标签信息
- 当前提问动作类型
- 一个明确的优先检索范围
它不是突然变聪明了，而是终于把它原本应该知道的信息稳定交给它了。
用一张图看旧链路的问题
这条链路的问题不在“完全搜不到”，而在于搜得到，但不一定搜得准，也不一定先搜当前页面。
再看优化后的新链路
可以看到，这次不是只改了前端，也不是只改了后端，而是把这两边真正串起来了。
预设 tips 也不是简单换个文案
以前很多 tips 本质上只是几句看起来更友好的提示词，比如“帮我总结一下”“解释一下这篇文章”“还有什么相关文章可以看”。
这些文字本身当然没问题，但如果后面仍然只当成普通文本处理，那么它们并不会天然带来更强的上下文理解。
所以这次我更关心的不是 tips 写什么，而是tips 背后对应的动作到底是什么。
现在它们会被拆成更具体的结构化动作，例如：
- 总结当前文章
- 提炼当前文章里的流程
- 解释当前文章关键点
- 延展到当前专题
- 从当前文章继续推荐全站阅读路径
这样 AI 收到的就不只是“一个句子”，而是“一个带有明确意图和作用域的动作请求”。
专题、分类、标签这些为什么也要一起打通
因为博客问答不只是文章内答疑，它还天然带着一点“站内导览”的属性。
用户在专题页里提问，和在文章详情页里提问，其实是两种不同需求：
- 前者更像“这个专题里有什么主线、我该先看哪些内容”
- 后者更像“当前这篇文章具体在讲什么，这一段又是什么意思”
如果这两种场景都只用同一套泛化问答策略去处理，AI 的导览能力就会很弱。
所以这次我也把：
- 首页
- archive
- 专题页
- 分类页
- 标签页
- 搜索结果页
都一起纳入了页面级上下文体系里。
这意味着 AI 不只是一个“回答器”，它开始更像一个真正懂站内结构的博客助手。
这次优化以后，实际体验上最大的变化
主要变化有三点。
第一，文章页里的提问更容易先回答当前文章本身。
不会像之前那样，一些本来很明显应该围绕当前文章回答的问题，却偏到全站泛化说明上去。
第二，当当前文章信息不够时，扩展也更自然。
现在它会更倾向于先说明“当前文章直接命中的信息有限”，再补专题或全站内容，而不是直接突然开始泛讲。
第三，搜索结果追问和划词提问终于更像同一个系统里的自然动作了。
用户并不需要理解底层是怎么检索的，但会明显感觉到：自己在什么位置发起问题，AI 就更像是在那个位置继续接话。
这套方案的取舍
这次我没有重建 Cloudflare 知识库，也没有大改文章入库主模型。
原因很简单：现有数据结构本身并不是完全不够用，真正缺的是前端上下文到后端检索策略之间那一层稳定映射。
所以相比“重做一套更大的系统”，我更想先把这套博客已有能力真正打磨顺。
也正因为这样，这次优化更像是一次深度融合，而不是一次“另起炉灶”的重构。
后面还可以继续往下做什么
这一步做完以后，博客 AI 已经明显比之前更知道“自己在哪、该怎么回答”。但如果继续往下走，我觉得还有几个方向可以继续挖。
比如：
- 继续增强跨文章关系图谱，让“相关文章补充”更稳定
- 在专题页里做更强的阅读路径推荐
- 给不同页面类型补更细的提问动作模板
- 让回答里的来源说明进一步区分“当前文章 / 当前专题 / 全站补充”
这些都不是必须一次做满的东西，但现在基础已经比之前稳了很多，后面继续加能力会更顺手。
最后
我一直觉得，博客里的 AI 问答如果只是“接个聊天框”，其实价值很有限。
真正有意思的地方，是让它变成博客系统的一部分，知道当前页面是什么、这篇文章属于哪个专题、用户现在到底在沿着什么路径阅读，以及这个问题应该先从哪一层内容开始回答。
这次做的，就是把这件事往前认真推进了一步。
从之前关注的“AI 能不能回答”，
现在慢慢变成：AI 能不能结合当前上下文，回答得更像这个博客自己的智能助手。
如果这篇文章对你有帮助，欢迎分享！
部分信息可能已经过时
