企业官网建设流程全解析

AIDD、Vibe Coding、SDD 三选一：2026 年 AI 写代码的三种路线，谁才是正经路子

【免费下载链接】spec-kit💫 Toolkit to help you get started with SDD or any other process!项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kit

2025 年底，"Vibe Coding 已死"的论调开始刷屏技术社区，紧接着 AWS 被曝把规范驱动开发（SDD）当成新标准来推、Kiro 两周的功能两天交付、WEF 调研称 65% 的开发者预计 2026 年自己的工作重心将转向 spec-first 流程。到了 2026 年，AI 辅助编程已经分裂成三条清晰的路线：Agentic IDE-Driven Development（AIDD）、Vibe Coding 和 Spec-Driven Development（SDD）。三者并非同一枚硬币的两面——它们对"人机分工"的假设、对产物的定义、对失败成本的容忍度完全不同。本文以 GitHub 开源的 spec-kit 仓库为解剖样本，结合 2026 年社区真实讨论，把三条路线的取舍掰开来看：谁在什么场景下是正经路子，谁只是特定阶段的过渡方案。

三条路线的本质差异：控制权交给谁

理解三条路线的分歧，先看它们各自把"控制权"放在哪里。

Vibe Coding把控制权完全交给模型的即时理解。开发者用自然语言描述意图，模型边想边写，代码即产物，一切以"跑起来、看起来对"为验收标准。它的心智负担最低，但代价是没有中间产物——没有需求记录、没有方案文档、没有任务清单，对话一结束，所有上下文烟消云散。2026 年 3 月，Tiago Valverde 在社区分享的实测很有代表性：直接提示 Claude 做小改动没问题，但一旦任务变复杂，就会出现范围蔓延、需求歧义到后期才发现、以及"改完不留任何痕迹"三个问题。

AIDD（Agentic IDE-Driven Development）把控制权交给一个增强过的 IDE 运行时：IDE 内嵌 agent、MCP 工具、自动上下文收集、代码索引。Claude Code、Cursor、GitHub Copilot 的 agent 模式都属于这一类。它比纯 Vibe Coding 强在工具链——agent 能自己跑测试、读代码库、调用外部工具，但依然没有把"意图"固化成独立于会话的资产。

SDD则把控制权交给一组可追溯、可评审、可复用的文档资产。spec-kit 在 docs/concepts/sdd.md 里把核心理念总结得很直白：先定义"做什么、为什么"（what and why），再决定"怎么做"（how）；规范不是代码的脚手架，而是可执行的起点——直接驱动实现生成，而非仅仅指导实现。spec-kit 的默认路径是constitution → specify → plan → tasks → implement → converge，其中 constitution 每个项目只建一次，后五步每个功能迭代一次。核心产物spec.md、plan.md、tasks.md都以 Markdown 形式落盘，任何人在任何时刻都能回到这个"事实快照"上继续工作。

一句话概括三者的关系：Vibe Coding 赌模型的即时理解，AIDD 赌 IDE 运行时的工作能力，SDD 赌过程的确定性。

Vibe Coding 为什么失宠：不是模型变笨了，是场景变大了

"Vibe Coding 已死"的说法并不准确，更精确的表述是：Vibe Coding 适用的任务规模被 AI 能力本身快速推高了。当模型只能改一个函数时，Vibe 是高效的；当模型已经能写完一整个服务时，没有规格约束的 Vibe 就变成了一场没有图纸的施工。

spec-kit 的 2026 年 3 月 newsletter（newsletters/2026-March.md）完整记录了这场舆论转向：ByteIota 报道 AWS 将 SDD 作为新标准推进，称超过 10 万开发者已在早期工具预览中采用 SDD 式流程，并演示了 Kiro IDE 将两周的功能压缩到两天完成；批评者也拿到了同样的版面——Marmelab 说 SDD 是"Agile 本来要解决的那些错误"，Isoform 的对照测试发现 SDD 完成 689 行代码耗时 33 分钟，而迭代式提示只要 8 分钟，且没有测得质量提升。

这场争论的结论最终收敛成一个混合共识，Red Hat 开发者的概括广为流传："Use the vibes to explore. Use specifications to build."（用 Vibe 去探索，用规格去构建）。这正是 spec-kit 自己在 docs/concepts/sdd.md 中给出的实验方向之一——"支持从 vibe-coding 到 AI-native 开发的多种方式"。Vibe Coding 没有死，它退回到了它本就擅长的位置：探索、原型、一次性脚本、对产物没有长期要求的场景。

SDD 的失宠与上位，背后还有一个常被忽略的结构性原因：协作成本。单人 + 单 agent 的项目，Vibe 的上下文即兴发挥完全够用；一旦涉及多人协作、多 agent 交接、跨团队接口，对话式的隐性上下文就无法承担"契约"职能。spec-kit 的 docs/guides/contract-driven-development.md 把这个逻辑讲得很清楚：当组件对外暴露接口时，先约定双方可依赖的契约，再各自实现——接口形状可以由 schema 定义，但"重试会不会创建第二笔订单"这种语义契约必须由文档记录。Vibe Coding 产不出这种契约，AIDD 的 IDE 上下文也留不住这种契约，只有落盘的规格能。

