先给结论
在 Odoo 里，很多自动化问题其实可以拆成三个层次：
- 什么时候触发 →
ir.cron - 触发后执行什么逻辑 → Server Action / Python 方法
- 是否基于记录事件自动响应 → 自动化规则
只要先把这三层分开，自动化设计就不容易乱。
为什么大家老把它们混在一起
因为它们都长得像“系统自动帮你做点什么”。
但它们真正关心的问题并不一样：
ir.cron关心的是时间- Server Action 关心的是动作内容
- 自动化规则关心的是记录事件
如果你不先分清，后面就会出现典型混乱：
- 明明要按时间跑，却硬塞到记录触发里
- 明明是复杂业务逻辑，却全塞在 Server Action 代码框里
- 明明该写正式方法，却试图用界面配置拼一个半成品流程
ir.cron 本质上是什么
ir.cron 最适合理解成：
系统定时器。
它的职责不是理解业务本身，而是到点以后把某个动作叫起来。
所以它更像一个“闹钟”或“调度器”，而不是业务逻辑本体。
这也是为什么你看定时任务配置时，常常核心信息都围绕：
- 多久跑一次
- 下次什么时候跑
- 调哪个模型/方法
- 是否激活
Server Action 又是什么
Server Action 更像一个：
可挂载的执行动作容器。
它能做的事情通常包括：
- 调 Python 代码
- 更新字段
- 创建活动
- 发消息或触发某些对象行为
它比 ir.cron 更接近“做什么”，但它通常仍不应该成为大型业务逻辑的长期归宿。
我的经验是：
- 简单动作，Server Action 很方便
- 复杂逻辑，最好回到正式模块方法里
否则后面排查和维护会越来越痛苦。
自动化规则最适合什么场景
自动化规则最适合：
- 创建时触发
- 更新时触发
- 满足某个 domain 条件时触发
- 某字段变更后自动做跟进动作
也就是说，它偏向“记录发生了什么变化，所以系统响应一下”。
这和 cron 那种“无论有没有人动记录，到点就跑”完全不是一回事。
一个特别好用的判断方法
如果你在想自动化方案，可以先问自己：
1. 这是按时间触发的吗？
如果是，大概率先想到 ir.cron。
2. 这是某条记录变化后马上响应的吗？
如果是，大概率偏自动化规则。
3. 这是复杂业务能力，未来还要复用、测试、扩展吗？
如果是，核心逻辑最好写在正式 Python 方法，不要只堆在 Server Action 里。
为什么复杂逻辑不建议全塞 Server Action
因为它写起来快，但维护性经常差。
常见问题有：
- 代码散在后台配置里，不好版本管理
- 不容易做单元测试
- 逻辑一多，排查路径很碎
- 不同环境迁移时容易漏
所以 Server Action 最适合当“挂钩点”或“轻动作层”，而不是长期堆放复杂业务规则的主战场。
ir.cron 最容易踩的坑
1. 以为 cron 是实时的
它是周期轮询，不是消息总线。
2. 定时逻辑里没考虑幂等
结果同一批数据反复处理。
3. 任务太重，却没有拆批
一次跑太多数据，容易拖垮性能。
4. 把业务规则写死在 cron 调度层
后面很难复用。
自动化设计最稳的方式
我更推荐这种分层：
- 正式模型方法：承载核心业务逻辑
- Server Action：作为轻量触发器或桥接层
- ir.cron / 自动化规则：决定什么时候触发
这样设计的好处是：
- 逻辑边界清楚
- 代码可测试
- 后续 API、按钮、cron 都能共用同一套方法
这比把一切揉成一个后台配置块稳定得多。
一句话记忆法
把这套关系记成一句话：
ir.cron管时间，自动化规则管事件，Server Action 管动作挂钩，真正复杂的业务逻辑最好回到正式模型方法里。
理解这句，Odoo 自动化设计就不容易再糊成一团。
DISCUSSION
评论区