> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# Task 改进建议

> **Historical idea pool / Non-normative（2026-07-15）**：本文的旧 closeResult/MRR 假设不是 current contract。有价值的问题应按 [Task System Design](/product-design/v3/tasks-feature/task-domain-lifecycle.md) 的 Outcome、verification 和 Policy 重新评估。

收集到的关于 Task 系统的改进建议，待后续迭代讨论和实现。

***

## 1. Autoclose 结果修正

**问题：** Task 被系统 Autoclose 后，如果结果判定有误（比如 AI 误判了通话意图），是否支持修改 closeResult？

**需要讨论的点：**

- 修改 closeResult 会影响后端数据和逻辑——营收归因数字需要联动重算
- 是否允许"重新打开"已关闭的 Task？还是只允许修改结果字段？
- 修改后的数据一致性：timeline 记录、Contacts 状态、Dashboard 指标是否需要回溯更新？

***

## 2. 同一会员多任务重复计算营收

**问题：** 一个会员同时触发多个 Task（如投诉 + 信用卡过期 + 取消意向），每个 Task 关闭成功后都计一次 MRR，导致同一个人的营收被重复计算。

**具体例子：**

- 第 1 周：员工联系会员处理支付失败，Task 关闭 → Payment Recovery MRR +$169
- 第 2 周：会员又说要取消，再开一个 Task 关闭 → Cancel Save MRR +$169
- 同一个月，同一个人，$169 被记了两次

**实际影响：** 一个会员同时有 3 个 Task 全部关闭成功，平台记 3 × $169 = $507 的"影响营收"，但实际只付一份月费。

**可能的方向：** 按会员去重，同一会员同一时间段内只计一次 MRR。

***

## 3. 归因系数线性化

**现状：** 归因是二元的——留满 90 天算 100%，没留满算 0%。

**问题：** "第 89 天走了完全不算"不合理。

**建议方案：** 以 3 个月（约 90 天）为满额基准，按实际留存天数线性计算归因系数：

| 实际留存      | 归因系数 |
| --------- | ---- |
| 90 天及以上   | 100% |
| 45 天      | 50%  |
| 30 天      | 33%  |
| 0 天（立即流失） | 0%   |

**公式：** `归因系数 = min(实际留存天数 / 90, 1.0)`

**好处：**

- 避免"第 89 天走了完全不算"的不合理情况
- 更真实地反映员工干预的实际价值——短暂安抚了 1 个月的会员和真正留住了 3 个月的会员，应该对应不同的归因数字
- 可以保留 90 天作为基础版本，后续根据数据调整基准天数

***

## 4. 营收归因接入真实收益数据

**现状：** 营收归因使用 Rules 页面配置的固定 MRR 单价（如 $169/月），所有会员统一计算。

**问题：** 实际场景中会员的付费金额差异很大——有人买月卡 $169，有人买年卡折算后 $99/月，有人买私教课 $300/月。固定单价无法反映真实的营收影响。

**可能的方向：**

- 通过 AI 识别通话/短信中提到的具体金额、套餐类型
- 对接 POS / 收银系统获取会员实际付费数据
- 两者结合：优先用 POS 真实数据，无数据时用 AI 从对话中提取