第一章. 核心范式与方法论

本章学习路径

1.1. Vibe Coding 的定义与边界

2025 年初，Andrej Karpathy（前特斯拉 AI 总监、OpenAI 创始成员）在社交媒体上首次提出了 “Vibe Coding” 这个概念。他描述了一种全新的编程状态：开发者不再逐行敲击代码，而是用自然语言描述意图，让 AI 生成代码，然后通过 “感觉”（Vibe）来判断结果是否正确——如果能跑就继续，不能跑就让 AI 修。

这个看似随意的描述，实际上揭示了软件开发领域正在发生的一场深刻变革。

1.1.1. 什么是 Vibe Coding

Vibe Coding 的核心定义：一种以自然语言为主要输入、以 AI 代码生成为核心引擎、以快速迭代验证为工作节奏的编程范式。

这个定义包含三个关键要素：

第一，自然语言成为一等公民。在传统编程中，我们用编程语言与计算机对话；在 Vibe Coding 中，我们用自然语言与 AI 对话，AI 再将其翻译为代码。这意味着 “表达清楚你想要什么” 的能力，第一次超越了 “知道怎么实现” 的能力。

第二，AI 承担代码生成的主要工作。开发者的角色从 “代码的生产者” 转变为 “代码的设计者和审核者”。我们不再需要记住每个 API 的参数顺序，不再需要手写样板代码（Boilerplate），这些重复性工作由 AI 完成。

第三，快速迭代取代完美规划。传统开发强调 “想清楚再动手”，Vibe Coding 则鼓励 “先让 AI 生成一版，跑起来看看，再逐步调整”。这种模式下，开发速度可以提升 3-10 倍，但也带来了新的风险——我们稍后会详细讨论。

1.1.2. Vibe Coding 与传统 Copilot 辅助编程的本质区别

很多开发者会问：我已经在用 GitHub Copilot 了，这和 Vibe Coding 有什么区别？

区别是本质性的。我们可以用一个类比来理解：

• 传统编程：你是厨师，从切菜到炒菜全程亲自操作
• Copilot 辅助编程：你是厨师，旁边有个助手帮你递刀、洗菜，但炒菜还是你来
• Vibe Coding：你是餐厅老板，告诉厨师 “我要一道酸甜口味的鱼香肉丝”，厨师（AI）负责完成，你负责试吃和反馈

下面这张图展示了三种模式在工作流程上的根本差异：

从图中可以看出几个关键差异：

控制权的转移。在传统模式和 Copilot 模式中，人类始终掌握代码的 “方向盘”——每一行代码要么是人写的，要么是人确认后才采纳的。而在 Vibe Coding 中，AI 一次性生成大段甚至整个文件的代码，人类的控制点后移到了 “验证” 和 “审查” 环节。

反馈循环的变化。Copilot 的反馈循环是 “写一行，补一行，确认一行”，颗粒度很细。Vibe Coding 的反馈循环是 “描述一个功能，生成一整块，整体验证”，颗粒度更粗，但速度更快。

技能要求的迁移。Copilot 仍然要求你具备扎实的编程基础，因为你需要判断每一次补全是否正确。Vibe Coding 则更强调 “需求表达能力” 和 “结果验证能力”——你可以不知道代码怎么写，但你必须知道代码应该做什么、做得对不对。

1.1.3. Vibe Coding 的适用场景与局限性

Vibe Coding 不是银弹。理解它的适用边界，是成熟使用这一范式的前提。

适用场景

局限场景

一个重要的认知：Vibe Coding 的价值不在于 “让不会编程的人能编程”，而在于 “让会编程的人效率倍增”。如果你完全不懂代码，你将无法判断 AI 生成的结果是否正确，也无法在出错时给出有效的修正指令。

1.1.4. 2026 年主流模型的 Vibe Coding 能力图谱

不同的 AI 模型在 Vibe Coding 场景下表现差异显著。选择正确的模型，是高效工作的基础。

Claude 4.5 Sonnet 目前是 Vibe Coding 体验最好的模型。它的代码风格最接近人类资深工程师，可读性高，很少有冗余的 “AI 味” 注释。更重要的是，它的 Artifacts 2.0 功能支持直接渲染全栈应用，所见即所得。如果你只能选一个模型作为日常主力，选它。

GPT-5.2 是深度思考的架构师。当你面对模糊的需求（比如 “设计一个支撑亿级流量的秒杀系统”），它能给出最严谨的架构方案。但它的思考时间有时过长，有时候官网因为流量过大会降智，会打断编码的心流状态，更适合用于修复 BUG 而非日常开发。

