场景锚点
把「用户觉得不方便」换成「某个具体的人在某个具体时刻正在经历什么」。抽象的需求推不出设计，具体的处境可以。
你会遇到的现象
- 团队每个人对同一句需求的理解都不一样
- 讨论方案时全靠「我觉得」，没有判断依据
- 让 AI 生成界面，它给的是一个放之四海皆可的通用页面
抽象描述的问题不是不准确，是它同时兼容太多种做法。「更快地录入」既可以是语音输入，也可以是快捷模板，还可以是自动识别，每一种都符合这句话。等你做完，才发现用户要的是第四种。
锚点的五个要素
怎么用它做决定
锚点写完之后，它就变成了一把尺子。每个方案拿过来量一遍。
| 候选方案 | 拿锚点量一量 | 结论 |
|---|---|---|
| 语音输入 | 收摊时周围吵，而且他不好意思对着手机说金额 | 否 |
| 拍照自动识别 | 他手里是零钱不是小票，没东西可拍 | 否 |
| 大按钮快捷金额 | 单手能按，被打断也不丢，符合他的常见面额 | 是 |
| 自动保存草稿 | 直接解决「回头忘了记到哪」这个主卡点 | 是 |
给 AI 的话
把锚点放进提示词里，生成的东西会立刻从通用模板变成有取舍的方案。
PROMPT · 带锚点的需求
先记住这个使用场景，后面所有设计决定都要以它为准： 谁：[具体的人，含年龄、设备、熟练度] 什么时候：[时间、地点、环境，以及手上还在忙什么] 想达成：[他要的那个状态，不是他要用的功能] 卡在哪：[具体哪一步出问题，出问题的后果是什么] 现在怎么办：[他目前的替代方案] 基于这个场景，请先告诉我： 1. 这个场景对界面提出了哪些硬约束（字号、点击区域、 单手操作、能否被打断等） 2. 你打算做的主任务是什么，为什么不是别的 3. 有哪些常见做法在这个场景下反而不适用 我确认之后你再写代码。
第三问最有用。它会逼 AI 说出「语音输入在这个场景下不合适」这类判断，而不是把所有能想到的功能都堆上去。