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