结论先行
很多人一看到 Studio 里的 AI 字段，就会下意识把它当成“前端弹窗收 prompt，然后直接问模型返回结果”。企业版其实把它拆成了一条很标准的前后端接力：Studio 负责编辑字段元数据，RPC 负责把定义写入模型，AI 字段引擎再根据这些定义去批量回填或按需求值。
第一层：入口或表面动作
前端入口在 AiFieldConfigurationDialog。它维护 fieldType、prompt、relation、selection 等状态，看起来像个配置弹窗，但真正关键的是：这个弹窗并不直接生成业务值，而是在定义“这个字段以后该怎么被 AI 计算”。到了 field_properties.js，onChangeAi() 和 updateSystemPrompt() 会调用 /web_studio/edit_field RPC，把 ai、system_prompt 等属性写回字段定义，并同步 widget 类型。这说明前端改的是 schema，不是 record data。
第二层：真正的业务护栏
后台接力在 ai_fields.models.ir_model_fields。字段创建/修改时，若发现 AI 标记和 prompt 已设置，就触发 ir_cron_fill_ai_fields。_reflect_field_params() 把 ai 和 system_prompt 反射为真正的字段参数，_cron_fill_ai_fields() 则批量找出待填充字段，分批处理。这里的架构价值很大：前端只表达配置意图，真正的大模型调用发生在受控的后台批处理中。
第三层：状态落点与边界
按需求值时，ai_fields.models.models.get_ai_field_value() 会根据字段类型、prompt、上下文字段与允许值计算结果；_fill_ai_field() 则把结果写回 record。它在 many2one/many2many 场景还会先检查 allowed values / read access，避免 AI 把值写到用户本就看不到的记录上。也就是说，AI 并不是一个越权副驾驶，字段权限和模型访问边界仍然生效。
为什么这套设计更稳
这条前端链路的真正重点是：UI 弹窗只负责定义，RPC 只负责存元数据，后台任务才负责消费定义并写数据。你如果把“点一下按钮就立刻问模型并改字段值”塞进 Studio 前端，会把 schema 编辑、业务数据写入、权限校验混成一团。
实战启示
所以这篇题目的答案其实很明确：Studio AI 字段不是一个花哨的 prompt 对话框，而是一套从界面配置到元数据落库，再到后台填充引擎的跨边界接力。前端只是第一棒。
DISCUSSION
评论区