全局定制与 OEM
很多“能不能改”类需求，本质上不是做不到，而是没先选对定制手段。这页把客户和客服最常反复确认的定制问题整理成 FAQ，帮助你快速判断该用全局 CSS、全局 JS、customI18nPostProcessor，还是 createTool()。
想隐藏按钮、tab、卡片，应该优先用什么？
优先用 全局 CSS。
这类需求只改“页面看起来怎样”，不改“页面要做什么”，所以 CSS 更直接、更稳定。常见场景包括：
- 隐藏首页“行业案例”“教学帮助”
- 隐藏登录页“忘记密码”
- 隐藏应用集市里的“导出”“去编辑”
- 隐藏弹窗中的“用户组”“组织架构” tab
- 限制图表弹窗里可见的图表类型
如果你已经可以用选择器稳定选中目标元素，就不要先上 JS。
想改欢迎语、按钮文案、空态提示，应该优先用什么？
如果你知道对应的 i18n key，优先用 window.customI18nPostProcessor()。
因为它是在 i18n 查找后稳定覆盖文案，不需要轮询 DOM，也不依赖页面结构。它特别适合：
- 改 Copilot / Data Agent 欢迎语
- 改固定按钮文案
- 改空态和提示语
- 做租户级品牌文案覆盖
只有在拿不到 i18n key，或者文案会随着页面结构、路由、渲染时机变化时，才建议退回全局 JS 直接改 DOM。
什么情况下才应该用全局 JS 改 DOM？
当需求依赖路由变化、页面渲染时机或运行状态时，才更适合用全局 JS。
高频场景包括：
- 图表无数据时，把默认提示语替换成业务文案
- 固定浏览器 tab 标题为公司名称
- 只在某个页面里隐藏某个下拉项
- 登出后跳第三方门户
- 屏蔽
/login入口或接第三方统计脚本
简单说：只改样式用 CSS，只改固定文案优先看 i18n Hook，必须看运行时状态才上 JS。
想让 Agent 能查内部知识库或调用业务 API，也算“全局 JS 定制”吗？
算，但这已经不是“页面定制”，而是 Agent 能力扩展。
这类需求要用 window.heisenberg.createTool()，适合：
- 接企业 FAQ / 知识库
- 接订单、库存、工单、审批状态等实时 API
- 调搜索引擎、向量检索或第三方 SaaS
- 让 Agent 执行轻量动作，例如创建工单、写回备注
如果你的诉求只是改欢迎语、改按钮、隐藏页面元素，就不要上 createTool()。
做 OEM 时，最常见的需求分别应该落到哪一层？
可以先按这个表判断：
| OEM 诉求 | 优先方式 |
|---|---|
| 改颜色、字体、边框、隐藏卡片/按钮 | 全局 CSS |
| 改固定文案、欢迎语、提示语 | customI18nPostProcessor() |
| 按页面状态动态处理内容或跳转 | 全局 JS |
| 给 Agent 增加企业私有能力 | createTool() |
如果一个需求同时涉及“视觉 + 行为”，通常会是 CSS 和 JS 组合，而不是只靠其中一种。
全局 CSS / JS 写错了，把页面搞坏了怎么办？
两种方式都预留了“后悔药”。
- CSS 失控时：访问带
no-global-css的页面，例如https://{host}/setting/global-css?no-global-css=true - JS 失控时：访问带
no-global-js的页面，例如https://{host}/setting/global-js?no-global-js=true
如果连页面都不方便进，也可以通过后端配置接口把对应功能整体禁用，再回到页面修复。
为什么同样是“隐藏功能”，有人用 CSS，有人却用 JS？
因为“隐藏”背后其实有两类完全不同的问题：
- 元素本来就在页面里，只是不要显示：优先 CSS
- 元素什么时候出现、在哪个页面出现，要看运行时状态：更适合 JS
比如：
- 应用集市里固定存在的“导出”按钮：CSS 就够
- 只在某个路由、某个下拉弹层出现时才隐藏：往往需要 JS 监听和判断
进一步阅读：