Codex 接手陌生项目怎么开始：先建地图，再改一处，再跑一次验证

接手一个陌生仓库，最危险的动作往往是“先改了再说”。页面、接口、配置和部署脚本可能跨越多个目录，一处看似简单的调整也可能影响缓存、权限或数据迁移。把 Codex 用在第一天的正确方式，是让它帮助你建立地图，而不是替你猜答案。

第一轮只回答四个问题

1. 项目如何启动、测试和构建？
2. 这项功能的入口文件、核心逻辑和数据来源分别在哪？
3. 仓库是否已有约定，例如贡献说明、测试规则或环境变量要求？
4. 哪一种最小验证能证明改动没有跑偏？

让 Codex 先列出目录职责和调用链，并要求它标出“不确定之处”。不要要求它直接“修好项目”；把问题缩成“找出订单状态从接口到页面的流向，并列出相关文件”。

第一处改动要小到可回退

选择一个能在本地复现、影响面有限的目标：修一条文案、补一个空值分支、增加一条测试。要求 Codex 先给出修改计划和涉及文件，确认后再写。完成后看 diff，而不是只看它的解释。

请先不要修改代码。输出：
1. 功能入口到数据来源的文件路径；
2. 最小修改方案；
3. 我应运行的验证命令；
4. 你无法确认的假设。

接手的第一个交付物不是大量代码，而是一张可信的项目地图和一处可验证的小改动。后续再用代码审阅的四步流程检查每个变更。