我做了三个面向前端开发者的 Claude Code / Codex / OpenClaw 共享插件，希望能少让大家重复踩坑

最近我把自己在业余时间折腾 AI 编码工具的一些心得，整理成了三个共享插件，并开源了出来：

• Claude Code：frontend-craft
• Codex：frontend-craft-codex
• OpenClaw：frontend-craft-openclaw

仓库地址：

• https://github.com/bovinphang/frontend-craft
• https://github.com/bovinphang/frontend-craft-codex
• https://github.com/bovinphang/frontend-craft-openclaw

先说在前面：

这不是什么"装上就原地飞升、老板看了流泪、同事用了沉默"的神奇插件。

它更像是我个人在业余时间，一边踩坑一边攒出来的共享工具箱。
目标也很朴素：

把前端开发中那些高频、重复、适合标准化的 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 每次都像一个喝了三杯美式的资深架构师。

但它比较适合做一件事：

把前端开发中那些重复劳动、规范约束、分析检查，尽量做得更稳定一点。

三个版本各自是什么来头？

Claude Code 版：frontend-craft

面向使用 Claude Code 的开发者。
Claude Code 的优势是上下文理解很强，适合复杂 review 场景、Legacy 迁移分析、以及"我也说不清这段代码什么意思但我想让 AI 试着解释一下"这类需求。

Codex 版：frontend-craft-codex

面向使用 OpenAI Codex 体系的开发者。
两个版本的工作流设计保持高度一致，切换工具时不至于重新从零开始。

OpenClaw 版：frontend-craft-openclaw ← 新成员

没错，这次多了一个。

OpenClaw 是最新加入的版本，面向使用 OpenClaw 的开发者。
它延续了前两个版本的核心工作流设计思路，同时针对 OpenClaw 的特性做了一些适配和优化——所以并不只是复制粘贴换个名字那么敷衍。

如果你正在评估或已经在用 OpenClaw，这个版本应该能帮你少走一些弯路。

当然，如果你还没用过 OpenClaw……也许这是个了解它的理由？
（我只是提供插件，不负责替任何工具站台，这句话请自行判断。）

我自己最看重的一个点：留痕

很多 AI 工具的问题，不是"不会说"，而是：

说完就消失。

比如一个经典小剧场：

• 你：帮我 review 一下这个模块
• AI：洋洋洒洒一大段，指出 8 个问题
• 你：好像很有道理
• 三天后你：它当时到底说了哪 8 个？
• 大家：……

所以我在这套插件里，尽量把 review / analysis / evaluation 结果输出到 reports/ 目录里。

好处很直接：

• 可以回看
• 可以共享
• 可以留档
• 可以复盘
• 可以给新人看
• 也可以防止自己隔天就忘了当初改了什么

对于多人协作的项目来说，这种"不那么炫，但很有用"的能力，往往比花哨更重要。

为什么要同时维护三个版本？

说实话，多维护一个版本意味着多一份同步成本。
我当时加 OpenClaw 版本的时候也犹豫过：真的有必要吗？

最后说服自己的理由只有一个：

既然社区都在探索，那就别把路走窄。

有的同学用 Claude Code，
有的同学用 Codex，
现在又有同学开始试 OpenClaw，
那就尽量把常用工作流在三个生态里都整理出来。

这样至少大家在切换工具时，不至于每次都从零开始重新"驯化" AI。

当然，如果你一直用同一个工具，那另外两个版本对你来说就是摆设。
这完全没问题。摆设里有时候也住着下次要用的东西。

它更适合哪些场景？

我觉得比较适合以下情况：

1. 多人协作的前端项目

尤其是有 review、规范、交接、留痕诉求的项目场景。

2. 新旧技术栈混合的项目

比如：

• React + Vue3 混合
• Next / Nuxt 并存
• Monorepo + 老项目共存
• 甚至还有一点你不太敢轻举妄动的祖传前端

3. 正在多工具对比选型的开发者

如果你正好在 Claude Code / Codex / OpenClaw 之间做评估，三个版本能帮你在同等工作流下，更清楚地感知各工具的实际差异——而不是靠网上的测评帖脑补。

4. 想把个人 AI 用法沉淀成可复用资产的开发者

比如独立开发者、开源项目维护者、或者希望把自己的 AI 工作流系统化的技术同学。

"共享插件方式"和"各自手搓 prompt"有什么区别？

这不是说"手搓 prompt"不好。
只是很多事情一旦要多人协作，就会从"灵活"变成"混乱"。

这个时候，共享插件的意义就出来了。

这不是万能插件，但我觉得它挺适合干"脏活累活"

我对它的期待其实很朴素：

• 不一定要最惊艳
• 但尽量要更稳定
• 不一定替代人
• 但尽量帮开发者减少重复折腾
• 不一定一次到位
• 但最好能持续沉淀

说得再接地气一点：

它可能不是让你"哇"的那种工具，
但我希望它是让你用了之后觉得"嗯，这个还挺省事"的那种工具。

三个版本都是。包括 OpenClaw 这个新来的。

做这几个插件的时候，我自己也踩过不少坑

比如：

• 不同工具的插件机制差异，比想象中大
• 同样的工作流，在不同生态里，表现并不会自动保持一致
• 有些能力看起来都支持，真正落到细节上，还是要一项项适配
• 目录组织、命名方式、输出格式、可维护性，这些比“先跑起来”更麻烦
• 你以为自己在写插件，写到后面发现像在给未来的自己修路

这也是我越来越强烈的一个感受：

AI 工具真正难的，很多时候不是“能不能用”，而是“能不能长期顺手地用”。

单次体验惊艳不难。
难的是一个月后还愿意继续用，
两个月后还能复用，
三个月后回头看，自己不会怀疑“这到底是谁设计的”。

最好不要是自己骂自己。
虽然工程师在这方面一般都挺有经验。

欢迎大家来一起拍砖和完善

这三个仓库现在肯定还有很多地方可以继续打磨。
尤其是 OpenClaw 版，算是最新加入的，还比较嫩，特别欢迎用过的同学来提意见。

所以我更欢迎的是：

• Star
• Issue
• PR
• 使用反馈
• 场景建议
• 甚至直接指出哪里做得不够好

因为开源项目最怕的不是被提意见，
最怕的是作者一个人默默觉得自己做得还可以，社区安静得像无事发生。

那就真的有点尴尬了。

特别是三个版本同时安静的时候。

开源地址

• Claude Code：https://github.com/bovinphang/frontend-craft
• Codex：https://github.com/bovinphang/frontend-craft-codex
• OpenClaw：https://github.com/bovinphang/frontend-craft-openclaw

如果你也在折腾 AI 编码工具的落地和工程化，欢迎来看看。
如果刚好能帮你少踩一个坑，那这些仓库就没白开。

Star 是鼓励，Issue 是鞭策，PR 是雪中送炭，我都欢迎。
三个仓库都一样。别只 Star 一个。（开玩笑的，随你。）