# 规划优先工作流 (/zh-CN/docs/verdent-for-vscode/configuration/plan-workflows)
> 为复杂任务使用 AI 辅助规划
规划优先工作流借助 **Plan Mode** 来运作，这是一种只读执行模式，Verdent 会在执行任何更改之前分析代码、开展调研并制定详细计划。该工作流将战略规划与具体实现分离开来，让你在投入代码修改之前进行审查与完善。
### 何时使用 Plan Mode [#何时使用-plan-mode]
* 需要协调的复杂多文件更改
* 对最佳实现方案不确定时
* 对生产关键代码进行高风险更改
* 在不熟悉的代码库中需要先行探索的任务
* 需要在执行前获得批准的战略规划需求
***
## AI 辅助任务拆解 [#ai-辅助任务拆解]
Verdent 通过 AI 辅助任务拆解，自动将复杂请求分解为易于管理的顺序步骤。
### 拆解流程 [#拆解流程]
Verdent 分析你的自然语言请求，以识别：
* 主要目标和预期结果
* 受影响的文件、组件或系统
* 所需的技术操作和依赖关系
* 潜在的复杂性因素
Verdent 检查你的项目结构，以理解：
* 现有架构和既定模式
* 文件组织和技术栈
* 需要修改的当前实现
Verdent 将请求拆分为逻辑子任务：
* 识别自然的分界点和实现阶段
* 按依赖关系排序任务（前置任务优先）
* 将相关操作分组
* 估算每个子任务的范围和复杂度
Verdent 可能会提出问题来完善拆解：
* “我应该修改现有的校验逻辑，还是创建一个新的校验器？”
* “你想为所有受影响的组件更新测试吗？”
* “这项更改应同时应用于 Web 和移动端组件吗？”
### 拆解特征 [#拆解特征]
* 任务规模适合 15-45 分钟的专注工作
* 为测试和验证留出自然的分界点
* 复杂到足以有意义，简单到足以执行
* 尊重依赖关系（先准备，后实现）
* 逻辑递进（数据层 → 业务逻辑 → UI）
* 在主要阶段之后进行验证步骤
计划拆解格式可通过 `plan_rules.md` 自定义，以控制：
* 详细程度（高层概览 vs 细粒度）
* 计划结构和章节
* 包含的信息（时间估算、风险、依赖关系）
***
## 计划审查与批准 [#计划审查与批准]
在 Plan Mode 中提交请求后，Verdent 会生成一份结构化计划，显示在 Chat View 中供你审查。
### 审查流程 [#审查流程]
Verdent 生成的计划包含清晰的章节、编号步骤、受影响的文件和已识别的依赖关系
审查以下方面：
* **正确性：** 该方案能否解决问题？
* **完整性：** 是否包含所有必要步骤？
* **效率：** 这是最佳方案吗？
* **风险：** 可能出什么问题？是否存在边界情况或安全隐患？
如有任何不清楚之处，请求补充信息：
```
Can you explain step 3 in more detail?
Why are we modifying both the service and controller?
What happens if the API call fails in step 5?
```
提供反馈以修订计划：
```
Let's use JWT tokens instead of OAuth2
Can we break step 4 into smaller substeps?
Add error handling considerations to the plan
```
Verdent 生成计划后，会提供两个选项：
* **Edit**：请求修改、提出澄清问题或进一步完善计划
* **Start Building**：切换到 Agent Mode 并开始执行已批准的计划
### 计划交互选项 [#计划交互选项]
审查生成的计划后，Verdent 会提供两个选项：
**Edit：**
选择此选项可以：
* 请求对计划方案进行特定更改
* 询问有关实现细节的澄清问题
* 添加缺失的要素或考虑因素
* 简化或扩展某些步骤
* 探索替代方案
这会让你留在 Plan Mode 中进行迭代式完善，而不执行任何更改。
**Start Building：**
选择此选项可以：
* 切换到 Agent Mode 并开始执行
* 以完全自主的方式实现已批准的计划
* 按计划进行文件修改并执行命令
你也可以选择：
* **手动实现**：审查计划并自行实现更改
* **增量执行**：要求 Verdent 实现特定阶段，并在各阶段之间设置检查点以供审查
使用 **Edit** 可以根据需要对计划进行任意多次迭代。只有当你确信方案正确且完整时，才选择 **Start Building**。
***
## 迭代式规划 [#迭代式规划]
用户可以通过选择 **Edit** 并提供对话式反馈，自由地修改和迭代计划。Verdent 将计划生成视为一个交互式、迭代式的过程。
### 修改方式 [#修改方式]
**请求特定更改：**
```
Change step 3 to use Redux instead of Context API
Add input validation before the database insert
Swap the order of steps 4 and 5
```
**添加缺失的要素：**
```
Add error handling for network failures
Include rollback procedures
Add performance optimization considerations
```
**简化或扩展：**
```
This is too complex - can we simplify the approach?
Break down step 5 into more detailed substeps
Give me more detail on the database schema changes
```
**探索替代方案：**
```
What if we used webhooks instead?
Show me an alternative plan using microservices architecture
Can we accomplish this without changing the database schema?
```
### 迭代流程示例 [#迭代流程示例]
```
User: "Add user authentication to the API"
[Verdent generates initial plan with JWT tokens]
User: "Actually, let's use OAuth2 instead of JWT"
[Verdent revises plan to use OAuth2]
User: "Add step for migrating existing users"
[Verdent adds migration step to plan]
User: "Can you break down the migration step more?"
[Verdent expands migration with detailed substeps]
User: Chooses **Start Building**
[Verdent switches to Agent Mode and begins execution]
```
**无限次迭代：**
* 修订次数不受限制
* 每次迭代都保留对话上下文
* 先前版本保存在聊天历史中
* 可以引用早期的计划版本：“回到第一个方案”
计划被否决是迭代式规划过程中的自然环节。它确保只执行经过批准、充分理解的策略，从而减少在错误实现上浪费的精力。
***
## 常见问题（FAQ） [#常见问题faq]
**不会。** Plan Mode 严格只读：
* Verdent 可以读取文件、搜索代码并分析你的代码库
* 在 Plan Mode 期间**不会发生任何文件写入、编辑或删除**
* 计划仅显示在 Chat View 中
* 只有在你明确批准并切换到 Agent Mode 后，代码执行才会开始
**安全保证：** Plan Mode 不会意外修改你的代码。它专为安全探索和策略制定而设计。
**可以。** 完全支持增量执行：
**增量批准模式：**
```
Let's start with Phase 1 first, then we'll review before continuing
Implement steps 1-3, then stop for review
Do the database migration first, I'll review before the API changes
```
**工作原理：**
1. Verdent 执行指定步骤
2. 在审查检查点停下
3. 你审查结果并提供反馈
4. 继续下一阶段或调整方案
5. 重复直至完成
**最适合：** 高风险更改、不熟悉的模式、以及通过分阶段推出来降低风险的生产关键代码。
增量执行让你在批准计划部分内容的同时推迟其他部分，这在任务执行中途优先级发生变化时非常有用。
**否决计划是完全正常且符合预期的：**
* Verdent 会根据你的反馈生成新计划
* 先前的计划版本保留在聊天历史中以供参考
* 不会发生任何代码更改（Plan Mode 为只读）
* 你可以无限次迭代直至满意
**常见的否决原因：**
* 方案过于复杂或过于简单
* 缺少边界情况或错误处理
* 存在更好的替代架构
* 误解了需求
**专业提示：** 否决是过程的一部分。迭代式地完善计划，胜过浪费精力去执行错误的策略。
**通过输入框即可即时切换：**
**进入 Plan Mode：**
* 点击输入框中的 **Switch Mode** 按钮
* 从下拉菜单中选择 **Plan Mode**
* 或者说：“切换到 Plan Mode”
**退出 Plan Mode：**
* 点击输入框中的 **Switch Mode** 按钮
* 从下拉菜单中选择 **Agent Mode**
* 或者在审查计划后选择 **Start Building**
**模式持久性：**
* 模式选择在当前会话中保持不变
* 新会话以默认的 Agent Mode 开始
* 你可以随时自由切换模式
**典型工作流：** Plan Mode → 审查 → Agent Mode → 执行 → 返回 Plan Mode 处理下一个复杂功能。
**可以，使用 `plan_rules.md`：**
**位置：** `~/.verdent/plan_rules.md`（全局配置目录）
**你可以自定义的内容：**
* **详细程度：** 高层概览 vs 细粒度的逐步说明
* **计划结构：** 要包含的章节（摘要、风险、依赖关系、测试）
* **包含的信息：** 时间估算、文件路径、验证步骤
* **格式偏好：** 编号列表、阶段、分类
**plan\_rules.md 示例：**
```markdown
# Plan Rules
## Plan Structure
- Start with a brief summary (2-3 sentences)
- Include estimated time for each major step
- List prerequisites before implementation steps
- Identify potential risks and mitigation strategies
## Level of Detail
- Break tasks into subtasks of 15-30 minutes
- Include specific file paths for modifications
- List functions or components to create/modify
- Provide verification steps for each phase
```
**更改会立即应用**于新的 Plan Mode 会话。
**不，Plan Mode 有独立的上下文管理：**
* **Plan Mode 上下文：** 针对分析和战略思考进行优化
* **Agent Mode 上下文：** 针对执行和实现进行优化
* **好处：** 计划不会用探索性调研污染执行上下文
**为什么分离很重要：**
* Plan Mode 可以探索多种方案而不会扰乱 Agent Mode
* 被否决的计划尝试不会消耗 Agent Mode 的上下文
* 切换到执行时拥有干净的起点
**上下文重置：** 切换模式会为新的任务类型提供全新的上下文。
**澄清问题是拆解过程的一部分：**
**为什么会提出问题：**
* 模糊的需求需要澄清
* 存在多种有效方案（需要选择其一）
* 尚未指定边界情况或约束条件
* 初始请求中偏好不明确
**如何回应：**
* 用对话式语言直接回答
* 如有帮助，可提供示例
* 如果你信任 Verdent 的判断，可以说“你来决定”
* 如果不确定，可以反问
**对话示例：**
```
Verdent: "Should I modify the existing validation or create a new validator?"
You: "Create a new validator - we'll deprecate the old one later"
Verdent: [Updates plan with new validator approach]
```
**专业提示：** 问题有助于 Verdent 生成准确、相关、契合你具体需求的计划。
***
## 另请参阅 [#另请参阅]
了解有关 Plan Mode 和其他执行模式的更多信息
为 Plan Mode 编写有效的提示词