PRD图片文档规范：从命名标注到版本管理的完整指南-开发者社区

PRD里放图片这件事，看起来根本不算个事儿，但真正在项目里跑过几个版本的人都清楚，图片文档恰恰是最容易翻车的环节。我见过需求文档写得逻辑严密、功能点拆得清清楚楚，结果一到图片部分就开始失控：视觉稿随手截屏、标注全靠聊天记录、新旧版本图混在一起，开发翻半天找不到对应配图，最后直接在评审群里问“这个空状态到底长什么样”。所以这篇文章我想把PRD图片文档这件事单独拎出来讲透，聊聊它为什么容易被低估、怎么定规范、实际交付时有哪些坑能提前避开。

这篇文章适合刚接手需求文档的新手产品，也适合带团队想统一文档标准的资深从业者。我会从图片文档在PRD里的职责讲起，给出一套可直接复用的命名、标注、归档规范，再拆解从产出到交付的完整实操流程，最后整理几个高频踩坑场景和排查思路。不说虚的，都是能直接落地执行的东西。

1. 为什么“图片文档”在需求文档里最容易被低估

1.1 需求文档里图片的三种职责

先想清楚一个问题：PRD里的图片到底在替文字干什么活？

我自己总结下来，图片在需求文档里承担三种职责。第一种是示意，用来描述界面布局、交互状态、视觉风格，属于“说不清楚，直接看图”的补充说明；第二种是定版，比如最终视觉稿、切图标注稿，这类图是设计和开发之间的交付契约，开发要按照这张图来量间距、取色值、导出资源；第三种是留痕，比如竞品截图、历史版本对比图、用户反馈中的现场图，这些图记录了决策依据和演进过程，防止后续追溯时凭记忆扯皮。

很多团队只把图片当“配图”，随手扔进文档里就不管了，问题就出在这里。图片没有职责区分，就没有对应的管理方式。示意性质的图可以粗糙一些，但定版性质的图必须清晰、完整、版本可控；如果混着放，开发根本分不清哪张是最终稿，哪张只是参考。

1.2 图片文档和文字需求的分工边界

图文分工这件事，处理得好能大幅提升评审效率，处理不好就是灾难现场。

文字的优势是精确表达逻辑关系、边界条件、异常流程，比如“当网络超时3秒时，显示重试按钮”，这类信息用文字写最稳。图片的优势是直观展示空间关系、视觉层次、交互细节，比如某个弹窗的布局、按钮的圆角大小、空状态的插画风格，这些内容如果用文字描述，写出来又臭又长，开发还得自己脑补。

所以正确的分工应该是：逻辑靠文字，视觉靠图片，两者互相引用而不是互相替代。我在实际写需求时有个习惯，凡是涉及界面表现的描述，一定配图；凡是涉及流程逻辑的描述，一定用文字加编号。图片和文字之间用明确的标记关联，比如在图片下方标注“见图3-2”，在正文里写“该弹窗的视觉样式参见图3-2”，这样两边的读者都不会迷路。

1.3 一张模糊图的隐性成本

一张不清晰的配图，看起来只是“观感不好”，实际消耗的成本远超想象。

开发拿到模糊图，第一步是去问设计要原图。设计翻了半天找到原图，发现版本已经更新过，于是又去问产品要最终版。产品发现自己当时从聊天记录里存的截图，已经找不到出处了。这个链路走下来，三个人各花了十五分钟，再加线上沟通的等待时间，四十五分钟就没了。如果这张图恰好是登录页这种核心页面，可能引发一系列连锁问题：开发按旧图做完，视觉验收不通过，返工重做。

这种成本在单个需求里不显眼，但一年积累下来非常可观。所以我现在看一个团队的文档规范是否成熟，先看他们的配图是否清晰、是否带标注、是否能追溯来源。

2. 一套可以直接复用的PRD图片文档规范

2.1 目录结构与命名规则：先解决“找不到图”的问题

