2026年3月到7月间,我在105天里构建出一个86.16万行代码的生产级应用,涵盖696个用户故事和779个已合并的拉取请求——但我说不出这一切究竟花了多少钱。驱动这一切的是我那套自主软件开发生命周期(SDLC)框架的第一代版本,由Claude Code执行具体工作。那一代框架从未记录用量,而Claude Code默认30天的会话记录保留期,又抹去了唯一可能留存的痕迹。这笔账不是大概知道,而是彻底无从查证——因为记录本身已经不存在了。如果测量没有被写进流水线,它就等于从未发生。装了仪表的工厂工厂的第二代版本会在运行过程中自行记录账单。每一次阶段尝试(stage attempt)都会把它消耗的token(输入、输出、缓存读取、缓存写入)、成本、所用模型以及失败类别写入一本账本。第一代应用没有留下任何记录,是因为那套框架本身什么都不记;而这一代框架恰恰相反——它不记账就无法运行。在给任何东西定价之前,我得先把计量单位讲清楚。在这套流水线里,“故事”(story)就是我们熟悉的敏捷概念——从史诗(epic)拆解出来的一个小需求,带有验收标准,这些标准就是智能体判断该停手了的依据。“完成的定义”(Definition of Done)就是机器判断自己已经做完的方式。人类过去把故事打包进迭代(sprint)来管理交付节奏;而在这套流水线里,一次故事构建(story-build)指的是一个故事走完它自己完整的交付周期——先写测试、构建、通过覆盖率门槛、由专门的评审智能体评审、最后合并。这个周期也包括修复缺陷,以及当某个智能体返回格式错误的答复时的重新请求。同一时间最多有五个故事在各自隔离的git工作树(worktree)中并行推进。本文数据集覆盖了这家工厂在2026年6月25日至7月18日期间、在同一个代码仓库中构建的全部故事,包括17次运行、193次故事构建、374次阶段尝试和336份会话日志。6月的运行使用Claude Opus 4.8,7月换成了Claude Fable 5,较小的部分交给了Claude Haiku 4.5处理。用量数据同时存在于账本和原始会话日志里,但两者的数字并不一致。日志才是地面真相(ground truth),原因我会在后面解释。这家工厂本身(claude-code-config)以及它构建出来的代码仓库(local-code-bench)都是公开的;方法论部分附上了CSV数据和提取脚本,任何人都可以核对每一个数字。而文章开头提到的那个生产级应用仍然是私有的,所以本文里只能看到它的幽灵。这家工厂总共消耗了5.957亿个token,交付了77个故事——平均每交付一个故事消耗770万个token。按官方标价计算,总花费为837.53美元,折合每个故事10.88美元。分子里包含了所有被浪费掉的token:5个最终标记为FAILED的故事、22次失败的阶段尝试、修复缺陷和重新请求所产生的循环,以及各种重试;而分母只统计真正交付成功的故事数量。在此前一篇文章里,我曾把每个故事的成本估计为几美元到几十美元。这次真正的计量结果是3.02美元到43.24美元,中位数9.56美元——说明我当时的估计基本站得住脚。表格里有两个发现让我意外。第一,故事点数几乎无法预测成本,中等和大型故事在中位数上只相差8%。第二,最贵的一个故事花了43.24美元,只是个3点的小故事,却撞上了一次评审重试和一轮缺陷修复循环。至于墙钟时间的均值大约是中位数的2.5倍,原因是那次通宵运行两次撞上了订阅套餐的限流窗口,卡住了好几个小时——这是计费机制造成的伪象,与智能体本身的表现无关。指标中位数均值最小值最大值每故事消耗token(百万)6.557.841.9924.48每交付故事的墙钟时间(分钟)19.748.87.6296.0每故事成本(美元,API等价)9.5611.023.0243.24表1. 按故事构建统计的可归因成本(n76,含5个失败案例;另有6个成功交付但未返回用量数据的故事,只出现在总量分母中)。价格采用运行当日Anthropic的官方标价。如果按这个比率去推算开头提到的那个幽灵应用的696个故事,大概相当于54亿个token的消耗——但我们永远不会知道真实数字了。工厂本质上是一台阅读机器这里正是我此前估计出错的地方。在那篇文章的算例里,我把缓存写入(cache write)当成免费的来定价——但它并不免费,而且成本占比一点也不小。智能体在每一轮对话中都会重新发送同样的指令和代码仓库上下文。API会把这部分稳定不变的上下文缓存下来,读取缓存内容的成本只有全新输入的十分之一;但把新内容写入缓存,反而要付一笔溢价。在全部token里,95.4%都是缓存读取。也就是说,工厂每写下或接收一个新token,就要重新读取大约73个缓存token。一座暗黑代码工厂,本质上是一台大部分时间在阅读、偶尔才打字的机器。表2的成本侧显示了我的估计究竟错在哪里:缓存写入只占token总量的3.3%,却占了账单的31.2%;缓存相关的流量整体占到成本的77%;而全新输入的成本占比只有1.6%,几乎是个可以忽略的舍入误差。类别token占比折算成本占比(美元)缓存读取95.4%45.9%缓存写入3.3%31.2%输出0.9%21.3%全新输入0.4%1.6%表2. 374次阶段尝试中的token类别分布。这种结构并不是这一条流水线独有的怪现象。在我用于开发框架本身的交互式会话里,缓存读取占比是96.4%;在那个幽灵应用残存下来的数据碎片里,这个比例是91.9%——三组独立样本、两代框架、两种工作模式,呈现出同样的形态。这看起来更像是智能体驱动开发消耗算力的一种内在属性,而不是偶然。最让我意外的实际结论是:**在智能体驱动的流水线里,真正的成本优化其实是缓存管理,而不是精简提示词。**上下文纪律、对缓存层级的敏感度,以及不会把自己上下文窗口塞满的编排器(orchestrator),这些才是真正能撼动账单的因素;而把提示词写得更短,基本不起作用。诚实的分母失败率这个数字有两种读法。狭义的读法只统计被标记为FAILED的尝试,占token总量的5.0%;而诚实的读法要把所有返工、重试、缺陷修复循环、重新请求,再加上那些边流式输出token边崩溃的会话全部算进去,得出的比例大约是13%。公开场合的成本声明,很少会说明自己用的是哪一种读法。76个故事里只有34个是一次性顺利通过的,但返工的代价其实并不高,因为相对于整个构建过程,重试所占的比重很小。我把这13%看作是一种质量账单,因为正是这些质量门槛(gates)拦住了问题。在拆解原始数据的过程中,我发现了一个bug,它说明我自己的计量表在说谎。账本只记录了694.65美元,而日志显示的真实花费是837.53美元——账本漏记了大约六分之一的真实消耗。原因是:每当返回结果没通过校验,控制器发起的重新请求就会把原始阶段行的用量数据直接覆盖掉,于是那次代价高昂的失败会话就这样从账目上被抹去了;而那些直接崩溃的会话,则压根没有写回任何数据。一共有57次尝试受到影响——这也是为什么会话日志才是真正的地面真相。计量系统本身,和它测量的代码一样,也需要接受审计。于是我把这个bug作为一份缺陷报告提交给了工厂自己,交给它自己的修复流水线去处理。工厂把报告拆解成三个具体缺陷,并在一次合并的PR中修复了覆盖问题和模型记录问题(issue #480、PR #482,3200个测试全部通过)。工厂审计了自己的计量表并修复了大部分问题;至于如何找回崩溃会话丢失的花费记录,则作为待办事项排进了后续工作队列。真正付账的人是谁这一切的边际账单其实是零。我用的是每月200美元的Max 20x订阅套餐,这也是为什么本文里的每一笔美元金额都标注为API等价(API-equivalent)——它们是换算出来的价格,而不是我实际付出的钱。在这种订阅制下,真正的硬通货是配额,不是金钱。那次通宵运行两次撞上了5小时的限流窗口,有十次任务分派等了3.3到4.2小时才自动恢复。在包月固定费率之下,时间才是那道真正的围栏。把三个代码仓库的工作量滚动累加一个月来看,API等价总花费约为1088美元,而实际只付了200美元的订阅费——超过五比一。而且这还只是一个下限,因为更早的会话记录已经被清理掉了。这说明的是官方标价与实际定价之间存在不对称,而不是说Anthropic在补贴用户:标价从来不等于Anthropic的成本,里面本来就包含着他们的利润空间。一个独立职业者,或者一家小公司,能不能合理合法地靠这种包月套餐长期运作?套餐条款里没有任何东西阻止他们这么做——没有营收门槛,也没有公司规模上限。Anthropic划下的那条线是合同性质的,而不是财务性质的。个人席位适用消费者条款;而125美元的团队高级席位,买到的是商业条款和集中管理权限,但每一美元能换到的配额大约只有个人套餐的一半。往订阅阶梯上爬,买到的是治理能力,而不是更多token。这种包月套餐的窗口期不会永远开着——配额会收紧,价格档位也会重新调整。一家会给自己记账的工厂,会在这笔交易变得不划算的那一天立刻察觉到;而一家不记账的工厂,只会莫名其妙地感觉自己变慢了、变穷了,却搞不清原因。这个计量表改变了什么在为这篇文章分析数据的过程中,我发现文中所有数字都是在模型路由(model routing)功能关闭的状态下产生的。也就是说,本该交给Haiku级别模型处理的机械式合并操作,却按照高端模型的价格来计费,这部分占了全部token的12.3%。这意味着每交付一个故事消耗770万个token,这个数字本身还是未经优化的水平。你正在读的这篇文章,顺带发现了这个bug,而修复方案已经排进了工厂的待办队列。第二个发现来自把计量表对准我自己。在交互式会话中撰写工厂的需求规格——那些史诗和故事——一共消耗了大约1.9亿个token,相当于25个故事的用量(折算约160美元)。当实现变得这么便宜的时候,代码本身就不再是那个最昂贵的产物了。10.88美元的故事,和那861,601行永远无法核算的代码之间,真正的区别只有一个:一条流水线把自己的账记了下来,另一条没有。方法论数据集、提取脚本以及假设条件A1至A10,见gist.github.com/fxmartin。项目A是local-code-bench(完整数据见gist);项目B是claude-code-config(仅公开汇总数据,详细会话数据留作后续文章使用);项目C是一个私有生产仓库,未公开。地面真相以每次会话的modelUsage数据包为准,账本数据作为备用;374次尝试中有317次有完整的价格数据,未测量的部分均如实标注,不做估算填补。价格采用2026年7月19日抓取的Anthropic官方标价:Opus 4.8为每百万token输入/输出5美元/25美元,Fable 5为10美元/50美元,Haiku 4.5为1美元/5美元;缓存读取按输入价格的0.1倍计算,1小时缓存写入按输入价格的2倍计算。所有浪费都计入总额;每故事成本以总花费除以77个成功交付的故事计算(10.88美元;若剔除6个未返回用量数据的交付,则为11.80美元)。账本的模型列在历史记录中存在NULL值,模型归属信息来自会话日志,该记录问题已在PR #482中针对未来运行修复。主要数据以token为单位,美元数字均为按上述价格换算所得的API等价值;实际计费方式是包月订阅制,并非按量付费。我的解读这篇文章表面上是一份成本核算报告,但它真正想说的其实是测量本身的合法性问题。作者在开头就抛出一个刺眼的对照:第一代框架构建了86万行代码却留不下一分钱的账,第二代框架构建的规模小得多,却能精确到小数点后两位。这不是因为第二代花的钱更少,而是因为它把记账这件事变成了流水线的强制组成部分——没有账本就跑不动。这其实呼应了一句很朴素但常被忽略的道理:任何没有被计量的成本,严格意义上都不存在,它只是未知,而不是零。第二个值得琢磨的点是缓存经济学。多数人直觉里会觉得省钱的关键是少说话——提示词写短一点,输出精简一点。但数据显示,95%以上的token都花在了缓存读取上,而缓存写入尽管量小(3.3%),却吃掉了近三分之一的账单。这背后的机制其实很简单:智能体每一轮对话都要背一遍整个上下文(仓库结构、历史指令、规范文档),API通过缓存把这个重复背诵的成本降下来,但每次上下文发生变化(比如切换任务、进入新的工作树),就要重新写一次缓存,而这次写入是要付溢价的。所以真正决定账单大小的,不是你写了多少提示词,而是你的编排逻辑有没有让智能体反复、无谓地刷新它的记忆。这对所有在做agentic工作流(不只是写代码,也包括自动化研究、内容生产流水线)的人都是一个可迁移的教训。第三个点是诚实的分母这一节,其实是在讨论一个方法论问题:**失败率该怎么算才算诚实。**很多团队在对外宣传成本或效率时,只统计明确失败的部分,而把返工、重试、崩溃后未写回的会话这些沉默的浪费排除在外。作者把5%和13%两个数字都摆出来,并解释了两者的差异来源,这种两种读法都给出,并说明取舍依据的做法,本身就是一种研究方法上的严谨示范——尤其是在AI相关的效率宣传普遍存在选择性披露的当下。最后,关于订阅制与API计费的部分,揭示了一个容易被忽视的经济现实:**包月套餐的便宜,本质上是用配额和时间换来的,而不是无中生有的补贴。**当作者说标价不等于Anthropic的成本,而是包含了利润时,他其实是在提醒读者:五比一的划算只是相对于官方标价而言,一旦供给方收紧配额或者调整定价结构,这种套利空间随时可能消失。而一个自己记账的系统,能在套利空间收窄的第一天就察觉到,这本身就是构建自动化流水线时应该内置的预警能力。总体上,这篇文章用一个具体、可复现的案例(带着公开的代码库、CSV和提取脚本),把AI辅助开发到底多贵这个问题,从营销式的模糊表述,拉回到了可审计、可验证的量级讨论上。这种做法本身,可能比文章里任何一个具体数字都更值得借鉴。