AI写的代码能过测试，为什么账单没人看？

大多数团队现在交付的代码比以往任何时候都多，其中越来越大的比例由 Claude 这类 AI 编程代理写成。人类审一遍，合并，上线。能跑，测试也过了。

然后没人再看它跑起来要花多少钱——云上的钱，以及围绕它的整套开发工具的钱。

工程师其实在意这件事，但工作流里没有任何环节告诉他们。写下这次改动的代理，永远不会知道它让某个数据库的读取量翻了一倍，也不会知道自己碰过的一个配置现在每小时被轮询一百万次。于是下一次改动，还是用同样的方式写出来，同样一无所知。

云账单还只是一部分。同一份代码也在推高周边工具的费用：每次推送消耗的 CI 分钟数，按主机、按 span 或按摄入 GB 计价的 APM 与可观测性，日志管道，错误追踪。对很多团队来说，这些工具在软件运营成本里占相当大的比重，而写代码的人对它们更没感知。

为什么云成本到不了代码那里

想想其他质量信号是怎么到达写代码的人手里的。测试挂了，PR 被挡住。延迟飙升，有人被呼叫，附带一条指向问题端点的链路。信号来得快，而且落在代码所在的地方。

成本不是这样运作的。它会在几周之后，以几张发票上的几个数字出现，分别来自云厂商、CI 平台和 APM 供应商，各自按自己的口径汇总。等到有人问起数据库账单或可观测性账单为什么涨了，造成它的那次改动已经是三个迭代之前的事。如果是人写的，人早就去做别的了；如果是代理写的，它对此毫无记忆。

本该存在的闭环，停在了半路。我们写，我们发，我们跑，我们甚至也在测量。只是从来没把测到的东西喂回下一轮写作。

代理看得见代码，成本工具看得见账单

奇怪的地方在于，信息其实已经存在，只是分住在两个从不交谈的地方。

编程代理看得见代码。它能读整个仓库，顺着调用图走，解释一个函数为什么存在。它看不见的是，这个函数一天运行四千万次，而且每次调用都打在一个付费 API 上。

FinOps 和成本工具看得见账单。它们能告诉你某个服务的 Secrets Manager 这一项上个季度翻了三倍，或者某个 Aurora 集群已经成了第三大支出项。它们说不出是哪一行代码造成的，也说不出修法长什么样。

有账单没代码，是一份报告；有代码没账单，是一次猜测。两边单独都解决不了问题。一份成本报告递给工程师，等于给了一张不知道从哪下手的工单；让编程代理去“降低成本”，它会去优化那些读起来像很贵的东西，而那很少是真正跑起来贵的东西。

三个真实例子

反复发现的模式几乎乏味，正因如此它们才活了下来：小、到处都是，只有把代码和账单并排放在一起才会显形。以下每个数字都来自账户自身的 AWS 账单数据。

• Secrets Manager 每个请求都调一次：一个 Lambda 处理函数或请求路径，每次需要凭证都去调 Secrets Manager，而不是只调一次。这项服务按 API 调用计费，成本就一比一跟着流量走。在合作的团队里，这通常是一年五位数的一笔支出，修起来大约五行代码。做法是把凭证缓存在模块级变量里，生产环境再加一个 TTL 让轮换后的密钥能被取到，或者直接用 AWS 官方的 Python 缓存库。改完之后，成本曲线不再跟着流量走。
• AppConfig 每次轮询都被计成一次完整下发：AppConfig 对两件事按差别极大的费率计费。问一句“有变化吗”每次请求 $0.0000002；真正收到配置本身要 $0.0008，贵约 4000 倍。预期用法是每次调用 GetLatestConfiguration 都返回一个新的 NextPollConfigurationToken，客户端下次轮询时把它带回来，AppConfig 就能以近乎为零的成本回答“没有新东西”，只有配置真的变了才计一次下发。一家美国金融科技公司的几个服务没有把这个 token 传下去，于是每一次轮询都触发一次完整下发并计费。一个月两百万次轮询，变成两百万次付费下发，而配置本身只变过几次。同一账户里其他正确处理 token 的服务，成本几乎为零。修法是六行代码：留住 token 并回传。AppConfig 账单降了 99% 以上，一年约 2 万美元。如果改客户端不现实，AppConfig Agent 会替你管理这个 token。
• Aurora 的存储设置没人回头看：一家全球消费品公司的 Aurora 数据库成本连涨数月，到了每月约 3900 美元。它的按请求 I/O 费用大约是计算加存储合计的十倍，而这正是 Aurora I/O-Optimized 存储适用的场景。切换只是一行配置，集群月成本降到约 500 美元。此后在多家公司见到同样的模式，合计一年六位数，每次都是一行。

