---

先说人话：这是个什么东西？

AI 编程工具越来越多，Claude Code、Codex、Cursor、Windsurf、Gemini CLI、Copilot、OpenClaw……一个个看起来都很能打。

但实际用起来，很多前端同学大概都经历过这种场面：

你说：“帮我写个 React 组件，注意类型、样式、可访问性和异常状态。”

AI 点点头：“收到。”

然后它交出来一个组件：

• any 用得像不要钱；
• loading、empty、error 状态集体失踪；
• 样式命名像临时工下班前随手敲的；
• 组件拆分全靠缘分；
• 代码能跑，但 reviewer 看了想请假。

这时候你会发现，AI 不是不会写代码，而是它缺一个“靠谱前端团队的工程约束”。

frontend-craft 做的就是这件事：

给不同 AI 编程助手装上一套统一的前端工程规范、工作流、Agent、Skill、Command 和 Hook，让 AI 不只是“会写代码”，而是尽量按团队标准写代码。

项目名称也挺直白：
frontend-craft = 前端手艺活。

AI 可以很快，但前端不能糙。

---

项目地址

GitHub 仓库：https://github.com/bovinphang/frontend-craft

---

为什么需要它？因为 AI 写前端，最大的问题不是“不会写”，而是“不稳定”

现在很多人用 AI 写代码的姿势，大概是这样：

今天用 Claude Code，让它写一个表单。
明天用 Cursor，让它改一个列表。
后天又用 Codex，让它重构一个页面。

结果项目里开始出现三种代码风格：

• 组件结构像三家装修队同时施工；
• 状态管理一会儿放组件里，一会儿塞 store，一会儿 URL 参数乱飞；
• API 层有的封装，有的裸奔；
• 校验逻辑有的用 schema，有的靠 if else 硬刚；
• UI 状态有的完整，有的只管 happy path；
• 最后 reviewer 变成了“代码考古学家”。

AI 本身没有你的团队上下文，也不知道你们项目的工程底线。
你不告诉它规则，它就只能自由发挥。

而自由发挥这件事，放在美术课上叫创作，放在前端项目里，通常叫事故现场。

---

frontend-craft 解决的不是“让 AI 更聪明”，而是“让 AI 更像团队成员”

它不是简单丢给 AI 一段“请写高质量代码”的提示词。

说实话，这类提示词我也写过：

请你作为一名资深前端架构师，使用最佳实践，输出高质量、可维护、可扩展、性能优秀、安全可靠的代码……

看起来很专业，效果嘛，有时像拜佛。

frontend-craft 更像是把前端团队长期沉淀下来的规范，拆成了可执行的工作流：

• 写 React？按 React + TypeScript 项目标准来。
• 写 Vue 3？按 Vue 3 + TypeScript + Pinia 的边界来。
• 做 Next.js / Nuxt？考虑路由、渲染、数据获取和工程结构。
• 做表单？考虑 schema、动态字段、异步校验和错误提示。
• 做接口？考虑类型、鉴权、上传、错误处理和重试。
• 做列表？考虑虚拟滚动、无限加载、性能边界。
• 做设计稿还原？接入设计工具上下文，别只靠截图猜。

简单说：

以前你是每次都要提醒 AI：“别乱写。”
现在你可以把“别乱写”做成插件。

---

它支持哪些 AI 编程工具？

frontend-craft 的定位是“一套工具，多种 AI coding assistant 复用”。

也就是说，你不是只能在某一个工具里用它，而是可以把同一套前端规范接入多个 AI 编程环境。

当前覆盖的典型工具包括：

• Claude Code
• Codex
• Cursor
• Windsurf
• OpenCode
• Kilo
• Gemini
• GitHub Copilot
• Antigravity
• Augment
• Trae
• CodeBuddy
• Cline
• OpenClaw
• Qoder

这点很实用。

因为真实团队里不太可能所有人都只用同一个 AI 工具。
有人喜欢 Claude Code，有人喜欢 Cursor，有人习惯 Codex，还有人坚持“我命由我不由工具”。

最后项目还是同一个项目。
代码风格不能因为 AI 工具不同，就写成“八国联军前端版”。

