背景
我们的一个诊所部署项目,在消息渠道上处理患者的预约沟通。患者用自然语言留言——改约、疗程问题、“我可以改到周四下午过来吗”——由 AI 助理负责对话。诊所的排班表就放在诊所原本习惯的地方:一份由前台维护的共享电子表格,格子里的标记惯例是员工沿用多年的做法。
最直接的做法,是让模型自己读排班表,看到空档就直接约上。我们没有这样做,而不这样做的原因,正是这篇文章有价值的部分。
规则一:哪些时段可以预约,永远不由模型决定
诊所的排班表把政策藏在惯例里:某些时段专门保留给复诊和咨询,而且是用视觉标记呈现的,并不是数据库里的字段。新客疗程永远不该被排进这些时段。前台员工都知道这件事;读着表格的语言模型却不知道——它只看到一个空档。
所以我们最先上线的功能根本不是预约,而是一道硬性闸门:保留时段在结构上就对助理关闭。不是“用提示词叮嘱它避开”——是直接封死,由一段在模型之后、在任何动作触及排班表之前执行的代码强制把关。提示词可以被说服;纯函数不行。
一句话概括整个架构:LLM 负责提取,确定性代码负责决定。 模型非常擅长读懂“下周四三点以后都行,疗程和上次一样”,并产出结构化的意图:期望时段、疗程类型、患者身份。在那之后的一切,都是平凡、可测试的逻辑——时段分类、资格规则、时长计算——以基于数据的纯函数写成,配有单元测试,和其他代码一样经过评审。
安全藏在乏味的细节里
大部分工程精力,都花在演示永远不会展示的细节上:
- 疗程时长来自诊所自己的参照表。 每一个可预约的疗程都有准备时间和疗程时间,逐行与诊所的纸质参照表核对——包括那一轮我们找出并修复了十九处不一致的核对。助理不可能给出一个实际时长放不进去的时段。
- 签到时间是推导出来的,不是猜的。 准备时间决定患者应该几点到,确认消息会直接写明。模型少做一次判断,前台少一次意外。
- 电话号码以文本格式写入。 电子表格会毫不留情地吃掉以数字格式存储的电话号码开头的 0。小 bug,真实世界的后果,确定性的修复。
- 模棱两可的情况一律转人工。 当请求无法干净地通过闸门——少见的疗程组合、规则解不开的时段冲突、患者问到政策表没有覆盖的事——助理不会即兴发挥,而是把对话连同完整上下文一起交给人工。转接是功能,不是故障模式。
清单里的每一条判断规则之所以存在,都是因为诊所经营者做了一个决定,我们把这个决定写进代码,而这段代码从此可被审视。当经营者调整政策,我们改的是一个函数和它的测试——不是改一段提示词然后祈祷。
我们为什么这样做
这个项目有一个周末就能上线的版本:把排班表丢给一个足够强的模型,加一段系统提示词,让它自己约。演示会非常漂亮,而且大多数时候都能正常工作。问题恰恰出在“大多数时候”。诊所的排班表是对真实患者和真实员工的承诺;失败的样子,是诊疗室被重复预约,以及前台在第二次出问题之后就再也不信任这个工具。
我们采用的切分——模型负责理解、确定性闸门掌握决定权、闸门之外的一切转交人工——前期多花工程成本,换回的是提示词给不了的东西:预约逻辑在触及患者之前可以被测试、事后可以被审计,政策变化时只需要在一个地方修正。
这个模式不限于诊所。任何 AI 助理触及他人赖以运转的资源——日历、库存、账本——同一条界线都适用。让模型读,但别让它说了算。