本文约1188字，阅读约3～4分钟，工具包在文末

如果你最近在研究GenUI，你肯定遇到过这些情况：

问题的根源不是AI不够聪明，是你没给它一个”思维框架”，或者是给的结构不完整，缺失的都是 AI 在延展和脑补。

为什么要这么做？

光靠”帮我生成一个交易仪表盘”这种prompt，本质是玄学。你不给它结构化约束，它能给你生成出花来——赛博朋克、极简北欧、上古Web2.0，什么风格都有，就是没有你想要的那个。

对于生产级别的需求和项目来说，这种长文本的提示词，在使用的便利性、性能、性价比都是极低的。需要更加体系化规范化的框架来规范。

因此，引入UI Spec的本质，不是给AI一份”设计稿”，而是给它一套”思考和生成规则”。

当我们说”让AI帮你生成UI”时，到底在说什么？

是在说”你给我画一个界面”？还是在说”你帮我把一个页面需求，转化为可执行的技术实现”？

大多数人对AI的期待是前者，而Harness想解决的是后者。

这个思维框架的来源，是我尝试把最近研究比较多的内容的优势全部融合在一起：

AI UI 工作流 × AHE 论文 × Superpowers  × SDD —— 形成一个统一的、可执行的 UI 开发规范体系，让生成 UI 高可用。

一、框架映射：AI UI 工作流 × SDD 方法论

这里的六阶段不是线性流程，而是迭代闭环。每个阶段产出是下一阶段的输入，同时接受上游的约束。

二、规格定义：Define Spec

2.1 规格的本质

规格不是”描述”，是”契约”。

一份UI Spec应该回答：

这个页面服务谁？（目标用户）

解决什么问题？（核心目标）

如何验收？（验收标准）

2.2 规格格式

以下内容，均围绕交易仪表盘为例

三、组件规范：Design Spec

3.1 组件化描述原则

把复杂界面拆解为可独立理解的最小单元。

每个组件必须定义：

名称与ID

类型（Card/Table/Form/Modal…）

优先级（High/Medium/Low）

状态（Normal/Loading/Empty/Error）

数据字段

交互行为

当然，还有最基础的形色字质构动，都需要 token 化。

3.2 四状态模式

四、视觉探索：Visual Prototype

4.1 Prompt约束结构

4.2 验收检查清单

信息层级：第一眼能看到核心信息

模块关系：相关模块相互靠近

视觉密度：不空旷也不拥挤

可组件化：每个模块可拆分为独立组件

五、代码生成：Execute Tasks

六、修正闭环：Verification

6.1 修正循环机制

6.2 修正控制原则

七、交付沉淀：Iterate & Archive

7.1 沉淀资产清单

7.2 模板复用机制

好的工作流应该产生可复用的模板。

页面类型 → 提取为模板：

Dashboard模板

List模板

Form模板

Detail模板

组件类型 → 提取为模板：

Alert Card模板

Data Table模板

Modal模板

八、方法论总结

结语

写UI Spec的本质，是把人类的审美判断，转化为AI可以理解的结构化约束。

不是限制AI的创造力，而是让创造力在可控范围内发挥。

当规格定义清楚，执行就会稳定。

当迭代收敛可控，交付就会可期。

以上Harness，已整理成 Ryan GenUI Harness 并开源至 GitHub：

https://github.com/RyanCheng77/ryan-genui-harness.git

也可通过 SSH 安装：

git@github.com:RyanCheng77/ryan-genui-harness.git

欢迎试用、反馈，欢迎提交 Issue 和 Pull Request！

整合探索不易，欢迎点赞转发！❤️

我是努力学 AI 的阿睿，欢迎关注一同探索进步。