AI写代码越来越快,为什么交付还是反复返工?

AI Coding 让代码生成越来越快，但交付中的返工，往往不是从代码阶段才开始。更早之前，产品意图、体验表达、工程约束和验证标准，已经在不同产物之间被反复交接、解释和补全。

AI 时代真正需要重构的，可能不是某一份 PRD 或设计稿，而是产设研围绕同一个交付项连续协作的方式。

一、过去的协作，是靠人把断点补起来

过去做一个需求，大家对流程并不陌生。

业务或产品先提出想法，产品经理整理 PRD，设计师产出设计稿，研发看 PRD 和设计稿评估实现，再拆前后端任务，写代码、联调、测试、上线。

这套流程已经运行了很多年。它不完美，但在以人为主要执行者的研发体系里，大体是可用的。因为中间有很多隐性的人工补全。

PRD 里没有写清楚的地方，研发可以在评审会上追问。设计稿没有覆盖的状态，前端可以根据经验补。技术方案没有展开的边界，研发负责人可以在实现过程中判断。测试用例没有提前定义完整，测试和产品也可以在提测后继续对齐。

换句话说，过去的产设研协作，并不完全依赖文档本身。它依赖的是一整套人和人之间的解释、追问、补充和判断。

PRD、设计稿、技术方案更像是交接物。它们把一个需求从一个角色传给下一个角色，再由下一个角色继续理解和补全。

但 AI 进入研发流程后，这个前提开始变化。因为执行者不再只有人。

二、AI 不只让写代码变快，也会放大输入里的断点

当 Coding Agent 开始理解需求、修改代码、调用工具、生成测试、提交 PR，原来那些可以靠人补齐的信息，就不一定能自然进入执行过程了。

产品写了一句“支持批量审批”，人类研发可能会追问：是否需要二次确认？是否允许部分成功？失败项怎么处理？无权限用户是隐藏入口还是置灰？是否需要操作日志？是否影响财务对账？

但 Agent 不一定会问完这些问题。

它可能直接开始实现。它会根据已有上下文猜测一个方案，生成一批代码，看起来也许能跑，但最后才发现：有些业务规则没覆盖，有些页面状态没表达，有些接口能力不存在，有些验收标准从一开始就没有定义。

这时问题并不是 AI 不会写代码，而是我们交给它的需求，本来就不是一个足够完整的工作对象。

这也是为什么，在 AI Coding 继续升温的同时，围绕 SDD 的讨论也开始变多：大家不只是关心 AI 能不能写代码，也开始关心代码之前的需求、设计和任务该如何被结构化。

SDD(Spec-Driven Development) 的价值在于，它不鼓励人直接把一句模糊需求丢给 Coding Agent，而是先把需求、设计和任务结构化出来，再让 Agent 基于更稳定的上下文执行。

这个方向很重要。它至少说明了一件事：AI 时代的软件研发，不能只靠 prompt 推动。需求需要被整理，边界需要被表达，任务需要被拆解，验收标准需要提前出现。

但如果把视角放回真实的产品交付，会发现问题还会再往前、再往外扩一层。因为一个需求不只是 Spec。它可能来自一句想法、一份 PRD、一段会议纪要、一个线上问题、一条用户反馈，也可能来自一个已经运行中的产品页面。它不只需要被写清楚，还需要被看见、被讨论、被修改、被评估、被验证。

三、真实产品交付，不只是一份 Spec

比如一个很普通的 B 端需求：在退款列表页增加批量审批能力。

产品关心的是：为什么做，给谁用，本期范围是什么，是否支持部分成功，失败项是否可以导出，无权限用户怎么看。

设计关心的是：批量操作入口放在哪里，二次确认弹窗怎么表达，处理中状态怎么呈现，部分成功结果页怎么设计，错误态、权限态、空态有没有覆盖。

研发关心的是：前端要改哪些组件，后端有没有批量审批接口，接口是否支持逐条失败原因，是否需要幂等键，是否记录操作日志，是否影响财务对账。

测试关心的是：哪些规则能自动化验证，哪些状态要截图，哪些异常路径要覆盖，失败后如何回归。

发布关心的是：灰度给谁，开关在哪里，出了问题怎么回滚，上线后看什么指标。

如果还是按传统方式，这些信息会分散在 PRD、设计稿、技术方案、测试用例、发布单和一堆沟通记录里。它们都存在，但不一定连在一起。

PRD 里写的是“无权限用户不可操作”，设计稿里画成了置灰，前端实现成 disabled，测试却按“隐藏入口”去验收。最后每个人都觉得自己没错，但需求还是返工了。

PRD 里新增“失败项支持导出”，设计稿需要补结果页状态，技术方案需要补导出接口，前端任务需要更新，测试用例也要跟着变化。但在很多团队里，这种影响并不会自动传递，只能靠人一轮轮同步。

