https://codexer.com/tags/%E6%95%88%E7%8E%87%E6%8F%90%E5%8D%87/Recent content in 效率提升 on CodexerHugozh-cnTue, 02 Jun 2026 09:00:00 +0800https://codexer.com/posts/2026-06-02-codex-boundaries-when-not-to-use/Tue, 02 Jun 2026 09:00:00 +0800https://codexer.com/posts/2026-06-02-codex-boundaries-when-not-to-use/<h2 id="你以为-codex-无所不能先回答四个问题">你以为 Codex 无所不能？先回答四个问题</h2> <p>用 Codex 写代码久了，很容易产生一种错觉：既然它能帮我重构模块、写测试、甚至修复安全漏洞，那是不是什么任务都能甩给它？</p> <p>答案是不能。</p> <p>一位在 Towards Data Science 上分享经验的开发者 Eivind Kjosbakken，最近两周从 Claude Code 切换到了 Codex，用 GPT-5.5 处理各种真实项目任务。他的结论是：Codex 在很多场景下比 Claude Code 更快、更精准，但它有一个致命的盲区。另一位来自 freeCodeCamp 的技术作者 Tatev Aslanyan 则在一份长达数万字的 Codex 手册中，专门用一整章来讨论「什么时候不该用 Codex」。</p> <p>把他们的经验和 OpenAI 官方的最佳实践放在一起，我提炼出了一套判断框架。</p> <p>在决定让 Codex 接手任务之前，先问自己四个问题：</p> <ul> <li>产出物是否有人能审查？（如果没人检查，AI 的自信就成了唯一的质量门槛）</li> <li>这是已知模式还是全新的架构决策？（Codex 擅长应用模式，不擅长选择模式）</li> <li>影响范围是否局限在一个仓库或服务内？（跨团队的事它看不到全貌）</li> <li>犯错的代价是否可控？（测试失败可以 revert，生产数据丢失不行）</li> </ul> <p>四个问题都回答「是」，Codex 大概率能胜任。任何一个回答「否」，你就需要重新考虑任务拆分方式，或者干脆自己动手。</p> <h2 id="场景一没人审查的一次性脚本">场景一：没人审查的「一次性脚本」</h2> <p>Codex 的核心价值在于它产出的东西可以被人类审查。diff 可以看，测试可以跑，review 可以做。如果你让 Codex 写一个直接操作生产数据库的一次性脚本，写完就跑，没有人 review，那 AI 的「自信」就成了你唯一的质量保障。</p> <p>这不是模型能力的问题，而是流程设计的问题。</p> <p>Kjosbakken 在文章中提到一个有趣的观点：他之所以敢给 Codex 开 YOLO 模式（允许它在工作目录内自由执行任何操作），是因为他的基础设施设计得好。Agent 不应该有能力永久删除数据库或造成不可逆的破坏。如果一个 Agent 或者一个人能做到这些，那说明基础设施本身就有问题。</p> <p>反过来说，如果你的环境还不够安全，那就别急着给 Codex 自由。先加固基础设施，再谈自动化。</p>