AI 为什么能回答，又为什么会答错
从生成机制到知识、上下文与能力边界，建立判断输出的依据。
AI 可以把一段杂乱的记录整理得很像一份专业报告，却在其中写进一个不存在的数字。问题不只在于它“偶尔不准”，而在于流畅的表达容易让人误以为背后已经完成事实核查。
使用 AI 的起点，是知道这次回答依据什么，以及什么证据能推翻它。
下面用一份虚构的客服周报，分清生成、知识、上下文和工具，让“检查一下”变成具体动作。
01 / 定义：生成答案不等于查到答案
语言模型根据输入和训练形成的模式生成后续内容。Token 是处理文本等信息的基本单位，不必等同于一个汉字或单词。预测下一个 Token 是生成机制，但模型可以借此表现出归纳、编程与推理能力；不能反过来把一切能力解释成简单复制。
关键在于：输出符合语言与模式，并不保证每项事实都真实。它可以推导正确，也可能沿着错误前提继续写出看似连贯的结论。让它更自信、说得更详细，都不是事实验证。
| 回答依据 | 能提供什么 | 主要边界 |
|---|---|---|
| 训练形成的知识 | 常见概念与规律 | 可能过时、混淆或遗漏细节 |
| 本次上下文 | 用户材料、指令、工具结果 | 材料可能缺失、相互矛盾或未被正确利用 |
| 实际工具调用 | 查询或计算得到的信息 | 调用可以失败，数据本身也可能错 |
02 / 推导：为什么换一句提示不能解决所有错误
假设你让 AI 写本周客服周报，却没提供工单。模型不知道真实数量，若仍被要求填写“问题分布”，就可能补出符合周报习惯的数字。此时缺的是数据，不是更强的写作技巧。
- 任务要求统计真实工单，因此必须有可追溯输入。
- 输入包含重复记录，直接数行会把重复工单也算进去。
- 去重后仍要定义分母：统计所有工单，还是仅已解决工单？
- 确认口径后执行计算，再让 AI 解释结果，而不是让它凭语言直觉估计。
图中核查先于结论。若模型给出“登录问题占一半”，你需要看到分子、分母和分类规则，而不是另一次同意这个结论的模型回答。
03 / 辨别：上下文、记忆与训练不是一回事
对话纠正可以改变当前回答，因为纠正进入了上下文；它不等于已经更新模型权重。产品可能保存记忆、项目资料或检索索引，但保存了什么、什么时候重新读取，是应用层的问题。
上下文也不是无限且均匀可靠的工作台。长材料中的关键规则可能被遗漏，摘要可能丢掉条件。即使文件装得下，也要检查模型是否用了正确版本。把所有资料一次性上传，不保证所有细节都进入本次判断。
- 事实错误：核对原始记录，而不只让模型再想一次。
- 逻辑错误：要求列出可检查的假设、计算和中间结果，不必索取模型内部思维过程。
- 执行错误：检查工具实际返回值与文件产物。
- 版本错误：确认资料生效日期、适用范围与更新关系。
04 / 应用：做一份能对账的客服周报
① 准备最小数据
ticket_id,category,status
T01,登录,已解决
T02,导出,待处理
T03,登录,已解决
T02,导出,待处理
T04,支付,已解决
先由你确定口径：按 ticket_id 去重，统计全部有效工单；演示数据里重复项内容一致，冲突重复则应列出来人工处理。正确总数是 4，登录类 2 条，占 50%。
② 让 AI 先处理，再写作
根据这份CSV制作一页客服周报。
先按ticket_id去重，报告原始行数、去重数量和分类计数。
如同一编号内容冲突，暂停该项统计并列出冲突。
计算通过后再写结论；没有原因证据时，不推断投诉原因。
输出：统计表、三条观察、待确认问题。不要补造趋势。
③ 用已知答案检查
- 核对它是否报告 5 条原始记录、4 个唯一工单。
- 核对三个分类计数是否加总为 4，登录占比是否为 50%。
- 检查是否凭一周数据写出“持续上升”。没有上期数据就不能比较趋势。
- 再加入一个空类别工单，要求单列“未分类”，检查它是否偷偷丢行。
- 打开实际输出文件，检查表格与摘要是否一致。
少量已知答案是校准工具。连 4 个工单都对不上，就不应急着让它处理成千上万条；先定位是去重、口径、计算还是表述出了问题。
05 / 迁移：从检查一句话，到设计整个工作
迁移到访谈分析时，分子分母变成了原话与主题：某位受访者的说法能否代表所有用户？迁移到制度问答时，关键变成条款版本：回答是否适用于这个人、这个时间和这个场景？
如果 AI 能准确引用一段话，是否就证明结论正确？
不能。引用可能确实存在，却不支持结论，或忽略了后面的例外条件。核查至少包含“材料存在、定位正确、含义一致、适用条件满足”。
模型能力边界不是让工作停下来，而是提醒我们把验证安排在需要的位置。下一步要解决的是哪些工作交给 AI、哪些判断由人承担，见完整任务中的 4D 协作。