👉目录

1 需求设计：SDD token成本

2 需求拆解：契约模板锁定预期

3 开发阶段：幻觉与按需引用的代价

4 构建阶段：失败的成本放大器

5 代码审查：用另一双眼睛找漏洞

6 发布阶段：在终点算总账

7 需求变更：让每一次不白干

8 写在最后：三张牌怎么打

本文介绍了AI流水线从需求设计到发布六个阶段的成本真相，聚焦小公司和个体开发者的实际场景。文章系统性地剖析了三个烧钱黑洞——需求设计的token无上限、开发的上下文膨胀与幻觉返工、构建修复的死循环，同时给出了两个省钱杠杆——需求拆解的契约模板和独立AI代码审查，以及一个核算账本——成本快照与报告。同时，本文还提供了可落地的成本控制策略，包括SDD做契约不做全量探索、缩小上下文、成本守卫与次数边界双重阀门、知识库跨变更摊销等实用方法。

关注JeffckyShare，一手技术干货提前解锁👇

正文开始前说明一句：本文不是反对AI流水线，而是反对不计成本地用AI流水线。

如果你在大厂，预算以百万计，GPU集群随便跑，那下面的内容可能跟你关系不大。但如果你在一家十几人、几十人的公司，每月的AI账单领导重点关注——或者你是个体开发者，流水线跑着跑着钱花光了事情还没干完——那这篇文章就是写给你的。

AI流水线（需求设计→需求拆解→开发→构建→审查→发布）听起来很美，但它的成本结构不是均匀分布。有些环节是烧钱黑洞，token 消耗没有上限；有些环节是省钱杠杆，花小钱就能让上下游省大钱；还有一个环节几乎不烧钱，但它能让你看清楚钱到底花在了哪。

不是每个阶段都在烧钱，关键是你得知道哪些是坑、哪些是工具、哪些是账本。下面我们一个一个拆开看。

01

需求设计：SDD 的 token 账本

SDD（Specification-Driven Development）是一个开源驱动开发框架，专用于做需求规划、设计和计划。它的核心思路是让AI通过多轮探索（explore）来生成规格文档，再根据规格文档驱动后续开发。

1.1 问题：explore 没有上限

理论上没问题。但实际用下来你会发现一件事：explore这一步没有上限。

AI会遍历每个分支路径，深挖每个细节，反复推敲每个决策。看起来是在做”严谨的需求分析”，实际上是在疯狂消耗token。一轮explore几万token，几轮下来十几万token，而你可能只拿到了一个所谓”更全面”的需求文档。

烧钱黑洞①： 探索没有上限，token 消耗取决于 AI 的”想象力”，而不是你的控制。

1.2 场景：小公司的需求不是探索出来的

在小公司，需求不是在办公室探索出来的，是在会议室撕出来的。你花几百块钱的token费用让AI帮你探索需求边界，不如拉着产品和开发开个半小时会。需求文档真正需要的不是”全面”，而是明确。

1.3 方案：只做”执行契约”不做全量探索

所以在实践中，对SDD的使用策略需要调整：不要用它做全量需求探索，只让它做”执行契约”。

什么是执行契约？就是前后端开发之间需要对齐的接口定义、数据结构、边界条件。这些东西是团队协作的硬约束，必须明确，AI擅长做这个。而业务逻辑描述、产品愿景这种软内容，不值得让AI反复探索。

敲黑板：SDD的价值在于生成契约，不是生成文档。用契约思维替代探索思维，是控制需求设计阶段成本的第一课。

02

需求拆解：用契约模板锁住预期

需求设计阶段产出了执行契约（接口定义、数据结构、边界条件），那这份契约怎么变成开发 Agent 能执行的任务？

2.1 拆解模板产出两份东西

答案是拆解模板。把契约套入标准模板，自动化生成两份东西。拆解本身几乎不消耗 token（套模板、填字段是机械操作），但它避免的是下游几十倍甚至上百倍的返工 token——这才是杠杆的真正含义。

