前一篇我把三个主流 AI 编码框架拆了一遍，最后哪个都没选------拿 OpenSpec 做底座、补 Superpowers 的铁律、套 Spec Kit 的宪法，自己搭了一套三层架构，也跑通了一个完整案例。
但架构图是静态的。真正跑起来之后的事------八个 Skill 怎么从三个长到八个、内部的三条铁律怎么定、跑了四个月拿到什么效果、哪些场景不该用------才是落地的关键。下面我会一五一十说一下。
八个 Skill 怎么长出来的
最开始我只写了三个 Skill------product、page、review。起因很朴素：产品经理写的需求太水，经常需求文档里面格式混乱，缺少内容的情况下就就丢过来，让开发兜底很难受，product 是拿来发现他们 PRD 里的问题，然后方便 diss 他们的；page 就是写代码，把组件和 API 组装成能跑的页面；review 审代码，别让 AI 写出来的东西直接上线。三个够用了一阵子。跑完第一个需求之后发现断档太多，才陆续补上 api、ui、test、qa、bugfix。项目里实际在跑的八个：
| Skill | 职责 | 借鉴来源 |
|---|---|---|
product |
需求评审 → 任务拆解，六维评审 | grill-me（逐层审问，一次一个问题，拿着 PRD 和已有代码交叉审问） |
api |
接口文档 → 类型定义 + 请求函数 | 自研 |
ui |
设计稿 → 组件代码，强制确认封装组件 | 自研，因为现有框架不覆盖 UI 还原 |
page |
组件 + API → 完整页面，强制覆盖加载/空数据/报错/正常四种状态 | 自研 |
test |
单元测试，行为基线 | Superpowers 的 TDD 铁律 |
qa |
QA 用例扫查，跟 product 的验收标准交叉比对 | 自研 |
review |
Code Review + 规范回写 | 自研（现有框架的 review 不跟规范回流挂钩，发现问题没法自动补进 CLAUDE.md） |
bugfix |
Bug Case → 根因定位 → 修复 | 自研（现有框架不强制根因定位，AI 容易"看起来像这里的问题"就下手改） |
加的时机也不是设计出来的，是被业务逼出来的。
qa 加进来的原因很具体------开发提测之后，测试环境 Bug 一堆，来回返工。后来发现很多问题开发自己跑一遍用例就能发现，但没人跑。补上 qa 之后，开发提测前先执行 qa Skill ------拿着测试的 Excel 用例对照 product.md 的验收标准，逐条扫查代码。能拦住的在开发环境就拦住了，落到测试环境的 Bug 少了一大截。
bugfix 加进来更直接------QA 提了一个 Bug，AI 改了三次都没好。每次都是"看起来像这里的问题"就下手改了，没先定位根因。后来补上铁律：根因说不清，不许动手。 改前三步：定位（一句话说清根因）、范围（这个根因还影响了哪）、验证（修完怎么自证）。
完整的八个 Skill 实现细节我在另一篇里展开了------《企业级 AI Coding 的 Harness 工程实战：8 个 Skill 串起全链路》。这篇聚焦在"为什么这么设计"，不在"怎么一步步写 Skill"。
每个 Skill 内部的三条共同设计
这八条 Skill 分工不同，但内部有三条共同设计。这三条比具体的执行步骤更重要------它们是这套方案能稳定运行的底层逻辑。
设计一：先读 CLAUDE.md，不许跳过。 
api 先确认命名规范和响应体格式，ui 先确认封装了哪些组件、哪些已废弃、哪些禁止直接用 antd 导入，bugfix 先确认修复可能触碰哪些禁区。最早版本的 ui 没加这条，生成的组件全用的 antd 原生组件，但项目里早就封装过了。AI 不知道的事不会主动问------不喂约束，它就按训练数据里的"通用实践"来。
设计二：有明确决策点，遇到不确定就停下来等人。
不是全自动。全自动在企业场景里是灾难 ------AI 做错判断没人拦，一路跑到线上才炸。product 发现某个功能已经有人做过了 → 停下来确认是复用还是重做。api 发现接口字段文档没说清楚 → 标 [待确认] 等人补。bugfix 发现 Issue 信息不全 → 暂停等人补充。
设计三：末尾挂一张"常见坑速查表"。
同一个模型在不同项目里犯不同的错。每个坑三列------现象、原因、处理。这只表是活的 ------每交付一个需求，review 发现新坑就补进去。比如 bugfix 的表里就记着：
| 现象 | 原因 | 处理 |
|---|---|---|
| 修完一个 Bug 引入另一个 | 只看了 happy path | 回三步检查法，边界情况逐条过 |
| 顺手重构了无关代码 | 忍不住"顺便优化" | 改前把"不做什么"念一遍 |
| 改了好几个文件但根因没找到 | 在症状层面修修补补 | 退回定位：一句话说清根因了吗 |
下一个修 Bug 的人不需要重踩这些坑------AI 加载 bugfix Skill 时，这些坑自动变成约束。这个设计灵感直接来自 Superpowers 的 Red Flags 表------用经验堵死 LLM 的自我合理化空间。
跑了四个月，效果怎么样
几个可量化的变化：
端到端交付周期。 一个中等复杂度的需求（比如前一篇讲的"加角色筛选"），从需求评审到 review 通过，稳定在 2天内 。对比纯手工写同样的改动（含前后端联调），快了 1倍。
PR 平均轮次。 引入 review Skill 之前，一个 PR 平均要 2-3 轮才能合。review Skill 上了之后，第一轮 AI 自审就能拦住 70% 的低级问题（组件用错了、规范没遵守、loading 态没处理），平均轮次降到 1-2次。
Token 成本。 不像 Superpowers 那样每个 task 都派生独立子代理。Skill 按需调用 ------简单的 UI 改动只走 product → ui → review，不触发 api 和 test。Token 消耗大概是 Superpowers 全链的 四分之一到三分之一半。
规范累积。 跑了四个月，CLAUDE.md 从最初的 20 行长到了 80 行 。每一条都是 review 发现的真实规范漏洞补进去的，没有一条是拍脑袋写的。spec/changes/ 下积累了 20+ 个需求 的完整产出，新需求进来前先搜有没有类似的------复用比例大概 30%。
但有一个事得提前说明下。
第一，八个 Skill 还在持续调。大概每跑完 3-4 个需求我就会微调一次决策点。它不是一套"装完就不用管"的成品，是一个活的系统。
不适合的场景
说实话。
需要极致代码质量和完整 TDD 覆盖的------Superpowers 的 14 个 Skill 比我这套更细粒度。我这里 test Skill 有 TDD 约束，但不像 Superpowers 那样，"没有失败测试不许写生产代码" 的铁律焊死在每一个执行节点上。
小团队、个人项目、一次性脚本、紧急 hotfix、原型探索------这些场景不需要这套东西，裸 Claude Code 更合适。流程开销是固定成本，团队越小、改动越小越不划算。
这套方案瞄准的场景是：中大型团队，想在速度和纪律之间找到一个真正能跑的平衡点。 绿地也好、棕地也好，都能跑。
三个可以立刻动手的事
如果你也在类似场景------有个几万行的老项目，不想太重也不想太野------下面三件事不用等到"搭完整体系"那天。
第一件：先建一个单目录收产出。 别管八个 Skill、别管 Delta Spec、别管 Harness 三层。就是 spec/changes/<feature>/，把每次改动的需求描述、接口说明、review 记录全塞进去。哪怕只收了两三个 markdown 文件，三个月后你回来翻能找得到，就已经比散落在聊天记录和 PR 描述里强十倍。从下一个需求开始就行，不需要补齐历史。
第二件：把 CLAUDE.md 里的"建议"改成"可验证约束"。 打开你项目里的 CLAUDE.md。如果里面写了"好好写代码""保持代码整洁"------删掉，换成"骨架屏必须用 CustomSkeleton""新依赖必须走审批""函数不超过 80 行"。AI 不知道什么叫"好好"，它只知道什么叫"必须"和"禁止"。 一条够了，下次 review 发现没拦住再补下一条。
第三件：挑一个最痛的环节写一个 Skill。 不需要八个全写。需求总是不清楚的写 product，UI 还原总是出问题的写 ui，Bug 总是反复修的写 bugfix。一个 Skill 三件事：触发条件 （什么时候用）、执行步骤 （标注决策点）、常见坑表。跑两个需求，review 自然会告诉你这个 Skill 漏了什么。
这篇文章多久会过时？
写完这两篇，我自己也在琢磨这个问题。
说实话，工具层面已经发生了翻天覆地的变化。现在很多人根本不用 IDE，全在终端里操作。两年前大家还在争论 Copilot 补全好不好用，现在连 IDE 这个壳都被很多人扔了。Spec Kit、OpenSpec、Superpowers 的版本号、具体命令、甚至某些阶段的名字，半年后大概率会变。
文中那些具体的实测数据------Spec Kit 1.5 小时、OpenSpec 40 分钟、Superpowers 55 分钟------这些数字是 2026 年 7 月的快照。模型升级，流程优化，数字马上变。大家读的时候把它当成 "这几个框架在同一个人、同一个需求下的相对差异 "，别当成绝对 benchmark。方向是对的，绝对值别较真。 
但工具会过时，不代表这篇文章的核心会过时。拆框架只是手段，我想讲的是更底层的另一个问题------
工具会过时，方法不会
AI 没有让软件工程技能贬值。恰恰相反------以前架构设计是"有了更好"，现在"没它不行"。
以前架构不好、规范不全、需求不清，顶多坑你自己和你的同事。现在呢？架构不好，还坑你所有的 coding agent------它们会忠实地复制你烂代码库里的烂模式，速度还快十倍。以前你写一个烂模块要三天，现在 AI 帮你写三十个烂模块只要三十分钟。
AI 不会替你思考，它只会加速执行你给它的一切------好的和烂的。所以那些过去"锦上添花"的工程基本功，现在成了生存门槛。
四个正在升值的基本功
第一：架构从可选项变成强制项。
过去架构设计在很多团队里是"有时间就做、没时间就跳"的事。AI 把这个窗口彻底关上了。你的代码库是什么结构、组件怎么分层、模块之间怎么依赖------AI 全盘照抄。AI 抹平了写代码的时间成本。烂架构的自我繁殖速度，跟好架构一样快。 你没得选，要么把架构理清楚，要么看着 AI 把你的技术债指数级放大。
前文那套组件分层对照表，本质就是在做这件事------不是写给 AI 看的说明书，是架构约束的可执行版本。
第二：AI 是知识放大器，不是知识替代品。
你是 AI 知识的上限。 如果你不懂架构、不懂怎么拆任务、不懂什么是好的反馈循环，AI 只会放大你的无知。反过来，如果你在这些领域有积累，AI 会把这些积累放大成十倍、百倍的产出。
这跟"AI 是 junior dev，你是 lead dev"是同一个意思。junior 写得快但没有判断力，没有记忆，不会主动问问题。你能不能当好这个 lead------把任务拆清楚、把标准讲明白、把产出审到位------决定了这个 junior 能不能成功。
第三：执行的比重从 90% 掉到 10%，但剩下的 10% 变成了 90%。
写代码本身------敲键盘、调样式、补边界------过去占了开发工作的九成。AI 把执行层的比重打下来了。但"想清楚要构建什么、接口怎么设计、什么样的代码算好、哪些坑不能踩"------这 10% 现在变成了工作的主体。
而这 10% 恰好就是软件工程的核心技能。不是"会用 React hooks"，是"知道什么时候不该用"。不是"能写 SQL"，是"能设计不会在两年后让你想删库跑路的表结构"。AI 帮我们卷低了执行的门槛，却卷高了判断力的天花板。工具代替的是键盘的敲击，而不是大脑的思考。
第四：过去 20 年的好书里都写好了。
这句话可能有点反直觉------AI 这么新的东西，答案怎么会在旧书里？但你想一下：《人月神话》讲的是"加人不会让项目更快"，放到今天就是"加 agent 不会让项目更快，拆不清楚任务加什么都没用"。《领域驱动设计》讲的是通用语言，放到今天就是组件分层表------AI 和代码库之间的通用语言。《程序员修炼之道》讲的是"不要容忍破窗"，放到今天就是"AI 会复制你的每一扇破窗，修好它再让 AI 开工"。
工具巨变，但工程方法没坏。AI 只是让你更需要那些真正重要的东西------而碰巧，那些东西过去 20 年的好书里都写好了。
四个不过时的思维工具
第一是"看透工具本质"的拆法。
前一篇我把三个框架拆成 "做什么 "、"怎么做 "、"按什么标准做 " 三个维度。这个拆法不依赖任何具体实现。明年冒出第四个框架，你拿着这套维度往上一套------它到底在解决哪个环节的问题、跟现有框架是什么关系，五分钟能判断出来。比"这个工具怎么用"更持久的是 "这个工具在解决什么问题的什么环节"。
第二是"棕地 vs 绿地"的场景判断。
不管工具怎么换，在已有代码上修修补补跟从头盖一栋楼，是两个彻底不同的挑战。这个判断标准十年不会变。"规范管理方式决定了框架的适用场景。 框架名换掉，规律还在。
第三是"胶水成本"。
Spec Kit + Superpowers 组合的核心痛点不是"两个都重"，是"中间那条缝得靠人手填"。这是工程里最容易被低估的成本------不是工具本身的复杂度，是工具之间的衔接面 。你每引入一个新工具，就在增加一条缝。缝越多，人越累。
第四是三个最基础的事。
跟客户沟通、搞清楚到底要构建什么、把大块拆成小块------不管你用 IDE 还是终端、用 Copilot 还是 Claude Code，一步都省不了。AI 能帮你把小块执行得更快，但 "拆成什么样的小块 "，还是得你自己判断。工具替你扛的是执行，不是思考。
工具会翻天覆地，工程方法岿然不动。把这两件事分开，你就不会被每个新框架牵着鼻子走。
我搭的那套方案里提到的 8 个 Skill、三个硬指标、.spec.yaml 追踪文件（就是个记录各 Skill 状态的流水线看板）------这些实现细节也在持续调。大概每跑完 3-4 个需求我就会微调一次 Skill 的决策点。后续开源如果去看我的仓库，跟这篇文章里的描述可能已经有出入。但设计原则------OpenSpec 的 Delta Spec 做底座、Skill 补纪律、单目录收拢------这四个月没变过。
如果你看完这三篇文章，只记住了一句话------"下次选工具时先想清楚它解决的是哪个环节的问题 "------那文章的目的就达到了。至于 Spec Kit 有几个阶段、OpenSpec 有什么命令，忘了也没关系。 量身定做的东西，比万能钥匙靠得住。
欢迎大家关注我的公众号：深入浅出AI
