用代码与账户数据构建智能客服

用户问「为什么我的图表是空的」，客服机器人只检索到一篇图表使用说明，往往解决不了问题。ai-track.app 的作者换了一条路：从代码提炼产品规则，再查询提问用户的真实账户状态，让模型解释眼前这件事。

这套 Laravel SaaS 客服系统不依赖帮助文章库，也没有向量数据库。它的价值在于把规则和账户数据放到一起；它最需要验证的地方，则是模型给自己的「高置信度」究竟有多可靠。

回答具体问题，先把规则和账户状态凑齐

作者认为，常见的文档检索客服有两个限制：没写进帮助中心的事情无法回答，产品更新后文档又可能落后。用户描述的是自己的处境，也未必使用文档里的标准术语。

他们的做法是在调用 LLM API 前，准备三类信息。

第一类是从代码库提炼的产品摘要，放进系统提示词。它不只是功能介绍，还包括代码中的具体规则：图表需要积累 3 天数据，提示任务每天运行一次，工单闲置 5 天自动关闭，以及使用哪个支付服务、设置入口在哪里。作者使用 AI 编程工具阅读代码并维护摘要，产品变化后重新生成。

第二类是当前用户的账户上下文。服务端查询用户所属组织、已有配置、创建的资源、资源启用时长，以及近期是否发生错误。模型因此有机会把「图表需要 3 天数据」和「这个资源刚启用」联系起来，而不是重复操作说明。这个例子是在解释机制，原文没有展示具体工单及其实际回答。

第三类是工单附带的环境信息。客服组件自动记录用户所在页面、浏览器、操作系统和视口尺寸，让「页面坏了」至少带上发生位置和设备线索。

回答的针对性，来自产品规则与用户状态的交叉，而不只是检索命中了哪些词。

不过，代码摘要仍然是一份经过压缩的材料。作者说它容易重新生成，这能降低维护成本，却不能直接证明摘要始终完整、准确。

自动回复的关键，是哪些工单必须交给人

模型收到工单和上下文后，需要返回结构化结果：一份回复，加上 high、medium 或 low 三档置信度。只有 high 才会发布，另外两档丢弃生成内容，转入人工队列。

作者还设置了明确的拒答范围。具体账单问题、存在歧义的问题、需要进一步调查的问题，都应返回低置信度；提示词同时禁止编造功能和承诺时间表。

这套规则的方向是合理的：不能因为模型能写出一段顺畅解释，就允许它代表产品作答。

但「模型说自己有把握」和「答案已经验证」是两回事。原文声称不会有猜测答案到达客户，却没有给出自动回复准确率、错误案例、置信度校准结果，或人工抽检数据。结构化输出方便程序判断和审计，并不能自动保证模型遵守所有约束。

人工接管也体现在工单流程里。自动回复通过真实管理员账号发到正常会话中，工单进入反馈状态，而不是直接关闭；用户继续回复，就能联系到人。这个设计保留了纠错入口。不过，原文没说是否明确标注 AI 回复，通过管理员账号发送也不等于经过人工审核。

实现很轻，难点藏在上下文选择里

按作者描述，Laravel 侧主要是一个服务类、一处 LLM API 集成，以及几段围绕工单的处理逻辑：查询账户状态、组装提示词、请求结构化结果、判断置信度、发布回复并切换状态。

作者把它概括为约 300 行代码，并称单张工单的模型费用不到 1 美分。这里没有提供模型名称、输入长度、调用次数或成本测算，因此这些描述只能说明作者项目里的实现规模，不能直接作为其他团队的预算。

它省掉了向量数据库、embedding 流水线和帮助中心迁移。产品更新时，重新生成摘要，也不需要重新训练模型。但工程工作并没有消失，而是集中到了三个判断上：哪些规则必须进入摘要，哪些账户字段足以解释问题，哪些情形必须拒答。

数据范围也要由服务端控制。作者表示，每次只提供当前工单用户自己的数据，不跨租户，也不把内容持久化用于训练。前两项可以通过应用权限和查询范围约束；训练数据如何处理，还取决于实际使用的 API 服务及其配置，原文没有展开。

我的判断

我赞同把账户状态加入客服上下文。对于「为什么没有数据」「为什么功能还没生效」这类问题，只有通用说明通常不够，资源年龄、配置状态和错误记录更接近答案。

但作者把文档检索的缺点说得过于绝对。代码能描述实现，却未必包含完整的服务政策、人工处理约定和对外承诺。代码摘要也可能漏掉条件分支，或者没有及时跟上已部署版本。把它称为始终完整、始终最新的事实来源，需要额外的更新机制来支撑。

文档检索和账户查询也不必二选一：前者适合提供经过审核的通用说明，后者适合解释用户的当前状态。哪个更好，要看工单类型，作者没有给出对照数据。

这是一套值得试验的客服架构，还不是经过数据证明的零错误方案。

真正决定能否上线的，应是历史工单上的表现，以及自动发布后能否发现和纠正错误，而不只是提示词写得多严。

能拿来做什么

• 如果你负责 SaaS 的前端客服入口，可以先补齐页面地址、浏览器、操作系统和视口信息，让人工客服和模型都能更快定位问题。
• 如果后端使用 Node，可以沿用同样的分工：服务端按当前用户权限查询必要账户字段，再将产品规则和工单组装成上下文。隔离范围应在查询层落实。
• 先选规则明确、能从账户状态解释的工单做试验，用历史工单核对答案和置信度，积累证据后再决定哪些回复可以自动发布。
• 让 AI 编程工具协助提炼产品摘要时，优先检查阈值、运行频率和状态转换，并把摘要更新纳入功能变更流程，避免维护出另一份过期说明。