让AI先写页面职责,再生成界面
文章建议在让AI生成布局前,先定义页面目的、决策所需信息、关键操作,以及加载、空白和错误状态。移动端适配也应保留任务必需的信息与能力,避免界面精致却无法完成业务操作。
AI 深度解读
AI agent 生成的订单状态页,可能卡片齐整、图表漂亮,却没讲清订单走到哪一步、出错后怎么办,甚至在手机上把取消按钮藏没了。问题出在布局之前:页面究竟要完成什么任务,还没有定义。
Design Decision Method 的第 5 步给了一个很轻的约束:先写清每个视图的用途、决策信息、操作和状态,再让 agent 安排布局。它值得读的地方,是把「看起来完成了」变成一组可以逐项检查的要求。
为什么漂亮页面容易答非所问
作者用订单状态页说明一种常见偏差:agent 接到需求后,直接套上熟悉的仪表盘样式,附送迷你趋势图,主按钮写着「Explore insights」。真正重要的订单身份和状态反而不突出。
作者的解释是,agent 擅长补全视觉模式,却未必能判断这个模式是否适合当前任务。监控仪表盘和订单状态页都可能出现数字,但查看单个订单的人,通常需要知道进度、下一步,以及自己还能做什么。
页面用途没有写清,装饰就容易占据任务的位置。
先写用途,相当于给后面的设计设定验收条件。趋势图能帮助用户决定下一步吗?「Explore insights」属于查订单的任务吗?如果答不上来,就没有必要加入。状态、下一步和出错后的恢复入口,也不该为了留白而被挤掉。
写几行视图说明,具体要写什么
原文中的 example.com 小店只是演示,不是真实案例,也没有测量结果。作者为它拟定的订单状态页说明,可以整理成五项:
- 用途是展示一个订单当前在哪里、接下来会发生什么,以及顾客能采取哪些操作。
- 决策信息包括订单 id、当前状态、最后更新时间、下一步、商品明细和客服入口。
- 操作包括查看物流、在允许时取消订单、联系客服,以及返回订单列表;查看物流的前提是存在承运商链接。
- 状态包括加载、空、错误和正常展示,各自都要定义页面如何回应。
- 设备适配从手机开始考虑,取消和客服入口必须可用,不能依赖仅悬停时出现的控件。
其中最有用的是状态说明,因为只写「支持 loading、empty、error」依然很容易敷衍过去。
加载时要保留订单上下文,让用户知道正在查什么;空状态要说明这个 id 没有对应订单,并提供返回路径;错误时仍然显示订单 id,同时提供重试和客服入口。正常展示则要让状态与下一步直接可读,无须借助图表才能理解。
这里没有要求所有页面都具备同一套状态。原文的限定是:列出适用于当前视图的状态,包括确实存在的加载、空和错误情况。
手机适配也有明确标准:布局可以调整,任务需要的能力必须保留。按钮变小、卡片换行都不是最终验收点,用户能否继续取消订单、寻求帮助,才是要检查的事。
这套方法适合放在哪一步
「structure each view」是六步流程中的第 5 步。完整顺序是:建立上下文、选择视觉系统、在布局前梳理对象关系、记录设计决策、组织每个视图,最后交付与验证。
它的位置很合理:前面先确定任务和关系,再把这些决定落实为具体页面,避免每次又从一个通用模板开始。
Design Decision Method 面向使用 AI agent 构建界面的开发者,遵循开放的 Agent Skills 格式,采用 MIT 许可证。原文说 README 提供 Claude Code、Cursor、Gemini CLI 和 Codex 的安装路径,但没有展开具体命令。
作者也给了使用边界。修改一行文案,无须补完整的视图说明;新增页面、改变用户作判断所需的信息,或者可能让某个操作在小屏幕上消失时,才值得写下这几行。
我的判断
我认同它把视图说明提前的做法。页面截图很容易让人只看间距、颜色和卡片,而用途、异常状态、操作条件一旦写出来,评审就有了更具体的依据。
但它提供的是检查框架,不能替团队确定需求。订单什么时候允许取消、物流链接来自哪里、哪些错误可以重试,仍然需要业务规则和接口约束。说明写得含糊,agent 依然可能自行补全。
和直接提供参考截图相比,它更能约束页面要完成的任务;和完整交互规格相比,它更轻,但覆盖范围也有限。它可以补在现有需求或组件规范里,原文没有证据证明必须安装这套技能才能获得效果。
作者没有测量节省时间的效果,这是一套有道理的经验流程,还不是效率结论。
它也没有给出采用前后的可用性对照数据。可以确认的收益,是团队多了一份在界面定型前就能检查的视图定义。
能拿来做什么
- 下次让 AI 新增订单状态页时,先提交用途、必要信息、操作、状态和手机适配要求,再要求生成布局,避免只给一句页面名称。
- 评审 AI 生成的界面时,分别检查加载、订单不存在、请求错误和正常展示,确认订单 id、下一步与恢复入口在对应状态下是否合理。
- 检查窄屏页面时,实际寻找取消和客服入口,并确认触屏操作可用,把任务能力是否保留作为验收条件。
- 修改涉及决策信息或操作位置时,同步更新那几行视图说明;单纯调整一句文案,则按原文建议保持流程轻量。