我怎么把 OpenAI 那套 frontend skill，用到已有项目里
不只是生成页面，而是先定义规范、约束和观测方式
参考原文：
以前我们用 AI 写前端，很多时候还是把它当成一个补零件的工具。帮我写一个页面，补一个组件，或者在已有项目里加一个 dialog。这样当然也有用，但它更多还是局部代工，不太像在做一个完整的产品前端。
看完 OpenAI 那篇文章之后，我的感觉是这件事可以再往前走一步了。AI 不只是帮你补页面、补组件，它已经可以参与定义一个产品整个前端的风格。UI 应该是什么样，交互应该遵循什么原则，工程上要有哪些约束，这些东西都可以先写成一套规范，然后让 AI 按这套规范去做。
所以这篇文章我想讲的，不是 GPT-5.4 又变强了，而是怎么把 OpenAI 那套 frontend skill 的思路，真正用到一个已经存在的前端项目里。重点也不是生成一个页面，而是先定义规范、建立约束、给出观测方式，然后让 AI 在这个基础上持续迭代。
我觉得这篇文章真正有价值的点，不是在教你怎么写一个漂亮页面，而是在讲：怎么把 AI 写前端这件事，逐步变成一个更工程化、更稳定、也更可复用的过程。
OpenAI 这篇文章到底在讲什么
我读下来，它大概讲了三层东西。
第一层是规范。一个前端项目本来就会有工程规范、UI 规范、设计原则。现在这套东西，也可以提前写给 AI。
第二层是代码层面的约束。光有 prompt 还不够，还得有 lint、CI、代码检查这些更硬的东西。因为 prompt 说到底还是软约束，真正能把质量兜住的，还是代码层面的检查机制。
第三层是观测性。规范定完了之后，怎么知道 AI 最后做出来的东西符不符合要求？这时候就要给它眼睛。比如用 Playwright 去截图、去对比、去看最终页面的效果。只有让它看得到结果，它才有机会继续迭代。
我觉得它真正讲的是一个 harness
我自己读完之后，脑子里一直想到的词其实是 harness。
你不能只跟 AI 说一句，你给我做一个什么风格的前端，然后就期待它每次都稳定输出。更有效的方式是，先给它规范，再给它检查工具，最后给它可观测性。这样它就不是在盲写，而是在一个有约束、有反馈、也有结果校验的环境里工作。
这个点我觉得前端和后端其实是一样的，本质上都是让 AI 可观测、可约束、可迭代。只不过前端多了视觉结果这一层，所以截图、对比、回看页面表现会更重要一点。
另外 OpenAI 在文里提到一个我也比较认同的点，就是 reasoning 不用拉太高。用 low 或者 medium 往往就够了。太高有时候会过度思考，反而把事情搞复杂。
我自己的做法
看到这里，我的第一反应其实很直接：我们肯定没必要自己一段一段去读文章，然后再手动把文章里的方法抄到项目里。
既然我们手上已经有 AI 了，那更合理的做法就是让 AI 自己去读这篇文章，自己提炼出里面的方法，然后把这些方法沉淀成一个可以复用的 skill。以后不管你拿到哪个已有前端项目，都可以先让它跑这套 skill，再去做具体改造。
所以我后来就是按这个思路去做的。我已经把这个 skill 写出来了，上面那个 frontend-skill 的链接就是。它的作用，不是替你直接生成某个页面，而是引导 AI 把 OpenAI 文章里讲的那些原则一步一步落下来。先识别现有项目，理解当前代码结构，再抽取设计方向，定义前端原则，最后再去改代码。
我自己比较喜欢 OpenAI 官网那几套设计风格，所以我当时就直接让这个 skill 去分析 OpenAI 官网的设计语言，看看它的风格到底是什么，它背后的原则是什么。然后先产出一个原则文件，再把这套原则应用到我自己已经有的项目里。
这样做的好处是，你不是在直接让 AI 模仿某个页面，而是在让它先抽象风格原则，再把原则应用到具体项目里。最后出来的结果就不会只是像，而是更接近一种有依据的统一风格。
最后一句
所以对我来说，这篇文章最重要的启发不是 GPT-5.4 会写更好看的前端，而是我们终于可以把 AI 写前端这件事，从零散地补页面，推进到定义规范、建立约束、给出观测、然后持续迭代的层面。一个 skill 也就不只是给一个项目用，而是可以慢慢变成多个项目都能复用的一套前端工作方式。
