Codex 接手项目时只读和可写范围怎么划清？

把 Codex 放进真实项目之前，应先区分只读扫描、允许修改目录、禁止命令和上线边界，减少误改配置和跨站风险。

• 站内相关：让 Codex 执行命令前怎么确认风险
• 站内相关：Codex 怎么处理工作区未提交修改
• 站内相关：脚本白名单 dry-run 检查
• 站内相关：Codex 安装与插件专题
• Codex 实操与 AI 资讯栏目

真实问题：为什么要先划边界

很多团队第一次做 Codex 接入时，只写一句“帮我维护这个项目”，然后把整个仓库、远程主机和数据库都放在同一个任务里。问题不在 Codex 能不能完成，而在任务边界没有被机器和人同时看懂。一个 SEO 静态栏目可能只需要读旧文章、写新 HTML、更新 sitemap 和首页 SQL，如果提示里没有说清楚禁止触碰 keys、server、支付、注册和其它站点，后续排错就会很被动。永沃云枢在维护 https://ai.jn83.com 这类站点时，更推荐把权限拆成可读、可写、可上线、不可碰四层，让 Codex 接入从一开始就带着审计线。

适用场景

这个方法适合站长、开发者和运营共同维护 AI API 接入文档、Codex 实操资讯、CCSwitch 配置页、模型调用管理页和 AI 自动化办公案例。尤其适合多人共用一个仓库、远程服务器上还跑着生产服务、首页内容通过 SQL 写入 public.settings 的场景。它不解决所有安全问题，但能把误改范围从口头提醒变成具体检查项。

操作步骤

第一步，列出允许读取的目录，例如 seo/codex-news、seo/sitemap.xml、seo/robots.txt、sql 历史首页文件和必要的提示文件。第二步，列出允许写入的白名单，最好精确到当天目录和当天 SQL 文件，例如 seo/codex-news/含日期的 slug、publish-urls.txt、sql/apply-home-news-日期.sql。第三步，把禁止项写成明确名词，不要只写不要乱改，而要写 server、admin-tools、keys、支付、登录、注册、全量后台设置接口。第四步，把远程目录也限定清楚，例如只允许 /opt/sub2api 下与 ai.jn83.com 对应的静态文件，不允许顺手检查其它站点。第五步，要求 Codex 在编辑前先说明会修改哪些文件，并在完成后输出文件清单、验证命令和未完成事项。

排错路径

如果发现 Codex 生成了不该出现的文件，先不要直接删除整个目录，而是看 git diff 或文件时间戳，区分本次新增和历史遗留。若首页 SQL 变短，说明可能只生成了资讯卡片片段，应回到最近一个完整 SQL，从完整 HTML 中替换新闻区。若 sitemap 或 robots 被写成乱码，要检查编码是否为 UTF-8 且 sitemap 前三字节不是 BOM。若 AI 模型接口文档里出现保证收录、永久稳定等无法验证说法，应在发布前删掉。

常见问题 / 避坑

问：只读扫描能不能包含 server 目录？答：可以由任务决定，但如果当前目标只是 SEO 静态资讯，读 server 往往没有必要。问：能不能让 Codex 自动运行部署脚本？答：只有提示明确允许上线并限定目标目录时才做；否则先生成本地文件和验证报告。问：为什么要写远程路径？答：因为本地 seo 目录和远程 /opt/sub2api/seo 不是同一个边界，少写一层就容易验收错位。

检查清单

检查白名单是否包含当天 4 篇文章目录、栏目页、sitemap、robots、publish-urls 和首页 SQL。检查禁止项是否覆盖全量设置接口、keys、支付、注册、邮件、验证码和其它站点。检查每篇文章是否有 canonical、JSON-LD、至少 4 个站内链接和 1500 个以上中文字符。检查上线后 /codex-news/、4 个新 URL、/sitemap.xml、/robots.txt、/image、/custom/canvas-workbench 是否可访问。

验收示例：把边界写成可以复查的证据

一次比较稳妥的交接记录应该包含三类证据。第一类是允许修改清单，明确本次只改 seo/codex-news 当天目录、栏目页、sitemap、robots、publish-urls 和首页 SQL；第二类是禁止修改清单，明确不碰 keys、server、支付、注册、登录、人机验证、邮件和其它站点；第三类是验证结果，写清每个新 URL 是否在 sitemap 中、首页 SQL 是否只有一条 UPDATE public.settings、是否带 WHERE key = 'home_content'。如果后续发现线上页面异常，接手的人可以按这三类证据快速判断问题是在内容生成、上传、数据库写入，还是搜索引擎推送环节。这个记录不需要很长，但必须能让另一个没有参与当天任务的人复盘。

现场记录建议

实际执行时，可以要求 Codex 在动手前先列出“将会修改”和“不会修改”的文件。完成后再把 git diff、URL 列表、乱码检查、去重结论和未完成事项放到同一段结果里。这样做的价值不是增加仪式感，而是把模型调用管理、Codex 接入和静态 SEO 发布之间的责任边界固定下来。尤其在 https://ai.jn83.com 这类同时包含 AI API 接入、CCSwitch 配置和 AI 自动化办公入口的站点上，首页开放状态、注册状态和搜索栏目并不是同一个风险等级，不能混在一起处理。