只读审计适合原因还没查清、工作区已有改动，或你只想要评估报告的场景。它的交付物是一组可以复核的发现，包括查看过哪些文件、问题证据在哪里、哪些地方仍无法确认。审计结束后再决定是否进入修改。
本文依据 2026 年 8 月的官方资料整理。权限选项和审查入口可能变化，开始前应看清当前项目采用的实际权限范围。
先冻结当前状态
Git 项目先查看分支、未提交改动和未跟踪文件。把结果保存到聊天里，便于区分原有现场与后续操作。非 Git 目录也要记录绝对路径和目标文件清单。
权限配置支持只读边界时，可以选取只读配置。即使没有切换设置，也要在任务里明确禁止修改文件、安装依赖和执行会产生写入的命令。沙箱负责技术边界，文字要求负责本次审计的具体范围，两者共同使用更稳妥。
把调查问题写窄
“检查整个项目”很容易得到一份泛泛报告。可以要求定位某条请求如何经过路由、校验和数据库访问，或核对移动端菜单为什么发生溢出。给出怀疑点时保留它的假设身份，让 Codex 同时寻找能够推翻它的证据。
下面这段请求适合代码审计。
先不要修改文件，也不要安装依赖。请追踪保存设置的完整调用路径，列出读过的文件和关键行，说明最可能的失败位置。证据不足的地方单独标出。
发现必须能够回到来源
每条发现至少要带一个可定位的依据，例如文件行、配置值、命令输出或可重复的页面现象。严重程度要和后果相称。尚未运行服务时，只能写静态代码风险，不能声称线上问题已经复现。
让 Codex 区分已经确认的事实、依据代码作出的推断和仍需实测的部分。报告还应说明没有检查哪些路径。一个清楚的未知项，比补成肯定结论更方便下一轮处理。
时间和版本属于审计材料
软件能力、依赖版本和线上配置会变化。报告需要写明检查日期、当前提交和能够确认的运行环境。引用外部产品行为时使用第一方资料，并保存页面链接。只有旧截图或二手描述时，把它列为待核信息。
同一份代码在开发配置和生产配置下可能走不同路径。没有读取目标环境，也没有运行对应测试时，审计结论只能覆盖已经检查的部分。
用只读复现缩小范围
能够安全运行现有测试或查询日志时，先使用不会修改数据的操作。失败出现以后保存命令、退出状态和第一段有效错误。若复现需要启动本地服务，确认它使用测试配置，也不会连接真实生产数据。
/review 可以检查未提交改动或分支差异，并在不改变工作区的情况下给出问题。它适合检查已有改动，面对尚未定位的运行错误时，仍需从复现步骤和相关文件开始。
审计结束后再开修改任务
先重查 Git 状态，确认审计没有留下文件变化。随后把已确认原因、允许修改的范围和验证方法整理成新的任务单。若决定暂不修复，审计报告也应足以让另一名维护者继续调查。
