AI Coding 时代，工程师要学会用可观测性管理半黑盒代码

核心摘要

• AI Coding 提高了代码生产速度，但人理解系统的速度没有同步提高，软件会越来越像“半黑盒”。
• 半黑盒代码不是完全不可读，而是实现细节、异常路径、历史兼容逻辑和真实流量行为不再完全由工程师脑内推导。
• 在 AI 辅助开发场景下，可观测性不应只用于线上排障，而要前移到设计、开发、Review、灰度和发布验证全过程。
• 日志、指标、Trace、配置变更和业务结果需要组成证据链，用来验证代码是否按预期运行，也用来快速排除错误归因。
• 工程师未来的竞争力，不只是会不会用 AI 写代码，而是能不能把 AI 生成的代码纳入可靠的工程反馈系统。

过去这些年，我一直在做监控和可观测性相关的事情。从 Open-Falcon 到夜莺监控（Nightingale），我经历过很多企业监控系统的演进，也见过很多线上事故的排查过程。

最近 AI Coding 发展很快，我越来越觉得，可观测性这个领域可能会迎来一个新的变化。

以前我们说可观测性，更多是在说线上系统出了问题之后，怎么通过指标、日志、链路追踪快速定位问题。这个逻辑当然还在。但 AI Coding 普及之后，可观测性的价值可能不只是“排障工具”了，它会变成工程师管理复杂度的一套基础能力。

原因很简单：代码生产速度变快了，但人理解系统的速度没有同步变快。

AI Coding 带来的核心变化：代码更快，理解更慢

过去工程师写代码，虽然慢一点，但实现过程基本是自己一步一步推出来的。代码为什么这么写，边界条件怎么处理，异常路径在哪里，自己心里大概有数。

现在不一样了。

很多时候，工程师描述一个需求，AI 很快就能生成一段实现。工程师看一遍，改几处，测试通过，PR 合并。效率确实提高了。

但这里面有一个新的问题：工程师可能知道自己想要什么，却未必完全理解 AI 帮他生成的所有实现细节。

当然，工程师可以逐行阅读理解。但是 Review 的速度会拖慢项目迭代速度，所以使用 AI Coding 之后，团队自然而然会使用 AI Review，进而导致工程师对实现细节的了解越来越少。

这不是说 AI 写的代码一定不好。恰恰相反，很多代码看起来挺合理，局部测试也能通过。真正麻烦的是，它可能在某些边界条件、异常路径、历史兼容逻辑、生产流量模式下出现问题。

更麻烦的是语义错误。工程师没法把脑子里的所有信息都交给 AI，AI 也无法承载人脑几十年的上下文。如果信息传递不准或遗漏，AI 就容易写出“语法正确、测试通过、业务语义不完全正确”的代码。

这类问题最难处理。因为它不是那种一眼看上去就错的代码，而是“看起来差不多对”的代码。

Stack Overflow 2025 开发者调查里有一个现象很有意思：不少开发者认为 AI 工具能提升效率，但也有大量开发者提到 AI 给出的答案经常“差一点就对”，调试 AI 生成代码也会消耗额外时间。

这其实说明了一件事：AI Coding 带来的核心挑战，不是代码能不能生成，而是生成之后谁来理解、验证和负责。

软件正在变成半黑盒

我觉得“半黑盒”这个词，可能会越来越适合描述 AI Coding 时代的软件。

它不是完全黑盒。代码还在那里，工程师仍然可以读，测试也可以跑。

但它也不再是过去那种完全由工程师自己推导出来的白盒系统。实现细节里会有越来越多 AI 生成的部分，越来越多快速接受的建议，越来越多“当时看起来没问题”的改动。

当代码规模变大、迭代速度变快之后，工程师很难再靠脑子记住所有逻辑，也很难只靠静态阅读代码理解系统行为。

这时候，我们需要换一个思路。

不要试图通过“把每一行代码都完全看懂”来获得安全感，而要通过“让关键行为在运行时可验证”来管理复杂度。

这就是可观测性要发挥作用的地方。

AI Coding 风险与可观测性治理总览

AI Coding 的风险不是一个单点问题。它会同时出现在代码理解、语义实现、上线验证、事故定位和责任归因里。可观测性要解决的，也不只是“有图可看”，而是把运行时事实补齐。

这个表背后的意思很简单：AI Coding 让代码生成更快，可观测性要让系统行为更可验证。

可观测性不应该只是运维的事

很多团队过去把可观测性当成运维平台，或者线上出了问题之后才用的工具。这种看法在 AI Coding 时代会越来越不够。

