让 Codex 写一个前端页面，直接说"写个 xx 页面"，它通常从空白开始。空白意味着技术栈要自己选，组件库要自己定，路径别名要自己配，然后从第一行组件写起。

这样写的后果我见过太多次。每个页面各写一套结构，状态管理想到哪写到哪，样式类名随手造，交付时看起来能用，一接手就发现是一堆没有骨架的散件。

所以我一直主张，前端任务要让 Codex 先有骨架再动手。这个想法在 GitHub 上有一个现成的 skill 帮我落地，叫 web-artifacts-builder。

我在哪找到的这个 skill

它在 Anthropic 的官方仓库里，路径是 github.com/anthropics/skills，Apache 2.0 许可，仓库的 skills 目录下还有很多别的例子。我拉了一份 SKILL.md 核对，确认它确实是前端构建方向，才考虑接进工作流。

这个 skill 的定位很清楚，给 claude.ai 生成复杂 Web artifact 用的，但它的结构方式对 Codex 写前端同样有价值。

skill 替 Codex 把骨架先立起来

web-artifacts-builder 定义的技术栈是 React 18、TypeScript、Vite、Tailwind CSS 3.4.1，外加 shadcn/ui。它的流程不是让你从零写，而是走五步。

第一步，跑初始化脚本。bash scripts/init-artifact.sh <项目名>，脚本会生成一个完整配置好的项目，包括路径别名、40 多个 shadcn/ui 组件、Radix 依赖，Node 18 以上会自动适配 Vite 版本。

第二步，在生成的项目里改代码。这一步才是写业务。

第三步，打包。bash scripts/bundle-artifact.sh 把所有代码、样式、依赖内联成一个 bundle.html 单文件。

第四步，把单文件交付展示。第五步，可选测试。

我关注的是前两步。对 Codex 来说，这个 skill 的价值在于把"要不要用组件库、要不要配别名、要不要搭工程"这些决定全替你做了。

我怎样让 Codex 用这个 skill

接进 Codex 不需要装什么插件，把 skill 目录放进项目，然后让 Codex 先读 SKILL.md 再执行。

我给的任务会这样写。

按 web-artifacts-builder 的 SKILL.md 执行。
先运行 scripts/init-artifact.sh 初始化项目骨架。
骨架生成后，在已有结构里完成页面开发，不要自己新建一套技术栈或组件体系。
开发完成运行 scripts/bundle-artifact.sh 打包成单文件。
改动期间不要随意更换已配置的 Tailwind 和 shadcn/ui 约定。

这条任务把 Codex 的发挥空间压到了业务代码上。技术栈、工程配置、组件库这些最容易跑偏的地方，都由 skill 的脚本先固定。

还有一条来自 SKILL.md 的约束很值得单独说。

AI 风格噪音它专门做了提醒

web-artifacts-builder 的文档里有一句明确的警告，避免所谓 AI 生成的味道。过度居中的布局、紫色渐变、清一色的圆角、满屏 Inter 字体，这些特征容易让页面一眼看出是模板产物。

它把这条写进设计规范，说明官方自己也意识到，AI 生成的前端最容易倒在视觉同质化上。

我把这条翻译给 Codex 时不会只贴原句。我会在任务里加一个验收项，页面布局是否只有一种居中模式，配色是否依赖渐变堆叠，字体和圆角是不是全靠一个模板。

这样写，Codex 完成的不只是功能，还有一个不像批量产物的界面。

适用边界要说清楚

这个 skill 不是万能的。

它绑定了 React 技术栈，Vue 项目、UniApp 项目用不上。它面向从零生成一个完整页面的场景，对既有工程里的增量改动没什么帮助。脚本依赖 Parcel 打包，如果项目已经有自己的构建链，bundle 这一步就不该用。

我判断用不用它，只看一个问题，这次任务是不是要从零立一个独立的前端交付物。是，就接骨架再写。不是，就按项目现有工程走，skill 反而添乱。

GitHub 上的 skill 很多，选的时候我会先看仓库归属和许可，再看 SKILL.md 里有没有真实的脚本和规则，而不是只看名字。这也是我判断一个开源 skill 值不值得让 Codex 加载的底线。

下一篇换一个功能相反的 skill。生成类 skill 管把代码写出来，调试类 skill 管把代码修对。我会从 GitHub 的 superpowers 仓库拉一个叫 systematic-debugging 的方法论 skill，看它怎么约束 Codex 修前端 bug 时先找根因再动手。

本系列持续更新。每次从 GitHub 找 skill，我都先问它补的是哪一段前端流程，再决定要不要接进