💡 **这篇解决什么问题：**怕 Codex 改坏代码、改到不该动的地方、说“完成了”其实没测过。这篇讲怎么按任务给权限、改之前留好退路、改之后看 diff 和测试证据、前端用浏览器验收，以及怎么让 Codex 帮你做 Code Review。
更多 Codex 文章：省点力 · Codex 小类
大家卡在哪里
- AI 写代码最怕三件事：看起来完成了，但边界没处理；改动范围扩大了，把不该动的地方也动了；测试没跑，或者跑失败了被忽略。
- 总结会漏，diff 不会：Codex 说“我只做了一个小改动”，别全信。
- 复杂改动很难一次做对：数据库迁移和端到端测试牵涉数据、环境和边界条件，要分步验收。界面看起来能用，不能证明迁移正确，更不能代替测试证据。
- 合并冲突：多个任务修改同一批文件，合并时容易互相覆盖。分支隔离和逐项检查都不能省。
- 忽略安全边界：不看 diff、直接在生产项目里开大权限、让它操作敏感后台，或者前端任务完全不看实际页面。
一、Codex 会不会乱改代码？取决于三件事
- 你的权限设置；
- 你的 prompt 是否清楚（见 让 Codex 听懂你：上下文、提示词和斜杠指令怎么用）；
- 你有没有看
/diff。
记住一句话：小任务、小权限、强验收。
二、按任务给权限
VS Code 插件里的几种模式
| 模式 | 能做什么 | 适合 |
|---|---|---|
| 聊天模式（Chat） | 提问、解释代码、了解项目，不会改项目 | 第一次了解项目，比如问“能介绍一下这个项目吗？” |
| 代理模式（Agent） | 阅读代码库、执行具体任务、修改项目文件 | 真正要改代码时 |
| 完全访问（Agent with full access） | 权限更大，还可以联网、访问项目外的文件，自由探索和修改 | 权限要求高、步骤复杂的任务 |
| 自定义配置 | 按自己的需要调整可用能力 | 有特殊需求时 |
Codex App 里要先看的权限项
- 自动审核开不开；
- 是否允许完全访问；
- 什么时候需要你审批；
- 当前工作空间是哪一个；
- 它能不能操作本机。
不给权限，AI 只能陪你聊天；权限给太大，自己又不看 diff，就容易出问题。按任务给权限，不要一刀切。随着你熟悉它的能力边界，再慢慢放开，免得每次确认都浪费时间。
三档权限，新手怎么选
不同版本界面的中文翻译可能略有差异，核心思路差不多：
- 默认权限：只给建议，适合你想先看方案；
- 自动审查：可以自动编辑文件，关键操作会请示你；
- 完全访问：权限更大，可以自动执行更多操作。
新手推荐：
- 日常用“自动审查”；
- 删除文件、安装依赖、推送代码必须手动确认；
- 批量重构时，先让它制定方案，确认后再执行；
- 不要一开始就完全放权，等熟悉它的行为模式再逐步开放。
在 CLI 里可以用 /permissions 控制它是只读、可以改文件，还是跑命令前必须问你。生产项目、老项目、没有 Git 的项目，尤其别一上来就让它撒开跑。
沙箱和审批的默认设置
- 命令在一个安全的沙箱里运行，防止它改动项目之外的东西。如果有事在沙箱里没法安全执行，它会先征求你的同意。
- 默认审批策略是“按请求审批”（
on-request）：先继续执行，只在需要更高权限时停下来问你。 - 默认沙箱是工作区模式：能改当前目录里的文件，不能随意写到外面。
- 这两项都能在启动时调整：普通代码修改保留默认；需要更多系统权限的操作，提前调整审批和沙箱范围；不清楚某项操作的影响时，先让它请求确认，别直接放开。
想少点确认弹窗？两种做法
做法一：直接关掉审批
# ~/.codex/config.toml
approval_policy = "never"
sandbox_mode = "workspace-write"这样 Codex 在项目目录里可以自由改文件、跑命令，不再询问。要注意：这等于把每一步的确认都交了出去；公司电脑上 requirements.toml 可能直接禁止 never（见 一次配好 Codex：AGENTS.md、config.toml、Skills 与 MCP）；新手和生产项目不建议这样配。
做法二：只给安全流程授权
对明确安全的本地流程，可以进一步收窄审批范围：在 AGENTS.md 里写明某个流程是安全的，比如本地测试用一次性数据、没有生产权限，允许它运行测试、修复本次改动造成的失败、重跑受影响的测试，每一步都不用请求批准。配置和规则的写法见 一次配好 Codex：AGENTS.md、config.toml、Skills 与 MCP。
智能体：能用，但要慎重开
智能体可以操作你电脑上的应用，比如浏览器、控制台、某些桌面软件。填云服务器配置、填 App Store 截图信息、网页上重复的填表动作，都很适合交给它。但这些东西别让它碰：
- 支付确认；
- 转账；
- 删除数据；
- 账号安全设置；
- 密钥和 token；
- 私密聊天；
- 公司内部敏感系统。
必须让它进控制台时，先让它说明计划，并同步你的要求：
你将要操作浏览器控制台。
在点击任何提交、删除、支付、确认按钮前，必须停下来等我确认。
如果页面出现 token、密钥、手机号、邮箱，不要读取或复述。这是基本的安全边界。你请一个真人助理操作电脑，也不会让他随便点支付按钮。把这些操作写成必须人工确认的边界，别依赖模型临时判断。
三、改之前，先留好退路
- 开分支。Net Ninja 在让 Codex 改代码前，先用
git switch -c feature/modal新建了一个分支。 - 任务前后各留一个 Git 检查点（官方 IDE 指南）。改坏了可以直接回退。
- 项目还没有 Git 就先初始化：
git init，然后提交一次。提交说明好好写，别学某些老项目全员都写update，多年以后查记录，自己都想给自己一拳。连到 GitHub 的完整步骤见 Codex 长任务和大项目：计划文件、Goals、会话管理、并行、云端与额度。 - 高风险任务先出方案。改 README、修文案、补注释，风险低，可以让它直接做；涉及支付、登录、权限、数据库迁移、用户数据、生产部署，一定先出方案再小步执行。**小任务可以快一点，大任务一定要慢一点。**大任务可以先用
/plan（见 让 Codex 听懂你：上下文、提示词和斜杠指令怎么用）。 - 数据库迁移、生产环境修改，必须保留人工审核。
四、一份可以直接复制的“安全修改”任务模板
修改一个现有网站，又不希望它顺手改坏其他功能时，可以直接用这段：
请先阅读当前项目，理解它的目录结构、技术栈和现有功能。
本次任务：【在这里填写需求】
按下面顺序执行：
1. 先找到与需求有关的文件，说明准备修改哪些文件、为什么。
2. 检查项目现有规则，包括 AGENTS.md、README 和相关配置。
3. 如果涉及数据库、认证、支付、生产环境配置或删除操作，先说明风险并征求确认。
4. 在确认范围内修改代码，不改动无关文件，不随意新增依赖。
5. 修改完成后运行项目已有的测试、类型检查或构建命令。
6. 检查 Git Diff，确认没有意外修改。
7. 最后告诉我：修改了什么、哪些测试通过、哪些没有验证、还有什么风险。
不要把没有运行过的测试写成已通过；遇到无法验证的环节直接说明。这个写法和 OpenAI 官方的分阶段开发、验收要求是一致的。
五、完整走一遍：Net Ninja 的弹窗组件示例
- 开分支：
git switch -c feature/modal。 - 切模式：从 Chat 切到 Agent，允许 Codex 修改项目。
- 提需求：做一个可复用的弹窗组件，要求是：半透明背景遮罩；白色弹窗主体；通过 slot 传入内容；有关闭按钮可以关掉弹窗；新建 pair 的表单在没有校验错误时提交，弹出成功提示。
- 看结果：Codex 新建了弹窗组件和测试文件，更新了表单和 CSS，插件里列出了每处修改、改了哪些文件，以及跑过的测试。表单提交后会显示选中的模型，弹窗里也有对应的模型详情。
- 耐心一点：这次任务结果正确，但是作者遇到过最慢的一次 Codex 操作之一。复杂改动比简单提问、小修改要花更多时间（模型选择也有影响，见 Codex 长任务和大项目：计划文件、Goals、会话管理、并行、云端与额度）。
- 浏览器里亲自验证：表单里已经有示例数据，提交后弹窗正常出现，关闭按钮能关掉。
- 验证校验逻辑：必填项没填完时，弹窗不出现；补齐后提交成功，弹窗再次出现。说明表单和组件连接正确，弹窗只在通过校验后打开。
六、改完以后看 diff
每次至少看 5 样东西
- 改了哪些文件？
- 有没有改到任务范围之外？
- 有没有新增依赖？
- 有没有跑 lint / test / build？
- 有没有留下调试代码、假数据、敏感信息？
按文件追问
请按文件列出这次改动。
每个文件说明：
1. 为什么改
2. 具体改了什么
3. 有什么风险
4. 用什么命令验证过它没跑测试时
你还没有运行测试。
请先根据项目文档找到测试命令。
如果没有测试命令，请说明你能运行的最小验证是什么。用 /diff 看真实改动
/diff 会显示新增了哪些文件、删了哪些内容、有没有未跟踪的文件。别只看它的总结，AI 的总结会漏，diff 不会。
在 IDE 里审查
- 改完后插件会给出一段简短的总结，并显示一份聚焦的 diff，不用另开导航面板，就能看到受影响的文件和改动行数。
- 每处编辑旁边有 Undo，可以撤掉不想要的修改，只保留你想要的部分；源码和改动理由并排显示。
- 还可以在同一个对话里直接提后续修改。
推荐组合：先 /diff 看改动，再 /review 让它审。
以前人写代码要 code review，现在 AI 写代码更要 review。AI 编程把人从重复操作里解放出来，但最后的判断还在人这里。
七、要测试证据，不要“已完成”
- 把检查方法写进
AGENTS.md，让它能自己完成“修改、检查、再调整”的闭环（见 一次配好 Codex：AGENTS.md、config.toml、Skills 与 MCP）。 - 复杂任务分阶段执行。每完成一阶段，就让它运行检查，报告具体哪些通过、哪些失败。长任务怎么定义完成条件和证据，见 Codex 长任务和大项目：计划文件、Goals、会话管理、并行、云端与额度。
- 回到文件确认功能真的落地。比如要求用 Responses API 生成
agents.md，就打开对应实现，确认调用已经接入，再实际运行一次；不能只看回复里写着“已添加”。
八、前端任务：一定要看页面
按钮有没有挤在一起，移动端有没有重叠，弹窗有没有遮住内容，颜色看不看得清，这些问题光看 diff 看不出来。只说“build 通过”不够，要让它打开浏览器验收。
请启动项目并打开本地页面。
重点检查：
1. 375px 移动端是否有文字重叠
2. 1440px 桌面端首屏是否正常
3. 按钮文字是否溢出
4. 表单错误状态是否清楚
发现问题后先截图说明，再修改。前端工作流：描述目标 → Codex 改代码 → Browser 打开页面 → 截图检查 → 继续修样式 → 再次验收。
每次前端任务都加一句，能过滤掉很多“代码看起来对，页面其实不对”的问题：
改完后请用浏览器截图验证，不要只说代码已经改完。九、让 Codex 帮你做 Code Review
新手最适合从 review 入门
第一次用 AI 改代码会紧张，可以先不让它改，让它 review。review 的风险比直接改低，又能看出它的判断力：它指出的问题靠谱，你就知道它理解了项目；不靠谱，你也能看出它在哪些地方会误判。这是建立信任最稳的方式。
review 一个 PR：
请 review 这个改动。
重点看：
1. 有没有明显 bug
2. 有没有边界条件没处理
3. 有没有安全风险
4. 有没有测试缺口
5. 有没有可以简化的地方
只给 review 意见，不要直接改代码。review 本地 diff：
请 review 当前 git diff。
按严重程度输出：
P0 必须修
P1 建议修
P2 可以优化
不要泛泛而谈，每个问题都指出文件和原因。内置的审查入口
- CLI：
/review会让 Codex 切换成审查者视角，重点看有没有 bug、行为回归、缺测试、漏掉的边界条件、安全风险。支持四种方式：对照某个基准分支检查；检查本地所有未提交的改动；只审查某个具体提交；审查时额外加自定义要求。 - IDE 插件：点击 Code Review，同样可以选这四种方式。以检查未提交改动为例，点一下对应选项，Codex 就会逐段检查，最后把问题整理出来。
自定义要求很有用，不同场景关心的点不一样：普通功能开发关注逻辑错误和边界情况；安全相关改动重点查权限、输入校验和潜在漏洞；准备发布的代码，再加上测试是否充分、风格是否统一。
把团队审查标准写成文件
新建一份 code-review-guidelines.md，再让 AGENTS.md 引用它，主文件也不会越写越长。可以写：
- 必须检查逻辑错误和边界情况；
- 涉及权限或用户输入时，重点检查安全风险；
- 新功能是否缺少必要的测试；
- 代码风格是否和项目保持一致。
怎么看审查结果
- Codex 审查时会优先找 P0、P1 这类最严重、最需要马上处理的问题，也会发现一些 P2、P3，但不会每个小地方都指指点点。审查意见太吵，人很快就会麻木，最后干脆全部忽略。
- 判断一条意见值不值得处理，一个很实用的标准：如果不修，上线后会不会出问题？
- 审查结果会回到 IDE 插件里，带一个修复按钮，点一下 Codex 就能接着把问题改掉，不用手动复制再让它处理一遍。官方团队自己也用它发现并修复过一些代码问题。
- 提交前固定跑一次
/review。
每次改完的固定三步
/diff
/review
运行测试不要只看它的总结。这也是 7 天练习路线第 4 天的内容：“请 review 当前 diff，只给意见，不改代码”，用来训练你判断它的质量。
团队想在每个 PR 上自动跑审查、在自己的容器里做私有审查，见 Codex 长任务和大项目：计划文件、Goals、会话管理、并行、云端与额度。企业管理员可以参考官方的企业管理员指南和安全指南（资源链接见 Codex 长任务和大项目：计划文件、Goals、会话管理、并行、云端与额度）。