Vibe Coding 目前没有一套行业统一的知识分类标准。最可靠的做法，是把成熟的软件工程、系统工程、质量管理和交付框架，统一到你的核心模型：
在约束下，通过 AI 和工具，把系统从当前状态推进到目标状态，并用证据确认结果。
另外，OpenSSF 对“纯 Vibe Coding”的定义是：接受 AI 代码但不阅读、不理解、不审查。你的定义已经把它升级成了工程化 Vibe Coding，不是盲目接受 AI 输出。
Vibe Coding 可以理解为一种目标驱动、受约束、可验证的状态转移闭环：在人定义目标、边界和验收标准的前提下，借助 AI 和工具，把系统从当前状态持续推进到目标状态，并通过证据确认结果，必要时回滚迭代。
从控制结构看，这个闭环是一种固定目标、可变策略、分层反馈的系统：先把模糊需求经过澄清、结构化、一致性检查和人工确认，冻结为带版本的目标基线 G*；再让 Agent 在目标基线和约束不被静默修改的前提下，反复执行“观察当前状态 S_t → 识别状态差距 Δ_t → 选择策略与行动 → 获取验证证据 E_t → 接受、修正、回滚或切换策略”，使系统逐步进入目标的验收集合。若单次行动无效，则修正行动；若当前策略无效，则切换策略；若目标存在矛盾、不可行或无法判定，则暂停执行，重新审查目标或交由人决定。
原始需求 R
→ 澄清、结构化、一致性检查、人工确认
→ 版本化目标基线 G*
→ 观察当前状态 S_t
→ 识别状态差距 Δ_t
→ 选择策略 π_t 与行动 O_t
→ 执行
→ 采集验证证据 E_t
→ 接受 / 修正 / 回滚 / 切换策略
→ 下一轮状态 S_{t+1}
这里的“固定目标”不是目标永远不能变化，而是未经授权不能被执行者静默改变；合法变化必须创建新的目标版本。这里的“收敛”也不是保证每一步都成功，而是在验证、回滚、尝试上限和退出机制约束下，使系统进入并保持在目标验收集合中。
这套地图不是某个机构现成发布的单一框架，而是把 Double Diamond、Scrum、NASA V&V、NIST SSDF、DORA 和 PDCA 统一到你们项目的核心定义中。
最终可以压缩成一句话：
Vibe Coding = 人定义并授权目标，Agent 选择并执行行动，工具改变状态，验证器提供反馈，Git 固化历史。
这里的“状态”不只是代码，也包括需求、上下文、环境、质量、版本和交付条件。“差距”也不是简单的数值相减，而是当前状态与目标状态之间尚未满足的结构化条件。
本模型是本项目的知识地图，不是某个机构发布的 Vibe Coding 官方标准。它把问题求解、系统工程、迭代开发、质量验证、安全开发和持续交付统一到同一条状态转移主线上。
只把 Vibe Coding 理解成“用自然语言让 AI 写代码”，会遗漏真正决定结果的部分：
- 目标没有定义清楚，AI 可能高效地做出错误的东西。
- 约束和上下文没有固定，AI 会在不同假设之间漂移。
- 没有验收标准，就无法判断输出是否真的完成。
- 没有版本和回滚，错误会污染后续状态。
- 没有反馈，下一轮只是在重复试错，而不是持续收敛。
因此，Vibe Coding 的核心不是生成更多代码，而是控制状态如何变化，并证明变化是否有效。
这套模型包含两个嵌套闭环：先把需求收敛成目标基线，再在目标基线不变的前提下推进系统状态。
原始需求 R
→ 澄清与结构化
→ 一致性、可行性与可验证性检查
→ 人工确认
→ 目标基线 G*
目标基线不是一段代码，而是当前版本的目标契约。它至少包含目标、约束、非目标、验收条件、证据要求、未决假设和变更授权。
观察 S_t
→ 计算差距 Δ_t
→ 选择策略 π_t
→ 执行动作 O_t
→ 获取证据 E_t
→ 接受 / 修正 / 回滚 / 切换策略
→ S_{t+1}
可以用下面的符号理解整套系统：
| 符号 | 名称 | 核心问题 | 在 Vibe Coding 中的表现 |
|---|---|---|---|
R |
原始需求 | 用户最初想解决什么？ | 想法、对话、Issue、业务请求和问题描述 |
G* |
目标基线 | 这一轮必须达到什么？ | 目标、约束、非目标、验收条件和证据要求 |
S_t |
当前状态 | 现在是什么情况？ | 需求、代码、文件、环境、测试、版本和运行结果 |
Δ_t |
状态差距 | 还缺什么？ | 尚未满足的功能、信息、能力、证据和修复项 |
K |
约束与上下文 | 什么不能改变？ | 规则、预算、技术栈、权限、安全、文档和边界 |
π_t |
当前策略 | 采用什么路线？ | 任务拆解、技术方案、工具选择和验证方案 |
O_t |
行动与工具 | 实际做什么？ | Prompt、Skill、Agent、脚本、编辑器、测试和部署工具 |
E_t |
证据与验证 | 怎么证明结果？ | 测试、审查、类型、schema、运行结果、指标和验收记录 |
H |
固化与反馈 | 如何保存并进入下一轮？ | Git commit、版本、日志、复盘、回滚和新的差距清单 |
目标验收集合可以表示为：
A(G*, K) = 满足目标基线 G* 且不违反约束 K 的所有可接受状态
因此，收敛不要求得到唯一实现；只要系统状态进入 A(G*, K)，并通过重新验证后保持稳定，就可以认为这一轮目标已经达成。
先读取已有文档、目录、代码、配置、错误信息和运行结果，不直接假设系统是什么样。
输出应该包括：
- 已经存在什么。
- 当前能运行到什么程度。
- 已知问题和风险是什么。
- 哪些信息仍然缺失。
把“做一个功能”改成可以验收的目标：
- 输入是什么。
- 输出是什么。
- 用户能完成什么事情。
- 哪些行为必须发生。
- 哪些行为不能发生。
- 什么结果算完成。
把目标拆成当前状态尚未满足的条件，而不是马上开始写代码。
状态差距 = 目标条件 - 当前已满足条件
常见差距包括：需求差距、知识差距、代码差距、环境差距、测试差距和交付差距。
把影响决策的条件显式写出来：
- 技术栈和已有依赖。
- 文件组织和接口契约。
- 安全、隐私和权限边界。
- 时间、预算和性能要求。
- 不允许修改的内容。
- 验收、测试和回滚规则。
Prompt、AGENTS.md、项目 README、架构文档和任务清单，都是上下文控制工具。
根据差距选择最小有效动作：
- 需要理解：先阅读、解释和追踪依赖。
- 需要规划：先生成方案、任务和验收标准。
- 需要实现：让 AI 修改最小范围的文件。
- 需要验证：运行测试、检查脚本和人工审查。
- 需要复用：调用 Skill、成熟库或已有工程能力。
不要让 AI 在没有目标和边界的情况下自由扩大任务范围。
一次只推进一个可以验证的差距。每一步都应该能回答：
- 改了什么。
- 为什么这样改。
- 如何验证。
- 如果失败，回到哪一个稳定点。
“AI 说完成了”不是证据。证据应尽量来自机器或可复查记录：
- 单元测试、集成测试和端到端测试。
- 类型检查、lint、schema 和静态分析。
- 实际运行结果和用户验收。
- Git diff、提交记录和构建产物。
- 安全、依赖和供应链检查。
验证通过后，用 Git 和文档固化状态；验证失败时保留失败信息，修正上下文或行动方案，再进入下一轮。回滚不是失败，而是控制状态空间的一部分。
“低层负责做事，高层负责纠偏”可以拆成四层：
| 层级 | 负责什么 | 失败时怎么做 |
|---|---|---|
| 行动层 | 执行命令、修改文件、运行测试 | 修正当前动作或回滚当前修改 |
| 策略层 | 任务拆解、技术方案、工具和验证路线 | 切换策略，不重复无效动作 |
| 目标层 | 需求、范围、约束和验收标准 | 重新澄清目标，创建新的目标版本 |
| 治理层 | 权限、风险、预算和最终取舍 | 暂停执行、人工接管或终止任务 |
判断顺序应当是：
动作失败 → 修正动作
策略失败 → 更换策略
目标矛盾或不可行 → 审查目标
目标涉及价值取舍或无法判断 → 交给人决定
Agent 可以发现问题、提出策略和建议目标变更，但不能自行批准目标变更。目标一旦被批准为 G*，任何变化都必须通过版本、差异和授权记录下来。
一轮状态转移至少同时满足以下条件，才可以标记为完成：
- 目标基线
G*已经明确，并且没有未处理的关键冲突。 - 当前状态已经满足目标验收集合
A(G*, K)。 - 测试、运行结果或人工验收提供了可复查证据。
- 独立复核没有发现关键回归、范围漂移或安全问题。
- 目标、约束和验收标准没有被静默修改。
- 已保存 Git 检查点，并且知道失败时如何回滚。
下面情况应视为“没有进展”，而不是继续盲目重试：
- 连续若干次动作没有减少状态差距。
- 同一个错误反复出现。
- 修改越来越多，但验收结果没有改善。
- 每次修复都引入新的同等或更严重的问题。
- Agent 开始修改目标、降低标准或扩大范围来制造“通过”。
无进展时要记录尝试和失败证据，切换策略；可用策略耗尽后再审查目标。任何层级都必须设置尝试上限和退出路径，不能把“继续生成”当作默认解决方案。
Vibe Coding 没有一套全行业统一的独立分类。可以使用成熟框架分别覆盖不同问题：
| 框架 | 覆盖部分 | 对本项目的用法 |
|---|---|---|
| Design Council Double Diamond | 发现问题、定义挑战、开发方案、交付验证 | 帮助完成 R → G* → S_t → Δ_t |
| Scrum | 透明、检查、适应；迭代和增量交付 | 组织多轮小步状态转移 |
| NASA Systems Engineering | 需求、系统分解、验证与确认 | 区分“产品做对了”和“做了正确的产品” |
| NIST SSDF | 安全需求、代码审查、测试和软件供应链 | 为 E 增加安全证据 |
| DORA Continuous Delivery | 可部署状态、自动化、持续测试和快速反馈 | 让目标状态能够稳定交付和恢复 |
| PDCA | 计划、执行、检查、行动 | 解释状态转移如何持续改进 |
来源：
- Design Council：The Double Diamond
- Scrum Guide：2020 Scrum Guide
- NASA：Product Realization
- NIST：SP 800-218 Secure Software Development Framework
- DORA：Continuous Delivery
- Deming Institute：PDSA Cycle
OpenSSF 对“纯 Vibe Coding”的定义强调：不审查、不理解 AI 生成的代码，只根据结果和后续提示词继续推进。本项目采用的是更严格的工程化定义：人必须负责目标、边界和验收，AI 输出必须经过验证。
| 项目资产 | 状态转移中的作用 |
|---|---|
| 问题求解 | 识别当前状态、目标基线和状态差距 |
| Prompt | 描述一次受约束的状态转移 |
| Skill | 封装可重复使用的状态转移方法 |
| Context | 提供当前状态、约束和背景信息 |
| AI Agent | 负责分析、规划、生成和执行候选动作 |
| 工具调用 | 读写文件、运行命令、测试和部署 |
| Quality Gate | 判断状态是否进入目标验收集合 |
| Git | 保存状态快照、形成证据、支持回滚 |
| 文档 | 把上下文和决策外置，降低记忆丢失 |
| Research | 发现更好的方法、工具、约束和验证方式 |
- 观察并描述当前状态。
- 把目标写成可验收的目标状态。
- 找出结构化的状态差距。
- 明确约束、上下文和禁止项。
- 把任务拆成小步状态转移。
- 让 AI 输出计划、动作和证据，而不是只输出代码。
- 用测试、审查和运行结果验证。
- 用 Git 固化和回滚。
- 根据失败反馈修正下一轮。
- 复杂 Prompt 技巧和模型关键词。
- 各种模型排行榜和工具品牌比较。
- 多 Agent 编排和复杂 MCP 生态。
- 高级企业架构、Kubernetes 和完整合规体系。
- 还没有明确问题时的自动化和大规模重构。
这些内容不是没有价值，而是应该在基本状态转移闭环稳定后再学习。
1. 当前状态、目标基线、状态差距
2. 目标、约束、对象和验收标准
3. Context、README 和 AGENTS.md
4. Prompt 与小步任务拆解
5. Skill、工具调用和 AI 执行
6. 测试、审查、安全和质量门禁
7. Git、版本、回滚和持续交付
8. 反馈、复盘和能力沉淀
9. 多 Agent、团队治理和高级工程体系
这也是教程的推荐主线：先让学习者完成一次小型、可验证、可回滚的状态转移，再逐步增加工具、协作和治理复杂度。
项目状态会从“想法未实现”走向“可运行产品”；学习者状态也会从“不会描述和验证”走向“能够独立控制状态转移”。
因此，学习 Vibe Coding 不是记忆工具清单，而是反复练习以下能力：
看清状态
→ 定义目标
→ 识别差距
→ 固定约束
→ 选择行动
→ 执行验证
→ 固化反馈
当学习者能够在不同项目、不同技术栈和不同 AI 工具中重复这个闭环时，才真正掌握了 Vibe Coding。
AI 生成代码只是提出了候选状态，不能证明目标已经达成。必须追加测试、审查和运行验证。
目标越模糊，AI 越容易扩大范围、改变无关文件或选择不适合的实现。需要明确上下文、禁止项和验收标准。
大任务会让状态变化难以定位，失败后也难以回滚。应该拆成小步，每步形成可验证结果。
记住更多工具不会自动提升状态转移能力。先定义差距，再选择工具；不要反过来围绕工具寻找问题。
没有 Git 快照、失败记录和上下文更新，下一轮只能重新猜测。每轮重要转移都应留下可复查的状态证据。
这个模型可以统一软件开发、学习、研究、文档、自动化和团队协作中的状态转移，但它不能替代领域专业知识，也不能保证目标本身正确。
尤其在安全、医疗、金融、法律和生产系统中，目标定义、风险评估、独立审查和正式验收仍然需要领域专家参与。