AI 快速交付应用，谁来掌控运维？

AI 速度下的隐忧：应用交付了，运维呢？

最近看到一个案例：有人用 AI 提示词在一个月内就交付了完整产品——认证、支付、仪表盘一应俱全，部署上线。这确实令人印象深刻，过去这需要团队干一个季度。但随后客户发邮件问导出功能为何失败，创始人却无从回答。不是暂时没答案，而是根本没有机制去获得答案：没有关联用户的错误日志，没有记录客户当时使用的套餐，也不清楚服务该客户的成本，所以连是否值得挽留都无从判断。应用是完成了，但围绕应用的业务运营却毫无“仪表盘”可言。

这不是技能问题。AI 很擅长构建用户能触摸的部分，却不会主动提供你需要的后台控制面板——那个让运营、成本、收入和增长变得可见的内部工具。没人提示，AI 就不会生成，于是大家普遍缺失这块。

数据揭示的真相：AI 是放大器，不是解决方案

Google 2025 年 DORA 报告调查了近 5000 名技术专业人士，发现 90% 在工作中使用 AI，日均约两小时。吞吐量上升了，但软件交付的不稳定性也随之增加。DORA 明确指出，速度提升并不能抵消这种不稳定性，其结论值得贴在显示器上：“AI 是放大器，它会放大你系统已有的特性。成功采用 AI 是系统问题，不是工具问题。”

安全数据也印证了这一点。佐治亚理工学院的 Vibe Security Radar 追踪与 AI 生成代码相关的 CVE，2025 年下半年约 18 例，2026 年第一季度就达 56 例，仅 2026 年 3 月就超过 2025 年全年。这令人不安：我们正在加速交付自己并不完全理解的东西。唯一的防御不是更多提示词，而是可观测性（instrumentation）。

为什么可观测性总被忽略？

可观测性不炫酷，没人会在发布推文中截图内部成本表。落地页会修改六版，运营视图却一版不改。模型只会给你所要求的，你要求“带订阅的 SaaS 应用”，它就会给你订阅功能，但不会主动问：“如果 Stripe webhook 静默停止触发，你如何察觉？”这种问题只来自实际踩坑的经验，而模型不会为此买单。

更关键的是，可观测性无法事后补填。你可以稍后加暗黑模式，稍后重构代码，但无法回到过去记录当时未记录的事件。数据库只知道当前状态，不知道状态如何演变。当有人问“改版后激活率提升了吗”，答案要么在第一天就开始记录的事件表中，要么就永远丢失。每一周没有可观测性，就是永久删除一段历史。

最小化可观测性：四个问题，四个小工具

你不需要复杂的仪表盘套件，只需回答四个问题，并用最小的工具满足它们：

• 最近 100 个错误，是否关联了用户 ID？
• 后台任务失败次数是多少？
• 依赖的第三方服务，最后一次成功 webhook 是什么时候？
• 每个客户的成本是多少？（这个可以后续补，但前三个必须立刻有）

其中，第三个最容易被忽视，却常常致命。支付 webhook 不会宣告死亡，它们只是停止，你可能三周后对账时才发现。一行记录“stripe · 最后事件 · 14 分钟前”比任何图表都更有价值。

成本失控的警示

Flexera 2026 年云状态报告（753 位云决策者）显示，估计浪费的云支出上升到 29%，逆转了五年改善趋势，85% 的受访者将云成本管理列为首要挑战。这些组织有 FinOps 团队和成本仪表盘，有工具却仍泄漏近三分之一。如果产品调用模型 API，成本波动会更剧烈。

给开发者和 AI 使用者的建议

• 在第一天就添加基础日志和错误追踪，不要等“以后再说”。
• 主动向 AI 提问，比如“我如何监控 webhook 失败？”而不是只描述功能。
• 将可观测性视为系统设计的一部分，而不是附加项。
• 定期检查成本表，了解每个客户的实际服务成本，避免盲目留存。

AI 能加速构建，但无法替代你对系统的理解。仪表盘虽不炫，却是业务生存的底线。