“Codex skin”和“Codex theme”经常被混用，但人们实际讨论的是权限、能力和恢复方式完全不同的几层定制。关键不是争论词义，而是知道变化发生在哪里、改变了什么、你需要信任谁。
第一层：原生外观设置
原生外观设置由官方应用自己提供，是风险最低的定制层。应用负责保存和应用参数，并随着产品一起更新。不同版本可能提供明暗模式或其他界面偏好，但不一定支持任意背景图、玻璃面板、装饰边框和复杂布局效果。
如果原生设置已经满足需求，应优先使用。它不需要注入器，恢复路径也通常最简单。
第二层：skin 配方
Skin 配方描述视觉意图。在 Codex Skin Maker 中，它包括：
- 背景图片；
- 裁切焦点；
- 变暗和模糊；
- 面板不透明度；
- 明亮或深色模式；
- 操作色、表面色和正文色；
- 预览图；
- 包元数据与校验值。
配方本身只是数据，不能直接修改桌面应用。它类似设计 Token 和素材集合，但还没有负责读取它们的运行时。
这个限制是有意的：装饰性下载应该容易检查，不应该隐藏脚本、认证变更或模型服务商配置。
第三层：运行时皮肤注入
公开的 Codex Dream Skin 项目代表第三层：本地软件通过回环 Chromium 调试会话启动官方 Codex 桌面应用，并向预期的渲染目标应用视觉 CSS 和装饰元素。
它能实现普通原生设置之外的背景和表面效果，也需要更多信任，因为本地运行时会接触较强的调试接口，并且要跟踪 Codex 界面结构变化。
上游文档称该流程保留原生控件，并避免修改签名应用包、app.asar 或 WindowsApps。这些是应该针对当前版本实际核对的重要目标。
视觉皮肤不应该改变什么
无论哪一种外观层，都不应要求改变：
- OpenAI 账号；
- API Key 或认证文件；
- 模型服务商或 Base URL；
- 项目数据；
- Prompt、任务或模型行为；
- WindowsApps 所有权或签名应用内容；
- 与外观无关的系统安全设置。
如果一个“皮肤”把视觉变化和上述操作绑在一起，应把它当成另一类软件重新评估，而不是普通主题。
分层为什么有利于恢复
假设 Codex 更新后外观出错：
- 原生设置通常可在应用内改回；
- 配方只是数据，可以编辑或丢弃；
- 运行时注入器需要文档化 Restore，停止调试会话并正常重开 Codex。
如果三层被打成一个不透明安装包，就很难知道哪一层失败。分开后，故障定位和用户同意都更清晰。
本站如何使用这些词
本站用 Codex skin 表示完整视觉概念，用 skin 配方 表示导出的数据包。我们不会把下载 ZIP 描述成“已经安装的主题”，因为获得素材与安全应用到桌面软件是两件事。
Codex Skin Maker负责设计与配方生成；安装指南说明独立的运行时决策；安全页面解释为什么本地处理、纯数据导出、CDP 风险、原生控件验证和恢复必须放在一起讨论。
应该选择哪一层？
以下情况优先原生外观设置：
- 主要需求只是明暗模式；
- 稳定性比自定义背景更重要；
- 不希望打开本机调试会话。
以下情况先制作 skin 配方：
- 想设计并归档一套视觉方向；
- 需要先测试裁切、颜色和对比度；
- 希望在不运行代码的前提下审查包内容。
只有在以下条件下再考虑运行时皮肤引擎：
- 理解当前源代码和权限；
- 额外背景与样式能力值得维护成本；
- 已测试验证和恢复；
- 愿意在应用更新后重新检查兼容性。
最吸引人的截图，不一定代表最合适的定制层。真正合理的选择，是使用能够达到目标的最低权限方案，并始终保留清楚的返回路径。