GPT88 / API Docs

Codex 实战四：审查当前改动，再逐项修复

审查真实代码改动，按文件位置、用户影响和验证证据整理问题。

适用范围：涉及账户、Key、模型、计费或接口的内容，请以 GPT88 当前控制台和对应 API 文档为准。

返回教程库

GPT88 使用说明 模型名、版本、默认值和平台入口可能随客户端版本变化，请按 GPT88 当前模型目录和客户端显示核对。

快速开始 · 模型导航 · GPT88 API Key 管理

代码能构建，不代表行为正确。一次有用的审查，应回答改动是否引入权限漏洞、边界错误或已有功能回归，并提供可核查的依据。这一课把“发现问题”和“修改代码”分成两个明确步骤，方便你控制范围。

先确定审查对象

审查未提交改动、某个提交，或者相对主分支的全部变更，是不同范围。不要只说“检查一下项目”。以下命令可帮助查看当前工作区，但 Git 差异不会包含未跟踪文件的正文。

git status --short
git diff --stat
git diff
git diff --cached

如果需要审查新文件，应让 Codex 同时读取相关未跟踪文件。审查分支时，还要指定实际存在的基准分支；不要默认每个仓库都叫 main。

第一步：只读审查

把范围、重点和报告格式一起说明。要求只读能避免它边检查边修改，导致你无法区分原始问题和后续修复。

请审查当前工作区未提交改动，包括已暂存、未暂存和相关新文件。
只报告本次改动引入或暴露的可行动问题，暂时不要修改文件。
阅读必要的调用方、接口实现和测试，重点检查：
权限与租户隔离、输入边界、分页与空状态、旧功能回归。
每个问题给出严重程度、文件位置、触发条件、实际影响和证据。
区分已确认问题与待验证疑点，不把个人代码风格偏好作为缺陷。
如果没有发现问题，也要说明审查范围和未验证部分。

审查可以运行现有检查，但应先识别项目脚本与必要环境。需要修改文件才能验证的内容，先报告方法和限制，留到修复阶段执行。

用具体问题检查四个方面

以订单筛选功能为例，可以用下面的表格核对审查是否触及关键路径。权限检查应结合后端实现，不能只根据页面是否隐藏按钮下结论。

方面具体检查点
权限查询是否保留登录校验与当前用户的数据范围
边界空关键词、纯空格、无效状态和超出范围页码如何处理
回归筛选后翻页、清空条件、接口失败是否仍符合原约定
证据问题能否对应实际调用链、请求或失败检查

例如，“订单接口没有权限控制”过于笼统。有效发现应指出新增查询路径漏用了现有用户过滤条件，并解释在何种请求下会读到其他用户的数据。如果没有可验证证据，就应保留为待确认项。

第二步：选择问题并修复

确认报告后，再单独给修复指令。可以先处理高影响问题，暂缓纯优化建议。下面示例中的编号应替换为审查报告里的真实编号。

请修复审查报告中的问题 1 和 2。
先说明各自根因和最小修改范围，再实现并验证。
保留已有业务约定与其他未提交改动，不做无关重构。
使用项目已有验证方式覆盖问题的触发条件与正常路径。
不要提交、推送或部署。完成后列出修复文件和检查证据。

如果修复涉及共用组件，还需要检查受影响的其他调用方。不要为了让一条测试通过，删除权限条件、放宽断言或跳过失败用例。

第三步：复审最终差异

修复本身也可能产生新问题。最后审查实际保留下来的全部差异，并确认最初发现的触发条件已经消失。

请复审现在的最终差异，确认问题 1 和 2 已解决，
并检查修复是否引入新的边界或回归问题。
输出仍存在的问题、已经验证的行为、实际检查命令及结果。
无法验证的部分明确说明原因；不要把“未发现”写成绝对安全保证。

验收清单

  • 审查范围明确，相关新文件与调用链都已纳入。
  • 每个发现有触发条件、影响和文件位置，严重程度有依据。
  • 只修复选定问题，修复证据覆盖异常和正常路径。
  • 最终差异完成复审，未验证范围在交付时清楚可见。

常见问题

没发现问题，是否可以直接上线

仍应按项目现有流程完成测试、业务验收和发布检查。审查结论只覆盖当时看到的代码与证据。

报告里都是命名和格式建议

补充审查目标：优先查找会导致错误结果、权限泄漏或回归的具体问题，并要求给出可验证场景。

相关链接