不少人第一次看到 Website Studio 的“Model Pages”时，会把它理解成一个更花哨的页面向导：选模型、点生成、稍后再去网站编辑器里拖拖拽拽。其实源码做的事情比这个重得多。
主要参考：
enterprise/website_studio/models/website_controller_page.pyenterprise/website_studio/static/src/editor_tabs.js
一、入口不是页面编辑器，而是 Studio 给模型上下文打包
editor_tabs.js 里注册的 “Model Pages” 不是随便开一个菜单，而是把当前被编辑的 res_model、默认网站发布、是否自动建菜单、是否自动建单页等上下文一起打进 action。
这意味着 Website Studio 不是在“空白页面”上工作，而是在“某个模型已经被选中”的前提下工作。后面的自动视图生成、字段占位符替换，都是围绕这个模型上下文发生的。
二、自动建页的关键不是复制 view，而是把通用模板变成可运行 arch
website_controller_page.py 里的 _create_auto_view 会先复制模板视图，再改成新的 key，然后在 website_studio.create_page 上下文存在时，用 _replace_arch_placeholders 把通用占位符替换成目标模型真实字段。
这一步非常关键。因为默认模板里的 studio_placeholder 只是一个“语义占位”，例如：
for='name'表示要找模型的显示名称字段for='monetary'表示优先找金额字段for='tags'表示尝试渲染 tag / x_studio_tag_idsfor='image'、for='html'表示补上模型里最合适的图片或 HTML 字段
也就是说，Website Studio 不是把页面模板原样抄过去，而是做了一次基于模型元数据的 arch 编译。
三、自动加字段的逻辑，解决的是“模型还不够网站化”
一个很容易忽略的细节是：如果模型上没有 x_studio_website_description，系统会先创建一个 HTML 字段，再把页面模板里的 HTML 占位符指向它。
这一步说明官方设计假设是：业务模型原本未必是面向网站展示设计的，Studio 需要先把它补到“可网站化”的最低状态。从产品体验看这很顺手，但从开发角度看，你必须意识到它会写 ir.model.fields，而不是只写一个页面视图。
四、公共访问不是天生存在，而是被动态补链
最容易被误解的一步，是 _get_ir_model_access 与随后的 ir.model.access 创建。若目标模型尚未对 website.website_page_controller_expose 这个组开放读权限，Website Studio 会主动补一条只读 ACL。
这意味着自动建页面不仅生成了前端展示层，还顺手搭好了最小可用的公开读取能力。否则页面能打开，控制器取不到记录，最终还是白搭。
五、实战里最该注意的三件事
1. 占位符替换不是万能推断
如果你的模型没有合适的 monetary、image、html 字段，某些占位符会被删除而不是保留空壳。二开模板时要接受这个行为，不要假设所有占位符都能替换成功。
2. 自动加 ACL 只解决“能读”，不解决更细的业务安全
Website Studio 给的是面向网站暴露组的最小读权限，不等于你已经完成字段级、记录级甚至多公司隔离设计。复杂模型仍然要自己补规则。
3. 视图 key 与模型 slug 很重要
自动生成页面高度依赖 slug 和 key 唯一性。若你在自定义模块里复制类似逻辑，却不处理 key 冲突，最终常见问题就是视图覆盖、菜单串页、缓存混乱。
六、结论
Website Studio 的模型页面功能，本质上是一套“模型元数据 → 网站视图骨架 → 公共读取能力”的自动装配链。看上去只是一个网站功能，实际上同时动了 Studio、QWeb arch、模型字段和 ACL。
所以它不是“帮你建网页”的小工具，而是一段把后端模型临时塑造成网站内容源的开发型流程。
DISCUSSION
评论区