网站建设中图片需求清单应该写到什么程度 - 多人协作交付不返工的标准
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /eb05b3c39888.html
📄
网站建设中图片需求清单应该写到什么程度 - 多人协作交付不返工的标准
需求清单要写到“另一个人拿着它就能独立完成图片准备与上传，不需要再问一句”的程度。具体说，每张图应写清用途位置、尺寸比例、文件格式、内容要求、命名规则、替代文本和交付时间。低于这个程度，协作中必然出现反复确认；高于这个程度，又会把时间耗在无意义的细节上。
用一个假设例子看清清单颗粒度
假设一个五人小组在做一个企业展示站，成员包括策划、设计、前端和两名内容编辑。策划只写了一句“首页放几张产品图”，结果设计交了三张不同比例的横图，前端在移动端裁掉了主体，内容编辑又把带水印的版本传了上去。返工两轮后，项目延期三天。问题不在能力，而在清单没有写到可执行的程度。把同一需求改写成清单后：
- 位置：首页产品模块第 1 至第 3 张轮播图。
- 尺寸：桌面端 1920×800 像素，移动端同图裁切为 1080×1080 像素，主体居中偏上。
- 格式：JPG，单张不超过 300KB；需要透明背景的图标另用 PNG。
- 内容：每张展示一款产品实物，背景为纯色，不出现文字水印。
- 命名：product-01.jpg、product-02.jpg、product-03.jpg。
- 替代文本：写明产品名称与用途，不堆关键词。
- 交付：设计在周四前放入共享文件夹，内容编辑周五核对。
这份清单没有写摄影参数、色号或压缩算法，但每个执行者都知道自己该做什么、做到什么标准。这就是合适的程度。
清单必须覆盖的六个字段
判断一份图片需求清单够不够用，可以对照六个字段逐项检查。缺任何一项，都可能成为返工点。
- 位置与用途：图片出现在哪个页面、哪个模块，是横幅、缩略图还是正文配图。用途不同，裁切方式和信息密度完全不同。
- 尺寸与比例：给出像素值和宽高比，并说明是否需要多套尺寸。只写“大图”等于没写。
- 格式与体积：明确 JPG、PNG、WebP 或 SVG，并给出体积上限。体积上限直接决定加载表现，属于必须约定的项。
- 内容与风格：主体是什么、背景如何处理、能否出现文字或水印、色调倾向。多人协作时，风格描述比尺寸更容易产生分歧。
- 命名与目录：统一命名规则和存放路径，避免出现“最终版”“最终版2”这类文件。
- 替代文本与责任人与时间：谁写 alt 文本、谁审核、什么时候交付。这三项经常被漏掉，却是协作中最容易卡住的环节。
哪些细节可以省略
清单不是越细越好。以下内容通常不必写进图片需求清单：具体相机型号和拍摄参数、精确到十六进制的色值（除非品牌规范已固定）、压缩工具的版本号、图片在服务器上的存储路径。这些属于执行者根据现有条件自行决定的范围，写进去反而增加维护成本。判断标准很简单：这个细节如果写错，会不会导致图片无法使用或需要重做？会，就写；不会，就交给执行者。
多人协作时的两个检查动作
第一，交付前由需求提出方对照清单逐项打勾，重点看尺寸、格式、命名和 alt 文本四项。第二，前端在接入后检查图片在桌面端和移动端的实际显示效果，确认主体没有被裁掉、没有变形。这两步各花十分钟，能挡掉大部分返工。
如果团队反复在图片上出问题，可以把上面六个字段做成一张固定表格模板，每个页面填写一份。模板稳定后，需求清单的编写时间会明显下降，交付质量也会更一致。下一步建议先挑一个正在进行的页面，用这份字段表重写它的图片需求，再对比之前的版本，看哪些字段是原来漏掉的。
