8.7 KiB
8.7 KiB
Aide 任务执行
你正在执行 Aide 任务执行流程。这是核心命令，整合了任务准备和任务执行。
参数
$ARGUMENTS：任务文档路径（可选）- 未传入时根据 flow 状态决定行为
前置准备
首先触发 aide skill 学习 aide 命令的使用方法。
开始
检查 flow 状态
aide flow status
根据状态决定行为：
- 无活跃任务 或 当前任务已 finish → 进入新任务流程
- 当前任务未完成 → 进入续接流程
新任务流程
阶段 1：任务准备 (task-optimize)
1.1 启动流程追踪
aide flow start task-optimize "开始任务准备: <任务简述>"
1.2 确定任务文档
# 如果传入了参数
任务文档 = $ARGUMENTS
# 如果未传入参数，使用配置默认值
aide config get task.source
读取任务文档内容。如文档不存在，询问用户提供任务内容。
1.3 口语化内容检测
检查任务文档或用户对话是否具有以下口语化特征：
- 使用非正式的口头表达方式
- 包含大量模糊表述（"我觉得"、"好像"、"大概"、"应该"等）
- 句子结构松散，缺乏条理性
- 包含冗余或重复的表达
- 思维跳跃，逻辑不连贯
如果检测到口语化特征：
- 触发
task-parserskill 学习口语化内容解析方法 - 按照 skill 指南对内容进行深度理解和规范化转换
- 将转换后的结构化内容作为后续分析的基础
即使内容部分口语化，也应进行解析，提取核心意图
1.4 任务分析
深度理解任务
- 任务要解决什么问题？
- 最终交付物是什么？
- 成功的标准是什么？
- 涉及哪些模块/系统？
- 是否有技术难点？
分析项目环境
根据需要阅读相关代码/文档，理解任务与项目现有结构的关系。
复杂任务（多子目标、多方案对比）建议使用 sequential-thinking 进行结构化分析
1.5 复杂度评估
根据任务复杂度评估指导原则（见附录）评估任务复杂度：
- 简单/中等任务：直接生成任务细则
- 复杂/超大任务：拆分为多个子计划
1.6 任务优化
准确性优化
- 识别歧义和不明确之处
- 识别隐含假设和未说明的前提
- 明确任务边界
简洁性优化
- 识别冗余表述
- 区分真冗余与必要强调
可执行性优化
- 将抽象要求转化为具体步骤
- 确保每个步骤有明确的输入、输出、验证标准
- 识别可能的替代方案
生成待定项
对于存在多种方案、有歧义、需要用户确认的内容，准备待定项数据。
1.7 待定项处理（如有）
aide decide submit .aide/pending-items.json
# 用户完成后
aide decide result
1.8 生成任务细则
产出任务细则文档，保存到配置的路径。
aide flow next-step "任务准备完成"
阶段 2：流程设计 (flow-design)
aide flow next-part flow-design "进入流程设计环节"
2.1 制定执行计划
- 具体的实现步骤
- 每个步骤的预期产出
- 潜在风险和应对方案
2.2 创建流程图
在配置的流程图目录创建 PlantUML 源文件：
aide config get flow.diagram_path
流程图类型
根据任务类型，需要创建不同类型的流程图：
| 类型 | 适用场景 | 必需性 |
|---|---|---|
| 任务执行流程图 | 所有任务 | 必需 |
| 程序逻辑流图 | 含程序设计与代码编写的任务 | 必需 |
任务执行流程图规范
展示任务执行的步骤顺序：
- 步骤分解：将任务分解为具体的执行步骤
- 顺序关系：明确步骤之间的先后顺序
- 决策点：标注关键决策点和分支条件
- 依赖关系：体现步骤之间的依赖
程序逻辑流图规范
展示程序代码的执行逻辑（仅限程序类任务）：
- 入口点：从程序入口函数（如 main、__main__）开始
- 控制结构：体现顺序、分支（if/switch）、循环（for/while）结构
- 语义化抽象：将代码逻辑抽象为人类可理解的业务描述，而非代码细节
- 模块化表示：
- 函数/模块表示为"盒子"
- 标注预期输入和输出
- 复杂函数可单独绘制详图
- 层次化组织：
- 主流程图展示程序整体执行流
- 关键子系统/模块可单独绘制详细流程图
- 通过引用关联主图与详图
为什么需要程序逻辑流图：
- 用户可以通过流程图快速理解程序的执行逻辑
- 在流程图阶段发现业务逻辑错误，避免实现后才发现方向错误
- 比逐行审阅代码更高效
流程图示例结构
@startuml
' 主程序流程图
start
:初始化配置;
:解析命令行参数;
if (参数有效?) then (是)
:调用处理模块;
note right: 详见 process-module.puml
else (否)
:显示错误信息;
stop
endif
:输出结果;
stop
@enduml
所有任务必须有流程图，用于：
- 规范化思考
- 方便用户审阅
- 早期发现逻辑错误
aide flow next-step "流程图设计完成"
2.3 进入实现环节
aide flow next-part impl "流程设计完成，进入实现环节"
aide flow 会自动校验 PlantUML 并生成 PNG
阶段 3：迭代实现 (impl)
按计划执行，每完成一个步骤：
aide flow next-step "<完成内容简述>"
遇到问题时：
aide flow issue "<一般问题>"
aide flow error "<严重错误>"
需要回退时：
aide flow back-step "<原因>"
aide flow back-part <环节名> "<原因>"
阶段 4：验证交付 (verify)
aide flow next-part verify "实现完成，进入验证环节"
- 对照任务细则验证每个成功标准
- 执行测试（如适用）
- 验证失败则回退修复
aide flow next-step "验证完成: <验证结论>"
阶段 5：文档更新 (docs)
aide flow next-part docs "验证通过，进入文档环节"
更新相关文档：
README.md（如有用户可见变更）CHANGELOG.md- 其他相关文档
aide flow next-step "文档更新完成"
阶段 6：收尾 (finish)
aide flow next-part finish "文档更新完成，进入收尾"
- 清理临时文件
- 检查遗漏的 TODO
- 向用户汇报完成情况
aide flow next-step "任务完成"
续接流程
当检测到未完成的任务时：
1. 分析当前进度
aide flow status
aide flow show <task_id>
了解：
- 当前处于哪个环节
- 已完成哪些步骤
- 最后的操作是什么
2. 载入项目认知
调用 /aide:load 的逻辑，按需载入项目文档。
3. 读取任务细则
aide config get task.spec
读取任务细则，了解任务目标和计划。
4. 继续执行
根据当前环节，从中断处继续执行。
复杂任务的子计划执行
对于拆分为多个子计划的复杂任务：
执行模式
task-optimize → [flow-design → impl → verify → docs] × N → finish
流程
- 完成 task-optimize，生成任务导览和所有子计划细则
- 对每个子计划：
- 进入 flow-design，为该子计划设计流程图
- 进入 impl，实现该子计划
- 进入 verify，验证该子计划
- 进入 docs，更新该子计划相关文档
- 标记子计划完成，更新任务导览
- 所有子计划完成后，进入 finish
子计划切换
完成一个子计划的 docs 后：
aide flow next-step "子计划 N 完成，开始子计划 N+1"
aide flow back-part flow-design "开始下一个子计划的流程设计"
附录：任务复杂度评估指导原则
评估维度
- 结构维度：模块数量、文件数量、依赖关系
- 逻辑维度：业务复杂度、状态管理、边界条件
- 集成维度：外部依赖、数据格式、兼容性
- 风险维度：技术风险、影响范围、回滚难度
复杂度等级
| 等级 | 特征 | 处理方式 |
|---|---|---|
| 简单 | 单文件或少量文件，逻辑清晰 | 直接执行 |
| 中等 | 2-4 个模块，有一定依赖 | 直接执行，注意顺序 |
| 复杂 | 5+ 模块，复杂依赖 | 拆分为子计划 |
| 超大 | 10+ 模块，全面重构 | 拆分为独立任务 |
拆分判断标准
满足以下任一条件时应拆分：
- 涉及 3 个以上独立功能模块
- 任务自然分为多个可独立交付的阶段
- 存在高风险环节，需要阶段性验证
- 存在明确的前后依赖关系
- 单次对话可能无法完成