一张 800 美元账单与 AI 编程中隐藏的决策

我用 AI 辅助编程度过了一个收获颇丰的月，发布了几个产品，但两周后收到约 800 美元的 Vercel 账单还是让我吃了一惊。当时我正在开发 Journey Kits，编程助手推荐用 Vercel 部署。我一心想尽快上线，没有停下来检查服务、配置或成本。

第一个问题是构建机器。我发现项目使用的是 Turbo，一种高资源选项，而我的小项目并不需要它。Vercel 当时的文档将 Turbo 和按需并发构建列为新 Pro 项目的默认设置；设置因套餐而异，也可能变化，因此不能把我的经历推广到所有账户。

屏幕显示，Turbo 每构建分钟收费 0.126 美元，Elastic 每 CPU 分钟起价 0.0035 美元。两者使用不同的计费单位：一次 Elastic 构建可以使用多个 CPU，所以后者不一定等于每个实际经过分钟的总价。这些是 2026 年 4 月显示的数字，并非当前报价。Vercel 后来[宣布降低 Turbo 价格](https://vercel.com/changelog/reduced-pricing-for-turbo-build-machines)，从 4 月 27 日开始逐步实施。

我每天还会部署几十次，有时前一次构建尚未完成就启动下一次。这些重叠或重复的构建消耗了资源。我关闭了项目的按需并发构建，让构建排队，并可以等待或取消已被后续版本取代的构建。收费取决于套餐、机器和并发设置，所以同样的调整不会给所有人带来相同节省。

我本该检查这些设置，但当时我行动很快，照着 AI 编程助手的建议做。我也没有问过为什么构建要花好几分钟。发布账单经历后，Theo 和其他人建议我检查构建过程本身。按时计费的构建运行越久，费用就可能越高，因此除了选择费率，优化时长也很重要。

我称，这些调整让我的持续费用从每周数百美元降到几美元，而且仍有进一步优化的空间。部署列表显示，早期构建耗时超过三分钟，后来一些示例接近一分钟，其中一次不到一分钟。这些是该项目的观察结果，并非有保证的结果，也不是对每项调整效果的受控拆分。

有人建议使用 GitHub hooks 进行构建，再用 Vercel 部署，我说自己也采纳了这一建议。视频没有完整说明调整后的流水线，也没有证明每一项节省分别来自哪项变动。把工作转移到另一项服务可能只是转移成本，仍需要适当的检查和部署控制。

我依然喜欢 Vercel。一名支持人员建议我提交工单，当时我还没有这样做；我希望可能获得退款，同时也承认自己没有检查设置。我从账单中吸取的教训是：放慢一点，弄懂配置和取舍。

视频由 Recall 赞助。我介绍了它的知识库和上下文工具，包括搜索、媒体引用、API 和 MCP 集成。这些是视频中呈现的赞助商宣传，并非对产品的独立测试；提到的优惠折扣也有时间限制。

从更广泛的角度看，我认为 2025 年底 Claude Opus 4.5 推出后，AI 编程发生了变化：编程智能体让我能够在几天内开发出过去可能需要数月的产品。我也提到其他开发者说自己手写或手动审查的代码减少了。这些是特定工作流程中的观察，并不能证明所有开发者或团队都如此工作。

同样的速度也改变了我选择依赖项的方式。我的智能体经常推荐 Vercel、Resend、Fly.io 和 Railway 等服务，而我常常不检查套餐或配置就接受建议。这样一来，可靠性、适用性、支持以及依赖供应商的风险等问题就没有得到解答。我的个人项目风险相对较低；生产服务可能需要更仔细的评估。

我把生成式引擎优化描述为让服务更容易出现在 AI 生成的推荐中。一位 Resend 创始人的帖子称，用户数突破 200 万，而四个月前刚达到 100 万。帖子并未证明增长完全由 AI 推荐推动，尽管我认为获得编程智能体的推荐可以帮助服务触达更多开发者。

机会在于更多人能更快地创建软件。矛盾之处在于，我们也可能在委托决策的同时，对实现了解得更少。我引用一条社交媒体帖子，展示其统计的 2026 年 4 月初 AI 公司发布的功能数量，以说明速度；统计使用了发帖者选定的类别，并非全面的生产力比较。

我担心，随着生成代码越来越多，逐行审查会变得困难。我称其在物理上不可能，但这是我对规模的判断，而非普遍成立的证明：团队可以结合有针对性的人工审查、自动检查、测试和其他控制措施。即使自然语言规格也可能很长，而且部署后的行为并不总是与我以为自己提出的要求一致。

根据我的经验，编程产品越来越突出对话和最终产品，而不是源代码。我比较了过去以编辑器为中心的工作流程、自动补全和聊天，与较新的 Cursor、Codex 和 Claude Code 界面。这是对 2026 年展示的界面的设计解读；代码和改动仍然可以打开审查。

Cursor 示例把聊天放在主视图中，也可以在浏览器中显示生成的产品。在 Codex 示例中，更改过的文件以及新增、删除的行数出现在对话中，打开改动即可查看代码。我喜欢看到产品，但多出的一步可能让人更容易忽略具体实现。

有些人把这一转变比作过去一层层的抽象：开发者从低级指令转向更易读的语言，现在又可以用自然语言描述目标。我担心的是，不精确的请求或解释可能与实际交付的行为不同。代码有正式的语法和执行规则，但程序仍可能包含缺陷或产生意外行为。

模型的编程和意图理解能力正在提高，我预计会出现更多由 AI 编写和审查大部分代码的工作流程。这不意味着自然语言摘要自动证明代码正确，也不意味着所有前沿团队都从不阅读代码。实际问题是，是否有人能够验证上线内容的行为、依赖关系和后果。

Python 和 Ruby 等人类可读语言让人比使用原始机器指令更容易操作软件。我猜想，未来的 AI 系统可能使用更适合机器而非人类的表示，再由 AI 用自然语言解释结果。这是一种可能的未来，并非已经确立的方向，也不能证明人类无法检查它。

这种情况让我担心，因为解释可能不完整或不准确。回到我的账单，我认为基本功仍然重要：理解为什么选择某项服务、它的配置意味着什么，以及引入了哪些设计上的取舍。构建生产系统的人应该投入时间理解并验证它们。

如果你刚开始用 AI 开发，学习基础知识有助于作出这些决定。我正在发布更多产品，也享受这个过程，但当我知道一个产品大体能运行却没有完全理解它时，仍会感到不安。意外账单让我具体感受到了这种矛盾。