从工程实践看，Codex限制条件应被当作一个可审查流程，而不是一次聊天。限制应具体到文件、接口、URL、数据和行为。
未说明保留范围时，代理可能顺手格式化或重构无关代码。这类偏差往往不会立即报错，而会在差异审查、测试或部署阶段出现，所以必须从源头限定范围。
本题涉及的功能可能更新，应优先查阅官方页面。OpenAI Docs建议把目标、上下文、限制和验证方式写清楚；复杂任务还需要明确阶段、停止条件和可观察结果。同时记录查阅日期。
更稳妥的顺序是先保存基线，再列出必须保留的路径、配置、兼容性和用户数据，并说明允许改动的边界，最后用相同条件复测。这样才能把变化归因于本次操作。
可把验收写成自动检查加人工审查。自动部分运行命令，人工部分用Git差异检查是否触及禁止范围，最后共同形成结论。
代码示例和命令应以文本呈现，不能只放在截图里；页面同时提供可抓取正文、规范URL和清楚的标题层级，便于长期索引。
为了让Codex限制条件能够被另一位成员复现，任务记录至少包含四个检查点：PRESERVE、BOUNDARY、DIFF、VERIFY。这些英文标签也可用于分支、日志或看板检索。
一次合格复盘要同时回答两件事：是否做到“用Git差异检查是否触及禁止范围”，以及是否出现“只写不要乱改过于模糊，无法转化为可执行规则”。前者决定是否继续，后者决定是否暂停、回滚或补充授权。
最终交付前还要打开生成文件、检查格式和数量。仅看到命令退出为零，不能证明用户真正拿到了可用产物。
对非技术用户，交付说明应把“已修改文件”“已执行检查”“尚未验证事项”分开写，避免把技术日志当成最终结果。
安全与效率不是二选一。只写不要乱改过于模糊，无法转化为可执行规则；通过最小权限、明确目标和自动验证可以同时减少等待与事故。