220 lines
5.0 KiB
Markdown
220 lines
5.0 KiB
Markdown
---
|
||
description: 任务准备流程。分析用户任务描述，优化表述，处理待定项，产出可执行的任务细则（task-spec.md）。
|
||
---
|
||
|
||
# Aide 任务准备
|
||
|
||
你正在执行 Aide 任务准备流程。本流程帮助用户将模糊的任务描述转化为清晰、可执行的任务细则。
|
||
|
||
## 流程概览
|
||
|
||
```
|
||
任务分析 → 任务优化 → 待定项处理 → 结果生成 → 用户确认
|
||
```
|
||
|
||
## 运行特点
|
||
|
||
- **轻量化**：不创建工作目录、不记录状态、不 git 提交
|
||
- **用户确认制**：待定项和最终结果都需要用户确认
|
||
- **可返工**：用户不满意可返回重新优化
|
||
|
||
---
|
||
|
||
## 阶段 1：任务分析
|
||
|
||
### 1.1 获取任务描述
|
||
|
||
确认任务描述来源：
|
||
- 用户已提供任务描述：直接使用
|
||
- 用户指定文件（如 `now-task.md`）：读取文件内容
|
||
- 用户未提供：询问用户任务内容
|
||
|
||
### 1.2 深度分析
|
||
|
||
对任务描述进行全面分析：
|
||
|
||
**理解核心目标**
|
||
- 任务要解决什么问题？
|
||
- 最终交付物是什么？
|
||
- 成功的标准是什么？
|
||
|
||
**识别复杂度**
|
||
- 涉及哪些模块/文件/系统？
|
||
- 是否有多个子目标？
|
||
- 是否存在技术难点？
|
||
|
||
**分析项目环境**
|
||
- 任务与项目现有结构的关系
|
||
- 是否需要了解特定代码/文档？
|
||
- 是否有相关历史实现可参考？
|
||
|
||
> 复杂任务（多子目标、多方案对比）建议使用 sequential-thinking 进行结构化分析
|
||
|
||
### 1.3 产出分析结论
|
||
|
||
在心中形成对任务的完整理解，为下一阶段做准备。
|
||
|
||
---
|
||
|
||
## 阶段 2：任务优化
|
||
|
||
### 2.1 准确性优化
|
||
|
||
- 识别任务描述中的**歧义**和**不明确之处**
|
||
- 识别**隐含假设**和**未说明的前提**
|
||
- 明确任务**边界**：哪些在范围内，哪些不在
|
||
|
||
### 2.2 简洁性优化
|
||
|
||
- 识别**冗余表述**（同一意思重复多次）
|
||
- 区分**真冗余**与**必要强调**
|
||
- 保持简洁但不丢失关键信息
|
||
|
||
### 2.3 可执行性优化
|
||
|
||
- 将抽象要求转化为**具体步骤**
|
||
- 确保每个步骤有明确的**输入、输出、验证标准**
|
||
- 考虑步骤间的**顺序和依赖关系**
|
||
- 识别可能的**替代方案**
|
||
|
||
### 2.4 生成待定项
|
||
|
||
对于以下情况，生成待定项：
|
||
- 存在**多种可行方案**需要用户选择
|
||
- 描述**有歧义**需要用户澄清
|
||
- 存在**隐含假设**需要用户确认
|
||
- 识别出**可以优化**但需要用户认可的内容
|
||
|
||
待定项数据格式：
|
||
```json
|
||
{
|
||
"task": "任务简述",
|
||
"source": "任务描述来源文件",
|
||
"items": [
|
||
{
|
||
"id": 1,
|
||
"title": "问题标题",
|
||
"location": {
|
||
"file": "now-task.md",
|
||
"start": 5,
|
||
"end": 7
|
||
},
|
||
"context": "为什么这是一个需要确认的问题",
|
||
"options": [
|
||
{
|
||
"value": "option_a",
|
||
"label": "选项A描述",
|
||
"score": 85,
|
||
"pros": ["优点1", "优点2"],
|
||
"cons": ["缺点1"]
|
||
}
|
||
],
|
||
"recommend": "option_a"
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 阶段 3：待定项处理
|
||
|
||
### 3.1 提交待定项
|
||
|
||
如果有待定项，执行：
|
||
```bash
|
||
aide decide '<json数据>'
|
||
```
|
||
|
||
程序会启动 Web 服务并输出访问链接。
|
||
|
||
### 3.2 等待用户决策
|
||
|
||
告知用户：
|
||
```
|
||
待定项已生成，请访问以下链接进行确认：
|
||
http://localhost:xxxx
|
||
|
||
完成后请告诉我，我会读取您的决策结果。
|
||
```
|
||
|
||
### 3.3 获取决策结果
|
||
|
||
用户确认完成后，执行：
|
||
```bash
|
||
aide decide result
|
||
```
|
||
|
||
读取用户的决策结果，整合到后续的任务细则中。
|
||
|
||
### 3.4 无待定项的情况
|
||
|
||
如果分析后没有待定项（任务描述已经足够清晰），直接进入下一阶段。
|
||
|
||
---
|
||
|
||
## 阶段 4：结果生成
|
||
|
||
### 4.1 生成任务细则
|
||
|
||
基于：
|
||
- 原始任务描述
|
||
- 分析优化结果
|
||
- 用户决策结果（如有）
|
||
|
||
产出 `task-spec.md`，包含：
|
||
|
||
```markdown
|
||
# 任务细则
|
||
|
||
## 任务目标
|
||
[清晰描述任务要达成的目标]
|
||
|
||
## 成功标准
|
||
[明确的、可验证的成功标准]
|
||
|
||
## 执行步骤
|
||
1. [步骤1]
|
||
- 输入：xxx
|
||
- 输出：xxx
|
||
- 验证：xxx
|
||
2. [步骤2]
|
||
...
|
||
|
||
## 技术决策
|
||
[记录已确认的技术选型和方案]
|
||
|
||
## 约束与边界
|
||
[任务范围边界、不包含的内容]
|
||
|
||
## 风险与假设
|
||
[已识别的风险和前提假设]
|
||
```
|
||
|
||
### 4.2 用户最终确认
|
||
|
||
向用户展示 `task-spec.md` 内容，询问确认：
|
||
|
||
```
|
||
任务细则已生成，请审阅上述内容。
|
||
|
||
- 如果满意，请回复"确认"，我将保存为 task-spec.md
|
||
- 如果需要修改，请说明具体问题，我会进行调整
|
||
```
|
||
|
||
### 4.3 处理用户反馈
|
||
|
||
- **用户确认**：保存 `task-spec.md`，prep 流程结束
|
||
- **用户要求修改**：根据反馈返回相应阶段重新处理
|
||
- **用户否决**：询问具体问题，必要时从分析阶段重来
|
||
|
||
---
|
||
|
||
## 注意事项
|
||
|
||
1. **不做假设**：遇到模糊需求主动询问，不要自行假设
|
||
2. **用户主导**：所有重要决策都需要用户确认
|
||
3. **保持精简**：任务细则要清晰可执行，避免冗余
|
||
4. **简体中文**：所有输出使用简体中文
|
||
5. **核心优先**：聚焦任务分析和优化本身，形式问题交给程序处理
|