图片文档的第一步不是画图，而是先把目录结构和命名规则定下来。没有规则，图越多越乱，最后连自己都找不到。

我常用的目录结构是按需求模块分层：

01-需求总览 01-需求背景 02-用户流程图 02-功能模块 01-登录注册 02-首页 03-个人中心 03-视觉参考 01-竞品截图 02-风格参考 04-设计交付 01-最终视觉稿 02-切图资源

这套结构的原则很简单：先按文档章节走，再按功能模块走，最后按图片性质走。每张图的命名要包含三个要素：所属模块、图片内容、版本号或日期。

命名示例：

登录页_视觉终稿_v2.0.png
登录页_错误提示态_v1.1.png
首页_竞品截图_某平台202405.jpg

这样的命名有两点好处。一是搜索方便，如果开发想要登录页的最终视觉稿，在文件夹里搜“登录页”加“终稿”就能定位；二是版本可溯，文件名里带上版本号，就算同模块有多张图也不会混淆。这里我特别想强调一点：图片名里千万不要写“最终版”“最新版”“修改版”这类含糊词，因为“最终版”永远不可能是最终版，三次修改之后就会出现“最终版”“最终版2”“最终版3（不要再改）”这种惨状。

2.2 图片尺寸、清晰度与格式的硬性约定

图片的质量参数看似细枝末节，却直接影响开发的读取效率和设计的交付效果。

我在团队里推的硬性约定是这样的：

位图分辨率不低于1440px宽（针对Web端），移动端截图保持1倍到2倍图的实际像素；
导出格式上，界面截图统一用PNG，禁止用JPG。原因是JPG压缩会导致文字边缘发虚，尤其在深色背景上特别明显。PNG能保住边缘质量，体积大一点但完全值得。
涉及交互状态的图，必须保证状态完整，不能截一半。比如要展示下拉菜单，至少要把触发元素和展开的面板放在同一张图里。

注意：截图后不要直接用聊天工具发送再另存，聊天工具的压缩算法会二次损伤画质。正确做法是截图后直接保存原图，再通过文件形式传到文档里。

尺寸这块我补充一句，不是所有图都要大尺寸，关键是有用的细节能被看清楚。如果一张图中包含多处细节，可以截整页加局部放大两张一起放，整页给全局感，局部放大给细节依据。

2.3 截图标注的通用标记规范

裸图放进PRD是远远不够的。没有标注的图片，读者只能靠猜，猜就有偏差，偏差就会导致返工。

标注规范核心是三件事：框、字、线。

框，就是在需要重点展示的区域画红色或蓝色框。红色框表示“这个区域是本次需求改动的位置”，蓝色框表示“这个区域是联动区域或参考区域”。一套图里只出现这两种颜色，不要五颜六色，否则视觉焦点全乱了。

字，就是在图片旁边加上简短说明。说明要回答“这张图要表达什么”，比如“点击右上角按钮后，显示下拉选项”，而不是写“这个页面好看”这种主观评价。文字放在图的左下方或右下方，字号统一。

线，就是用引线把图片中的区域和说明文字连起来。引线要细，不要遮挡关键内容，箭头要小，指向要精准。

这里有个容易忽略的细节：所有标注做完之后，要保留一张无标注的纯净原图放在旁边。开发在实现时需要干净的视觉稿，设计在后续改版时需要原图，两张一起放，各取所需。

2.4 版本标识与变更记录

图片文档最怕的就是版本混乱，尤其是多次评审后的视觉稿，谁改过、改了什么、对应哪版需求，必须可查。

我的做法是给每张重要图片加版本标识，形式不必复杂，在图片下方加一行小字即可，比如“v2.0 2024.06.18 更新按钮颜色”。如果团队用在线协作文档，可以直接利用文档的更新记录功能，但前提是图片本身要替换而不是另存副本。很多团队习惯“旧图不删，新图另存”，结果图库里堆积了几十张相似图片，谁也不知道哪张有效。