如果代码生成速度越来越快，可观测性就必须前移到开发过程里。

一个工程师在提交一个重要变更时，不应该只问三个问题：

• 代码能不能跑？
• 测试有没有过？
• Review 有没有通过？

还应该问另外几个问题：

• 这个功能上线后，我怎么知道它真的按预期运行？
• 如果它影响了性能、错误率、资源消耗，我能不能第一时间看出来？
• 如果线上出了问题，我能不能证明问题是不是这次变更导致的？
• 如果不是我这次变更导致的，我有没有证据说明问题在哪里？

这几个问题，才是 AI Coding 时代工程师真正需要补上的能力。

代码可以由 AI 辅助生成，但运行时行为必须被工程师掌握。

每个重要变更都应该带着可观测性一起上线

我认为，未来一个比较健康的工程习惯是：每个重要变更都要带着可观测性设计一起上线。

也就是说，工程师写功能时，就要顺手想清楚：

• 这个功能的关键路径是什么？
• 正常情况下应该产生什么指标？
• 异常情况下应该打出什么日志？
• Trace 里能不能看出它经过了哪些逻辑分支？
• 有没有业务层面的成功率、失败率、耗时、数量变化？

如果这个功能是 AI 辅助生成的，这件事反而更重要。

因为人对实现细节的掌控变弱了，就更需要通过运行时信号来验证它。

过去我们常说“测试是质量的一部分”。现在可能还要加一句：可观测性也是质量的一部分。

测试更多是在上线前证明“它大概率能跑”。可观测性是在上线后证明“它在真实世界里正在正确运行”。

这两者不是替代关系，而是互补关系。

用日志、指标和 Trace 管理半黑盒代码

半黑盒代码的难点，不是完全无法观察，而是静态代码阅读不足以解释真实系统行为。工程师需要把关键行为转化为可查询、可关联、可验证的运行时信号。

日志：解释发生了什么

日志适合记录关键决策、异常上下文和业务语义。AI 辅助生成代码之后，日志尤其要覆盖那些“看起来没问题、但语义可能错”的地方。

例如：关键参数是什么、命中了哪个分支、为什么走降级逻辑、外部依赖返回了什么、异常输入是否被识别。这些内容不应该只停留在代码注释里，而应该在必要时出现在运行时日志里。

指标：判断影响有多大

指标适合回答趋势和影响范围问题。一个 AI 辅助生成的变更上线后，工程师至少应该能看出错误率、延迟、吞吐、资源消耗和核心业务数量是否发生变化。

如果没有指标，团队就很容易陷入“感觉没问题”或者“可能是它导致的”的争论。指标的价值，是把争论变成可比较的事实。

Trace：还原请求经过了哪里

Trace 适合还原一次请求的完整路径。它可以告诉工程师，请求经过了哪些服务、卡在哪个环节、哪个依赖变慢、哪个分支耗时异常。

在半黑盒代码里，Trace 的意义会更大。因为工程师未必完全记得每段 AI 生成逻辑的细节，但可以通过 Trace 看到真实请求是否经过了预期路径。

验证语义：证明业务结果是否正确

AI Coding 最怕的不是语法错误，而是语义错误。语义错误的特点是：代码能跑，测试可能也过，但业务结果不对。

所以可观测性不能只停留在系统层。它还要覆盖业务层面的验证语义，比如成功率、失败原因分布、关键状态流转、核心对象数量变化、关键规则命中情况。

这些信号能帮助工程师回答一个更本质的问题：这段代码不是只“跑起来了”，而是真的“做对了吗”？

上线不是结束，而是验证的开始

AI Coding 还有一个影响：它会让团队更频繁地发布。

发布越频繁，单次发布的心理重量可能会下降。大家会觉得，反正改动不大，反正 AI 也帮忙写了，反正测试也过了，先上再说。

这时候最危险。

软件质量不是靠“感觉应该没问题”保证的，而是靠一套反馈系统保证的。

所以我更倾向于把上线看成一次受控实验。

一个变更上线之后，我们应该观察一段时间：

• 错误率有没有变化？
• 延迟有没有变化？
• 资源消耗有没有变化？
• 下游依赖有没有异常？
• 核心业务指标有没有波动？
• 用户行为有没有异常？

如果有异常，要能快速把它和这次变更关联起来。如果没有异常，也要能用数据证明它确实没有造成明显影响。

这就是工程师在 AI Coding 时代需要建立的新工作习惯：不是写完代码就结束，而是完成从代码到运行时反馈的闭环。

