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 常见问题速查表问题现象直接原因排查与解决图片模糊聊天工具压缩、粘贴压缩图原图通过附件上传禁止直接粘贴图文不一致文字和图片更新不同步图文相互引用对照版本历史检查找不到对应图命名混乱、目录结构不清晰按模块归档文件名带模块和版本号新旧版本混乱旧图未清理、版本号缺失建立变更记录表及时更新版本标识开发误解图片缺少标注和说明关键图加框、字、线标注附设计意图评审发现缺图写文档时漏检查按检查清单逐项过重点页面无遗漏5. 让图片文档成为团队的共同资产图片文档不只是产品经理一个人的事它连接着设计、开发和测试本质上是团队的共同资产。既然是共同资产就要有共同维护的意识而不是写完就扔。我见过比较健康的团队做法是设计提交视觉稿时自带规范的命名和版本说明产品在整合进PRD时保留原图属性并补充标注开发在拿到文档时如果发现图片问题第一时间反馈而不是默默忍受测试在用例中对照图片验证视觉细节。这样才能形成正向循环让图片文档的质量越滚越高。个人维护上我可以分享两个小技巧。第一个技巧是定期清理每个迭代结束后把过期的图片和废弃的截图清理掉保持图库干净。地方不需要天天整理但每隔一两个迭代要动手一次。第二个技巧是给常用图做模板比如空状态、错误提示、弹窗这类高频组件存成固定模板下次写需求直接套用既统一又省时间。我在实际项目中还有一个体会图片文档做得好不好和写文档的人画图水平没有必然关系有关系的是是否认真对待“别人怎么看这张图”。只要每次配图时多想想读者需要什么、哪里容易误解规范熟练之后自然就能形成习惯。最后说一个很小的经验。很多人写PRD时把图片当作“辅助材料”最后有时间就放没时间就跳过。但恰恰是这些被跳过的配图会在开发阶段变成一个个“再确认一下”的提问轰炸到群里。与其那时候被反复打扰不如写文档时就多花两分钟配好图、标好注。这个投入产出比怎么算都划算。 
长河君 · 2026/10/22 16:19:34 · 阅读 1.2k 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 常见问题速查表问题现象直接原因排查与解决图片模糊聊天工具压缩、粘贴压缩图原图通过附件上传禁止直接粘贴图文不一致文字和图片更新不同步图文相互引用对照版本历史检查找不到对应图命名混乱、目录结构不清晰按模块归档文件名带模块和版本号新旧版本混乱旧图未清理、版本号缺失建立变更记录表及时更新版本标识开发误解图片缺少标注和说明关键图加框、字、线标注附设计意图评审发现缺图写文档时漏检查按检查清单逐项过重点页面无遗漏5. 让图片文档成为团队的共同资产图片文档不只是产品经理一个人的事它连接着设计、开发和测试本质上是团队的共同资产。既然是共同资产就要有共同维护的意识而不是写完就扔。我见过比较健康的团队做法是设计提交视觉稿时自带规范的命名和版本说明产品在整合进PRD时保留原图属性并补充标注开发在拿到文档时如果发现图片问题第一时间反馈而不是默默忍受测试在用例中对照图片验证视觉细节。这样才能形成正向循环让图片文档的质量越滚越高。个人维护上我可以分享两个小技巧。第一个技巧是定期清理每个迭代结束后把过期的图片和废弃的截图清理掉保持图库干净。地方不需要天天整理但每隔一两个迭代要动手一次。第二个技巧是给常用图做模板比如空状态、错误提示、弹窗这类高频组件存成固定模板下次写需求直接套用既统一又省时间。我在实际项目中还有一个体会图片文档做得好不好和写文档的人画图水平没有必然关系有关系的是是否认真对待“别人怎么看这张图”。只要每次配图时多想想读者需要什么、哪里容易误解规范熟练之后自然就能形成习惯。最后说一个很小的经验。很多人写PRD时把图片当作“辅助材料”最后有时间就放没时间就跳过。但恰恰是这些被跳过的配图会在开发阶段变成一个个“再确认一下”的提问轰炸到群里。与其那时候被反复打扰不如写文档时就多花两分钟配好图、标好注。这个投入产出比怎么算都划算。