前言

之前有一篇我写过 prd-three-layer-template：AI 编码工作流要稳，需要先统一需求入口；评审稿子和需求开发的稿子不是同一份。

而这次主要解决的是「第二次迭代中的第二份 PRD 怎么进流水线」。

在实际干活中还有更烦的这一类：需求已经出过一版甚至两版了，产品又甩来增量——比如加个邀请码、改句文案、流程多一步等等。

这时候最怕的事情出现，简单讲就两件事。

一是产品经理写的新 PRD 写得像从零开项目一样，评审问需求中的「相对上一版到底改了啥」，详细答不上来，说的全是稿子之外的，稿子写的看到头疼。二是Html原型为了「更好看」，整站重生，主题色、导航、根本没动过的页面也被AI重新生成给冲掉了。

人看着就感觉非常的漂，AI 更不知道边界在哪。

看的我脑袋疼 ～ 迭代的意义都丢了，看着就是新的。

所以我后来又做了个技能：prd-iterate。

不想继续痛苦下去，靠别人不如靠自己。

为此我就干了一件事：拿着上一版 PRD（最好再带上一版可点 HTML）+ 本轮新需求，吐出「一眼能看出本版改了什么」的迭代稿，并在旧原型上做增量修改。有旧 HTML 时，禁止从零生成整站。

兼职做一做产品经理的角色，最后得到的这一新东西比再写一份漂亮长文有用得多了。

工作流不稳，先查是不是「又重写了一遍」

很多人以为二次需求翻车是因为「新需求说不清楚」。其实不是的，二次迭代我更常看到的是另一类故障问题：

没有变更契约与约束。 鬼知道之前的版本是什么？谁还记得几个星期前或者几个月前的需求是什么？

目前大致上同一轮增量，文档可以写成：

•整份新 PRD，和上一版对不上号；

•群里几句「加个字段就行」；

•原型直接重生，风格漂成另一个产品。

•这里跟之前保持一样，再新增的其他。

•交互描述，前端自己看着办等等。

但是我们走 AI 编码流水线期望的是稳定增量：哪几页动、哪几页禁动、验收测 delta 还是全量回归。格式一乱，Agent 只能猜，边界太模糊了。

但是我们永远不要赌。让 AI 猜上一版「大概可能还有效，看抽卡效果」，其实成本很高——轻则把没动的页面也改了，重则把禁改的比如品牌色当「优化体验」给换了。AI 如果意会错啦，万万后果很严重，没人想去review AI 写的那些代码。太痛苦啦～

所以 prd-iterate 核心要解决的不是「把文档写得更长」，而是两件事：

1.让本版变更可见，包括（新增 / 保留 / 必改 / 禁改）

2.让下游知道：原型只能增量改，不能整站重生

这是工程护栏边界问题，不是「产品交互体验好不好看」的问题。

设计之初：就锁死三件事

我之前的第一版定调很简单。核心不是帮你写更长的 PRD，是管住迭代范围与方向。

1. 必须有基线 没有上一版 PRD，就别硬走迭代——那是全新功能，该用 prd-three-layer-template 从零写。缺了基线或缺新需求时，只列「待补充」，不许瞎编上一版内容再成稿。

2. 顶部必须有具体的功能变更地图模块，以下四块齐全

没有这四块，就算写了一大篇，也不算完成。每条还得落到页面名或模块名——写「优化体验，交互改进」这种空话，直接不合格。都需要明确的，不要泛化空话。

3. 有旧原型：先复制，再改；禁止整站重生 没列进「新增 / 必改」的文件默认不动。视觉交互从旧稿抽风格接着用，不能另起一套 AI 默认皮肤。

另外还有一条边界：这个技能只出 PRD + 原型，不写业务代码。实现另走研发流程。

新的 PRD + 原型，只为明确本次迭代功能是什么 ～

后来发现：归类才是坑，冲突必须停

在后续使用技能的过程中，我使用了一阵子之后，我发现，真正难的不是「有没有具体的需求变更功能地图」，是每条新需求该进哪一个之前的板块，或是新的板块。

其实人一但想糊弄，就会写出「优化体验，交互优化一下」，或者把禁改项悄悄写成必改。

为此我后面就又补了几条硬规矩要求。

我不想未这些不明确的东西负担，给我自己加了负担，谁知道你要的优化体验是什么～ 每一个的体感都是不一样的。

我不想未了后续重新迭代，增加后续再次迭代的痛苦系数。

按照我的经验，当你使用AI编码完成之后，再改需求的时候，这个时候就又是另一种痛苦的开始。

四块归类（决策树，一条只进一块）

基线完全没有该能力/页面？
  ├─ 是 → 本版新增
  └─ 否（基线已有）
        ├─ 本轮明确不碰 → 旧的保留
        ├─ 已冻结 / 写明不可动 → 本版禁改
        └─ 要改行为 / 文案 / 流程 / 布局 → 本版必改

动手写需求功能地图前，我还会先问自己三句：

•这条是扩大范围（基线没有）还是改既有行为（基线已有）？

•会动到的页面，是不是已经在禁改或历史冻结里？

•本版验收应该测 delta，还是又被要求全量回归？（默认只写验收增量）

冲突时：禁改 > 必改，没裁定不成稿

需要自行定义规则，如果「必改某页」和「禁改某页」撞车，不能自己猜。先记进开放问题，用固定话术问人：

