Vibe Coding 与可观测性：从“能跑”到“可信赖”的 AI 工程分水岭

Vibe Coding 最近真的很火。第一次让 AI 用自然语言生成一段能跑的代码时，那种感觉确实很妙：你描述需求，AI 给出实现，你还没来得及读完它生成的函数，屏幕上已经跑出了结果。我见过不少开发者用这种方式快速搭原型、写脚本、做内部工具，甚至有人把一个重复了几周的手工操作，在一个周末里用 Vibe Coding 自动化掉了。

但问题也恰恰出现在“跑通之后”。demo 很顺，接入真实数据和真实业务后，系统就开始变得不可理解。AI 生成的代码能运行，却很难被解释；出了问题，你不知道是输入变了、模型抽风了，还是下游解析逻辑错了。这种时候，真正决定 Vibe Coding 是“玩具”还是“工程”的变量，已经不再是代码量，而是可观测性，也就是 Observability。它才是把 Vibe Coding 变成 AI Engineering 的那道分水岭。

1. Vibe Coding 的真正价值，不是“不用写代码”

很多人把 Vibe Coding 理解成“以后可以不用写代码了”。我觉得这是一个危险的方向。它真正的价值不在替代写代码，而是把一个想法快速变成可运行的雏形，把大量机械性、试探性的编码工作交给模型，让人把精力留在“想清楚要什么”和“判断结果对不对”上。

1.1 为什么 Vibe Coding 让人上瘾

Vibe Coding 的体验和传统开发很不一样。传统开发是先设计、再实现、再调试，每一步都要你亲自维护心智模型。Vibe Coding 则是“期望 → 生成 → 验证”，模型把大部分编码工作一次性完成，哪怕结果不对，修正成本也远低于从零开始写。

这种方式让人上瘾的核心原因，是反馈极快。你说“写一个脚本，把 CSV 按某个字段分组，输出 Markdown 表格”，几秒钟后代码就出来了，跑一下，结果基本符合预期。这种即时成就感会让人产生一种错觉：AI 已经把这件事解决了。

但这里藏着一个误区：产出速度不等于理解深度。代码是 AI 生成的，但你要对它负责。如果你不知道它在边界情况下会怎么处理，不知道哪个分支会被走进，不知道异常路径为什么这样设计，那么这个代码对你来说就是一个“亮着灯的黑箱”。快速生成只能提高起点，并不能替代对行为的理解。

1.2 但“demo 能跑”和“系统可信”之间隔着什么

“能跑”和“可信赖”之间，隔着一条大多数 Vibe Coding 新手看不见的沟。

demo 能跑，通常只意味着 happy path 通了。输入正常、条件正常、结果正常的情况下没问题。但真实系统里，80% 的复杂度来自异常路径：用户输入了一个空字段，上游返回了重复数据、网络超时、模型返回格式变化、依赖升级后行为改变。

demo 能跑，也不等于可维护。代码没有日志、没有分层、没有清晰的错误处理，AI 生成时又可能把逻辑揉在一个大函数里。你让 AI 解释它自己当时的意图，它说你上传代码时它就是这样的。这种状态下，任何一次修复都可能引入新的连带问题。

demo 能跑，更不等于可复现。传统代码是确定性的，同样的输入应该产生同样的输出。AI 应用不是。模型有随机性，上下文窗口有截断，外部工具调用顺序可能变化，同一段 prompt 在不同模型版本下的行为可能完全不同。如果缺少记录，你根本不知道这次结果是在什么条件产生的。

所以我更愿意把“能跑”看成起点，把“可信赖”定义为三件事：行为可理解、变更可追溯、失败可复现。这三件事，都依赖可观测性。

1.3 真正缺的不是代码能力，而是可解释性

Vibe Coding 场景里，开发者缺的往往不是写代码的能力，而是对系统行为的解释能力。

你问 AI：“把 CSV 分组后合并成一个对象数组。” AI 写了。但为什么它选择保留这个字段？为什么对空值默认取空字符串？为什么递归深度只到两层？这些隐含决策，模型没有解释，代码里也不一定看得出来。

传统方式下，你可以通过阅读每一行代码推导出全部行为。AI 生成方式下，模型内部的推理过程我们看不穿。但有一点可以确定：模型内部不可观测，不代表系统行为不可观测。

我们可以从行为层面观察它：输入是什么，输出是什么，每一步耗时多久，失败发生在哪个环节，重试了几次，模型用了哪个版本，当时 token 消耗多少。把这些行为记录下来，黑箱模型就可以被当成一个“行为可控的组件”来使用。这正是可观测性要补上的位置。

