01先确定这份反馈要回答什么问题
排截图前，先写一句很普通的话，说明这份反馈要完成什么任务。比如：Apple Pay 返回后结账失败，旋转图片后导出按钮消失，移动端菜单挡住价格卡片，保存项目重新打开后文字丢失，或者确认邮件收到了但链接打开了错误页面。这句话会决定哪些图片应该进入拼图。没有它，拼图就会变成一堆界面瞬间，读者还要替你把案情拼起来。
一张有用的 Bug 拼图通常回答四个问题：用户想做什么，原本期待发生什么，实际发生了什么，哪些上下文可能影响复现。上下文不是所有可能细节，而是少数可能有用的线索：浏览器、设备、账号状态、套餐类型、语言、文件类型、屏幕尺寸、网络状态，或者失败前的关键一步。读者不应该像审讯图片一样，自己寻找故事。
这和教程截图拼图不一样。教程讲顺利路径；Bug 反馈讲坏掉的路径。两者都需要顺序，但 Bug 反馈还需要更清楚地标出不确定性。如果你不知道问题到底来自 Safari、翻译页面、某个上传文件还是过期会话，就用标签说明观察结果，不要把猜测写成结论。
02少选几张截图，让每一张都有理由存在
最容易犯的错误，是把所有截图都放进去，因为少一张好像就不保险。可截图越多，反馈未必越强。如果读者要检查九张几乎一样的屏幕，很可能错过按钮变化、toast 出现、价格更新或布局错位的那一秒。拼图应该收窄注意力，而不是证明你已经很努力。
一个实用结构是三到六格：起始状态、操作、如果有参考就放预期状态、实际结果、错误消息或控制台线索、环境备注。如果问题只在很长流程之后出现，放最关键的检查点，而不是把一路上无聊的页面都塞进去。如果已经有录屏，拼图仍然可以作为索引图，告诉别人应该看视频里的哪几帧。
围绕证据大胆裁切。完整手机截图看起来诚实，但真正有用的细节可能只占一个小角落。保留足够界面上下文来证明位置，然后裁掉无关的浏览器外壳、通知、壁纸、标签页和空白区域。在在线拼图工具里，稳定网格加清楚标签通常比花哨布局更好，因为读者的注意力已经花在问题本身了。
03呈现预期和实际，但不要假装已经知道原因
预期和实际，是很多 Bug 反馈的核心，但要谨慎处理。预期不一定代表产品客观错误。有时是界面让用户形成了某种期待；有时是文档承诺了某个行为；有时是旧版本曾经这样工作；有时用户只是因为下一步不清楚而卡住。一张好的拼图，会给这些差异留空间。
可以用这些标签：预期、实际、之前可用状态、设计参考、文档说明、用户以为会这样、下一步不清楚。标签很小，但能避免反馈比证据本身更武断。如果你在对照设计稿或发布说明，只截取相关部分，并在工单正文里附源链接。拼图应该支撑反馈，而不是变成全部档案。
对于视觉 Bug，尽量把正确参考和错误结果以相同尺度并排放。按钮错位、卡片溢出、文字换行难看、裁切切掉人脸、导出图片发糊，这些问题在公平对比中更容易判断。前后对比排版指南里的判断同样适用：对比图应该让差异明显，但不要为了显得严重而夸张。
04如果复现很重要，就把顺序做出来
有些 Bug 是单屏问题，有些只会在特定路径之后出现。如果顺序重要，就给每个格子编号。不要假设读者一定会从左到右理解顺序，因为图片可能在手机上查看、被工单系统压缩，或者被聊天软件裁切。小小的步骤编号不是装饰，而是证据的一部分。
每一步标签保持短：打开项目、添加图片、旋转、导出、返回、重新打开、切换语言、使用优惠码、上传 HEIC、同意权限、点击返回。如果一个动作长到塞不进标签，把细节写在工单正文里，让拼图只展示可见检查点。截图拼图应该让路径可读，而不是在需要精确复现时取代文字步骤。
对于很长的流程，可以用长图保存原始记录，用拼图做摘要。截图拼接工具适合把聊天、教程或完整走查保存在一张长图里，而 Bug 拼图只突出行为变化的两三帧。这样能同时照顾两种读者：快速分诊的人，以及之后需要完整路径的人。
05只放可能改变判断的环境线索
环境信息很重要，但也很容易变成噪音。一个只在窄屏手机、特定语言、WebP 导出或访客会话下出现的问题，需要这些线索。一个弹窗里的错别字，通常不需要把用户电量、位置和完整浏览器版本都放进图片。目标是给下一位处理者足够上下文，帮助复现或排除常见原因。
可以留一条很小的环境栏：设备、浏览器、已知系统、可见 App 版本、语言、账号状态、文件类型、图片数量、导出格式、视口尺寸或权限状态。保持事实，不要把没有验证过的东西标成原因。“在 iPhone Safari 观察到”通常比“Safari 导致”更有用，也更诚实，除非你真的已经测试过其他浏览器。
涉及支付、登录、学校、医疗、工作或客户系统时尤其要小心。截图可能暴露账号名、客户 ID、订单号、邮箱、内部 URL、功能开关和私有后台。如果某个细节是客服处理必需的，优先放在安全工单字段里，而不是烧进一张到处转发的图片。拼图应该推动问题前进，而不是制造新的隐私问题。
06图片离开小范围之前先打码
Bug 截图里很容易带出意外信息。浏览器标签页、书签、控制台日志、邮箱、真实姓名、工作区标题、付款金额、API key、带 token 的 URL、私密聊天、地图位置、孩子姓名和客户数据，都可能安静地躲在截图边缘。拼图会让这些细节更容易扩散，因为它把几个私密瞬间变成了一张方便转发的文件。
导出前放大检查每个格子。先裁切，再遮住仍然不该流转的内容。如果问题本身涉及私密内容，可以做两个版本：一个只含最低必要细节的私密客服版，一个去掉敏感字段、适合团队或公开范围查看的版本。对于泄露后可能造成损害的密钥和 token，不要依赖随手一模糊；如果细节不必要，就应该完全移除或遮死。
浏览器本地图片处理隐私指南解释了为什么在浏览器里本地编辑图片可以减少不必要的上传暴露，但它不会自动净化最终文件。把 Bug 图发给供应商、公开 issue、社区论坛或大型内部频道前，按照片拼图发布检查清单过一遍。
07标签要降温，而不是继续加火
Bug 反馈常常带着烦躁，而这种烦躁可能完全合理。但图片上的标签通常越冷静越有用。“坏了”“错了”“没法用”“离谱”可能准确描述了当时感受，却不一定帮助别人调试。像“按钮被遮挡”“保存后报错”“返回后总价变化”“预期预览缺失”“下一步不清楚”这样的标签，更能指向可以处理的工作。
这不是为了牺牲真实感来照顾情绪，而是在节省注意力。读反馈的人需要快速识别失败状态，判断能否复现，并把问题交给设计、前端、后端、内容、计费、客服或产品。具体标签省时间。情绪如果能解释严重程度、紧急度或客户影响，可以放在消息正文里，而不一定压在每个截图格上。
如果拼图用于客服沟通，可以参考客服支持拼图指南里的原则：给客服足够行动信息，但不要让对方玩寻宝游戏。一张好的支持图片，应该像一次尊重对方时间的交接：这是我看到的，这是发生的位置，这是我有意保留在图片外的私密细节。
08为分诊、工程和回访分别保存版本
一张 Bug 拼图很少能同时服务所有人。分诊版应该短，在工单列表里也能读。工程版可能需要步骤编号、环境信息、控制台片段、网络状态或文件特征。给客户看的回访版通常要移除内部备注，只聚焦可见结果或临时绕行办法。把三类读者揉进一张图，会让图片沉重，也更容易被误用。
文件名要朴素：checkout-bug-ios-safari-2026-08-29、export-preview-missing-qa、mobile-menu-overlap-private、support-ticket-redacted、before-after-fix-check。重要问题要单独保留原始截图。拼图是摘要，不是取证容器。以后如果有人需要时间戳、原始尺寸、控制台日志、服务器日志或精确 request ID，源材料应该仍然在合适的安全位置。
问题修好后，如果对后续记忆有帮助，可以做一张最终对比：修复前、修复后、备注。这份小归档可能用于发布说明、QA 回归检查，或解释一个很细的设计修复。但不要在测试不足时宣称整个系统都已经好了。诚实的结论更窄，也更有力量：这个观察到的问题，在这条路径上，现在按预期工作。
09如何应用到快速修图
先命名问题，修正才会更快。拥挤、平、失衡、模糊、不一致、难读，分别对应不同修法。
测试修正时保留旧导出。并排比较能避免你不小心撤掉之前更好的选择。