Codex 生成本地脚本前怎么做路径白名单和输出预览？
Codex 生成批处理、同步脚本或 SEO 静态页面前，应先明确输入目录、输出白名单、dry-run 结果和回滚证据，避免脚本误扫或误写无关文件。
真实问题
让 Codex 生成本地脚本最常见的事故不是语法错，而是脚本扫描了不该扫描的目录，或者把输出写到了相邻项目。比如维护静态 SEO 页面时，目标只是生成当天 4 篇文章，脚本却递归处理了整个站点，顺手格式化了历史文件。开发者 AI 调用越方便，越需要把路径边界写清楚。永沃云枢在 https://ai.jn83.com 维护 Codex 接入流程时，通常先定义输入清单、输出白名单和 dry-run 结果，再允许写入。
适用场景
适用于 Codex 生成批量重命名、静态文章生成、sitemap 更新、SQL 文本生成、日志汇总、Markdown 转 HTML、测试数据清理等本地任务。它也适合多人协作仓库，因为工作区可能已有用户未提交修改。开始前可先参考 Codex 接入生产仓库前权限审计怎么做 和 Codex 看到工作区已有改动怎么办，把权限与现有差异分开看。
操作步骤
第一步，写出本次允许读取的目录和允许写入的目录，路径要用绝对路径，不要只写“当前目录”。第二步，在脚本参数里加入 dryRun、inputRoot、outputRoot、allowedFiles，默认 dryRun 为 true。第三步，真正写入前先打印计划：将创建哪些文件、修改哪些文件、删除是否为零、每个文件的原因是什么。第四步，对每个输出路径做 Resolve-Path 或等价校验，确认它仍在白名单内。第五步，生成结果后让 Codex 汇总差异、验证命令和未处理风险。
排错路径
如果 dry-run 显示的文件数量异常，先停下看 glob 是否过宽，例如把 seo 写成了项目根目录。若输出路径包含 ..、软链接或临时目录，需要强制解析成绝对路径再比较。若脚本准备覆盖已有文件，先判断它是否属于当天任务，如果不是，就把它列为外部改动，不要重写。涉及首页 SQL、AI API 接入配置或 CCSwitch 配置时，还要确认脚本只生成文本，不连接数据库、不调用后台 API。
常见问题 / 避坑
问：只靠 git diff 能不能兜底？不够，生成脚本可能已经影响了未跟踪文件。问：dry-run 结果太长怎么办？保留文件数、路径前缀和前 20 条样本，异常时再展开。问：能否让 Codex 自动运行修复？可以运行只读验证和白名单内生成，但高风险写入要有明确边界。问：为什么要记录证据链？因为交接时需要知道哪些文件是本轮生成、哪些是历史文件，具体可看 Codex 做完改动后怎么留下证据链。
检查清单
检查输入根目录和输出根目录是否为绝对路径；检查写入白名单是否只包含本次任务文件；检查 dry-run 默认开启；检查脚本没有删除动作；检查日志能说明每个文件的生成原因；检查 Codex 接入专题 的操作说明是否仍适用。验收时故意放一个相邻目录样本，确认脚本不会穿透过去。
复盘建议
脚本完成后，把“允许写入范围、实际写入文件、跳过文件、验证结果、未执行动作”写进交付说明。这个习惯看似繁琐，但能显著降低误改站点、误改配置和误覆盖用户改动的概率。对长期维护的静态资讯栏目来说，路径白名单不是一次性文档，而是每次自动化运行都要重新确认的安全边界。
验收标准
验收时先把脚本的输入目录和输出目录各列一遍，再让 Codex 输出计划清单，确认每个目标路径都能被 Resolve-Path 解析成绝对路径。接着手工挑一个相邻目录样本，验证它不会被脚本误扫、误删或误改。若脚本涉及 SQL 或 sitemap，最好先在本机写出 UTF-8 文本，再检查文件头和 diff，避免上游链路改变编码。再补一次空跑，把输出文件的数量、文件大小和修改时间都记下来，确认没有多出隐含目录、临时文件或缓存文件。
如果要复用到 AI API 接入或 CCSwitch 配置生成器里，也要保持同样的白名单思路：脚本只负责生成文本，不负责执行发布、数据库写入或后台接口调用。这个边界一旦放松，后面排错会变成找谁改了什么，而不是看脚本本身是否合理。Codex 接入本地脚本时，最值钱的不是自动化本身，而是把不可见的写入范围变成可检查的清单。
验收报告里最好单独列出“没有执行”的动作，例如没有删除文件、没有连接远程服务、没有提交搜索引擎、没有修改白名单外页面。缺少这些否定项时，后续复查很难判断脚本到底被限制住了没有。如果 dry-run 清单和实际写入数量不一致，哪怕只差一个文件，也应该停止并重新检查 glob 和路径解析。