早知早检健康私域 AI 服务助手

原来 AI 手里没有转人工按钮。它在回答里写「我帮你转人工」，再由代码从文字里猜它是不是真要转。10-04 线上真机出了事：用户问「我说的健康情况会被保存吗」，AI 答对了，最后一句「……的话，可以告诉我帮你转人工」却被代码当成要转，建了一张没人需要的工单。当天先补了一条规则止血（带「的话」的条件句不算）。

补完我问了一句：「这种修法是不是太写死固定了？有什么办法可以更灵活的吗？更 Agentic 的。」规则一直在追模型的说法：先是「的话」，再是问句，又是「转人工时」。10-05 用 17 句专门的问法量了一下线上版本：不该转的 50 次里误转了 12 次，该转的 30 次只转了 14 次。

于是定下新做法：要不要转，由 AI 判断；「转」这个动作，做成一个按钮；红线问题、查不到依据、超时这些必须转的，仍由代码直接转。规则版留着当对照组。开工前写好上线标准：不该转的 0 次误转；该转的每句 5 次至少转 4 次；该拦的照样拦；日常咨询的工具调用、举证不能掉。我的要求是：「评测预算不用担心，主要是评测充足和到位才是最重要的。」

1. 转人工变好了，日常回答却像是变差了。第一版：不该转的误转 0/50，该转的 24/30；但 30 道考题里的举证掉到 11/20（线上 16/20）。第二版按探针结果补了 7 条规矩，举证更低，9/20。
2. 最顺手的猜测是错的。第一反应是「新版少查了知识库」。专门做了 16 句知识库探针，每版跑 90 次：查知识库的比例线上 80%、新版 87%，新版并没有少查。
3. 评测本身会骗人。同一个线上版本，一天之内举证就在 14 到 16 题之间浮动；70% 的及格线正好落在它自己的平均附近。之前两次判「退步」，都只跑了一两轮，还拿去和隔天的线上比。
4. 修好一处，另一处又坏。修好回答长度之后，「我都问了三遍了还是不行」这句该转的，从 3/5 掉到 0/5。

第二版不上线。我的要求是：「不补旧规则，先查原因，一定要查清楚根因！」

• 换一把更灵敏的尺子。不看每题过没过，看每轮回答平均多少字、每条回答引了几个编号。线上每轮 237–255 字，新版 194–231 字，四轮全低于线上（置换检验 p=0.014）。原来不是不查，是答短了，答不全，举证就掉分。
• 一次只改一处，拆开测。只加转人工按钮、提示词不动：回答 206 字，和新版一样短。只改提示词、不加按钮：253 字，和线上一样长。根因是转人工按钮的说明里那句「reply 就是用户这一轮看到的全部回答，限 300 字」：模型把这个「简短收尾」的框框，带进了普通回答。
• 连评测方法一起改。比版本改成同一时段交替跑、每版至少 3 轮；新规则上线前，先拿历史上一千多条回答扫一遍，看会不会误伤。我提出「不用我每轮手动点」，评测后台加了「排队」，一组 7、8 轮的对照一次点完（登录口令仍由我本人输入）。
• 判据本身也会误判，就按统计理由改，并留痕。第四版的结果暴露出两条判据的毛病：「3 轮平均不低于线上」，一个和线上一模一样的版本也有将近一半的机会被判低；「每句 5 次至少 4 次」，就算模型每句真有九成会转，6 句一起过线的概率也只有六成左右。我把它们改成「不显著低于」和「两轮合起来 10 次至少 8 次」，改动和理由都写进了决策记录。
• 不照单全收 AI 的方案。「退款少退了 50 块」这句，AI 起初提议不先要订单号。我问：「为什么不先要订单号？」一查才发现，人工客服在飞书卡片上看不到用户身份，订单信息只能靠 AI 带过去。改成：先查本人订单，查到就把订单号和金额写进工单再转，查不到再问。
• 最后两句不再加字，改用代码护栏。说明越长，回答越短。剩下「退款少退了」和「问门店 CT 机型号」两句，用两道只拦一次的护栏补：没查订单就问订单号，拦一次让它先查；说了查不到又反问要不要转人工，打回一次让它直接转。

