测试

代码生成结束不等于任务完成。补丁可能通过编译，却在错误处理、并发、权限或兼容性上留下回归；也可能修复了症状，却没有覆盖真正的根因。让 Codex 在交付前承担一次独立审查，可以显著提高发现问题的概率，但前提是审查范围明确、发现有证据、修复后重新验证。 先固定审查基线 Codex 的 /review 可以针对不同差异工作：与基础分支比较适合模拟 Pull Request 审查；审查未提交改动适合提交前检查；指定提交适合确认一个独立变更；自定义说明则用于聚焦安全、边界条件或性能。 选择范围时，先回答“这次准备交付的变化到底是什么”。如果工作区混有实验文件，直接审查全部未提交内容会制造噪声；如果功能分散在多个提交，只看最后一个提交又会丢失上下文。开始前查看 Git 状态和差异基线，确保代理看到的内容与评审者将收到的内容一致。 /review Focus on regressions, error handling, authorization boundaries, and missing tests. Ignore formatting unless it changes behavior. 好的聚焦说明描述风险，而不是预设结论。不要要求“找出至少五个问题”，这种指标会鼓励低价值发现。也不要把格式化规则交给模型反复评论；能够由 lint 或格式化工具稳定执行的规则，应该交给自动化检查。 要求可行动的发现 一条有效发现应包含位置、触发条件、实际影响和判断依据。严重程度应反映用户或系统风险，而不是措辞强度。阻断数据写入、绕过权限或导致崩溃的问题优先级高；只影响极端日志格式的建议不应与它们并列。 收到发现后不要立即批量接受。先让 Codex 展示相关调用路径、构造最小复现，或者指出违反了哪项现有约束。对于依赖框架行为的判断，应查看项目锁定的版本和官方资料。证据不足的猜测可以保留为待确认风险，但不应该包装成已经证实的缺陷。 团队反复强调的领域规则可以写进最接近代码的 AGENTS.md，例如支付流程不得基于请求中的展示金额结算。规则要说明应阻止的行为，同时给出安全路径或例外。Codex Code Review 是额外评审者，不替代分支保护、必需审批和测试门禁。 从发现走到验证 审查闭环可以固定为五步： 复现：在修改前证明问题存在，记录输入、环境和失败结果； 修复：只处理已确认问题，避免借机重写无关代码； 回归测试：优先添加一个修改前失败、修改后通过的针对性测试； 扩大检查：运行相关测试后，再执行仓库要求的 lint、类型检查和构建； 复审：重新运行 /review，确认原发现消失且补丁没有引入新风险。 并非每个问题都能自动化测试，例如只在特定外部系统发生的故障。这时应提供最强的可重复验证手段，如最小脚本、日志对比、截图或人工步骤，并明确记录证据缺口。不能验证和已经验证是两种完全不同的交付状态。 测试范围应与改动风险匹配。纯函数修复通常从单元测试开始；跨模块契约要覆盖调用双方；数据库迁移需要前向、回滚和旧数据场景；界面变化还要检查交互、窄屏和无障碍状态。只运行最容易通过的测试，并不能证明真实行为正确。 让人工评审关注真正的取舍 自动审查最适合扫描遗漏、追踪调用路径和执行重复检查。人仍然需要判断需求是否正确、风险是否值得、界面是否符合预期，以及一次改动是否应该现在发布。让 Codex 在提交前整理变更摘要、验证命令和剩余风险，可以把人工注意力从机械核对移到这些取舍上。 合并前的最终记录应该足够具体：审查的是哪个分支或提交，接受并修复了哪些发现，哪些发现被判定为误报，运行了哪些命令，以及是否仍有未覆盖场景。这样的记录既方便 Pull Request 评审，也为后续回归提供可追踪依据。 交付清单 审查范围与准备提交的差异一致； 高优先级发现有明确位置、影响和复现证据； 修复包含针对性回归测试，或明确记录无法测试的原因； 仓库规定的检查全部运行并报告结果； 修复后完成复审，最终仍由人决定是否合并。 上一篇：从模糊需求到可验证补丁 ...