工程师需要用证据链自证清白

线上出了问题，最常见的场景是什么？

大家先看最近有没有发布。然后开始问：是不是这个服务的问题？是不是这个人刚才改的？是不是这次需求引入的？

在 AI Coding 时代，这种情况可能会更多。因为代码变更更多，变更频率更高，每个人都可能在短时间内合入更多代码。

这时候，工程师要自证清白，不能靠解释。

你说“我觉得不是我的问题”，没有用。你说“这块逻辑我看过，应该没事”，也没有用。

真正有用的是证据：

• 这个版本是什么时候上线的？
• 上线后错误率有没有变化？
• 相关接口的 P95、P99 有没有变化？
• Trace 显示耗时卡在哪个服务？
• 日志里异常参数是从哪里来的？
• 配置有没有变更？
• 数据库有没有慢查询？
• 依赖服务有没有抖动？

这些东西串起来，才是一条证据链。

我觉得未来工程师的一个重要能力，就是用可观测性数据构建证据链。

不是为了甩锅，而是为了更快缩小问题范围，让团队少一点争论，多一点事实。

一句话：AI 可以帮工程师更快地产生代码，但工程师必须用可观测性证明这些代码在真实世界里是可靠的。

可观测性会成为 AI Coding 的仪表盘和自动刹车系统

AI Coding 的发展趋势挡不住，也没有必要挡。

代码生成会越来越快，工程师会越来越多地借助 AI 完成日常开发工作。真正的问题不是要不要用 AI，而是用了 AI 之后，软件工程体系能不能跟上。

如果没有测试，没有 Review，没有灰度，没有可观测性，AI Coding 只会让不确定性更快进入生产环境。

但如果工程体系足够成熟，AI Coding 会是很大的生产力提升。

这里面，可观测性扮演的是一个很关键的角色。

它是仪表盘，让工程师知道系统正在发生什么。

它也是自动刹车系统，用来发现并阻断不合理的变更。

更重要的是，它是一套证据系统，让工程师在半黑盒的软件复杂度面前，仍然能用事实管理系统。

我一直觉得，监控和可观测性的本质，不是为了画更多图，也不是为了堆更多数据。

它真正解决的是一个朴素问题：当系统变复杂之后，人还能不能理解它、控制它、对它负责。

AI Coding 让这个问题变得更迫切了。

FAQ

AI Coding 时代为什么更需要可观测性？

因为 AI Coding 让代码生成更快，但工程师对实现细节、异常路径和真实流量行为的掌控不一定同步增强。可观测性可以把运行时行为变成日志、指标和 Trace 证据，帮助工程师验证代码是否真的按预期工作。

半黑盒代码是什么意思？

半黑盒代码不是完全不可读的黑盒。它的代码仍然存在，测试也可以运行。但由于实现细节越来越多来自 AI 生成、AI Review 或快速接受的建议，工程师不一定完整掌握每个分支、边界条件和历史兼容逻辑。

可观测性和测试是什么关系？

测试主要在上线前证明代码大概率能跑，可观测性主要在上线后证明代码在真实世界里是否正确运行。两者不是替代关系，而是互补关系。AI Coding 越普及，这个互补关系越重要。

工程师如何用可观测性自证清白？

靠证据链，而不是靠解释。版本发布时间、错误率变化、P95/P99 延迟、Trace 路径、关键日志、配置变更、慢查询和依赖抖动，都可以帮助团队判断问题是否由某次变更导致。

AI 生成的代码需要特别埋点吗？

不一定是“特别埋点”，而是重要变更都应该带着可观测性设计一起上线。对 AI 辅助生成的核心逻辑、异常路径、历史兼容逻辑和业务语义判断，更要确保有足够的日志、指标和 Trace 信号可以验证。

结论

未来工程师的竞争力，不只是会不会使用 AI 写代码，而是能不能把 AI 生成的代码纳入一套可靠的工程反馈系统里。

写代码会越来越快。

但理解系统、验证系统、解释系统，仍然是工程师的责任。

而可观测性，会成为这份责任最重要的基础设施之一。

作者简介：秦晓辉，ToB 软件创业者，长期关注监控、可观测性、RCA、SRE 方向。曾主导 Open-Falcon、夜莺监控等开源项目建设。极客时间专栏《运维监控系统实战笔记》作者，公众号 SRETALK 主理人。

参考资料：

• Stack Overflow 2025 Developer Survey: https://survey.stackoverflow.co/2025/ai
• Google DORA 2025 State of AI-assisted Software Development Report: https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/