AI 应用真正的 Bug 很少让程序崩溃，更多是程序跑通但结果不对。掘金社区一篇技术文章把这类问题拆成三类：代码层（如接口超时、张量维度异常，能被日志捕获）、数据层（脏数据、文本编码异常，程序不报错但输入本身有误）、模型层（幻觉、prompt 失效，输出语义错误）。核心流程是先用前置校验（pre-check，即调用模型前先做输入合规检查）排除明显问题，再对异常样本聚类（把同类失败案例归到一起分析）。文章附带了完整的 Python 示例代码，覆盖空输入拦截、幻觉关键词识别、服务异常三类场景。
这是什么
文章给出的方案并不复杂：先把所有失败案例收进一个样本池（error_samples），再按类型归档。作者把 AI 应用的失败模式（failure mode，即系统出问题的具体形式）从「程序崩没崩」这一维度切换到「输出对不对」这一维度，这是 AI 时代软件工程最重要的认知转变之一。代码本身只有几十行，但背后的方法论可以扩展到任何 AI 应用的稳定性保障体系。
行业怎么看
开发者社区的共识是：AI 应用的稳定性问题往往不在模型本身，而在三层之间的接口。一个反常识的判断是，模型层 Bug 反而最容易修复——换个 prompt（提示词，即给 AI 的指令格式）模板往往就解决了；数据层 Bug 看起来简单，实际排查成本最高，因为脏数据通常是一批而非一行。
另一种声音也值得注意。有工程师指出，三类 Bug 在真实场景里经常叠加：「prompt 改了一个词，输出格式变了，下游脚本崩溃，错误被记到代码层，根因却在模型层。」我们注意到，这套方案的价值不在于给出确定答案，而在于把「黑盒失败」变成「可归类的样本池」，让团队有据可查，而不是每次靠猜。
对普通人的影响
对企业 IT：建议把 AI 项目的日志规范提前到上线前。传统「程序没崩就好」的标准不再适用，AI 应用的失败模式更隐蔽，需要专门的样本审计机制。
对个人职场：会用 prompt 的人下一步要学的是判断 AI 输出的质量边界。知道 AI 何时会胡说，比会写提示词更有长期价值——这是从「使用者」升级为「验收者」的关键一步。
对消费市场：短期感知不强，但采购 AI 客服、翻译等服务的甲方应关注「错误率」而非「准确率」。真正损失业务的，往往是那些没报错的错。