如何避免重复踩坑，统一 Claude CodeCodexOpenClaw 插件开发？

最近我把自己在业余时间折腾 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，风格随缘 共用工作流，口径更稳定 工具覆盖 一般只熟悉自己用的那个 Claude Code / Codex / OpenClaw 三套可选 review 结果 说完就散，回头难找 可落盘留痕，方便复盘 新人接入 靠口口相传和"你自己悟一下" 有固定入口，上手更顺 规范统一 容易漂移 更容易沉淀为可复用资产 老项目适配 经常临场发挥 有更明确的场景支持 协作使用 个人很灵活，多人略混乱 少一点玄学，多一点复用 这不是说"手搓 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 一个。（开玩笑的，随你。）