省钱杠杆①： 投入接近零，但放大了下游所有环节的成本效率——拆得准，后面全省。

一份是前后端对齐的规范。 接口的入参、出参、状态码、异常处理——每个字段都明确标注，前端该调哪个接口、后端该暴露哪个接口，白纸黑字写清楚。开发 Agent 拿到的是”执行标准”而不是”参考建议”。

一份是具体的任务计划。 每项任务都有明确的完成标准——契约对齐就算完成，不依赖 LLM 的主观判断。开发 Agent 不需要”猜”接口应该长什么样，照着模板实现就行。

2.2 不做拆解的后果：前后端对不上

没有这个环节会怎样？

开发 Agent 在没有契约约束的情况下，只能自己”想象”接口怎么设计。后端想象一套、前端想象另一套，两端大概率对不上。联调时才发现契约不一致，所有涉及接口的代码都要返工——修改代码、重新构建、重新审查，一个循环跑下来 token 消耗远超拆解阶段那点模板投入。

2.3 杠杆怎么用：细在接口约束

前面说过，SDD 的价值是生成契约。而需求拆解的价值就是把契约变成可执行的开发计划。它锁住了前后端的预期，避免了开发阶段因契约不清导致的返工。

这个杠杆怎么用？最关键的一点：拆解得够细，但细的不是功能逻辑，是接口约束。 每个接口的每个字段都明确指定，不让开发 Agent 有任何”自由发挥”的空间。自由发挥=不可靠=返工=烧钱。

敲黑板：需求拆解不消耗 token，但拆得不好会放大下游所有环节的 token 消耗。用模板锁住契约，让开发 Agent 从”猜着写”变成”照着写”。

03

开发阶段：幻觉与按需引用的代价

开发阶段是AI流水线中token消耗最大的环节，也是最能体现”成本失控”的场景。

烧钱黑洞②： 上下文越大单次越贵，幻觉越多返工次数越多，二者叠加就是成本失控。

3.1 按需引用：上下文越大成本越高

先说”按需引用”的问题。开发Agent在执行任务时，需要在上下文中引用相关文件。很多方案的做法是将整个代码库放入上下文，让AI自己判断需要看哪些文件。但这里有一个被忽视的问题：AI不会真的”知道”哪些文件是需要的，它只是根据文件名和路径猜的。

你给了它全部代码，它每一次推理都要扫描整个上下文。上下文越长，单次调用的成本越高，推理速度越慢。而且大量的无关文件不仅浪费token，还会干扰AI的判断——信息噪声会让输出质量下降。

正确的做法是指定引用范围，只给Agent需要的最小上下文。比如这个任务只涉及订单模块，就不要把用户模块的代码也塞进去。上下文每缩小一点，成本就下降一点。

3.2 引用文件不会执行：Front Matter 的陷阱

再说”引用文件不会执行”的问题，这个更隐蔽。

你在YAML Front Matter中描述任务步骤，AI会读取这些描述来理解任务。但这里有个可能会比较致命的误解：AI读取了描述，不代表它会执行描述中的步骤。

那正确的做法是什么？就是图片中描述的：以下步骤不可用摘要替代，必须逐步执行子文档中的完整内容。 在定义任务时明确标注哪些步骤是强制执行的，哪些是参考性的，让AI能区分”必做”和”可选项”。

如果缺乏这种强制标识，AI可能”看到”了”需要先运行测试再提交代码”这一行，但在实际执行时直接跳过了。不是因为它故意忽略，而是因为Front Matter对它来说只是”背景信息”而不是”执行指令”。AI对YAML Front Matter元数据信息的注意力很高，但对其中描述的步骤没有强制执行的意识。

敲黑板：开发阶段的成本控制核心是”缩小上下文+验证输出”。给AI的信息越少越准，幻觉的空间就越小。不要信任AI在复杂上下文中的判断力。