• 最终版 10-08 上线。最后两个版本的探针里，不该转的问法一共跑了 165 次，AI 自己决定的误转 0 次（改造前 12/50）；该转的 6 句全部过线：直接要人工 10/10、10/10，退款 9/10，「问了三遍」9/10，CT 型号 9/10，绑错邀请人 10/10。
• 日常咨询（30 道考题）的工具调用、举证和改造前没有显著差别；逐题时延反而快了 2.7 秒。
• 顺带抓出并修好 5 个计划外的问题：「低剂量螺旋 CT」被当成药量拦下、问提现门槛答成「价格以商品页为准」、嘴上说转了实际没建单、工单原因露出英文代号、评测自己撞上每天 50 次的使用上限。
• 51 轮评测，每一轮的编号、版本、结论都记在《运行时评测迭代记录》里。

线上回归时发现：用户问「广州哪里能做肺癌早筛」，AI 不去查门店，先反问「给谁做、多大、男的女的」，还说「这些信息确定了我就能查到具体门店」。门店查询根本不看年龄，这句话是假的。

在健康场景里，追问是把双刃剑：不该问的问了，用户烦；该问的没问，就靠猜下单。另外按红线 R4，吸烟史、病史这类健康信息，AI 不能主动收集。

1. 改提示词量不准。只量「不该问的不问」，把提示词改成「永远别问」就能满分。所以专门做了追问探针，两个方向都量：7 种不该问的问法、4 种该问的问法，各跑 3 次；低频问题另跑 10 次一组。问法刻意和考题不重合，免得照着考题调。每一版提示词都有一个 12 位的「指纹」，线上也报这个指纹，哪组数是哪一版量的，一眼对得上。
2. 治好一个毛病，冒出另一个。v2 起，AI 绕开「追问」这个工具，直接在回答里问「他吸烟吗？有没有高血压？」。v3 写明「健康情况不主动问」，比例从 13% 降到 5%；但量出来一个更严重的问题：登记了追问之后，它接着去查商品、门店，最坏的一次替用户编了答案：「您 55 岁符合年龄要求」「广州有 4 家」「10 月 3 日」，而用户只说了一句「想约个肺癌早筛」。
3. 代码拦住了，它又换个法子编。v4 在提示词里写「问和答二选一」，同时用代码拒绝「问完再查」。真执行降到了 0，可被拒之后，模型会假装用户已经回答了：「收到，56 岁女性……稍后帮你查看适合的筛查项目」。

• v5 只改代码，一个字不改：拒绝的同时结束这一轮，回给用户的是 AI 登记的那句问题（没写就按缺的字段拼一句）。模型最后自由发挥的那段字，恰恰是编造发生的地方，就不用它。
• 「需要什么信息」去核下游要什么，不凭感觉定。v1 把「帮我约」定义成只缺城市和日期，核了下单接口才知道：被检人的年龄、性别必须有，不适用的单根本下不了。探针和提示词错在了同一个地方，v2 一起改。
• 工具说明和提示词一样要量。加转人工按钮那次（案例 01）学到：工具说明是模型每一轮都看的字，改它会改变普通回答的写法；而说明书（Skill）模型多数时候不去翻，关键规矩要写在每轮都看得到的地方。

• 被拒之后用户看到的回答，编造 0 次；这类轮次耗时从 20–62 秒降到 10–17 秒；主动问健康情况 0/63。被兜住时用户看到的，就是一句正常的追问，比如「您爸爸今年多大了？」。
• 不该问的乱问保持 0/21，该问的问到 12/12；30 道考题和回归集每版都另跑，没有一版把它们改坏。
• 还有一次教训写进了方法：09-29 到 10-03，一个参数写法让 6 个业务工具对模型整个不可见。修好之后，提示词一个字没改，工具调用和举证从 65% 到了 80%。这个提升属于「工具恢复可见」，不能算到提示词头上。每一组数，只能来自一种条件。

