图像与视频 编辑复核
产品界面视觉 Brief
把产品功能和用户任务转成可用于界面截图或概念图的视觉 Brief，避免生成与实际产品不符的画面。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名产品视觉导演。请根据真实产品功能设计视觉 Brief，清楚区分真实 UI 截图、概念画面和装饰性素材。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 用户任务、产品状态和必须出现的界面元素
2. 画面层级、视角、构图和重点交互
3. 颜色、材质、光线和品牌限制
4. 不可伪造的功能、数字和用户数据
5. 桌面/移动版本、替代构图和验收清单
输入变量：
- 产品功能（{{product}}）：说明真实功能、流程和当前状态。
- 观看者（{{audience}}）：说明画面给谁看、在什么渠道出现。
- 品牌视觉（{{brand}}）：提供颜色、字体、禁用元素和已有资产。
- 输出规格（{{format}}）：说明尺寸、画幅、是否需要文字可读。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 真实产品画面优先使用截图或可复现界面，生成图只做概念表达。
- 生成后核对文字、Logo 和功能是否被模型虚构。
WHEN IT FITS
适用判断
适合这些情况
- 界面设计需要方向指引，但不想限制得太死。
- 要保证和已有产品的视觉一致。
- 有明确的功能需求需要视觉承载。
换个做法更好
- 你要展示的是已有界面：用《产品界面截图展示 Brief》。
- 有成熟的设计系统：按系统来，brief 是多余的。
- 功能需求还不清楚：视觉做完要返工。
FAILURE MODES
常见翻车与修正
- brief 直接指定了具体的布局和组件，设计师没有发挥空间。
brief 应该说明约束和目标而非结果。要求描述用户要完成什么、有哪些限制，具体方案留给设计。
- 没说明极端情况，比如内容为空或超长时怎么显示。
要求列出空状态、加载中、错误态和内容超长的处理要求，这些是最容易漏的部分。
- 只考虑了理想数据，实际数据一放进去布局就崩。
要求提供真实的数据样本作为设计依据，包括最长和最短的情况。
ACCEPTANCE
怎么判断输出合格
- brief 说的是约束和目标，不是具体方案。
- 空态、加载、错误和超长内容的处理都有要求。
- 基于真实数据样本，不是理想化内容。
- 和已有产品的视觉一致性要求明确。
SAFETY BOUNDARY
使用边界
- 概念视觉里的功能不能超出产品实际能力，官网展示会被当作功能承诺。
- brief 里引用的真实数据样本要脱敏，设计稿常在外部协作工具里流转。