AI 开始替我们写代码后，我们停掉了哪些付费服务

HN Claude Code Adoption 2026-10-13T00:06:50.605164

我们的工程团队只有三个人，但过去四周里合并了 708 个 pull request。按标价算，基础设施和工具链（含 AI 订阅）每月花费大约 1500 欧元。这背后的大部分运维工作——从 Kubernetes 升级、CI 运行器，到日志排查和代码审查——现在都由 Claude 和 Codex 完成，我们只需其中一人把关。也正因如此，哪些服务还值得付费，发生了变化。

我是 Stefan Kirsch，amaiko 的 CTO 兼联合创始人。我在读物理时就第一次接触到 AI，从那以后一直看好它。我写了 40 年代码，完全不介意以后再也不敲分号。我在小创业公司和大企业都当过 CTO，在我带过的所有团队里，这一支人数最少、效率最高。另外两位是 Markus Heigl，拥有数十年经验的资深开发者；以及 Florian Schauer，我们的资深 SRE。

以下价格均为 2026 年 10 月的欧元标价，必要时按 1.10 的汇率从美元换算。估算值会单独标注。

服务器

我们租用了 16 台 Hetzner Cloud 服务器，分布在德国和芬兰。其中 11 台组成三个基于 Talos Linux 的 Kubernetes 集群：生产、内部工具集群，以及一个小型开发集群。预发布环境是生产集群里的一个 vcluster。另外 5 台跑 CI。OpenTofu 负责创建服务器，ArgoCD 负责从 git 部署其他所有东西。

集群里跑了很多服务，如果放在云上，这些本来会各自单独出现在账单上：CloudNativePG 管理的 Postgres、Keycloak、NetBird VPN、Gatus 做可用性检查、Renovate、k8up 做备份，还有我们的监控系统。

这些全由 Florian 管理，Claude 负责大部分实际操作——从 Talos 升级，到排查某个 rollout 为什么起不来。Claude 还会通过 Hetzner API 创建服务器。它从自己的 shell 环境里读取 token，所以没人需要把密钥粘贴到对话里。生产环境的变更走 git 和 ArgoCD，如果某个 agent 想重启、删除或同步生产环境里的任何东西，必须得到我们其中一人的明确许可。

按现在的标价，集群这一侧（11 个节点、11 个负载均衡器、约 1.5 TB 块存储外加一些对象存储）每月大约 480 欧元。

作为对比，我按同样的规格在 AWS 法兰克福区算了一遍：三个 EKS 控制平面、按 vCPU 和内存匹配的 Graviton 实例、11 个应用负载均衡器、NAT 网关、gp3 卷，再加上假设每月 2 TB 的出网流量。按需计费大约每月 3700 欧元，买一年 Savings Plan 是 3100 欧元，买三年是 2400 欧元；如果换成 x86 实例，按需计费约 4500 欧元。也就是说，Hetzner 的按需价格便宜约八倍，对比三年承诺价也便宜约五倍。

有两点要说明。Hetzner 的 CX 服务器用的是共享 vCPU，而 Graviton 的一个 vCPU 是完整的物理核心。我们的负载跑在共享核心上没问题，但这个对比并不完全对等。另外 Hetzner 今年涨了两次价：4 月涨了约 30%，已购服务器也在内；6 月 CPX 和 CCX 产品线的新订单涨了 113% 到 176%。

我们的 Windows CI 机器跑在更贵的一种机型上，因为便宜的那种没货了，而且最近有一笔订单返回了 resource_unavailable。Hetzner 最便宜的产品线目前根本下不了单。下周要是把我们的容量翻三倍，我没把握 Hetzner 能接得住。

我们本来就是 OVHcloud 的客户，用它做备份，也用来做最初的自托管模型实验。这两部分都没算进本文的总账里。我们整套环境都是代码，我觉得换到别的服务商大概一天就能搞定。服务商只需要给我们一台能 SSH 登录的服务器就行，Talos 和其他东西都在后面再装。

监控

指标进 Prometheus 和 Mimir，日志经 fluent-bit 进 Loki，链路追踪通过 OpenTelemetry collector 进 Tempo，最上面是 Grafana。整套都跑在内部集群里，长期存储放在 Hetzner 的对象存储上。这套东西是 6 月替换 SigNoz 的。SigNoz 问题不少，用起来也累，我们还得自己给它写 MCP 服务器。更重要的是，Claude 跟 Grafana 配合得好得多。我猜是因为 Grafana 用得太广、文档太多，模型在训练时见过大量相关内容。