本版「必改：xxx」与「禁改：xxx」冲突。
按默认：守禁改，本版不做这条必改。
若业务必须改，请明确批准：把该项移出禁改，并留下裁定记录。
你选：A 守禁改  /  B 批准改禁改表

没裁定之前，不成稿，不改禁改面的 HTML。

听起来啰嗦，但比评审会上吵「到底能不能动品牌色」省事。

还补了一批「千万别做」——为了更好看重写公共 layout、用整个文件覆盖来冒充增量、拿 Git diff 当给产品来看的主交付。开发人其实要的是可读变更需求功能地图，而不是去会看 diff。

没有人不想轻松写代码，不要心累的写代码。

案例：注册引导从 v1 到 v2

要求就是用技能包里的标准样例说人话。真实项目把页面名换成你们自己的就行。

v1 长什么样

两步注册 + 成功页，不含邀请码。 页面三张：填手机号 → 填密码 → 「注册成功」。 评审还冻了：主色和字体别乱换；步骤 1 本轮没要求就别动。

本轮新需求（就两句）

1.注册第二步加邀请码校验；

2.成功页主文案改成「欢迎加入」。

具体的PRD如下

变更需求功能地图怎么填（节选）

本版新增

•邀请码校验（基线没有）→ 动 register-step2.html

本版必改

•步骤 2：原来只有密码 → 加上邀请码

•成功页：「注册成功」→「欢迎加入」

旧的保留

•步骤 1、两步主流程骨架、主色字体

本版禁改

•design tokens

•步骤 1 布局和字段（本轮没要求改）

V2 的PRD如下

验收怎么写

别写「把整个注册再测一遍」。只写相对 v1 的增量，例如：

•步骤 2 能看到邀请码输入；

•成功页主标题是「欢迎加入」；

•步骤 1 和 design-tokens 相对 v1 没换肤、没整页重写。

原型怎么动

有旧 HTML：整份复制到 v2 目录，只改步骤 2 和成功页；步骤 1、样式 token 保持不动。变更处可以打「本版」角标，方便评审对照。

一眼能回答三个问题：改了啥、没改啥、不许改啥——这才是迭代稿该有的样子。

变更的需求功能地图如下：

再举一个冲突例子

有人说：「登录页换个更潮的配色。」 禁改表里写着：主色 / 登录页配色冻结。

按规则这是冲突，不是偷偷写进「必改」就完事。

默认：本版不做「换潮色」。若业务坚持，必须有人明确批准改禁改表，并在变更地图留下「谁批的、结果怎样」。

没这句话，登录页配色文件就别动。

二次三次迭代，只为了需求明确，功能明确，改了什么，加了什么，删了什么。

人需要明确要做什么？不要期望让AI去猜。

按照目前我的使用经验来看，基本上所谓的交互体验优化这类的明确，或者你直接扔个html交互稿，你最终落下的PRD中没有详细写清楚的，AI 编码做出了成果中就是没有的，就算有，也会存在缺失的情况，有些模型好的会缺的少，模型差的可能就你没写它就没做。

怎么用：对话口令可以直接丢给 Agent

先准备好：

1.上一版 PRD（必填）

2.本轮新需求（必填，能拆成一条条更好）

3.上一版可点 HTML（强烈建议；有则必须增量改）

4.输出目录和目标版本，比如 …/某功能/v2/

口令可以原样丢：

请用 prd-iterate：基于 @v1/PRD.md，本轮需求是……
旧原型在 @v1/mockups/，输出到 …/v2/

期望产出：

v2/
  change-map.md    ← 四块变更地图
  PRD.md           ← 文首嵌地图的迭代 PRD
  mockups/         ← 复制后增量改的原型

有旧原型时，记住那句硬约束：禁止「根据新 PRD 从零生成整站」。

什么时候别用它

一句话：prd-iterate 管二次 / 三次需求文档 + 风格延续的增量原型。 不管从零开天辟地，也不管直接改仓库代码。

单页改两个字、没有自动化流水线，直接对话让 AI 改就行，不必强上。

不是什么需求都需要使用这个技能的，按照需求来。

一旦你在用 Agent 跑端到端，或者一个人兼产品兼前端，变更契约就会从「可选」变成「少点头疼事情的生存线」。

我们需要快乐的进行AI编码。

最后总结

回顾一下这篇的核心脉络：

问题根源： 二次迭代很痛苦，存在翻车可能，经常不是新需求不会写，而是没有变更契约约束，鬼知道本次需求改了什么——整份重写 PRD、整站重生原型，评审对不上「相对上一版改了啥」，AI 只能猜边界。

不期望产品经理能给出什么友好的逆天需求文档。只能保证自己可以快乐的编码，少些痛苦。

我的解法： 不要等别人规范化，自己先建一层迭代入口。prd-iterate 把增量压成固定姿势，得到如下：

硬规矩： 禁改大于必改；冲突必须人裁定，不成稿；空话地图不合格。

踩坑教训： 有需求变更功能地图还不够，归类要准。「优化体验，交互改进」进不了任何一块；为了更好看换肤，等于主动破坏禁改。

最后需要一点清醒： 这套不是万能的，也不是每次都写得完美。全新需求走三层模板；单页小改可以直接对话。但一旦你开始用 Agent 跑端到端、或者自己兼产品，迭代契约就值得前端先动手。

统一增量入口，让变更可见，让下游知道改哪、不改哪——这件事，和统一第一份 PRD 入口一样，值得自己先做。

这个技能，后续还是需要在真实项目实践中进行多次迭代优化的。

目前还在改进完善中。

文章来自：51CTO