talesofzes
132 lines
3.9 KiB
Markdown
132 lines
3.9 KiB
Markdown
# 02_事项任务
|
|
|
|
## 1. 模块目标
|
|
|
|
事项任务模块承接老板 AI 秘书草稿、程经理确认和手动创建事项，负责通知接收人、记录反馈、展示状态和沉淀失败原因。第一版只做轻量事项闭环，不做完整项目管理。
|
|
|
|
## 2. 第一版做什么
|
|
|
|
1. 事项可以来自 AI 草稿确认。
|
|
2. 事项可以由程经理确认复杂草稿后生成。
|
|
3. 事项可以由老板或程经理手动创建。
|
|
4. 普通员工第一版不默认给别人创建事项。
|
|
5. 事项必须有发起人、接收人、事项内容、反馈要求和状态。
|
|
6. 事项生成前必须经过人工确认。
|
|
7. 事项生成后可以创建飞书通知。
|
|
8. 接收人可以反馈：已收到、处理中、已完成、有问题。
|
|
9. 有问题反馈必须填写一句原因。
|
|
10. 发起人、程经理或有权限人员可以查看处理进度。
|
|
11. 通知失败或无人反馈的事项需要可见，但不单独做看板。
|
|
|
|
## 3. 第一版不做
|
|
|
|
1. 不做复杂项目管理系统。
|
|
2. 不做多级子任务。
|
|
3. 不做复杂审批流。
|
|
4. 不做绩效排名。
|
|
5. 不做任务依赖和甘特图。
|
|
6. 不做项目级看板。
|
|
7. 不做独立反馈看板。
|
|
8. 不从 AI 工作台结果生成事项。
|
|
|
|
## 4. 核心流程
|
|
|
|
简单事项：
|
|
|
|
```text
|
|
AI 草稿或手动输入
|
|
-> 人工确认
|
|
-> 创建 tasks
|
|
-> 创建 notifications
|
|
-> 飞书通知接收人
|
|
-> 接收人反馈
|
|
-> 更新事项状态
|
|
-> 写入 operation_logs
|
|
```
|
|
|
|
复杂事项：
|
|
|
|
```text
|
|
老板确认转程经理
|
|
-> 创建 pending_manager_confirm 事项或待确认记录
|
|
-> 给程经理发飞书提醒
|
|
-> 程经理进入平台确认、修改和分发
|
|
-> 通知接收人
|
|
-> 接收反馈
|
|
```
|
|
|
|
## 5. 数据对象
|
|
|
|
本模块主要使用：
|
|
|
|
1. `ai_drafts`
|
|
2. `tasks`
|
|
3. `notifications`
|
|
4. `feedbacks`
|
|
5. `failure_records`
|
|
6. `operation_logs`
|
|
|
|
字段以 `docs/contracts/数据对象约定.md` 为准。
|
|
|
|
## 6. 接口需求
|
|
|
|
主要接口：
|
|
|
|
1. `GET /api/tasks`
|
|
2. `POST /api/tasks`
|
|
3. `GET /api/tasks/{id}`
|
|
4. `PATCH /api/tasks/{id}`
|
|
5. `POST /api/tasks/{id}/manager-confirm`
|
|
6. `POST /api/tasks/{id}/cancel`
|
|
7. `POST /api/tasks/{id}/notify`
|
|
8. `POST /api/tasks/{id}/feedback`
|
|
|
|
接口格式以 `docs/contracts/API接口约定.md` 为准。
|
|
|
|
## 7. 权限规则
|
|
|
|
1. 老板可以创建事项。
|
|
2. 程经理可以创建和分发事项。
|
|
3. 普通员工不能给别人创建事项。
|
|
4. 接收人只能反馈自己相关事项。
|
|
5. 程经理只能确认待自己处理的复杂事项。
|
|
6. 管理员 / AI 团队可以为排查查看必要记录，但不处理业务分歧。
|
|
|
|
## 8. 状态流转
|
|
|
|
事项状态以 `docs/contracts/状态流转约定.md` 为准。核心约束：
|
|
|
|
1. 未确认事项不得通知接收人。
|
|
2. `pending_manager_confirm` 必须由程经理确认后才能进入通知流程。
|
|
3. 通知失败进入 `notify_failed`，不得假装已通知。
|
|
4. 已取消事项不能反馈、通知或补发。
|
|
5. 有问题反馈会将事项标记为 `problem`，并记录原因。
|
|
|
|
## 9. 失败和日志
|
|
|
|
必须记录：
|
|
|
|
1. 事项创建来源：AI 草稿、手动创建或程经理确认。
|
|
2. 创建、修改、取消、通知、补发、反馈操作。
|
|
3. 权限拒绝。
|
|
4. 通知失败。
|
|
5. 有问题反馈原因。
|
|
6. 人员映射缺失或接收人不明确。
|
|
|
|
## 10. 给 AI 的测试样例
|
|
|
|
1. 普通员工请求给同事创建事项，应返回权限错误。
|
|
2. 老板确认简单事项后，事项进入待通知或已通知状态。
|
|
3. 研究类事项应进入程经理确认路径。
|
|
4. 接收人反馈“有问题”但不填原因，应返回校验错误。
|
|
5. 通知失败时，事项状态不得变成已通知。
|
|
6. 已取消事项不得再次通知。
|
|
|
|
## 11. Review 重点
|
|
|
|
1. 后端是否做了权限校验，而不是只靠前端隐藏按钮。
|
|
2. 状态流转是否只走允许路径。
|
|
3. 通知失败是否留下失败记录。
|
|
4. 有问题反馈是否强制原因。
|
|
5. 是否避免把复杂项目管理能力混入第一版。
|