Gemini 3.0 Pro 的杀手锏是超过 1000 万 Token 的上下文窗口。当你需要接手一个文档缺失的老项目，或者进行大规模代码重构时，它能一次性读完整个代码库，这是其他模型做不到的，且 Gemini 的前端能力可谓是所有模型中训练的最强的一档，由他负责前端的样式编写绝对没问题

DeepSeek-V3 是性价比之王，API 价格仅为 GPT-5.2 的二十分之一，但编码能力已经逼近 Claude 4.5 的水平。它特别适合作为代码补全（Tab 键触发）的后台模型，以及需要大量 API 调用的自动化测试场景，更适合打零工

Qwen 2.5 Coder 是国内开发者的本地化首选。它对中文注释和国内技术栈（Spring Cloud、Vue）的理解远超欧美模型，并且可以部署在本地显卡上运行，实现代码零泄漏。

实战选型建议

1.1.5. 本节小结

本节我们建立了 Vibe Coding 的基础认知框架。

1.2. 提示词工程在代码生成中的应用

在上一节中，我们明确了 Vibe Coding 的核心是 “用自然语言描述意图”。但这里有一个关键问题：自然语言天生是模糊的，而代码必须是精确的。如何跨越这道鸿沟？

答案是 提示词工程（Prompt Engineering）——一套让 AI 准确理解你意图的方法论。

很多开发者对提示词工程存在误解，认为它就是 “学会写更长的 Prompt” 或者 “背诵一些魔法咒语”。这种理解过于表面。提示词工程的本质是 认知同步——让 AI 的思维过程与你的预期对齐。

1.2.1. Zero-shot 与 Few-shot 的选择策略

在与 AI 交互时，我们有两种基本策略：

Zero-shot（零样本）：直接描述需求，不提供任何示例。

1

请写一个函数，接收用户列表，返回年龄大于 18 岁的用户

Few-shot（少样本）：在描述需求的同时，提供一个或多个示例。

1
2
3
4
5
6

请写一个函数，接收用户列表，返回年龄大于 18 岁的用户。

参考这个类似函数的风格：
def filter_active_users(users):
    """筛选活跃用户"""
    return [u for u in users if u.is_active]

什么时候用哪种策略？这取决于任务的 模式明确度 和 风格要求。

Zero-shot 适用场景：

• 任务是通用的、模式化的（如 “写一个快速排序”）
• 你对代码风格没有特殊要求
• 你想快速获得一个可用的版本，后续再调整

Few-shot 适用场景：

• 任务涉及项目特定的业务概念（如 “根据我们的会员等级规则计算折扣”）
• 你需要 AI 遵循特定的代码风格或命名规范
• 之前的 Zero-shot 尝试没有得到满意的结果

一个实用技巧：当你发现 AI 反复生成不符合预期的代码时，不要只是重复描述需求，而是切换到 Few-shot 模式——给它一个 “正确答案” 的样本，往往比解释十遍需求更有效。

1.2.2. CoT（思维链）在复杂编程任务中的应用

当任务变得复杂时，Zero-shot 和简单的 Few-shot 都可能失效。这时候需要引入 思维链（Chain of Thought, CoT） 技术。

CoT 的核心思想是：不要让 AI 直接给出最终答案，而是要求它 展示推理过程。这就像数学考试要求 “写出解题步骤” 一样——当 AI 被迫分步思考时，它的准确率会显著提升。

不使用 CoT 的提示：

1

实现一个 LRU 缓存，支持 get 和 put 操作，时间复杂度要求 O(1)

使用 CoT 的提示：

1
2
3
4
5
6
7
8

我需要实现一个 LRU 缓存。请按以下步骤思考：

1. 首先分析 LRU 缓存的核心特性是什么
2. 然后思考要实现 O(1) 的 get 和 put，需要什么数据结构
3. 接着设计这些数据结构如何配合工作
4. 最后给出完整实现

请在每一步都写出你的思考过程。

CoT 在以下场景特别有效：

进阶技巧：自动 CoT

2026 年的主流模型（特别是 GPT-5.2）已经内置了自动 CoT 能力——当它检测到复杂任务时，会自动进入 “深度思考” 模式。但你仍然可以通过显式提示来 强制触发 或 引导方向：

1
2

这是一个复杂的问题，请不要急于给出答案。
先花时间分析问题的各个方面，考虑可能的边界情况，然后再给出你的方案。

1.2.3. 高精度伪代码的书写规范

自然语言的最大问题是 歧义。同一句话，不同的人（或 AI）可能有完全不同的理解。

考虑这个需求描述：

1

用户下单后，如果库存不足，要通知用户

这句话至少有三个歧义点：