frontend-craft 的价值就在这里：
不管你用哪个 AI 助手，前端工程标准尽量保持一致。

---

它里面都有什么？

可以粗略理解成五类能力。

---

1. Agents：让专门的人干专门的事

frontend-craft 内置了一组前端专用 Agent。

你可以把它们想象成一个小型前端评审委员会：

• fec-code-reviewer：代码评审，关注架构、类型、样式、安全等；
• fec-typescript-reviewer：专门盯 TypeScript 类型安全；
• fec-security-reviewer：检查 XSS、敏感信息、危险 API；
• fec-performance-optimizer：关注包体积、渲染性能、网络瓶颈；
• fec-architect：帮你规划页面拆分、组件边界、状态流；
• fec-test-planner：按风险拆测试层级；
• fec-debugger：处理构建、运行时、UI、接口等复杂问题；
• fec-figma-implementer：从设计稿实现 UI；
• fec-ui-checker：做视觉还原和 UI 问题检查。

这就比“让一个 AI 什么都干”靠谱很多。

就像公司里你不会让后端同学顺手把品牌视觉、端到端测试、无障碍和 CSS 动画全包了。
当然，他如果真能全包，那请珍惜，他可能不是后端，是赛博诸葛亮。

---

2. Skills：自动激活的前端经验包

Agent 偏“谁来做”，Skill 偏“怎么做”。

frontend-craft 里有大量前端场景 Skill，会根据项目框架、文件类型、任务上下文自动激活。

比如：

• React + TypeScript 项目标准；
• Vue 3 + TypeScript 项目标准；
• Next.js / Nuxt 项目标准；
• Vite 配置与构建优化；
• Monorepo 工程组织；
• API 集成；
• 状态管理；
• 表单处理；
• 浏览器存储；
• 路由权限；
• PWA；
• Web Worker；
• Canvas / Three.js；
• SVG 动画；
• 列表虚拟滚动；
• 测试策略；
• 组件测试；
• E2E 测试；
• 安全审查；
• 可访问性检查；
• 性能优化；
• 依赖升级；
• 老项目现代化迁移；
• 文档同步。

这类东西看着碎，但非常贴近日常开发。

因为前端项目出问题，往往不是因为某个单点技术不会，而是这些细节到处漏一点：

• 表单少了错误态；
• 接口少了异常兜底；
• 状态边界没分清；
• 组件拆分太粗；
• 样式和设计系统断层；
• 测试只测 happy path；
• 权限路由只挡了菜单，没挡页面；
• 性能问题上线后才发现。

frontend-craft 的 Skill 更像是把这些“资深前端踩坑备忘录”提前塞给 AI。

AI 写代码可以快，但不能快到把坑也一起批量生成。

---

3. Slash Commands：把常用工作流变成命令

frontend-craft 提供了一组常用命令，比如：

/fec-init
/fec-review
/fec-scaffold
/fec-plan
/fec-tdd
/fec-debug
/fec-refactor-clean
/fec-doc-sync

这些命令不是为了看起来酷，而是把常见工作流固定下来。

举几个例子。

初始化项目规范

/fec-init

用于生成项目说明、规则、配置等基础文件。
适合新项目接入，也适合老项目补齐 AI 工作上下文。

---

做代码评审

/fec-review

让 AI 不只是说一句“代码整体不错”，而是从架构、类型、渲染、样式、可访问性等维度做结构化 review。

“整体不错”这四个字，在代码评审里杀伤力不大，迷惑性极强。
真正有用的是指出哪里可能炸、为什么会炸、怎么改。

---

生成脚手架

/fec-scaffold dashboard feature

用于按项目约定创建页面、功能、组件目录结构。

这对团队项目很有用。
否则每个人都能发明一种目录结构，最后项目目录长得像菜市场摊位图。

---

做 TDD

/fec-tdd

用于前端测试驱动开发，走 red → green → refactor 流程。

前端 TDD 不一定适合所有场景，但在复杂表单、权限逻辑、状态机、数据转换、工具函数、交互边界里，非常值得用。

---

清理死代码

/fec-refactor-clean

