2026 上半年,AI 编码的主线从"对着模型许愿"(vibe coding)转向结构化、可复用、跨工具的工程化体系。下面是近期 GitHub 上最值得关注的范式演进、Skills 生态与高热仓库。
过去半年最大的共识:开放式 prompt 产出不稳定。业界转向"规格 → 计划 → 任务 → 代码",并把整个链路拆成分层职责。AI 在执行结构化任务时,远比面对开放式 prompt 表现稳定。
"Vibe coding"(凭感觉写)= 你给 AI 一句模糊指令,它一口气猜着写完。问题是:需求越大,猜得越偏,而且你很难说清它哪里错了。
"Spec-Driven"(规格驱动)= 把一个大需求切成四段,每段都先对齐、落成文件,再进下一段。AI 每段只处理一个清晰小目标,出错点可定位、可回退。这就是为什么它更稳。
一句话:不是 AI 变聪明了,而是把"开放式大题"拆成了"有标准答案的小题"。下面这张表是这条流水线被拆出来的几层分工,各有代表项目。
| 分层 | 职责 | 代表项目 |
|---|---|---|
| Spec 框架 定义 What | 产出 SPEC.md / ARCHITECTURE.md / TASKS.md,锁定"要建什么" | GitHub Spec Kit OpenSpec BMAD-METHOD Intent cc-sdd |
| 规划 / 任务 编排 How | 把 spec 拆成可执行任务图,相当于"AI 项目经理" | Taskmaster Agent OS Beads Feature-Driven-Flow |
| 执行 Agent 写代码 | 多 agent 读仓库、改文件、跑测试、提交 | GSD OpenDevin CrewAI LangGraph AutoGen |
| AI IDE 提供界面 | 把规划与执行直接嵌入编辑器工作流 | Cursor Windsurf Kiro Claude Code |
| Spec-as-Source 最激进 | spec 即源码,生成的代码视为"编译产物"(类比 Terraform / SQL) | Tessl Intent 类平台 |
关键差异在于"人介入的位置":Spec 框架让人写详细需求,执行 Agent 与 Spec-as-Source 则把人推向只做高层系统设计。
Anthropic 于 2025-10 推出 Agent Skills 格式,2025-12 开源为标准。如今 Claude Code、OpenAI Codex CLI、Cursor、Gemini CLI、GitHub Copilot 共同支持 SKILL.md。核心机制是渐进式披露:启动时每个 skill 只扫约 100 token,真正用到才加载完整内容,比 MCP 更省 token、更易分享。
Skill 就是一个 SKILL.md 文件:顶部一句话说"我能干什么、什么时候用我",下面才是详细步骤。AI 平时只读那一句话(约 100 token),判断"这次任务用得上"才把全文加载进来。
为什么这设计关键:你可以挂上几百个 skill 而几乎不占上下文,用到哪个才付哪个的"内存成本"。而且因为是纯文本文件,一处写好,五大工具通用,还能像代码一样分享、版本管理。
对比 MCP:MCP 是常驻的工具服务(一直占着上下文和连接);Skill 是按需翻开的说明书(不用时几乎零成本)。两者互补,不是替代。
分类法来自社区:Skills 大体分这两类——一类补能力,一类锁偏好。
按社区讨论度与 star 增速挑选(数据为社区博客 / 榜单口径,仅供横向参考)。
GitHub 官方出品 · MIT · 兼容 30+ agent。装法:uv tool install specify-cli + specify init <proj> --integration <agent>(需 uv / Python 3.11+ / Git)。核心是一组斜杠命令,把"凭感觉写"变成"按规格建"。支持 skills 模式的 agent(如 Codex 传 --skills)会安装为 agent skill 而非 prompt 文件。
过去写代码是"需求文档写完就扔,代码才是真章";Spec Kit 把这件事倒过来:规格本身成为可执行的源头,代码是规格生成出来的产物,而不是规格只在旁边当参考。
它强制你分阶段走:先定项目宪法(铁律)→ 再说要建什么 → 消除歧义 → 才谈用什么技术 → 拆任务 → 最后才写码。每一步都落成文件,AI 在后续每一步都回头看这些文件,所以不会越写越跑偏。
打个比方:盖房子先签施工合同(宪法)、画设计图(spec)、定材料供应商(plan)、列施工排期(tasks),最后才动工(implement)。Spec Kit 就是逼 AI 按这个顺序来,而不是上来就砌墙。
| 命令 | 产物 | 作用 |
|---|---|---|
/speckit.constitution | constitution.md | 项目治理原则,所有决策的基石 |
/speckit.specify | spec.md | 功能规格:用户故事 + 功能需求,只谈 What/Why,不谈技术栈 |
/speckit.clarify | — | 覆盖式追问,规划前消除歧义(推荐) |
/speckit.plan | plan.md · research.md · data-model.md | 技术实现方案,在这里才指定技术栈与架构 |
/speckit.analyze | — | 跨产物一致性 / 覆盖度检查(tasks 后、implement 前) |
/speckit.checklist | 清单 | 生成质量清单,验证需求的完整/清晰/一致——官方称之为"给英文规格写的单元测试" |
/speckit.tasks | tasks.md | 按用户故事拆任务,带依赖排序、并行标记 [P]、文件路径 |
/speckit.taskstoissues | GitHub Issues | 任务转为 issue 便于跟踪 |
/speckit.implement | 代码 | 按计划顺序执行全部任务,落地功能 |
已命名集成包括 Copilot(默认)、Claude Code、Gemini CLI、Codex CLI、Cursor CLI、Qwen、opencode、Kiro、Goose 等;specify integration list 可查全部。三大开发阶段:Greenfield(从零生成)· Creative Exploration(并行多方案)· Brownfield(存量迭代)。
可定制两套机制:Extensions 加新命令/能力(扩展"能做什么",如接 Jira、加代码评审);Presets 改既有产物的格式/术语(改变"怎么做",如强制合规规格模板)。两者按优先级叠加,项目本地 overrides 可做一次性微调。
ECC 自称"harness-native operator system"——不是一堆 config,而是叠在 agent 之上的完整运行体系。它回答了一个关键问题:当模型够强之后,瓶颈变成"harness 工程",而非模型本身。下面是它的五大支柱。
"Harness"(挽具/马具)指的是套在模型外面的那层工程:模型是引擎,harness 是车身、变速箱、仪表盘。同一个引擎,装进玩具车还是赛车,表现天差地别——这就是为什么"模型一样,harness 不同,效果差很多"。
ECC 的五根支柱各解决一个长期痛点:Skills 给能力、Instincts 让它从每次会话里自学经验、Memory 治"开新会话就失忆"、Security 自查秘钥与越权、Research-first 强制先查清楚再动手。
为什么值得关注:它示范了"个人/团队怎么把零散的 hook、prompt、规则,组装成一个可自我进化的操作系统",是 harness 工程化的样板。
/evolve 聚类成完整 skill;30 天 TTL 淘汰不成熟项。可跨人/项目导入导出。--opus 跑红队/蓝队/审计三 agent 对抗。search-first skill 强制"先调研再写码",配合 docs-lookup / deep-research,用证据替代凭空臆造方案。ECC_HOOK_PROFILE=minimal|standard|strict 调严格度。它解决的 8 类痛点:会话失忆、质量不稳、重复犯错、安全盲区、上下文窗口浪费、跨工具碎片化、重幻觉轻调研、人工编排开销。
同属 CLI agent,但定位差异明显:Claude Code 拼"自动化生态",Codex 拼"异步委派 + 系统级安全",OpenCode 拼"模型无关 + 低成本"。benchmark 与价格为文章口径。
| 维度 | Claude Code | Codex | OpenCode |
|---|---|---|---|
| 最强 benchmark | SWE-bench Pro 64.3% | Terminal-Bench 82.7% | 取决于所选模型 |
| 重度月成本 | $100-200 | 按 token,浮动 | $10-80 BYOK 或 $0 |
| 执行模型 | 交互式结对 | 异步任务队列→PR | 交互 + 持久服务 |
| 锁定 | 仅 Anthropic | 仅 OpenAI | 任意,可会话内切换 |
| 安全模型 | 应用层 | 内核级沙箱 | 用户自控 |
一句话:深度自动化选 Claude Code,异步/系统级任务选 Codex,低成本/隐私/灵活选 OpenCode。
作者 Jesse Vincent(obra)· MIT · 你当前环境已装。它不是"一堆 prompt",而是一套完整软件开发工作流,由可组合的 skill + 强制触发机制构成。一句话定位:从你开始"建东西"那刻起,它不急着写代码,而是先逼出 spec,然后一路 TDD + 子 agent 执行,常能自主连续工作数小时不偏离计划。
Spec Kit 给你"流程命令",但要你手动一步步敲;Superpowers 更进一步:它用 hook 在会话一开始就强制注入纪律,让 AI 自己判断"这事该先 brainstorm、该先写测试",不用你催。
它的杀手锏是子 agent 驱动开发:每个任务派一个全新的子 agent 去做(不带主会话的杂乱上下文),做完先过"是否符合规格"审查、再过"代码质量"审查,不过就打回重做。等于给 AI 配了独立的实现者 + 两道质检员。
为什么能连干几小时:主 agent 只做调度、不被细节淹没;子 agent 上下文干净、目标单一。分工 + 自动质检,就是它"不偏离计划"的底层原因。
| 阶段 | 做什么 |
|---|---|
brainstorming | 苏格拉底式提问澄清意图,探索备选方案,分段展示设计供确认,存为设计文档 |
using-git-worktrees | 设计通过后建隔离工作区 + 新分支,跑项目初始化,验证测试基线干净 |
writing-plans | 拆成 2–5 分钟的小任务,每个任务含确切文件路径、完整代码、验证步骤(假设执行者是"没判断力、不爱测试的junior") |
subagent-driven-development | 每个任务派一个全新 subagent,做两阶段评审;或 executing-plans 分批 + 人工检查点 |
test-driven-development | 强制 RED→GREEN→REFACTOR:先写失败测试、看它失败、写最小代码、看它通过、提交。先于测试写的代码会被删掉 |
requesting-code-review | 任务间按计划评审,按严重度报告;critical 问题阻断推进 |
finishing-a-development-branch | 验证测试,给出 merge/PR/保留/丢弃选项,清理 worktree |
这是 Superpowers 质量的关键。每个任务:全新 subagent(不继承主会话上下文)由控制者投喂精确上下文 → 实现+自测+提交+自审 → 先过 spec 合规评审(防多建/漏建)→ 再过代码质量评审 → 有问题就回到实现者修复并重审,直到通过 → 标记完成。全部任务后再跑一次整体终审。
模型分级降本:1–2 文件且 spec 完整 → 便宜快模型;多文件集成 → 标准模型;架构/设计/评审 → 最强模型。这正是"controller 省 token、subagent 隔离上下文"的精髓。
| 类别 | skill |
|---|---|
| 测试 | test-driven-development(含 testing-anti-patterns) |
| 调试 | systematic-debugging(4 阶段根因法 + root-cause-tracing / defense-in-depth / condition-based-waiting)verification-before-completion |
| 协作 | brainstorming writing-plans executing-plans subagent-driven-development dispatching-parallel-agents requesting-code-review receiving-code-review using-git-worktrees finishing-a-development-branch |
| 元 | writing-skills using-superpowers |
设计哲学 4 条:① TDD 永远先写测试 ② 系统化优于拍脑袋 ③ 复杂度削减为第一目标 ④ 证据先于断言(验证后才声称成功)。这与你 CLAUDE.md 里"先求简单 / 完成前必须真实验证"高度一致。
自称"The most loved spec framework"。MIT · TypeScript · npm @fission-ai/openspec · Node 20.19+。本质:给 AI 编码加一层轻量、可持续演进的 spec 层,写码前先就"建什么"对齐。它和 Spec Kit 最大的不同是增量提案制(change-based)——spec 是随每次变更持续更新的活文档,天生为存量项目(brownfield)而设计。
Spec Kit 是"一次性为整个功能写一份大 spec",适合从零开新项目。但老项目天天改东西,你不可能每次都重写一遍全量规格。
OpenSpec 换了个思路:维护两套目录——specs/ 是"系统现在长什么样"的稳定真相;每次要改东西,先在 changes/ 里写一份"这次要改什么"的提案(只描述增量),实现完再把这份增量合并回稳定 specs。
打个比方:specs/ 像 Git 主分支(当前真相),每个 change 像一个 PR(只含 diff),archive 就是 merge。所以它天生适合存量项目、改动可追溯、文档不会腐化。
proposal.md — 为什么做、改什么specs/ — 本次涉及的需求与场景design.md — 技术方案tasks.md — 实现清单实现完成后 /opsx:archive 归档到 changes/archive/<日期>-<name>/ 并把变更合并进稳定 specs。扩展 profile 另有 /opsx:new /continue /ff /verify /bulk-archive /onboard;CLI:openspec init / update / config profile;支持 25+ 工具,自带 dashboard。
| 对比对象 | OpenSpec 的差异点 |
|---|---|
| vs Spec Kit | Spec Kit 全面但重:僵化阶段门、大量 Markdown、需 Python。OpenSpec 更轻、可自由迭代、无强制阶段门 |
| vs Kiro(AWS) | Kiro 强但锁死在自家 IDE、仅支持 Claude 模型。OpenSpec 用你现有工具 |
| vs 什么都不用 | 把"模糊 prompt + 不可预测结果"变成"先对齐再写码",带来可预测性而无繁文缛节 |
哲学 5 条:流动非僵化 · 迭代非瀑布 · 简单非复杂 · 为 brownfield 而非仅 greenfield · 从个人项目可扩到企业。实操:官方推荐 Codex 5.5 / Opus 4.7 做规划与实现;强调 context hygiene(实现前清空上下文);telemetry 可用 OPENSPEC_TELEMETRY=0 关闭。
名字玩梗 "Build More Architect Dreams"。MIT · npm bmad-method · 需 Node 20.12+ & Python 3.10+ & uv。本质不是"加一层 spec",而是一整套虚拟敏捷团队:用 12+ 个专职 agent 角色(PM/架构/开发/UX…)把"从想法到上线"的完整生命周期跑通,scale-adaptive(按项目规模自动伸缩流程)。
Spec Kit / OpenSpec 解决的是"建什么"(规格);BMAD 解决的是"谁来建、按什么角色协作"。它把一个开发团队的岗位——产品经理、架构师、开发、UX、测试——各做成一个 AI 角色,每个角色有自己的职责和产出物。
你不是对着一个"全能 AI"许愿,而是依次召唤不同角色:先让 PM 角色理需求、架构师角色定方案,再交给开发角色落地。角色之间通过文件工件交接,像真实敏捷团队的协作流。
代价与回报:环境最重(Node+Python+uv)、要学的角色最多;但换来的是覆盖"从想法到上线"的完整流程。适合复杂项目、想要一支"虚拟团队"的人。
BMM — 核心方法,34+ 工作流BMB — Builder,自造 agent/工作流TEA — Test Architect,测试架构BMGD — Game Dev,游戏开发CIS — Creative Intelligence,创意bmad-help — 内置导航 skill特色玩法 Party Mode:多角色同处一个会话互相对线,像开真实评审会。Web Bundles:把规划流程打包成 Gemini Gems / ChatGPT Custom GPTs,用包月模型做规划再回到 CLI 实现,省 token。
| 能力 | 说明 |
|---|---|
| Cross Platform Agent Team | 同一套角色跨多个 CLI/平台复用 |
| Sub Agent + Skills | 对齐 Anthropic 子代理与 Skills 架构 |
| BMad Builder v1 | 用框架造框架,自定义角色与工作流 |
| Dev Loop Automation | 开发循环自动化,减少人工串场 |
定位对照:Spec Kit/OpenSpec 解决"建什么"的对齐,BMAD 解决"谁来建、按什么流程建"——最重,但覆盖面也最广。下一节用一张表把三者放一起选型。
三个最热的 SDD(规格驱动)框架,定位差别很大。下面这张表帮你按项目情况选,不用三个都学。
| 维度 | Spec Kit | OpenSpec | BMAD-METHOD |
|---|---|---|---|
| 出品方 | GitHub 官方 | Fission-AI | bmad-code-org |
| 本质 | 规格优先的阶段门流程 | 变更增量(delta)+活文档 | agent 角色驱动的全生命周期 agile |
| spec 模型 | 一次性 spec.md → plan → tasks | specs/(稳定真相)+ changes/(提案) | PM/架构/开发等角色产出工件 |
| 技术栈 | Python | Node / TypeScript | Node 20+ & Python 3.10+ & uv |
| 安装 | specify CLI | npm @fission-ai/openspec | npx bmad-method install |
| 重量 | 重 · 流程僵化 · 门禁强 | 轻 · 流动 · 改动小 | 最重 · 12+ agent · 覆盖全流程 |
| brownfield | 偏弱(为新项目设计) | 强(增量最适合存量改造) | 强(规划与开发分离) |
| 工具兼容 | 30+ agent CLI | 25+ 主流 CLI · 自带 dashboard | 跨平台 + Web Bundles(Gemini/ChatGPT) |
| 适用场景 | 中大型新项目、强约束团队 | 存量迭代、改动要可追溯 | 完整产品团队、从想法到上线 |
一句话选型:新项目要强约束 → Spec Kit;老项目持续迭代要可追溯 → OpenSpec;想要虚拟团队覆盖全流程 → BMAD。三者并不互斥:可用 OpenSpec 管日常增量,大型立项时再上 Spec Kit / BMAD。
大量 skill 专治千篇一律的 AI 输出。典型是 frontend-design:禁用 Inter 字体、中性灰、8px 圆角这类默认套路,强制"先定美学再写码"。Vercel 的 Web Design Guidelines / React Best Practices 装机量极高。
从"单次会话"转向"会带记忆、能从重复错误中学习"的体系。ECC 把 skills / instincts / memory / security / research-first 打包成 harness,hooks + 评审循环让设置越用越聪明。
工具链解耦。同一套 spec / skill 喂给不同 agent(Claude Code / Codex / Cursor 通吃),AGENTS.md 成为跨工具的"agent README",已被 60k+ 项目采用。
subagent 并行执行 + 计划/代码双重 review 成为标配。Superpowers 是范本,Codex 也已支持 subagents 与 custom agents。
科研(K-Dense-AI/scientific-agent-skills)、营销(Corey Haines 32 skills)等说明 SKILL.md 正成为通用的"专家能力封装格式",不再局限于写代码。
你当前环境已装 Superpowers,下面三步可直接叠加收益。
选 Spec Kit 或 OpenSpec,把"需求 → 任务"结构化,减少开放式 prompt 带来的返工。
从 awesome 清单挑 Encoded Preference 类 skill,把代码风格、评审清单、提交约定写进 SKILL.md。
frontend-design / Vercel 规范类 skill 对 UI 项目收益最直接,杜绝"AI 味"默认输出。