这就是 AI 时代产品交付真正容易断的地方。不是没有 PRD，也不是没有设计稿，而是这些产物之间缺少连续关系。

更进一步说，未来真正发生变化的，可能不是“PRD 会不会消失”或“设计稿会不会消失”，而是它们还会不会继续作为彼此独立的交接物存在。

四、协作中心，可能会从文档转向产品现场

在新的协作方式里，产品、设计、研发可能不再围绕一份文档或一张设计稿来回传递，而是围绕同一个产品现场推进。

这个产品现场可以是一个正在运行的页面，也可以是一个空白画布、一个 AI 生成的高保真原型、一份设计稿、一个流程图，或者一组页面截图。

大家不再只是说“请看这份 PRD”或“请看这个 Figma 链接”，而是直接在产品现场上讨论：这个区域要改什么，交互是否成立，状态是否缺失，接口是否支持，规则怎么验证，这次交付到底卡在哪里。

当协作从“交接文档”变成“共同推进产品现场”，很多传统产物的形态都会变化。

PRD 可能不再是一篇从头写到尾的长文档，而是从产品意图、澄清问题、业务规则和验收口径中持续生成出来的产品说明。设计稿也不一定总是先被完整画出来，再交给研发实现。很多场景下，团队可以直接在产品现场里生成高保真原型、状态矩阵和 before / after 预览，让设计参与确认体验方向，而不是只交付一张静态稿。

技术方案也可能不再是研发接到需求后单独补的一份文档，而是随着产品规则、体验状态和仓库上下文逐步展开，自动形成影响范围、接口契约、改动边界和风险判断。测试方案也不应该最后才出现，只要产品规则和体验状态开始被定义，验证点就应该同步生成。哪些能自动化验证，哪些需要截图，哪些需要人工确认，应该在执行前就被看见。

这时，PRD、设计稿、技术方案、测试方案都不再只是交接物，而更像是同一个交付项下的不同视图。产品看产品意图和业务规则，设计看体验状态和原型预览，研发看技术影响和执行上下文，测试看验证计划，发布看门禁、灰度、回滚和证据。

这些视图可以被人评审，也可以被 Agent 消费，还可以在交付完成后沉淀为证据。这才是 AI 时代产设研协作真正可能发生的变化。

五、围绕一个交付项，而不是传递一堆文件

这个变化不是让产品不用写需求，设计不用做设计，研发不用做技术判断，而是这些工作不再一定通过彼此独立的交接物来完成。

过去，一个需求像是在不同角色之间接力。产品写完 PRD，交给设计。设计画完稿，交给研发。研发评估后再拆任务。测试在后面补验收。发布时再补灰度和回滚。

每一棒都很重要，但每一次交接都可能丢东西。产品说的是业务目标，设计看到的是页面表达，研发关心的是接口和仓库，测试关心的是验证路径。大家面对的是同一个需求，但看到的往往不是同一个对象。

AI 时代，更合理的方式可能是反过来：先有一个共同的交付项，然后产品、设计、研发、测试和 Agent，都围绕这个交付项工作。

这个交付项可以是一件很小的事，比如“退款列表增加批量审批”；也可以是一件更大的事，比如“新增活动配置页”；还可以是一次修复、一次体验优化、一次权限补齐、一次跨端适配。它不是一份文档，也不是一张设计稿，更不是一个研发任务，而是这次产品变化本身。

围绕这个交付项，团队可以在同一个产品现场里不断补齐信息。产品补齐业务目标、用户场景、范围、非目标和验收口径；设计补齐页面状态、交互反馈、关键文案和高保真预览；研发补齐影响仓库、相关模块、接口契约、改动边界和技术风险；测试补齐验证路径、异常场景、自动化用例和人工确认点；Agent 基于这些已经被确认的信息，生成执行计划、修改代码、运行测试、回收证据。

这时，协作的中心就变了。它不再是“谁写完一份东西，再交给下一个人”，而是“同一个交付项现在还缺什么，谁需要补，补完以后会影响哪些下游”。

这个变化看起来不大，但对真实研发很关键。因为产品交付里很多问题，不是出在某个人没有努力，而是出在信息没有连续流动。PRD 变了，设计稿不知道；设计状态补了，技术方案没更新；接口能力不支持，产品范围没有及时收缩；验收口径变了，测试用例和 Agent 执行上下文没有同步；上线失败了，失败原因没有回到需求本身，下一次还是重复踩坑。

如果有一个围绕交付项展开的工作台，这些变化就不应该只存在于聊天记录和会议纪要里。它应该能明确告诉团队：这条业务规则来自哪里，影响了哪个页面状态，需要哪个接口支持，对应哪些测试点，有没有进入 Agent 的执行上下文，最后有没有被验证通过。

六、我们缺的不是 AI PRD 工具，也不是 Coding Agent 外壳

