过去这些年，我一直在做监控和可观测性相关的事情。从 Open-Falcon 到夜莺，我经历过很多企业监控系统的演进，也见过很多线上事故的排查过程。
最近 AI Coding 发展很快，我越来越觉得，可观测性这个领域可能会迎来一个新的变化。
以前我们说可观测性，更多是在说线上系统出了问题之后，怎么通过指标、日志、链路追踪快速定位问题。这个逻辑当然还在。但 AI Coding 普及之后，可观测性的价值可能不只是“排障工具”了，它会变成工程师管理复杂度的一套基础能力。
原因很简单：代码生产速度变快了，但人理解系统的速度没有同步变快。
代码写得越快，理解代码越难
过去工程师写代码，虽然慢一点，但实现过程基本是自己一步一步推出来的。代码为什么这么写，边界条件怎么处理，异常路径在哪里，自己心里大概有数。
现在不一样了。
很多时候，工程师描述一个需求，AI 很快就能生成一段实现。工程师看一遍，改几处，测试通过，PR 合并。效率确实提高了。
但这里面有一个新的问题：工程师可能知道自己想要什么，却未必完全理解 AI 帮他生成的所有实现细节。
这不是说 AI 写的代码一定不好。恰恰相反，很多代码看起来挺合理，局部测试也能通过。真正麻烦的是，它可能在某些边界条件、异常路径、历史兼容逻辑、生产流量模式下出现问题。
这类问题最难处理。因为它不是那种一眼看上去就错的代码，而是“看起来差不多对”的代码。
Stack Overflow 2025 开发者调查里有一个现象很有意思：不少开发者认为 AI 工具能提升效率，但也有大量开发者提到 AI 给出的答案经常“差一点就对”，调试 AI 生成代码也会消耗额外时间。
这其实说明了一件事：AI Coding 带来的核心挑战，不是代码能不能生成，而是生成之后谁来理解、验证和负责。
软件正在变成半黑盒
我觉得“半黑盒”这个词，可能会越来越适合描述 AI Coding 时代的软件。
它不是完全黑盒。代码还在那里，工程师仍然可以读，测试也可以跑。
但它也不再是过去那种完全由工程师自己推导出来的白盒系统。实现细节里会有越来越多 AI 生成的部分，越来越多快速接受的建议，越来越多“当时看起来没问题”的改动。
当代码规模变大、迭代速度变快之后，工程师很难再靠脑子记住所有逻辑，也很难只靠静态阅读代码理解系统行为。
这时候，我们需要换一个思路。
不要试图通过“把每一行代码都完全看懂”来获得安全感，而要通过“让关键行为在运行时可验证”来管理复杂度。
这就是可观测性要发挥作用的地方。
可观测性不应该只是运维的事
很多团队过去把可观测性当成运维平台，或者线上出了问题之后才用的工具。这种看法在 AI Coding 时代会越来越不够。
如果代码生成速度越来越快，可观测性就必须前移到开发过程里。
一个工程师在提交一个重要变更时，不应该只问三个问题：
- 代码能不能跑？
- 测试有没有过？
- Review 有没有通过？
还应该问另外几个问题：
- 这个功能上线后，我怎么知道它真的按预期运行？
- 如果它影响了性能、错误率、资源消耗，我能不能第一时间看出来？
- 如果线上出了问题，我能不能证明问题是不是这次变更导致的？
- 如果不是我这次变更导致的，我有没有证据说明问题在哪里？
这几个问题，才是 AI Coding 时代工程师真正需要补上的能力。
代码可以由 AI 辅助生成，但运行时行为必须被工程师掌握。
每个重要变更都应该带着可观测性一起上线
我认为，未来一个比较健康的工程习惯是：每个重要变更都要带着可观测性设计一起上线。
也就是说，工程师写功能时，就要顺手想清楚：
这个功能的关键路径是什么？正常情况下应该产生什么指标？异常情况下应该打出什么日志？Trace 里能不能看出它经过了哪些逻辑分支？有没有业务层面的成功率、失败率、耗时、数量变化？
如果这个功能是 AI 辅助生成的，这件事反而更重要。
因为人对实现细节的掌控变弱了，就更需要通过运行时信号来验证它。
过去我们常说“测试是质量的一部分”。现在可能还要加一句：可观测性也是质量的一部分。
测试更多是在上线前证明“它大概率能跑”。可观测性是在上线后证明“它在真实世界里正在正确运行”。
这两者不是替代关系，而是互补关系。
上线不是结束，而是验证的开始
AI Coding 还有一个影响：它会让团队更频繁地发布。
发布越频繁，单次发布的心理重量可能会下降。大家会觉得，反正改动不大，反正 AI 也帮忙写了，反正测试也过了，先上再说。
这时候最危险。
软件质量不是靠“感觉应该没问题”保证的，而是靠一套反馈系统保证的。
所以我更倾向于把上线看成一次受控实验。
一个变更上线之后，我们应该观察一段时间：
错误率有没有变化？延迟有没有变化？资源消耗有没有变化？下游依赖有没有异常？核心业务指标有没有波动？用户行为有没有异常？
如果有异常，要能快速把它和这次变更关联起来。如果没有异常，也要能用数据证明它确实没有造成明显影响。
这就是工程师在 AI Coding 时代需要建立的新工作习惯：不是写完代码就结束，而是完成从代码到运行时反馈的闭环。
工程师需要用证据链自证清白
线上出了问题，最常见的场景是什么？
大家先看最近有没有发布。然后开始问：是不是这个服务的问题？是不是这个人刚才改的？是不是这次需求引入的？
在 AI Coding 时代，这种情况可能会更多。因为代码变更更多，变更频率更高，每个人都可能在短时间内合入更多代码。
这时候，工程师要自证清白，不能靠解释。
你说“我觉得不是我的问题”，没有用。你说“这块逻辑我看过，应该没事”，也没有用。
真正有用的是证据：
这个版本是什么时候上线的？上线后错误率有没有变化？相关接口的 P95、P99 有没有变化？Trace 显示耗时卡在哪个服务？日志里异常参数是从哪里来的？配置有没有变更？数据库有没有慢查询？依赖服务有没有抖动？
这些东西串起来，才是一条证据链。
我觉得未来工程师的一个重要能力，就是用可观测性数据构建证据链。
不是为了甩锅，而是为了更快缩小问题范围，让团队少一点争论，多一点事实。
一句话：AI 可以帮工程师更快地产生代码，但工程师必须用可观测性证明这些代码在真实世界里是可靠的。
这也会反过来改变可观测性系统
如果这个判断成立，那可观测性系统本身也需要变化。
过去很多可观测性系统主要围绕资源和服务展开：机器、容器、接口、日志、Trace、告警。
这些仍然重要。但在 AI Coding 时代，仅仅观察服务是不够的，还要观察变更。
一个好的可观测性系统，应该能把代码变更、发布动作、配置变更、运行时指标、日志、Trace、告警和业务指标串起来。
它不应该只告诉工程师：“错误率升高了。”
它还应该帮助工程师回答：“错误率升高之前，系统发生了什么变化？这些变化里，哪个最可能相关？影响范围有多大？能不能回滚？有没有类似历史事故？”
也就是说，可观测性系统要从“看图工具”变成“工程证据系统”。
这对产品会提出几个新要求。
第一，它要更懂变更。不只是采集指标，还要知道版本、发布、配置、依赖和代码路径之间的关系。
第二，它要更懂业务。不只是 CPU、内存、QPS、错误率，还要能表达业务成功率、任务完成率、数据延迟、核心流程异常。
第三，它要更懂排障过程。不只是把数据摆出来，还要能自动整理时间线、异常点、影响范围和可能原因。
第四，它要能成为 AI Debugging 的上下文。未来 AI 不只是写代码，也会参与排障。但 AI 要想真正帮上忙，必须拿到高质量的可观测性数据。否则它只能基于几行日志猜测原因。
可观测性会成为 AI Coding 的刹车和仪表盘
AI Coding 的发展趋势挡不住，也没有必要挡。
代码生成会越来越快，工程师会越来越多地 leverage AI 完成日常开发工作。真正的问题不是要不要用 AI，而是用了 AI 之后，软件工程体系能不能跟上。
如果没有测试，没有 Review，没有灰度，没有可观测性，AI Coding 只会让不确定性更快进入生产环境。
但如果工程体系足够成熟，AI Coding 会是很大的生产力提升。
这里面，可观测性扮演的是一个很关键的角色。
它是仪表盘，让工程师知道系统正在发生什么。
它也是刹车系统，让团队在变化过快时能够及时发现风险。
更重要的是，它是一套证据系统，让工程师在半黑盒的软件复杂度面前，仍然能用事实管理系统。
我一直觉得，监控和可观测性的本质，不是为了画更多图，也不是为了堆更多数据。
它真正解决的是一个朴素问题：当系统变复杂之后，人还能不能理解它、控制它、对它负责。
AI Coding 让这个问题变得更迫切了。
未来工程师的竞争力，不只是会不会使用 AI 写代码，而是能不能把 AI 生成的代码纳入一套可靠的工程反馈系统里。
写代码会越来越快。
但理解系统、验证系统、解释系统，仍然是工程师的责任。
而可观测性，会成为这份责任最重要的基础设施之一。
作者简介：秦晓辉，技术出身的 ToB 软件创业者，长期关注监控、告警治理和可观测性方向。曾参与 Open-Falcon、夜莺监控等开源项目建设，也曾在极客时间撰写技术专栏。现在持续思考中国企业如何把监控系统升级为真正的可观测性和稳定性工程能力。
参考资料：
- 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/
