接手项目最贵的不是写代码
不管是同事甩过来的祖传仓库，还是你自己半年前扔下的老项目，重新打开时真正卡住你的从来不是「不会写」，而是：入口在哪、依赖怎么装、这个函数为什么这么写、哪个目录动了会炸。
这部分「考古工作」，恰恰是 Codex 最擅长、也最被低估的能力。
一句话总结这套方法：它替你翻代码，你替自己把关。速度快的那部分给它，判断生死的那部分归你。
第 0 步：先系安全带
在让 Codex 碰任何文件之前，先做三件事，一分钟就能搞定：
# 1. 开一个专用分支，别在主干上折腾
git checkout -b codex-recon
# 2. 确认工作区干净，避免它的改动和你的改动混在一起
git status
# 3. 如果有未提交的东西，先存起来
git stash
然后在 Codex 里把权限模式调成默认权限（需要时才弹框），而不是一上来就完全访问。
再检查一遍：.env、密钥文件、生产配置有没有躺在仓库里。有的话先加进忽略列表，别喂给 AI。
第一步：侦察模式——先读不改
这是全套流程里效果最好的一句开场白：
先不要改任何代码。
通读这个仓库，然后告诉我：
1. 程序入口在哪个文件，启动命令是什么；
2. 核心模块有哪几个，各自负责什么，画出模块边界；
3. 一个典型请求从进来到返回，依次经过哪些文件；
4. 依赖怎么安装，测试怎么跑；
5. 哪些目录 / 文件是最危险的（改了容易连锁出问题），为什么。
「先不要改代码」这五个字必须写进去。否则 Codex 大概率会一边读一边顺手「帮你优化」，让你的第一次 diff 变得没法看。
跑完这一轮，你对项目的理解基本能追上一个交接了半天的老同事。
第二步：让它复述理解，你来纠偏
侦察报告出来后，别急着夸。挑两三个你自己确实清楚的点去对答案：
你说订单状态流转在 order_service 里处理，
把这段状态机的完整逻辑复述一遍，包括所有分支和异常回滚路径。
如果它复述得对，说明上下文加载到位，后面可以放心派活；如果它开始编，那就说明仓库太大或者关键文件没读到——这时候要么缩小工作区到子目录，要么手动把关键文件拖进对话框。
这一步是全流程的质量闸门，别跳过。
第三步：安全体检，按五问顺序来
老项目最容易藏雷的地方是安全。这五问是有顺序的，一层套一层：
① 加载上下文
分析这个项目的整体安全状况。先读项目结构和关键代码，
告诉我它的架构和完整的鉴权链路：请求进来后在哪一层校验身份、哪一层校验权限。
② 验证已有发现
这里有一份历史扫描报告（贴上内容）。
逐个验证这些漏洞现在是否真的还存在，用实际的 HTTP 请求复现，
把请求和返回都贴出来作为证据。
③ 定向深挖
检查所有接收用户输入的地方，有没有 XSS、SQL 注入、路径遍历。
管理后台的权限校验是否完整？普通用户能不能越权访问管理接口？
④ 补充扫盲
除了已经确认的，常见 Web 安全问题里还有哪些存在？
重点看：CSRF、SSRF、速率限制缺失、安全响应头、文件上传类型校验、越权改他人数据。
⑤ 生成报告
把所有确认的问题写成一份报告，每个按「描述 / 危害 / 复现步骤 / 修复方案」四段写，
按严重等级从高到低排序。没有实证的疑似项单独放一节，标注为「待验证」。
提示：问得越具体，结论越可信。「有没有 XSS」会得到一段泛泛而谈；「检查前端渲染、后端存储、文件下载这三个环节的 XSS」会得到三层交叉验证的结论。
第四步：手术模式——最小改动
摸清楚了、体检完了，才开始动刀。核心是把范围写死：
修复报告里的第 3 号漏洞（订单详情接口越权）。
约束：
- 只允许修改 order_controller.py 和 auth_middleware.py 这两个文件；
- 不新增依赖，不改数据库迁移文件；
- 保持现有 API 响应格式不变；
- 补充三个测试：正常访问、越权访问、参数缺失；
- 改完运行 pytest，把输出贴给我。
对比一下这两种下法的差别：
| 下法 | 结果 |
|---|---|
| 「帮我修一下越权问题」 | 它可能顺手重构了三个模块 |
| 写死文件范围 + 验收标准 | diff 干净，五分钟能 review 完 |
第五步：diff 验收 + 沉淀进 AGENTS.md
改完必须自己看 diff，重点盯四类：
- 边界条件：空值、超长输入、并发有没有考虑；
- 安全问题：有没有硬编码密钥、调试日志泄露信息；
- 误删代码：有没有把不相关的逻辑顺手删了；
- 测试真实性：测试是真在验证行为，还是只断言了 HTTP 200。
确认没问题，把这次的经验固化下来：
把这次修复中形成的规则写进项目根目录的 AGENTS.md，包括：
禁止修改的文件清单、必须运行的检查命令、任务完成的判定标准。
下次新开对话，Codex 会自动读到这些规则，不用你再重复交代。
四种模式速查
| 模式 | 适用任务 | 开场白关键词 |
|---|---|---|
| 侦察 | 读旧项目、找风险、理解结构 | 「先不要改代码」 |
| 手术 | 小范围修 bug、补测试 | 「只改这些文件，最后给我 diff」 |
| 重构 | 拆文件、换结构 | 「分阶段做，每阶段保持可运行」 |
| 维护 | README、部署文档 | 「以别人能复现为标准补齐步骤」 |
别踩这三个坑
一是一句话让它重构整个项目。 范围越大，无关改动越多，review 成本反而超过手写。按可验证的功能切分，一次只解决一个问题。
二是只说「怎么写」不说「怎样算完成」。 与其规定实现细节，不如给出验收条件、兼容要求和测试命令。智能体最需要的是清晰边界。
三是看到「测试通过」就合并。 测试可能覆盖不足，也可能压根没跑成功。提交前看命令的真实输出，别只看它的口头汇报。
把「先读不改 → 复述纠偏 → 最小修改 → diff 验收 → 规则固化」这五步焊进流程，接手任何陌生仓库都不会再手忙脚乱。
来源：公众号《Codex 怎么用？别把它当代码生成器，是你项目目录里第一个 AI 同事》与《Codex 安全审计实战》分享内容，本文为原创转写与流程重构。
资料最后核对日期：2026-08-05 · 内容整理自 CodexGuide 社区公开教程