• “下单后” 是指点击下单按钮后，还是支付成功后？
• “库存不足” 是指完全没有库存，还是库存少于订单数量？
• “通知用户” 是弹窗提示、发短信、还是发 App 推送？

为了消除歧义，我们需要一套 高精度伪代码 的书写规范。这不是真正的代码，而是一种结构化的自然语言，它比纯自然语言更精确，但比真正的代码更灵活。

高精度伪代码的五个要素

要素一：明确的输入输出

1
2
3
4
5
6

输入：
- orderRequest: 包含 userId, productId, quantity 的订单请求对象

输出：
- 成功时：返回 orderId
- 失败时：抛出 InsufficientStockException，包含当前库存数量

要素二：清晰的条件分支

1
2
3
4
5
6
7
8
9

处理逻辑：
1. 查询 productId 对应的当前库存 currentStock
2. 如果 currentStock >= quantity：
   - 扣减库存
   - 创建订单记录
   - 返回 orderId
3. 如果 currentStock < quantity：
   - 不修改任何数据
   - 抛出异常，携带 currentStock 信息

要素三：边界情况的显式声明

1
2
3
4

边界情况处理：
- 如果 productId 不存在：抛出 ProductNotFoundException
- 如果 quantity <= 0：抛出 InvalidQuantityException
- 如果并发扣减导致库存变负：回滚事务，重试整个流程（最多 3 次）

要素四：非功能性要求

1
2
3
4

约束条件：
- 整个操作必须在数据库事务中完成
- 库存扣减必须使用乐观锁或悲观锁防止超卖
- 响应时间要求：P99 < 100ms

要素五：示例数据

1
2
3
4
5

示例：
输入：{ userId: "U001", productId: "P001", quantity: 2 }
当前库存：5
预期输出：{ orderId: "O001" }
库存变化：5 -> 3

完整示例

将上述要素组合，一个高精度的需求描述应该是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

【功能】创建订单并扣减库存

【输入】
- orderRequest 对象，包含：
  - userId: 字符串，用户唯一标识
  - productId: 字符串，商品唯一标识
  - quantity: 正整数，购买数量

【输出】
- 成功：返回新创建的 orderId（字符串）
- 失败：抛出对应的业务异常

【核心逻辑】
1. 参数校验：quantity 必须 > 0，否则抛出 InvalidQuantityException
2. 查询商品：根据 productId 查询商品信息，不存在则抛出 ProductNotFoundException
3. 库存检查：获取当前库存 currentStock
4. 库存充足（currentStock >= quantity）时：
   a. 使用乐观锁扣减库存
   b. 创建订单记录（状态为"待支付"）
   c. 返回 orderId
5. 库存不足时：
   a. 抛出 InsufficientStockException，message 中包含 currentStock

【事务要求】
- 步骤 4 的 a 和 b 必须在同一个数据库事务中
- 如果乐观锁冲突，自动重试，最多 3 次

【示例】
输入：{ userId: "U001", productId: "P001", quantity: 2 }
库存：5
输出：{ orderId: "ORD-20260115-001" }
库存变为：3

当你用这种格式描述需求时，AI 生成的代码准确率会大幅提升，因为你已经帮它消除了几乎所有的歧义空间。

1.2.4. 本节小结

1.3. Context（上下文）管理策略

在上一节中，我们学习了如何写出高质量的提示词。但即使是完美的提示词，如果 AI 不了解你的项目背景，它生成的代码也很难直接使用。

这就引出了 Vibe Coding 的第二个核心技能：上下文管理。

上下文管理的本质是 信息筛选——在有限的 Token 窗口内，让 AI 获得最相关的信息，同时过滤掉噪音。这是区分 Vibe Coding 新手和高手的关键能力。

1.3.1. Token Window 的本质与限制

每个 AI 模型都有一个 上下文窗口（Context Window），它决定了模型一次能 “看到” 多少信息。你可以把它想象成 AI 的 “工作记忆”——窗口内的信息它能记住，窗口外的信息它完全不知道。

2026 年主流模型的上下文窗口

看起来很大？但在实际开发中，上下文消耗的速度远超你的想象：

一个中等复杂度的对话，轻松就能消耗 3 万 Token。如果你引用了多个文件，或者对话轮次较多，很快就会触及窗口上限。

触及上限会发生什么？

当上下文超出窗口时，模型会 静默丢弃 最早的内容。这意味着：

• 你在第一轮对话中说明的项目背景，可能已经被 “遗忘”
• 你之前让它遵循的代码规范，可能不再生效
• 它可能会生成与之前讨论矛盾的代码

