用 Coding Agent 做好产品设计：HTML 设计稿、设计系统与减法
整理自一篇「如何用 Agent 做好产品设计」的经验文（作者称纯人工写作）。文末补了我对 HTML 设计稿是否适用于 iOS 的判断。
核心观点
用 Coding Agent 做产品设计，别迷信「一段 Prompt 出炫酷界面」。真正管用的是一套老派但可执行的纪律：
知道什么是好设计 → HTML 当设计稿 → 组件库起步 → 设计系统当宪法 → 大胆减法 → 隔离文件里多方案对比 → 耐心打磨。
对 iOS 原生，HTML demo 到真机往往不平滑——除非一开始就用模拟器/真机渲染。
先搞清楚什么是好的产品设计
听着像废话，但这是最核心的问题。方向错了，再怎么努力都是浪费。
举例：Claude 标志性的暖色背景 + 衬线字体，去年还可以称好看，现在已经常被当成「没认真打磨 UI」的典型；GPT 喜欢用的绿色表单风也类似。
解决办法只有一条：多看真正的好东西，尽量找到信息源头，少吃二手审美。
好看是手段，不一定是目的
设计不是艺术创作。核心是解决问题、满足需求、达成目标。好看既不是充分条件，也不是必要条件。
假设你要做一个网页版 IP 质量检测工具，用户要的是打开之后能快速看到分析结果。你为了好看堆高光、阴影、材质、three.js 模型，网页被拖慢、体验被干扰——这就是设计方案与需求脱节。
用 HTML 文件当设计稿
对设计要求极高时，仍然可以用 Figma、Paper 一类专业工具。但在绝大多数情况下，HTML 已经是更好的选择——无论前端项目还是不少原生项目的前期探索。
HTML 对 Agent 的友好程度可能仅次于 Markdown：改样式、改交互都方便，还能被各种 Agent 客户端内置的浏览器打开、批注、截图。想做什么就做什么。
补充：这对 iOS 也适用吗？
我的判断是：部分适用，但不能当默认中间桥。
HTML 很适合快速探索信息架构、流程、文案和大致布局——Agent 改得动、比得了。但从 HTML demo 落地 iOS，材质、导航范式、手势、安全区、字体渲染、系统控件语义都不同，中间往往断层很大。
更平滑的路径通常是：一开始就用真机或模拟器渲染效果，把 HTML 留作低保真探索；高保真与验收以 SwiftUI / UIKit 预览或真机为准，别指望「HTML 一次翻译成原生」。
用组件库，不要什么都从零开始
引入合适的组件库能节省大量时间和成本。按个人偏好和项目完成度选即可，常见的有 Shadcn UI、Hero UI、Base UI 等。
创建设计系统：Agent 的宪法
这是全文最核心的技巧。
设计系统的目的，是给 Agent 处理页面设计时立一部宪法：色彩、字体、排版、间距、阴影、组件、布局、交互、文案风格——全部定清楚，收归到一个统一的 HTML 文件或文件夹。
项目开始前做好设计系统，能大量节省调整琐碎细节的时间。每做完新模块，习惯性问一句：是否符合当前设计系统？
这和 Stitch / DESIGN.md 一路是同构的：一致性靠规范文件，不靠模型「记得上次用了什么色」。
多做减法
目前的模型普遍有添加大量细节的倾向。要大胆删除那些不必要的东西。
完成一轮调整后，还可以让 Agent 提取这些决策体现出来的设计原则，并补充回设计系统——规范会越用越准。
在有限范围内多做对比
某个模块设计拿不准时，可以让 Agent 多做几个方案来对比，但一定要在单独的 HTML 文件里进行，不要直接修改项目代码。
不要迷信 One Shot
不要迷信社交网络上各种一段 Prompt 就搞定的炫酷案例。准备工作做得越好、想得越清楚，项目推进就越快。至于是一轮搞定、两轮搞定还是十轮搞定，并不重要。
耐心打磨，才是常态。
可带走的清单
| 原则 | 做法 |
|---|---|
| 审美 | 看真好产品，少二手 |
| 目标 | 解决问题优先，好看是手段 |
| 载体 | Web 用 HTML；iOS 用 HTML 探索 + 真机验收 |
| 起步 | 组件库 |
| 宪法 | 设计系统文件，模块后自检 |
| 迭代 | 减法，并把原则回写系统 |
| 探索 | 隔离 HTML 多方案对比 |
| 节奏 | 不迷信 one-shot |
Agent 能加速改稿，但不能替你判断「什么才是好设计」。那部分，仍然得你自己练出来。
评论