版本变更记录建议用表格集中维护，列为“图名、版本、日期、变更内容、关联需求编号”。这张表放在需求文档开头或结尾的附录里，评审时先看变更表，再逐个看图，效率会高很多。

3. 图片文档从产出到交付的实操流程

3.1 收集与预整理：视觉稿、原型图、竞品截图怎么归档

需求文档的配图来源，大致有三个：设计提供的视觉稿、产品自己画的原型图、用来佐证方案的竞品截图。三个来源的归档方式不一样。

视觉稿是正式交付物，归档时要放到“设计交付”目录，文件名用“页面名+内容描述+版本号”，由设计或产品统一维护。原型图是过程资产，放在“功能模块”目录下对应模块里，画得粗糙没问题，但关键交互状态要能表达清楚。竞品截图是参考材料，放在“视觉参考”目录，截图时注意带上可辨识的界面元素和来源信息，以免后面想回看原页面找不到出处。

收集环节有个工作习惯很关键：第一时间记录图片的来源和用途，不要等到最后统一补。我当时整理一套大型后台需求文档，有近两百张图，就是因为随时归档，整个过程没出过乱子；相反，有个同伴习惯先攒截图最后再整理，结果光核对来源就花了一天。

3.2 标注与说明：每张图要想清楚“读者需要看什么”

给图片写说明，不是写“这张图是XX页面”，而是要写“读者从这张图里应该得到什么信息”。

实操的时候，我会对每一张重点图片问自己三个问题。第一，这张图表达的是哪个页面或哪个组件；第二，这个页面或组件的关键状态是什么；第三，开发看到这张图时最需要关注哪块内容。三个问题想清楚，标注自然就有了方向。

比如一张登录页视觉稿，标注里写“登录页视觉终稿，注意表单校验错误时输入框边框变红，提示文案显示在输入框下方”就比“登录页图片”有用得多。再比如一张空状态图，标注“当订单列表为空时显示此页面，插画+文案居中，按钮为底部通栏样式”就把关键信息点透了。

注意：图片说明不需要写成完整句子，用短语或短句列出关键点即可，越精确越好。复杂的说明放在正文对应章节，图下面只放关键提示。

3.3 嵌入文档与独立交付的取舍

图片文档最终怎么交付，有两种主流方式，分别是嵌在PRD正文里和独立整理成图片附录材料。

嵌在正文里的优点是阅读流畅，评审时不用来回切换文件，开发对照需求文字和图片很顺手。缺点是如果图片过多，文档会变得很长，加载缓慢，而且设计稿更新后需要同步替换文档里的图片。这种情况适合中小型需求，或者页面改动不多的迭代。

独立整理成图片附录的优点是设计团队可以单独维护，版本更新不影响正文结构，适合大型项目或视觉稿频繁调整的阶段。缺点是开发需要来回对照两套文件，容易看漏，评审时展示也不够直观。

我的建议是分层结合：PRD正文中嵌入关键页面的示意图和交互状态图，保证主流程可读；完整的视觉稿和切图资源单独整理成设计交付文档，在PRD里放索引链接。这样做兼顾了阅读效率和版本维护。如果是轻量需求，直接嵌入正文就够了，不用搞两套。

3.4 评审前后的图片文档检查清单

图片文档提交评审前，值得花十分钟过一遍检查清单。这个清单是我吃过亏之后总结出来的：

关键页面是否都有配图，是否有“文字描述了很多，但对应页面没有图”的空白区；
每张图是否清晰可读，是否被压缩模糊；
每张图是否有名称、版本号、日期；
每张关键图是否有标注，标注是否指向明确；
图片中的交互状态是否完整，是否有起止状态；
文档中描述的状态是否都能在图中找到对应；
是否有过期图片残留，版本号是否与当前需求一致。

评审结束后，根据评审意见更新图片，同时更新版本表和变更记录。这个动作要养成肌肉记忆，因为评审中提出的问题如果不落到图片版本上，下次评审还会被同样的问题再问一遍。