04

构建阶段：失败的成本放大器

开发Agent提交代码后，进入构建阶段。如果构建失败，成本就开始了连环放大。

烧钱黑洞③： 修复循环中的每一次失败都在叠加 token，死循环时成本没有上限。

4.1 修复循环：成本放大的起点

AI生成的代码有很多”不确定性”。依赖版本写错、引用路径不对、配置文件遗漏——这些问题在人类开发者身上也会出现，但AI的出错模式更加随机。同一个任务，人类开发者连续做十次可能错一两次，AI做十次可能每次错的点都不一样。

这意味着构建失败的概率更高，而每次构建失败都需要：

1. 分析错误日志（又是一轮AI推理）

2. 定位问题代码（回退到开发模式）

3. 修复后重新构建（重复的算力消耗）

4. 如果修复引入了新问题——循环开始，而且 AI 可能陷入两种死循环

第一种：规范缺失导致的反编译死循环。 比如场景：构建报错说封装包的命名空间找不到，AI 分析是”缺少引用”，但规范里根本没注明应该用哪个命名空间。它找不到正确答案，于是去”反编译”封装包陷入死循环。

第二种：AI 自行推断失误的死循环。 构建报错后 AI 凭经验猜测原因——改错文件、改错方向，新错误又触发新一轮猜测。每轮都在消耗 token，但根本问题一个都没修好。

4.2 次数边界：出口阀门

还有一个容易被忽略的原则：构建也要有边界。 不能允许流水线无限次重试构建修复，每多一次都是成本累加。建议明确一个硬性指标——比如连续构建失败3次，停止流水线，切换人工介入。这不是认输，是止损。

4.3 成本守卫：入口阀门

但这两道边界不是谁补充谁的关系，而是各自守在不同的关口。

次数边界是出口阀门：每轮修复结束后检查，如果已经失败了 3 次，说明修复方向不对，停下来让人介入。

成本守卫是入口阀门：每轮修复开始之前，先查当前会话的累计成本。如果已经超过预设阈值（比如 100 美元），停下来问用户一句——继续还是终止？不一定每一轮修复都很贵，但你不知道哪一轮会触发幻觉死循环，所以每轮开始前都得看一眼。

这个顺序很重要——先过成本守卫才能进入修复，修完再看次数到了没有。 钱不够了不让修，次数到了不让继续修。一个卡入口，一个卡出口，构建阶段的成本才算兜住底。

这个机制做起来很轻——成本守卫检测本身只需要读一次本地会话元数据，不调模型，几乎零开销。但它解决了一个实际问题：成本失控往往不是单次操作太贵，而是小金额的修复循环累加到了难以接受的数字。 在循环入口设一道卡，比跑完了再后悔有效得多。

敲黑板：成本守卫卡入口——超预算不让进；次数边界卡出口——超次数不让续。两个阀门各守一道门，构建阶段的成本才算兜住底。

05

代码审查：用另一双眼睛找漏洞

开发Agent写完代码，先让构建跑一轮。代码能编译通过，说明基础语法和依赖没有大问题，这时候再交给独立的 AI Agent 去做审查——不能让它自己审自己。

省钱杠杆②： 发现问题的阶段越靠前，修复成本越低。审查是构建之前最后一道低成本关卡。

同一个AI写代码和审代码，用的是同一套思维模式。它写的时候漏掉的东西，审的时候大概率也发现不了。这就是AI作弊——不是故意的，而是它天然看不到自己的盲区。

所以正确的做法是：用另一个独立的AI Agent来做审查。 新Agent没有被之前开发过程的上下文污染，带着一双”干净的眼镜”去读代码，更容易发现隐藏的问题。

审查聚焦三个方向：

5.1 方向一：任务闭环确认