09-24 的线上截图：用户问「广州哪里能做肺癌早筛」，广州明明有 4 家能做的门店，AI 却说「广州还没有可约门店」。更麻烦的是它时好时坏：同一句话隔两分钟再问，一次错一次对。

30 道考题测不到这种故障。考题固定的是用户的问法，而这个故障的触发条件，是模型自己的一个措辞选择（比如写成「广州市」）。那天横评了 150 条回答，一句「没有门店」都没采到。这种发生得少、后果却严重的故障，抽样天然抽不到，只能撞到一次，钉一个用例。

1. 混在考题里会被稀释。一条修过的故障再坏了，放进 30 道题的分母里，只会显示成「掉了几个点」。
2. 问一次答对，证明不了什么。原始故障是间歇的，这次答对只说明这次它写对了。
3. 判据容易被另一种失败钻空子。如果只锁「别再说没有门店」，模型不查、直接转人工也能过，那是拿另一种失败换掉了这一种。
4. 检查的人和被检查的人不能有同一个盲点。有一次，探针的检测规则和线上的检查规则用了同一个写法，漏检连报都没报出来。

• 单独一份、单独报告。回归集和考题一起跑，但不进考题的四项指标，评测后台里单列。
• 每条跑 5 次，全过才算过。结果分三种：过 / 没测到（模型先反问了，或链路故障）/ 坏了。后来又把撞上 90 秒时限单列成「超时」，因为它量的是快不快，不是对不对。
• 判据锁住故障本身，也锁住「正确的结局」。门店那条要求：调过查时段的工具、没说「没有门店」、没有转人工。判据的写法故意不复用线上的检查函数。
• 现在钉了 4 条：

  用例	用户原话	当时出了什么事
  INC-001	广州哪里能做肺癌早筛	广州有 4 家门店，AI 说没有（09-24）
  INC-002	广州市哪里能做肺癌早筛	同上的变体，测「广州市」能不能被正确识别
  INC-003	广州能做肺癌早筛的门店，明天上午哪家还有位？	AI 拿店名当门店编号去查，次次查不到，反复重试撞上 12 轮上限，转了人工（09-26）
  INC-004	我说的健康情况会被保存吗	答对了，最后一句「……的话可以告诉我帮你转人工」却被代码当成要转，建了一张没人要的工单（10-04）

• 它抓到过一个大问题。09-29 那一轮验收，三条回归全是 0/5。如果只看考题，工具调用和举证都是 65%，像是「模型不太行」。回头翻这 15 次的会话记录，全是「找不到这个工具」；线上真机问同一句，答的是「我这边暂时调不到门店实时列表的工具」。顺着查下去：一个参数的写法，让 6 个业务工具对模型整个不可见。修好后三条各 5/5，15 次全部真的查了时段；考题的工具调用和举证回到 80%。之后加了一道自动检查：任何写法让工具列不出来，测试当场变红。
• 新钉的用例第一轮就有收获。INC-004 上线后的第一轮又抓到两件：描述流程的「转人工时……」被当成要转；另一条知识还是旧口径。都修好后 5/5。后来做转人工改造（案例 01），它一直盯着「问转人工本身被误建工单」这个老毛病，改造上线后再没出现。
• 10-04 定稿评测：INC-001/002/003 各 5/5；每次评测自动带上回归集。

小程序被微信 AI 调用，是这个方向最稀缺的部分。技能做好后，真机上出了三个问题：商品列表的「查看全部」点了没反应；付款后上面那张订单卡还挂着「去支付」；卡片白屏或半屏白。之前已经改了五版，每版都在猜「卡片初始化的时机不对」，每版上线后真机都还有白卡。

1. 平台在内测，很多行为官方没写，规则还在变。
2. 观测本身是断的。诊断日志的白名单还停在旧格式，关键事件全被丢掉，之前一轮的结论其实没有任何日志支撑。
3. 真机上有两个调试面板（AI 面板的、小程序的），日志分在两边，很难对齐。
4. 安卓新版本每一轮都报「系统出现了问题」，连一句「你好」也报。

