用 Augment Code 完成一次规格—计划—执行的三阶段 Vibe Coding

Vibe Coding 指的是这样一种开发方式：开发者用自然语言描述意图，由 AI 助手生成、修改或重构代码，而不是逐行手写。Augment Code 属于这一类工具中偏重「整库理解」的一档——它会索引整个项目，让 AI 在跨文件关系的基础上给出建议，并通过 Agent 执行多文件编辑。这篇教程要教会你的是一件具体的事：用 Augment Code 的 /specify、/plan、/tasks 三阶段流程，把一句自然语言需求变成可审阅、可回滚的多文件改动。适合刚接触 AI 编程、想先建立正确工作习惯的初学者；如果你已经在用单行补全类工具，也能从这里的流程设计里拿到可迁移的做法。站内另有一份工具条目可供对照：Augment Code。

需要先说明一点：Vibe Coding 降低的是「写」的门槛，不是「判断」的门槛。AI 可以生成能编译的代码，但架构一致性、边界条件、测试覆盖仍然要人来把关。下面所有步骤都围绕这个前提展开。

准备工作

编辑器与扩展

Augment Code 以 IDE 扩展的形式提供，官方列出的集成包括 VS Code、JetBrains 系列、Vim 和 Neovim。本教程以 VS Code 为主线，其他编辑器请按各自扩展市场的说明安装。

如果机器上还没有 VS Code，先安装它。VS Code 免费，也是各类 AI 编程助手的常用宿主环境。

账号与套餐

扩展装好之后需要登录账号。Augment Code 提供多个套餐层级，其中 Community 套餐对个人开发者足够用，Developer 与 Enterprise 层级提供更高的额度与能力。免费层级通常在对话次数或使用量上存在限制，达到上限后需要付费。

具体的套餐名称、价格、额度与各地区的可用情况会随时间调整，请以官网当前信息为准，不要依据任何二手文章里的数字做决策。本教程的流程在 Community 套餐下即可完整走通。

网络与项目条件

Augment Code 的部分工作流依赖云端服务与已认证的账号，因此通常需要联网使用。另外，由于它的核心能力建立在整库索引之上，请准备一个结构相对完整的项目目录，而不是几个散落的脚本文件——索引质量直接决定后续建议的准确度。

动手前的心理准备

建议在开始前确认项目处于版本控制之下，并且工作区是干净的。三阶段流程中的执行阶段会真实修改文件，有版本控制才能随时对比与回退。

操作步骤

第一步：安装扩展

打开 VS Code，点击侧边栏的扩展图标，或使用快捷键 Ctrl+Shift+X（macOS 上为 Cmd+Shift+X）打开扩展面板。在搜索框中输入 Augment Code，在结果中找到对应条目并点击安装。

安装完成后，侧边栏会出现 Augment Code 的入口，图标是一个字母「A」。后续的对话、规格、计划与任务都在这个面板里发起。

第二步：登录并选择套餐

在扩展内触发登录，按提示完成账号注册与套餐选择。教程场景下选择 Community 套餐即可。登录成功后扩展即处于可用状态，不需要额外配置密钥文件。

第三步：让 Augment 索引你的代码库

扩展安装并登录后，会自动扫描当前打开的项目，不需要手动上传文件。它的 Context Engine 会读取项目中的文件、依赖关系与目录结构，建立索引，从而在后续对话中给出贴合本项目的建议。

这一步没有需要你点击的「开始索引」按钮，但有一个实践要点：在索引充分建立之前不要急着提复杂需求。如果项目较大，先让编辑器保持打开一段时间，再开始提问。索引不完整时，AI 对项目结构的判断会失准，生成的代码容易与既有约定冲突。

第四步：打开对话面板，先做一次小请求

点击侧边栏的「A」图标打开 Augment Code 面板，在输入框中用自然语言描述任务，例如「给应用加一个登录表单」。这是最直接的用法，适合验证环境是否正常。

但对初学者来说，直接跳到这种「一句话生成功能」的模式并不理想。更稳妥的做法是采用下面这套三阶段流程：先写规格，再出计划，最后执行。它把一次大改动拆成三个可检查的节点，每个节点你都有机会介入。

第五步：规格阶段 —— 用 /specify 把需求写成技术规格

三阶段流程的第一阶段是规格（Specification）。你用平实的语言说清想要什么，Augment 把它转写成一份详细的技术规格。命令形式如下：

auggie /specify "Add dark mode support to the app with user preference stored in local storage"

这条命令的含义是：为应用增加深色模式支持，并把用户偏好保存在本地存储中。注意需求里包含了两层信息——功能本身（深色模式）和约束条件（偏好持久化到 local storage）。约束写得越明确，规格阶段产出的技术规格就越贴近你的真实意图。

规格阶段的价值在于给 AI 提供足够的结构性上下文。一句「加个深色模式」在不同项目里意味着完全不同的改动范围：主题变量定义在哪、样式方案是 CSS 变量还是预处理器、切换入口放在哪个组件、持久化的键名约定是什么。规格阶段就是把这些隐含信息显式化的过程。

第六步：计划阶段 —— 用 /plan 拆出子任务

规格确定之后，进入计划（Planning）阶段。Augment 会把大任务拆解成若干子任务，典型内容包括：

• 识别需要修改的文件
• 定义需要创建的函数与模块
• 确定各部分的集成点

这一步的关键在于：计划是可以审阅和调整的。在进入执行之前，你应该逐条读一遍计划，确认它要改的文件确实是你预期的那几个，要新建的模块没有和现有结构重复，集成点选在了合理的位置。如果发现偏差，此时修正的成本远低于执行完之后再返工。

