直接回答
只有当 screenshot recipe 被整理成一份能说明“每一张图要证明什么、文案层级怎么工作、需要出现什么视觉证据”的设计 brief 时，它才真正具有操作性。否则 screenshot strategy 仍然停留在抽象层面，设计拿到的只是彼此脱节的 overlay 文案。一个合格的截图 brief，必须把序列角色、证明点、headline、副文案、画面意图和评审标准放进同一个交接文件。团队最常见的问题，是只把几句 headline 交给设计，却没有解释为什么这些文字属于这张图；或者画面方向已经先被决定，再回头检查它是否还支撑元数据里的主承诺。真正可执行的 brief，应该让人一眼看出每一帧要证明什么，以及在设计成本变高之前必须先检查哪些点。
brief 总览
| brief 组成 | 它在解释什么 | 为什么重要 | | --- | --- | --- | | 画面角色 | 这张图在整组序列里的职责 | 防止每一帧都在做同样的事 | | 证明点 | 这张图必须证明什么 | 让视觉方向持续服务产品主承诺 | | 文案层级 | headline 和副文案如何分工 | 帮助设计保留信息重点 | | 画面意图 | 图片需要展示或暗示什么 | 避免布局和策略脱节 | | 评审标准 | 通过前要检查什么 | 让修改决策更明确 |
一份设计可执行的 screenshot brief 应该包含什么
1. 每一张图在序列中的角色
设计需要知道当前这一帧是开场、证明、流程说明、信任建立还是 CTA。没有角色说明，画面可能很好看，但整组序列仍然很弱。
2. 每一张图承载的证明点
每一帧都应该负责一个价值点、功能证明或用户结果。这样视觉处理才会持续对消息策略负责。
3. headline 和副文案的层级关系
只有 headline 还不够。设计需要知道哪些文字是固定主标题，哪些是辅助解释，版面需要为多少解释性文案预留空间。
4. 画面方向说明
brief 里要写的是“这张图需要证明什么”，而不是只写“上面贴什么字”。这一步决定了 screenshot recipe 能不能变成真正的执行说明。
5. 评审 checkpoint
溢出、一致性、叙事连续性和表达真实性，都应该在布局变得昂贵之前完成检查。
常见失效模式
设计拿到 headline，却拿不到背后的逻辑
这是最常见的交接问题。视觉团队收到了文字，却不知道为什么这段文字应该放在这一帧上。
画面方向先被批准，信息对齐后补
如果设计决定先锁定，之后才检查这张图是否仍然支撑元数据主承诺，那么这个 brief 就会从策略性文件退化成装饰性文件。
评审开始得太晚
当结构级评审只在“布局已经很贵”之后才开始，团队就会更倾向于保护沉没成本，而不是优化截图序列。
截图 brief 检查清单
- 在设计开始前先定义每一帧的角色。
- 给每一帧绑定一个明确的证明点或结果。
- 明确展示 headline 和副文案的层级关系。
- 说明画面里必须出现什么视觉证据。
- 在布局成本变高前冻结评审标准。
一个操作规则
如果 brief 说不清楚每张图要证明什么、文字层级怎么工作、以及评审通过前到底要检查哪些点，那么它还没有准备好交给设计执行。
为什么这和 StorePilot 有关
StorePilot 的价值在于让 screenshot recipe、项目定位、当前文案和评审状态留在同一个项目记录里。这使设计 brief 继续挂在同一套 launch system 里，而不是变成一份脱离上下文的创意备注。