查询正确，AI 却在回答时写错姓名

数据库查对了，工具也没选错，AI 最后还是可能把客户名字写错。Dashing 团队在开发店铺记账助手 Dash 时发现，问题出在最后一步：模型把正确数据组织成自然语言时，重新「抄写」了事实，而这次抄写并不可靠。

作者的应对很具体：姓名只在严格条件下做单词级纠正，金额先由代码生成展示文本，再校验模型是否照抄。这篇值得读的地方，是把 Agent 的检查范围从工具调用延伸到了用户真正看到的答案。

工具返回正确，不代表用户收到正确答案

Dash 是销售点与记账应用 Dashing 内的助手，服务使用 Arabic、Kurdish 和 English 的小店经营者。店主可以问谁还欠款、本周卖了什么、哪些商品库存不足；涉及记录收款等修改时，需要店主先批准。

作者已经为常见问题做了测试：有没有选错工具、有没有传错参数、有没有编造数据。在实际对话中，这些环节大多正常，正确数据也完整地到达了模型。

错误发生在生成回复时。客户 Karim 被写成 Kiram；表示「系统管理员」的员工角色，被改成接近「清洁专员」的含义；商品名丢了最后一个字母，变成了复数形式。

这些语言里的姓名往往很短，彼此只差少数字母。改错一个字母，结果仍可能是另一个真实姓名，读起来也很顺。店主据此联系客户，就可能找错人。

更麻烦的是，错误会进入对话历史。模型下一轮重新读取自己的回复，继续沿用错名，一次笔误逐渐成为后续回答的依据。

工具调用成功，只能证明数据取到了，不能证明最终答案忠实于数据。

作者也试过发现错误后让模型重新生成。但在他们的测试中，第二次仍会犯同样的错，还要多付一次完整调用的费用和等待时间。原文没有给出样本量、错误率或重试成功率，因此能确认的是这条修复路径在他们的测试里效果不好。

为什么他们敢直接修改模型的回复

团队最初反对自动修改输出，担心纠正机制造成更大的错误。后来，他们把规则收窄到一个可以明确核对的范围。

姓名纠正必须同时满足这些条件：

• 候选姓名来自当前对话自己的工具数据。
• 正确姓名没有出现在回复中。
• 回复里某个词与正确姓名使用同一套字母系统，并且恰好相差一个字母。

满足条件后，只替换那个完整单词，并记录纠正日志。不修改词内部的片段，也不改动其他内容。只要正确姓名已经在回复的任何位置出现，检查就直接放行。

这套做法的依据是：正确姓名已经存在于工具结果中，程序只需要核对模型有没有抄错，无须重新推断用户想找谁。

但它也主动放弃了一部分覆盖范围。例如，一条回复同时出现正确姓名和错误变体，按照原文规则不会修正。规则越窄，越容易判断修改依据，也越可能漏掉复杂错误。

另外，「恰好相差一个字母」的实现没有公开。它是否包含插入、删除、相邻字母交换，以及如何划分多语言单词，原文都没说清。不能直接把这段描述等同于某一种编辑距离算法。

金额先由代码排好，再检查模型有没有照抄

姓名错误是意外，金额则是作者从一开始就防备的对象。

他们让普通代码为工具返回的每笔金额生成可直接展示的文本，包含对应币种的小数位数、千位分隔符和货币代码。模型拿到的是成品，并被要求原样复制。

不过，给出成品还不够。最终回复中的每个金额，都必须匹配当前对话数据中的某个展示值；明确标为示例的金额可以例外。比较之前，两边会先做规范化，兼容原文所说的阿拉伯数字表示差异。

需要精确呈现的业务值，应当由代码生成，并在输出端核对。

同一套检测代码运行在两个位置：在线上，每条回复展示给用户前执行姓名纠正和金额检查；在线下，对脚本对话和真实生产对话做测试。

离线测试还检查另外两件事：助手建议修改的记录是否确实来自真实数据，以及已经执行的修改是否事先得到用户批准。加上姓名、金额，一共四类检查。

复用检测代码的价值，是减少「测试检查一套，线上执行另一套」的偏差。生产对话触发离线告警，可以暴露线上遗漏或回归。不过，离线检测本身无法保证问题一定在用户看到之前被发现；实时拦截仍要依靠输出前的检查。

我的判断

我认同作者把最后一公里纳入验证。对于记账助手，名字和金额都是用户采取行动的依据。语句流畅并不能替代事实准确，这一层校验很有必要。

确定性纠正也有成立的前提：系统手里已经有可信原值，修改对象足够明确，规则可以审计。把它推广成「看到近似姓名就自动替换」会很危险，同一业务里完全可能存在两个只差一个字母的客户。

金额检查还有一个边界：某个金额确实出现在工具数据中，不代表模型把它分配给了正确客户。原文描述的是展示值匹配，没有说明是否核验了客户、金额与记录之间的对应关系。

和重新生成相比，局部纠正省去了一次额外模型调用；和固定模板相比，它保留了自然语言表达的空间。但作者没有提供这些方案的对照数据，也没有给出误修率。因此，这是一份有清晰工程依据的经验，尚不足以证明它对所有团队都更优。

能拿来做什么

• 在 Node 服务的工具响应中，同时提供业务原值和展示文本，让金额格式由代码统一处理，并在回复返回前核对展示值。
• 给 AI 编程任务补上一条验收要求：检查最终回复中的姓名和金额是否忠实于工具结果，不能只验证工具调用成功。
• 为重试记录修复结果、额外调用成本和等待时间。若同类错误持续复现，就据此评估是否适合加入范围明确的确定性校验。
• 用实际用户的语言建立多轮测试，检查错名是否在后续回复中继续传播，同时覆盖修改记录必须经过用户批准的流程。