让 AI 帮忙建线索很诱人，但真正危险的是：它会不会把不能写的字段也写了，甚至把已有信息盖掉。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/ai_crm/models/crm_lead.pyenterprise/ai_crm/tests/test_ai_crm_tools.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
ai_crm 并不是给大模型一个 create lead 的任意写权限。它先暴露可用参数，再走受控工具创建流程，并且在 portal 场景明确禁止把已有值随便覆盖，确保 AI 只是代填，不是越权改 CRM 事实。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 ai_crm 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. 先声明 available params，再允许创建
_ai_get_lead_create_available_params(country_code=None) 说明 AI 不是拿到 crm.lead 全字段随便填，而是先问“这次允许用哪些参数”。
2. create lead 要经过预处理
_ai_prepare_lead_creation_values(vals) 与 _ai_create_lead(...) 表明，模型给出的输入还要先被整理、过滤，再进入真正创建。
3. portal 场景强调 no-overwrite
tests 里 test_create_lead_tool_portal_no_overwrite 专门说明，面向外部门户用户的 AI 工具不能把已有 CRM 信息当作草稿覆盖。
三、最容易被误解的边界
- 把 AI 当超级管理员，默认允许任意字段写入。
- 忽略 public / portal 与内部用户的权限差异。
- 允许模型覆盖已有线索字段，最后 CRM 事实被“优化文案”改掉。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先打印 available params，确认 AI 工具看到的字段范围。
- 再查 prepare_lead_creation_values 是否过滤了不安全输入。
- 最后验证 portal 路径下 no-overwrite 测试覆盖的字段行为。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
企业版 AI 建线索的成熟之处，不在于“能不能自动建”，而在于它先把可写范围和覆盖边界钉死，再让模型发挥。
DISCUSSION
评论区