4. 高频踩坑现场与排查技巧

4.1 图片模糊：从源头阻断压缩，而不是事后补救

图片模糊是最常见的问题，背后的原因是图片在流转过程中被多次压缩。

排查思路是追根溯源：先看原图是否清晰，如果原图清晰，那就是文件流转出了问题。聊天工具传输会压缩，部分在线文档上传也会二次压缩，这是两个最大的“画质杀手”。解决办法也很简单，关键图片不要通过聊天工具传，直接用文档附件的原图功能上传；在线文档如果压缩严重，就把图片打包成压缩包上传，或者单独走文件管理平台。

另一个隐蔽的模糊源是“复制粘贴”。从网页或设计工具里直接复制图片粘贴进文档时，粘贴的是压缩后的位图，不是原图。正确做法是先保存文件，再以文件形式上传插入。

4.2 图片和文字描述不一致：统一信息来源，别让两边打架

图片和文字描述对不上，是评审中最尴尬的场面。产品在台上讲得头头是道，开发指着大屏幕说“这图和文档里写的不一样”，场面瞬间失控。

这个问题的主要原因是图片和文字的更新节奏不一致。有些人先改文字忘了换图，有些人换了图忘了改文字。解决思路是在文档结构上强制图文关联，比如每张图下方都标注“对应正文第X.3节”，正文对应的描述里也标注“参见图X-X”，这样哪边遗漏了更新，第一时间就能发现。

如果团队用在线协作文档，推荐把所有相关文字和图片放在同一页面区域，利用文档的版本历史来查看改动记录。版本历史是追踪图文不一致的利器，谁在什么时间改了哪一段，一目了然。

4.3 版本更新后图片没同步：把更新动作变成流程，而不是记忆

图片没同步，本质上是因为“同步”这件事只靠个人习惯，没有变成流程。

我踩过的坑是：某次评审后，视觉改了按钮位置，但产品只更新了图片，没有更新文字描述，也没有更新变更记录。下一轮联调时，开发照着旧文字实现，设计以为开发看了新图，两边对不上，最后产品背锅。

从那以后，我把“图片更新”拆成一个固定动作清单：换图、更新图名版本号、改正文对应描述、同步变更记录表。四步走完，才算完成一次图片更新。这个过程看起来很琐碎，但形成肌肉记忆之后，一分钟就能做完，省下的是后面沟通扯皮的时间。

4.4 产品、设计、开发三方视角的差异：把抽象对齐变成具体协作

同一张图，在三种角色眼里是三种东西。产品看到的是需求意图，设计看到的是视觉表现，开发看到的是布局参数和实现成本。

三方视角不一致，在图片文档里表现得特别明显。产品觉得“这个按钮放在这里不就完了”，设计纠结的是按钮的层级和视觉重量，开发关心的是这个位置在响应式布局下怎么处理。如果图片文档里只有一张孤零零的设计图，没有说明设计意图、交互逻辑和实现约束，开发就只能自己猜，猜错就是返工。

我现在的做法是，重要图片旁边附上简短的“设计意图说明”和“交互逻辑说明”。设计意图说明告诉读者“这个页面为什么这样设计”，交互逻辑说明告诉读者“这个页面有哪些状态切换、边界情况怎么处理”。这两段文字不用长，三五句就够，但能把三方视角拉到同一个频道上。

4.5 常见问题速查表

问题现象	直接原因	排查与解决
图片模糊	聊天工具压缩、粘贴压缩图	原图通过附件上传，禁止直接粘贴
图文不一致	文字和图片更新不同步	图文相互引用，对照版本历史检查
找不到对应图	命名混乱、目录结构不清晰	按模块归档，文件名带模块和版本号
新旧版本混乱	旧图未清理、版本号缺失	建立变更记录表，及时更新版本标识
开发误解图片	缺少标注和说明	关键图加框、字、线标注，附设计意图
评审发现缺图	写文档时漏检查	按检查清单逐项过，重点页面无遗漏