前端在Codex里不同阶段使用不同技能

image

今天我们来聊聊一个很多前端都正在遇到，但又不太愿意直说的问题：

为什么 AI 明明把代码改得很快，项目却没有因此更轻松，反而更容易返工？

很多人第一次用 Codex、Cursor、Claude Code 这类工具，体验都很上头。

你提一句需求：

“帮我做一个用户管理页，带搜索、新增、编辑、删除。”

几分钟后，页面出来了。

按钮有了。

表格有了。

弹窗也有了。

看起来效率直接起飞。

但真正把代码接进项目，问题才刚开始。

样式不统一。

组件边界很乱。

useEffect 到处飞。

类型表面能过，细看全是隐患。

移动端没测。

交互状态不全。

再过两天，连你自己都不想改这段代码。

所以问题并不在于 AI 会不会写。

问题在于，很多人把 AI 当成“一个万能前端”，直接扔进项目里硬干。

这套用法，短期很爽，长期基本都会返工。

真正的问题，不是 Prompt 不够长

现在不少前端还在纠结一件事：

是不是我 Prompt 写得不够详细？

是不是我把需求写成 300 字，AI 就能一次性给我正确答案？

其实大多数时候，不是这回事。

因为真实项目从来不是“把页面写出来”这么简单。

你还要考虑：

• 页面结构是不是专业

• 组件能不能复用

• 主题是否统一

• 状态边界清不清楚

• 类型是否可靠

• 性能有没有坑

• 移动端会不会出问题

• 上线前有没有审查过

这些事，不是一个超长 Prompt 能兜住的。

你让 AI 一口气把所有事都做完，它大概率会先把“看得见的部分”快速堆出来。

但真正影响维护成本的，恰恰是后面那些看不见的东西。

所以前端用 AI，核心不是继续打磨一条更长的指令。

而是先把工作流搭起来。

前端最该补的，不是提示词，而是 Skill 分工

你可以把 AI 理解成一个执行速度非常快，但默认不会主动收边界的助手。

它擅长往前冲。

但不擅长自己踩刹车。

这时候最有效的方法，不是要求它“既懂设计、又懂结构、又懂性能、又懂审查、还要懂 AI 接口”。

而是给它分工。

说白了，就是把一个全能型请求，拆成多个明确岗位。

哪个阶段做页面。

哪个阶段控组件。

哪个阶段查性能。

哪个阶段做 Review。

哪个阶段看体验。

当你开始用 Skill 做分工，AI 才会从“随手生成代码”，变成“按前端流程推进任务”。

这两者差别非常大。

前者追求的是快。

后者追求的是可持续地快。

一套更实用的 8 Skill 思路

如果你现在正准备给 Codex 配一套前端工作台，可以先按下面这 8 个方向来理解。

我这里说的是“岗位分工”，不是让你一次性把所有 Skill 全开。

做页面结构：frontend-design

直接在Skills上搜进行

这个位置解决的不是“能不能画出页面”，而是页面有没有产品感。

很多 AI 生成页面的问题，不在于功能缺失，而在于一眼看上去就很临时。

信息层级不对。

主次不清。

留白混乱。

列表区、筛选区、详情区像是拼起来的。

这种情况下，先让负责页面结构和视觉层级的 Skill 介入，往往比你立刻写业务代码更有效。

接基础组件：shadcn-ui

做后台、工具台、配置页时，真正消耗时间的，常常不是“写一个按钮”，而是把表格、弹窗、Tabs、下拉菜单、分页、Toast 这些基础能力稳定接进现有项目。

如果这个环节没收住，后面页面越多，UI 越容易散。

所以需要一个明确负责组件接入和一致性的 Skill。

收主题系统：tailwind-theme-builder

很多项目一开始图方便，颜色直接写，类名直接堆。

短期没感觉。

等你要切暗黑模式、统一品牌色、做多套主题时，就知道之前欠了多少债。

所以主题、颜色变量、样式基线，越早收口越省事。

这个位置本质上是在防“样式债务”。

控组件结构：vercel-composition-patterns

AI 写组件有一个非常典型的问题：

一开始看着挺完整，越改越胖。

最后一个组件塞满各种布尔开关：

showSearch、showFilter、enableExport、enableInlineEdit、isAdmin……

这种代码不是不能跑。

而是之后每次改动，心里都发毛。

