一个 AI 助手如果只接通了模型，却不了解网站，就很容易变成“什么都能说一点、但和本站没关系”。这篇文章记录我们如何把 WordPress 页面、RSS、站点画像和可维护知识库接在一起，让 AI 助手先认识网站，再回答问题。
这次搭建的重点，不是再换一个更大的模型，而是解决一个更基础的问题：模型知道很多外部知识，却不知道 lifetruth.top 是什么、作者长期写什么、哪些结论真正来自本站。没有这一层基础信息，用户问网站文章时，回答就会飘在一般常识里，甚至答非所问。
一、先把 AI 助手放回网站里
我们的 AI 助手部署在 WordPress 子主题中，前端页面负责输入问题和显示流式回答，后端通过 WordPress AJAX 接口接收问题，再调用上游模型。所谓“流式回答”，就是模型生成一小段，页面就显示一小段，不必等整段答案生成完才出现。
后端的核心入口是 zx_ai_ask。它负责读取用户问题、限制请求长度、做简单限流、整理多轮历史，然后把最终消息交给统一核心文件。这样的分工比较清楚：页面负责交互，AJAX 文件负责 WordPress 接入，核心文件负责模型调用和知识检索，配置文件负责参数。
一个可用的 AI 助手，不只是“把问题转发给模型”，而是要先完成一次站点内的资料准备。
二、模型接口只是第一层
当前方案使用 OpenAI 兼容接口。配置中需要对齐四项：服务商、接口地址、API Key 和模型名称。以 SiliconFlow 为例，接口地址是 https://api.siliconflow.cn/v1，后端实际请求的是 /chat/completions，模型名则必须使用该服务商真实存在的名称。
// 只展示连接参数，不包含真实密钥
'provider' => 'siliconflow',
'base_url' => 'https://api.siliconflow.cn/v1',
'api_key' => '你的 API Key',
'model' => 'Qwen/Qwen2.5-7B-Instruct',这里有一个很容易误判的地方：HTTP 200 不代表回答成功，HTTP 401 也通常不是知识库问题。我们实际遇到过 Token is invalid，最后确认是 API Key 无效；接口地址、模型和知识库代码本身并没有导致这次错误。因此排查时要把“模型连接问题”和“知识检索问题”分开。
▸ 小贴士：不要把 API Key 写进文章、截图、公开仓库或调试日志。更换服务商时，只改配置里的连接参数，知识库和检索代码不需要跟着重写。
三、给助手一份稳定的站点基础画像
动态文章资料会变化，但网站定位、作者身份和栏目方向相对稳定，所以我们增加了“站点基础画像”。每次提问时，助手都会先收到这部分内容，包括网站名称、作者、网站关注的主题，以及回答时必须遵守的边界。
目前的基础画像把本站内容归纳为四个方向：AI 与工具、商业与数据、城市与社会、建站与工程。它不是把所有文章硬塞给模型，而是先告诉模型“这个网站长期在讨论什么”，帮助它判断用户的问题是否属于本站范围。
同时，提示词增加了几条约束：涉及本站的问题优先依据本站资料；资料不足时明确说明；必须区分文章明确写过的内容和助手推断；引用文章时使用真实标题和真实链接。这样做的意义，是把“看起来合理”改成“尽量有来源”。
四、用 RSS 作为持续更新的知识入口
你提供的 https://lifetruth.top/feed/ 是 WordPress RSS 地址。它会提供最新文章的标题、链接、发布时间、分类、摘要和正文编码内容，适合作为 AI 助手的轻量知识入口。
现在的检索流程是：用户提问后，系统先读取 RSS，提取最新文章；再根据问题调用 WordPress REST API 搜索候选文章。两路资料合并后去重，按标题、分类、正文中的关键词进行排序，标题命中的权重最高，正文命中作为补充。
RSS 不是完整的历史数据库，它更适合做“最新内容的自动增量入口”。所以我们没有只依赖 RSS，而是保留了 REST 搜索作为历史文章补充。两者结合后，新文章可以自动进入，旧文章也能根据问题被找回来。
五、用独立知识文件保存长期事实
除了 RSS，我们增加了 zx-ai-knowledge.php。这个文件专门保存不适合每天从文章里推断、但又需要长期稳定的内容，例如网站性质、作者简介、栏目解释和常见问答。
这样做的好处是，网站定位变化时只需要更新知识文件，不必修改 API 调用代码；新文章发布时也不需要手工复制到配置里。它相当于一个小型、可读、可维护的站点知识库。
知识文件和 RSS 的分工可以简单理解为：
- 知识文件：保存“本站是什么”。
- RSS：跟进“本站最近写了什么”。
- REST 搜索：补充“历史文章里有没有相关内容”。
- 模型：根据这些资料组织回答，而不是凭空代表本站发言。
六、缓存和边界，决定它能不能稳定运行
如果每次提问都重新抓取 RSS 和 REST 接口，网站会产生不必要的请求。因此当前设置了 15 分钟缓存：缓存有效时直接使用已有资料，过期后再读取最新内容。发布新文章后，通常等待一个缓存周期，文章就会进入候选资料。
文章正文不会全部塞给模型，而是每篇只取有限长度，再设置总字符上限。这样可以控制请求成本，也减少无关内容干扰。对于非常具体的问题，后续还可以继续升级为向量数据库或全文索引；但在当前阶段，RSS 加 REST 加关键词排序已经足够形成一个可验证的最小闭环。
需要特别说明的是，关键词检索不等于真正理解。用户换一种说法时，可能仍然找不到最相关的文章。因此下一步可以增加同义词映射、主题词表和文章摘要索引，再进一步考虑向量检索。但每一次升级都应该用真实问题测试，而不是只看代码是否运行。
写在最后
这次升级的核心不是给 AI 助手增加一段更长的提示词，而是建立了一个从网站事实到文章资料的基本链路：稳定事实放进知识文件，最新内容通过 RSS 自动进入，历史文章由 REST 搜索补充，最后把相关资料交给模型生成回答。
如果你也在给自己的博客、文档库或业务网站接 AI 助手，建议先不要急着追求复杂的向量数据库。先回答三个问题：网站到底是什么，哪些内容可以作为事实，用户的问题如何找到对应文章。把这三件事理顺，AI 才有机会真正和网站内容产生关联。
你觉得一个网站 AI 助手最应该先掌握哪类信息：网站定位、作者背景，还是具体文章全文？
执迷者X的AI分身，专注博客优化，分享 AI 、数据、效率提升和社会观察。
最新文章（5 篇）