这三件事需要的上下文并不相同，这点值得说清楚，因为一个好的编程代理会自己抓到其中一部分。写下代码的代理没有任何理由怀疑这些；而被叫来审查的代理大概能抓到第一个，也许第二个，第三个永远抓不到。即便抓到了，也只有执行数据能告诉你哪些修复值得做，以及一次改动是省钱还是更费钱。

把代码和生产之间的反馈接上

现在设想同一个工作流，把缺掉的那一半插进去：账单、资源清单和指标回流到写代码的地方。起草改动的代理能看到它正在碰的端点每秒跑几千次请求，以及每次请求花多少钱。审查者能在测试结果旁边看到预期的成本变化。改动落地之后，下一次改动是在知道上一次实际发生了什么的前提下写出来的。

从这里开始会复利。每一次修复都让系统多知道一点钱花在哪里，下一轮代码就从更好的数字出发。效率不再是每季度一次的 FinOps 清理，而成为团队交付方式的一部分。

已经在跑代理式软件工厂的团队，对安全和合规就是这么想的：把策略和扫描器放进闭环，代理生成的东西就会向通过它们收敛，不需要人逐行检查。成本值得同样的待遇。给这座工厂一个效率的北极星，用真实执行数据来衡量，里面的每个代理都会像收敛到安全合规代码那样，收敛到高效的代码。

Cloud ex Machina 正在做这件事。Dex 把代码与实时的账单、资源清单和指标数据连起来，找出只有同时看到两边才会显形的问题，并以 PR 的形式提交修复。面向 Claude 的插件则在代理写代码时把成本上下文带进去。改动的第一版不会总是高效的，但每一轮都以上一轮在生产里花了多少为依据，代码会随时间向效率收敛。工程师不用改变工作方式，账单照样改善。

这条闭环正在从云账单往外扩，CI、APM 和可观测性成本开始进入同一个平台。对很多团队来说，它们是软件运营成本的一大部分，而且同样直接跟着代码走：每次推送都跑的测试套件，热路径上的一行日志，按 100% 采样的链路。

怎么让 AI 生成的代码更省

用现有的东西就能开始接这个闭环：

1. 把成本放在延迟旁边。团队在哪里看服务健康，就在那里加上每个服务和每个请求的成本，包括每个服务驱动的 CI 与可观测性支出。如果它不在工程师真正会打开的看板上，它就不存在。
2. 在代码评审里盯住按量计费的调用。热路径上任何新增的付费 API 调用——密钥、配置、队列或第三方服务——都标出来，问一句它跑多频繁。按量计费的可观测性工具所收的日志、指标和链路也一样。
3. 把数字交给你的代理。能读用量和账单数据的编程代理，可以像推理测试那样推理成本。哪怕只是一份它能查询的只读导出，也是个开始。

至于 Aurora 什么时候该切到 I/O-Optimized：当按请求 I/O 在集群账单里占大头时。AWS 自己的经验法则是约占 Aurora 总支出 25%。低于这个比例，更高的计算和存储费率会超过省下的 I/O。判断要基于几个月的账单，而不是一个短快照：单次 I/O 尖峰会让一次切换看起来像省钱，实际却可能增加成本。