用于识别并安全移除未使用代码、导出、样式、路由和依赖。

这个命令适合老项目。
毕竟很多前端项目都有一个共同特点：

代码没坏，但没人敢删。
因为谁也不知道它是不是在某个神秘入口被调用。

---

4. Hooks：让 AI 不要“写完就跑”

很多时候 AI 写完代码就停了，但真实开发不是这样。

你写完代码，还要：

• 格式化；
• lint；
• type-check；
• test；
• build；
• 检查有没有危险命令；
• 确认有没有把项目搞炸。

frontend-craft 的 Hooks 就是干这个的。

它支持在 AI 会话事件里自动执行一些动作，比如：

• 会话开始时检测项目框架和包管理器；
• 执行 Bash 前拦截危险命令；
• 写入或编辑文件后自动格式化；
• 会话结束时跑 lint、type-check、test、build；
• 跨平台桌面通知。

这就相当于给 AI 安了个“下班前检查清单”。

以前 AI 写完代码：

我写完了，你测一下。

现在可以尽量变成：

我写完了，我也先帮你检查了一轮。

虽然不能保证 100% 没问题，但至少从“开盲盒”变成“带验货单开盲盒”。

---

5. 设计工具 MCP：让设计稿还原别再全靠猜

做前端的都懂，设计稿还原这件事，表面上是写 UI，实际上是翻译。

设计师说：“这里留白要轻一点。”

前端问：“轻一点是多少 px？”

设计师说：“你感受一下。”

你感受了半天，最后 PR 评论区出现一句：

这里和设计稿不太一致。

frontend-craft 接入了多种设计工具相关能力，比如 Figma、Sketch、MasterGo、Pixso、墨刀等，目标是让 AI 在做设计到代码时拿到更丰富的上下文。

这对 UI 还原、Design Token 映射、组件实现、视觉 QA 都有帮助。

---

怎么安装？

前置要求：Node.js 22+。

推荐全局安装 CLI：

npm install -g @bovinphang/frontend-craft@latest

进入你的前端项目：

cd your-project

交互式选择 AI runtime：

fec setup

也可以指定接入某个工具：

fec setup claude
fec setup codex
fec setup all

如果希望全局生效，可以加 --global：

fec setup claude --global
fec setup all --global

不想全局安装，也可以用 npx：

npx @bovinphang/frontend-craft@latest

---

一个真实一点的使用场景

假设你现在有个需求：

做一个后台管理系统的用户列表页，支持搜索、筛选、分页、批量操作、权限控制、接口异常提示和移动端适配。

不用 frontend-craft 时，你可能会这样跟 AI 说：

帮我写一个用户列表页，要求代码高质量，注意组件拆分，注意 TypeScript，注意性能，注意用户体验，注意异常处理，注意可访问性。

这段话的问题是：
你说了很多“注意”，但 AI 不一定知道“注意到什么程度”。

用了 frontend-craft，你可以把任务拆得更工程化：

请先规划用户列表页的组件边界、数据流、状态归属、API 类型、权限控制、异常状态和测试策略。

然后再执行：

/fec-plan
/fec-scaffold user-management feature
/fec-review

如果是复杂交互，再配合：

/fec-tdd
/fec-debug

最终效果不是“AI 突然成神”，而是：

• 它更容易按项目规范思考；
• 它更容易输出结构化报告；
• 它更容易覆盖容易遗漏的工程细节；
• 它更容易从“生成代码”进入“完成任务”的状态。

这才是 AI 编程在团队项目里真正有价值的地方。

---

它适合谁？

我觉得 frontend-craft 特别适合这几类人。

1. 经常用 AI 写前端的个人开发者

你可能不缺 AI 工具，但缺一套稳定的前端工作流。

今天让 AI 写 React，明天让 AI 改 Vue，后天让 AI 重构老 jQuery 页面。
没有规范兜底，很容易写着写着项目就变成“AI 作品展”。

frontend-craft 可以帮你把常用规范沉淀下来。

---

2. 有多个前端项目的团队

团队最大的问题不是“某个人写得不好”，而是“每个人理解不一样”。

