用 AI 写界面的人，多半都撞过同一堵墙：同一个项目里，第一屏是克制的深灰卡片，第三屏就变成了紫色渐变按钮；换个会话重新开一次，字号和间距又重来一遍。你越是指望模型「照着已有的感觉来」，它越是每到新页面就重新发明一套样式。
StyleSeed 想解决的正是这件事。它不给你模板，而是让你先把「这个项目认定什么算好设计」定下来，再把这套决定编译成一份规则文件，让 AI 在动每一屏之前先读它、做完之后再用脚本核一遍。它的自我定位写得很克制：辅助专家判断，而不是用一堆口味替代专家。
这个姿态值得认真测一次。我在一台 Linux 沙箱里把它完整跑了一遍：克隆仓库、跑自带的全部测试、用它自己的检查器扫它自己的演示站、再在空白项目里试着编译一份规则包。结论有点意外——它自己的测试几乎无可挑剔，但它自己的成品过不了它自己的闸门。
它到底做了什么
一句话：它是个设计方法引擎，不是组件库。仓库里同时放了三层东西。
最上面是技能层：一个登记的入口技能，加上 22 个工作流。每个工作流是一份给 AI 看的作业规范，比如「搭页面」「审可访问性」「打分」「改间距」各自一份。它们不是 22 个独立技能，而是同一个技能内部分岔的 22 条路线，所以你在 Claude Code 里只要说 /styleseed build，在 Codex 里说 $styleseed build，不必记住 22 个名字。
中间是方法层：一套写死的设计语言与手艺规范。它把「什么时候该用哪种版式、为什么」拆成一条条判据，成体系地覆盖色彩、数字与货币展示、文字层级、卡片内部结构、阴影、分区、图表样式，并且专门有一节列出绝对禁止项。
最下面是编译器：真正干活的那部分。它读你的项目配置，挑出这次任务真正需要的规则，压成一个规则包，落在项目的隐藏目录里。README 里的说法是「不必每个任务都背着 220KB 的全本手册」。
这一步是整个项目里最有价值的想法。模型失忆的根因不是上下文不够长，而是它每次都读到一大堆与当前任务无关的规范，重要的那几条被稀释掉了。把规则按任务裁一遍，等于帮它把注意力收窄。
| 层 | 内容 | 可执行性 |
|---|---|---|
| 技能层 | 1 个入口 + 22 个工作流 | 22 个工作流里 7 个带脚本 |
| 方法层 | 设计语言与手艺规范 | 纯文档 |
| 编译器 | 按任务裁剪规则包 | 有脚本，有版本与哈希 |
实测：测试全绿，成品被自己判错
第一件事，跑它自带的测试。仓库里有 25 个测试文件，用 Node 自带测试器跑完，共 195 个用例，全过，没有任何跳过。这一项可以算干净。
第二件事，用它自己的确定性检查器扫它自己的演示站。这个检查器是它产品的一部分：查硬编码颜色、查写死的像素值、查被关掉却没人替代的焦点框、查没有无障碍标签的纯图标按钮。
在它自己的仓库根目录跑，退出码是 2，也就是它自己认定不合格。五个配置合计 119 条发现，其中 5 条是错误级，114 条是警告级。
最要命的是那 5 条错误级。五条是同一个原因：仓库里每个演示配置都记着「我这份规则包长什么样、多大、哈希是多少」，但用当前引擎重编译一遍，对不上。换句话说，规则包是旧版引擎编的，引擎后来改过，规则包没跟着重编译。我另外用它自带的另一条核对命令验证过一次，五个配置全部直接报引擎版本号不一致。
这说明一件具体的事：它把「产物与来源必须对得上」做成了硬闸门，而它自己的演示站恰好卡在这道闸门上。这道闸门本身是对的设计——规则包一旦悄悄过期，后面所有基于它打的分都不作数。但一个把可复核当卖点的项目，仓库里挂着五个自己的错误级告警，观感上很难圆。我只能确认这部分没重编译，作者是没发现还是有意留作演示，无从判断。
114 条警告的分布也值得一提。硬编码颜色 102 条，任意像素值 11 条，关闭焦点框 1 条。命中最集中的单个文件是演示站的对比页，42 条。那个页面恰恰是它用来展示「有规则与没规则的差别」的地方。
22 个工作流，只有 7 个能自己动手
README 反复强调「一个技能，22 个工作流」，这句话是真的，我逐个数过：22 个目录，每个都有一份作业规范，主入口文档引用了全部 22 个，没有一个悬空，也没有一个漏引。48 个组件也是真的，32 个界面组件加 16 个组合件，跟声明一致。
但「工作流」这个词容易被理解成「22 个能自动跑的功能」。实际拆开看，带可执行脚本的只有 7 个，另外 15 个是纯文档。
这不算欺骗，它自己也在文档里写了这套东西是给 AI 读的作业规范，不是 22 条命令。但读者该知道自己买到的是什么：22 份写得很细的施工说明，加 7 个真能干活的脚本。真正的自动化集中在编译、打分、核对、间距测量这几件事上。
我用空白项目试了一次编译。什么都不传，它直接报错要求你指定输出风格，不会替你猜。把风格、载体、领域、页面类型四件事都指定之后，它编出一份 21,885 字节的规则包，比全本手册小一个数量级。
这个设计取舍我认为是对的：设计方向是人的决定，它只负责把决定变成可执行的约束。
和同类比，它适合谁
跟组件库不是一类东西。界面组件库给你一堆现成零件，你挑着装；它给你一套判断标准和检核手段，零件是附带的。
跟通用 AI 生成界面也不是一类。通用生成每次都在重新猜；它的价值在于把「猜」换成「读一份你已经批准过的决定」。
适合两类人。一类是自己有一套审美、但带不动 AI 的人：你已经知道要什么，缺的是让模型每次都记住。另一类是几个人共用一个前端仓库的团队，需要把「我们的设计共识」写成文件而不是靠口头传。
不适合两类人。一类是还没有设计判断、指望工具替他决定的人：它会有耐心地问你四个问题，然后按你的回答执行，你的回答含糊，产物就含糊。另一类是只想快速出一屏原型的人：编译、打分、核对这套流程是给「要长期维护的界面」准备的，一次性草稿用不上。
几个值得写在明处的局限。它的组件脚手架目前只面向 React 加 Tailwind 这一套技术栈，换栈只能借它的方法，借不到零件。打分只读代码与截图，读不出「这个信息层级对业务是否合理」。它反复强调分数不等于人的验收，这句话不是免责，是事实。
判断
值得放进观察清单，尤其值得抄它的思路。
它做对的那件事很简单：把设计决定写成文件、编译成小包、再用脚本核对产物。这三步里没有一步是新的，串起来才是它的贡献。而它自己演示站上那 5 条错误级告警，恰好反证了这套机制真的会咬人：一个连自己都不放过的闸门，比一个永远亮绿灯的闸门可信。
如果要试，建议先从一个小页面开始，把风格和领域这两项定清楚，看它编出来的规则包是不是你真的认同。认同了再扩大，不认同就说明你需要先自己想清楚，而不是换工具。
关注 AI商业快讯，每天一篇 AI 热点深度解读。
相关阅读：