别再让 AI 把前端做成一次性原型：我为什么做 floop
太长不读：
AI 写前端很快，但它经常把你的设计系统写散。
第一版像魔法，第五版像事故现场。
所以我做了 floop：一个开源、local-first 的质量回路，让 AI 在生成 UI 前先理解 token 和组件，在生成后被规则反向检查。
前端 AI 开发最爽的地方，也是最危险的地方¶
过去我写一个后台页面，脑子里会自动跑一遍流程：
这个按钮用哪个组件？主色是不是该走 token？表单错误态有没有复用已有模式？这个列表为空时展示什么？
有了 AI agent 以后，这些事突然变快了。
你说一句：
帮我做一个订单管理页，左边筛选，右边表格，支持批量操作。
十几秒后，它真的给你一个页面。看起来还不错。甚至有阴影、有圆角、有 hover、有 loading。
第一天你会很兴奋。
第二天你会继续让它加功能。
第三天它开始自己发明新的蓝色。
第四天它把已有的 Button 组件绕过去，手写了一个 <button class="px-4 py-2 ...">。
第五天你打开代码，发现你的项目里同时存在三套间距、四种卡片、五种按钮写法，以及一堆没人敢删的 inline style。
AI 没有恶意。它只是太擅长“往前生成”了。
问题是，工程不是一直往前堆。
工程还需要往回看：看已有约束，看组件边界，看设计系统，看团队约定。
这就是 floop 想补上的地方。
为什么 prompt 不够？¶
你当然可以在 prompt 里写：
请严格遵守我们的设计系统，不要写 hardcoded color，不要重复造组件。
有用吗？
有一点。
但不稳定。
因为 prompt 是建议，不是约束。AI 生成到兴头上时，很容易为了完成当前页面，把“复用组件”这件事当成次要目标。
尤其当你连续迭代时，上下文里充满了临时需求：
- 把按钮挪右边
- 加一个高级筛选
- 表格支持 sticky header
- 这个弹窗改成两步
- 先别管样式，跑通再说
这些小改动堆起来，AI 会逐渐忘记最开始那套规则。
你以为你在做产品迭代。
实际上你在喂养一个越来越难维护的临时原型。
我把它叫做“一次性原型陷阱”。
floop 的想法：给 AI 加一个质量回路¶
floop 不是另一个 UI 生成器。
它更像一个夹在 AI agent 和代码库之间的质量回路。
核心思路很简单：
生成前，先让规则显性化。
生成后，再用规则反向检查。
在 floop 里，AI 不应该直接冲进页面写 HTML。它要先理解项目里的设计 token 和组件结构，例如：
- 哪些颜色、间距、圆角、字号是允许的
- 哪些组件已经存在
- 哪些场景应该复用
Button、Card、Dialog、Table - 哪些写法属于违规，比如裸写颜色值、绕过组件库、重复造 wheel
然后 floop 用 CLI 做校验。
如果 agent 写了一个硬编码的 #333，而项目要求用 var(--text-primary)，检查应该失败。
如果 agent 在已有按钮组件的场景里手写原生 <button>，检查也应该失败。
失败不是坏事。
失败是回路的一部分。
AI 看到错误，回去改，再检查，直到符合项目规则。
这才是我想要的 AI 前端开发：不是“生成一次就算完”，而是“生成、检查、修正、再检查”。
它和 Figma Make、Google Stitch 不同在哪里？¶
Figma Make 和 Google Stitch 很强。
但它们更像是在自己的生态里完成从设计到原型的生成。
我想要的是另一种东西：
一个能放进现有代码库、现有终端、现有 agent workflow 里的开源工具。
我不想把项目规则锁进某个云端黑盒。
我希望设计规则就放在仓库里，像代码一样被 review，像配置一样被版本控制。
这也是 floop 选择 local-first 的原因。
AI agent 可以换。今天 Cursor，明天 Claude Code，后天 Copilot 或 Codex。
但规则应该留在你的项目里。
你的设计系统不应该跟着工具迁移。
真正的问题不是“AI 不会写 UI”¶
AI 会写 UI。
它甚至写得太快了。
真正的问题是：AI 不天然理解“这个项目的 UI 应该怎么继续长”。
一个成熟项目里，前端代码不是孤立页面集合，而是一套不断演化的设计语言。
好的 UI 工程不只是页面好看，还包括：
- 新页面能不能继承旧页面的视觉语言
- 新组件会不会破坏已有组件边界
- 快速迭代后，样式债会不会不可控
- 多个 agent 参与开发时，规则是否仍然一致
这些东西靠人脑盯，很累。
靠 code review 兜底，也太晚。
floop 想把这件事提前。
在 AI 写出一堆“看起来能用”的代码之后，立刻问它：
你真的遵守项目规则了吗？
我希望 floop 成为什么¶
我不想把 floop 做成一个“更聪明的生成器”。
生成器已经够多了。
我更想把它做成 AI UI 工程里的刹车和护栏。
快，是 AI 的优势。
稳，应该由工程系统补上。
如果一个工具能让 agent 少发明一次颜色，少绕过一次组件库，少制造一次后期重构，那它就已经有价值。
因为真实项目里，最贵的从来不是写第一版。
最贵的是第三周还能继续改，第六周还能放心合并，第十二周新人接手时不会想重写。
这就是 floop 的出发点：
让 AI 写出的 UI，不再只是 demo，而是能进入工程生命周期的代码。
项目地址：