过去七天里，这套技术栈每天吞下约 5 GB 日志和 7 GB 链路追踪数据，同时保存着大约一百万个活跃指标序列。它与 ArgoCD、Forgejo 和 VPN 共用的内部集群，服务器费用是每月 48 欧元。加上数据量和存储桶，监控部分的支出远低于每月 100 欧元；这部分是估算值，因为账单上没有任何项目按工作负载拆分开来。

在这样的数据量下，如果用托管服务、保留 30 天数据，费用大致是：

以我们目前的数据量，单单一个月的 Datadog 费用就够我们三个 Kubernetes 集群跑大约八年。其中绝大部分花在指标序列上：Grafana Cloud 每千个活跃序列收费约 5.90 欧元，而 Datadog 把 Prometheus 序列当作自定义指标计费，每一百个约 4.50 欧元。日志和链路追踪部分，在 Grafana 的账单里大约占 110 欧元。那个「10 万序列」的估算前提是，我们会先精简指标基数再迁移到托管服务。我们从来没有开过会讨论哪些指标值得保留。

我们的智能体自己会读这些数据。Grafana 的 MCP 服务器把 Loki、Mimir 和 Tempo 作为工具提供给 Claude，所以排查问题通常从 Claude 查询日志和链路追踪开始，而不是由我们某个人把片段粘贴到聊天窗口里。一个定时任务会扫描生产和预发环境的日志，按指纹把错误分组，然后为每个新出现的错误开一个 issue。上面那些数据量数字，就是我在写这篇文章时通过同一个连接查出来的。

托管厂商也有 MCP 服务器。对我们来说区别在于成本和数据放在哪里。一个智能体追一个 bug，很容易跑五十次探索性查询，而我们不按查询次数付费。日志存在我们自己的服务器上，只有查询结果会进入模型的提示词。

代码审查

CodeRabbit 的客服曾经说我们的用量「不太正常」。当时我们用的是 Pro+，是它那时候最大的自助服务套餐。通常一个上午它审查了前两三个 PR，然后就触发了速率限制，没审查的 PR 越堆越多。我们不合并未经审查的代码，所以它们只能等着，我们也只能等着。实际上大概每五个 PR 里只有一个能在我们需要的时候拿到审查结果。

CodeRabbit 的额度按开发者和小时计算。三个人、每人再带上好几个 agent，产出的 PR 和修复轮次远超这个额度能覆盖的范围。钱从来不是问题：按现在最高档的公开套餐，三个席位每月不到 200 欧元。

PR 开出来之后再审查，本身也有代价。每修一轮就要再推一次，CI 随之重跑，还要从按小时计的额度里再消耗一次审查。CodeRabbit 支持平台里也没有 Forgejo——就算前面都无所谓，一个月后照样得换掉。

现在审查发生在 PR 出现之前。Claude 干完一块活，先在本地分支上提交，再让 Codex 对着它跑：

codex review --base origin/main -c model_reasoning_effort="xhigh"

Codex 用 GPT-6.1 Sol 或 GPT-6 Astra 做审查，始终开到最高推理强度，绝不用小模型凑合。Claude 逐条处理结果：真问题就修，误报就写一段反驳。然后 Claude 恢复同一个 Codex 会话，让它对每条结论给出裁定：

codex exec resume "$SESSION" \
  "We addressed your findings in commit <sha>. Finding 2 is not a bug because ...
   Judge each of your findings: is it resolved? Did the fixes introduce anything new?"

如此反复，直到 Codex 接受每一处修复或反驳，且不再报出新问题。之后才推分支、开 PR。

之所以恢复会话，是为了让 Codex 的上下文里仍然保留它先前的结论、Claude 的回应和已做的修复。重新开一轮审查等于从零开始，很容易把已经被反驳的结论又提一遍。那些原本每轮都要重复的规则，写进 AGENTS.md，Codex 开工前会先读它。这些审查包含在我们的 OpenAI 订阅里，不额外花钱。

Git 托管与 CI

GitHub 出过几次故障，把我们的部署卡住。生产环境爆出严重 bug 时，我可不想把接下来的一个小时花在刷新 githubstatus.com 上。我们的 Actions 账单一个月快到 900 欧元，对三个开发者来说实在不便宜。托管 runner 也慢，Windows 以及 macOS、iOS 构建尤其慢。

自托管运行器（self-hosted runner）本可以降低成本和加快速度，但对服务中断毫无帮助，因为每个任务仍然依赖 GitHub 的控制平面。2025 年 12 月，GitHub 还宣布从 2026 年 3 月起对自托管运行器上的任务收取每分钟约 0.2 美分的费用，不到 48 小时就推迟了。我不想把预算押在一个已经试图按分钟对我自己的硬件收费的供应商身上。