我给自己定的规矩是：用证据验证怀疑的原因，不靠印象。每轮真机测试前，先写好判定表（出现什么结果 → 说明什么 → 下一步做什么），测完照表下结论。

• 先修观测，再取证。修好日志白名单；做 A/B 诊断包：同一种卡交替用两种写法，每张卡右上角标「序号·写法」，录屏和日志一一对齐。测之前写好判定规则：A、B 两种写法都出白卡，就是宿主的问题。第一轮录屏按每 0.25 秒一帧、1215 帧做像素检测，没复现；第二轮复现了：两种写法的卡片代码都在约 65 毫秒内完整跑完、没有报错，外框却始终是卡宽的 1.31 倍，超过官方 1:1 的上限。按事先的规则，判为宿主问题（那台手机的微信版本低于官方最低要求），不是我们的写法。
• 一次只验一个假设，被推翻就撤回。曾怀疑「安卓新版把带错误标记的结果当成系统故障」，准备好了修改。但只查订单（没有错误标记）也报错、连「你好」也报错，假设被推翻，那个改动没做。
• 核官方文档和官方仓库。原子卡片在官方指南里标着「暂不支持调试」，官方规范从 7 月起默认不生成卡片，进小程序统一走「账号卡片 → 接力页」。于是我定了方案：进小程序统一走接力页，给 8 个接口各配一个落点（问知识进首页、查商品进详情、准备下单进确认页、改期进售后页并预选新时段）；卡片保留、暂停投入；安卓的问题整理证据报给微信。
• 安卓：做最小复现，带着证据报给微信。把技能换成只有一个 ping 接口的最小版本（310 KB 变成 8.3 KB），「你好」照样报错，说明和我们的代码无关。观测平台的调用链对照：安卓在接口返回之后就再没有生成回复，iPhone 是完整的。10-02 写成缺陷报告，在微信开发者社区提交。

• iPhone 上又跑了三轮接力页验收：第三轮找出 4 处缺口，第四轮发现「技能写的本地存储，小程序主包读不到」（上一版方案的前提不成立），改走平台给的接力数据通道；第五轮九句话全部落到正确的页面，被检人信息也自动预填上了。
• 实测出来、官方没写的平台行为，都记进了文档：半屏下回复一出来，下面的页面会自动跳到接力页（证据：页面计数器 4 句话收到 9 次回调）；接力页收到的参数是对象，官方写的是字符串；账号卡片会落到「这一轮最后一个成功接口」给的页面；平台模型会把「大后天」算成第 4 天、自己拼时段编号，于是规定时段编号只认 30 分钟内查过的，相对日期交给服务端算；iPhone 上图文混排的链接会显示成一长串编码，我决定去掉。
• 自动化检查：技能相关的 418 条断言全过，官方静态校验 304 项、0 错误 0 警告。整理成一份约 1000 行的《微信 AI 卡片问题排查与平台能力》，每条能力都标了出处（官方文档 / 官方仓库 / 实测）和核对日期。

公众号常常是用户最先接触到的地方。我希望它不只发文章：用户在后台提的服务问题，当场有人答；答完，还能顺手把人引到小程序去下单。

1. 大模型来不及。微信 5 秒内收不到回复就断开、重试，最多三次。实测走大模型中位要 7 秒，4.2 秒内只有 15% 的问法能答完；后来横评，最快的模型中位也要 6.7 秒，没有一个进得去。
2. 个人号不能「先回执、后推送」。个人订阅号不能认证，发不了主动客服消息；官方的「AI 回复」要粉丝数满 10000 才能开。
3. 一根分数线切不开。真问题的检索分数最低 3.9，无关问题最高 10.3，两边重叠，设哪个阈值都会误伤。
4. 消息推不到后台。排查了六轮才确认：个人公众号用不了云开发的消息直推；最后在另一个控制台找到能直连云函数的 HTTP 网关。