提醒：可观测性的目标不是看穿 AI 内部在想什么，而是让 AI 的外部行为可以被记录、被关联、被复盘。

2. 可观测性为什么是 AI Engineering 的分水岭

传统软件开发已经形成了完整的可观测性体系。到了 AI 应用这里，这套体系不但依然适用，而且变得更重要。原因很简单：系统里的不确定性变多了，必须靠外部记录来弥补不可解释的内部过程。

2.1 从“能运行”到“行为可理解”

可观测性回答三个问题：发生了什么、为什么发生、影响有多大。这三个问题在传统系统里已经很难回答，在 AI 系统里更难。

一个模型调用可能经历这样的链路：用户请求进入服务、构造 prompt、调用模型、模型返回、解析 JSON、写入数据库、给前端返回结果。这 7 个环节里，任何一个都可能出问题。如果没有日志，你只能看到“最后结果不对”；日志不结构化，你只能靠 grep 关键字；日志之间没有 trace_id，你无法把一个请求的链路串起来。

真正的可观测性，意味着你能够随时回答：“这条输出为什么是这样？它经历了哪条路径？消耗了什么资源？失败卡在哪一个点？”不管代码是手写的还是模型生成的，只要系统运行在真实环境里，这些问题就必须有答案。

2.2 可观测性不是“多打日志”：Logs / Metrics / Traces

很多项目确实打了日志，但依然不可观测。因为可观测性不是“多几行 print”，而是三个维度互相配合。

• Logs（日志）：记录离散事件，比如一次请求进入、一次模型调用失败、一次重试发生。日志的价值在于定位细节，但难做趋势分析。
• Metrics（指标）：记录可聚合的数值，比如每秒请求数、错误率、平均响应延迟、token 消耗量。指标的价值在于发现趋势，但信息粒度粗。
• Traces（追踪）：记录一个请求从入口到出口经过的整个链路。一次模型调用中，prompt 构造、模型推理、后处理、外部工具调用，每一步都可以作为 span 记录。追踪的价值在于理解跨环节的因果关系。

对 AI 应用来说，Traces 尤其重要，因为一次生成往往跨越多层：模型调用、数据库查询、缓存、工具调用、后处理、前端展示。如果只有日志没有 trace_id，出了问题你只能看到各个模块自己的记录，没法拼出完整路径。没有完整路径，就无法判断“模型输出没问题，是后处理把它弄坏了”，还是“prompt 构造就有问题，模型回答自然偏了”。

2.3 AI 系统要多观察一层“意图”

传统系统观察的是参数、请求、数据库、CPU、内存。AI 系统还要观察另外一层：意图相关的输入和参数。

具体来说，你至少需要知道，这一次调用模型的 prompt 是什么，有没有被截断，用了哪个模型版本，温度是多少，最大 token 数是多少，上下文窗口占了多少，请求和返回各消耗多少 token。这些数据里，任何一个变化都可能让输出发生明显漂移。

如果你把温度从 0.2 改到了 0.8，输出不稳定，你可能误以为模型能力退化。如果你近期更新了 prompt 模板，模型输出明显变长，没有记录 prompt 版本，你就无法判断成本上涨的原因。可观测性在 AI 系统里多出来的这一层，本质上是把“模型生成过程的可复现条件”记录在案。

有了这层记录，你才能在队友问“这次结果为什么这样”的时候，拿出 trace 说：你看，请求长了 30%，上下文被截断，模型在缺少中间信息的情况下做出的判断。而不是只能说“我也不太清楚，它有时候就是这样”。

3. 给 Vibe Coding 加可观测性的最小闭环

Vibe Coding 项目通常很小，很多人听到“可观测性”会下意识觉得太重。但完整平台确实不必现在搭，一个最小闭环其实很轻：给请求加 trace_id，把日志变成结构化输出，在关键节点记录输入输出。这件事一两天就能做完，却能让一个 AI 原型从“能跑”跨到“可调试”。

3.1 先定义观察目标：输入、行为、输出

不要一上来就想“我要上日志平台”“我要接追踪系统”。先把观察目标定义清楚。对大多数 AI 项目，只需要盯住三个维度：

一个实用的判断标准：如果有人问你“这个系统为什么会这样”，你能否从已有的记录里拼出答案？如果不能，说明有个维度没覆盖到。

3.2 最轻量的技术方案：结构化日志 + trace_id

第一个最小方案，不需要引入专门的可观测性平台，只需要两件事。

