Vibe Coding（氛围编程）
模型收费
|-----------------------|------------|----------------------|---------------------------|-------------------|-----------------|
| 模型 | 类型 | 费用 | 备注 | 省钱技巧 | 风险提示 |
| claude code sonnet4.6 | 包月套餐 | 20 刀 / 100 刀 / 200 刀 | 比较难的问题使用模型 因为 20 刀不够一个月使用 | 土耳其旅游办卡 低价区 | 有可能封号 |
| gpt5.5 | 包月套餐 | 20 刀 / 100 刀 | token 量稍微多一点 也不够一个月 | 苹果 id 登录 土耳其旅游 充值 | 20 刀套餐免费用一个月 |
| GLM 智谱 AI 5.1 | 包月套餐 | 49 元 | 很划算 但是不好抢 | 包季度 包年度 有优惠 | |
| 千问 3.7max | 包月套餐 | 198 元 | 企业级 | | |
| Deepseek V4 PRO | API 按量 | 平均 3 块一天 | 性价比最高 不用不花钱 | 用的少的用户 推荐使用 | 之前有思考过慢的问题 已经修复 |
学完应该认知：
什么是Vibe Coding（氛围编程）、Agentic Engineering（智能化引擎）、SDD（Spec-Driven Development 规范化驱动开发）的核心差异与适用场景
理解AI编程四阶段演进与LLM Loop工作机制，具备评估主流AI编程工具的专业判断
熟练使用Claude code完成环境配置，模型接入，项目开发，调试部署
根据任务复制度灵活选择模型，配置分层使用策略优化成本
创建自定义Skills模块与MCP配置，实现团队级认知复用与多代理协作
独立构建并部署完整Web应用，具备PRD（需求文档）编写，架构决策，代码审查的工程能力。
第一部分：AI编程基础理论
1.1 AI辅助编程全景认知
1.1.1 什么是AI辅助编程
你用自然语言描述"你想要什么"，角色从"打字员"变成"管理员"
|------------|--------------|----------------------------|
| 维度 | 传统编程 | AI 辅助编程 |
| 核心技能 | 编程语言语法、算法 | 需求描述、意图表达、结果验证 |
| 人的角色 | 代码编写者 | 需求定义者 + 结果审查者 |
| 关注点 | "怎么做"（How） | "做什么" 和 "为什么"（What & Why） |
| 学习周期 | 数月到数年 | 数天到数周 |
| 出错时 | 自己调试代码 | 用自然语言告诉 AI 去修复 |
1.1.2 AI编程的发展历程
第一阶段：智能补全时代（2020-2022）
代表产品：GitHub Copilot、TabNine
就像手机输入法的联想功能 ------ 你打了几个字，它猜你接下来要打什么。这个阶段的 AI 只能帮你补全一行或几行代码，依然需要你自己动手写大部分代码。
第二阶段：对话式编程时代（2023-2024）
代表产品：ChatGPT、Claude.aiAI、通义灵码
进化成了一个 "编程顾问"。你可以用自然语言问它 "怎么写一个排序算法"，它会给你一段完整的代码。
但问题是：你需要自己把代码复制到项目中、自己处理各种细节，AI 并不了解你的项目全貌。
第三阶段：智能体编程时代（2024 至今） ← 我们现在就在这里
代表产品：Claude Code、Cursor Agent、Qoder、Codex
这是一个质的飞跃！AI 从 "回答问题" 进化到了 "完成任务"。你告诉它 "给我的项目添加一个用户登录功能"，它会自己去读你的项目代码，自己创建需要的文件，自己写代码，自己运行测试 ------ 全程自主完成。
这就像从 "问路人"（对话式）变成了 "请了一个代驾"（智能体）------ 你只需要说目的地，它自己开车到。
第四阶段：协作工程时代（正在形成）
多个 AI 智能体组成 "团队"，各司其职 ------ 一个负责设计架构、一个负责写代码、一个负责测试、一个负责审查代码质量。人类的角色进一步上升为 "项目总监"。
1.1.3 AI是如何"理解"和"生成"代码的
Token 化：AI 怎么 "阅读" 代码
AI 不是人像一样一个字一个字地读代码，它把文本切成一个个小块，叫做 Token。
例如，Hello world会被切成Hello和world两个 Token。中文的你好世界可能被切成你好和世界两个 Token，也可能被切成更多个。
为什么这个概念重要？因为 AI 的计费和能力限制都以 Token 为单位。你发送的内容越长，消耗的 Token 越多，费用越高。
提示：简单记住这个换算关系 ------1 个 Token≈4 个英文字符≈1-2 个中文字符。一篇 1000 字的中文文章大约是 500-1000 个 Token。
上下文窗口：AI 的 "工作记忆"
上下文窗口是 AI 一次能 "记住" 的内容量。这就像你的办公桌大小 ------ 桌子越大，能同时摊开的文件越多。
|----------------------|---------------|-------------|
| 模型 | 上下文窗口 | 相当于 |
| 早期模型 | 4K Token | 一篇短文 |
| GPT-5.x/ GPT-4o 系列 | 128K+ Token | 一本小说到一套资料 |
| Claude Sonnet / Opus | 200K-1M Token | 一本厚书到一套资料 |
| Gemini Pro 系列 | 1M Token 级别 | 一个小型图书馆 |
概率生成：为什么 AI 有时会 "胡说八道"
AI 生成内容的本质是预测概率最高的下一个词 。大多数时候它预测得很准，但有时候它会 "一本正经地胡说八道"------ 这被称为 "幻觉"（Hallucination）。
例如，AI 可能信心满满地告诉你某个函数的用法，但这个函数根本不存在。这就像一个知识渊博但偶尔会编故事的朋友 ------ 大部分时候值得信赖，但关键信息你需要自己验证。
避坑：永远不要 100% 信任 AI 生成的代码。尤其是涉及数据库操作、用户认证、支付逻辑等关键代码时，一定要仔细检查。"信任但验证" 是 AI 编程的黄金法则。
1.1.4 Vibe Coding:感觉驱动的编程新范式
Vibe Coding 是 AI 大牛 Andrej Karpathy（前 OpenAI/Tesla AI 主管）在 2025 年初提出的概念。他的原话是："完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在。"
翻译成大白话就是：不要纠结代码的每一个细节，跟着感觉走，让 AI 帮你实现想法。
Vibe Coding 的核心原则
意图优先 ：先描述你想要什么效果，而不是告诉 AI 怎么写代码
快速迭代 ：不追求一次完美，拥抱 "生成 → 测试 → 修正" 的循环
信任但验证 ：相信 AI 的能力，但始终检查关键逻辑
上下文经营：持续维护和优化提供给 AI 的背景信息
Vibe Coding 适用场景
原型开发、概念验证（快速把想法变成可运行的东西）
个人项目、学习项目（试错成本低）
探索性编程（不确定最终效果，边做边看）
UI / 前端开发（可视化反馈快，容易判断好不好）
Vibe Coding 需谨慎的场景
生产环境的核心系统（银行、医疗等）
安全敏感代码（认证、加密等）
性能极致要求的场景
1.2 Agentic Engineering：工程化升级范式
1.2.1 为什么纯 Vibe Coding 在大项目中不够用
Vibe Coding 对于做小项目、快速原型非常好用，但当项目变大变复杂时，纯粹的 "跟着感觉走" 会遇到四类核心问题：
代码质量不可控：AI 可能输出可运行但结构混乱的代码，长期累积形成技术债务；
前后矛盾：多轮对话下 AI 会给出互相冲突的代码实现方案；
缺乏全局视角：AI 仅聚焦当前局部任务，无法考量改动对整体架构造成的连锁影响；
难以协作：无统一代码规范约束时，多人协作或多轮会话产出的代码风格割裂，无法合并维护。
类比说明：自建小木屋可以随性开发（Vibe Coding）；大型楼宇建设必须配套图纸、规范、质检体系，对应 Agentic Engineering（智能体工程化）。
1.2.2 什么是智能体（Agent）
在 AI 编程场景下，智能体（Agent）是能够自主完成完整任务的 AI 系统。
|------------|------------------|----------------------------|
| 维度 | 普通 AI 聊天 | 智能体（Agent） |
| 行为 | 你问一句，它答一句 | 下达目标后，自主规划、分步执行完整流程 |
| 能力 | 仅能生成文字内容 | 可读写本地文件、执行终端命令、检索代码、调用外部工具 |
| 主动性 | 被动应答用户提问 | 主动拆解任务、自主排查并解决执行问题 |
| 记忆范围 | 仅留存单次对话上下文 | 支持长期项目记忆，可持续迭代维护项目 |
| 通俗比喻 | 百科全书（只负责查阅作答） | 实习生程序员（独立接手完整开发任务） |
智能体标准工作循环：感知 → 推理 → 行动 → 反馈
Claude Code就是一个典型的编程智能体一一你告诉它"帮我添加一个用户注册功能，它会自己读懂项目代码，自己创建文件，自己写代码并运行测试。
1.2.3 智能体协作模式
当单个智能体无法承载复杂大型项目时，可部署多个智能体分工协作，逻辑类比企业团队分工，不同智能体分别承担产品、开发、测试、设计等专属职责。
模式 1：领导者 - 执行者模式（Leader-Worker）
设置 1 个 Leader 领导 Agent，负责接收整体需求、拆解任务、统筹协调；多个 Worker 执行 Agent，分别承接细分具体工作。
- 领导 Agent：接收用户需求，做任务规划与分配
- 编码 Agent：负责代码编写实现
- 测试 Agent：编写测试用例、执行测试校验
典型工具案例
Qoder 是该模式落地代表，内置指挥官 Leader、开发 Coding、研究员 Research、测试 Verify 等多角色独立 Agent 协同工作。
模式 2：管道式协作（Pipeline）
多个 Agent 按照固定先后顺序接力流转，等同于工厂流水线串行作业。
流转链路：需求分析 Agent → 架构设计 Agent → 代码实现 Agent → 测试 Agent → 部署 Agent
模式 3：对等协作（Peer-to-Peer）
全部 Agent 地位平等，互相交叉审查校验，和开发同事之间互相做代码评审（Code Review）机制一致。
|--------------|-----------------------------------|-----------------|-----------------|
| 协作模式 | 核心运行逻辑 | 类比场景 | 适用场景 |
| 领导者 - 执行者模式 | 顶层 Agent 统筹分派任务，下级 Agent 独立执行细分工作 | 公司老板分配任务给不同岗位员工 | 大型项目多模块并行开发 |
| 管道式协作 | Agent 按固定工序串行接力流转，上一环输出给到下一环 | 工厂流水线加工 | 标准化完整交付链路项目 |
| 对等协作 | 所有 Agent 平级，互相交叉审核校验 | 开发同事互相代码评审 | 需要多重校验、高可靠性代码场景 |
1.2.4 自主决策与任务分解
优秀 AI 编程智能体不会一次性输出全部代码，会仿照资深程序员思路，先规划再执行。
Plan-Act-Observe-Reflect 闭环循环
完整执行流程及示例：
Plan（规划）：梳理完整实现步骤示例：要完成登录功能，我需要做这些事......
Act（行动）：落地执行具体操作示例：先创建数据库用户表......
Observe（观察）：校验执行结果，发现问题示例：创建成功，但数据表缺少必要字段......
Reflect（反思）：定位问题并制定修正方案示例：需要修改表结构，新增邮箱字段......
回流至 Plan 环节：继续推进后续剩余步骤
任务分解原则 ------MECE
MECE（Mutually Exclusive, Collectively Exhaustive）源自管理咨询，中文释义：相互独立，完全穷尽。
相互独立：拆分后的子任务无重叠、无交叉；
完全穷尽：所有子任务合并后完整覆盖整体需求，无遗漏环节。
实例：拆解「构建一个博客系统」
用户系统（注册、登录、个人资料管理）
文章系统（创建、编辑、删除、列表展示）
评论系统（发表、删除、回复评论）
分类标签（创建分类、打标签、按分类筛选）
部署上线（打包、服务器配置、域名绑定）
该拆分满足：5 个子任务互不重叠，且完整覆盖博客全部功能范围。
1.3 规范驱动开发 SDD（Specification-Driven Development）
1.3.1 为什么 AI 编程需要 "规范"
你有没有过这种经历：在淘宝买衣服时，你描述 "我要一件好看的衣服"，结果收到的和你想的完全不一样？这就是沟通不精准导致的。
AI 编程也是一样。如果你告诉 AI"帮我做一个网站"，它可能做出一个和你期望完全不同的东西。"垃圾进，垃圾出"------ 模糊的需求必然导致不准确的结果。
规范（Specification）就是你和 AI 之间的 "合同"，它明确地写清楚：
- 要做什么（功能需求）
- 怎么做（技术方案）
- 做到什么程度（质量标准）
有了这份 "合同"，AI 才能精准地理解你的意图。
1.3.2 需求规范：PRD 文档
****PRD（Product Requirements Document，产品需求文档）****描述的是 "要做什么"。
用户故事（User Story）格式：
作为一个 角色，我希望 功能，以便 价值 / 目的。
例如：作为一个博客读者，我希望能按标签筛选文章，以便快速找到我感兴趣的内容。
验收标准（Acceptance Criteria）格式：
Given（前提条件）：系统中有 20 篇文章，其中 5 篇标记了 "Python" 标签
When（操作）：用户点击 "Python" 标签
Then（预期结果）：页面只显示这 5 篇标记了 "Python" 标签的文章
用 AI 辅助生成 PRD 的 Prompt：
这是一个非常实用的技巧 ------ 你可以让 AI 帮你把模糊的想法变成结构化的需求文档：
我想做一个个人书签管理工具。
请帮我生成一份完整的 PRD 文档，包含：
- 项目概述（一句话描述）
- 目标用户
- 核心功能列表（按优先级排列：Must Have / Should Have / Nice to Have）
- 每个功能的用户故事和验收标准
- 非功能需求（性能、安全、兼容性）
1.3.3 技术规范：SPEC 文档
SPEC（Technical Specification，技术规范文档）描述的是 "怎么做"。
一个完整的 SPEC 文档包含：
|------------|------------|------------------------------|
| 模块 | 内容 | 说明 |
| 系统架构 | 整体架构设计图 | 前后端如何交互 |
| 技术选型 | 使用什么技术和框架 | 比如 Next.js + Prisma + SQLite |
| 数据模型 | 数据库表结构设计 | 有哪些表、每个表有哪些字段 |
| API 接口 | 接口定义 | 每个 API 的 URL、请求参数、返回格式 |
| 目录结构 | 项目文件组织 | 代码放在哪个文件夹 |
让 AI 从 PRD 自动生成 SPEC 的 Prompt：
粘贴你的 PRD 内容
要求：
- 推荐技术选型并说明理由
- 设计完整的数据模型（包含字段类型和关系）
- 列出所有 API 接口（RESTful 风格）
- 给出建议的项目目录结构
1.3.4 质量规范
质量规范定义了 "做到什么程度算合格"：
编码规范：代码风格统一、命名规则、注释要求
测试规范：需要覆盖哪些测试场景
安全规范：输入验证、认证授权、数据保护
提示：对于初学者来说，不需要一开始就写完美的规范文档。从简单的 PRD 开始，随着项目变复杂再逐步完善。规范的核心价值在于 ------ 让你和 AI 的沟通更精准。
1.3.5 规范文件的组织与管理
建议在项目根目录下创建一个 specs/ 文件夹，统一管理规范文件：
my-project/
├─ specs/
├ ├─ PRD.md # 产品需求文档
├ ├─ SPEC.md # 技术规范
├ ├─ ARCHITECTURE.md # 架构设计
├ ├─API.md # API 接口文档
├─ src/ # 源代码
├─ CLAUDE.md # 给 Claude Code 的项目说明（详见第二部分）
├─package.json
规范文件最大的价值之一是 ------ 可以直接作为 AI 工具的上下文输入。当你把 SPEC.md 的内容提供给 Claude Code 时，它就能精准地按照你的技术方案来写代码。
1.4 主流模型系列介绍
1.4.1 大语言模型基础知识
参数量：模型的 "大脑" 大小
你可能听说过 "7B 模型"、"70B 模型" 这类说法。这里的 B 是 Billion（十亿）的缩写，指代模型参数总量。简单理解：参数越多，模型越 "聪明"，但响应速度越慢、调用成本越高。
|--------------|----------------|------------|
| 参数量级 | 能力 | 类比 |
| 1-7B | 基础对话、简单代码编写 | 小学生 |
| 7-30B | 较好的编程能力、常规逻辑推理 | 中学生 |
| 30-70B | 优秀代码编写、复杂逻辑推理 | 大学生 |
| 70B+ | 顶级代码生成、深度长链推理 | 研究生 |
提示：参数量不是评判模型能力的唯一标准。训练数据质量、训练优化方案同样关键；部分小参数模型经过精细化微调后，在专属垂直任务上效果可以媲美大参数量模型。
上下文窗口：AI 编程核心概念重申
对 AI 编程场景而言，上下文窗口直接决定 AI 能读取项目内多少代码内容。窗口容量越大，AI 对整体项目架构理解越完整，代码生成准确率越高。
4K Token ≈ 单个代码文件 → 仅能读取当前打开文件
32K Token ≈ 数个关联文件 → 可读取业务相关多个配套文件
128K Token ≈ 小型完整项目 → 能够理解整个小项目全貌
200K Token ≈ 中型完整项目 → 多数主流长上下文模型的标准上限
1M Token ≈ 大型完整项目 → Claude、Gemini、GPT 等旗舰模型超长上下文规格
Token 计费：你的 "油费"
使用 AI 模型就像开车需要加油 ------ Token 就是你的 "油"，用多少付多少。
费用 = 输入 Token 数 × 输入单价 + 输出 Token 数 × 输出单价
Temperature：AI 的 "创造性开关"
Temperature 是一个 0-1 之间的参数，控制 AI 回复的 "随机性"：
Temperature = 0：每次给出几乎相同的答案（最确定性）→ 适合代码生成
Temperature = 1：每次答案都不同（最随机）→ 适合创意写作
提示：编写代码时，通常不需要手动调整 Temperature。Claude Code 默认使用适合编程的低 Temperature 值。
1.4.2 Claude 系列（Anthropic）
Claude 是本教程推荐的主力模型，由 Anthropic 公司开发。
|-------------------|-------------|------------|--------------|--------------|--------------|--------------|
| 模型 | 上下文 | 速度 | 代码能力 | 推理能力 | 费用档位 | 关键特点 |
| Claude Haiku 4.5 | 200K | 极快 | 良好 | 中等 | | 轻量任务、批处理、低成本 |
| Claude Sonnet 4.6 | 1M | 快 | 优秀 | 强 | | 日常开发主力，性价比高 |
| Claude Opus 4.7 | 1M | 中等 | 顶级 | 极强 | $$ | 复杂规划、架构和疑难问题 |
核心优势：
- 超长上下文（200K 到 1M，随模型不同而变化），项目级代码理解能力强
- 代码生成质量在业界领先
- 指令遵循能力精确（你说什么，它就做什么）
- 安全对齐好（不容易生成危险代码）
1.4.3 GPT 系列（OpenAI）
|---------------------|------------|-----------------|----------------|
| 模型 | 定位 | 特点 | 适用场景 |
| GPT-5.5 | 最新旗舰 | 推理、编程、多模态综合能力最强 | 复杂开发、架构设计、疑难调试 |
| GPT-5.x mini / nano | 轻量模型 | 速度快、成本低 | 简单任务、批量处理 |
| o 系列推理模型 | 深度推理 | 强化数学、算法、复杂推理 | 算法题、复杂约束问题 |
核心优势：多模态能力强、工具调用生态成熟，和 Codex / ChatGPT / OpenAI API 的集成最完整。适合场景：将 UI 截图转换为代码、需要视觉理解的任务。
1.4.4 GLM 系列（智谱 AI） -清华大学
智谱 AI 的 GLM 系列（配套 CodeGeex 代码助手），中文能力和代码能力均衡，国内可用。
|-------------|--------------------|--------------------------|
| 模型 | 特点 | 在 cc 中的角色 |
| GLM-4.7 | 智谱当前默认主力模型，代码与推理均衡 | 默认占用 Opus / Sonnet 槽位 |
| GLM-4.5-Air | 轻量、高速 | 默认占用 Haiku 槽位 |
| GLM-5.1 | 高阶推理模型，能力更强 | 需手动覆盖三个槽位才会启用，高峰期算 3 倍消耗 |
1.4.5 DeepSeek 系列 国内推荐
|-----------------------|-------------------------------------|---------------------------------|
| 模型 | 特点 | 适用场景 |
| deepseek-v4-pro1m | DeepSeek 官方 Claude Code 接入示例使用的主力模型 | 通过 Anthropic 兼容端点接入 Claude Code |
| deepseek-v4-flash | 轻量高速模型 | 适合 Haiku / Subagent 等轻量槽位 |
核心优势：
- 极致性价比：价格远低于官方 Claude
- 代码能力强，接近 Claude Sonnet 水平
- 国内直连，注册简单
- 官方为 Claude Code 提供了专用的Anthropic 兼容端点，适配度高
1.4.6 通义千问系列（阿里云）
|-----------------------------|------------|--------------|
| 模型 | 特点 | 适用场景 |
| Qwen-Plus / Qwen-Max | 均衡性能、中文优化 | 中文项目的日常开发 |
| Qwen3-Coder / Qwen-Coder 系列 | 代码专精 | 纯编程任务、代码生成 |
核心优势：中文理解能力出色、国内直连、阿里云生态集成。
1.4.7 其他值得关注的模型
|--------------------|-------------|------------|-------------|
| 模型 | 开发者 | 特点 | 场景 |
| Gemini Pro 系列 | Google | 超大上下文、多模态 | 超长代码库分析 |
| Kimi / Moonshot 系列 | 月之暗面 | 长上下文、中文好 | 中文长文档处理 |
| Llama 系列 | Meta | 开源旗舰、可本地部署 | 离线 / 隐私敏感场景 |
| Mistral 系列 | Mistral AI | 欧洲开源、代码能力强 | 本地部署替代方案 |
1.4.8 模型选型实战指南
1.4.8.1 选型决策树
面对一个编程任务时，按以下流程选择模型：
你的任务是什么？
简单任务（代码补全、格式化、小修改）
- 追求最快速度 → Claude Haiku / GLM-4.5-Air / 本地 Qwen
- 追求最低成本 → DeepSeek API / 本地 Ollama
- 完全免费 → 本地 Ollama 模型
日常开发（功能实现、Bug 修复、代码生成）
- 英文项目 → Claude Sonnet（首选）
- 中文项目 → Claude Sonnet 或 通义千问 / GLM-4.7
- 预算紧张 → DeepSeek V4 / GLM / Kimi
复杂任务（架构设计、算法难题、疑难 Bug）
- 深度推理 → Claude Opus / GPT-5.5 / DeepSeek V4 Pro
- 超长代码库 → Gemini Pro（1M 上下文）
特殊场景
- 离线 / 隐私要求 → 本地 Ollama + Llama/Qwen
- 截图转代码 → GPT-5.5 / GPT-4o 系列（多模态）
- 国内直连要求 → DeepSeek / 千问 / GLM
1.4.8.2 成本优化策略
策略一：分层使用
简单任务 ------ Haiku / GLM-4.5-Air / 本地 Qwen（成本：$）
日常任务 ------ Sonnet / DeepSeek V4 Pro（成本：$$）
复杂任务 ------ Opus / GLM-5.1（成本：$$$）
不要所有任务都用最贵的模型，就像不是每次出门都需要打专车。
策略二：Prompt Cache（缓存利用）
Claude 和 GPT 都支持 Prompt Cache ------ 如果你发送的上下文中有大量重复内容（如每次都发送同一个 CLAUDE.md），后续请求可以复用缓存，显著降低重复上下文的输入成本。
策略三：本地模型补充
对于简单的代码格式化、注释生成等任务，可以使用 Ollama 部署的本地模型，完全免费。
|---------------|---------------------------|----------------------|
| 使用强度 | 推荐模型 | 月费用估算 |
| 轻度（每天 1-2 小时） | DeepSeek API / GLM / Kimi | ¥5-30（视模型与套餐） |
| 轻度 | Claude Sonnet | 10-30（约 ¥70-210） |
| 中度（每天 3-5 小时） | Claude Sonnet | 30-80（约 ¥210-560） |
| 重度（全天使用） | Claude Sonnet + Haiku | $80-200（约 ¥560-1400） |
1.4.9 安全与隐私考量
|----------------------|--------------|--------------|
| 方案 | 数据隐私 | 适用场景 |
| 云端 API（Claude/GPT 等） | 数据经过服务商服务器 | 一般项目、学习项目 |
| 本地部署（Ollama） | 数据不出本机 | 企业敏感代码、隐私要求高 |
1.5 本部分小结
核心概念回顾
|---------------------|-----------------------------------------|
| 概念 | 一句话解释 |
| AI 辅助编程 | 用自然语言指挥 AI 写代码，人类从 "写代码" 变成 "指挥 AI 写代码" |
| Vibe Coding | 跟着感觉走的编程方式，适合快速原型和小项目 |
| Agentic Engineering | 系统化的 AI 驱动开发方法，适合大型项目 |
| Agent（智能体） | 能自主规划、执行、验证任务的 AI 系统 |
| SDD（规范驱动开发） | 先写规范（PRD/SPEC），再让 AI 按规范执行 |
| PRD | 产品需求文档，描述 "做什么" |
| SPEC | 技术规范文档，描述 "怎么做" |
三者的关系
Vibe Coding（感觉驱动）
↓ 项目变大、需要更多控制
Agentic Engineering（系统化方法）
↓ 需要精准的沟通 "合同"
SDD（规范驱动开发）