# 通用任务管理流程

## 目标

承接非教练型但高频的滴答清单操作，包括：

- 查询今天的任务或某段时间的任务
- 查看清单或项目
- 搜索、筛选任务
- 创建普通任务
- 更新提醒、优先级、截止时间、标签
- 标记任务完成
- 移动任务到其他清单

## 交互原则

- 查询类请求直接读取并告诉用户结果，不要把查询也变成确认流程。
- 单个明确写操作默认直接执行，执行前只用一句话说明准备做什么。
- 如果任务对象不清、范围不清，先问 1 个决定性问题，不要把字段一次性全问完。
- 完成通用任务请求后，最多补 1 条高价值建议，例如提醒缺失、优先级冲突或适合时间盒化。
- 如果用户只是要快速执行，建议压到一句可忽略的补充，不要喧宾夺主。

## 查询类请求

### 今天 / 明天 / 最近的任务

优先使用：

- `list_undone_tasks_by_time_query`
- 需要看已完成时，再补 `list_completed_tasks_by_date`

如果用户说“我今天有哪些任务”，不要只查未完成就当成全量清单；要说明当前返回的是未完成任务，或补查已完成任务。

### 指定日期范围

优先使用：

- 未完成：`list_undone_tasks_by_date`
- 已完成：`list_completed_tasks_by_date`

### 关键词搜索

优先使用：

- `search_task`

搜索到候选任务后，如果要继续改、完成、移动，优先先定位到具体任务 ID，再调用 `get_task_by_id`。

### 清单 / 项目查看

优先使用：

- 所有清单：`list_projects`
- 清单详情：`get_project_by_id`
- 清单及未完成任务：`get_project_with_undone_tasks`
- 清单内查特定任务：`get_task_in_project`

### 多条件筛选

优先使用：

- `filter_tasks`

适用于按日期、清单、优先级、标签、类型、状态的组合筛选。

## 写操作请求

所有写操作都遵守这两个原则：

1. 先用一句话告诉用户准备执行什么
2. 执行后必须回读校验，不能只汇报“已完成”

只有高风险批量动作才需要显式确认：

- 批量完成
- 批量改期
- 一次移动多条任务
- 清空式或不可逆的大范围修改

### 创建任务

优先使用：

- 单个：`create_task`
- 批量：`batch_add_tasks`

创建后立刻：

- `get_task_by_id`

必须校验：

- 标题
- 优先级
- 截止时间
- 提醒时间
- 清单归属

### 更新任务

适用于：

- 改标题
- 改优先级
- 改截止时间
- 改提醒
- 改标签

优先使用：

- `update_task`

更新后立刻：

- `get_task_by_id`

如果回读后提醒仍等于截止时间，不能说“提前提醒已设置成功”。

### 完成任务

优先使用：

- 单个任务：`complete_task`
- 批量完成清单任务：`complete_tasks_in_project`

完成后立刻：

- `get_task_by_id`

如果是重复任务，回读时只信当前实例状态，不要把历史完成记录当成本次已完成。

### 移动任务

优先使用：

- `move_task`

移动后立刻：

- `get_task_by_id`
- 或 `get_task_in_project`

不要假设 `update_task` 可以替代跨清单移动。

## 用户表达到工具的推荐映射

- “我今天有哪些任务？” -> `list_undone_tasks_by_time_query`
- “列出所有清单” -> `list_projects`
- “帮我创建一个任务” -> `create_task`
- “把这个任务标记完成” -> `complete_task`
- “把这个任务移到工作清单” -> `move_task`
- “按优先级筛一下今天未完成任务” -> `filter_tasks`
- “查一下‘买牛奶’” -> `search_task`

## 约束

- 不要发明不存在的 MCP 工具名。
- 没有回读校验前，不要向用户确认“提醒已设置成功”或“状态已同步完成”。
- 如果写操作依赖具体任务 ID，而当前只有模糊任务名，先搜索并确认目标，再执行。
- 回复先自然说明结果；只有在列表较长或变更较多时，再补短结构。