你让 AI 写了个功能跑通了上线了结果半夜收到告警。你把报错信息贴回给 AI它改了一版重新部署又出现新的问题。这个循环很常见不是概率问题而是方法论问题Vibe Coding 阶段的反馈信号太弱。能运行不代表懂行为懂行为不代表能评估能评估不代表可回归。要跳出这个循环关键不是换一个更聪明的模型而是把可观测性从“事后的监控”提升到“事前的开发闭环”里。这篇文章围绕一个核心论点展开Observability 是把 Vibe Coding 变成 AI Engineering 的钥匙。我会先拆解三个概念之间的边界与关系再解释为什么没有可观测性的 Vibe Coding 会在生产环境翻车然后给出日志、指标、追踪、评估四个可落地的观测手段最后用 Java 场景演示如何在 AI 编程工具生成代码之后补上可观测性这一环。适合正在用 AI 辅助编码、又担心代码质量和可维护性的开发者也适合准备把 AI 生成的代码推向生产环境的团队。1. 核心概念速览先对齐 Vibe Coding、Observability、AI Engineering 的边界这个话题容易聊虚因为三个词都是热词。先把定义收紧后面才好讨论问题。概念核心含义关注的问题失败成本Vibe Coding用自然语言驱动 AI 生成代码开发者以“感觉对”为验收标准能不能跑起来低Observability通过日志、指标、追踪、评估等手段让系统内部状态能被外部观测系统发生了什么、为什么发生中AI Engineering把 AI 应用的开发、测试、部署、监控当成严谨工程是否稳定、可评估、可回滚、可维护高三者不是对立关系而是递进关系。Vibe Coding 改变的是代码生产方式从手写变成对话生成。AI Engineering 改变的是工程标准从“能跑”变成“可交付、可维护、可演进”。而 Observability 是二者之间的桥梁它解决的是 Vibe Coding 最大的短板——当你不完全理解 AI 生成的代码时你靠什么判断它是好的。很多人把可观测性理解成“监控系统”这是一个常见的窄化。监控解决“有没有出问题”可观测性解决“出了什么问题、为什么出现、能不能修复”。在 AI 生成代码的场景里后者比前者更重要因为你面对的常常是一个黑盒AI 为什么这么写它依赖了哪些上下文它在哪个分支上做了妥协这些问题注释里往往没有答案。从工程角度看Vibe Coding 的最大问题是反馈信号太弱。传统开发靠测试用例告诉开发者代码对不对靠 Code Review 判断代码好不好靠性能测试观察资源消耗。但 Vibe Coding 的默认反馈只有一个编译能不能过、运行崩不崩。这个信号根本没有覆盖质量、成本、稳定性、安全性这些生产环境真正关心的维度。可观测性就是来补信号缺失的。它把系统运行时的行为数据收集起来让“AI 生成了什么”和“系统实际表现怎样”之间建立一条可检查的链路。有了这条链路Vibe Coding 才能从“试错式开发”升级为“有反馈、有评估、可回归的工程实践”。2. 为什么没有可观测性的 Vibe Coding 会在生产环境翻车先说结论Vibe Coding 本身没有错错在直接把它当成生产级交付方式。没有可观测性兜底时它会在下面五个方面出现问题。第一生成代码不透明定位问题困难。AI 生成代码后开发者通常只看了入口和出口中间的逻辑依赖、异常处理、边界条件未必全都读过。线上出问题后排查者面对一段不熟悉、也不是自己写的代码要定位根因就会很吃力。没有 traceId、没有请求上下文、没有结构化日志排障基本靠猜。第二没有基线无法判断回归。一段由 AI 生成的代码第一次运行可能延迟 200ms第二次变成 600ms但代码完全没有变化。这种现象在调用大模型时非常常见因为模型推理耗时本身有波动。如果没有指标基线团队会误判为新版本引入了性能回归然后开始一次毫无意义的重写。第三不可复现。同一个请求模型可能给出不同输出同一个 Prompt换了模型版本结果也不同。没有记录模型版本、Prompt 版本、温度参数和随机种子出现问题后你没有办法在相同条件下复现也就无法验证修复是否有效。这是 Vibe Coding 工程化最容易被忽略的一点。第四成本失控。AI 生成的代码里常见“循环调用大模型”“失败重试不加退避”等写法。没有 token 消耗和调用次数这些指标成本上涨只会以月底账单的形式突然出现。到了账单出来再排查已经晚了。第五责任断层。AI 生成的代码容易缺少测试用例、边界校验和安全检查因为模型在生成时更多关注“完成任务”而不是“覆盖所有异常”。代码上线后如果测试、检查清单、日志监控都不完善出了问题就是整个团队一起背锅但又找不到真正的问题负责人。这五个问题不是模型能力问题而是系统可见性问题。模型生成代码越快系统生产出来的未知代码就越多对可观测性的依赖就越强。这也是标题里那句话的本质Observability 是 Vibe Coding 走向 AI Engineering 的必要条件。3. 可观测性如何改变 Vibe Coding 的开发闭环传统 Vibe Coding 的闭环是提出需求、让 AI 写代码、运行看一眼、能跑就提交。这个闭环的验收信号非常单一而且是由“感觉”驱动的。可观测性介入后闭环会变成这样生成代码 → 补齐观测埋点 → 运行并采集数据 → 评估质量与表现 → 判定是否达标 → 回归比较 → 上线持续监控。这个过程中最核心的变化是验收标准从“能跑”变成了“有证据表明它没问题”。证据来自结构化的日志、来自明确可度量的指标、来自一条完整的调用链、来自一个可重复执行的评估集。用这些证据做判断开发者的角色就从“相信 AI 的感觉”变成了“检查 AI 行为的证据”。这里有一个实际的落地技巧在每一轮 Vibe Coding 会话中把可观测性直接写进需求。不要让 AI 只生成业务代码而是要求它同时生成日志关键字段、错误边界和指标埋点。比如你可以直接告诉 AI请为这个接口增加请求级 traceId记录输入参数摘要、耗时、token 消耗并在失败时输出异常堆栈和上下文。让可观测性成为生成代码的默认组成而不是事后补加这个习惯会显著提高 AI 生成代码的可维护性。当开发闭环中有了证据AI Engineering 才真正开始。因为只有你可以观察 AI 生成的系统才能对它的行为做评估只有可以评估才能谈优化和回归只有可以回归才能放心地把代码交给生产环境。这是一条完整的链路缺失任何一环都会退回“靠感觉开发”的状态。4. 落地第一步在 AI 生成的代码里补上三种观测信号从操作层面看可观测性落地最少要做三件事结构化日志、指标采集、链路追踪。对 AI 应用来说还要加第四件事评估Eval。前三个属于传统分布式系统可观测性的基本功第四个是 AI 应用特有的。4.1 结构化日志让问题可以被检索AI 生成的代码最容易出现的问题是日志散乱、没有统一格式。把日志改造成 JSON 格式带上请求 ID、模型名称、调用耗时、token 用量等字段问题排查速度会明显提升。下面是一个 Java 项目中推荐的日志框架配置示例使用 Logback 输出 JSON 日志configuration appender nameJSON classch.qos.logback.core.ConsoleAppender encoder classnet.logstash.logback.encoder.LogstashEncoder customFields{service:ai-bff}/customFields /encoder /appender root levelINFO appender-ref refJSON/ /root /configuration配置完成后代码里就可以按统一字段打印结构化信息import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.slf4j.MDC; public class LlmOrderService { private static final Logger log LoggerFactory.getLogger(LlmOrderService.class); public String createOrderSummary(String userId, String prompt) { String traceId MDC.get(traceId); long start System.currentTimeMillis(); log.info(llm_call_start traceId{} userId{} promptLen{}, traceId, userId, prompt.length()); try { String result callLlm(prompt); long costMs System.currentTimeMillis() - start; log.info(llm_call_end traceId{} costMs{} resultLen{}, traceId, costMs, result.length()); return result; } catch (Exception e) { log.error(llm_call_error traceId{} error{}, traceId, e.getMessage(), e); throw e; } } private String callLlm(String prompt) { // 实际调用 OpenAI、Claude 或本地模型的逻辑 return ; } }这里的关键字段是 traceId。只要请求入口生成一个 traceId并向下游所有日志和后端调用传递排障时就可以把一次完整请求的所有日志串联起来不需要再靠时间戳和用户 ID 猜测关联。4.2 指标把成本和性能变成可读的数字日志解决的问题是“发生了什么”指标解决的问题是“趋势如何”。在 AI 应用中至少需要三个核心指标请求量、延迟分布、错误率。另外还要加上 token 消耗这是 AI 应用特有的成本指标。在 Java 生态里可以使用 Micrometer 暴露指标给 Prometheusimport io.micrometer.core.instrument.MeterRegistry; import io.micrometer.core.instrument.Timer; import org.springframework.stereotype.Service; Service public class LlmMetrics { private final Timer llmCallTimer; public LlmMetrics(MeterRegistry registry) { this.llmCallTimer Timer.builder(llm_call_duration_seconds) .description(LLM 调用耗时) .publishPercentiles(0.5, 0.9, 0.99) .register(registry); } public void record(Runnable runnable) { llmCallTimer.record(runnable); } }指标的作用是帮助团队建立基线。当你知道这个模型接口中位数延迟是 300ms、P99 是 800ms下一次 AI 生成代码把延迟优化到 200ms 时你就有依据判断这是优化还是噪声波动。没有基线所有性能优化都是在猜。4.3 链路追踪看清楚一次请求的完整路径AI 应用比传统 Web 服务更容易出现“慢请求”因为一次用户请求可能对应多次模型调用、多次工具调用、多次数据库查询。如果没有链路追踪根本看不出耗时在哪里。推荐使用 OpenTelemetry这是目前可观测性领域的通用标准。Java 服务可以通过以下方式启动时挂载 Agentjava -javaagent:opentelemetry-javaagent.jar \ -Dotel.service.nameai-order-service \ -Dotel.exporter.otlp.endpointhttp://127.0.0.1:4317 \ -jar ai-order-service.jar挂载后应用内部自动生成 traceId 和 span把一次请求内涉及的 HTTP 调用、数据库访问、消息队列操作串联起来。配合 Jaeger 或 Grafana Tempo可以直观看到请求在哪一段耗时最高。对 AI 应用而言还要在这个链路中增加模型的调用信息比如模型名称、Prompt 摘要、输入 token 数和输出 token 数方便后续分析。5. Java 场景落地让 AI 生成的 Spring Boot 服务带上观测能力搜索热词里经常出现“vibe coding java trae”说明 Java 开发者很关心怎么把 AI 编程工具用在真实项目里。这里给出一套可复制的做法无论你用的是 Trae、Cursor 还是 Copilot都可以照这个思路走。一次典型的 Vibe Coding 会话可能是这样的你让 AI 生成一个 Spring Boot 接口这个接口调用大模型来总结订单。AI 会生成 Controller、Service、一个 HTTP Client然后本地跑通。问题在于这套代码里没有链路追踪、没有 token 统计、没有错误分类。正确的做法是在生成业务代码时把可观测性需求一起写进 Prompt。比如请生成一个 Spring Boot 服务接口路径为 /api/order/summary。 需要满足 1. 请求入口生成 traceId 并放入 MDC。 2. 使用 RestClient 调用大模型接口记录模型名称、prompt 长度、耗时、token 用量。 3. 失败时抛出业务异常并输出包含 traceId 的错误日志。 4. 使用 Micrometer 统计每次调用的耗时和错误数。 5. 项目依赖中引入 Logstash Logback Encoder、Micrometer、OpenTelemetry。这样生成的代码就不只是能跑而是从一开始就具备可观测性骨架。然后在本机验证三个事情启动时能不能看到 JSON 日志、请求后指标是否出现在 Prometheus、异常请求是否带上了完整的错误上下文。Spring Boot 的启动配置也可以直接让 AI 帮忙生成。下面是标准的 application.yml 配置片段用于开启 Micrometer 的 Prometheus 端点management: endpoints: web: exposure: include: health,prometheus metrics: tags: application: ai-order-service启动后访问http://127.0.0.1:8080/actuator/prometheus如果能看到http_server_requests_seconds或自定义的llm_call_duration_seconds指标说明指标链路已通。再把接口接到 Grafana就能看到延迟和请求量的实时趋势。这套流程并不复杂但它改变了 Vibe Coding 的交付标准。过去你拿到 AI 生成的代码先看能不能跑现在你要先确认日志格式、指标端点、链路追踪是否完整。跑通只是第一步看得清楚才是提交的前提。6. LLM 应用特有的可观测性Eval 评估与质量追踪传统可观测性解决的是系统运行问题但对 AI 应用还有一个特殊问题输出质量。模型可能返回 200但回答却是错的、偏离主题的、甚至包含有害内容。回答好不好需要另一套评估机制。这就是 Eval评估。一个最简单的评估闭环至少包含三部分固定的测试集、可重复的评估流程、明确的通过标准。比如你用 50 条业务问题作为测试集每次修改 Prompt 或更换模型版本后跑一遍测试集人工或自动判断每条回答是否达标然后比较两个版本的通过率。在代码层面可以做一个非常轻量的评估工具类import json import requests EVAL_CASES [ {question: 订单超过 7 天未发货怎么办, expected: 退款机制}, {question: 如何修改收货地址, expected: 订单管理}, ] def run_eval(llm_endpoint): total len(EVAL_CASES) passed 0 for case in EVAL_CASES: resp requests.post(llm_endpoint, json{prompt: case[question]}, timeout30) answer resp.json().get(output, ) # 这里可以用一个简单的关键词规则做自动判断也可以接更强的模型做裁判 if case[expected] in answer: passed 1 return {total: total, passed: passed, pass_rate: passed / total} result run_eval(http://127.0.0.1:8080/api/order/summary) print(json.dumps(result, ensure_asciiFalse, indent2))Eval 的价值在于把“AI 输出好不好”这个主观问题变成可量化的指标。有了 pass_rate你才敢在 Vibe Coding 过程中频繁调整 Prompt、换模型、改代码结构。每次改动后跑一遍评估集通过率下降就说明这次改动有问题通过率上升才允许提交。还有一个工程细节容易被忽略请求中的模型版本和 Prompt 版本也要记录。很多团队排查问题时发现同一个接口昨天和今天的输出行为不一样但日志里没有版本信息完全无法判断是模型热更新、Prompt 修改还是代码变更。解决方法是把 model、prompt_version、temperature 等参数写入告警和日志的 metadata 字段。这是成本最低、收益最明显的一项改进。7. 资源占用与性能观察可观测性本身也有成本可观测性不是免费的它本身也会消耗 CPU、内存、存储和网络带宽。在 Vibe Coding 场景下AI 生成的代码如果滥打日志、指标维度过多、trace 采样率过高会产生大量数据账单和磁盘占用都可能成为新的痛点。观察可观测性自身的成本重点看四个指标每秒日志条数、每条日志平均大小、指标基数大小、trace 采样率。其中日志大小最容易失控JSON 日志确实可读性高但字段越多、单条越大存储成本越高。推荐的策略是把可排查性强的字段放入日志把高频变化的值放入指标把请求级完整链路用 trace 描述并通过采样控制数据量。采样方面不同的请求适合不同的策略。错误请求和慢请求建议全量保留因为这类请求是排障重点普通成功请求可以用 10% 左右的采样率。这个比例不是死规则需要根据实际情况调整。调整的目标只有一个在可接受的存储成本内保证最需要的排障数据不丢。token 成本也要纳入可观测性。AI 应用的成本大头通常不是服务器而是模型调用。建议在每次模型调用时记录 model、prompt_tokens、completion_tokens、total_tokens 这四个字段。有了这些数据可以用 Grafana 按天汇总成本趋势判断 Prompt 膨胀和重试策略是不是在悄悄抬高账单。8. 常见问题与排查方法Vibe Coding 加上可观测性之后会碰到一些典型问题。这里列出一份排查清单按“现象、可能原因、排查方式、解决方案”组织。问题现象可能原因排查方式解决方案同一段 AI 生成的代码反复出现同一种 bug提示词上下文不足AI 没有获取运行反馈查看结构化日志中异常堆栈和输入输出把失败样本作为 few-shot 回传给 AI并让 AI 补测试用例接口延迟忽高忽低模型负载、并发、重试策略查看 trace 中每段 span 耗时为模型调用设置超时、退避重试和缓存线上问题但不知道是哪个版本造成没有记录模型版本和 Prompt 版本在日志 metadata 中注入版本号请求上下文统一附加版本信息token 成本异常上涨提示词膨胀、无限重试、日志中误传完整 Prompt查看指标趋势并按 model 分组设置预算告警精简 Prompt对日志中的 Prompt 做截断和脱敏评估通过率波动大测试集不固定、模型温度过高固定评估集、多次运行取平均使用低温度或确定性采样维护静态版本测试集日志量暴增导致存储成本上升日志字段过多或保留时间过长统计单条日志大小和每日条数降采样、精简字段、设置分级存储保留策略traceId 丢失请求串联不上异步线程没有传递 MDC 上下文检查日志中 traceId 字段为空的比例使用线程池装饰器或显式传递 TraceContext这些问题的共性在于它们不是模型能力不足导致的而是系统缺乏观察手段导致的。只要补齐了日志、指标、追踪、评估这四类信号大部分问题都能在 10 分钟内定位到具体环节。9. 最佳实践把 Vibe Coding 当工程做把 Vibe Coding 从感觉驱动升级为工程驱动核心是建立约束。以下是推荐的一套实践集合团队可以直接拿来当迭代清单。第一任何 AI 生成的代码必须带可观测性骨架。至少包含 traceId、结构化日志、错误上下文三个要素。这条可以在团队规范里强制也可以写进常用的 Prompt 模板让 AI 每次生成代码时自动带上。第二保留一份最小可运行的可观测性配置。不管项目最后用哪种监控平台本地开发环境至少要能跑通 Prometheus 和 OpenTelemetry。否则等到上线前再接监控排障能力始终是缺位的。第三批量实验必须固定版本。Vibe Coding 过程中经常出现“改了一版 Prompt效果更好”这类判断。为了避免误判每次实验都要记录模型名称、Prompt 版本、测试集版本、评估结果。这样好与坏才算数。第四上线前必须跑评估集。不管代码是手写还是 AI 生成提交到生产前至少要跑一次回归评估确认通过率不低于之前基线的 95%。这是 AI 应用最接近“测试套件”的保障。第五涉及用户隐私的数据要脱敏。不要在日志里记录完整 Prompt、完整回复或用户个人信息。可以记录长度、哈希、关键标签但原始内容要进专门的受控存储并设置访问权限。第六接口服务要限制访问范围。如果给 AI 应用提供 API应该在网关层加上认证、限流和审计防止未授权调用和恶意刷量。这个问题在生产环境里很常见AI 接口比普通接口更容易被滥用也更难被发现。第七发布商用前做效果复核。即使评估集通过也不代表真实场景一定没问题。建议在灰度阶段继续采集质量指标用真实用户反馈做一轮人工抽检再逐步放量。10. 总结与下一步这个主题最值得尝试的点是把可观测性直接注入到 Vibe Coding 的工作流里从“AI 写完我看看”变成“AI 写完我验证”。Vibe Coding 不是不能用于生产但它必须有一套工程护栏而可观测性是这套护栏中优先级最高的一环。优先验证的第一个功能是 traceId。给每个请求建立一条完整链路先把“看得到”这件事做扎实。第二个要验证的是 token 成本指标这是 AI 应用最容易出问题也最容易被忽视的地方。第三个是评估集先把输出质量的基线建起来再谈 Prompt 优化和模型切换。最容易踩的坑是过度自信AI 生成代码速度很快很容易让人忽略验证环节。解决方法是把验证动作也交给 AI——让 AI 生成测试用例、生成评估集、生成日志和分析面板把验证本身变成一道自动化工序。后续可以继续扩展的方向包括用评估集做 Prompt 的 A/B 回归、结合 Langfuse 或 LangSmith 做更细粒度的推理过程追踪、把模型版本和 Prompt 版本纳入 CI/CD 流程做自动回归、用链路追踪数据驱动限流和缓存策略优化。这些都是在“能观察”的基础上逐步做起来的第一步永远是先让系统本身可见。