ARTICLE · 1271263

AI重做研发工作流,PRD 的终点不是文档

发布时间：2026-10-29 02:08:17 最近访问：2026-10-29 02:08:17

「AI 重做研发流程」系列 · 02

今年这一整年，我把大部分精力放在两件事上：一是在上海交大读机器学习课程，二是探索 AI 能给研发团队带来效能提升。

课程从线性回归、MLP、CNN、RNN 一路讲到 Transformer 与大语言模型，最后落在 SFT 微调、训练流水线、推理模型和多模态。读它的动机很直接：搞清楚大模型的底层原理。

实践是把一个开源模型调成自己的：基于 Qwen3.5-0.8B，用 LoRA 微调，再挂一个决策头。它不生成文字，只对候选答案打分，输出经过温度校准的概率。模型卡和权重都开源在 Hugging Face 上（guoan1/jev-qwen35-08b）。

这个系列记录的就是这件事：我把自己当成样本，一次一个环节地看研发流程怎样更好结合 AI 并改进。不是工具评测，是把整个过程的经验分享给大家。希望给正在做 AI 研发效能提升的管理者们一些启发。

一个订单取消的功能改版上线。第二天商家端反馈：订单被取消了，但我没收到通知。

查下来，新写的取消逻辑里没有通知这一步。研发说 PRD 没写这条；产品说这是常识，上一版一直如此。两边都不算错，错的是这条共识从来没有被写下来过。

这篇谈的是：当 AI 开始读 PRD，这些空白不会再被协商填平，而是会导致质量下降。

章节一，二是在交代传统PRD在Ai工作流中的问题，如果你不想了解，可以直接跳到第三节开始讲Ai使用的PRD的结构。

一、PRD 是给人读的，这个前提正在失效

传统 PRD 用图文描述逻辑和流程，读者是人。

图文本身也有局限。流程图擅长表达路径，不擅长表达判定：一个方框写“校验订单状态”，读者知道要校验，但不知道校验哪几条、不满足时走哪条分支。图上的留白，最后也是由读图的人补的，和文字一样。

人读文档时会自动补全。看到“用户取消订单”，有经验的工程师知道要通知商家、要释放库存、要处理退款；这些动作不在文档里，在他的经验里。

补全依赖的东西，通常有三种载体：

写下来的文档；
说过的口头约定；
习惯了的历史做法。

只有第一种能被机器读到。后两种靠人传人，传一次损耗一次，换一个人就断一次。

不写下来是有原因的。写下来要花时间，而在团队稳定的时候，隐性知识几乎不产生成本——资深同事都知道，说一句就同步了。只有三种情况会让它显形：人员流动、跨团队协作，以及读者从人换成机器。前两种发生得慢，第三种来得突然。

这解释了一个常见现象：同一个 PRD，资深同事和新同事交出的东西不一样。不是文档有歧义，是两个人带进来的上下文不同。

所以 PRD 一直有个隐含前提：读者的经验足以补全文档的空白。它的验收对象从来不是“机器能不能判定”，而是“人读懂了没有”。

在人读的模式下，这个前提大致成立。代价是延后暴露：空白在评审会上一带而过，在联调时被口头补齐，直到某一次上线才暴露。

这笔代价有一个具体形态：责任判定。上线出了问题，研发看文档，产品看常识，双方都没有说谎，因为判据本来就不在同一个地方。判定一次要开一次会，开完也未必有结论，最后常常按谁更了解上下文、谁的声音更大来定。

这种成本不进任何工时表，但它每个需求都在发生一次。文档越是写给人看，责任就越依赖人；人一变，边界就模糊。

二、AI 不再替团队补全

AI 不在这套补全机制里。

它没有团队记忆，只有上下文窗口。需求文档、接口定义、历史代码，给到它的它能用；没给到的，它拿不到。

第一篇说过，能力上限由接入的上下文决定，可以用工程手段抬升。但这里有个前提：接进去的上下文本身得是可判定的。PRD 是写给人看的，接进去的仍是一片空白。

拿不到的地方，它不会停下来确认。它会按通用做法填一个看起来合理的结果。

举个具体的。让它实现取消订单，状态怎么变、库存怎么释放，文档里写了，它大概会做对；文档里没写的条件差异，它按通用做法填。比如你们的规则是“预售订单取消时，赠品不退回”，通用做法里没有这一条，它不会写。反过来，它可能加一句“取消后 30 分钟内可恢复”，这是不少产品的默认行为，但你们的业务里没有。前者是漏，后者是加，两种都算错，而且都不会在评审时被一眼看出来。

如果旧实现也被接进上下文，它可能照着旧代码抄一遍——抄得对不对，取决于旧代码是否还代表当前的规则；没接进去，它就按通用模式补。两种情况下，决定结果的都是它手上的上下文，不是团队里的共识。

这就是幻觉的实际形态：不是随机乱码，是合理的错误补全。它补的恰恰是那些没写下来的部分，而且补得通顺，评审时很难第一时间看出来。

这些补全来自训练数据里的普遍模式。普遍模式覆盖的是常见业务，覆盖不了你们特有的规则：某个渠道的订单不能拆、某类商品退款要先质检、某个状态只能由系统发起。越是个性化的业务，AI 自作主张的空间越大。

