构建比官方更顺手的 Codex,Skills 自动化同步上游
2026年2月6日星期五
Codex v0.99.0 版本将引入 /statusline 功能,能够更直观地展示当前的项目信息和模型状态,如下图所示。

在官方推出这个功能之前,我已经实现了类似的状态栏。本文不讨论如何实现状态栏本身,而是分享开发完成后,如何利用 Skills 快速同步上游代码的实践经验。
相比官方版本,我的实现在信息呈现上更加直观,功能也更加丰富 🤩。
链接🔗:https://github.com/Loongphy/codext
此外,官方还未提供 Windows App,可以在该仓库的 Release 下载编辑器版本,相关构建教程参见上一篇 OpenAI Codex App for Windows: 从零构建教程。
修改内容
由于这是个人定制化工具,我遵循以下原则进行改造:
- 跳过测试代码:测试运行耗时较长,暂不考虑
- 保持 TUI 结构稳定:尽量不破坏现有界面架构,降低后续合并代码的复杂度
- 快速同步上游:只关注功能实现,无需考虑代码审查和合并流程
基于上述原则,目前已实现以下功能:
1. 顶部状态栏
在编辑区域顶部增加状态栏,实时显示四类核心信息:
- 模型信息:当前使用的模型和推理等级
- 工作目录:当前所在文件夹路径
- Git 状态:当前分支名称及文件变更情况
- 用量统计:5 小时内的使用量和重置倒计时
2. 协作模式的独立配置
支持为 Plan 模式和 Code 模式分别配置模型参数:
[collaboration_modes.plan]
model = "gpt-5.2"
reasoning_effort = "xhigh"
[collaboration_modes.code]
model = "gpt-5.2-codex"
reasoning_effort = "xhigh"
3. 账号热切换
在新终端执行 codex login 后,其他终端会自动监听 auth.json 的变化并重新加载 TUI,无需手动退出重启。

为什么要二次开发
功能起源
Codex v0.90 版本正式推出了 Plan 模式和 Code 模式(默认)。这两种模式整体表现出色,Plan 模式还借鉴了 Cursor 的设计理念,会主动向用户提问以深入理解需求。

在开发大型功能或进行重构时,可以通过 Shift + Tab 切换到 Plan 模式。经过多轮对话确定最终方案后,再切回 Code 模式执行。
实践两天后我发现:对于前端开发,强烈建议严格遵循 Plan → Code 的工作流程。在 Plan 模式下与 Codex 充分交流,能够明确更多 UI/UX 细节,最终产出质量更高。
虽然 Vibe Coding 体验不错,但也暴露出一些问题。比如,Plan 和 Code 模式的模型与推理等级都是硬编码为 gpt-5.2-codex medium。这可以理解,毕竟功能还在实验阶段,内置提示词也在持续优化。但对于我这种习惯将推理等级设置为 xhigh 的用户来说,这显然不够理想。再加上使用体验不够便捷,于是开启了二次开发之路。
最终效果如下:

核心诉求
二次开发的目标很简单:提升效率,优化开发体验。
- 实时用量展示:频繁使用
/status查看模型和用量很繁琐,需要一个像上下文用量那样直观的实时视图 - Git 分支提示:多分支并行开发时,需要明确当前所在分支,避免在错误分支上提出重复需求
- 模型配置确认:需要随时确认当前使用的模型和推理等级配置
……
你也许也有自己的痛点。既然现在的 Coding Agent 已经足够强大,为什么不直接打造一个更符合个人习惯的定制版本呢?
当然,二次开发也意味着取舍:一旦开始,你需要持续追赶官方的最新版本,每次发版都要同步并合并代码。
同步上游的工作流程
为了避免复杂的代码冲突,我采用了以下流程:
- 基于特定版本创建功能分支(如
feat/v0.94),开发并验证功能后,将改动记录到CHANGED.md文件 - 同步官方最新版本:执行
git fetch upstream tags,获取最新 tag(如rust-0.98.0) - 基于最新版本重建分支(如
feat/rust-0.98),从旧分支复制CHANGED.md,根据记录的改动重新开发 - 验收功能完成更新
这套流程的核心思路是:每次都基于最新代码从零开始,完全避免处理上游代码冲突。跳过测试代码编写,快速交付,完成迭代。
Skills 分享
基于上述流程,我整理了一套 Skills,你也可以根据自己的需求进行改造。
详见:https://github.com/Loongphy/codext/blob/main/.agents/skills/codex-upstream-reapply/SKILL.md

致谢
状态栏设计参考了:https://linux.do/t/topic/1481797