[aide] impl: 子计划2&3完成:修改 run 命令集成 skill 触发和强化流程图规范
This commit is contained in:
@@ -52,7 +52,25 @@ aide config get task.source
|
||||
|
||||
读取任务文档内容。如文档不存在,询问用户提供任务内容。
|
||||
|
||||
#### 1.3 任务分析
|
||||
#### 1.3 口语化内容检测
|
||||
|
||||
检查任务文档或用户对话是否具有以下口语化特征:
|
||||
|
||||
- 使用非正式的口头表达方式
|
||||
- 包含大量模糊表述("我觉得"、"好像"、"大概"、"应该"等)
|
||||
- 句子结构松散,缺乏条理性
|
||||
- 包含冗余或重复的表达
|
||||
- 思维跳跃,逻辑不连贯
|
||||
|
||||
**如果检测到口语化特征**:
|
||||
|
||||
1. 触发 `task-parser` skill 学习口语化内容解析方法
|
||||
2. 按照 skill 指南对内容进行深度理解和规范化转换
|
||||
3. 将转换后的结构化内容作为后续分析的基础
|
||||
|
||||
> 即使内容部分口语化,也应进行解析,提取核心意图
|
||||
|
||||
#### 1.4 任务分析
|
||||
|
||||
##### 深度理解任务
|
||||
|
||||
@@ -68,14 +86,14 @@ aide config get task.source
|
||||
|
||||
> 复杂任务(多子目标、多方案对比)建议使用 sequential-thinking 进行结构化分析
|
||||
|
||||
#### 1.4 复杂度评估
|
||||
#### 1.5 复杂度评估
|
||||
|
||||
根据**任务复杂度评估指导原则**(见附录)评估任务复杂度:
|
||||
|
||||
- **简单/中等任务**:直接生成任务细则
|
||||
- **复杂/超大任务**:拆分为多个子计划
|
||||
|
||||
#### 1.5 任务优化
|
||||
#### 1.6 任务优化
|
||||
|
||||
##### 准确性优化
|
||||
|
||||
@@ -98,7 +116,7 @@ aide config get task.source
|
||||
|
||||
对于存在多种方案、有歧义、需要用户确认的内容,准备待定项数据。
|
||||
|
||||
#### 1.6 待定项处理(如有)
|
||||
#### 1.7 待定项处理(如有)
|
||||
|
||||
```bash
|
||||
aide decide submit .aide/pending-items.json
|
||||
@@ -106,7 +124,7 @@ aide decide submit .aide/pending-items.json
|
||||
aide decide result
|
||||
```
|
||||
|
||||
#### 1.7 生成任务细则
|
||||
#### 1.8 生成任务细则
|
||||
|
||||
产出任务细则文档,保存到配置的路径。
|
||||
|
||||
@@ -134,6 +152,67 @@ aide flow next-part flow-design "进入流程设计环节"
|
||||
aide config get flow.diagram_path
|
||||
```
|
||||
|
||||
##### 流程图类型
|
||||
|
||||
根据任务类型,需要创建不同类型的流程图:
|
||||
|
||||
| 类型 | 适用场景 | 必需性 |
|
||||
|------|----------|--------|
|
||||
| 任务执行流程图 | 所有任务 | **必需** |
|
||||
| 程序逻辑流图 | 含程序设计与代码编写的任务 | **必需** |
|
||||
|
||||
##### 任务执行流程图规范
|
||||
|
||||
展示任务执行的步骤顺序:
|
||||
|
||||
- **步骤分解**:将任务分解为具体的执行步骤
|
||||
- **顺序关系**:明确步骤之间的先后顺序
|
||||
- **决策点**:标注关键决策点和分支条件
|
||||
- **依赖关系**:体现步骤之间的依赖
|
||||
|
||||
##### 程序逻辑流图规范
|
||||
|
||||
展示程序代码的执行逻辑(仅限程序类任务):
|
||||
|
||||
- **入口点**:从程序入口函数(如 main、\_\_main\_\_)开始
|
||||
- **控制结构**:体现顺序、分支(if/switch)、循环(for/while)结构
|
||||
- **语义化抽象**:将代码逻辑抽象为人类可理解的业务描述,而非代码细节
|
||||
- **模块化表示**:
|
||||
- 函数/模块表示为"盒子"
|
||||
- 标注预期输入和输出
|
||||
- 复杂函数可单独绘制详图
|
||||
- **层次化组织**:
|
||||
- 主流程图展示程序整体执行流
|
||||
- 关键子系统/模块可单独绘制详细流程图
|
||||
- 通过引用关联主图与详图
|
||||
|
||||
> **为什么需要程序逻辑流图**:
|
||||
> - 用户可以通过流程图快速理解程序的执行逻辑
|
||||
> - 在流程图阶段发现业务逻辑错误,避免实现后才发现方向错误
|
||||
> - 比逐行审阅代码更高效
|
||||
|
||||
##### 流程图示例结构
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
' 主程序流程图
|
||||
start
|
||||
:初始化配置;
|
||||
:解析命令行参数;
|
||||
|
||||
if (参数有效?) then (是)
|
||||
:调用处理模块;
|
||||
note right: 详见 process-module.puml
|
||||
else (否)
|
||||
:显示错误信息;
|
||||
stop
|
||||
endif
|
||||
|
||||
:输出结果;
|
||||
stop
|
||||
@enduml
|
||||
```
|
||||
|
||||
**所有任务必须有流程图**,用于:
|
||||
- 规范化思考
|
||||
- 方便用户审阅
|
||||
|
||||
Reference in New Issue
Block a user