做大模型产品第一天就该想的事：可观测性

「AI做了点什么。但我完全不知道它到底做了什么。」——在这种情况发生之前，可观测性（observability，指从外部理解系统运行状态的能力）是你真正需要提前考虑的事。

用Claude Code或Cursor这类AI编程工具开发时，你能看到"它跑通了"。但"为什么能跑通""它在哪、怎么做的决策""实现是否符合我的意图"，这些变得难看得多。

把AI放进产品本身时也一样——无论是调用大语言模型（LLM，Large Language Model，一种基于深度学习的自然语言处理模型）接口、构建AI智能体，还是集成MCP（Model Context Protocol，模型上下文协议，一种让AI工具与外部系统交互的标准）工具。如果你看不到AI返回了什么、做了什么决策，你就无法改进它。

运维领域（SRE，Site Reliability Engineering，网站可靠性工程）有个原则："看不到，就修不了。"这个原则直接适用于AI驱动的开发，也适用于运行AI功能的产品。

这篇文章记录了我对基于LLM开发中可观测性的思考——以及我正在实际做的事。

可观测性的三根支柱，AI时代怎么塌了两根

可观测性是SRE的核心概念之一。它指从外部理解系统状态的程度，通常被描述为"三根支柱"：日志（Logs，记录系统事件的离散数据）、指标（Metrics，可聚合的数值测量）、追踪（Tracing，请求在分布式系统中的完整路径）。

三者齐全时，你能回答："发生了什么？""为什么发生？""在哪发生？"

但在AI参与的开发中，你需要在两个场景下重新思考这件事。

场景一：用AI工具开发时。变化发生得飞快，但"为什么会这样"变得难看得多。这不是代码质量问题——是流程可观测性问题。

简单说，AI跑得越快，你越需要刻意创造让人类能观察正在发生什么的节点。

场景二：把AI嵌入产品时。这时候可观测性不是锦上添花，是生死线。

产品里塞AI？这三条日志红线不能碰

最低限度：记录你发给AI什么，AI返回什么。光这一条，就能让你在事后调查："那次输出为什么错了？"

第二条：记录AI做了什么。如果你用AI做智能体（agentic，指AI自主决策并执行多步骤任务的能力）的事，这点尤其重要。没这个，你追查不了"AI把工具调用顺序搞错了"这类问题。

第三条：把AI做的事和用户做的事关联起来。要看清这个，需要把AI日志和产品用户行为日志打通。

这是我在kaizen-lab和相关项目里正在落地的方案。把页面浏览和自定义事件存进数据库，就能把AI输出和用户行为连起来。

我在这篇详细写过："把Vercel Analytics的数据流接到内部数据库，让AI评估产品行为"。

另一个方向：通过MCP让外部AI工具能访问产品状态，这本身就是可观测性的一种形式。AI自动处理时，错误可能悄无声息发生。接入Sentry（一款错误监控和性能追踪平台），能捕获意外异常。

我在这篇覆盖过："用Sentry × AI智能体自动化错误检测→根因分析→修复PR（Pull Request，代码合并请求）"。

"能跑就行"是AI开发最大的坑

AI驱动的开发里，停在"能跑就行，收工"太常见了。

但"能跑"和"能跑对"是两件事。没有可观测性，你只是在祈祷。

我见过太多团队： demo演示完美，上线后用户投诉，然后对着黑箱干瞪眼——输入一样，输出随机，复现不了，定位不了。

这不是技术债，是技术黑洞。

传统软件的开发反馈环是：写代码→看结果→调代码。AI时代的反馈环变成了：描述需求→AI生成→看结果→调描述。第二个环节是黑盒，如果你不在输出侧打光，整个环就断了。

更隐蔽的问题是决策漂移。LLM的输出有随机性，温度参数（temperature，控制生成文本随机性的数值，越高越随机）调高一点，同样的输入可能走完全不同的推理路径。没有追踪，你会发现"上周还好好的"成了最可怕的句子。

我在kaizen-lab的实操：把可观测性埋进每个关节

说说我具体怎么做的。

第一，AI交互全落库。每次调用LLM，请求体、响应体、耗时、token消耗（token，大语言模型处理文本的最小单位，通常按使用量计费），全部写进结构化日志。不是打文件，是进数据库，能关联查询。

第二，用户行为与AI输出交叉分析。用户点了哪个按钮、看了哪页、停留多久，和AI当时返回了什么，在同一张时间轴上对齐。这样当用户说"推荐不准"时，我能精确回溯到那次推理的上下文。

第三，MCP工具调用全追踪。AI调了哪个外部工具、传了什么参数、返回什么、怎么基于返回做下一步决策，链路完整保留。这是智能体场景的生命线——没有它，你根本不知道AI为什么突然开始循环调用同一个API直到超时。

第四，错误自动分级+AI辅助诊断。Sentry捕获异常后，不是直接扔给人，是先过一层AI分类：是LLM返回格式错乱？是工具调用超时？是上下文窗口（context window，模型能处理的最大文本长度）超限？分类完再决定是自动修复、生成修复PR，还是人工介入。

这套东西不性感，但省命。上周一个凌晨的告警，从触发到定位到修复PR，23分钟。没有可观测性打底，这个时间单位是天。

为什么这事现在必须想，而不是"以后再说"

有个残酷的事实：AI系统的可观测性债务，比传统技术债贵十倍。

传统bug，你复现、调试、修。AI系统的诡异行为，你可能连复现都做不到——同样的输入，模型版本没变，输出变了，因为底层推理基础设施（infrastructure，指支撑AI运行的硬件和软件环境）悄悄更新了。

OpenAI、Anthropic这些厂商不会提前三个月通知你"我们要改GPT-4的微调权重"。你的自动化测试全绿，上线后用户看到胡说八道，这就是现实。

更麻烦的是，AI系统的"对"和"错"本身模糊。传统软件，2+2=4是对的，=5是错的。AI写摘要，"好"和"更好"没有客观标准。没有可观测性，你连A/B测试（一种对比两种方案效果的实验方法）都不知道在比什么——用户停留时长涨了，是因为摘要变好了，还是变娱乐化了？

所以可观测性不是运维的事，是产品定义的事。你得先想清楚"什么算好"，才能观测"是不是好"。

我现在的判断是：未来12-18个月，AI产品的竞争会从"功能有没有"转向"效果稳不稳"。能稳定交付预期质量的团队，靠的是可观测性基建；靠运气和调提示词（prompt engineering，通过设计输入文本来引导AI输出的技术）的，会在规模上去后暴雷。

数据支撑这个判断：Gartner 2024年报告显示，到2026年，50%的企业生成式AI项目将因信任、风险和安全管理问题被搁置——而可观测性是信任的基础。不是锦上添花，是入场券。

如果你今天开始做一个LLM项目，我的建议粗暴但有效：第一天就把可观测性写进技术方案，不是"后续优化"，是P0需求（最高优先级需求）。延迟的代价不是加几周班，是产品死掉时你都不知道为什么。