更危险的是，模型不会告诉你它忘记了什么。它会表现得好像一切正常，但生成的代码却莫名其妙地偏离了预期。

1.3.2. 会话管理：何时清除、何时延续

理解了 Token 窗口的限制，我们就能制定合理的会话管理策略。

应该延续当前会话的情况

• 你正在迭代同一个功能，需要 AI 记住之前的讨论
• 你在调试一个 Bug，需要 AI 了解之前尝试过的方案
• 你在进行代码审查，需要 AI 记住整个文件的上下文

应该开启新会话的情况

• 你要开始一个完全不同的任务
• 当前会话已经进行了 20 轮以上，AI 的回复开始出现 “遗忘” 迹象
• 你发现 AI 反复犯同样的错误，可能是早期对话中的错误信息在 “污染” 它

会话污染的典型症状

当你发现这种 “记忆回退” 现象时，最有效的做法不是再次纠正，而是 开启新会话，并在开头一次性说明所有约束条件。

实用技巧：会话检查点

在长对话中，每隔 10 轮左右，主动要求 AI 总结当前的理解：

1
2
3
4

请总结一下我们目前讨论的内容：
1. 我们要实现什么功能？
2. 有哪些约束条件？
3. 目前的实现方案是什么？

如果 AI 的总结出现偏差，说明关键信息可能已经丢失，是时候考虑新建会话了。

1.3.3. 文件引用与项目级上下文构建

现代 AI 编程工具（Cursor、Windsurf、Trae）都支持将代码文件作为上下文引用。但 “能引用” 和 “会引用” 是两回事。

引用文件的三个层次

层次一：被动引用

大多数开发者停留在这个层次——打开一个文件，AI 自动将其纳入上下文。这种方式的问题是：你打开的文件不一定是 AI 需要的文件。

层次二：主动引用

通过 @file 或拖拽的方式，显式告诉 AI 需要参考哪些文件。这比被动引用更精准，但仍然是 “文件级” 的粒度。

层次三：精准引用

只引用文件中的关键片段，而不是整个文件。例如：

1
2

请参考 UserService.java 中的 createUser 方法（第 45-78 行），
实现一个类似的 createOrder 方法

这种方式能最大化利用有限的 Token 窗口。

项目级上下文的构建策略

对于大型项目，不可能把所有文件都塞进上下文。你需要构建一个 分层的上下文体系：

第一层：始终存在的上下文

这些信息应该在每次对话开始时就提供给 AI，通常通过 IDE 的 “Rules” 或 “System Prompt” 功能实现：

• 项目的技术栈和架构风格
• 命名规范和代码风格要求
• 核心的领域概念解释

第二层：按需加载的上下文

根据当前任务动态引用：

• 如果在写 Service 层，引用对应的 Repository 接口
• 如果在写 API，引用 DTO 定义和校验规则
• 如果在改 Bug，引用相关的测试用例

第三层：临时引用的上下文

只在特定对话中使用，用完即弃：

• 具体的报错堆栈
• 某个需要重构的方法
• 临时的调试日志

构建项目记忆文件

一个高效的做法是在项目根目录维护一个 AI_CONTEXT.md 文件，内容包括：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 项目 AI 上下文

## 技术栈
- 后端：Spring Boot 3.2 + MyBatis-Plus
- 前端：Vue 3 + TypeScript
- 数据库：MySQL 8.0 + Redis 7.0

## 架构约定
- Controller 只做参数校验和结果包装，不写业务逻辑
- Service 层必须定义接口，实现类以 Impl 结尾
- 所有数据库操作必须通过 Repository 层

## 命名规范
- 类名：大驼峰，如 UserService
- 方法名：小驼峰，动词开头，如 createUser
- 常量：全大写下划线，如 MAX_RETRY_COUNT

## 核心领域概念
- 租户（Tenant）：系统的顶级隔离单位，所有数据都归属于某个租户
- 工作空间（Workspace）：租户下的二级隔离，一个租户可以有多个工作空间

每次开始新会话时，将这个文件作为第一条消息发送给 AI，能显著提升代码生成的一致性。

1.3.4. 本节小结

1.4. 代码审查与技术债的 AI 治理

在前面的章节中，我们学习了如何让 AI 高效地生成代码。但这里有一个不能回避的问题：AI 生成的代码，质量到底如何？

答案是：能用，但需要人类把关。

这就引出了 Vibe Coding 时代人类开发者的新角色定位——从 “代码的生产者” 转变为 “代码的审计官”。

1.4.1. AI 时代代码审查的焦点迁移

传统的代码审查（Code Review）关注什么？

• 语法是否正确
• 命名是否规范
• 逻辑是否清晰
• 是否有明显的 Bug