这也是为什么，我觉得 AI 时代的协作工具，不应该只是再做一个 AI PRD 工具，也不应该只是再做一个 Coding Agent 的外壳。

AI PRD 工具解决的是“帮我写一份需求文档”。Coding Agent 解决的是“帮我完成一段代码修改”。但真实产品交付中间还有一层更难的东西：从产品意图到工程执行之间，如何形成一个连续、可确认、可追溯的工作对象。

这个工作对象需要能被人理解，也能被 Agent 消费。它不能只是一段自然语言，因为自然语言太容易模糊；它也不能只是一组代码任务，因为那已经太靠后。它应该同时包含产品意图、产品现场、体验表达、工程约束、验证计划和交付证据。

比如还是“退款列表增加批量审批”这个例子。在新的协作方式里，团队可能不是先写一篇完整 PRD，再画一套完整设计稿，再开技术评审，而是打开现有退款列表页，直接圈选表格区域，输入“这里增加批量审批，支持部分成功展示，失败项可以导出，只有客服主管能操作”。

系统先把这句话变成一个交付项。它会追问产品：是否需要二次确认，失败项是否支持重试，无权限用户是隐藏入口还是置灰，是否影响财务对账。它会生成体验预览：新增批量选择、批量审批按钮、二次确认弹窗、处理中状态、部分成功结果页、失败项导出入口、无权限状态。设计可以在这个预览上继续调整，而不是必须先从零画一套稿。

它也会分析工程影响：前端可能要改哪些组件，后端是否需要新增批量审批接口，接口是否要返回逐条失败原因，是否需要幂等键和操作日志。研发可以确认这些判断，也可以提出风险和替代方案。与此同时，它会同步生成验证方案：有权限用户能批量审批，无权限用户看不到入口，部分成功能展示失败原因，失败项可以导出，重复提交会被拦截。测试和产品可以在执行前就确认这些验收点。

等这些信息足够清楚后，系统再把它们整理成给不同执行者使用的上下文。前端 Agent 看到的是页面状态、组件范围、接口契约、非目标和验收点；后端 Agent 看到的是 API 设计、权限逻辑、错误码结构、幂等要求、操作日志和单测要求；验证 Agent 看到的是 E2E 路径、Mock 数据、截图点和人工确认点。

这时，Agent 不是凭一段模糊需求去猜，而是在一个已经被产品、设计、研发共同确认过的交付项上执行。

七、代码合并不是结束，证据回流才是闭环

执行完成后，事情也不应该停在“代码合并”。

PR 链接、代码 Diff、测试结果、截图、失败修复记录、人工确认、发布记录、灰度策略、上线数据，都应该回到这个交付项上。这样一次交付才真正闭环。

它不只是“代码写完了”，而是团队能够回头看见：这次产品变化从哪里来，经过哪些判断，谁确认过什么，Agent 执行了什么，哪里失败过，最后靠什么证据证明它已经完成。

这也是后续经验复用的基础。下次再做类似的批量操作、权限控制、部分成功、失败导出，就不必从零开始。过去的交付项、上下文、验证方案和证据，都可以变成新的样本。

所以，AI 时代产设研协作的变化，不是简单地把原来的 PRD、设计稿、技术方案搬到一个 AI 平台里。那只是换了一个地方写文档。

真正的变化应该是：产品交付从“文档交接”变成“围绕产品现场和交付项的连续推进”。

文档还可以存在，设计稿也可以存在，技术方案也可以存在，但它们不再是协作的终点，也不再是彼此割裂的交接物。它们会变成同一个交付项下的不同视图，有些由人编写，有些由 AI 生成，有些由系统从产品现场、代码仓库、测试结果和发布记录里自动回收。

人负责判断、确认和取舍。Agent 负责生成、执行和验证。工作台负责把这些过程串起来，让每一次产品变化都能被看见、被推进、被验证、被沉淀。

这可能才是 AI Coding 之后更值得关注的方向。

代码生成会继续变强，Coding Agent 会越来越能干，SDD 也会让需求到代码的过程更结构化。但如果产品意图、体验表达、工程约束和验证证据仍然散落在不同地方，AI 写代码越快，返工也可能来得越快。团队越需要一个地方回答：我们到底要做什么，现在清楚到什么程度了，谁确认过，哪些地方还没想清楚，Agent 拿到的上下文够不够，结果怎么证明是对的。

这些问题不解决，AI Coding 很容易只是在局部变快。局部变快不等于产品交付变顺。

软件交付的本质，从来不只是写代码，而是把一个模糊的想法，推进成一个可运行、可验证、可发布、可回溯的产品结果。AI 让执行成本下降之后，这件事不会变得不重要，它会变得更重要。

接下来，我也会沿着这个方向继续做一些开源实践：不是再写一份 AI PRD，也不是再套一层 Coding Agent，而是尝试把一次产品变化从提出、澄清、表达、执行到验证，真正放到同一个工作台里。