如何避免重复踩坑，统一 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/ 目录里。 好处很直接： 可以回看 可以共享 可以留档 可以复盘 可以给新人看 也可以防止自己隔天就忘了当初改了什么 对于多人协作的项目来说，这种"不那么炫，但很有用"的能力，往往比花哨更重要。 为什么要同时维护三个版本？ 说实话，多维护一个版本意味着多一份同步成本。