需求拆解阶段产出了一份任务清单，开发阶段的每个Agent各领了几个任务去实现。审查时要做的，就是把这份任务清单和实际代码逐项对齐——任务清单上的每一条，在代码里是否真的实现了？实现得对不对？有没有漏掉边界情况？AI在实现复杂业务时，经常会”忘记”某些分支逻辑，但如果你不拿清单去对，这些遗漏在审查阶段是发现不了的。

5.2 方向二：防 TODO 逃逸

AI碰到拿不准或复杂的业务逻辑时，有可能会打个TODO标记先跳过去。这本身不是问题，问题是TODO打上之后就容易被遗忘。审查阶段需要做一次全量扫描，逐个确认：是真正的待办事项，还是AI留下的未完成代码。确认无误才能放行，带TODO的代码出不了审查关。

5.3 方向三：安全审查

AI写代码的能力很强，但安全是它的天然短板。安全需要”对抗思维”——谁会怎么攻击这段代码？输入从哪来、经过什么校验、最终落到哪里？AI擅长的是”实现思维”——把功能做出来就行。所以AI生成的代码在输入校验、权限检查、敏感信息处理这些方面往往是最薄弱的。独立的审查Agent需要专门针对这些安全盲区做扫描。

审查发现问题后，打回给开发Agent修复。修复完如果改动较大，可以再走一轮快速审查。但注意控制轮次——审查修复的循环本身也有成本，一般一轮足够，问题多了说明开发阶段的质量门禁没守住。

敲黑板：构建保证代码能跑，审查保证代码该跑。先自动检查再逻辑审查，两个环节各司其职，才是不浪费token的正确顺序。

06

发布阶段：在终点算总账

流水线走到发布阶段，前面五个阶段的成本像散落的珠子——需求设计花了多少？拆解和计划用了多少？开发阶段反复调用了多少次？构建失败了几轮？这些数据如果不能汇总，你永远不知道钱花在了哪里。

核算账本： 不烧钱，但让一切可量化。没有它，前面所有成本讨论都是拍脑袋。

所以发布阶段的实际工作不是部署，而是算总账。

 6.1 成本快照：每阶段埋点

在流水线的每个阶段埋一个成本快照工具，每次完成阶段性任务后，调用它把当前的token消耗、调用次数、耗时写入一个统一文件——比如 cost-snapshots.json。

 6.2 成本报告：终点算总账

等流水线走到终点，基于这份 cost-snapshots.json，汇总所有阶段的成本数据，输出一份完整的成本报告。报告里应该清晰列明：每个阶段消耗了多少token、花了多少钱、占总成本的比例、是否存在异常峰值。

 6.3 三个关键问题

有了这份报告，你才能回答三个关键问题：

1. 哪个环节最烧钱？ ——是不是需求设计阶段探索过度了？还是开发阶段反复返工了？

2. 哪些成本本可以避免？ ——比如某个构建失败导致的全链路回退，原本在本地预检就能拦住。

3. 下次怎么优化？ ——基于数据调整策略，而不是凭感觉拍脑袋。

敲黑板：不量化就无法优化。成本快照+最终报告是流水线的”记账本”，没有这个环节，成本意识就是一句空话。

07

需求变更：让每一次都不白干

前面六个阶段讲的都是单次流水线的成本控制。但还有一个场景绕不开——需求变更。

做过遗留系统的人都懂：项目跑了几年，文档早就过时了，唯一可信的就是代码。做需求变更时，AI 没有业务文档可以参考，只能去读代码、反向推断业务逻辑。这个过程很耗 token，而且读出来的东西，如果不用就白读了。

解决思路很简单：让 AI 在变更过程中沉淀知识，供下次变更复用。

怎么做？核心是四个环节。

 7.1 环节一：先读再用

每次变更开始时，不急着让 AI 直接写代码。先检查有没有之前沉淀的业务知识——如果有，加载当前变更相关的部分，让 AI 带着已有的理解去做变更。有了业务上下文，它读代码就能更快定位到关键逻辑，不需要从头理解整个系统。

 7.2 环节二：有损沉淀