这些在 AI 时代变得不那么重要了——不是因为它们不重要，而是因为 AI 在这些方面已经做得足够好。现代大模型生成的代码，语法错误率极低，命名也基本符合惯例。

那么，人类审查者应该关注什么？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

flowchart LR
    subgraph Traditional["传统审查焦点"]
        T1["语法正确性"]
        T2["命名规范"]
        T3["代码风格"]
        T4["基础逻辑"]
    end

    subgraph AI_Era["AI 时代审查焦点"]
        A1["安全漏洞"]
        A2["架构合理性"]
        A3["边界情况"]
        A4["性能隐患"]
        A5["业务语义"]
    end

    Traditional -->|"焦点迁移"| AI_Era

焦点一：安全漏洞

AI 生成的代码可能包含隐蔽的安全问题，因为它是基于公开代码训练的，而公开代码中充斥着不安全的写法。

需要重点检查：

• SQL 注入：AI 是否使用了参数化查询
• XSS 攻击：用户输入是否被正确转义
• 权限校验：是否在每个入口都验证了用户权限
• 敏感信息：是否有硬编码的密钥或密码

焦点二：架构合理性

AI 擅长解决局部问题，但不擅长全局思考。它生成的代码可能在当前文件内是完美的，但放到整个系统中却破坏了架构的一致性。

需要重点检查：

• 是否遵循了项目的分层架构
• 是否引入了不必要的依赖
• 是否与现有代码的风格一致
• 是否重复实现了已有的功能

焦点三：边界情况

AI 倾向于处理 “正常路径”（Happy Path），对异常情况的考虑往往不够周全。

需要重点检查：

• 空值处理：参数为 null 时会发生什么
• 边界值：数组为空、数字为 0 或负数时的行为
• 并发场景：多线程同时调用会出问题吗
• 资源释放：数据库连接、文件句柄是否正确关闭

焦点四：性能隐患

AI 生成的代码通常是 “能跑” 的，但不一定是 “跑得快” 的。

需要重点检查：

• 是否有 N+1 查询问题
• 循环内是否有不必要的重复计算
• 是否正确使用了缓存
• 大数据量时的时间复杂度是否可接受

焦点五：业务语义

这是 AI 最难把握的部分。它能理解代码逻辑，但不一定理解业务含义。

需要重点检查：

• 业务规则是否被正确实现
• 领域概念是否被正确使用
• 是否符合产品的预期行为

1.4.2. AI 生成代码的技术债特征

AI 生成的代码是否天生带有技术债？答案是肯定的，但这种技术债有其独特的特征。

特征一：过度防御

AI 倾向于生成 “安全” 的代码，这导致大量冗余的空值检查和异常捕获：

1
2
3
4
5
6
7
8
9
10
11
12
13

// AI 生成的典型代码
public void processOrder(Order order) {
    if (order == null) {
        throw new IllegalArgumentException("订单不能为空");
    }
    if (order.getId() == null) {
        throw new IllegalArgumentException("订单ID不能为空");
    }
    if (order.getUserId() == null) {
        throw new IllegalArgumentException("用户ID不能为空");
    }
    // ... 十几行校验后才是真正的业务逻辑
}

这些校验不是错的，但如果每个方法都这样写，代码会变得臃肿。更好的做法是在入口处统一校验，内部方法信任调用者。

特征二：命名冗余

AI 喜欢 “自解释” 的命名，但有时会过度：

1
2
3
4
5

// AI 生成
public UserResponseDTO getUserByUserIdFromDatabase(Long userId) { ... }

// 更简洁的版本
public UserDTO getUser(Long userId) { ... }

特征三：注释过度

AI 生成的代码往往带有大量 “显而易见” 的注释：

1
2
3
4
5
6
7

// 获取用户ID
Long userId = user.getId();
// 检查用户ID是否为空
if (userId == null) {
    // 如果为空，抛出异常
    throw new IllegalArgumentException("用户ID不能为空");
}

这些注释不仅没有价值，还会增加维护负担——当代码修改时，注释往往不会同步更新。

特征四：模式僵化

AI 会严格遵循它学到的 “最佳实践”，即使在不需要的场景：

1
2
3
4
5
6
7
8
9
10
11
12

// 一个简单的工具方法，AI 也要搞成完整的类
public class StringUtils {
    private StringUtils() {
        throw new UnsupportedOperationException("工具类不允许实例化");
    }

    public static boolean isEmpty(String str) {
        return str == null || str.trim().isEmpty();
    }
}

// 实际上，对于项目内部使用，一个简单的方法就够了

1.4.3. 技术债的识别与清理机制

