最近我把团队里常用的一些 Claude Code / Codex 工作流，整理成了两个共享插件，并开源了出来：
- Claude Code：
frontend-craft - Codex：
frontend-craft-codex
仓库地址：
先说在前面：
这不是什么“装上就原地飞升、老板看了流泪、同事用了沉默”的神奇插件。
它更像是一套我在企业前端团队里，一边踩坑一边攒出来的共享工具箱。
目标也很朴素：
把一些高频、重复、适合标准化的 AI 工作流，尽量整理得更能复用一点。
为什么会做这个？
因为我发现，很多团队在用 AI 编码工具时，都会进入一种熟悉又微妙的状态：
- 每个人都有自己的 prompt 小宇宙
- 每个人都觉得自己在提效
- 但团队层面看，还是有点“八仙过海，各显神通”
- review 说过的话，过几天就找不到了
- 新同学接入时，常常只能靠口口相传
- 老项目不会接，新项目乱接一通
说白了就是：
个人会用 AI，不等于团队真的把 AI 用成了稳定生产力。
所以我就想，干脆把这些经常重复出现的事情，收拢成一套共享工作流。
这套插件主要能干什么？
目前主要覆盖这些前端团队常见场景：
- Code Review
- Security Review
- Accessibility Check
- Design to Code
- Scaffold
- lint / type-check / test / build 后辅助修复
- React / Vue3 / Next.js / Nuxt / Monorepo
- Legacy Web / 老项目迁移分析
先立个谦虚的 flag：
它当然不是万能的。
它不能替你理解所有业务逻辑，
也不能替你驯服全部祖传代码，
更不能保证 AI 每次都像一个喝了三杯美式的资深架构师。
但它比较适合做一件事：
把前端团队里那些重复劳动、规范约束、分析检查，尽量做得更稳定一点。
我自己最看重的一个点：留痕
很多 AI 工具的问题，不是“不会说”，而是：
说完就消失。
比如一个经典小剧场：
- 你：帮我 review 一下这个模块
- AI：洋洋洒洒一大段，指出 8 个问题
- 你：好像很有道理
- 三天后你：它当时到底说了哪 8 个？
- 大家：……
所以我在这套插件里，尽量把 review / analysis / evaluation 结果输出到 reports/ 目录里。
好处很直接：
- 可以回看
- 可以共享
- 可以留档
- 可以复盘
- 可以给新人看
- 也可以防止自己隔天就忘了当初改了什么
对于企业团队来说，这种“不那么炫，但很有用”的能力，往往比花哨更重要。
为什么同时做 Claude Code 和 Codex 两个版本？
原因也不复杂：
既然团队都在探索，那就别把路走窄。
有的同学更习惯 Claude Code，
有的同学想试 Codex，
那就尽量把常用工作流在两个生态里都整理出来。
这样至少大家在切换工具时，不至于每次都从零开始重新教 AI 干活。
它更适合哪些团队？
我觉得比较适合这些场景：
1. 多人协作的企业前端团队
尤其是有 review、规范、交接、留痕诉求的团队。
2. 新旧技术栈混合的团队
比如：
- React + Vue3 混合
- Next / Nuxt 并存
- Monorepo + 老项目共存
- 甚至还有一点你不太敢轻举妄动的祖传前端
3. 想把 AI 用法沉淀成团队资产的负责人
比如前端负责人、技术经理、架构师、核心骨干同学。
“共享插件方式”和“各自手搓 prompt”有什么区别？
| 维度 | 各自手搓 | 共享插件 |
|---|---|---|
| 使用方式 | 每人一套 prompt，风格随缘 | 团队共用工作流，口径更稳定 |
| review 结果 | 说完就散，回头难找 | 可落盘留痕，方便复盘 |
| 新人接入 | 靠口口相传和“你自己悟一下” | 有固定入口，上手更顺 |
| 规范统一 | 容易漂移 | 更容易沉淀为团队资产 |
| 老项目适配 | 经常临场发挥 | 有更明确的场景支持 |
| 团队协作 | 个人很灵活，团队略混乱 | 少一点玄学，多一点复用 |
这不是说“手搓 prompt”不好。
只是对于团队来说，很多事情一旦要多人协作，就会从“灵活”变成“混乱”。
这个时候，共享插件的意义就出来了。
这不是万能插件，但我觉得它挺适合干“脏活累活”
我对它的期待其实很朴素：
- 不一定要最惊艳
- 但尽量要更稳定
- 不一定替代人
- 但尽量帮团队减少重复折腾
- 不一定一次到位
- 但最好能持续沉淀
说得再接地气一点：
它可能不是让你“哇”的那种工具，
但我希望它是让你用了之后觉得“嗯，这个还挺省事”的那种工具。
欢迎大家来一起拍砖和完善
这两个仓库现在肯定还有很多地方可以继续打磨。
所以我更欢迎的是：
- Star
- Issue
- PR
- 使用反馈
- 场景建议
- 甚至直接指出哪里做得不够好
因为开源项目最怕的不是被提意见，
最怕的是作者一个人默默觉得自己做得还可以，社区安静得像无事发生。
那就真的有点尴尬了。
开源地址
- Claude Code：github.com/bovinphang/…
- Codex：github.com/bovinphang/…
如果你也在折腾企业前端团队的 AI 落地、工程化、规范化，欢迎来看看。
如果刚好能帮你少踩一个坑，那这个仓库就没白开。
Star 是鼓励，Issue 是鞭策，PR 是雪中送炭，我都欢迎。