AI 在开发过程中会做大量推断——状态机怎么流转、字段什么含义、模块间怎么调用。这些推断不能一股脑全存下来，需要过滤：

• 代码和注释里已经写明的 → 不存，存了也是冗余

• 标准实现、常规 CRUD → 不存，没有知识价值

• 纯猜测、无证据支撑的 → 不存，可能是错的

只存那些”读代码也看不出来、但 AI 通过跨文件比对才发现的隐含知识”。这样才能控制知识库的体量，不随着变更次数膨胀。

 7.3 环节三：人工确认

AI 沉淀下来的推断不是直接进知识库的。它会在写入时对自己做一次”置信度评估”——有充分证据支撑的（如多处代码相互印证），直接作为确定知识存入；证据不充分或存在矛盾信号的，打上待确认标记。

这些带标记的条目不会自动生效。下一轮变更读取时，会直接把它们过滤掉——不加载到上下文，不浪费 token，不给 AI 当”确定事实”用。只有人工逐条审视确认之后，才会在后续变更中真正起作用。

这个过程对知识库来说是质量门禁：AI 负责发现线索，人负责确认线索。AI 写得越多，需要人确认的就越多，但确认过的内容会持续产生价值。

 7.4 环节四：按需读取

下次做需求变更时，不把整个知识库一股脑塞进上下文。而是根据当前变更的描述，匹配相关的业务知识，只加载匹配的部分。不相关的知识不加载，既省 token，也避免无关信息干扰 AI 判断。

 7.5 成本逻辑：一次摊销多次

这套机制的价值在于改变成本结构：

第一次变更时，AI 读代码分析业务是全额开销，沉淀知识是额外小额开销，看起来变贵了。但从第二次变更开始，AI 可以先读知识库再读代码，大部分业务上下文从

知识库就能拿到，只需要关注变更部分的增量代码——token 消耗明显下降。

而需求变更在真实项目中发生的频率远比新功能开发高，每多一次变更，这笔投资的回报就多一分。

敲黑板：把单次变更中”读完就丢”的 token 消耗，变成”一次沉淀、重复使用”的可摊销投资。对频繁变更的遗留系统来说，这是 ROI 最高的成本控制手段。

08

写在最后：三张牌怎么打

回到开篇的框架：三个黑洞、两个杠杆、一个账本。全文拆完之后，它们不是孤立的，而是可以组合使用的三张牌。

对抗黑洞①（需求设计的 token 无上限），打”明确需求”牌。需求越模糊，AI 需要探索的空间越大。把需求写清楚，SDD 只做契约不做全量探索——这是成本控制的第一道防线。

对抗黑洞②（开发的上下文膨胀和幻觉返工），打”裁剪+按需”牌。缩小上下文、指定引用范围、开发阶段不做全量代码库扫描——每一刀切下去都是实实在在的 token 节省。

对抗黑洞③（构建修复的死循环），打”两道阀门”牌。成本守卫卡入口，次数边界卡出口。钱不够了不让修，次数到了不让继续修。

撬动杠杆①（需求拆解的倍增效应），打”契约模板”牌。拆解本身几乎零 token，但拆得准不准决定了开发阶段 Agent 会不会返工。投入最小，产出最大。

撬动杠杆②（代码审查的前置拦截），打”独立 AI”牌。构建先跑、再请另一个 AI 来审。审出问题的成本最低的阶段就是这里。

读懂账本（发布的成本报告），打”量化”牌。没有数据，所有判断都是感觉。成本快照+最终报告，让下一轮优化有据可依。

最后补一句实操层面的提醒：以上所有环节，关键决策节点都需要硬性 Hook 人工确认。 需求拆解完了人对不对？开发交付出口人签不签？构建反复失败人要不要停？AI 可以跑流程，但阀门在人手里。这不是降低效率，是防止 AI 在错误的路上越走越远。

以上全文基于个人理解，欢迎批评指正。