既然 AI 生成的代码会带来技术债，我们就需要建立一套机制来定期识别和清理。

识别机制：AI 代码质检清单

在每次 AI 生成代码后，对照以下清单进行检查：

清理机制：定期重构日

建议每周或每两周安排一次 “AI 代码清理”，专门处理积累的技术债：

一个反直觉的建议

不要试图让 AI 生成 “完美” 的代码。Vibe Coding 的核心优势是速度，如果你在每一行代码上都追求完美，就失去了这个优势。

更好的策略是：

1. 让 AI 快速生成 “能用” 的代码
2. 人工审查关键的安全和架构问题
3. 定期批量清理风格层面的技术债

1.4.4. 本节小结

1.5. SOP（标准作业程序）的建立

到目前为止，我们学习了提示词工程、上下文管理、代码审查等一系列技能。但这些技能如果只是零散地使用，效率提升是有限的。

真正的高手会将这些技能 系统化，形成可复用的 标准作业程序（SOP）。

1.5.1. 为什么需要 Prompt 序列化

考虑这样一个场景：你需要实现一个 “用户注册” 功能。

新手的做法：

1

帮我写一个用户注册功能

然后 AI 生成了一堆代码，可能缺少参数校验，可能没有处理重复注册，可能密码是明文存储的。于是你开始一轮轮地补充要求：

1

加上参数校验

1

处理一下邮箱已存在的情况

1

密码要加密存储

1

还要发送验证邮件

每一轮对话，AI 都可能修改之前的代码，导致你需要反复检查整个实现。

高手的做法：

在开始之前，先规划好整个功能的实现步骤，然后按顺序执行一系列精心设计的 Prompt：

1
2
3
4
5
6

Prompt 1：设计用户注册的接口契约（输入、输出、异常）
Prompt 2：实现参数校验逻辑
Prompt 3：实现邮箱唯一性检查
Prompt 4：实现密码加密存储
Prompt 5：实现验证邮件发送
Prompt 6：整合以上步骤，生成完整代码

这种方式的优势：

• 每一步都有明确的目标，AI 的输出更可控
• 可以在每一步进行审查，及时发现问题
• 形成的 Prompt 序列可以复用到类似功能

1.5.2. 功能开发的标准化拆解方法

直接将一个大的任务交给大模型，最终得到的结果往往都会很差，又或者是缺陷，例如：给我提供一个用户注册功能

大模型怎么能够理解，用户注册的流程是什么？该如何封装？密码是否需要加密？是否需要邮件服务？这都无法靠一句话来实现，尽管现在有许多工具大模型的plan模式的确能够帮你将一句细致的词拆分为详细的流程，但流程注定是流程，流程是人去介入的，基于你业务的能力去拆分的流程往往会更为细致

如何将一个功能拆解为标准化的 Prompt 序列？这里提供一个通用的框架：

阶段一：契约设计

在写任何实现代码之前，先让 AI 帮你设计 “契约”——接口长什么样、数据结构是什么、可能抛出哪些异常。

1
2
3
4
5
6
7
8
9
10

【任务】设计用户注册功能的接口契约

【要求】
1. 定义 Controller 层的接口签名（路径、方法、参数、返回值）
2. 定义请求和响应的 DTO 结构
3. 列出所有可能的业务异常及其错误码

【约束】
- 遵循 RESTful 规范
- 错误码格式：USER_XXXX

阶段二：核心逻辑

契约确定后，再实现核心业务逻辑。这一步要明确告诉 AI 不要处理异常情况，只关注 “正常路径”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

【任务】实现用户注册的核心逻辑

【前置条件】
- 假设所有参数都已通过校验
- 假设邮箱一定是唯一的
- 假设所有外部服务都正常

【要求】
1. 创建用户记录
2. 密码使用 BCrypt 加密
3. 生成邮箱验证 Token
4. 调用邮件服务发送验证邮件
5. 返回用户ID

【参考】
- 使用阶段一定义的 DTO 结构

阶段三：异常处理

核心逻辑完成后，再补充异常处理。这种分步方式能让每一步的代码都保持简洁。

1
2
3
4
5
6
7
8
9
10
11

【任务】为用户注册功能添加异常处理

【需要处理的情况】
1. 参数校验失败（邮箱格式、密码强度）
2. 邮箱已被注册
3. 邮件服务调用失败
4. 数据库操作失败

【要求】
- 使用阶段一定义的异常类型
- 确保事务的正确回滚

阶段四：集成测试

让 AI 生成测试用例，覆盖正常路径和异常路径。

1
2
3
4
5
6
7
8
9
10
11
12

【任务】为用户注册功能编写测试用例

