先说结论
mail.activity.type 里的“下一活动建议/触发”，和 mail.activity.plan 里的“活动计划”，不是一回事。
一句话区分：
下一活动链，解决的是‘完成这一条之后，下一步建议做什么’；活动计划，解决的是‘围绕一个业务节点，一次性铺出一组协作动作’。
如果把两者混用，最常见的问题就是：
- 计划和触发重复生成活动
- 责任人分配混乱
- 用户以为是线性流程，结果实际是模板批量下发
一、mail.activity.plan 到底是什么
在 addons/mail/models/mail_activity_plan.py 里，计划本体非常克制：
- 适用模型
res_model - 一组模板
template_ids - 公司范围
- 是否启用
真正有业务内容的是 mail.activity.plan.template。
模板定义了：
- 活动类型
- 相对计划日期的偏移量
- 是计划日前还是计划日后
- 负责人来自“启动时指定”还是“模板预设用户”
- 默认摘要、说明和下一活动建议
所以活动计划不是“神奇自动推进器”，而是一张批量下发协作动作的清单。
二、为什么它不等于 next activity
mail.activity.type 里有两套链式能力：
suggested_next_type_idstriggered_next_type_id
这两个字段解决的是当前活动完成之后的下一步联动。
而 mail.activity.plan.template 解决的是：
- 当某个计划被应用到记录时
- 要一次性创建哪些活动
- 这些活动的截止日期如何相对基准日期偏移
- 每一步应该分给谁
也就是说：
- next activity 偏“单步完成后的后续动作”
- activity plan 偏“围绕某个场景预先布好动作网”
例如：
- 员工入职可以用活动计划，一次铺出合同、设备、培训、权限、回访
- 销售电话做完后建议“发报价”或“约会议”，这更像 next activity
三、为什么模板里要自己定义 delay，而不是直接复用活动类型
源码里模板明确写了：
- 模板自己的 delay 字段优先生效
- 活动类型上的 delay 只是类型属性，不是计划内统一排程规则
这很重要。
因为活动类型是“可复用元件”，计划模板是“具体执行剧本”。
同一个“会议”类型活动：
- 在入职计划里可能要提前 7 天安排
- 在售前推进里可能要计划日后 2 天安排
如果完全依赖活动类型自己的 delay，计划就没法表达场景差异。
四、责任人为什么会变复杂
模板里 responsible_type 有两条核心路径：
on_demand：启动计划时临时指定other：模板里预设固定用户
这说明 Odoo 认为活动计划不是只给单人用的，它本来就是跨角色协作编排工具。
常见误区是：
- 把所有步骤都写死给一个管理员
- 结果所有人都在等同一个人点完成
更合理的做法是：
- 需要现场决定的步骤，用 on demand
- 长期固定归属的步骤，用模板预设责任人
五、为什么模型兼容性会被严格检查
mail.activity.plan.template 会校验活动类型和计划的 res_model 是否兼容。
这不是多余限制，而是为了避免出现这种尴尬：
- 计划应用在项目任务上
- 其中却混入只适用于 CRM 线索的活动类型
如果不拦住，用户表面上创建成功，后面才会在动作入口、默认说明、视图跳转里各种错位。
六、最容易踩的误区
误区 1：用活动计划替代所有流程自动化
活动计划适合编排协作动作，不适合承载所有业务状态机。
误区 2：把 triggered next activity 和 plan 同时开满
这样最容易制造重复活动。
误区 3：忽视计划日期
模板截止日期是相对计划日期算的，不是相对“今天”一刀切。
七、排错顺序
当团队抱怨“为什么活动一下子冒出这么多”时，建议按这个顺序查：
- 这批活动是计划启动时生成的，还是某条活动完成后触发的
- 看模板 delay 是相对计划日前后，还是误以为跟活动类型 delay 一样
- 检查 responsible_type，是 on demand 还是模板固定用户
- 看是否同时还配置了 triggered next activity
- 最后才去怀疑导入、自动化或定时任务
最后一句
活动计划不是“下一个提醒”的放大版，而是把多人协作拆成一组可落地步骤的编排工具。
把这个边界看清，活动体系才不会越用越乱。
DISCUSSION
评论区