规模上更麻烦。一份稍大的 PRD 里，几十上百个场景分散在不同章节，越靠后的部分，越难和前面定下的约束保持一致。人也会漏，但人能问、会被打断、会在模糊的地方停一下；AI 不会停下来确认，它直接往下写。

有人会说，那就把文档切小、分段喂。分段能缓解长度问题，缓解不了指代问题：这一段里的“该订单”指哪种状态、哪个渠道适用哪条规则，只在团队的共识里。结构化解决的正是这件事——每个场景可以独立装载，每条预期结果可以单独判定。

于是验收标准被迫改变：以前是“评审时能不能讲清楚”，现在是“机器能不能判定”。

如果 AI 不只读 PRD，还按它拆任务、写代码、生成用例，同一个缺口会在四个环节各放大一次：拆任务时漏掉的场景，写代码时不会补；写代码时补错的规则，测试用例会照着错的一起写。

一句话：AI 不会让需求变简单，它会把需求里的模糊处，一处一处变成缺陷。

三、把 PRD 写成可判定的结构

软件工程的历史，一直在做同一件事：把更高一层的表达，翻译成机器能执行的东西。汇编、高级语言、各种框架，每一次抬升，都靠一个新工具把上一层翻译下去。

需求这一层过去抬不上去，因为它是自然语言，机器读不懂。现在这一层有了被翻译的可能，做法的重心也跟着变。

交大的智能体软件工程课上给出的做法，是把 PRD 从文档变成需求模型。课件里有一句话，把这个转变说得很直接：你不仅在编写文档，更是在建立需求模型。

图源：上海交大《智能体软件工程》课程课件。

三层：

需求 Req：编号、描述，描述可以是文本加图；
场景 Scenario：有名字，一个需求下面挂多个；
步骤 Step：一个场景由一串步骤组成，每一步是一个动作（action）加一个预期结果（expectation）。

一个需求对应多个场景，一个场景对应多个步骤。层级不深，但每一层都有明确的职责。

图源：上海交大《智能体软件工程》课程课件。

图中比示意多出来的一层，是需求先按模块拆成了子需求；节点类型仍然只有需求、场景、步骤三种。

常被问到一个问题：流程图还要不要画？要。图承担的是背景和动机——为什么做、涉及哪些角色、主流程长什么样；模型承担的是判定。两者不冲突：图给人看，模型给人和机器一起用。

场景负责覆盖路径。正常路径只是其中一条，还要有失败路径和边界。订单取消这个需求，至少包括：用户主动取消（已支付未发货）、超时未支付自动取消、商家拒单取消，以及一条反例——已发货不可取消。

步骤负责可判定。动作要可观察：谁、在什么状态下、做了什么。预期结果要可断言：系统处于什么状态、返回什么、界面上发生什么。

把订单取消的一个场景写开，大概是这样：

场景：用户主动取消（已支付未发货）
步骤 1：用户点击取消 → 订单状态变为“取消中”步骤 2：订单置为“已取消” → 订单状态为“已取消”步骤 3：发起退款 → 生成一笔退款单，金额等于实付金额步骤 4：通知商家 → 商家端收到取消通知步骤 5：释放库存 → 商品库存数量回增

另一个场景可以写得很短：

场景：超时未支付自动取消
步骤 1：订单创建后开始计时 → 计时起点被记录步骤 2：超过支付时限仍为待支付 → 订单状态变为已取消步骤 3：释放库存 → 对应库存数量回增

两个场景都用到“释放库存”，但触发条件不同、各自独立判定。这种重复不是冗余，它保证每条路径都能单独验证。

对照开头那起事故，问题就清楚了。退款、通知商家，在旧写法里都是常识，落在文档的空白处；新写法里，它们各自是一个步骤，各带一条预期结果。漏了就是漏了，不需要等上线才知道。

我们团队用的也是这套模式，只是拆分粒度和命名不同。这里按课程的定义讲，便于对照。

两条粒度上的约束值得单独说：

一个步骤只描述一个可观察的变化。“取消订单并通知商家”要拆成两步，因为它是两件事，会分别失败，也应该分别判定。

场景数量没有上限，但有下限。已知的失败路径必须覆盖，已经出过的事故补一条。穷举不完，所以这份模型是活文档，每出一次问题就长一条。

这件事的成本是真实的。产品会觉得重：以前半天写完的 PRD，现在要拆场景、写预期结果，时间翻倍。收益也很直接：设计有依据，任务拆得动，写代码有验收目标，测试用例可以直接从步骤里长出来。

结构化的成本落在需求端：首次拆解最费时间，之后是维护成本。这笔账能不能算平，取决于维护成本是否低于返工成本——只要这份模型还在被复用，通常低于。当然我们的做法是拆分场景，步骤，动作，预期结果本身也是Ai来完成。会大大降低成本，但人的审阅不能少，而且审阅的人要对交付出去的文档负责。我认为这是从人主导向Ai主导的一个大的变化。人负责审阅并对结果负责，Ai主导执行。

