用原生 JS 与 PHP 搭建站内知识助手

网站聊天机器人最让人头疼的，是它把营业时间、服务范围和政策答错，还表现得很有把握。HeshBot 作者给出的方案很克制：用自己的网站内容建立知识文件，让助手据此回答，找不到依据就承认不知道，并引导访客联系真人。

这套实现用原生 JavaScript、一个 PHP 7.4 接口和 Python 构建脚本串起流程，适合拿来理解小型网站助手的基本结构。不过，「要求模型只按资料回答」和「确保它不会编造」，中间还有需要验证的距离。

一个小型网站助手，需要哪些部件

HeshBot 的前端只有聊天按钮和面板，使用原生 JavaScript，没有框架，也没有接入第三方聊天平台。它负责展示交互，把问题发送到自有托管环境中的一个接口。

后端是单个 PHP 7.4 端点，运行在普通共享主机上。处理流程也很直接：接收问题，补充网站内容作为上下文，调用模型，再把答案返回给前端。

这个拆分对前端开发者很有参考价值。聊天面板负责交互，服务器负责访问模型和处理资料，不需要先搭一整套复杂系统。

API key 留在服务器上，并存放于 Web 根目录之外，也就是浏览器无法通过网站路径直接访问的位置。模型调用需要的密钥，不应该随前端代码一起发给访客。

网站内容怎样变成回答依据

作者用 Python 构建脚本读取网站公开页面，再将内容整理成知识文件。网站更新后，重新执行脚本，助手使用的资料也随之更新。

知识文件可以理解为给助手准备的一份站内参考资料。它的价值不只是让模型知道网站提供什么服务，还在于划定回答范围：

• 文件中有依据，才回答。
• 文件中没有答案，就明确说明。
• 无法回答时，提供联系方式，让访客继续找人确认。

这里容易忽略的是更新流程。模型不会因为网页改了就自动获得新内容。按照作者描述，必须重新运行构建脚本；原文没有说明这个动作是否已经接入部署流水线。

另外，原文只说接口会加入合适的上下文，没有交代如何检索、如何切分文档，也没有说明是整份文件传入，还是只选取相关片段。因此，不能直接把它当成一套已经说明完整的检索增强生成（RAG）方案。

模型可以替换，公开接口必须设限

HeshBot 使用作者自行构建和微调的 HeshLLM:20B。作者也承认，其他项目可能更适合使用托管的前沿 LLM API。

他的主张是：让回答有内容依据，比单纯追求模型规模更重要。对营业时间、服务介绍这类问题，这个方向合理，因为模型再大，也不能代替网站提供准确资料。

但作者进一步提出，有充分内容约束的微调模型，胜过允许自由编造的大模型。这是经验判断。原文没有提供对照测试、准确率或错误样本，不能据此得出普遍的性能结论。

公开聊天框还会带来接口滥用问题。HeshBot 设置了按 IP 限流、消息长度上限、对话规模上限，以及同源检查，避免其他网站借用接口；API key 则继续保存在 Web 根目录之外。

作者将这些设计归因于 25+ 年技术支持经历和 Google Cybersecurity 证书培训。不过，原文没有公开具体阈值，也没有提供安全测试结果。

我的判断

最值得借鉴的是它把任务收得很窄：回答站内服务和项目信息，资料不足就交给真人。相比让通用聊天机器人自由回答，这样更容易检查答案，也更容易确定哪些问题不该答。

需要打问号的是「只根据知识文件回答，所以不会编造」这个推论。提示规则提供了约束，但原文没有展示程序如何核验答案，也没有给出面对诱导提问时的测试结果。内容有依据是必要条件，回答是否守住依据仍需测试。

同源检查也有边界。它可以作为限制其他网页调用的措施，却不能单独承担接口鉴权；直接请求接口的脚本仍需要限流等措施约束。

技术选型则要看现有环境。原生 JavaScript 加单个 PHP 接口适合作者的共享主机场景；已有 Node 后端的团队可以沿用职责划分，不必为了复刻案例更换语言。代码以 MIT 许可证开源，便于参考，但原文没有交代成本、延迟和维护负担，尚不足以判断它是否适合更大规模的网站。

能拿来做什么

• 给现有网站做助手时，先限定它能回答的问题，例如服务范围、项目介绍和 FAQ，再整理对应资料与无法回答时的联系入口。
• 将知识文件生成加入网站发布流程，至少明确网页更新后由谁执行脚本，避免页面已经改动，助手仍引用旧政策。
• 无论后端使用 PHP 还是 Node，都把模型调用和 API key 留在服务器，并为公开接口设置请求频率、消息长度和对话规模限制。
• 上线前准备一组能查到答案、资料缺失和诱导编造的问题，分别检查回答是否准确、是否承认不知道，以及是否提供正确的联系方式。