规划优先工作流
为复杂任务使用 AI 辅助规划
规划优先工作流借助 Plan Mode 来运作，这是一种只读执行模式，Verdent 会在执行任何更改之前分析代码、开展调研并制定详细计划。该工作流将战略规划与具体实现分离开来，让你在投入代码修改之前进行审查与完善。
何时使用 Plan Mode
- 需要协调的复杂多文件更改
- 对最佳实现方案不确定时
- 对生产关键代码进行高风险更改
- 在不熟悉的代码库中需要先行探索的任务
- 需要在执行前获得批准的战略规划需求
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）
Plan Mode 会真的向我的文件写入任何代码吗？
不会。 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工作原理：
- Verdent 执行指定步骤
- 在审查检查点停下
- 你审查结果并提供反馈
- 继续下一阶段或调整方案
- 重复直至完成
最适合： 高风险更改、不熟悉的模式、以及通过分阶段推出来降低风险的生产关键代码。
增量执行让你在批准计划部分内容的同时推迟其他部分，这在任务执行中途优先级发生变化时非常有用。
如果我否决了一个计划会怎样？
否决计划是完全正常且符合预期的：
- Verdent 会根据你的反馈生成新计划
- 先前的计划版本保留在聊天历史中以供参考
- 不会发生任何代码更改（Plan Mode 为只读）
- 你可以无限次迭代直至满意
常见的否决原因：
- 方案过于复杂或过于简单
- 缺少边界情况或错误处理
- 存在更好的替代架构
- 误解了需求
专业提示： 否决是过程的一部分。迭代式地完善计划，胜过浪费精力去执行错误的策略。
如何在 Plan Mode 和 Agent 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 示例：
# 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 使用与 Agent Mode 相同的上下文吗？
不，Plan Mode 有独立的上下文管理：
- Plan Mode 上下文： 针对分析和战略思考进行优化
- Agent Mode 上下文： 针对执行和实现进行优化
- 好处： 计划不会用探索性调研污染执行上下文
为什么分离很重要：
- Plan Mode 可以探索多种方案而不会扰乱 Agent Mode
- 被否决的计划尝试不会消耗 Agent Mode 的上下文
- 切换到执行时拥有干净的起点
上下文重置： 切换模式会为新的任务类型提供全新的上下文。
如果 Verdent 在规划过程中提出澄清问题怎么办？
澄清问题是拆解过程的一部分：
为什么会提出问题：
- 模糊的需求需要澄清
- 存在多种有效方案（需要选择其一）
- 尚未指定边界情况或约束条件
- 初始请求中偏好不明确
如何回应：
- 用对话式语言直接回答
- 如有帮助，可提供示例
- 如果你信任 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 生成准确、相关、契合你具体需求的计划。