“页面坏了，帮我修一下”往往遗漏了最有价值的信息：操作路径、实际结果和预期结果。本篇用一个虚构的文章编辑页说明如何组织排错任务。你不必提前知道问题出在哪个函数，但需要把自己看到的现象说清楚。

先记录一条完整的复现路径

假设问题是“文章标题保存后，刷新又变回旧标题”。至少记录这些内容：

  • 入口：后台文章管理，打开某篇文章的编辑页。
  • 操作：把标题改成一个容易识别的新值，点击保存。
  • 界面反馈：出现保存成功提示。
  • 实际结果：刷新页面后恢复旧标题。
  • 预期结果：刷新后仍显示新标题。

如果问题只在特定浏览器、账号角色或文章状态下发生，也一起补充。截图适合说明布局，报错文本和网络响应适合说明执行失败；不需要把全部项目文件重复粘贴进对话。

一份可以直接改写的排错任务

请排查文章编辑页标题没有保存的问题。
复现：打开后台文章编辑页 → 修改标题 → 保存 → 刷新。
实际：提示保存成功，但刷新后恢复旧标题。
预期：新标题能被保存，重新打开仍存在。
请先复现，沿表单提交、保存接口、存储和重新读取的路径定位原因。
修复后重新执行这条路径，并验证保存失败时不会误提示成功。
给出根因、涉及文件、实际验证结果，以及尚未验证的部分。

这个示例由本站编写。它给出可观察的结果，没有预先断言是数据库还是前端出了问题，便于排查时比较不同证据。

判断根因时，沿数据走一遍

可以把链路画在纸上：输入框 → 请求内容 → 接口处理 → 持久化 → 读取结果 → 页面显示。要求解释哪一步和预期不一致。例如，请求中没有新标题，修数据库通常不能解决根因；接口返回成功却没有写入，就要核对服务器实际执行情况。

如果暂时无法复现，应继续缩小条件，而不是直接改一个猜测的位置。可以补充是否每次发生、是否只影响某个字段，以及最近是否改过相关功能。

修完以后，要检查相邻场景

这类保存问题可以检查三组场景：正常保存后重新打开；必填项为空时有明确提示；接口返回失败时保留输入且不显示成功。若项目已有相关测试，应复用它们。界面问题还要实际操作页面，单纯构建成功并不能证明交互正确。

官方 Codex 工作流也建议修复后再次执行复现步骤，并运行适合当前问题的检查。查看官方工作流示例。

怎样读最后的修复说明

关注“原因—改动—验证”是否互相对应。如果原因是请求字段遗漏，说明中应能指出补回了哪个字段，以及刷新读取结果的检查。如果只是写了“优化逻辑，问题已解决”，可以要求补充实际证据。

遇到本地没有测试数据、无法登录测试账号等情况，应该明确列为未验证。你可以提供必要的测试条件，但不要把密码和密钥写进公开的问题描述或提交到仓库。

常见问题

一定要给出完整错误日志吗？

先提供出错操作附近的完整报错段，保留错误类型和调用位置；无关的长日志可以后补。发送前遮掉令牌、个人信息和连接凭据。

多个问题一起发会更省事吗？

如果它们来自同一条操作链，可以一起描述关联；彼此无关时，分清每个问题的预期结果，更容易逐项验收。

根因修复后还需要看差异吗？

需要。检查有无无关文件变化、临时调试代码，以及是否为了绕过错误而削弱了校验。然后再按项目流程提交。

继续阅读

用 AGENTS.md 保存项目约定，让后续排错任务沿用相同的验证标准。本文参考 OpenAI 官方提示与工作流文档整理。