第一，把日志从print改成结构化日志。结构化日志是一行 JSON，而不是一串拼起来的字符串。原因很直接：字符串日志只能靠人眼扫，JSON 可以被查询、过滤、自动聚合。日志量大之后，字符串日志就是噪音，结构化日志才是可分析的数据。

第二，每个请求或每次任务生成一个trace_id，从入口一直贯穿到出口。这样即使还没有接分布式追踪系统，你也可以通过 trace_id 把一个请求的所有日志捞出来。对应到 AI 任务里，可以是一次“生成文本”任务、一次“批量处理”任务，也可以是一个用户会话。

提醒：结构化日志不等于把所有变量都打出来。可观测性的价值在于信息可检索、可关联，而不是日志体积大。

3.3 一段可用的落地示意

下面是一段 Python 通用示例，只用了标准库，演示“trace_id + 结构化日志 + 错误记录”这个最小闭环。具体项目里，AI 调用 SDK 可能不同，但思路是一样的。

import json import logging import time import uuid # 配置为 JSON 结构日志的写法因语言和框架而异，但核心是“一行一个 JSON 对象” logging.basicConfig(level=logging.INFO) logger = logging.getLogger("vibe_app") def ai_process(prompt: str, context: str = "", model: str = "model-1") -> str: trace_id = uuid.uuid4().hex[:12] started = time.time() logger.info(json.dumps({ "event": "ai_process.start", "trace_id": trace_id, "model": model, "prompt_chars": len(prompt), "context_chars": len(context), })) try: # 这里是 AI 模型调用，具体 SDK 因项目而异 result = "生成的文本" # ... 调用模型并拿到输出 ... duration_ms = round((time.time() - started) * 1000, 2) logger.info(json.dumps({ "event": "ai_process.end", "trace_id": trace_id, "status": "ok", "output_chars": len(result), "duration_ms": duration_ms, })) return result except Exception as exc: duration_ms = round((time.time() - started) * 1000, 2) logger.error(json.dumps({ "event": "ai_process.error", "trace_id": trace_id, "error": type(exc).__name__, "message": str(exc), "duration_ms": duration_ms, })) raise

在真实 AI 调用场景里，还会额外记录模型参数和 token 消耗，例如：

