前言最近做需求评审越来越觉得不对劲。产品用 AI 写 PRD、做原型文档看着挺完整可跟现有系统一对流程、规则甚至业务名词都对不上。关键边界还没说清楚评审一结束又开始催开发估工时、倒排期。最让我窝火的是都用上 AI 了查系统、梳理业务比以前方便了怎么反而连需求都没弄明白就急着往下做这些事让我重新琢磨软件工程里一个很实际的问题现在一个功能可以很快写完但凭什么说它做对了目录前言原型都出来了项目要做成什么样还没说清需求还没说清楚就催着倒排期产品不熟悉系统连名词都可能对不上开发懂业务也得有人把方案带回业务方原型出来了需求却还没定下来这份 PRD 怎么一路走到了代码里评审时需要把现有系统摆出来先把一条业务流程说清楚测试不能只对照这份 PRD省没省时间也要看后面的沟通和调整原型都出来了项目要做成什么样还没说清我们现在做需求评审会碰到这样一种情况产品拿 AI 写 PRD再做成原型文档有了页面也有了。但放到现有系统里一看流程对不上规则对不上有时候连业务名词指的是什么都对不上。后面不熟悉这块系统的开发拿着这些 PRD 继续用 AI 写代码。测试也依据这些材料往下做。东西越做越多那些没说清的边界也跟着进了代码和用例。等到理解对不上又得回头补充背景、讨论方案、调整实现和测试。产品也有产品的难处。业务方未必一次就能说清目标诉求可能变化排期压力也可能先落到产品身上。很多问题需要产品、开发和测试一起才能弄明白。熟悉系统的开发不能只等一份完美 PRD发现概念对不上、流程走不通就得把问题和方案拿出来。测试也需要核对业务预期发现规则缺失或前后矛盾就在评审里提出来。产品则需要把涉及业务取舍的部分带回去确认。最让人火大的是每个环节都已经花了时间大家却还要不断确认到底要做什么、做到什么程度。原型可以帮助发现问题方案也可以在讨论中调整但项目目标、这次的范围和预期结果不能一直靠后面的人猜。说难听点项目要解决什么问题这次做到哪里什么结果才算达到目标这些都还说不清楚就急着让 AI 写这么多东西到底在忙什么一份 PRD 写完了就当这些问题都有答案了一个原型能点了就接着往下实现。现有系统怎么处理哪些规则不能漏哪些边界还没定又要到哪一步才有人去问没确认的内容一路被写进文档、做成界面再变成代码和测试看起来越来越像已经确定的要求。到了发现问题的时候要检查和修改的地方也越来越多。AI 已经可以帮忙查资料、找代码、梳理流程搞清楚现状也有工具可以用了。但眼前这些反复确认和调整让人忍不住想问从项目目标到具体功能每一步到底有没有对齐过还是拿着上一环节的产出就直接往下做了需求还没说清楚就催着倒排期更让人火大的是评审一结束马上就让开发毛估工时接着倒排期。项目到底要做到哪里主要流程能不能走通几个关键边界怎么处理都还没有讲清楚就开始问什么时候能做完。做什么还得继续确认做完的日期倒要先给出来。这个工时到底按哪一版理解估粗估当然可以做。项目需要判断投入开发也可以根据现有信息给一个范围。但估算至少得说明按什么范围做、哪些能力可以复用、哪些问题还等着确认。一个答案不同就会改变方案的问题还悬在那里估算也只能带着这个前提。不能报完一个数就当后面的事情全都确定了。尤其是评审里已经发现 PRD 和现有系统对不上开发提出了另一种方案还得让产品带回业务方确认。这时候确认要多久、最终选哪种做法都没有结论。把这些也塞进开发工时里难道开发给出一个日期业务决定就会跟着出来如果交付日期确实不能动那就把这次必须交付什么、哪些可以放到后面、还缺什么配合拿出来谈。倒排期得排出这些取舍。光让开发把天数往前压悬着的问题还是悬着。AI 能帮忙把 PRD 写快、原型做快、代码生成快。可业务还没确认的选择、系统里还没查清的影响不会因为用了 AI 就自动消失。评审都还没把这些讲明白如何让开发给出一个确定的交付日期产品不熟悉系统连名词都可能对不上产品是直接和业务沟通的人。业务提出一个诉求产品收集下来接着要弄清楚它在现有系统里对应什么已经有哪些能力这次要改哪一段哪些地方确实需要新增。熟悉系统的产品用 AI 写 PRD 时至少知道文档里的概念和流程应该怎样核对。系统里一个业务对象叫什么某个状态意味着什么哪些操作已有哪些规则不能漏这些都有自己的判断。AI 写得不对比较容易看出来也有依据让它修改。不熟悉系统的时候问题就麻烦了。需求收集完交给 AI 整理写出来的文档可能条理清楚但里面的领域名词和概念已经跟现有系统不一样。读起来像是在讲同一件事仔细对照才发现对象、状态和处理范围都未必对得上。拿“订单完成”举个例子。它指已经发货、已经签收还是已经结算如果现有系统里这些是不同状态PRD 里却笼统写成“完成”后面的操作条件就没法直接确定。这个词的含义不先说清楚开发和测试就可能各自理解一套。如果文档给已有的概念换了一个名字又没有说明两者的关系开发接手以后就需要先判断它指的是已有对象还是业务真的要新增一种对象。如果开发也不熟悉这块系统又直接把文档交给 AI 实现就可能把已有能力重新做一套或者把本来不同的流程合在一起。这时评审要先把概念对齐才能继续讨论功能。PRD 里这个词指什么现有系统里对应什么两边有差异是因为需求要改还是因为文档没有写准确都得讲明白。产品不需要掌握每个实现细节但直接承接业务诉求以后至少要能和开发、测试一起说清楚这些关键概念。确实不熟悉的部分可以请熟悉系统的人一起核对。收集完需求再让 AI 写出一份文档还没有完成这一步。开发懂业务也得有人把方案带回业务方熟悉业务的开发可能比产品更清楚这块系统实际怎么运转。哪些状态有什么含义流程之间怎么衔接改一个地方会影响哪里都能看出问题也能给出更合理的方案设计。以我们公司为例开发目前并不直接对接业务方拿到的主要是产品整理后的需求对业务目标和取舍有疑问也需要通过产品再去确认。懂系统里的业务能够提出方案不代表掌握了这次需求的全部背景。例如开发发现现有能力就能满足一部分要求可以提出复用方案发现原型里的操作会影响后续流程也可以给出另一种设计。但业务方是否接受这样的操作方式目标有没有变化哪些取舍已经确认还需要把方案和问题带回去沟通。这里容易卡住的是开发已经说明了问题也提出了更合理的做法方案却还没有经过业务确认。此时如果直接按新方案改业务预期可能对不上继续按原 PRD 做又可能把已经发现的问题带进实现。所以评审不能停在开发提完建议这一步。需要有人把方案带回业务方把取舍说清楚再将确认结果更新到 PRD 和原型里。尚未确认的部分也要明确留下。开发给出了合理方案并不意味着业务已经接受了这个方案。原型出来了需求却还没定下来原型当然有用。文字里不好理解的操作做成页面以后按钮、字段和步骤就清楚了。产品和开发可以围绕同一个界面讨论很多问题也更容易被发现。但原型能把一个操作展示出来还需要继续说明它在业务上意味着什么。例如页面上增加了一个取消按钮就需要知道哪些状态允许取消谁可以操作取消后修改哪些数据已经发生的后续处理怎么办。这些问题在不同系统里可能有完全不同的答案。按钮可以先做出来答案却不能靠按钮的存在来确定。已有系统里的需求尤其如此。一项新操作可能接在原有流程的中间前面已经发生了数据变更后面还有别的模块依赖这个结果。单独看新页面操作顺序也许很顺放回完整业务过程就需要检查它是否仍然成立。如果 PRD 和原型没有核对这些关系界面越完整越容易让人误以为需求已经充分考虑过了。未确认的状态变化也可能成为原型里的默认行为。所以评审原型的时候得沿着一次操作往下问谁在什么情况下开始做完以后系统变成什么状态接下来谁会用这个结果。如果某一步还没有答案就把问题留在对应的位置。原型可以继续用于探索但这一段还不能被当作已经确认的实现要求。这份 PRD 怎么一路走到了代码里产品整理需求开发根据需求实现测试按照需求验证。这套分工本身很自然。问题出在PRD 如果连业务概念都没有对齐又包含了未经确认的规则而后面的角色也缺少现有系统的知识就可能没有人发现这些问题。开发面对一份已经写好的文档容易以为某个状态、某个操作范围已经在评审里确定。AI 接到这份文档后可以继续补齐接口、字段和条件分支。测试再根据同一份文档设计场景也可能得到和实现一致的预期。这里最容易忽略的是**开发和测试理解一致也可能是一起理解错了。**两边都对照同一份 PRD还得有人确认这份 PRD 本身是否符合实际业务。这也会扩大后续调整的范围。原本需要确认的一条规则到了后面可能已经变成了页面交互、接口参数、状态判断和测试用例。重新确认以后这些地方都需要检查是否跟着修改。大家接着同一份材料往下做的时候没说清的地方可能就被跳过去了。它们到了代码和测试里有了具体实现和预期结果再想起这些边界往往已经需要改好几个地方。在我们现在的情况里文档与系统不一致、边界不清以及后续反复沟通和修改确实是存在的。哪些属于目标进一步明确哪些属于业务探索哪些是原本能核对的问题遗漏了还需要从实际任务中继续区分不能都归到某一个角色或者工具上。有些规则确实漏写了有些是现有系统行为没有查明也可能有一些是在开发过程中才改变。处理方式应当跟着原因走。如果业务决定变了就记录新的决定如果现状没有查清就补做系统核对如果规则已经明确但实现遗漏再处理实现问题。评审时需要把现有系统摆出来对已有系统做需求评审需要先对齐项目希望解决的问题和这次的范围再回答一个具体问题这次修改到底发生在原有业务的哪里产品需要带来业务目标和确认结果熟悉系统的开发可以补充现状、影响和方案。方案涉及业务取舍时还需要有人负责回到业务方确认。开发可以借助 AI 查代码、找入口、整理状态但关键结论应当能回到实际页面、接口、配置或者数据上。光列出受影响的模块名称还不够。模块之间怎样衔接当前哪些条件会改变处理路径已有数据采用什么口径都可能影响这次需求。以我个人的经验来讲下面这些是评审时可以直接核对的内容项目希望解决什么问题这次做到哪里明确业务目标、本次范围和预期结果。文档里的业务名词指什么能对上现有对象和状态新增或改变的概念有明确说明。当前流程怎样完成这项业务能找到对应入口知道主要步骤和结果。这次具体改在哪里说清增加、删除或改变了哪一步。哪些规则和数据会受影响明确状态、权限、历史数据和后续使用方。还有哪些问题没确定写出问题、影响范围和负责确认的人。怎样判断修改符合预期留下几个经过确认的业务例子。一个问题标成待确认并不意味着所有工作都必须停下来。与它无关的部分可以继续。关键是知道它影响哪一段不让开发在这一段里默默替业务作决定然后让测试把这个决定当成既定要求。现有系统也可能有缺陷业务当然可以要求改变。核对现状是为了看清变化而不是要求新功能永远维持过去的做法。原有行为要保留还是要纠正都可以讨论但需要明确写下这次的决定及其影响。对于不熟悉系统的开发这些记录尤其有帮助。接手时如果只有新原型和新 PRD就容易把任务理解成从零实现一个功能。能够同时看到现状、目标和差异才更容易判断哪些能力应当复用哪些地方必须改。这些信息也是给 AI 的有效上下文。让它直接照原型生成接口与让它先核对当前流程再说明需要修改的位置是不同的任务。后者的分析仍然需要检查但至少把系统现状纳入了工作范围。先把一条业务流程说清楚如果整份需求的边界都不清楚一次性把所有页面和接口交给 AI可能很快就得到大量待确认的实现。可以先挑一条主要业务流程从入口走到结果。产品、开发和测试一起看它是否完整尤其是正常流程之外哪些情况会阻止操作哪些后续处理会受影响。拿运费优惠举个例子。假设要给新订单增加优惠除了优惠比例还要知道优惠作用于哪笔金额最低收费是否继续有效已出账订单是否需要重新计算。如果约定基础运费打八折但最终金额不能低于 60 元就可以确认两个例子基础运费 100 元时最终收取 80 元基础运费 70 元时最终收取 60 元。再明确已出账订单保留原金额就能继续核对查询和出账入口是否遵守这个决定。至于优惠资格、币种和舍入方式这个例子没有展开。实际实施时仍然需要确认不能因为两个数字算得出来就认为整条计费流程已经定义完了。这样的讨论不需要先写出大量代码。它先让几个人对一次业务变化达成一致再决定实现怎样组织测试怎样验证。这类确认不能只留在会议或者聊天里。产品需要更新规则和原型说明开发记录系统改动和依据测试把例子转成用例。如果材料没有跟着改下一次 AI 读取它们时仍然可能沿用旧假设。任务也可以顺着这条流程拆。一个步骤是否适合独立实施要看它能不能说明业务结果、能不能验证以及与其他步骤的依赖是否清楚。只按照页面或者文件数量拆开未必能减少理解上的冲突。遇到会影响金额、库存、权限或者跨系统状态的问题还需要看失败以后怎么办。已经生成的数据是否需要修正操作是否允许重试由谁发现未完成的处理。这些属于业务流程的一部分不能一直留到测试阶段再补。对于状态简单、影响很小的需求几条说明就可能足够。投入多少分析应当取决于真实影响把每个小改动都变成长文档也会消耗团队时间。测试不能只对照这份 PRD测试需要把 PRD、当前流程和评审后确认的变化放在一起看。尤其是已有系统的需求不能只看新文档里写了什么还得知道原来哪些行为应该保留。如果 PRD 有误开发和测试又共同沿用它测试就可能验证了错误的要求。AI 生成的用例可以很多断言也可以全部通过但它们共同依赖的业务预期仍然值得检查。所以测试在评审阶段就需要参与确认旧流程哪些行为应当保留新流程改变了什么哪些数据不应当受到影响。这样才能把新要求的检查和原有行为的回归放在一起。继续用运费案例说明。优惠金额计算正确是一项检查已出账订单没有被重新计算是另一项查询页面展示保存的金额而没有临时按新规则重算又是一个需要核对的入口。这些预期应当来自业务决定与系统分析。让 AI 阅读代码后生成测试可以检查一些实现细节但还需要拿确认过的业务例子来检查实现是否走偏。换一个模型或者再开一个对话可以增加发现问题的机会。如果输入的仍然是同一份有误的 PRD也可能得到相同的结论。真正需要补充的是对预期的核对依据。验证结果也要说清范围。单元测试能支持被测规则的判断集成测试能够检查选定的协作链路历史数据核对可以检查所选案例。没有覆盖的情况应该进入交付说明让后面的人知道还存在什么问题。测试通过以后上线还要看实际业务结果。像运费这样的功能需要核对金额和账单接口返回成功还不足以判断收费是否符合约定。省没省时间也要看后面的沟通和调整这些沟通、确认和调整都会花时间。AI 到底省了多少时间需要结合具体任务记录看看时间究竟花在了哪里以及这些投入有没有让项目目标和方案更清楚。可以先从具体任务里记录原因。发现问题时它属于需求遗漏、现状不一致、规则变更还是实现缺陷发现时已经影响了哪些产出修正它需要哪些人重新参与这些调整不能都叫返工。原型帮助发现新想法方案讨论后作出取舍都是正常的项目推进。需要具体看的是这次调整获得了什么新信息还是仅仅把前面没有传清楚的内容又解释了一遍。两种情况都占时间但原因和处理方式不一样。也要把写代码之外的时间算进去。整理背景、检查生成结果、修改文档、重新联调和测试都会占用资源。如果只统计第一次代码生成有多快就看不到后面的成本。如果要调整现在的做法可以先从一条正在评审的业务流程开始。把项目目标、本次范围、当前行为和未确认的问题放在一起让产品、开发和测试共同核对。再看看关键问题是否能更早明确后面是否少了重复解释和不必要的修改。没必要一上来就给所有环节增加一套复杂规定。AI 在这个过程中仍然很有用。它可以整理现状、比较材料、找调用入口、补充检查场景再根据确认后的要求实施。用它的人需要判断每项产出能支持什么结论以及哪些问题仍然需要业务和系统知识来回答。工程师写代码的方式可以改变但理解系统的工作还在。不熟悉某一块系统也不意味着只能接受文档上的描述可以借助工具查明现状再找熟悉业务的人确认关键判断。现在看到一个功能很快写完我更在意的是它依据哪些已经确认的规则放进现有系统后会改变什么又有什么依据说明这些变化符合预期。下一次评审可以先把 PRD 里的一个操作放回完整业务流程看看是否能走到明确的结果。如果走到某一步就需要猜就先把那一步说清楚。