基础篇
进阶篇
高频篇
精选篇
手写篇
面经篇
AI 篇
原理篇
每日一题
小程序题库
  • 知识卡片碎片时间过考点
  • 场景篇按分类整理的大前端场景考点
  • 历年面经按年份追踪真实考点
  • 算法题库NEW在线编码即时判题
  • 专项自测100 题快速查漏
  • 前端基础
    • HTTP从报文一路讲到 HTTPS
    • 浏览器渲染、事件循环、进程
    • 计算机基础Linux、网络、操作系统
  • 进阶专项
    • 设计模式23 种模式怎么用
    • 前端系统进阶学习大型项目工程化
    • 前端综合文章长期沉淀的实践文
  • 工程与工具
    • Node学习指南从环境搭建到服务端
    • NPM工作流script、依赖与发布
    • Docker容器化部署上手
    • Canvas图形与动画实战
  • 路线与导图
    • 思维导图知识点全景图
    • 学习路线按图索骥不跑偏
  • 动态
    • 公众号动态公众号历史文章
    • 博客动态站长的技术博客
    • 开发者导航常用工具与文档站
    • AI 热点每日 AI 资讯与动向
AI 工作台
简历
旧版
AIHT
内容
精选全部 AI 动态热点榜AI 日报收藏
分类
模型行业编程产品技术观点开源
更多
Agent 接入
返回首页开发者导航
AIHT
精选 / 资讯详情
8.0
热点
AI SCORE
编程提效2026-11-06 13:10

让AI先写页面职责,再生成界面

dev.to · AI#AI编程#界面设计#需求定义
Editor brief · 编辑速览

文章建议在让AI生成布局前,先定义页面目的、决策所需信息、关键操作,以及加载、空白和错误状态。移动端适配也应保留任务必需的信息与能力,避免界面精致却无法完成业务操作。

文章思维导图
Knowledge map
拖拽缩放
AI deep read

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、下一步与恢复入口在对应状态下是否合理。
  • 检查窄屏页面时,实际寻找取消和客服入口,并确认触屏操作可用,把任务能力是否保留作为验收条件。
  • 修改涉及决策信息或操作位置时,同步更新那几行视图说明;单纯调整一句文案,则按原文建议保持流程轻量。
Original source

本文由 AI 通读原文后重新编写,观点部分为站内判断,细节以原文为准,来源 dev.to · AI,原文版权归原作者所有。

阅读原文
上一篇
用TypeScript构建可核查的数据分析智能体
下一篇
引用全对,研究 Agent 仍会被假来源攻破

资讯速览

dev.to · AI · 2026-11-06 13:10

AI 评分 8.0 / 10

相关标签

#AI编程#界面设计#需求定义

继续阅读

  • 智能体记忆应拆成三类工程问题
  • 用TypeScript构建可核查的数据分析智能体
  • 引用全对,研究 Agent 仍会被假来源攻破
  • 智能体记忆故障的诊断与治理方法
  • 让 AI 生成的账本逻辑通过证明再上 JVM