logger.info(json.dumps({ "event": "model.invoke", "trace_id": trace_id, "model": model_name, "temperature": temperature, "max_tokens": max_tokens, "prompt_tokens": prompt_tokens, "completion_tokens": completion_tokens, "latency_ms": latency_ms, # 不要记录 prompt 的完整原文，避免敏感信息进入日志 }))

记录这些字段的价值是：一段时间后，当你发现某类请求变慢或输出变差时，可以按模型版本、prompt 长度、token 消耗做一次快速分析。如果这些字段缺失，你只能靠猜。

3.4 第一批观察节点放哪里

新手容易犯的错是打太多日志，或者到处都打。更合适的做法是先在四个节点埋点。

• 入口：任务刚开始时，记录输入摘要。
• 模型调用前后：记录模型名称、参数、耗时、token。
• 异常处理：所有except块里记录错误类型和 trace_id，不许用except: pass。
• 出口：任务结束时，记录状态和结果摘要。

先保证这四条存在，再考虑要不要加更多。很多 Vibe Coding 项目，尤其是内部工具和自动化脚本，有这个最小闭环就已经能解决绝大部分“这代码到底干了什么”的问题。

4. 常见坑点：很多 AI 项目 demo 完就死，问题出在哪

每次看到 demo 跑通后就放弃的项目，我都会先怀疑一句话：“我没有 log 也能跑啊，为什么这些工程化这么麻烦？” 这种观点忽略了系统进入长期运行后的场景。Vibe Coding 项目最容易在几个点上暴露出短板。

4.1 三类典型症状

第一类症状是输出不稳定。第一次跑结果很好，第二次跑结果却变了。你说模型随机，但说不清是什么参数导致的。没有记录温度、模型版本、上下文长度，你只能抱着“它就是抽了”的态度接受它。

第二类症状是任务中断后无法恢复。一个批量任务跑到一半挂了，重新运行时又从最早开始，重复消耗 token。因为没有 checkpoint，也没有 trace，你甚至不知道上次跑到第几条。

第三类症状是结果不可复现。同一条 prompt，在旧版本模型上生成的结果，到新版本模型上完全不同。没有版本记录，你就无法回溯“之前那个好结果是用什么模型生成的”。团队里换个人接手时，问题更严重——他说“这个输出看起来不对”，但没人能告诉他“对”的标准在哪。

4.2 一条能用的排查链路

当 AI 项目出问题，我一般不是先去改 prompt，而是按下面这个顺序排查：

1. 确认行为是否发生：先找 trace_id，确认请求有没有真正进入系统。
2. 排查输入：检查 prompt、上下文、输入长度、模型参数。很多时候不是模型变笨了，是输入条件和上次不同。
3. 排查模型调用层：模型调用是否成功、超时、被限流，返回的 JSON 是否合法，latency 和 token 是否异常。
4. 排查下游处理：后处理解析、数据库写入、外部工具调用是否报错。AI 模型输出正常，不代表下游代码能处理。
5. 排查资源与成本：CPU、内存、并发、token 消耗是否到达瓶颈。系统变慢不一定是模型问题，可能是批量任务把资源占满了。

这条链路的核心原则，是从“外部边界”往“内部细节”走。先确认整个输入输出有没有问题，再层层往下看。如果一开始就盯着 AI 模型调 prompt，很容易忽略真正的问题可能出在入口参数或者下游解析。

4.3 常见错误姿势

有些项目确实是打了日志，但依然让人无从下手，因为姿势不对。

一是只在报错时看日志。平时不知道正常时应该长什么样，结果报错日志和正常日志混在一起，你分不清什么才是异常。正确做法是正常路径也打摘要日志，建立基线。

二是日志里没有 trace_id。日志是打了，但每个模块各自打各自的，一个请求在服务端经过多个步骤时，无法串联。没有 trace_id 的日志，在排查多环节问题时几乎等于没有。

三是记录敏感信息。把 prompt 完整原文、用户输入、数据库连接串打进去，日志一开，隐私和账号风险全暴露。正确做法是记录摘要和长度，文本内容按需脱敏。

四是日志打太多。每个循环、每个变量都打一条，最后日志文件膨胀，检索效率极低，反而找不到关键信息。好的日志是克制的：只在有业务意义的事件上打点。

4.4 不是所有项目都需要完整可观测性

必须承认，可观测性是分级的。对于单纯的一次性脚本、本地数据清洗、几天就删的实验代码，确实没必要上一整套追踪系统。

• 一次性脚本、本地实验：结构化日志 + trace_id 就够了。
• 定期运行的内部工具：加指标、错误率、重试逻辑和简单 dashboard。
• 面向用户的服务：需要完整的 Logs + Metrics + Traces，配合告警。
• 强合规、高安全场景：还要增加审计日志、权限控制、敏感信息自动脱敏。

判断标准其实很朴素：这个系统会长期运行吗？别人会接手吗？失败的影响范围大吗？三个问题里有两个是“是”，就值得投入。如果只是临时脚本，那保持轻量即可，但至少别用裸print。

5. 从 Vibe Coding 到 AI Engineering，还差几块拼图

可观测性是分水岭，但不是全部。它解决的是“看得见、查得清”的问题，而真正的 AI Engineering，还需要把评估、版本、成本、安全这些因素纳入到统一的工作流里。

5.1 可观测性之外的工程拼图

第一块拼图是评估闭环。Vibe Coding 生成完代码，你得有办法验证输出质量。不一定是完整测试套件，但至少要有一条可重复的链路来判断“这版结果是否比上一版好”。常见的做法是给模型输出加结构化字段打分，或者跑一组固定的样例用例，观察它是否稳定产出预期结果。没有评估闭环，可观测性会退化成“记录了一堆数据但不知道什么是好”。

第二块拼图是版本控制。代码要进 Git，prompt 和模型配置也要进版本管理。很多 Vibe Coding 项目把 prompt 写在 Jupyter notebook 或 IDE 里，随手改一下，模型输出就变了，却没人知道是哪版改的。把 prompt 模板、模型名称、温度、上下文构造逻辑都纳入版本管理，才能和日志中的 model 字段对应起来。

第三块拼图是成本控制。AI 项目里，token 消耗是直接成本，而且会随调用量增长快速上升。Vibe Coding 原型可以忽略它，但一旦上线，就必须在指标里记录 token 消耗，设置调用上限，思考缓存和批量策略，不能让一个输出格式解析失败导致重复调用三五次。

第四块拼图是权限与安全。AI 生成代码时，如果 prompt 里包含不该暴露的数据，或模型调用逻辑可以触达内部系统，风险会成倍放大。日志里做脱敏、配置里做最小权限，是 AI 工程里最基本的防线。

5.2 团队协作里的关键转变：能复现、能解释、能交接

从一个开发者自己玩，到多个人协作维护，Vibe Coding 项目会遇到一个明显的协作瓶颈：怎么把“我不太清楚它为什么这样”变成可沟通的信息。

我之前遇到过类似场景：同事用 Vibe Coding 写了一个 AI 辅助的数据处理工具，demo 跑得不错。后来一次生成结果异常，我们俩坐在同一台电脑前，花了一个小时也没复现。因为他没记录模型版本，也没记录当时的输入上下文。最后只能重新写 prompt，靠聊天记录里的截图还原。这个教训很直接：Vibe Coding 生成出来的不只是代码，还有一系列决策点。这些决策点没有记录，交给别人时就是一个“不可解释的盒子”。

团队协作的转折点，在于把沟通方式从“让我看看代码”变成“让我看看 trace”。代码当然要读，但更有价值的是看到一个请求从进入到返回的完整路径。协作时能说“我把这次 trace 发给你，你检查一下第 3 跳的上下文构造”，比“你跑一次试试，我这边是正常的”要高效得多。

5.3 一条分层演进路径：脚本、服务、产品

我不建议任何项目都从第一天就搭完整的可观测性平台。更合理的方式是随复杂度递增，按阶段演进。

• 阶段一：脚本级别。目标是把“能跑”变成“能调试”。做法：结构化日志 + trace_id + 输入输出摘要。适合个人工具、原型验证。
• 阶段二：服务级别。目标是把“能调试”变成“能监控”。做法：接入 Metrics，记录请求量、错误率、延迟、token 消耗；把日志转存到一个可以检索的平台。适合内部工具、小规模服务。
• 阶段三：产品级别。目标是把“能监控”变成“能预警、能复盘”。做法：完整的 Traces、告警规则、dashboard、评估闭环、成本约束。适合用户模型、生产级 AI 应用。

每升一级，意味着投入增加，但也意味着系统可靠性的要求更高。Vibe Coding 项目最大误区，是认为原型验证之后可以直接进入生产。正确姿势是，先确认它值得继续演进，再按步骤补齐工程能力。

6. 关于实践，我的三条建议

如果上面的内容对你有用，最后我想收敛成三条可以直接落地的建议。它们都围绕同一个判断：Vibe Coding 的代码可以快速生成，工程能力却不能靠提示词生成。

6.1 把每次 Vibe Coding 当成一次需要审计的代码提交

不要抱着“反正是 AI 写的，看看能不能跑”的心态。每次让 AI 生成代码前，先写清楚一句话目标，以及验收标准。生成完成后，第一件事不是兴奋地跑结果，而是补上最基本的入参校验和日志。

这里最容易被忽略的是：AI 生成时，它默认你提供的需求是完整且明确的。它不会主动告诉你它跳过了哪些异常情况。你要做的，是把它生成的代码当成一个陌生同事提交的 PR 来 review，而不是当成“免费外包”。

6.2 从第一行代码开始写结构化日志

这是成本最低、收益最直接的工程化动作。无论项目多小，都不要用print来调试和追踪。至少从第一行代码开始，就用结构化日志，给每次任务生成一个 trace_id，把关键输入输出记录成 JSON。

可能有人觉得这样很繁琐。但 Vibe Coding 项目最大的特点就是代码迭代快，人工不可能逐行 read。日志是我们为数不多的“外部审计视角”。它可以帮你回答“它这次为什么不一样”“它在哪里失败了”“它消耗了多少资源”。没有这些，你只能对着黑箱猜。

6.3 先建立最小可观测闭环，再谈优化和扩展

不要在一开始就想着接全套指标、告警、dashboard。先建立一个可用的最小闭环。这个闭环的标准是：一条请求能被追踪，一个错误能被定位，一次输出能被验证。只要这三个能力存在，你就已经具备了把这套系统继续演进的基础。

等未来出现性能问题或成本问题，再按需要逐步增加 Metrics 和 Traces，不用一开始就做成重型系统。反过来，如果连最小闭环都没有，就急于优化 prompt、提升效果、扩大并发，那所有优化都会建立在“看不见的基础”上，很难持久。

说到底，Vibe Coding 是一个很值得长期关注的方向，但它的意义不是让我们绕过工程，而是让我们把更多认知从“怎么写代码”里解放出来，放到“我要什么，结果对不对，它为什么这样”这些更重要的判断上。可观测性正是承接这个判断的基础设施。AI 帮你把代码写出来了，工程还是要你自己扛下去。

如果你正准备用 Vibe Coding 做一个项目，我建议在第一次运行之前，先花十分钟回答一个问题：这个程序跑起来后，你会看到哪些记录？靠这些记录，你能不能向一个还没接触过项目的人解释，它为什么这样工作？如果能，说明你已经从 Vibe Coding 走向了 AI Engineering；如果不能，那今天就是补齐这一步最好的时间点。