SDD 的工程化底座：从工作流引擎到五类可组合原语

SDD 之所以在 2026 年从"方法论"升级为"正经路子"，是因为它有了工程化的承载。spec-kit 作为 GitHub 官方开源的实现，仓库本身就是一个完整的证据链。

看 workflows/speckit/workflow.yml，spec-kit 把 SDD 的每一步都做成了可机器编排的流程：specify生成规格 → 人工 gate 评审（approve/reject）→plan生成方案 → 再 gate →tasks拆任务 →implement执行，每一步命令都有明确的输入输出契约。这意味着 SDD 不再依赖某个特定 agent 的自觉，而是被流程引擎强制执行。

更关键的是 spec-kit 在 2026 年上半年打磨出的五类可组合原语（docs/history.md 有完整演进记录）：

• Integrations：对接各类编码 agent，仓库内置目录（integrations/catalog.json）当前收录 42 个，从 Claude Code、GitHub Copilot、Gemini CLI 到 Mistral Vibe、DeepSeek Harness、Docker Agent——包括 Vibe Coding 的代表性工具本身；
• Extensions：按需扩展能力，如官方一等流程bug（assess → fix → test）和assess（intake → research → define → shape → decide）；
• Presets：替换或定制默认行为。内置的 presets/lean/preset.yml 就是给"嫌七步流程太重"的人准备的——只保留specify → plan → tasks → implement四步，每个命令只产出一个精简 Markdown 文件，"只要提示词，只要产物"；
• Workflows / Workflow steps：多步骤自动化与可复用步骤单元。

这套架构直接回应了 2026 年社区对 SDD 的核心批评。批评者说"SDD 太重"，lean preset 用四步流程消解仪式感；批评者说"规格会漂移、文档与代码脱节"，社区用 verify-tasks 这类扩展来拦截"标记完成但没写代码"的幽灵完成，用 Archive & Reconcile 处理规格生命周期；批评者说"SDD 绑死单一工具"，42 个集成目录和 agent 无关的设计让流程与具体模型解耦。

值得一提的还有 spec-kit 自己的 dogfooding。它在 docs/guides/agentic-sdlc.md 中公开了自己作为"用 SDD 开发 SDD"的案例：feature-assess 工作流会在 GitHub Actions 中实例化 Specify CLI、安装 assess 扩展、走完 intake/research/define/shape/decide 五阶段并把go/needs-clarification/kill结论贴回 issue——但人类维护者始终拥有是否启动评估、如何处置结论的最终决定权。这种"agent 干活、人拍板"的分工，正是 2026 年 SDD 的主流形态。

给不同规模团队的选择清单

三条路线不是单选题，而是按团队规模和任务性质分层的组合题。下面这份清单基于上文的事实与源码证据整理。

个人开发者 / 独立黑客 / 原型阶段

• 首选 AIDD（Claude Code、Cursor 等 agent 模式），必要时叠加 Vibe Coding 做探索。
• 判断标准：产物是否需要被明天的自己复用？如果不需要，Vibe 即可；如果需要记录决策，哪怕只是写一页spec.md，也值得走一遍 SDD。
• 上手路径：uv tool install specify-cli+specify init（README.md），让 agent 在项目目录内用/speckit-specify起一个规格。

中小团队（5~20 人）

• 以 AIDD 为日常开发主力，SDD 用于跨人交接的功能和有外部接口的模块。
• 重点利用 spec-kit 的 presets 降仪式感：用 presets/lean 砍掉模板仪式，用 community 扩展补质量闸门（如 verify-tasks 拦截幽灵完成）。
• 契约先行：参照 docs/guides/contract-driven-development.md，对每个对外接口确定"一个权威所有者"，版本化发布契约，禁止静默同步到 latest。

大型团队 / 企业 / 合规敏感场景

• SDD 是主流程，AIDD 是执行层，Vibe 只保留在白板探索阶段。
• 理由来自 2026 年 3 月社区情报与仓库实证的双重支撑：企业需要可审计的决策轨迹（spec/plan/tasks 都是落盘资产）、可执行的合规约束（constitution 与预设可强制加入威胁模型章节、要求测试任务必须在实现任务之前）、跨 agent 的可移植性（42 个集成，换模型不换流程）。
• 规模化的方式是 bundles：spec-kit 的 examples/bundles/developer 展示了如何把扩展、预设、步骤、工作流打包成一个按角色分发的完整配置，直接specify bundle build产出分发物。

至于"谁才是正经路子"——2026 年的答案已经不在三条路线内部，而在它们的边界上。Vibe 负责把探索成本降到零，AIDD 负责把执行效率拉满，SDD 负责把意图固化成资产、让人和 agent 都能在同一个事实快照上协作。那些宣称某条路线"已死"的叙事，往往只是把一个路线的适用边界当成了它的失败。真正成熟的团队做法是：让三种路线各归其位，而不是三选一。

【免费下载链接】spec-kit💫 Toolkit to help you get started with SDD or any other process!项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kit