Codex 接手大型仓库总找错入口怎么办？
大型仓库里同名目录、旧页面、测试样例和生成产物很多。Codex 接入后如果一上来就改文件，很可能把历史入口当成现用入口。更稳的做法，是先用只读扫描画一张目录地图，再用小样本验收确认改动位置。
真实问题
很多团队把前端、后台、静态 SEO、脚本和历史实验代码放在同一个仓库。页面可能同时出现在 pages、app、server、admin-tools、seo 和 dist 里，某些目录还只是旧版本留档。让 Codex 直接“改首页”“修 API”“更新文章”，听起来很明确，落到文件系统里却不一定明确。永沃云枢在 https://ai.jn83.com 的维护流程里，会先确认当前运行入口、发布入口和允许写入目录，再让 Codex 动手。
适用场景
适用于多端项目、静态站和业务后台混放、AI 自动化办公脚本和网页项目共仓、Codex 需要根据用户描述找文件、团队没有最新架构图的情况。它也适合开发者 AI 调用相关项目，因为 API 路由、SDK 示例和真实服务入口经常同名。新手可能把整个流程理解成“让 GPT 中转帮我改代码”，更准确的说法是把 AI 模型接口能力接入到受控的本地工程流程里。
先画目录地图
目录地图不是正式文档，也不需要漂亮。它只回答四个问题：用户看到的页面来自哪里，接口请求落到哪里，构建产物放在哪里，哪些目录本次禁止修改。地图里要标出入口文件、路由文件、配置文件、测试样例和生成目录。对于 Codex 接入来说，这一步的价值是把上下文从“所有文件”缩小到“相关文件”，避免模型调用管理消耗在无关搜索上。
操作步骤
- 先只读列目录，记录一级和二级目录，不要递归打开所有文件。
- 根据任务关键词搜索入口，例如 title、路由路径、API path、CSS class、组件名和数据库 key。
- 把命中的文件分成现用入口、旧入口、测试样例、生成产物和未知五类。
- 查看启动脚本、构建配置和 sitemap，确认真实页面不是从 dist 或缓存里来。
- 在用户允许的目录里选择最小改动点，先改一处可验证文本或样本，不批量重构。
- 运行本地检查命令，确认改动被当前入口引用，再继续处理正文、样式或接口逻辑。
检查命令
没有 rg 时，可以用 PowerShell 做基础扫描。示例：
Get-ChildItem -Path . -Directory | Select-Object Name
Get-ChildItem -Path . -Recurse -File | Select-String -Pattern "home_content"
Get-ChildItem -Path . -Recurse -File | Select-String -Pattern "Codex 实操"
这些命令只用于定位，不应该顺手改文件。若任务涉及自动生成脚本，要结合 路径白名单和 dry-run 预检，先看输出预览再写入。
常见问题 / 避坑
问：为什么不能直接让 Codex 全仓搜索后修改？可以搜索，但不能把所有命中都当成现用入口。问：目录地图会不会浪费时间？对小项目可能是多一步，对大项目通常能省掉多次返工。问：已有未提交改动怎么办？先按 未提交变更隔离流程 标记哪些是用户改动。问：AI API 接入项目也要这么做吗？要，接口示例、mock 服务和真实网关常常混在一起。
检查清单
- 是否列出当前任务允许读取和允许写入的目录。
- 是否确认页面入口、接口入口、构建产物和发布产物的关系。
- 是否区分现用入口、旧入口、测试样例和生成目录。
- 是否先做一处小样本验收，再扩展到完整改动。
- 是否保留命令输出、文件路径和验收结果，便于下一位同事接手。
- 是否把 Codex 接入、CCSwitch 配置和 AI 自动化办公脚本的边界写清楚。
交接记录
目录地图做完后，最好把它放进任务交接记录，而不是留在临时对话里。记录格式可以很简单：本次目标、确认过的入口文件、排除的旧目录、允许修改的路径、禁止触碰的路径、验证命令和未确认风险。对于依赖 AI API 接入或 CCSwitch 配置的项目，还要写明配置文件只读还是可改。这样下一轮 Codex 接手时，不必重新扫描全仓，也能减少误覆盖用户已有改动的概率。
如果仓库里有多个相似前端入口，还可以让 Codex 先找一段页面上独有的文案，再反查它来自哪个模板或数据源。这个动作比凭目录名判断更可靠，也更适合静态页面、后台配置页和自动生成内容混在一起的项目。