• 检索直出是主路径，不是降级。我在任务书里写的是：「回执是主路径不是降级路径，回执里的检索片段质量是公众号体验的核心。」所以公众号先交付「不调大模型」的版本，作为这条验收的保底。
• 答案分三档。很像，就直接回正文；有点像，只列编号和标题，问一句「你是不是想问这个」；不像，就说没查到。12 条无关问题，一条都到不了「直接回正文」那一档。
• 红线在公众号这一路再守一道。「我血压 160/100，这个算高吗？」会被拦下，回边界说明并建议就医；下单、退款、改期这类写操作，一律引导进小程序。
• 不拿官方 AI 回复兜底。它答的是公众号文章，不带编号、不受红线约束，而且偏偏在「一条都没查到」时接手，那正是最可能越界的问题。我把它改作评测对照，后来因为粉丝门槛没跑成，如实记下。
• 文章和客服用同一份知识。10 篇公众号文章由知识库自动编译出来，覆盖全部 97 条；知识库一改，文章跟着变，不会出现两套说法。

• 热调用中位 449 毫秒，12/12 在 4.2 秒内（冷启动 2.3 秒）；HTTP 网关直连比经一层中转快三四百毫秒。
• 真机收到的回答带知识库编号、更新日期和「自动回复」声明；红线问法被拦下。

AI 再谨慎，总有答不了、不该答的问题。用户被转走之后，如果等不到回复，体验比 AI 答错还糟。

1. 一个藏了很久的事故。两轮横评里 132 次转人工，工单号全是空的。三个问题叠在一起，而两边的测试都是绿的：AI 那边用的假云函数一律返回成功，云函数那边的测试默认带着用户身份。两边各自都通过，接在一起从没测过。
2. 微信的规则。客服消息只能发给在客服会话里互动过的用户（48 小时内、最多 5 条），助手页里的对话不算。原设计「建单时就给用户发一条摘要」多半会被拒；人工的回复也一样，用户不进客服会话，回复就丢了。
3. 个人主体的限制。企业微信客服要认证，于是工单进飞书；从网关进来的请求不能直接调微信接口，人工回复只能交给每分钟一次的定时任务去发。
4. 内部术语露给了用户。我在真机上看到转人工卡片写着「红线 R1-numeric」，就问：「这是什么意思？」

• 先把底线定下来。我的原则是：「所有系统没接住的事项，按道理都应由人工兜底。」比如「某地没有门店」这种查不到依据的话，重试用尽也不放行，改成如实说「本次查询没成功，已自动为您转接人工」。
• 修事故，补「接在一起」的测试。假云函数改得和真函数一样严，新测试在旧代码上验过会变红。修好后，我在真机上拿到了第一张工单号。
• 顺着微信的规则改流程。「告诉用户」改到用户进入客服会话的那一刻发，那是唯一能确定窗口开着的时候；转人工卡片的主按钮就是「进客服会话等人工回复」。
• 人工回复另存一份，放进「我的工单」。回复不管微信发没发成，都存进工单；用户在「我的 → 我的工单」里能看到，「我的」页提示「有新回复」。读工单用一个新的只读接口，只认用户本人，AI 读不到人工回复。飞书卡片也改了说法：发不到微信时写「已存进小程序，不用重发」，免得人工重复回复。
• 给用户看人话。工单里保留内部原因，卡片上换成「指标要不要紧，需要医生结合你的情况判断」这样的话。

• 真机七步跑通：工单卡片 47 秒进飞书群；人工在飞书回复后 57 秒送到用户微信；降级路径（微信客服小助手接入、联系方式）也验过。
• 用户没进客服会话时，微信拒发，小程序照样看得到：一张测试工单 14:12 建单，14:15「我的」页出现「有新回复」，点进去就是人工的回复。
• 用户问「人工回复多久能到」，我没接受推测，用录屏对着状态栏时钟测：基本在同一分钟内到。

