AI 写前端这件事，过去两年一直是个尴尬的存在。
你给 GPT 或 Claude 一段描述，它吐出一堆 HTML + Tailwind，跑起来看着还行，但组件之间没有状态同步、没有无障碍访问、没有响应式断点的精细控制。你能用，但不敢放到生产环境。
thesysdev/openui 想解决的不是"AI 能不能写 UI"，而是"AI 写 UI 应该用什么格式"。
问题不在生成能力，在输出格式
现在所有 AI 编码工具生成 UI 的方式本质上都是文本到文本的翻译：prompt → HTML/JSX → 渲染。这个链路有三个结构性缺陷：
第一，不可验证。AI 输出的是一段代码字符串，你只能跑起来看对不对。没有中间表示可以做静态检查、做 diff、做回滚。
第二，不可组合。A 工具生成的按钮和 B 工具生成的表单放在一起，样式冲突是常态。因为没有一个共享的 UI 描述层。
第三，不可迭代。你告诉 AI"把蓝色改成红色"，它重新生成整个组件。增量更新？不存在的。
OpenUI 的思路是把 UI 描述从代码字符串抽离出来，定义一个结构化的、机器可读的中间层。类似 JSON Schema 之于 API 文档，OpenUI 想成为生成式 UI 的协议层。
它长什么样
从仓库看，OpenUI 的核心是一个声明式的 UI 描述格式，用类似 AST 的树结构表示组件、属性、事件和样式约束。AI 模型不需要直接输出 JSX 或 HTML，而是输出 OpenUI 格式的描述，然后由渲染引擎转换为目标平台的具体实现。
这个项目目前还处于早期（4,523 stars，309 forks），README 里的 demo 还比较简单。但它解决的问题是对的——AI 编程工具已经从"能不能写代码"进入了"怎么写可维护的代码"的阶段，UI 层是这个链条上最后一块没有标准化的区域。
谁会关心
如果你在用 Cursor、Claude Code 或 Copilot 写前端，这个方向值得跟。不是因为你现在就能用它，而是因为一旦有头部编码工具采纳了类似标准，你的 prompt 工作流会从"描述 + 试错"变成"描述 → 结构化输出 → 自动渲染"。
前端工程师的角色也会跟着变：不再是手写组件，而是定义 OpenUI 描述层的约束规则，让 AI 在规则范围内生成。有点像从 CSS 手写转到 Tailwind 再转到 CSS-in-JS 的那波迁移，只是这次的推手是 AI。
隐患
项目还在 v0 阶段，协议没稳定，社区不大。最大的风险是——如果 OpenAI 或 Anthropic 自己搞一套封闭的生成式 UI 格式，开放标准可能直接被绕过。历史上这种"标准 vs 平台"的博弈，平台赢的次数更多。
但至少在 v0 阶段，方向是对的。
怎么上手
git clone https://github.com/thesysdev/openui.git
cd openui
# 查看示例和文档
仓库里有基本的 CLI 工具和渲染示例。别指望能立刻用到生产环境，但如果你在做 AI 编码相关的工具链，看看它的协议设计会有启发。
主要来源：