手搓 AI 助手,难不难?

网站或应用内容做得再全，也有两个绕不开的问题。

一是浏览和查找有成本。信息再多，也得访客自己一页页翻，翻不到就走了。

二是内容是固定的。每个访客的问题不一样，"你们这个适不适合我这种情况"，这种个性化的问题，静态页面答不了。

所以很多网站或应用都需要一个智能助手，提升用户使用效率。

智能助手怎么搭建？难不难？

刚好，我最近给一个网站加了一个，从动手到上线一天。索性写一篇搭建说明。

思路

整个事情拆成四块：设计、技术、知识库、实现。

设计定理念和功能，上面已经说了。

剩下三块逐一讲，其中知识库是重点。

技术

两条路：自己实现，或者借助开源工具。

自己实现，要做对话管理、知识检索、模型调度，变量太多。如果不是要做专业的客服系统，没必要。

开源工具里可以选 FastGPT^[1]：一个开源的 AI 应用搭建平台，能创建智能助手、建知识库、编排工作流，最后通过 API 访问。它支持 docker^[2] 自己部署，数据都在自己手里。

选型的判断标准只有一句：先想清楚自己要做到什么程度，变量越少越好。 只是给网站多一个能答问题的入口，选一个成熟工具接上去就是最优解。

知识库

助手会不会胡说八道，不取决于模型多聪明，取决于你喂了它什么、许它说什么。分三层。

第一层，整理知识库。

把网站上的知识、信息、示例梳理一遍，按主题整理成文字文档。以官网为例，可以分成：产品与理念、价格与套餐、隐私与数据安全、功能与使用、合作方式，外加一份图片索引（告诉助手什么场景可以引用哪张图）。

一个原则：只放对外公开的口径，内部资料不要进知识库。这些文档是助手唯一能依据的材料。

整理好导入 FastGPT，它会学习并构建好可用的知识库。

第二层，嵌进工作流，划好边界。

不是把知识库直接挂到助手上就完事，而是嵌进一个工作流：访客的问题先进一个"问题分类"节点，迅速判断在不在服务范围内——

• 在范围内：检索知识库，组织回答；
• 超出范围：不进后续环节，直接给一条固定的婉拒回复。这一步几乎不消耗 token，闲聊、算命、让帮忙写代码的，都被这一句挡回去。

分类的取向建议是"宁放过、不错杀"：拿不准的一律算在范围内，反正后面还有知识库把关。

第三层，写死"不许编"。

在助手的回答规则里明确：知识库命中的，按知识库的口径答；没命中的，不许编，老实说"这个我答不好"，然后引导联系真人。

这三层做完，助手才从"能聊天"变成"能上岗"。最终对外暴露的，就是这个工作流的 API。

实现

前端不复杂，一个浮窗组件加一次 API 调用。

但有三个硬要求：

1. 浮动的
   ：助手固定在页面角落，页面怎么滚它都在；
2. 切换页面不重置
   ：翻页不能打断对话。单页应用把助手挂在路由外层即可，再把会话状态存一份到会话级存储里，双保险；
3. 回复里的链接要可用
   ：助手回复里带的链接不能是死文字。站内链接点击后站内跳转、不新开窗口（新开窗助手就被打断了），站外链接才新标签打开；图片路径要直接渲染成图片。

然后是安全：调 AI 的 apikey 不能泄漏，哪怕是 FastGPT 创建的应用的 apikey。

而写在前端就等于把 apikey 公开了。

推荐两种做法：

一是加一个后端。 前端请求自己的后端，由后端带着 key 去调 FastGPT。网站本来就有后端的，加一个转发接口即可——用 FastAPI^[3] 这类工具，几十行就能搞定，顺手还能做访问限频。

二是用 nginx^[4] 转发。 纯静态网站、不想为这事加后端的，nginx 一个配置就能解决：转发请求时用 proxy_set_header^[5] 把 key 注进请求头，访客全程接触不到 key；还可以再加一层校验，要求访客请求带一个自定义暗号，不带就拒绝：

location/api/assistant/chat{# 校验访客暗号，不带就拒绝（可选）    if($http_x_access_key!="你的暗号"){return403;}# 真正的 key 由 nginx 注入，访客接触不到    proxy_set_headerAuthorization"Bearerfastgpt-你的key";proxy_set_headerContent-Typeapplication/json;proxy_passhttp://127.0.0.1:3000/api/v1/chat/completions;}

前端只管请求自己的 /api/assistant/chat，key 和暗号都在 nginx 这一层。

做法不同，核心思想一样：key 永远不出服务端。

AI 助力

上面这些，大部分活儿都可以交给 AI 干。

前端浮窗组件，把设计要求说清楚，AI 直接生成；三个硬要求提出来，它都能落实。

知识库整理也可以借助 AI：把网站现有的页面内容喂给它，让它按主题整理成结构化的知识库文档，你再校对口径。

甚至 FastGPT 的工作流怎么编、分类和回答的提示词怎么写，都可以先让 AI 起草，你再按实际效果调整。

真实分工变成了：AI 负责执行，我们只做两件事——说清楚要什么，最后验收。

这是我能一天上线智能助手的主要原因。

我的实践

FastGPT 是早前因为需要 AI 分析能力和复杂工作流就部署好的，开发助手时顺手用了。

当然，一天上线不等于一次到位，实测中抓到几个典型问题：

• 助手回复图片时只回了路径文字、不显示图
• 回复的链接是纯文本、点不动
• 早期版本没有范围拦截，问什么它都敢聊

前两个靠前端渲染处理解决，第三个就是"问题分类"节点的由来。

这几个坑的共同点：AI 侧的问题，最后靠工程手段兜住。 规则写了不等于它会执行，关键约束要在代码层有机械兜底。

另外这事没有"做完"的时候，因为系统在演进、访客的提问在变化等等，后续补充和优化必不可少。上线只是开始。

落地锦囊

给网站加 AI 助手，顺序别搞反：先整理知识库、划清边界，再谈技术实现——技术选型是整件事里最不重要的决定。

两条红线：

• API key 永远不出服务端
• 知识库没命中的问题，宁可答不上，不许编

还有一条的话，就是，别自己硬扛，从写代码到整理知识库，多让 AI 干活。

留言聊聊：如果给你的网站装一个 AI 助手，你最怕它胡说哪句话？

我在接 AI 应用落地的顾问和小型开发委托，有具体问题可以留言或私信聊。

飞说落地，AI 应用的最后一公里。