构建比官方更顺手的 Codex，Skills 自动化同步上游

Codex v0.99.0 版本将引入 /statusline 功能，能够更直观地展示当前的项目信息和模型状态，如下图所示。

在官方推出这个功能之前，我已经实现了类似的状态栏。本文不讨论如何实现状态栏本身，而是分享开发完成后，如何利用 Skills 快速同步上游代码的实践经验。

相比官方版本，我的实现在信息呈现上更加直观，功能也更加丰富 🤩。

链接🔗：https://github.com/Loongphy/codext^[1]

此外，官方还未提供 Windows App，可以在该仓库的 Release^[2] 下载编辑器版本，相关构建教程参见上一篇 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 已经足够强大，为什么不直接打造一个更符合个人习惯的定制版本呢？

当然，二次开发也意味着取舍：一旦开始，你需要持续追赶官方的最新版本，每次发版都要同步并合并代码。

同步上游的工作流程

为了避免复杂的代码冲突，我采用了以下流程：

1. 基于特定版本创建功能分支（如 feat/v0.94），开发并验证功能后，将改动记录到 CHANGED.md 文件
2. 同步官方最新版本：执行 git fetch upstream tags，获取最新 tag（如 rust-0.98.0）
3. 基于最新版本重建分支（如 feat/rust-0.98），从旧分支复制 CHANGED.md，根据记录的改动重新开发
4. 验收功能完成更新

这套流程的核心思路是：每次都基于最新代码从零开始，完全避免处理上游代码冲突。跳过测试代码编写，快速交付，完成迭代。

Skills 分享

基于上述流程，我整理了一套 Skills，你也可以根据自己的需求进行改造。