于是我们搬到了 Forgejo。这是 Codeberg e.V.（一家德国非营利组织）旗下开发的 GPL 自由软件。它在我们的内部集群上以单个 Pod 运行，成本已经算在服务器开支里了。从 8 月起它就和 GitHub 并行运行，主分支同步镜像过去；10 月 7 日正式成为我们的主要代码托管平台，完整历史全部迁移：分支、标签、发布，每个 pull request 都保留原编号。写这篇文章时迁移完成还不到一周，所以半年后再来问我效果如何。我们的产品同事也在 Forgejo 里提交和跟踪 issue，没人额外为他们买席位。

CI 跑在自己的机器上：四台 Linux 服务器，合计 24 个并行任务槽；还有一台 Windows 机器，需要自定义安装，因为 Hetzner Cloud 没有 Windows 镜像。

我们的 macOS 运行器是办公室桌上的一台 M2 Mac mini，连着办公室 Wi-Fi。NetBird 把它和其他机器连起来，防火墙把它和办公室网络其余部分隔开。

这些加起来每月约 220 欧元，Mac 按三年折旧。GitHub 托管的运行器 Linux 上每分钟约 0.5 美分，macOS 上 5.6 美分。我们四台 Linux 服务器的花费，相当于每月约 21,600 分钟的 GitHub Linux 时长。

macOS 上的差距最大。按三年摊下来，一台新的 Mac mini（M6 芯片、16 GB 内存、512 GB 存储，不含税 1,066 欧元）的成本，大约相当于每月 530 分钟的 GitHub macOS 时长，也就是每天约 18 分钟。一台常开的 M2 Mac 放在 AWS 法兰克福区域，每小时约 0.95 欧元，最少按 24 小时计费，每月约 700 欧元。这笔钱差不多每七周就能买一台新的 Mac mini。

AI 订阅

我们每人有两个订阅：Claude Max 20x，每月约 180 欧元，用于开发，由 Claude Code 负责写实现；ChatGPT Pro，每月约 90 欧元，用 Codex 做代码审查。这样每人约 270 欧元，整个团队每月约 820 欧元。写代码这块我们没有按量付费的 API 开销，我平时同时跑五到九个智能体，额度一直够用。

这种分配跟工作量挂钩，因为写实现消耗的 token 远比做审查多。我希望有另一个模型家族来复核 Claude 的产出，同时保留两家供应商，万一某家改了条款，还有地方可以迁移。这事已经发生过一次：九月的 DevDay 上，OpenAI 推出了约 450 欧元的 Pro 档，同时下调了原本 180 欧元档所包含的用量（价格不变）。我们用的 90 欧元套餐没受影响。

条款变动是实实在在的风险，因为这些订阅的定价远低于 API 价格。ccusage 按 API 标价估算本地 Claude Code 和 Codex 的日志。过去 30 天，我个人的用量折合下来，Claude Code 约 9,000 欧元，Codex 约 680 欧元，而订阅费分别是 180 和 90 欧元。这种价格我认为撑不了多久。

人力

没有智能体的话，上面这套东西得靠人来做：要么养一支平台团队来运维，要么买托管服务，再配一支小一点的平台团队。做个对比，我估算托管方案每月约 5,000 到 5,400 欧元，还不含 macOS 和 Windows 的 CI。我们那 820 欧元覆盖的所有事情——从写代码、审代码到跑平台、看日志——原本都要靠人完成。问题是要几个人。

过去四周，我们三个人在两个仓库里合并了 708 个 PR，这不含机器人、发布 PR 和自动化配置。算下来每周 177 个，每人约 59 个，大家都是标准的 8 小时工作日。其中 511 个在应用仓库，每周 128 个。

LinearB 的 2026 基准把每个 PR 改动超过 228 行的情况归为「有待改进」。我们在应用仓库的中位数是 548，含测试和五种语言的翻译（25 分位 180，75 分位 1,523）。

作为基准，DX 测出的数据是：不用 AI 的开发者每周中位数合并 1.4 个 PR，每天用 AI 的是 2.3 个，Claude 重度用户大约 4 个。LinearB 把每周超过 2 个就算作顶尖水平。

