PRD 写得越来越漂亮，需求怎么越来越糊涂？

date

slug

ai-prd-requirements

author

status

Public

前言

最近做需求评审，越来越觉得不对劲。产品用 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 里的一个操作放回完整业务流程，看看是否能走到明确的结果。如果走到某一步就需要猜，就先把那一步说清楚。