这是什么
一次用户提问背后，可能跑了 4 步（检索、模型、工具、再生成）——但传统日志只记录最后一秒。这是工程师社区正在反复讨论的痛点：AI 应用「不可观测」，出了事只能靠用户描述和工程师猜测。
失效在三个地方。第一，AI 输出是概率性的，传统日志靠「预期 vs 实际」对比，AI 没有「预期」。第二，一次提问背后跑了多步，单条日志只看得到最后一秒。第三，答案质量强依赖「模型当时看到了什么」（检索到了哪些文档、系统提示词版本），光看最终输出不知道它为什么答错。
修复办法朴素：放弃 print 这种自由文本日志，改用结构化日志（key=value 格式，比如 event=llm_call in_tokens=69），并给每个请求生成唯一的 request_id（类似订单号，能串起一次请求的所有步骤）贯穿所有环节。事后 grep 一下这个 ID，就能还原一次请求的耗时、token 数、哪一步失败、当时模型拿到了什么上下文。
作者把这叫「AI 应用观测的地基」——再炫酷的追踪平台也是锦上添花，地基没打好，上了线就是黑盒。
行业怎么看
赞成的人觉得这戳到了行业痛点。多位 AI 工程团队负责人在社交平台呼应：很多公司花几百万搭 Agent（让 AI 自主完成多步任务的程序，比如自动订机票、写周报），用户一报障就懵，因为「没法证明 AI 这次答得对不对」。结构化日志看着土，但它能直接接告警、入看板、做回归测试，是从「能跑」到「能管」的门槛。
反对意见值得说几句。第一，结构化日志不是银弹——它告诉你「发生了什么」，但答不了「为什么」，模型行为偏差的根因要靠评测集和人工标注配合定位。第二，国内很多 AI 项目还停在 PoC（概念验证）阶段，业务方根本没动力做精细化观测，因为还没真用户，谈观测是「过早优化」。第三，request_id 看似简单，跨多模型、多服务做链路染色（每个环节贴同一个 ID）工程量很大，作者自己吐槽 openai SDK 的日志噪音能淹没业务日志。
对普通人的影响
对企业 IT：花了几十万上线的智能客服、知识库、出题系统，老板问「为什么用户投诉越来越多」时技术团队答不上来——这正是结构化日志要解决的问题。观测能力迟早会成为采购 AI 产品的硬指标。
对个人职场：和 AI 应用相关的岗位会从「调 prompt（提示词）」分化出「AI 运维 / 可观测性」这类新角色，懂日志、链路、成本分析的人会比单纯会用 ChatGPT 的人更稀缺。
对消费市场：用户会越来越明显地感受到 AI 产品稳定性的差异。同样的功能，能告诉用户「答错了为什么」的产品会赢，出了问题只会说「请重试」的产品会输——透明比聪明更重要。