【覆盖场景】
1. 正常注册成功
2. 邮箱格式错误
3. 密码强度不足
4. 邮箱已存在
5. 邮件发送失败但用户创建成功（需要补偿）

【要求】
- 使用 JUnit 5 + Mockito
- 每个测试方法只测试一个场景

阶段五：代码审查

最后，让 AI 审查自己生成的代码（是的，这很有效）。

1
2
3
4
5
6
7
8
9
10

【任务】审查以下用户注册代码

【审查维度】
1. 安全性：是否有注入风险、敏感信息泄露
2. 性能：是否有 N+1 查询、不必要的循环
3. 可维护性：命名是否清晰、职责是否单一
4. 边界情况：是否处理了所有异常路径

【代码】
（粘贴之前生成的代码）

1.5.3. 可复用开发模板的设计原则

当你按照上述方法完成了几个功能的开发后，就可以将 Prompt 序列抽象为 可复用的模板。

模板设计的三个原则

原则一：参数化

将具体的业务概念替换为占位符：

1
2
3
4
5
6
7
8
9
10
11
12

【模板】CRUD 功能开发 - 阶段一：契约设计

【任务】设计 {实体名称} 的 {操作类型} 功能接口契约

【要求】
1. 定义 Controller 层的接口签名
2. 定义请求和响应的 DTO 结构
3. 列出所有可能的业务异常

【约束】
- 遵循 RESTful 规范
- 错误码格式：{模块前缀}_XXXX

使用时只需填入具体值：

• {实体名称} = 订单
• {操作类型} = 创建
• {模块前缀} = ORDER

原则二：分层

将模板分为 “通用层” 和 “业务层”：

• 通用层：适用于所有项目的基础模板（如 CRUD、认证、文件上传）
• 业务层：针对特定业务领域的模板（如电商的下单流程、金融的风控流程）

原则三：版本化

模板会随着经验积累而优化，需要进行版本管理：

1
2
3
4
5
6
7
8

templates/
├── v1/
│   ├── crud-create.md
│   └── crud-query.md
├── v2/
│   ├── crud-create.md  # 增加了缓存处理
│   └── crud-query.md   # 增加了分页优化
└── current -> v2/

1.5.4. 本节小结

1.6. Agentic Workflow（代理工作流）概念

在前面的章节中，我们讨论的都是 “人类主导” 的 AI 编程模式——人类发出指令，AI 执行，人类验证，循环往复。

但 AI 编程正在向一个新的阶段演进：Agent 模式。在这种模式下，AI 不再只是被动地响应指令，而是能够 自主规划、执行和反思。

理解这一趋势，对于把握 Vibe Coding 的未来方向至关重要。

1.6.1. 从 Chat 到 Agent 的演进

Chat 模式的局限

我们目前使用的大多数 AI 编程工具都是 Chat 模式：你说一句，AI 回一句。这种模式有几个固有的局限：

• 单轮思考：AI 只能基于当前对话生成回复，无法进行多步骤的规划
• 无法执行：AI 只能生成代码文本，无法真正运行代码、查看结果
• 无法自我修正：如果生成的代码有错误，AI 不知道，除非你告诉它

Agent 模式的突破

Agent 模式的核心是赋予 AI 三种新能力：

规划能力：Agent 能够将一个复杂的任务自动拆解为多个子任务，并规划执行顺序。

执行能力：Agent 能够调用外部工具——运行代码、读写文件、执行命令行、甚至操作浏览器。

反思能力：Agent 能够检查自己的输出，发现错误并自动修正，而不需要人类介入。

1.6.2. 规划-执行-反思循环的原理

Agent 的工作方式可以用一个循环来描述：

一个具体的例子

假设你给 Agent 一个任务：“为这个项目添加用户认证功能”。

传统 Chat 模式的处理：

• AI 一次性生成一大堆代码
• 你需要手动创建文件、粘贴代码、运行测试
• 发现问题后，你需要描述问题，AI 再生成修复代码

Agent 模式的处理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

[规划阶段]
Agent 思考：用户认证功能需要以下步骤：
1. 添加 Spring Security 依赖
2. 创建 User 实体和 Repository
3. 实现 UserDetailsService
4. 配置SecurityFilterChain
5. 创建登录和注册接口
6. 编写测试用例

[执行阶段 - 步骤1]
Agent 执行：修改 pom.xml，添加依赖
Agent 运行：mvn dependency:resolve
Agent 检查：依赖下载成功 ✓

[执行阶段 - 步骤2]
Agent 执行：创建 User.java 和 UserRepository.java
Agent 运行：mvn compile
Agent 检查：编译通过 ✓

