Odoo 企业版 AI 字段为什么不是“给字段加个模型提示词”而已：property definition、cron fill 与 write/create

把 AI 结果塞进字段很容易想成“compute 一下就完了”，真正难的是：这个字段要像正常字段一样受模型元数据、批处理和写入生命周期约束。

这篇文章主要参考了以下企业版源码与测试入口：

• enterprise/ai_fields/models/ir_model_fields.py
• enterprise/ai_fields/models/models.py
• enterprise/ai_fields/models/mail_message.py

一、这个模块真正解决的不是表面动作，而是跨模块语义对齐

ai_fields 把 AI 结果做成字段，不只是多一个 compute。它要在模型元数据里反射参数、校验 property definition、决定哪些记录可批量补值，并且在 create/write 时守住不会把普通 ORM 行为搞乱。

如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 ai_fields 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。

二、核心机制链路

1. AI 字段先是元数据对象

ir_model_fields.create()/write()、_instanciate_attrs()、_reflect_field_params() 表明 AI 字段不是运行时随手算一个值，而是要先把定义安全反射回模型层。

2. property definition 有专门校验

Base._validate_properties_definition()、_additional_allowed_keys_properties_definition() 和 sanitize 逻辑说明，给 AI 字段的输入/输出结构不是任意 JSON，必须过 schema 与安全边界。

3. 批量补值靠 cron，不靠请求时现算

_cron_fill_ai_fields()、_ai_fill_records_with_empty_field() / _empty_property() 表明系统更偏向离线补齐空值，避免每次打开记录都阻塞等待 AI。

三、最容易被误解的边界

• 把 AI 字段当普通 computed field，忽略 ir.model.fields 层的定义同步。
• property definition 随便写，最终生成的提示词/结构不可控。
• 在前台写入时同步跑 AI，导致 create/write 生命周期不可预测。

这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。

四、实施与排查时，建议按这个顺序看

• 先看字段定义是否正确反射到模型。
• 再核对 property definition 校验有没有拒绝非法结构。
• 最后检查 cron 是否按 batch 只填空值，而不是反复覆盖已有内容。

对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。

五、结论

AI 字段成熟的标志，不是“模型能吐字”，而是它被当成一个真正受 Odoo ORM 约束的字段来治理。