所以你需要一个专门负责“拆组件、降复杂度、还原组合式结构”的角色。

它的作用不是生成新页面，而是避免页面越做越难维护。

查 React 实现质量：vercel-react-best-practices

很多返工，不是视觉返工，而是实现返工。

比如：

• 数据获取位置不合理

• 客户端状态放太多

• useEffect 滥用

• 组件边界切错

• 不必要的重新渲染

• 包体积悄悄膨胀

这些问题，页面上线当天未必炸。

但只要这个页面继续迭代，它迟早会回来找你。

所以这个 Skill 更像“技术体检员”。

它帮你在还能收拾的时候，把结构问题提前拦下来。

做代码审查：typescript-react-reviewer

这是我最建议一定要配的一个位置。

因为 AI 写完代码之后，最危险的一件事，就是你觉得“反正它都生成好了，我先合进去再说”。

别这么干。

AI 写完，不代表代码就真的稳。

你需要一个只负责挑问题、不负责夸奖的审查角色。

它要盯的，是这些东西：

• 类型是不是只是“表面通过”

• 状态流有没有隐藏风险

• 组件职责是否混乱

• 边界条件有没有漏

• 后续维护成本会不会过高

前端最怕的不是今天多改十分钟。

前端最怕的是两周后回来看，发现这段代码谁都不敢动。

做体验兜底：web-design-guidelines

很多页面从设计稿看没问题，从开发机看也没问题。

一到真实使用场景，问题全出来了。

字太长溢出了。

空状态没有。

按钮反馈不明显。

移动端布局挤了。

表单报错不清楚。

这类问题很少在“功能开发”阶段被主动处理，因为大家都忙着先跑通。

所以你需要一个专门做体验检查和 UI 审视的环节。

它的价值在于：上线之前，帮你补齐那些最容易影响观感和使用感的细节。

查 AI 接入方案：openai-docs

只要页面里涉及 AI 对话、流式输出、文件上传、工具调用、模型选择这些能力，就不要凭印象接。

因为这一块变化快，接口、参数、模型名、SDK 用法都有可能更新。

这种场景下，最稳的办法不是“凭经验写”，而是让查官方资料的 Skill 先介入。

前端接 AI 最大的问题，从来不是代码量大。

而是一开始就接错了。

这 8 个 Skill，不是一起用，而是按任务组合

很多人看到这里，会下意识再问一句：

那我是不是每次都把 8 个 Skill 一起开起来？

不用。

真正高效的方式，是按任务组合。

比如你今天是做一个新页面，可以这样排：

frontend-design -> shadcn-ui -> tailwind-theme-builder

如果你今天是在重构一个老组件，可以这样排：

vercel-composition-patterns -> typescript-react-reviewer

如果你今天准备上线一个页面，可以这样排：

vercel-react-best-practices -> web-design-guidelines -> typescript-react-reviewer

如果你今天要接 AI 功能，可以这样排：

openai-docs -> vercel-react-best-practices -> typescript-react-reviewer

你会发现，关键根本不是“Skill 越多越好”。

关键是，哪一步该让谁上。

这才是 AI 真正进入工程流程的方式。

如果你现在只想先配 3 个

那我建议先别贪多。

先把这 3 个放进去：

• frontend-design

• typescript-react-reviewer

• web-design-guidelines

原因很简单。

前端用 AI 最常见的返工，基本都逃不过三类：

• 页面看起来不专业

• 代码结构不稳

• 体验细节不完整

这 3 个位置，刚好对应这三个问题。

先把它们补齐，你对 AI 产出质量的感受会明显不一样。

最后说句更直接的话

很多前端现在并不是不会用 AI。

而是用法太粗暴。

一上来就让 Codex 直接改项目，确实快。

但那种快，往往只是把问题更快地写进代码库里。

真正成熟的用法，不是让 AI 一口气替你做完整个前端。

而是把它放进你的流程里，让它在合适的位置做合适的事。

Prompt，解决的是“你想让它干什么”。

Skill，解决的是“这一步应该怎么干”。

工作流，解决的是“它什么时候干、干到什么程度、谁来兜底”。

当你把这三层理顺之后，AI 才不是一个只会快速产出代码的工具。

它会开始变成一个真正能参与前端协作的助手。

而这，才是前端团队把 AI 用顺手的分水岭。