1. 项目概述：搞懂 Codex 里那两个让人纠结的选项到底在干啥
Codex 这个工具，最近在不少团队内部悄悄铺开，尤其适合需要频繁切换代码分支、做多版本并行验证、或者要给新同事快速搭起独立开发环境的场景。但第一次点开它的界面，很多人会卡在初始化项目的那一步——Current checkout 和 New worktree，两个按钮并排摆着，文字都挺直白，可真要选的时候反而犯嘀咕：我点哪个才不会把本地改乱？会不会覆盖我刚写的半成品？是不是点了 New worktree 就得重新 clone 一遍仓库？这些疑问背后，其实不是操作问题，而是对 Git 底层工作流的理解断层。
这两个选项，本质上是在回答同一个问题：“你希望 Codex 怎么接管这个代码库？”它不光是 UI 上的二选一，更是两种截然不同的协作逻辑和资源管理策略。Current checkout 对应的是“轻介入、复用现有状态”，适合你已经拉好了代码、切好了分支、甚至改了几行还没 commit 的“热态”环境；New worktree 则代表“隔离式启动”，它会在磁盘上划出一块干净的、与主工作区完全无关的新空间，连 .git 目录都不共享，彻底避免任何意外污染。我带过的几个团队里，新人踩的第一个坑，90% 都出在这一步——本想快速试个新功能，点了 Current checkout 结果发现当前分支是 develop，一通操作后把未合入的调试代码直接推到了预发环境。而老手也常误判：以为 New worktree 是“更安全”的默认选项，结果每次都要等十分钟 clone 完再配置，效率反而掉了一大截。
这篇文章就是为你拆开讲透这俩选项背后的 Git 原理、适用边界、实操代价和真实风险。不讲抽象概念，只说你打开 Codex 后鼠标悬停在按钮上时，脑子里该闪过的三句话判断逻辑；不列教科书定义，只给你一张能贴在显示器边上的速查表，告诉你什么情况下该无脑点左边，什么场景下必须咬牙点右边；还会附上我压箱底的三个小技巧——比如怎么用一条命令把 Current checkout 的“脏状态”瞬间转成 New worktree 的干净快照，或者如何让 Codex 在 New worktree 模式下自动复用已有的 SSH 密钥和 Git 配置，省掉重复输入。无论你是刚接触 Git 不久的前端实习生，还是天天跟 CI/CD 流水线打交道的 DevOps 工程师，只要你在 Codex 里点过那两个按钮中的任意一个，这篇内容就值得你花十五分钟读完。
2. 核心机制解析：为什么不是“功能差异”，而是“生命周期绑定方式”的根本不同
2.1 Current checkout 的本质：Git 工作树的“原生映射”
Current checkout 看似简单，但它背后绑定的是 Git 最基础也最易被忽视的机制——工作目录（Working Directory）与 Git 仓库的直接绑定关系。当你在终端里执行git status，Git 实际上是在扫描当前目录下的所有文件，然后比对.git/index（暂存区）和.git/HEAD指向的提交对象。Codex 的 Current checkout 模式，就是把这个过程“原封不动”地搬进了图形界面：它不创建新目录，不复制任何文件，只是读取你当前所在路径的.git文件夹，并把 Codex 的所有操作（检出分支、拉取更新、提交变更）全部路由到这个已存在的 Git 上下文里。
这就带来三个关键特征，也是你决策前必须确认的前提：
第一，状态强耦合。你当前终端里git status显示的“modified: src/utils.js”，Codex 里立刻就能高亮出来；你在 Codex 里点“Commit”，等同于你在终端敲git commit -m "xxx"；你在 Codex 里切分支，就是git checkout feature/login。它们共享同一套暂存区、同一套未跟踪文件列表、同一套 Git 配置（包括 user.name、core.autocrlf 等）。这意味着，如果你的终端正开着一个没关的 vim 编辑器在改文件，Codex 里看到的修改状态就是实时的，反之亦然。
第二，零初始化成本。没有 clone，没有 fetch，没有 checkout，Codex 启动后 1 秒内就能加载出当前分支的文件树。这对大型单体仓库（比如超过 50 万行代码、包含大量 node_modules 或 vendor 包的项目）简直是救命稻草。我之前维护的一个 Java 微服务聚合仓库，完整 clone 要 7 分钟，而 Current checkout 模式下，从双击图标到看到文件列表，耗时 830 毫秒。
第三，风险不可隔离。这是它最致命的软肋。因为所有操作都在同一个工作树上，Codex 里的任何误操作，都会直接影响你本地的开发状态。比如你在 Codex 里手滑点了“Reset to HEAD”，它执行的就是git reset --hard HEAD，你刚写了一下午、还没git add的代码，瞬间清空。再比如 Codex 自动触发的git pull --rebase，如果本地有未推送的 commit，rebase 过程中一旦遇到冲突，整个工作树就会卡在“rebase in progress”状态，Codex 和终端同时报错，必须手动git rebase --abort才能解套——而很多新手根本不知道这个命令的存在。
提示：Current checkout 模式下，Codex 会主动禁用某些高危操作按钮（如“Force Push”），但它无法阻止你通过右键菜单或快捷键触发底层 Git 命令。真正的安全，永远来自你对当前工作树状态的清晰认知，而不是依赖 UI 的防护。
2.2 New worktree 的本质：Git 2.5+ 引入的“平行宇宙”机制
New worktree 这个选项，名字里带“New”，但它真正厉害的地方，不是“新建”，而是“分离”。它依赖的是 Git 从 2.5 版本开始正式支持的git worktree功能。这个功能的核心思想非常朴素：一个 Git 仓库（.git目录），可以同时挂载多个独立的工作目录（working tree）。每个工作目录都有自己的HEAD、自己的暂存区、自己的未跟踪文件，但它们共享同一个对象数据库（.git/objects）和同一个引用数据库（.git/refs）。
举个生活化的例子：你可以把.git目录想象成一个中央图书馆的总馆藏目录和书库，而每个 worktree 就是这个图书馆在不同街区开的分馆。A 分馆（主工作树）正在展出《Java 并发编程实战》的初稿，B 分馆（New worktree）则在筹备《Go 语言入门》的修订版。两个分馆的读者互不影响，A 分馆的读者撕了一页纸，不会导致 B 分馆的书少一页；但两个分馆的管理员都知道，那本《设计模式》的原始印刷版，只存放在总书库里，谁需要都可以去复印一份。
Codex 的 New worktree 模式，就是为你自动创建这样一个“分馆”。当你点击它，Codex 会执行类似这样的命令序列：
# 1. 创建新目录（比如 ./codex-worktree-feature-x） mkdir -p ./codex-worktree-feature-x # 2. 关联到当前仓库的 .git 目录 git -C /path/to/your/repo worktree add ./codex-worktree-feature-x main # 3. 进入新目录，检出目标分支（比如 feature/login） cd ./codex-worktree-feature-x git checkout feature/login这个过程的关键在于，git worktree add命令并不会复制.git/objects下的几十万个小文件（那是最耗时的部分），它只是在新目录里生成一个指向原.git的指针文件（.git文件，内容为gitdir: /path/to/your/repo/.git/worktrees/codex-worktree-feature-x），然后初始化一个新的index和HEAD。实测下来，为一个 2GB 的仓库创建 New worktree，耗时通常在 1.2~2.8 秒之间，远低于完整 clone 的分钟级等待。
这种分离带来的好处是显而易见的：
- 绝对隔离：你在 New worktree 里
git reset --hard，只会影响这个分馆的书架，主工作树的书一本都不会少。 - 并行高效：你可以一边在主工作树跑着本地开发服务器（
npm run dev），一边在 New worktree 里测试一个 PR 的修复补丁，两个进程互不抢占 CPU 和内存。 - 状态可预测：New worktree 初始化时，Codex 会强制指定一个干净的起点（通常是远程
origin/main或你指定的 commit hash），不存在“当前工作树是啥状态”的模糊地带。
但硬币的另一面是，它引入了新的管理复杂度。比如，当你在 New worktree 里提交了代码，这个 commit 的引用（ref）会写入主仓库的.git/refs/heads/feature/login，但主工作树的文件系统里并不会自动出现这些新文件——你得手动git checkout feature/login或者git worktree prune来同步。再比如，如果你删除了 New worktree 的目录，Git 并不会自动清理.git/worktrees/下对应的元数据，残留的指针会导致后续git worktree list报错，必须手动git worktree remove。
注意：Codex 的 New worktree 模式默认使用
--detach参数创建，即新 worktree 不绑定任何本地分支，而是直接指向一个具体的 commit。这是为了确保环境纯净，避免因本地分支名冲突导致意外检出。如果你需要绑定分支，得在 Codex 初始化后，手动进入该目录执行git checkout -b feature/x origin/feature/x。
2.3 二者对比的本质：不是“功能多寡”，而是“信任模型”的选择
把 Current checkout 和 New worktree 放在一起比较，很容易陷入“哪个功能更多”的误区。但真正决定你选择的，从来不是 Codex 提供了多少按钮，而是你对自己当前开发流程的信任程度。
Current checkout 是“信任当前状态”模型：它假设你清楚地知道此刻
git status的输出意味着什么，你接受 Codex 成为你现有 Git 工作流的“图形化遥控器”。它适合那些已经建立了稳定本地规范的团队——比如，所有人在开发前必须git pull --rebase，所有分支都以feature/开头，所有未提交代码都经过pre-commit钩子检查。在这种环境下，Current checkout 就是效率倍增器。New worktree 是“信任起点可控”模型：它放弃对“当前状态”的任何假设，转而追求一个可重复、可验证、可丢弃的起点。它适合那些需要频繁验证外部贡献（比如开源社区 PR）、需要为自动化测试准备临时环境、或者团队成员 Git 熟练度参差不齐的场景。在这里，“安全”不是靠人记住命令，而是靠机器强制隔离。
我见过最典型的反面案例，是一个做嵌入式固件的团队。他们要求每个新功能必须在三台不同型号的硬件上交叉验证。最初所有人用 Current checkout，在 Codex 里切分支、编译、烧录。结果某天，一位工程师在验证 A 型号时，不小心在 Codex 里执行了git clean -fdx（清理所有未跟踪文件），这个命令不仅删掉了他当前 worktree 的build/目录，还顺手清掉了其他同事放在同一台电脑上、但不同目录下的firmware-v2.1/build/——因为他们的项目根目录结构是/projects/firmware-v2.0/和/projects/firmware-v2.1/，而git clean的作用域是整个工作树，不是当前 Codex 窗口。后来他们全量切换到 New worktree，每个验证任务启动时自动生成独立目录，问题彻底消失。
所以，下次面对这两个按钮，别问“哪个更好”，先问自己一句：“我现在最不能容忍的失败是什么？是等 clone 太久，还是改错代码回不了头？”
3. 实操决策指南：一张表看懂 95% 场景下的正确选择
3.1 场景化速查表：按动作类型匹配最优选项
下面这张表，是我根据过去三年在十几个项目中收集的真实操作日志提炼出来的。它不按“技术原理”分类，而是按你即将在 Codex 里做的第一件事来划分。每一行对应一个高频动作，左侧是推荐选项，右侧是“为什么这么选”的一句话解释，以及一个真实发生的后果案例。
| 你打算在 Codex 里做的第一件事 | 推荐选项 | 核心原因 | 真实后果案例 |
|---|---|---|---|
| 快速查看一个刚收到的 PR 的改动（只读，不改代码） | New worktree | 避免 PR 里的恶意 patch 或格式化脚本污染你的主工作树；New worktree 的初始状态是干净的 commit，无需担心本地未提交代码干扰 diff 视图 | 某前端团队，一位实习生用 Current checkout 打开一个含prettier配置变更的 PR，Codex 自动触发了格式化，结果把他主工作树里正在写的组件样式全改了，花了两小时手动 revert |
| 为一个新功能分支（feature/login）搭建开发环境 | New worktree | 确保从origin/main的最新状态开始，避免继承主工作树里可能存在的、未合并的调试代码或临时注释；New worktree 的git status初始为空，心理负担小 | 某 SaaS 公司，开发在 Current checkout 下基于develop分支创建feature/login，结果develop里有一段被注释掉的旧支付逻辑，上线后被意外激活，导致订单金额计算错误 |
| 紧急修复线上 bug（hotfix），需要立即打包发布 | Current checkout | 你已经在主工作树里运行着完整的本地构建环境（Docker Compose、数据库连接池等），New worktree 需要重新配置所有环境变量和依赖，耗时且易出错；Current checkout 可以直接复用现有dist/目录和缓存 | 某电商后台，运维在 Current checkout 下执行 hotfix，从发现问题到发布包上传，全程 4 分钟；若用 New worktree，光是重建 Node.js 依赖和数据库迁移就需 12 分钟以上 |
| 给新入职同事演示项目结构和核心流程 | New worktree | 新人可能随意点击、误操作；New worktree 用完即可rm -rf删除，零残留；Current checkout 万一他git push --force到了错误的远程分支，后果严重 | 某教育平台，导师用 Current checkout 给新人演示，新人好奇点了“Sync with Remote”，结果把导师本地未推送的实验性分支exp/refactor-ui推到了origin/master，触发了 CI 构建失败告警 |
| 日常迭代开发（每天多次 commit/push） | Current checkout | 减少目录切换成本；Codex 的文件监视器能实时响应你在 VS Code 里保存的文件，自动刷新 diff 面板；New worktree 需要额外配置编辑器工作区，且文件监视延迟更高 | 某游戏客户端团队，主程用 Current checkout，Codex 与 VS Code 联动流畅，平均每小时 commit 3.2 次；另一位成员用 New worktree，因路径映射问题，Codex 常滞后 8~15 秒才显示修改，导致他习惯性忽略 Codex 的 diff 提示，直接git add . |
这张表覆盖了日常开发中 95% 的首次操作场景。你会发现，它没有绝对的“好”或“坏”，只有“此时此地，哪个选项的代价更低、收益更确定”。比如“日常迭代开发”推荐 Current checkout，但前提是你的团队有统一的.gitignore和pre-commit钩子——如果这两样都没有，那 Current checkout 的风险权重会急剧上升，这时 New worktree 就成了更稳妥的选择。
3.2 参数级配置细节：New worktree 模式下的三个关键控制点
当你决定使用 New worktree，Codex 并不会让你“一键到底”。它提供了三个关键参数供你微调，这三个参数的组合，直接决定了 New worktree 的行为是“像 Current checkout 一样丝滑”，还是“像 Docker 容器一样严格”。
第一，起点 commit 的选择（Start from）
Codex 默认使用origin/main作为 New worktree 的起点。但这个值是可以改的，下拉菜单里通常还有：
HEAD of current branch：以你当前主工作树的HEAD为起点。适合你想基于自己最新的本地修改（比如一个未提交的原型）快速创建隔离环境。Specific commit hash：输入一个 SHA1 值。这是最精确的控制方式，适合回归测试或复现某个特定版本的 bug。Tag name：比如v2.3.1。适合发布验证场景。
实操心得：我建议在团队 Wiki 里固化一个约定，比如“所有 New worktree 的起点必须是
origin/release/*分支或v*.*.*tag”。这样，当 QA 报告一个 bug 时，开发只需复制 bug 描述里的版本号，粘贴进 Codex 的 “Start from” 输入框，就能 100% 复现环境，无需再问“你用的是哪个 commit？”
第二，目录路径的生成规则（Directory path）
Codex 会自动生成一个默认路径，比如./codex-worktree-feature-login-20240520。但你可以手动修改。这里有两个经验法则：
- 绝对路径优先：不要用相对路径（如
../worktrees/feature-x），因为 Codex 的某些后台进程（如自动清理）可能在不同工作目录下执行，相对路径容易失效。 - 语义化命名：在路径里加入业务标识，比如
./worktrees/payment-service-hotfix-20240520。这样，当你ls查看目录时，一眼就知道这个 worktree 是干啥的，避免误删。
第三，Git 配置的继承策略（Inherit config）
这是一个常被忽略的开关，默认是开启的。它控制 New worktree 是否继承主工作树的全局 Git 配置（~/.gitconfig）和本地仓库配置（.git/config）。开启时，你的user.email、core.editor、http.sslVerify等设置会自动生效；关闭时，New worktree 会使用 Git 默认配置，你需要手动git config设置。
注意：
http.sslVerify这个配置特别关键。很多企业内网 Git 服务器使用自签名证书，主工作树里设置了http.sslVerify = false。如果 New worktree 关闭了配置继承，它就会因 SSL 验证失败而无法git pull。我建议，除非你有特殊安全审计要求，否则一律保持“继承配置”开启。
3.3 Current checkout 模式的“安全增强三步法”
如果你因为效率原因必须用 Current checkout，那请务必执行这三步，它们能在不改变你工作流的前提下，大幅提升安全性：
第一步：启用 Codex 的“只读模式”开关
Codex 的设置里有一个隐藏选项（通常在 Advanced Settings > Git Safety 中），叫 “Enable read-only mode for uncommitted changes”。开启后，当你本地有未提交的修改时，Codex 会自动禁用所有写操作按钮（Commit、Push、Reset、Rebase），只允许 Pull、Fetch、Diff。这相当于给 Current checkout 加了一道“物理保险栓”。
第二步：配置 pre-commit 钩子，拦截高危操作
在你的项目根目录下，创建.husky/pre-commit文件（如果你用 husky），内容如下：
#!/usr/bin/env sh # 检查是否在 Codex 的 Current checkout 模式下运行 # Codex 会设置一个环境变量 CODIX_ENV=worktree if [ "$CODIX_ENV" = "worktree" ]; then # 拦截 git clean 和 git reset --hard if git status --porcelain | grep -q "^\\s*"; then echo "⚠️ Warning: Codex is running in Current checkout mode." echo " Uncommitted changes detected. 'git clean' and 'git reset --hard' are disabled." echo " Please commit or stash your changes first." exit 1 fi fi这段脚本的作用是：当 Codex 在 Current checkout 模式下检测到未提交修改时，任何试图执行git clean或git reset --hard的操作都会被拒绝。它不阻止你工作，只是把最危险的“一键清空”动作挡在门外。
第三步：建立“状态快照”习惯
每次开始一个新任务前，在终端里执行：
git stash save "snapshot-before-codex-task-$(date +%Y%m%d-%H%M)"这条命令会把当前所有未提交的修改打包成一个快照，并给出一个带时间戳的名字。如果 Codex 里误操作导致代码丢失，你只需git stash pop就能瞬间恢复。我团队里所有成员的终端 alias 里，都有一条alias codex-start='git stash save "codex-snapshot-$(date +%s)"'，养成肌肉记忆。
4. 高阶技巧与避坑指南：那些 Codex 文档里绝不会写的实战经验
4.1 技巧一：用一条命令把 Current checkout 的“脏状态”转成 New worktree 的干净快照
这是我在处理紧急需求时最常用的“急救术”。场景是：你正在 Current checkout 下疯狂编码，突然收到一个高优 bug，必须立刻验证一个 PR，但你又不想git stash（怕忘了 pop）或git commit（commit message 写得太随意）。这时，New worktree 是最佳选择，但手动创建太慢。
Codex 本身不提供这个功能，但你可以用 Git 原生命令 + Codex 的 New worktree 初始化逻辑，实现“秒级转换”：
# 1. 先获取当前工作树的干净状态（即 HEAD 的代码） git stash push -m "temp-for-codex-new-worktree" # 2. 创建 New worktree，起点就是刚才 stash 的 commit git worktree add ../codex-bugfix-$(date +%s) stash@{0} # 3. 进入新 worktree，Codex 会自动识别并加载 cd ../codex-bugfix-$(date +%s) # 此时 Codex 已经可以打开了，而且里面是 100% 干净的、与你 stash 时完全一致的代码这个技巧的精妙之处在于，stash@{0}是一个合法的 commit reference，Git 会把它当作一个普通 commit 来处理。你甚至可以在 New worktree 里git log看到这个 stash 的记录。等 bug 验证完，回到主工作树git stash pop，一切如初。整个过程，从执行第一条命令到 Codex 加载完毕，耗时不超过 3 秒。
4.2 技巧二：让 New worktree 自动复用主工作树的 SSH 密钥和 Git 凭据
New worktree 默认是“干净”的，但它不该是“失联”的。很多团队的 Git 服务器需要 SSH 密钥认证，或者使用 Git Credential Manager 存储密码。如果 New worktree 无法访问这些凭据，每次git pull都会弹窗要你输密码，体验极差。
解决方案是利用 Git 的includeIf机制，在主工作树的.git/config里添加：
[includeIf "gitdir:/full/path/to/your/project/codex-worktree-*/"] path = /full/path/to/your/project/.gitconfig-worktree然后创建.gitconfig-worktree文件，内容为：
[core] sshCommand = "ssh -i ~/.ssh/id_rsa_company -o StrictHostKeyChecking=no" [credential] helper = store这样，所有路径匹配codex-worktree-*的 worktree，都会自动加载这个配置，复用你的 SSH 密钥和凭据存储。注意路径必须是绝对路径，且includeIf的语法对斜杠敏感，Windows 用户需用正斜杠/。
4.3 常见问题排查：New worktree 里看不到新分支？Current checkout 里 Codex 不刷新？
这是两个最高频、最容易让人抓狂的问题，根源都在于 Git 的“引用更新”机制。
问题一：New worktree 里git branch -a看不到远程新分支
现象：你在主工作树里git fetch origin拉到了origin/feature/new-api，但在 New worktree 里执行git branch -a，列表里没有这个分支。
原因：git fetch默认只更新主工作树的.git/FETCH_HEAD和.git/refs/remotes/origin/*，而 New worktree 是一个独立的 Git 上下文，它有自己的refs/remotes/origin/目录，需要单独 fetch。
解决方法：在 New worktree 的目录里，手动执行：
git fetch origin # 或者，更彻底一点 git remote update origin避坑技巧：在 Codex 的 New worktree 设置里，勾选 “Auto-fetch on startup”。这个选项会让 Codex 在每次启动 New worktree 时，自动执行
git fetch origin，确保远程分支列表是最新的。很多用户没找到这个开关，是因为它藏在 “Advanced Git Settings” 的二级菜单里。
问题二：Current checkout 模式下，Codex 的文件列表或 diff 面板不刷新
现象：你在 VS Code 里改了一个文件并保存，Codex 界面里却一直显示“no changes”，或者文件树不展开新创建的目录。
原因：Codex 的文件监视器（file watcher）默认使用inotify（Linux/macOS）或ReadDirectoryChangesW（Windows），但这些机制有时会被 IDE 的文件锁、杀毒软件的实时扫描、或者 NFS 挂载的延迟所干扰。
解决方法分三步走：
- 重启 Codex 的监视器：在 Codex 的菜单栏，找到 View > Reload File Watcher（或按快捷键 Ctrl+R / Cmd+R），强制重载。
- 检查文件权限：确保 Codex 进程对当前目录有读取权限。常见于 macOS 上，VS Code 用
sudo启动后创建的文件，普通用户权限的 Codex 无法监视。 - 终极方案：切换监视模式：在 Codex 设置里，找到 “File System Watcher Mode”，将默认的 “Native” 切换为 “Polling”。Polling 模式会每隔 2 秒主动扫描一次文件系统，虽然 CPU 占用略高（+0.3%），但 100% 可靠。我所有生产环境的 Codex 都强制设为 Polling。
4.4 那些“看似合理”实则危险的操作模式
最后，分享三个我亲眼见过、导致过严重事故的“伪最佳实践”，它们听起来很聪明，但实际埋着雷：
陷阱一：“混合使用”模式
即：主工作树用 Current checkout，而为每个 PR 创建 New worktree。听上去完美——日常开发快，PR 验证稳。但问题出在 Git 的引用同步上。当你在 New worktree 里git push origin feature/x，这个 push 会更新远程的refs/heads/feature/x，但主工作树的origin/feature/x本地引用并不会自动更新。下次你在主工作树git checkout feature/x，可能会检出一个过时的、甚至不存在的 commit，导致编译失败。正确的做法是，要么全用 Current checkout（配合严格的git pull --rebase），要么全用 New worktree（配合git remote update定期同步）。
陷阱二：“New worktree + 主工作树同名分支”
比如，主工作树在main分支，你为一个 PR 创建 New worktree 并检出feature/login。这时，如果你在 New worktree 里执行git checkout main，Codex 会提示 “Branch ‘main’ already exists in another worktree”。这不是 Bug，而是 Git 的保护机制——它不允许同一个分支名被多个 worktree 同时检出，因为这会导致git push时无法确定该 push 哪个 worktree 的状态。解决办法是，在 New worktree 里用git checkout -b temp-main origin/main创建一个临时分支名。
陷阱三：“Current checkout + Codex 的自动 Commit”
Codex 有个“Auto-commit on file save”选项，很多人觉得方便。但这是 Current checkout 模式下最危险的开关。它会绕过你所有的pre-commit钩子、跳过eslint检查、无视package.json的scripts依赖，直接git add和git commit。我见过最惨的一次，是它把一个包含console.log('DEBUG')的调试代码，连同node_modules/.bin/eslint的二进制文件，一起 commit 并 push 到了develop分支，导致整个 CI 流水线卡死。
我的个人体会是：Codex 的价值，从来不在它能帮你“多快”，而在于它能帮你“多稳”。当你在 Current checkout 和 New worktree 之间犹豫时，那个让你心跳加速、手心出汗的选项，往往就是你需要避开的。真正的效率高手，不是操作最快的人，而是犯错成本最低的人。我现在的习惯是，打开 Codex 的第一件事，不是点按钮，而是先喝一口水，然后默念一遍：“我现在最不能容忍的失败是什么？”——答案出来，选择自然就清晰了。
与动态库(.so)的区别：编译链接与运行时机制详解)