老带新是私域里成本最低的增长方式，分销就是把「分享」和「交易」接起来的那一环：前半段是关系链（分享、绑定），后半段是佣金计算、结算和提现。我想自己把佣金规则设计清楚，而不是装一套现成的开源商城。

1. 解冻和售后必然打架。佣金在报告出具后 7 天解冻，售后窗口是报告出具后 15 天，中间重叠 8 天。「佣金已经解冻、甚至提现了，这一单又被退款」不是边缘情况，是日程表上写好会发生的。
2. 绑定不能反悔。一旦绑定，这个人以后所有订单的佣金都分给上级，而且不能改。
3. 合规。多级分销有监管红线；保险销售要持牌，佣金不能给到无资质的个人。

• 佣金跟着「报告」走，不跟下单日走。服务完成的定义是报告出具。报告还没出时，佣金明细写「待报告出具」，不猜一个日期糊上去。
• 退款冲销分两档。还在冻结的，从冻结里扣；已经结算的，从可用余额里扣，扣不动就记成「欠回」，下一笔解冻优先抵扣。余额永远不为负。
• 绑定要用户确认，不做扫码静默绑定。转化会掉一点，这是明知的取舍。不能绑自己、不能循环、绑了不能改；层级封顶两级，写成代码常量，不做成后台可配。
• 佣金只发生在普通健康服务商品。下单时把「是否参与分销」写死在订单上，算佣金时只读、不重判；保险类商品在代码里就不能下单、不产生佣金。
• 退路要做进界面。推广码生成失败时，我要求能手动输入推广码。退路只写在文档里，真跑起来照样卡住。
• 后台只开放该开放的。运营后台能推进订单、审核提现、上下架和改价；适用年龄这类会直接决定能不能下单、AI 怎么回答的参数不进后台。界面允许的事，迟早有人会做。

• 分销闭环按验收标准走通：扫推广码绑定 → 下单产生佣金并冻结 → 解冻 → 提现申请 → 售后退款时佣金冲销。
• 佣金的冻结、解冻、两档冲销和欠回都有专门的自动化测试；云函数层的测试把微信云开发换成内存实现，在本机端到端跑分销全链路。

智能客服成败在会不会串工具。所以开工时我就定了：「主模型按 30 条封存评测的工具调用正确率选，不按价格。现在别定。」后来又明确：「成本不要作为核心考虑项。主要考虑的是效果和时延。」

1. 名次会翻。第一天单轮排第一的模型，第二天掉到最后；原来垫底的 qwen3.7-plus 从 55% 涨到 75%。同一个模型两轮之间最多差 10 个百分点，这就是这张表的分辨率。
2. 想按的那把尺子分不出来。五个模型的工具调用正确率只差 7 个点，在误差里。
3. 评测会悄悄偏心。早期把「预算耗尽」「撞 90 秒」当成链路故障剔出分母，结果越容易跑飞的模型看起来越好；还有一次，一半模型从旧断点续跑，比的根本不是同一种条件。
4. 平台会掉链子。跑到六十条左右，云函数大面积超时。查下来不是配额，是平台冷启动堆积。

• 先粗筛再细比。11 个模型各跑 3 道题粗筛，挑出 5 个各跑 30 道。
• 每个模型跑两轮取平均（我定的），报告里写明：差距小于 10 个点的名次没有意义。
• 先修尺子。该算的失败一律算进分母；每条结果带「条件指纹」，条件一变自动作废重跑；所有模型共用同一份知识库快照；开跑前把云函数逐个叫醒。
• 工具调用分不出，就看分得出的。举证率在模型之间差 25 个点。qwen3.7-plus 的举证（70%）和检索命中（85%）都是第一；代价也写明：成本更高，最慢 5% 的回答慢了近一倍。AI 起初推荐最便宜的那个，两轮数据出来后自己收回，改成把取舍摆给我。

• 我定了 qwen3.7-plus。
• 10-04 定稿评测上，它的工具调用、举证都是 80%，越界拦截 100%。