什么是氛围编程 (vibe coding)？

氛围编程 (vibe coding) 是一种新兴的软件开发实践，它使用人工智能 (AI) 根据自然语言提示生成功能代码，从而加快开发速度，并让应用构建变得更加容易，对于那些编程经验有限的用户尤其如此。

该术语由 AI 研究人员 Andrej Karpathy 于 2025 年初创造，用于描述一种工作流，其中开发者的主要角色从逐行编写代码转变为通过对话风格更浓的过程指导 AI 助理生成、完善和调试应用。这样，您就可以腾出时间和精力思考大方向或应用的主要目标，而 AI 则负责编写实际代码。

氛围编程 (vibe coding) 与传统编程

使用传统编程时，您需要专注于实现细节，手动编写语言所需的特定命令、关键字和标点符号。而使用氛围编程时，您只需专注于所需的结果，用通俗易懂的语言描述您的目标，例如“创建用户登录表单”，AI 则负责处理实际的代码。

以下是比较：

OpenCode

背景介绍

AI 编程助手：OpenCode —— 免费开源、支持多种模型
增强插件：Oh My OpenCode —— 多模型协作、智能体系统（可选）

资料 : https://www.runoob.com/ai-agent/opencode-coding-agent.html

技术架构

SDD 与 OpenSpec

规范驱动开发（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。

OpenSpec 的核心结构可以概括成两块：

• openspec/specs/：系统当前“事实”的所在，按业务域组织的规范文件，描述的是现在这个系统实际如何工作。- openspec/changes/：正在进行中的变更，每个变更一个文件夹，里面通常包含：
  • proposal.md：为什么要做、准备做什么；
  • design.md：怎么做、关键技术决策；
  • tasks.md：拆分出的实施任务；
  • specs/：本次变更对应的 delta specs（增量规范），只写“新增/修改/删除了哪些行为”。

当一个变更完成、归档时，OpenSpec 会把这些 delta specs 合并回主目录下的 specs/，并把整个 change 文件夹挪到 changes/archive/，形成一条可追溯的“规范演化历史”。

从理念上看，OpenSpec 还强调几个关键特性：

• fluid / iterative：不再把工作强行切成“规划 → 实现 → 结束”的刚性阶段，而是鼓励在实现过程中不断回头修正规范与设计；- easy：初始化成本尽量低，文件就是 Markdown / YAML，任何编辑器都能打开；
• • brownfield-first：尤其关注“在已有系统上做增量变更”的场景，用 delta specs 把“今天要改什么”说清楚，而不是重写一份大而全的文档。

在这样的设计下，人与 AI 的协作模式也发生了改变：人通过 OpenSpec 的目录结构和文档规范，把上下文、约束和预期行为喂给 AI；AI 则在这些约束之内，去生成代码、补全文档、拆解任务甚至回填测试。两者真正对齐的，是那一份份可以被执行、可以被验证的规范。