[执行阶段 - 步骤3]
Agent 执行：创建 CustomUserDetailsService.java
Agent 运行：mvn compile
Agent 检查：编译失败 ✗
错误信息：找不到 PasswordEncoder Bean

[反思阶段]
Agent 分析：需要先配置 PasswordEncoder
Agent 调整：在步骤4之前插入 PasswordEncoder 配置

[继续执行...]

整个过程中，人类只需要在最后验收结果，中间的试错和修正都由 Agent 自动完成。

1.6.3. Agent 模式在编码工具中的体现

2026 年的主流 AI 编程工具都在向 Agent 模式演进。以下是几个典型的体现：

Cursor 的 Composer 模式

Cursor 的 Composer 不再是简单的代码生成，而是一个能够：

• 同时修改多个文件
• 自动运行测试验证修改
• 根据测试结果自动调整代码

Claude 的 Computer Use

Claude 4.5 的 Computer Use 功能允许 AI 直接操作你的计算机：

• 打开终端执行命令
• 操作 IDE 进行重构
• 打开浏览器验证前端效果

Devin 类产品的全自动开发

以 Devin 为代表的 “AI 软件工程师” 产品，能够：

• 接收一个 GitHub Issue
• 自动分析代码库
• 生成修复方案
• 提交 Pull Request
• 根据 Review 意见修改

Agent 模式的风险与边界

Agent 模式虽然强大，但也带来了新的风险：

当前阶段的建议

Agent 模式仍在快速发展中，目前的建议是：

• 简单任务：可以放心使用 Agent 模式，享受自动化带来的效率提升
• 复杂任务：使用 Agent 进行初步实现，但关键决策点仍需人工介入
• 敏感任务：暂时避免使用 Agent 模式，坚持人工主导

1.6.4. 本节小结

1.7. 本章总结与核心概念速查

本章我们系统性地探讨了 Vibe Coding 的核心范式与方法论。从 “什么是 Vibe Coding” 出发，逐步深入到提示词工程、上下文管理、代码审查、SOP 建立，最后展望了 Agent 模式的未来。

这些内容的核心目标只有一个：帮助你从 “会用 AI 工具” 进化到 “能驾驭 AI 工具”。

1.7.1. 核心概念速查表

1.7.2. 场景化速查模板

场景一：开始一个新功能的开发

1
2
3
4
5
6

【步骤】
1. 在 AI_CONTEXT.md 中确认项目背景已更新
2. 新建会话，首先发送项目上下文
3. 使用 SOP 模板的"契约设计"阶段，定义接口
4. 逐步完成核心逻辑、异常处理、测试用例
5. 使用代码审查清单进行自检

场景二：接手一个陌生的代码库

1
2
3
4
5
6

【步骤】
1. 选择 Gemini 3.0 Pro（大窗口模型）
2. 将整个代码库作为上下文引入
3. 首先询问：这个项目的整体架构是什么？
4. 然后询问：核心的业务流程有哪些？
5. 最后针对具体模块深入了解

场景三：调试一个难以复现的 Bug

1
2
3
4
5
6

【步骤】
1. 收集完整的错误日志和堆栈信息
2. 引用相关的代码文件作为上下文
3. 使用 CoT 提示：请分步骤分析这个错误可能的原因
4. 让 AI 列出所有可能的原因及其概率
5. 从最可能的原因开始逐一排查

场景四：进行大规模代码重构

1
2
3
4
5
6

【步骤】
1. 首先让 AI 分析当前代码的问题（不要直接开始重构）
2. 确认重构目标和约束条件
3. 让 AI 制定重构计划，分为多个小步骤
4. 每个步骤完成后运行测试，确保没有破坏现有功能
5. 所有步骤完成后进行整体审查

场景五：选择合适的 AI 模型

1
2
3
4
5
6

【决策树】
├── 日常功能开发 → Claude 4.5 Sonnet
├── 需要深度思考的架构问题 → GPT-5.2
├── 需要阅读大量代码/文档 → Gemini 3.0 Pro
├── 高频率的代码补全 → DeepSeek-V3
├── 涉密项目 → Qwen 2.5（本地部署）

1.7.3. 从本章到下一章

本章我们建立了 Vibe Coding 的认知框架和方法论基础。但方法论终究需要落地到实践中才能产生价值。

在接下来的章节中，我们将进入实战环节：

• 如何搭建高效的 AI 编程环境
• 如何将 SOP 应用到真实项目中
• 如何处理 AI 编程中的常见陷阱
• 如何持续优化你的 AI 协作效率

方法论是地图，实践是旅程。带着本章建立的认知框架，我们继续前进。