拿 PR 数量来折算人力很粗糙。为了不让数字虚高，我只统计了应用仓库，而且对标的是每周 2 个 PR 的顶尖开发者——这已经远高于 1.4 的中位数——同时忽略了 PR 的大小。这样算下来，我们应用仓库的合并速度大概相当于 64 个这样的开发者。然后我再对 PR 数量覆盖不到的部分打个折扣，并加上一名平台工程师来运维托管服务：

工资这一列按资深工程师每月约 8,500 欧元估算，这是德国资深工程师的正常薪资加上雇主承担的社保部分，不含招聘、设备和管理的成本。我们自己的薪资也在这个区间。

协作成本完全没进模型。一个 22 人的团队要花大量时间开会、对齐进度、做人员规划。我们每两周开一次回顾会，平时还有一次关于工具链的例会。其他事情都是有事就拉个短会。

我会选 3× 那一行。这其实是个主观判断——取决于一个合并的 PR 到底代表多少实际工作量，你也可以选别的。按 3× 算，模型得出大约 22 人、每年多出约 190 万欧元的工资，而我们的订阅费是每年约 9,800 欧元。就算按 10× 那一行，团队也还有约 7 人。

按 3× 估算的每月成本：

代码审查与测试

我的每个 agent 都在自己的 git worktree（工作树）里、基于自己的分支工作，并运行各自的子 agent，所以我手头总有多个功能和修复同时推进。我通过它们的 PR 描述来跟踪进展。代码我早就不看了。在这个量级下我也看不过来，而且有了这些检查机制，我更信任 agent 审过的代码，而不是人审过的代码。做咨询那些年，我见过太多烂代码——一个人写出来，另一个人盖了章就过了。

应用仓库里有这些检查：

这些规则很严。我们的主分支上连一条 linter 提示都没有，更别说警告了，报错更是想都别想。

这套设置我们花了几个月。早在 7 月之前，我们就已经在用 agent 了，随着模型和运行框架（harness）越来越好，它们能独立完成的事也越来越多。7 月我们每周大约合并 100 个 PR；最近三周分别是 231、200 和 194 个。同期应用仓库里 PR 的中位改动行数从 428 涨到了 548。DX 在 2024 年 11 月到 2026 年 2 月间跟踪了 400 多家公司，这些公司对 AI 工具的使用平均上升了 65%，PR 吞吐量的中位数涨了约 8%。DX 认为，目前 AI 编程工具给多数组织带来的提升在 5% 到 15% 之间。

刚开始的时候，agent 只够干点小打小闹的活。最初的架构是我自己定的，早期很多代码也是我手写的。我觉得，正因为起步慢，这套设置才能运转得这么好。如果换成一个新项目，我还是会先慢慢来，然后再放手让 agent 去做。

在十几个需要四到八轮评审的 PR 里，某一轮发现的缺陷往往来自上一轮的修复。于是我们加了一份书面清单，让 agent 在提交任何修复之前逐条过一遍：还有哪些地方要跟着改，这次修复让哪些原本走不到的地方变得可达，以及改完的 diff 本身是否自相矛盾。

另外两条规矩也是这么来的。有一次我们合并了一个 PR，当时还有五个测试分片在跑。由于我们没把这些检查设为必需项，自动合并就直接放行了。现在 agent 通过一个小脚本合并：先重新确认 head commit 上的每一项检查都是绿的，然后只合并这个 commit。还有一种情况是：为修 bug 写的测试一直是「因为错误的原因」通过——有个测试只检查某个 key 存在，却不管它的值。现在每个修复都要做回滚验证：把修复回退掉，必须正好是为它写的那几个测试变红。

回滚率在每个月合并的 PR 中一直保持在 0.4% 到 1.1% 之间，而每周吞吐量翻了一倍。10 月到目前为止是 0.6%。

从 7 月至今，我们出过一次严重的线上事故。9 月 11 日，一次 NestJS 升级让我们的全局限流器连 WebSocket 消息也开始拦截，每来一条消息就抛异常，结果所有已经升到新版本的聊天应用都不再响应。Teams 机器人走的是 HTTP，还在正常回复，定时任务也没受影响。正因为这些回复还在，从表面看一切正常，我们花了将近两个小时才发现问题。发现问题后大约 40 分钟修复就上线了。

预发环境其实已经以同样的方式坏了两天。我们大意了，上线前没在那儿测。此前一段时间一直很顺，人就松懈了。现在 Claude 有了一个能操作我们 Web 应用的 CLI，可以自己跑预发测试。

接下来做什么

我们想在自己的硬件上跑开源模型，处理范围小、边界清晰的修复，全程无人值守。目前正在做实验，也有了第一批测试结果。

我们怎么测量的

查看原文