PRD 低保真线框图：文字对不上图，先平铺一遍
文字对不上图？把 PRD 平铺成一页黑白灰线框图：流程、状态、待确认，全标出来。
产品评审上最费时间的场面，不是大家意见不合，而是同一份 PRD，每个人脑子里都长出了一版自己的图。写的人想的是三步走完的核心链路，看的人盯着的是「登录之后到底进哪个页面」；等设计稿出来才发现，权限弹窗没人提过、加载失败没定义过，而那句话在 PRD 里本来就有两种读法。
文字是线性的，产品是多线的。一份 PRD 把所有信息都写全了，跳转关系却散在不同章节里，状态描述夹在段落中间，光靠读，很难拼出完整的流程。
我把这半年攒下来的技能陆续上架到了 WorkBuddy，一共 11 个，这是第 3 篇。今天讲 PRD 低保真线框图（v1.0.0）：给它一份成文的 PRD，还你一页能从第一屏读到最后一屏的黑白灰线框图，说不清楚的地方，它不替你猜。
一、为什么要做
写需求和看需求这两种角色我都做过，最常出现的分歧不是对错，是「我以为你也这么理解」。
页面散落在文字里。PRD 会写「用户提交表单后进入结果页，结果页展示审核状态」，可结果页长什么样、有几种状态、空的时候显示什么，往往在另一章才提一句。顺着读不觉得，真要复盘完整链路，只能来回翻。
状态最容易被漏。正常流程谁都会写，异常分支没人愿意写。加载中、无数据、请求失败、权限被拒之后去哪，恰恰是开发和测试最先撞上的地方，也最容易在评审时被一句「这个后面再说」带过。
含糊的地方没人标记。跳转去向没写、字段来源不明、前后说法矛盾，这些在文档里常被一句模糊的话糊过去。评审时如果没人拎出来，就会一路带到代码里，代价翻好几倍。
所以我想要的不是一张好看的图，而是一份便宜的中间物：在 PRD 和视觉稿之间，能一眼看完、能指着说「这里没写」、改起来不心疼。线框图正好干这个活。
二、产物长啥样
输入是一份成文的 PRD，Markdown、Word、需求文档都行。输出是一个单文件 HTML，默认落在项目根目录 wireframes.html，也可以按产品命名成 wireframes-<产品名>.html，你指定路径就从你的。
打开之后，从上到下的阅读顺序就是用户真实的使用顺序，页面分四块。
页头。产品名、PRD 版本或路径、生成日期，再加三个统计：屏幕数、状态数、待确认数。评审开始前先看一眼量级，心里有数。
流程总览导航。按流程分组的锚点列表，点一下就跳到对应分组，最后一项直达文末的待确认清单。
流程分组与屏幕卡片。一个分组就是一条核心流程，组头写着流程名和它的入口、出口。组里的每张卡片是一屏，卡片头是屏幕编号、页面名称和状态标签，下面依次排着流程位置（第几屏、上一步、下一步）、黑白灰的线框主体，还有一张操作表：每一步操作会进入哪个页面或状态，都能对上 PRD 的依据章节。
待确认清单。文末汇总成一张表，编号、所在屏幕、问题描述、建议确认方，一列不少。
整个文件零外部依赖，不引外部 CSS、JS、字体和图片，全部内联，双击离线就能打开。这一点在评审场景里很实用：不用装环境，丢进群里谁都能看。
三、六条铁律
技能文档把行为约束写成了六条铁律，其中几条直接决定了产出能不能用。
只做低保真，不做正式 UI。黑白灰、基础框线、图片占位块，只表达信息层级、核心文案、按钮位置和页面状态，层级靠字号和深浅区分，不靠颜色。这是刻意的：图上一旦有了颜色，讨论就会滑向「这个蓝是不是太深」，结构问题反而没人提。主按钮是深灰底白字，次按钮是白底细边框，图片占位是浅灰块加对角交叉线，翻来覆去就这几样。
按用户真实使用的顺序平铺。分组顺序不跟着 PRD 的章节走，而是按用户实际会走的路径：典型是首次启动或引导、注册登录、核心任务、次要功能、设置。被多个流程共用的页面只画一次，放在首次出现的流程里，别的地方写一句「→ 见 2-1」。
每一屏标清四要素：页面名称、它在流程里的位置、用户可以执行的操作、操作之后会进入哪个页面或状态。四样缺一个，评审就会退回到猜。
状态要补，但补得有依据。PRD 明确提到的状态必须全部画出来，漏一个算缺陷；PRD 没提、但明显适用的通用状态，比如异步页面的加载中，技能会补画，并在卡片角上标「通用状态」，保留还是删掉交给你评审决定。状态变体屏单独成卡，编号加后缀，2-1a 就是 2-1 的加载态。
不擅自加功能，说不清就标「待确认」。这是我觉得最难得的一条：宁可图上有空缺，也不替你把 PRD 没写的功能补上。含糊、矛盾、缺失的地方统一登记为待确认项，页内是琥珀色虚线标注块，卡片角上是编号 WD-01、WD-02，文末还要有汇总表，写清问题所在屏幕、问题描述，以及建议找产品、后端还是设计确认。
四、怎么调用
技能装好之后，在对话里用自然语言说就行。技能的 description 里写明了用途和触发词，提到画线框图、低保真原型、wireframe、把流程平铺出来检查，都能触发。我真实会用到的说法大概是这几种：
「这是我们的 PRD，帮我把核心流程平铺成低保真线框图，重点看看哪些状态没定义」
「画线框图，把整个流程检查一遍，没说清楚的地方标出来」
「把所有页面按用户使用顺序平铺出来，顺手找一下跳转断点」
它内部走的流程大致是六步：通读 PRD 建流程清单、划分流程分组、逐屏生成线框卡片、补状态和标待确认、组装单页 HTML、自检后交付。
第一步会先产出一张「流程 → 屏幕编号」矩阵，比如 1-1、1-2、2-1 这样的编号，这张矩阵就是最终 HTML 的骨架；每一屏同时记下 PRD 依据，也就是章节号或原文要点。所以你在卡片上看到「点击重试 → 回到 1-1a」时，旁边一定跟着 § 章节号，能回查。
产物打开就是几条系统命令的事：
# 默认输出在项目根目录，可以按产品命名，也可以指定路径 start wireframes.html # Windows open wireframes.html # macOS xdg-open wireframes.html # Linux
交付时技能会给出三样东西：文件路径、屏数与状态数与待确认数的统计，以及待确认清单全文。这份清单不只写在文件里，回复里也会列一遍，这是文档里写明的交付约定，评审时照着推进就行。
五、边界与注意
先说最容易误解的一点：它不是设计稿。技能文档写得很直白，不适用高保真视觉稿、带真实交互的可点击原型和正式 UI 设计。线框图上没有配色、字号、间距和动效，按钮位置与文案只代表 PRD 里的描述，拿它做视觉验收一定跑偏。
它也替代不了交互设计。产出是一个静态 HTML，除了流程总览里的锚点跳转，页面本身点不动。要验证交互手感，还得靠可点击原型。
它是个后置工具，不是需求生成器。前提是项目里已经有成文的 PRD，PRD 写得空，出来的图就空。它做的是把已经写下的东西可视化，再把没写下的地方标出来，不会凭空替你想功能。
待确认多，不是坏事。如果一页图上标了十几条待确认，说明这份 PRD 正到了该补的时候，而这些正是评审要解决的问题。技能文档里也写，这份清单是最重要的评审产出之一。反过来说，如果它自作主张猜一个答案填进去，你连「这里有坑」都不会知道。
通用状态是补画的，需要你拍板。PRD 没提的加载中这类状态，卡片角上会注明「通用状态」，留或删由评审决定。
它承诺不新增功能。文档里的自检清单要求：PRD 提及的核心页面全部出现、一一对应，同时没有新增任何 PRD 没有的功能。我这次测下来，这条约束是它和「让 AI 自由发挥画原型」最大的区别：宁可留下一句待确认，也不替你脑补一个页面。
我是文茂，热衷于分享 AI 工具与开发者生态观察。觉得有用欢迎点赞、在看、转发三连。