文章目录什么是氛围编程 (vibe coding)OpenCode背景介绍技术架构OpenSpec给AI画施工图纸规范驱动开发Spec-Driven DevelopmentSDDOpenSpec一套轻量的 SDD 工作流Superpowers 给AI上工程纪律经验总结什么是氛围编程 (vibe coding)氛围编程 (vibe coding) 是一种新兴的软件开发实践它使用人工智能 (AI) 根据自然语言提示生成功能代码从而加快开发速度并让应用构建变得更加容易对于那些编程经验有限的用户尤其如此。该术语由 AI 研究人员 Andrej Karpathy 于 2025 年初创造用于描述一种工作流其中开发者的主要角色从逐行编写代码转变为通过对话风格更浓的过程指导 AI 助理生成、完善和调试应用。这样您就可以腾出时间和精力思考大方向或应用的主要目标而 AI 则负责编写实际代码。氛围编程 (vibe coding) 与传统编程使用传统编程时您需要专注于实现细节手动编写语言所需的特定命令、关键字和标点符号。而使用氛围编程时您只需专注于所需的结果用通俗易懂的语言描述您的目标例如“创建用户登录表单”AI 则负责处理实际的代码。以下是比较功能传统编程氛围编程 (Vibe coding)代码创建逐行手动编码AI 根据自然语言提示生成开发者或用户角色架构师、实现者、调试者提示者、引导者、测试者、优化者需要具备编码专业知识较高编程语言和语法知识较低了解所需的功能主要输入精确的代码自然语言提示和反馈开发速度通常较慢有条不紊可能更快特别是对于原型设计更简单的任务错误处理根据代码理解进行手动调试通过对话式反馈进行优化学习曲线往往很陡可能降低进入门槛代码可维护性依赖于代码质量、开发者技能和既定实践可能严重依赖 AI 输出质量和用户评价OpenCode背景介绍AI 编程助手OpenCode —— 免费开源、支持多种模型增强插件Oh My OpenCode —— 多模型协作、智能体系统可选资料 : https://www.runoob.com/ai-agent/opencode-coding-agent.html官网https://opencode.ai/技术架构基于客户端-服务器架构的开源AI编程助手解决方案服务器组件处理AI模型集成、代码分析和任务执行等核心逻辑客户端则专注于用户界面和交互体验。所有核心任务如 AI 模型调用、工具执行和会话管理都由服务器全权负责。这种设计的优势在于多端支持除了 TUI桌面应用、VS Code 等 IDE 插件都可作为客户端接入实现功能复用。高可扩展性通过清晰定义的 API可以轻松集成新的客户端或自定义服务。隐私安全服务器可运行在本地代码和上下文信息无需上传至第三方服务器保障了数据安全。为了进一步模块化OpenCode 的设计遵循了“四层”模型各层职责清晰。客户端层提供用户交互界面包括终端 TUI、桌面应用、VS Code/Cursor 等 IDE 插件。核心服务层系统的“大脑”负责任务的拆解与执行包含代理调度、任务管理和工具引擎。扩展层负责功能扩展和个性化适配支持插件系统、MCP 服务器和技能配置等。模型适配层抽象了不同 AI 提供商的接口实现对超过 75 种 LLM 的统一适配和调度。OpenSpec给AI画施工图纸规范驱动开发Spec-Driven DevelopmentSDD近两年AI 编码助手已经能“听懂人话”从一段自然语言描述里生成大段代码。但很多团队也发现如果需求只是散落在聊天记录里、脑补在每个人的心里AI 很容易“发挥过度”——代码写出来了却不是你真正想要的系统行为。规范驱动开发Spec-Driven DevelopmentSDD试图解决的就是这个问题。它把规范spec而不是代码当成系统的“单一事实来源”先用结构化、机器可读的方式把系统应该做什么、有哪些边界和不变量写清楚再让代码、测试和文档都围绕这份规范生成和验证。在 InfoQ 的文章中SDD 被形容为一种“可执行架构”规范不只是说明书而是驱动生成代码、检测漂移、持续验证行为的控制平面架构不再是建议而是可以被执行和强制的规则。在 AI 时代这种思路格外契合人类更多精力放在表达意图、约束和政策上机器根据规范去生成代码、测试和各种工件并不断对照规范做校验一旦实现和规范不一致就通过自动化验证或“漂移检测”及时发现和纠正。换句话说SDD 把人与 AI 的分工从“人写代码、AI 帮补全”提升为“人维护意图和规范、AI 负责具体实现”让协作的重心回到“说清楚要什么”上。OpenSpec一套轻量的 SDD 工作流OpenSpec 就是在这个背景下长出来的一个开源框架它不是再造一门 DSL而是用非常接地气的方式把 SDD 变成日常可以落地的工作流。项目本身在 GitHub 上开源OPSX 工作流的详细说明则在官方文档中有完整介绍docs/opsx.md。官方定义Agree before you build — human and AI align on specs before any code gets written.一句话先定规矩再写代码。核心设计specs/ 和 changes/ 分离把“当前状态”和“变更提案”分开管理openspec/ ├── specs/# 所有系统规范的当前真相来源像Git的main分支│ └──[capability]/ │ └── spec.md └── changes/# 所有提议、进行中、已归档的变更└──[change-name]/ ├── proposal.md# 为什么要改、改什么├── tasks.md# 实施检查清单└── specs/# 规范的增量“补丁”当一个变更完成、归档时OpenSpec 会把这些 delta specs 合并回主目录下的 specs/并把整个 change 文件夹挪到 changes/archive/形成一条可追溯的“规范演化历史”。从理念上看OpenSpec 还强调几个关键特性fluid / iterative不再把工作强行切成“规划 → 实现 → 结束”的刚性阶段而是鼓励在实现过程中不断回头修正规范与设计- easy初始化成本尽量低文件就是 Markdown / YAML任何编辑器都能打开brownfield-first尤其关注“在已有系统上做增量变更”的场景用 delta specs 把“今天要改什么”说清楚而不是重写一份大而全的文档。在这样的设计下人与 AI 的协作模式也发生了改变人通过 OpenSpec 的目录结构和文档规范把上下文、约束和预期行为喂给 AIAI 则在这些约束之内去生成代码、补全文档、拆解任务甚至回填测试。两者真正对齐的是那一份份可以被执行、可以被验证的规范。Superpowers 给AI上工程纪律Superpowers 提供一系列强大的技能Skills来增强开发工作流。这些技能包括brainstorming - 头脑风暴创建功能前的需求探索dispatching-parallel-agents - 并行任务分发executing-plans - 执行书面实施计划finishing-a-development-branch - 开发分支完成处理receiving-code-review - 代码检视意见处理requesting-code-review - 请求代码审查subagent-driven-development - 子Agent驱动开发systematic-debugging - 系统化调试test-driven-development - 测试驱动开发using-git-worktrees - 使用 Git Worktreesusing-superpowers - 技能使用引导必读verification-before-completion - 完成后验证writing-plans - 编写实施计划writing-skills - 技能编写项目地址gitclone https://github.com/obra/superpowers.git ~/.config/opencode/extensions/superpowers官方定义Superpowers is a complete software developmentworkflowfor your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them.核心设计它把软件工程的最佳实践变成AI必须遵守的规则。Superpowers内置了一套完整的工作流强制AI按固定步骤走它的技能是自动触发的不需要你记住命令。你说“帮我规划一个新功能”AI会自动调用brainstorming开始问问题。另外Superpowers对测试的态度非常硬核先写测试再写代码。如果在测试之前写了代码直接删掉。在业界规范驱动开发已有多种实践范式。我们调研后发现两个主流方案各有优劣范式优势不足Superpowers技能Skills体系设计精良任务拆解和执行能力强人机交互流畅缺乏统一的目录规范spec管理分散资产沉淀能力弱OpenSpec目录结构规范清晰specs/作为唯一真相源归档合并机制完善技能包体系较弱AI执行流程不够标准化将两者融合取长补短——复用Superpowers的技能优势引入OpenSpec的目录规范和归档机制可形成一套端到端的SDD解决方案经验总结三个弯路的本质问题弯路一直接把需求扔给 AI 编码缺乏设计可见性事后才发现方向错误弯路二纯粹使用 OpenSpec 端到端文档结构化但设计仍不可见无法事前判断方案弯路三堆砌大量检查点和文档每个环节都有检查点过度流程导致 Token 浪费文档过时反而增加认知负担验证的有效原则AI 执行能力强 → 保留直接编码能力结构化流程必要 → 保留 OpenSpec 的 proposal/spec/design/tasks更适合跨 Session 延续开发设计“可见”比设计文档多 更重要Grill Me 和设计视图不可或缺。文档必须随设计变化同步更新而非追加说明关键平衡点在直接编码太快和重流程太慢之间需要的是一个轻量但可见的设计阶段——编码前能通过可视化设计物而非纯文字文档看清实现方案且这些设计物能随代码同步演进。关于实践方案的落地建议分三步走第一步建立 Grill Me 机制在需求输入后让 AI 先提问 5-10 个关键问题通过问答澄清需求理解避免方向偏差第二步轻量设计视图只产出对当前决策有帮助的视图类图、流程图、时序图不追求 41 视图完整性追求决策有效性第三步设计物同步更新代码变更时同步更新对应的设计图保持设计物的新鲜度避免过时Grill-Me问题模板包含 4 层问题第一层必须需求理解、成功标准、优先级第二层建议技术上下文、约束条件、依赖关系第三层可选设计方向、接口设计、异常处理第四层按需边界条件、并发场景、回滚方案核心原则简单需求只答第一层复杂需求逐步深入。编码过程中发现新问题可以随时补充。 
长河君 · 2026/8/5 22:14:51 · 阅读 1.2k vibe coding/SDD实践
文章目录什么是氛围编程 (vibe coding)OpenCode背景介绍技术架构OpenSpec给AI画施工图纸规范驱动开发Spec-Driven DevelopmentSDDOpenSpec一套轻量的 SDD 工作流Superpowers 给AI上工程纪律经验总结什么是氛围编程 (vibe coding)氛围编程 (vibe coding) 是一种新兴的软件开发实践它使用人工智能 (AI) 根据自然语言提示生成功能代码从而加快开发速度并让应用构建变得更加容易对于那些编程经验有限的用户尤其如此。该术语由 AI 研究人员 Andrej Karpathy 于 2025 年初创造用于描述一种工作流其中开发者的主要角色从逐行编写代码转变为通过对话风格更浓的过程指导 AI 助理生成、完善和调试应用。这样您就可以腾出时间和精力思考大方向或应用的主要目标而 AI 则负责编写实际代码。氛围编程 (vibe coding) 与传统编程使用传统编程时您需要专注于实现细节手动编写语言所需的特定命令、关键字和标点符号。而使用氛围编程时您只需专注于所需的结果用通俗易懂的语言描述您的目标例如“创建用户登录表单”AI 则负责处理实际的代码。以下是比较功能传统编程氛围编程 (Vibe coding)代码创建逐行手动编码AI 根据自然语言提示生成开发者或用户角色架构师、实现者、调试者提示者、引导者、测试者、优化者需要具备编码专业知识较高编程语言和语法知识较低了解所需的功能主要输入精确的代码自然语言提示和反馈开发速度通常较慢有条不紊可能更快特别是对于原型设计更简单的任务错误处理根据代码理解进行手动调试通过对话式反馈进行优化学习曲线往往很陡可能降低进入门槛代码可维护性依赖于代码质量、开发者技能和既定实践可能严重依赖 AI 输出质量和用户评价OpenCode背景介绍AI 编程助手OpenCode —— 免费开源、支持多种模型增强插件Oh My OpenCode —— 多模型协作、智能体系统可选资料 : https://www.runoob.com/ai-agent/opencode-coding-agent.html官网https://opencode.ai/技术架构基于客户端-服务器架构的开源AI编程助手解决方案服务器组件处理AI模型集成、代码分析和任务执行等核心逻辑客户端则专注于用户界面和交互体验。所有核心任务如 AI 模型调用、工具执行和会话管理都由服务器全权负责。这种设计的优势在于多端支持除了 TUI桌面应用、VS Code 等 IDE 插件都可作为客户端接入实现功能复用。高可扩展性通过清晰定义的 API可以轻松集成新的客户端或自定义服务。隐私安全服务器可运行在本地代码和上下文信息无需上传至第三方服务器保障了数据安全。为了进一步模块化OpenCode 的设计遵循了“四层”模型各层职责清晰。客户端层提供用户交互界面包括终端 TUI、桌面应用、VS Code/Cursor 等 IDE 插件。核心服务层系统的“大脑”负责任务的拆解与执行包含代理调度、任务管理和工具引擎。扩展层负责功能扩展和个性化适配支持插件系统、MCP 服务器和技能配置等。模型适配层抽象了不同 AI 提供商的接口实现对超过 75 种 LLM 的统一适配和调度。OpenSpec给AI画施工图纸规范驱动开发Spec-Driven DevelopmentSDD近两年AI 编码助手已经能“听懂人话”从一段自然语言描述里生成大段代码。但很多团队也发现如果需求只是散落在聊天记录里、脑补在每个人的心里AI 很容易“发挥过度”——代码写出来了却不是你真正想要的系统行为。规范驱动开发Spec-Driven DevelopmentSDD试图解决的就是这个问题。它把规范spec而不是代码当成系统的“单一事实来源”先用结构化、机器可读的方式把系统应该做什么、有哪些边界和不变量写清楚再让代码、测试和文档都围绕这份规范生成和验证。在 InfoQ 的文章中SDD 被形容为一种“可执行架构”规范不只是说明书而是驱动生成代码、检测漂移、持续验证行为的控制平面架构不再是建议而是可以被执行和强制的规则。在 AI 时代这种思路格外契合人类更多精力放在表达意图、约束和政策上机器根据规范去生成代码、测试和各种工件并不断对照规范做校验一旦实现和规范不一致就通过自动化验证或“漂移检测”及时发现和纠正。换句话说SDD 把人与 AI 的分工从“人写代码、AI 帮补全”提升为“人维护意图和规范、AI 负责具体实现”让协作的重心回到“说清楚要什么”上。OpenSpec一套轻量的 SDD 工作流OpenSpec 就是在这个背景下长出来的一个开源框架它不是再造一门 DSL而是用非常接地气的方式把 SDD 变成日常可以落地的工作流。项目本身在 GitHub 上开源OPSX 工作流的详细说明则在官方文档中有完整介绍docs/opsx.md。官方定义Agree before you build — human and AI align on specs before any code gets written.一句话先定规矩再写代码。核心设计specs/ 和 changes/ 分离把“当前状态”和“变更提案”分开管理openspec/ ├── specs/# 所有系统规范的当前真相来源像Git的main分支│ └──[capability]/ │ └── spec.md └── changes/# 所有提议、进行中、已归档的变更└──[change-name]/ ├── proposal.md# 为什么要改、改什么├── tasks.md# 实施检查清单└── specs/# 规范的增量“补丁”当一个变更完成、归档时OpenSpec 会把这些 delta specs 合并回主目录下的 specs/并把整个 change 文件夹挪到 changes/archive/形成一条可追溯的“规范演化历史”。从理念上看OpenSpec 还强调几个关键特性fluid / iterative不再把工作强行切成“规划 → 实现 → 结束”的刚性阶段而是鼓励在实现过程中不断回头修正规范与设计- easy初始化成本尽量低文件就是 Markdown / YAML任何编辑器都能打开brownfield-first尤其关注“在已有系统上做增量变更”的场景用 delta specs 把“今天要改什么”说清楚而不是重写一份大而全的文档。在这样的设计下人与 AI 的协作模式也发生了改变人通过 OpenSpec 的目录结构和文档规范把上下文、约束和预期行为喂给 AIAI 则在这些约束之内去生成代码、补全文档、拆解任务甚至回填测试。两者真正对齐的是那一份份可以被执行、可以被验证的规范。Superpowers 给AI上工程纪律Superpowers 提供一系列强大的技能Skills来增强开发工作流。这些技能包括brainstorming - 头脑风暴创建功能前的需求探索dispatching-parallel-agents - 并行任务分发executing-plans - 执行书面实施计划finishing-a-development-branch - 开发分支完成处理receiving-code-review - 代码检视意见处理requesting-code-review - 请求代码审查subagent-driven-development - 子Agent驱动开发systematic-debugging - 系统化调试test-driven-development - 测试驱动开发using-git-worktrees - 使用 Git Worktreesusing-superpowers - 技能使用引导必读verification-before-completion - 完成后验证writing-plans - 编写实施计划writing-skills - 技能编写项目地址gitclone https://github.com/obra/superpowers.git ~/.config/opencode/extensions/superpowers官方定义Superpowers is a complete software developmentworkflowfor your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them.核心设计它把软件工程的最佳实践变成AI必须遵守的规则。Superpowers内置了一套完整的工作流强制AI按固定步骤走它的技能是自动触发的不需要你记住命令。你说“帮我规划一个新功能”AI会自动调用brainstorming开始问问题。另外Superpowers对测试的态度非常硬核先写测试再写代码。如果在测试之前写了代码直接删掉。在业界规范驱动开发已有多种实践范式。我们调研后发现两个主流方案各有优劣范式优势不足Superpowers技能Skills体系设计精良任务拆解和执行能力强人机交互流畅缺乏统一的目录规范spec管理分散资产沉淀能力弱OpenSpec目录结构规范清晰specs/作为唯一真相源归档合并机制完善技能包体系较弱AI执行流程不够标准化将两者融合取长补短——复用Superpowers的技能优势引入OpenSpec的目录规范和归档机制可形成一套端到端的SDD解决方案经验总结三个弯路的本质问题弯路一直接把需求扔给 AI 编码缺乏设计可见性事后才发现方向错误弯路二纯粹使用 OpenSpec 端到端文档结构化但设计仍不可见无法事前判断方案弯路三堆砌大量检查点和文档每个环节都有检查点过度流程导致 Token 浪费文档过时反而增加认知负担验证的有效原则AI 执行能力强 → 保留直接编码能力结构化流程必要 → 保留 OpenSpec 的 proposal/spec/design/tasks更适合跨 Session 延续开发设计“可见”比设计文档多 更重要Grill Me 和设计视图不可或缺。文档必须随设计变化同步更新而非追加说明关键平衡点在直接编码太快和重流程太慢之间需要的是一个轻量但可见的设计阶段——编码前能通过可视化设计物而非纯文字文档看清实现方案且这些设计物能随代码同步演进。关于实践方案的落地建议分三步走第一步建立 Grill Me 机制在需求输入后让 AI 先提问 5-10 个关键问题通过问答澄清需求理解避免方向偏差第二步轻量设计视图只产出对当前决策有帮助的视图类图、流程图、时序图不追求 41 视图完整性追求决策有效性第三步设计物同步更新代码变更时同步更新对应的设计图保持设计物的新鲜度避免过时Grill-Me问题模板包含 4 层问题第一层必须需求理解、成功标准、优先级第二层建议技术上下文、约束条件、依赖关系第三层可选设计方向、接口设计、异常处理第四层按需边界条件、并发场景、回滚方案核心原则简单需求只答第一层复杂需求逐步深入。编码过程中发现新问题可以随时补充。