对初学者而言，计划阶段还有一个附带收益：你能从 AI 的拆解方式里学到「一个功能应该被切成哪几块」，这本身就是一种架构训练。

第七步：执行阶段 —— 用 /tasks 落地改动

计划确认后进入执行（Execution）阶段。Agent 会按照计划编辑代码、创建文件，或在项目范围内套用既有模式。这是 Augment Code 最具代表性的能力：自主完成跨文件的改动。

能力越强，越需要监督。执行阶段结束后，务必逐文件检查改动内容，而不是看到「完成」就继续下一个需求。执行阶段的具体命令与参数形式请以扩展内当前提供的用法为准。

一个完整示例

下面用一个最小但完整的场景走通全流程：给一个已有的前端应用增加深色模式，并把用户选择持久化。

场景设定

假设项目是一个已经能正常运行的前端应用，有既定的样式方案和组件目录结构，工作区干净、已纳入版本控制。目标需求一句话：

为应用增加深色模式支持，用户偏好保存在本地存储中。

阶段一：生成规格

auggie /specify "Add dark mode support to the app with user preference stored in local storage"

执行后得到一份技术规格。阅读时重点确认三件事：

• 规格里识别的样式方案是否与项目实际一致（例如它认为是 CSS 变量，而项目实际用的是别的方案）
• 持久化方式是否写成了本地存储，键名是否与项目既有命名习惯相符
• 是否遗漏了「跟随系统偏好」这类你可能想要的默认行为——如果遗漏，此时补充进需求

阶段二：生成并审阅计划

规格确认后进入计划阶段。产出的计划应当覆盖：需要修改哪些文件、需要新建哪些模块（例如主题切换组件、偏好读取工具函数）、以及这些部分在哪里接入现有代码。

审阅清单：

1. 要修改的文件列表里，有没有你完全没预料到的文件？如果有，先搞清楚为什么。
2. 要新建的模块，项目里是否已经存在功能重叠的实现？
3. 集成点是否选在了应用的最外层容器，而不是某个局部组件？
4. 子任务的顺序是否合理——先定义主题变量，再改组件，最后接切换入口。

发现问题就在这一步调整计划，不要带着疑问进入执行。

阶段三：执行并验证

计划确认后进入执行阶段，Agent 按计划完成多文件改动。执行完成后按下面的顺序验证：

1. 用版本控制工具查看本次改动的完整 diff，逐个文件过一遍。
2. 启动应用，手动切换深色与浅色模式，确认样式生效且没有残留的硬编码颜色。
3. 刷新页面，确认偏好被正确读取并恢复。
4. 清除本地存储后再刷新，确认应用能回落到合理的默认状态，而不是报错或白屏。
5. 如果项目有测试，运行一遍，确认没有破坏既有行为。

这个示例刻意选得小。它的意义不在于深色模式本身，而在于让你把「规格 → 计划 → 执行 → 验证」跑成一个闭环。等你熟悉了这个节奏，再逐步放大需求的范围。

初学者实践要点

从小请求开始

第一次提问不要要求大范围、横扫式的改动。请求越小，产出越容易审阅，迭代也越快。一个能在一屏 diff 内看完的改动，远比一次生成二十个文件更容易发现问题。

重视上下文完整性

Augment Code 的效果高度依赖它对项目结构的理解程度。在提需求之前，让它把仓库索引充分建立起来。项目结构混乱、命名随意时，索引质量也会下降，这一点在动手之前就值得整理。

始终审阅生成的代码

即使工具能完成多文件编辑，也要逐项检查改动。AI 可能引入技术债或结构上的不一致——代码能跑通，不代表它符合项目的架构约定。审阅不是对工具的不信任，而是这套工作流本身的一部分。

不要放弃基本功

过度依赖是最常见的坑。初学者容易在「AI 能生成」之后跳过对基础编码原理的学习，结果是遇到 AI 也解决不了的问题时无从下手。把 AI 当作协作伙伴，而不是替代品。

注意事项

能力边界

Augment Code 的核心能力包括：理解跨文件关系的代码库感知、可执行自主改动的 Agent、面向大型仓库的上下文丰富建议、多编辑器集成、具备项目感知的对话界面，以及可一次处理数十万 token 的高上下文模型。这些能力让它区别于单行补全类工具——后者通常只在你光标附近给建议，而 Augment 会索引整个仓库并支持自主的多文件编辑。

但能力边界同样明确：Vibe Coding 并不能完全取代传统编码。AI 可以生成代码，开发者仍然需要监督、调试和测试。

常见问题

代码质量风险。AI 可能产出能编译但违反架构标准、或带来意料之外缺陷的代码。执行阶段的逐文件审阅是主要防线。

免费层级的用量限制。免费套餐在对话或使用量上可能有限制，达到上限后需要付费。具体额度与计费方式请以官网当前信息为准。

联网依赖。部分工作流依赖云服务与已认证的账号，离线环境下无法完整使用。

索引不完整导致的偏差。在索引尚未充分建立时提出复杂需求，AI 对项目结构的判断会失准，生成的代码容易与既有约定冲突。这是初学者最容易踩、也最容易避免的坑。

关于 API 类改动的补充

如果你用 Augment Code 生成或修改 API（尤其是 REST 或 GraphQL 端点），生成之后需要验证这些端点是否按预期工作。这类验证应当纳入常规流程：对 AI 生成的端点做接口测试与契约校验，确认它们在各种输入下行为正确、足够健壮，再进入后续环节。把「生成」和「验证」当成两个独立步骤，是使用这类工具时值得固定的习惯。