背景
把本地 Codex 升级为 ChatGPT Codex 后，原本约定好的短语命令没有像预期那样启动经验站流程。表面上看像是技能没有安装，实际上升级同时带来了配置格式变化和新增钩子的信任边界，两个问题叠在一起，很容易把排查带偏。
这类问题的关键不在于反复改提示词，而是先确认新客户端是否真的读取了同一份用户配置、是否仍能看到技能，以及短语路由是否被允许执行。
这次解决了什么
最终确认新版本地客户端仍会读取用户级 Codex 配置，也仍能发现自定义的经验站发布技能。失效不是内容站项目本身的问题，而是旧配置中的服务层取值已经不被新版 CLI 接受，导致完整配置加载异常。
同时，短语路由不应只依赖模型“猜到”要使用哪个技能。为 生成精选稿 一类命令补上用户提示提交钩子后，命中短语会把经验站技能、目标目录和发布语义明确注入当前任务。
关键过程
先区分客户端层和项目层：新版桌面程序虽然显示为 ChatGPT Codex，但内部仍启动本地 Codex 的 app server 与代码模式宿主。因此经验站技能、审核稿和 SSH 发布能力仍可留在本机，不需要迁移到网页服务。
随后用新版 CLI 的调试入口检查模型可见上下文，确认经验站发布技能仍在技能列表中。继续读取配置时，发现旧的 service_tier = "default" 已不符合新版配置枚举；新版只接受新的服务层取值，或直接使用默认值。
移除过时项后，配置可以被新版正常读取。最后增加短语路由钩子：直接输入 生成精选稿 时默认生成文章并执行真实 SSH 发布；出现“只生成本地审核稿”或“不同步线上”时则保留为本地待审核稿。
踩坑
第一个坑是把桌面产品升级理解成“只是换了界面”。客户端版本升级也可能改变本地配置 schema，旧配置文件不一定会自动迁移。看到聊天窗口还可以对话，并不表示代码模式、技能系统和本地钩子已经成功加载。
第二个坑是只检查技能文件是否存在。技能存在只能证明模型有机会发现它，不能证明短语会稳定路由到它。对于会触发真实发布的简短命令，应额外建立确定性的提交钩子或等价路由层。
第三个坑是忽略钩子信任。新增的本地命令钩子通常需要客户端做一次明确的信任确认；在确认前，技能仍可见，但短语注入不会真正运行。
最后方案
升级后先用新版 CLI 验证配置能被解析，再确认技能列表包含自定义技能。不要沿用已废弃的配置值；没有明确需求时，删除旧的显式默认值通常比猜一个新值更稳妥。
经验站流程采用两层保障：技能描述负责让模型理解完整工作流，UserPromptSubmit 钩子负责把 生成精选稿 这类短语变成明确的流程命令。发布仍由经验站项目内的审核、脱敏、构建和 SSH 脚本完成，钩子不直接绕过这些边界。
以后怎么做
每次 Codex 大版本升级后，先跑三项小检查：配置解析、技能发现、短语路由。三项都通过，再测试真实项目对话和真实发布。
对本地自动化命令，保留一个最短触发词，但同时提供本地审核限定词。这样日常发布足够轻，涉及敏感内容或需要复看时，也能明确停在本地审核层。