同样一个 loading 状态，有人用组件，有人写在页面里。
同样一个 API 错误，有人 toast，有人弹窗，有人静默失败。
同样一个表单校验，有人用 schema，有人手写，有人相信用户不会乱填。

前端工程化的本质之一，就是减少这种随机性。

frontend-craft 可以让 AI 也遵守类似的工程边界。

---

3. 正在做老项目改造的人

老项目迁移最怕什么？

不是代码老。
是你不知道哪些代码能动，哪些代码一动就祖坟冒烟。

frontend-craft 里有 legacy 相关能力，适合做 jQuery / 传统前端向现代 React、Vue、TypeScript、Vite 等方向迁移时使用。

它不会魔法般让老项目一夜年轻，但可以让改造过程更有章法。

---

4. 对代码质量比较洁癖的人

如果你看到下面这些代码会血压升高：

const data: any = res.data;
<div onClick={handleClick}>提交</div>
// TODO: later
catch (e) {
  console.log(e);
}

那你大概率会喜欢 frontend-craft。

它不是为了让代码显得“高级”，而是尽量让 AI 输出更接近可维护、可 review、可交付的工程代码。

---

它不是什么？

为了避免误会，也说几句实在话。

frontend-craft 不是银弹。

它不能保证 AI 永远不犯错。
它不能替代你理解业务。
它不能帮你背锅。
它也不能让一个混乱十年的项目，装完插件后自动变成硅谷样板间。

它更像一个“前端工程加固包”：

• 给 AI 更多项目规范；
• 给团队更多统一入口；
• 给 review 更多结构化依据；
• 给开发流程更多自动检查；
• 给设计还原更多上下文；
• 给老项目改造更多方法论。

最终代码质量，还是要靠人和流程共同兜底。

但如果你已经在用 AI 写前端，它确实能把体验从“AI 随缘输出”往“AI 工程协作”推一步。

这一步，不小。

---

推荐上手姿势

如果你是第一次试，建议别一上来就让它改整个项目。

可以按这个顺序来：

第一步：先装到一个测试项目

npm install -g @bovinphang/frontend-craft@latest
cd your-project
fec setup

第二步：让它做一次 review

Review my recent changes. Focus on architecture, type safety, rendering behavior, styles, accessibility, and missing tests.

或者直接：

/fec-review

先看看它输出的 review 报告是否符合你的预期。

第三步：拿一个小功能试试

比如：

• 登录表单；
• 用户列表；
• 设置页；
• 详情弹窗；
• 文件上传；
• 权限路由；
• 移动端响应式页面。

不要一开始就让它重构整个宇宙。
AI 也怕你突然说：“顺便把祖传系统现代化一下。”

第四步：逐步沉淀团队规则

如果你发现某些规则很适合自己团队，可以进一步结合项目的 CLAUDE.md、rules、README、工程规范文档一起使用。

frontend-craft 的价值不是“一次性爽一下”，而是让 AI 长期保持相对稳定的工程习惯。

---

最后：AI 时代，前端更需要“手艺感”

很多人说 AI 会让前端变简单。

我觉得只说对了一半。

AI 确实能让写代码更快。
但项目越大、团队越复杂、业务越长期，越不能只追求“快”。

真正麻烦的从来不是写一个按钮。
而是这个按钮在不同权限、不同状态、不同设备、不同主题、不同语言、不同异常场景下，都别出幺蛾子。

这就是前端工程的手艺活。

frontend-craft 这个项目有意思的地方在于，它不是试图取代前端工程师，而是试图把前端工程师平时反复强调的那些东西，变成 AI 可以执行的工作流。

让 AI 少一点自由发挥。
让项目少一点随机惊喜。
让 reviewer 少一点深呼吸。
让前端多一点工程质感。

如果你也在用 AI 写前端，建议试试这个项目。

项目名称：frontend-craft
GitHub：https://github.com/bovinphang/frontend-craft
npm 包：@bovinphang/frontend-craft

欢迎 Star、试用、提 Issue。
更欢迎你拿它去真实项目里折腾一下。

毕竟，前端工程这门手艺，不能只靠玄学，也不能只靠加班。

有工具，就先把工具用起来。