Codex 把我 C 盘半边天削平了——AI Coding 时代，别再盲目 Approve
凌晨 1 点，我让 Codex 顺手清一下 node_modules。8 分钟后，C 盘里的 Documents、Desktop、Downloads 全都被它从字母 A 扫到了 Z。而且——是我亲手点的 Approve。
前言：一次“看起来无害”的清理
事情起因蠢得让人不想承认。我在一个 Next.js 项目里折腾 pnpm，node_modules 已经膨胀到深路径无法用普通方式删除（Windows 下经典“路径过长”报错）。我开了个 Codex Desktop 会话，对 cwd 指着那个项目，发了一条 5 个字的中文 prompt——大意是“继续做一下”——然后看着它出方案。
方案出来挺漂亮：
– 用 \\?\ 长路径前缀绕开 Windows 的 260 字符限制
– 调 cmd /c "rd /s /q ..." 强制无确认删除
– 还加了 StartsWith safety check，确保删除目标在 root 之内
我看了一眼，点了 Approve。然后命令开始跑，10 秒后超时退出。Codex 看输出报错，自己改写命令重试。又超时。再试。再试……8 分钟后我才意识到：Codex 的输出里出现了 $Recycle.Bin、Boot\BCD、$WINRE_BACKUP_PARTITION.MARKER 这些字符串。这些不是我的项目目录里的文件——这是 C 盘根目录。
现场：从字母 A 删到了 Z
事后从 Codex 的 sqlite 日志里挖出来的命令实际输出长这样（节选）：
command timed out after 120426 milliseconds
$Recycle.Bin\S-1-5-18 - Access is denied.
$Recycle.Bin\S-1-5-~1 - Access is denied.
$Recycle.Bin - Access is denied.
$WINRE~1\Rollback - Access is denied.
$WINRE_BACKUP_PARTITION.MARKER - Access is denied.
\AMTAG.BIN - Access is denied.
\Boot\BCD - Access is denied.
AI Coding 时代的“生产力”，本质是把“决策密度”从“每一行代码”压缩到了“每一次 Approve”。
以前你要敲 100 行代码做一件事，每敲一行都在做小决策。现在你只点一次 Approve，背后那 100 行的全部风险被打包成一个按钮。这个按钮值多少 token 的注意力——你愿意付，还是不愿意付，决定了你是 AI 时代的受益者还是受害者。
我这次付了一份“半个 C 盘”的学费。希望写出来，能让你少付一点。
事故还原全过程、logs_2.sqlite 提取脚本、可复用 SQL 查询，都在我个人仓库的事故归档里。如果你也踩过类似的坑，评论区聊聊——咱们一起把 AI Coding 时代的“地雷地图”画起来。
AI Coding Vibe Coding AI Agent Codex Windows 踩坑
你锁屏了，Codex 还在干活；AI 替身时代，来了
AI 编程工具越来越好用的同时，我注意到一个问题。我用的是 $100/月的 GPT Pro，日常 Vibe Coding，目前额度还够用。但不少 Pro 用户反馈，每周限额还没等到重置日就烧完了。AI 编程工具的“好用程度”和“钱包燃烧速度”，正在成正比增长。
“私房评价”🚧
Codex 这波更新，最值得关注的不是某个具体功能，是一个方向：AI 正在从「你需要它时才叫它」变成「它一直在后台帮你干活」。Appshots 让 AI 看到你的屏幕，/goal 让 AI 理解你的目标，Locked Computer Use 让 AI 在你离开后继续工作。三个更新，同一个终点：AI 不是你的工具了，它在变成你不在场时的替身。对开发者来说，学会和 AI 分工是基本功，但学会在 AI 替你干活时保持安全意识，是进阶课。
我给 Codex 加上 Superpowers 和 OpenSpec 后，才开始真正理解 AI Coding 工作流
自己也要读 diff、看页面、跑关键流程。最后确认的不只是代码，而是业务结果。这套流程刚开始会显得慢。尤其当你看到 Codex 几秒钟就能改一堆文件时，会觉得前面的讨论、计划和验证有点磨人。但我现在越来越觉得，这个“慢”是值得的。因为它减少的是后面的返工。它让 Codex 的速度用在正确的方向上。
Codex 没有降低专业要求
很多人讨论 AI 编程时，会自然走向一个问题：程序员是不是不重要了？我自己的感受刚好相反。Codex 的确能写很多代码。但它没有替你决定真实问题是什么。它没有替你决定第一版做多大。它没有替你决定哪些取舍符合当前项目。它也不会天然知道某个结果是不是真的能交付。这些判断仍然在人这里。只是程序员的专业能力，开始往两端移动。
往前，你要更会定义问题。不是只说“做个功能”，而是能讲清楚用户、场景、边界和成功标准。中间，你要更会拆任务。不是一次性把所有东西扔给 AI，而是把需求拆成能独立实现、独立验证的小步骤。往后，你要更会验结果。不是看它有没有写代码，而是看它有没有通过测试、跑通流程、留下证据，还有没有隐藏风险。这可能才是会写代码的人第一次用 Codex 最该练的东西。不是怎么让它多写一点。而是怎么让它在正确的问题上，小步写，写完验，验完再继续。
如果说以前的程序员更多是在和代码本身较劲，那么 AI coding 之后，我们要更多地和问题、边界、证据较劲。Codex 可以成为一个很强的工程搭档。但前提是，你不能把方向盘也交出去。第一次用它，不要急着让它写代码。先让它理解你正在做什么。再让它理解你真正要解决什么。最后，让它用可验证的结果证明：这一步，确实走对了。
别再叫它 GPT 了！Codex 才是 AI 编程的“真工程师” ——深度拆解优势、风险与落地全指南
普通人/开发者该如何正确使用 Codex？
日常轻度需求：通用 GPT 足够
写一段简单算法题、生成一个基础工具函数、解释一段代码逻辑——这些日常开发中的小任务，通用 GPT-5 或 GPT-5.4-mini 完全够用，成本和响应速度反而更优。不必事事强上 Codex，选对模型才是效率最大化的关键。
项目落地、工程开发、批量迭代：优先 Codex
当任务涉及以下情况，坚决切换至 Codex：多文件联动修改（例如一次修改涉及 5 个以上文件的耦合变更）、大规模重构或遗留代码现代化（如将 10 年历史的单体应用拆分为模块化结构）、跨语言工程任务（如后端 API 与前端 TypeScript 类型定义同步修改）、自动化闭环开发任务（从 Issue 到 PR 的全链条自主执行）、复杂调试与漏洞排查。
正确的组合策略是：用通用 GPT 快速验证思路、生成草稿，用 Codex 执行落地、完成迭代，用人工进行架构把关和质量最终确认。
核心原则：扬长避短，用模型提效，而非依赖模型全权决策
把 Codex 当作一个能力出众但仍在成长中的工程协作者，而非全知全能的决策者。Codex 可以负责“执行”这一层——写代码、跑测试、做重构，而关键的“决策”层——架构设计、技术选型、需求理解——始终应保留在人类的判断范围内。了解它的边界，规避它的风险（尤其安全漏洞），才能真正让 Codex 的价值在工程实践中得到释放。当人机协同成为一种基础工作模式，而不是一个时髦概念时，AI 编程才真正进入了黄金时代。
为什么像 Codex CLI 这样的 AI 编码工具，不能只看它会不会写代码
讨论 AI 编码工具时，最常见的误区，是把“它会不会写代码”当成主要判断标准。这当然重要，但如果只看这一点，判断往往会失真。因为一个工具能不能进入真实工作流，取决于的不只是“产出能力”，还有“判断结构”。
像 Codex CLI 这样的工具，真正决定它能不能进入真实工作流的，至少还有四件事：
第一，来源是否清楚。你看到的仓库、文档、安装方式和项目身份，是不是一致的？如果来源链条模糊，团队就会在“到底应该相信哪个入口”上浪费时间。一个进入生产前的工具，首先应该是可确认的，而不是需要猜的。
第二，边界是否清楚。它能读什么、改什么、执行什么命令、什么时候必须停下来交给人复核？边界不是额外负担，而是把工具从“会动的东西”变成“能被管理的东西”。没有边界的自动化，本质上是把决策权交给了不透明流程。
第三，验收是否清楚。改动之后看什么证据来判断“这次使用是成功的”？是 git diff、测试结果、日志，还是人工检查？如果验收标准不明确，团队就会用“看起来不错”替代“已经确认”。而一旦判断标准模糊，工具越快，风险越大。
第四，回滚是否清楚。如果这次试用判断错了，团队是否能快速撤回，不把试错成本扩散到主流程？这一步经常被忽略，因为大家默认“只要先试试就好”。但在真实项目里，试试本身就是成本。没有回滚路径，试用就会和冒险画上等号。
所以我越来越觉得，AI 编码工具的核心问题不是“能力展示”，而是“判断结构”。判断结构不清楚，再好的演示也只会让团队更快地进入不确定状态。反过来，如果判断结构清楚，哪怕工具还不完美，团队也知道怎么验证、怎么限制、怎么撤回。