具体到下游：设计可以按场景画流程；任务拆分可以按场景或步骤切，一个任务对应一组可验证的步骤；写代码时，每个步骤的预期结果就是自测断言；测试阶段，场景和步骤天然就是用例骨架。这不是四份额外产出，是同一份东西的四个视图。

课程里把这套结构做成了一个需求编译器：一棵需求树进去，根节点生成界面骨架和接口，叶子节点生成代码主体，以及单元、集成、界面三层测试。

意义不在于自动化程度，而在于产物同源——改一条预期结果，受影响的代码和测试能被定位到，而不是靠人翻提交记录。

还有一个落地问题：谁来写。产品主写，研发补技术边界，测试补失败路径——三方在同一个模型上评审，而不是各读一遍文档、各自形成理解。这一步把评审从讨论需求，变成确认判据。

需要强调的是判定标准：AI 可以有幻觉，但结果必须是确定的、可检查的。需求模型每一层的存在意义，就是让“对错”可以被判定，而不是被讨论。

四、写不全的部分，需要另一个基础设施

需求模型解决的是“写下来”，解决不了“想得起来”。

产品写不全，是结构性问题。业务规则、例外处理、历史事故的教训，大部分不在产品脑子里，在组织里。让产品一个人把全套共识写进需求模型，不现实；靠评审会上的临时提醒，也只能覆盖与会者恰好记得的部分。

所以结构化之后还缺一层：一个能把组织知识喂给需求模型的底座。

写一条需求时，这个场景涉及哪些规则、哪些例外、过去出过什么问题，应该能被检索出来、被引用进来，而不是靠产品凭记忆补。这份知识如果散落在聊天记录、老员工的经验和一次次事故复盘里，需求模型就只能写到人记得的深度。

比如写“订单取消”，知识里如果有一条“取消必须通知商家”，附带它来自哪次商家投诉，这条规则就能被带进编写界面。产品只需要判断它适不适用，而不是从零回忆。写需求最费时间的部分，从来不是打字，是想起来。

知识在这里的作用不是替产品做决定，是把做决定需要的依据摆到桌面上。

这个底座该怎么建、建到什么粒度、怎么让它不过期，另有一篇专门讲。这里只留一个问题：你的需求模型能写到多好，取决于背后的知识有多完整。

五、推动它，比写它难

前面算的是团队的账：维护成本低于返工成本就划算。但这笔账算在团队身上，成本落在具体的人身上。

原来这份成本是隐性的：PRD 留白，研发凭经验补，测试凭经验补，联调时口头对齐，出了问题再回溯。它不是没有成本，是成本分散在很多人身上，每个人只承担一点，谁也不用为它负责。结构化等于把这些成本集中到产品一个人身上，而且要求当场付清。

对产品来说，这是要求变高，不是工作变轻。要穷举场景、要给每条预期结果下断言，靠的是对业务规则和例外情况的完整掌握——这跟“把需求写清楚”不是同一种能力。写得好的人不会因此更轻松，写得一般的人会明显更吃力。

收益也不落在产品身上。模型写得好，设计更快、拆任务更准、代码和用例能直接长出来，这些好处落在研发和测试。产品多花的时间，在自己身上看不到回报。

所以组织上的一致，不是发一份规范，是三件事同时变：

下游真的消费这份模型。设计按场景画，任务按步骤切，用例从步骤里长出来。产品写的东西没人用，两三个迭代就会退回原样。
验收按模型判。出问题先看哪条预期结果没满足，而不是先问“文档里写没写”。判据换了，上游的投入才有去处。
兜底停掉。研发不再默认“产品没写就是常识”，测试不再替需求补场景。兜底还在，结构化就只是多写了一份文档。

六、边界与降级版

不是所有需求都值得这么写。

探索型需求：还不知道要什么，先做原型和验证，结构化没有意义；
一次性活动：用完即弃，投入结构化不划算；
强主观的判断：界面好不好看、交互顺不顺手，这些写不成预期结果，也不该硬写。这里也会涉及一个很重要的话题，如何收敛场景。这需要团队协作将共识沉淀到研发阶段的Spec中。例如弱网环境下的处理，异常的处理等通用场景不需要每一个需求再单独列出来。

判断标准可以更简单：这个需求会不会被反复修改、反复验证。一次性的东西，投入不划算；反复出现的东西，每一次模糊都在收费。

如果团队小、流程本来就不重，不必全量铺开。两个降级做法：

只做最高频的两三条流程。下单、退款、登录这类反复改、反复出问题的流程，收益最大。

先写预期结果这一层。不急着拆场景，先把每个步骤“应该发生什么”写清楚。这一层成本最低，也最接近 AI 和测试真正需要的东西。

反过来也要防一种失败：结构化过度。把每个细节都写成预期结果，需求模型会变成测试用例集，产品变成替测试写脚本的人。判据是：预期结果描述业务上可观察的结果，不描述实现细节。写“商家收到取消通知”是业务结果；写“调用通知接口并返回 200”就是实现。

最后留一个自检：这条需求上线后，谁来判断对错？如果答案是“评审会上讨论”，说明它还没结构化。