让 Codex 把你的终端启动速度提升 10 倍

最近我想把用了多年的 Oh My Zsh 换掉，换成现代轻量方案：Zinit + Starship + Rust 工具链（eza/bat/fzf/zoxide）。

但我没有自己一步步手敲，而是直接把整套方案的设计文档丢给了 Codex，让它在我的真实 macOS 环境里完成迁移、调优、验证的全流程。整个过程暴露了一个挺有意思的点：agent 干活和人干活的差别，不在于会不会写配置，而在于会不会在每一步给自己设“验证关卡“。

先说现状判断

Oh My Zsh 的问题不是插件不好用，是它在每次开 shell 的时候把一堆不需要的东西全量加载一遍。半秒延迟过去大家当成“开店的成本“忍了，但如今越来越多人开始受不了。

新阵营的核心思路是换成按需加载：

组件作用替代谁Zinit插件管理器，支持 lazy-loadOMZ 框架本身Starship跨 shell promptPowerlevel10kzoxide智能 cdcd / autojumpeza / bat / fd / rgRust 重写的基础命令ls / cat / find / grepfzf模糊搜索Ctrl+R 原生历史

目标是把启动时间从 OMZ 的几百毫秒压到 120ms 以内。

把这件事交给 Codex 之后,它是怎么做的

我把方案文档发过去,只说了一句“用 Zinit 的 lazy-load 换掉 Oh My Zsh 的全量加载，保留 OMZ 里你真正用到的 git aliases，加上 Rust 工具链的质感**。迁移路径很平滑——保留肌肉记忆，去掉额外开销，用 zinit snippet OMZP::git 这类方式按需引入 OMZ 插件。 如果你现在就在用 Oh My Zsh，可以直接用这套方案替换，不需要先卸载 OMZ。想要我帮你根据具体的 Node/Go/Podwise 工作流调整 aliases 或 Starship 显示内容，说一声。 帮我根据上面的这套方案，来配置一下我当前的 shell 环境，我现在在用 oh my zsh，帮我把 omz 直接删掉，并启用这个形式。按这个方案配置我的环境,把 OMZ 删掉“。接下来发生的事,比我预期的更“工程化“:

1. 先备份再动手。 它没有直接覆盖 ~/.zshrc,而是先确认我现有配置里除了 OMZ,还混了 mise、Bun、pnpm、DYLD_LIBRARY_PATH 和几个 API key 的 export。这些都是要原样保留的“存量资产“,不能在框架迁移里被误删。

2. 把密钥从主配置里摘出来。 它把所有密钥类的 export 移进了一个独立的 ~/.zshrc.local,主配置只 source 它。这个动作不是方案文档里要求的,是它自己判断“框架配置和密钥不该混在一起“之后加的。

3. 删除前先做语法检查。 新配置写完后,先做了一遍语法校验,确认 Starship 配置能被当前版本正常解析,再去执行备份、写入、删除 OMZ 这一串不可逆操作。

4. 验证环境本身可能在说谎。 第一轮测速时,zsh -i -c 这种“伪交互“环境里冒出了 ZLE 相关的报错和不真实的耗时(掺了插件首次下载的网络等待)。它没有把这些噪音当成真实问题去“优化掉“,而是先定位噪音来源——区分清楚“这是真实终端会发生的问题“还是“这是测试方式本身的伪影“。最后定位到是 fzf –zsh 在非 TTY 环境里尝试绑定 keybinding,加了一层“只在真实终端会话里加载“的判断,而不是简单地把这些功能砍掉换取一个好看的测试数字。

5. 用 profiling 代替猜测。 优化到 0.27s 卡住的时候,它没有继续凭感觉调,而是套了一层 zprof,实测出 Zinit 的 OMZ snippets 占约 20ms、compinit 占约 13ms、而 mise activate zsh –shims 这种每次 fork 子进程的初始化占了大头,约 70ms。

6. 对症下药而不是无差别延迟加载。 找到瓶颈后,它把 ZLE 相关的几个插件(fzf-tab、autosuggestions、syntax-highlighting)和 OMZ snippets 都改成 Zinit 的 turbo 延后加载——保证 prompt 先弹出来,功能性插件随后无感接上。对 mise,它没有简单延后,而是直接换成零 fork 的 PATH 注入方式,跳过整个子进程开销。

这件事说明了什么

这次迁移最后没有精确卡到 120ms 的目标(中间值在 0.27s-0.66s 之间反复),但比 OMZ 原来的体验已经是数量级的提升。比起最终数字,我更在意的是过程里这几个动作:

• 不可逆操作(删 OMZ)之前一定先备份和校验

• 测出来的“问题“先怀疑是不是测试方法本身的问题,而不是急着去优化

• 卡住了就上 profiling 工具,而不是凭感觉继续调

• 优化要分场景——该延迟加载的延迟加载,该换实现方式的换实现方式,不是一刀切

这套“工程纪律“原来需要靠经验积累,现在 Codex 在执行配置迁移这类任务时,已经会主动把它当成默认动作。对独立开发者来说,这意味着很多“我知道该怎么做但懒得每一步都小心“的杂事,可以放心交出去了。

附:当时给 Codex 的原话

用 Zinit 的 lazy-load 换掉 Oh My Zsh 的全量加载，保留 OMZ 里你真正用到的 git aliases，加上 Rust 工具链的质感**。迁移路径很平滑——保留肌肉记忆，去掉额外开销，用 zinit snippet OMZP::git 这类方式按需引入 OMZ 插件。 如果你现在就在用 Oh My Zsh，可以直接用这套方案替换，不需要先卸载 OMZ。想要我帮你根据具体的 Node/Go/Podwise 工作流调整 aliases 或 Starship 显示内容，说一声。 帮我根据上面的这套方案，来配置一下我当前的 shell 环境，我现在在用 oh my zsh，帮我把 omz 直接删掉，并启用这个形式。

就这一句话,剩下的备份、密钥隔离、语法校验、噪音排查、profiling、分场景优化,都是它自己拆解出来的执行步骤。