让Codex直接接手整个项目看起来很快，实际最容易丢掉范围、证据和回滚点。
从目录树开始逐个文件解释，信息很多却没有主线。真正需要先知道的是入口在哪里、数据怎么流动、改动如何被构建和验证。
所以这篇文章只解决一件事：用少量关键文件建立现有项目的结构地图和安全修改路径。这套流程先控制一个小范围，确认有效后再扩大，避免把第一处错误复制到全部材料。
适合谁
适合接手陌生网站、脚本或仓库，需要先知道文件怎么协作再修改的人。
不适合的情况也很明确：任务没有边界、原件无法恢复、关键事实无人负责，或最终结果准备直接对外发布。先解决这些前提。
Codex可以读取项目、修改文件和执行命令，因此先使用副本或版本控制，明确禁止触碰的目录与生产环境。高风险操作、唯一原件和最终判断必须留给人工。
开始前准备
- 项目目录与说明文件
- 启动、构建和测试命令
- 一个具体要解决的问题
- 建立一个测试副本或新目录，不直接操作唯一原件。
- 写下一句验收标准：结构说明能回答入口、内容源、生成物、验证命令和风险边界，并与实际命令输出一致
准备材料时，把“必须原样保留”“允许调整”“信息不足时禁止猜测”分开写。三类边界混在一句话里，执行时最容易被忽略。
完整步骤
第一步之前：先做一个最小样本
小样必须足够小，出现问题时能回到具体输入和步骤；也要足够真实，不能只用一个刻意简化、永远不会出错的示例。
第一步：读取项目说明和入口
先找规则、README、包管理配置、主入口与构建脚本。
把“关键文件清单”作为本轮留存证据。后续合并或扩大范围时，都应能用它复盘。
第二步：沿目标功能追踪数据流
从页面或命令入口追到数据、模板、处理逻辑和输出，不平均阅读全部文件。
先停在这里检查一次。此时应已经形成“目标功能关系图”，并且能回到原始材料说明它从哪里来。
第三步：确认生成物与手写源
识别哪些文件会被重新生成、哪些文件是唯一内容源。
这一阶段的完成标志不是工具有回复，而是“可编辑与生成文件边界”已经可供人工检查。
第四步：用只读命令验证理解
运行列表、构建说明或现有测试，比较实际输出与结构判断。
继续下一步之前，抽查“项目理解摘要与证据”中的边界项和异常项；发现前提不成立就先修正。
第五步：人工验收并沉淀流程
不要在第五步继续扩写内容，而是做对账：输入是否齐、步骤是否留证、结果是否可恢复、风险是否有人确认。
实际示例
接手文章站时，从package.json找到build-articles脚本，再追到Markdown、模板和输出HTML。这样能知道应编辑content而不是直接改生成页面。
可以先这样描述任务：
我正在处理“用少量关键文件建立现有项目的结构地图和安全修改路径”。已有材料包括项目目录与说明文件、启动、构建和测试命令、一个具体要解决的问题。请先不要扩大任务范围，也不要补造缺失信息。先完成“读取项目说明和入口”，输出可以人工检查的中间结果；我确认后，再继续“沿目标功能追踪数据流”。最终请按照“结构说明能回答入口、内容源、生成物、验证命令和风险边界，并与实际命令输出一致”列出验收结果和仍需人工确认的内容。
这个任务描述故意先要求中间结果，再允许继续。对高风险或范围较大的工作，可以在每一步都保留同样的确认点。
常见问题与报错
项目没有README或说明已经过期
把构建配置、启动脚本、最近变更和实际命令作为证据，明确标记推测；不要用旧文档覆盖当前事实。
任务跑了很久，却说不清改了什么
先要求列出计划和预计修改文件，每个阶段输出变更摘要、diff、命令和未解决项；没有检查点的长任务应暂停后重新拆分。
一次修改太多文件，出现问题无法定位
回到版本控制或副本，按一个目标一组文件重新执行；每批修改后立即运行对应检查，不把多个不相关需求放进同一次任务。
排查时先看实际读取文件、修改diff、命令和输出。一次只调整一个范围或规则，避免把多个故障叠在同一次执行里。
完成后的检查方法
- 结构说明能回答入口、内容源、生成物、验证命令和风险边界，并与实际命令输出一致
- 关键结论能回到原始材料、文件、命令输出或当前控制台。
- 没有把缺失信息、推测内容或示例数字写成已经确认的事实。
- 重要文件保留原件、版本或可恢复副本，敏感信息没有进入公开内容。
- 结果已经由真正负责这项工作的人审阅，而不是只看页面是否生成。
最后再问自己一次：这份结果解决了最开始的问题，还是只生成了另一份需要重新整理的材料？只有前者才算完成。
资料来源
- OpenAI Codex文档
用于核对Codex的产品定位和当前官方使用说明。
- OpenAI AGENTS.md指南
用于核对项目级规则文件的作用范围；具体行为以当前Codex版本为准。
FAQ
可以一次把整个任务交给Codex完成吗？
不建议一次交付全部范围。先按本文步骤完成一个小样，用“结构说明能回答入口、内容源、生成物、验证命令和风险边界，并与实际命令输出一致”验收，再决定是否扩大范围。
遇到“项目没有README或说明已经过期”应该先检查什么？
把构建配置、启动脚本、最近变更和实际命令作为证据，明确标记推测；不要用旧文档覆盖当前事实
完成后还需要人工检查吗？
需要。AI或执行工具负责推进流程，最终仍要由你根据原始材料、任务规则和“结构说明能回答入口、内容源、生成物、验证命令和风险边界，并与实际命令输出一致”完成验收。