规划和实现复杂功能
使用 IBM Bob 的 Plan 模式与 AI 编码代理一起确定范围、审查和实现复杂功能。学习如何编写规划提示、优化生成的计划以及在 Agent 模式下运行实现。
在本教程中，你将使用 Bob 的 Plan 模式为 Galaxium Travels 演示应用程序创建一个结构化的实现计划，以添加座位等级。然后你批准该计划，让 Bob 在前端、后端和数据库层实现该功能。
本教程教你如何编写有效的规划提示、审查生成的计划时要注意什么，以及如何在 Bob 编写任何代码之前迭代计划。
先决条件
为什么使用 Plan 模式
Bob 是一个自主代理。当你使用模糊的提示时，Bob 会用自己的假设填补任何空白。这些假设可能与你的意图不符，即使它们在技术上是准确的。
当你创建计划时，Bob 会生成一组 Markdown 文件，描述范围、架构决策和有序的实现步骤。由于计划与实现分离，你可以在 Bob 编写任何代码之前阅读、质疑和优化它。
设置你的环境
克隆 Galaxium Travels 演示代码。clone 命令还会检出包含你在教程中使用的代码的 bob-learning-path-branch。
git clone -b bob-learning-path-branch https://github.com/IBM/galaxium-travels在 Bob 中，点击 File，然后点击 Open Folder。
导航到你克隆的 galaxium-travels 目录并打开它。
在你的项目中初始化 Bob
在 Bob 聊天面板中运行 /init，让 Bob 创建根 AGENTS.md 文件和规则 AGENTS.md 文件。
根 AGENTS.md 文件告诉 Bob 项目的整体结构、约定和目标，以便 Bob 可以编写适合你项目的代码。没有它，Bob 每次都会从头开始，因为 Bob 是无状态的。
.bob 中的规则文件是 Bob 为其每个模式创建 AGENTS.md 的地方：Agent、Plan 和 Ask。每个模式都有一组不同的规则来指导 Bob 在该模式下的行为。
/initBob 请求创建 AGENTS.md 文件的权限。点击 Approve todo tools for task 以创建文件。
如何编写 Plan 提示
你在 Plan 模式中编写的提示成为 Bob 工作的规范。模糊的提示会产生模糊的计划。在输入之前，回答这四个问题：
- 功能做什么，不做什么？ 明确的范围可以防止 Bob 添加你没有要求的工作。
- 功能涉及哪些层？ 例如，UI、API 和数据库。
- 适用哪些约束？ 文件数量限制、命名约定、向后兼容性要求以及 Bob 应视为不可协商的任何其他内容。
- "完成"是什么样子？ 具体的验收标准。例如，"用户可以在预订期间选择 Economy、Business 或 Galaxium 等级"为 Bob 提供了明确的目标。
生成计划
使用 Plan 模式创建 Bob 在实现座位等级功能时遵循的计划。
创建计划
在输入字段中运行以下提示。该提示应用了如何编写 Plan 提示部分的范围界定原则：命名要更改的层、设置文件数量限制、排除管理仪表板并陈述验收标准。
Bob 请求使用技能工具和子代理的权限，以便它可以运行 Create plan 技能。点击 Approve skill tools for task 和 Approve subagent tools for task 以批准请求。
我想为 Galaxium Travels 添加座位等级。乘客在预订航班时应该能够选择 Economy、Business 或 Galaxium 等级。
范围：
- 更新预订 UI 以显示座位等级选择器
- 更新后端预订 API 以接受并存储所选等级
- 更新数据库架构以向 bookings 表添加 seat_class 列
- 不要添加管理仪表板更改 — 这超出范围
约束：
- 在 galaxium-travels 文件夹中创建一个名为 `plans` 的文件夹
- 不要创建超过三个计划文件
- 保持数据库更改向后兼容
完成条件：用户可以在预订期间选择座位等级，所选等级将保存并显示在其预订确认中。以下屏幕截图显示 Bob 提出澄清问题以了解你的意图。根据你编写提示的方式，你的问题可能会有所不同。回答问题，或告诉 Bob 选择最佳选项。
当 Bob 完成时，它会请求批准写入计划文件。点击 Approve edit tools for task。
Bob 将计划文件作为 Markdown 文件放置在 plans 文件夹中。你的计划文件名可能会有所不同。
/galaxium-travels/plans/seat-class-plan.md审查计划
计划文件是 Bob 构建的规范。审查位于 plans 文件夹中的计划，以了解建议的更改。
审查计划时，寻找以下内容：
- 范围匹配： 计划是否包含你要求的所有内容？是否包含你没有要求的内容？
- 模糊语言： 寻找"根据需要添加"或"适当更新"等短语。这些是未声明的假设。在批准之前用具体说明替换它们。
- 命名文件： 每个步骤都应标识它涉及的文件。如果某个步骤说"更新预订组件"而没有命名文件，请要求 Bob 更具体。
迭代计划
如果计划与你的意图不符，请要求 Bob 在同一 Plan 模式对话中修改它。你不需要重新开始。
例如，Bob 在上一步中生成的计划对每个等级的颜色或徽章不够具体。
b. Apply a distinct colour or badge per class (e.g. grey for Economy, gold for Business, cosmic-gradient for Galaxium) consistent with the existing status colour pattern要解决此问题，你运行以下提示以明确设置每个等级的颜色：
请更新计划以指定每个等级的以下颜色：
- Economy: green
- Business: gold
- Galaxium: cosmic-gradient你的计划中可能没有相同的问题。审查计划并要求 Bob 澄清你注意到的任何模糊语言或添加缺失的细节。
实现新功能
开始新对话
点击聊天界面顶部的加号以开始新对话并清除上下文窗口。
开始新对话会清除上下文窗口，这样：
- 防止早期规划讨论消耗你的令牌预算。
- 使实现上下文专注于已批准的计划。
- 降低 Bob 混淆规划和实现指令的风险。
切换到 Agent 模式
从模式选择器中选择 Agent 以切换到 Agent 模式。
构建功能
提交此提示以实现功能：
构建 plans 文件夹中的功能
@plans/@plans/ 引用引用文件夹中的所有计划，因此你不需要单独命名文件。
以下屏幕截图显示了一个示例 plans 文件夹：
Bob 提示你 Approve todo tools for task 和 Approve edit tools for task。批准两个请求。
你已在预订 UI、后端 API 和数据库中添加了座位等级支持，Economy、Business 和 Galaxium 等级选项在整个系统中得到体现。
后续步骤
在本教程中，你学习了如何编写有范围的规划提示、审查生成的计划以查找空白和模糊语言、迭代计划直到它与你的意图匹配，以及使用干净的上下文窗口实现已批准的规范。
继续学习标准化 Bob 的行为以了解如何创建自定义规则来控制 Bob 的行为。
在创建新的上下文窗口中了解 Bob 的上下文窗口如何工作，以理解为什么开始新对话可以提高实现质量。
探索添加 Bob 功能以扩展 Bob 在你的项目中可以做的事情。