InSnap代码评审和 Pull Request 中怎么用好截图
只给 diff，UI 改动很难评审。一组小而精的截图——前后对照、标出重点、带上关键状态——就能让 PR 真正可评审。
一个改动按钮行为、表单校验或加载状态的 PR，光看 diff 很难判断。评审者最后只能切分支、重新构建，再去猜你说的那个界面在哪。一组小巧、做得好的截图能省掉这些工作。
截下改动前后
对任何看得见的改动，把同一屏截两次：
- 在基分支上截下受影响的区域。
- 在你的分支上，用同样的窗口大小和缩放截下完全相同的区域。
- 两张都留着；不要只把其中一张裁得更紧。
视口、浏览器缩放和窗口大小一致，对比才有意义。如果布局是响应式的，就截几个关键宽度（比如 1280 和 390），并标注出来。
只标注差异
评审者需要知道往哪看，而不是听一场完整导览：
- 一张截图里有多个改动时用序号：1 是新的空状态，2 是错误提示。
- 用形状圈出改动的区域。
- 用文字写预期行为，尽量短。
- 任何隐私内容都用马赛克或模糊：客户姓名、邮箱、令牌、内部 URL。
不要标注整屏。如果改动只是一个控件，一个箭头加一句话就够了。
静态图不够时，录下交互
有些改动只有在动起来时才说得清：一个以前会提前关掉的下拉菜单、一个现在能正常结束的加载圈、一次拖拽交互。用快速录制录 10–20 秒，然后附上 MP4；想要在评审里直接播放，就用 GIF（Pro）。
- 如果可能，在同一段里先演示出问题的行为，再演示修好后的行为。
- 除非旁白确实补充了信息，否则关掉麦克风；静音片段自动播放是安全的。
- 片段短到能看两遍就够了。
把证据放进 PR
可预期的结构能替评审者省时间：
- 改了什么，一句话。
- 改动前 / 后图片，并排或上下摆放，每次都保持同样的顺序。
- 怎么复现截图里的状态（如果不是默认页面的话）。
- 要检查什么 —— 可能会回归的一两处。
- 环境（如果重要）：系统、浏览器、显示缩放。
把图片直接附在 PR 里，而不是链到个人网盘。如果用分享链接，记住它可能过期或需要密码；代码评审里，附件通常更好。
让截图组保持精简
评审者是扫着看的。三张聚焦的截图会被认真读，十五张会被直接划过去。
- 每个可见改动一组前后对照。
- 裁掉浏览器外框和无关面板。
- 只用来交代背景的图可以压缩或缩小；像素级改动保持原分辨率。
- 角度稍有不同、状态却重复的截图，删掉。
提交前检查清单
| 检查项 | 原因 |
|---|---|
| 前后截图的视口和缩放一致 | 否则对比不成立 |
| 一张图只说一个改动 | 更容易讨论和收尾 |
| 标注指向改动处 | 不用到处找 |
| 隐私数据已遮住 | PR 的可见范围往往比想象中大 |
| 只在需要动态时用视频 | 短才有人看 |
| 用附件，不用个人链接 | 评审者不该还要登录 |
常见问题
应该附截图还是屏幕录制？
状态用静态图，交互用短片段。10–20 秒的录制足够展示一次过渡；再长通常就没人看了。
评审截图里怎么藏客户数据？
姓名和 ID 用强度拉高的马赛克，机密内容用实色盖住，或者干脆裁掉那块区域。模糊比马赛克弱，不要用来处理敏感内容。
做评审截图需要 Pro 吗？
截屏、标注、序号、马赛克和基础 MP4 录制都不需要。GIF 导出、智能擦除和视频编辑器的效果是 Pro 功能，但大多数评审用一组静态图加一个 MP4 免费就够了。
