1. 为什么 AI 系统的调试难度远超传统应用

1.1 传统应用的调试是线性的

传统 Web 应用的调试链路通常是确定性的。假设有个 bug："用户点击下单按钮后页面报错了"。你的排查路径大致是这样的：

1. 打开错误监控平台，找到这条报错日志
2. 看堆栈信息，定位到是 orderService.create() 方法里抛了异常
3. 查看异常详情，发现是数据库连接超时
4. 检查数据库状态，确认是连接池配置不合理
5. 修改配置，部署上线，问题解决

整个过程的关键特征是：问题可复现，原因可追溯，修复可验证。 你看到同一个报错，就知道是同一个原因。修完之后再触发同样的操作，不报错了就说明修好了。

1.2 AI 应用的调试是非线性的

AI 伴侣的调试完全不同。假设你收到一条用户反馈："AI 回复不对，我明明告诉过它我养了一只猫，它说我没有养宠物。"

这个「回复不对」可能出在整条管线里的任何环节：

• 记忆写入失败：用户说了"我养了一只猫"，但异步后处理没把这条事实真正写入数据库
• 记忆检索失败：事实已经写入了，但向量检索的时候没有把它召回来
• 查询理解错误：查询计划解析偏了，导致检索方向不对，根本没去搜"宠物"相关的记忆
• Prompt 组装遗漏：记忆检索到了，但在拼 Prompt 时因为 Token 预算不足被截断了
• 情绪路由偏差：当前使用的回复模板更强调情绪表达，弱化了事实引用
• LLM 幻觉：上下文里明明有"养了一只猫"，但模型在生成时还是忽略了这个事实

你会发现，同一个表面症状（「回复不对」），背后可能对应 6 种完全不同的根因，而且这些根因分布在管线的不同阶段。

更麻烦的是，LLM 具备非确定性。同样的输入再跑一次，结果可能不一样。 你用同样的消息测试，AI 这次答对了，并不代表上次答错的原因已经消失。这意味着你不能像传统系统那样依赖「事后复现」来定位问题。