一个需求交出去，到底要几份东西？

有个问题，很多人没认真算过。

做完一个需求，你交出去的到底是什么？

大部分人的第一反应是"代码"。再想想，会说"代码加 SQL"。再往下问，就答不上来了。

但这个答案，决定了你怎么估算工期，也决定了你为什么总是觉得自己"明明写完了却还没交完"。

一、先老老实实算一遍

拿一个再普通不过的需求举例：给后台加一个"优惠券管理"，能列表查询、能新增、能停用。

看起来是个 CRUD，两三天的事。拆开看，你实际要交的东西是这些：

需求侧： 这个需求的边界在哪——优惠券要不要支持叠加？停用了之后已经发出去的券怎么处理？这些如果不定死，后面全靠猜。

设计侧： 表怎么设计（优惠券主表、发放记录表、跟订单的关联），接口怎么定（列表查询的参数、分页返回结构、停用是 PUT 还是 POST、停用失败的错误码是什么）。

后端： 实体、Mapper、Service、Controller，加上并发下的库存扣减逻辑，加上至少能覆盖主要分支的校验。

前端： 列表页、新增表单、停用确认弹窗、停用后的状态展示、操作失败的提示。

配置与脚本： 建表 SQL、初始化数据、可能需要加的字典项、权限点配置。

验证： 主要分支跑通，边界情况（已发放的券被停用、并发领取）有结论。

数一数：七类。

其中"代码"只占两类，而且恰恰是 AI 最容易帮你代劳的那两类。

剩下五类，才是真正吃掉时间的部分。

这也解释了一个很普遍的感受：用了 AI 之后，写代码确实快了好几倍，但一个需求的总耗时，好像没缩短那么多。

因为你省掉的是那两类，剩下的五类一动没动。

二、为什么"代码行数"是个错的度量

行业里有个挺有意思的现象。

LinearB 在 2026 年给出的数据里，AI 时代的 PR 平均体积是此前的约 2.6 倍，但 merge 率不到一半。GitClear 同期观察到的一个指标是代码 churn（写完很快又被改掉的比例）同比上升了 39%。

这两个数字放在一起，说明了一件事：产出变大了，但落地的比例在下降。

代码写得更多，被推翻的也更多。

为什么会这样？因为写代码的成本被压到极低之后，瓶颈转移到了"决定写什么"上。

以前写代码贵，所以你会先想清楚再动手——想不清楚就写，返工的成本你承受不起。这个成本客观上逼着你把上游工作做足。

现在写代码便宜了，这个约束消失了。于是"先写再说"变成默认动作，本来应该在上游解决的模糊地带，全都被推到了下游，变成 churn、变成大 PR、变成 merge 前的反复修改。

所以度量单位该换一换了。 不是"这个需求多少行代码"，而是"这个需求要交几份东西"。

行数骗人。AI 可以在十分钟内给你两千行，其中三百行是错的、两百行是多余的。而"要交几份东西"骗不了人——少一份，下游某个环节就得停下来等你。

三、产物清单比代码行数更接近真实成本

有个做法值得拿出来讲一讲。

飞算 JavaAI 的智能会话里，"前后端设计"这条指令的产出不是代码，而是一组文档：工作区上下文、技术栈决策、数据库设计、接口设计、技术需求覆盖、后端设计规范基线。这些全部落进项目的 docs 目录。

而它做前端页面设计的依据，是前面那份 API 接口设计文档。前端开发这条指令在缺少这些上游文档时会停下来，提示回到设计环节补齐——补齐之后才继续。前端工程最终落在项目的 frontend 目录。

这套设计的含义其实很明确：它把"要交几份东西"这件事显式化了。

不是生成完代码就结束，而是先明确这个需求需要哪几份产物，每一份落在哪里、由谁的下游环节消费。需求文档给设计环节用，接口设计给前端页面用，技术栈决策给半年后接手的人用。

成本也就因此变得可见：你要交的不是一个"做完的需求"，是这一组产物。哪一份缺了，下游会在那个位置停下来，而不是带着缺失继续跑。

边界照旧说清楚：它不会替你决定优惠券能不能叠加这类业务规则，也不会替你判断一个表该不该拆。它做的是——把该有的产物列出来，并且不让缺失的环节被悄悄跳过去。

四、那几份文档，为什么不能省

顺着这个思路再往下推一步：设计侧那几份文档，到底能不能跳过去直接写代码？

很多人觉得能。理由也很实在：“需求我脑子里清楚，直接写更快。”

问题出在两个地方。

第一个：脑子里的东西不会自己同步。

你自己写后端，脑子里的接口定义跟你的代码天然一致，没问题。但当你要同时产出前端页面时，另一端不是你的脑子。要么是你自己第二天忘了当初定的是什么，要么是页面生成的那一侧拿不到这份定义。

于是就出现了最常见的返工：页面写完了，发现字段对不上，回头改接口；接口改了，Service 层跟着动。

第二个：文档不是记录，是下游环节的起点。

这一点容易被误解。很多人把文档理解成"写完之后补的说明"，所以觉得可以省。

但在跨层交付里，文档是输入，不是输出。前端页面是依据接口设计文档生成的，不是依据你写代码时的记忆生成的。少了这份输入，下游环节要么停下来，要么自己猜。

猜的代价，前面已经说过了：Sonar 2026 年那份覆盖 1149 名开发者的调查里，96% 的人不信任 AI 生成的正确性，只有 48% 会在提交前检查。猜出来的东西，大概率就这么进仓库了。

五、怎么把这件事落到自己的流程里

不一定非要用某个工具，这个思路本身可以拆出来用。

第一，开工前先列产物清单。

不是估算"几天写完"，而是先写出"这个需求最后会有几份东西"。列出来之后你会发现，工期估算突然准了很多——因为你终于在估算你真正要做的那些事。

第二，把上游产物当成硬前置。

接口没定的时候，不开始写页面；表结构没定的时候，不开始写 Service。听起来是废话，实际执行时，绝大多数 churn 都来自这一条没守住。

第三，让缺失可见。

给流程设一个检查点：上游产物不存在时，明确提示并停下，而不是带着默认值继续。这一条的价值不在于它多聪明，而在于它把"猜"挡在了提交之前。

第四，度量要跟着改。

如果你还在用代码行数或者提交次数衡量产出，那你正在鼓励的错误行为。改成看：这个需求的产物齐不齐、PR 一次 merge 过的比例有多少、churn 有多少。

六、一笔更诚实的账

回到最开始那个问题：一个需求交出去，到底要几份东西？

答案是：取决于你交付的边界在哪。

只写接口，那三份就够——接口文档、代码、SQL。

一个人交付整个系统，那就是前面数过的七类。

这也是为什么"转全栈"这件事，让人感觉工作量涨得不成比例。你以为只是多了一个前端页面，实际上多出来的是一整组产物：页面从哪份接口长出来、技术栈怎么定、状态在哪一层持有、错误在哪一层呈现。

多出来的不是代码量，是产物的种类。

而当你把度量从"写了多少行"换成"要交几份"，很多之前说不清的疲惫感，一下子就有了解释。

你手上最近做完的那个需求，除了代码，你还交了几份东西？

数一数，欢迎在评论区报个数——我猜大部分人会比自己以为的少两份。