文章目录
- 什么是氛围编程 (vibe coding)？
- OpenCode
- 背景介绍
- 技术架构
- OpenSpec：给AI画施工图纸
- 规范驱动开发（Spec-Driven Development，SDD）
- OpenSpec：一套轻量的 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 Development，SDD）
近两年，AI 编码助手已经能“听懂人话”，从一段自然语言描述里生成大段代码。但很多团队也发现：如果需求只是散落在聊天记录里、脑补在每个人的心里，AI 很容易“发挥过度”——代码写出来了，却不是你真正想要的系统行为。
规范驱动开发（Spec-Driven Development，SDD）试图解决的，就是这个问题。它把规范（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 的目录结构和文档规范，把上下文、约束和预期行为喂给 AI；AI 则在这些约束之内，去生成代码、补全文档、拆解任务甚至回填测试。两者真正对齐的，是那一份份可以被执行、可以被验证的规范。
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 Worktrees
- using-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 个关键问题
- 通过问答澄清需求理解，避免方向偏差
第二步：轻量设计视图
- 只产出对当前决策有帮助的视图（类图、流程图、时序图）
- 不追求 4+1 视图完整性，追求决策有效性
第三步：设计物同步更新
- 代码变更时，同步更新对应的设计图
- 保持设计物的"新鲜度"，避免过时
Grill-Me问题模板包含 4 层问题：
- 第一层（必须）：需求理解、成功标准、优先级
- 第二层（建议）：技术上下文、约束条件、依赖关系
- 第三层（可选）：设计方向、接口设计、异常处理
- 第四层（按需）：边界条件、并发场景、回滚方案
核心原则：简单需求只答第一层，复杂需求逐步深入。编码过程中发现新问题可以随时补充。
)
