让Codex复现错误：整理最小复现案例与环境信息

如果只向Codex提出“帮我修复错误”，它可能会把不同的失败当成同一个问题。首先需要说明，是程序无法启动、特定输入下计算错误，还是只有画面显示不同。好的复现资料并不取决于说明的长度，而在于是否包含能在其他执行中确认相同失败的条件。

本文介绍先复现错误，再请求修复和验证的方法，不以特定模型或付费方案为前提。下面的代码和日志格式是为说明而编写的示例，并非实际项目的执行结果，也不是本博客读者的错误记录。需要区分Codex提出了修改建议与错误实际上已经解决这两种状态。

1. 将错误报告分成四栏

先写明输入、运行步骤、预期结果和观察结果。输入是引发问题的资料，例如文件或函数参数；步骤是处理这些资料的顺序。预期结果是希望遵守的规则，观察结果是实际画面或输出。如果没有写明预期结果，就很难判断消除了异常的修改是否属于正确行为。

栏目	用于说明的填写示例	应避免的表述
输入	数量栏中一个空格字符	输入了奇怪的值
步骤	用该字符串调用示例函数	直接运行了
预期	将其视为空的数量值	应该正常
观察	此次运行出现的异常及其位置	大概是转换错误

这里的观察栏应填写自己实际运行得到的结果。如果从网上复制未经确认的错误信息，可能会复现另一种失败。没有日志时，应将观察结果标为未确认，先请求简短的复现过程。可能的原因应写在单独的栏目中，避免把它们作为已确认的观察结果传达。

2. 从可能改变结果的项目开始整理运行环境

准备工作目录、操作系统、语言运行时、依赖锁定文件、运行命令和当前代码版本。如果是网页画面问题，可以补充浏览器、画面尺寸等相关条件。与其冗长地列出所有设备信息，不如选择重新制造失败所需的条件。版本应使用在当前环境中确认的值，而不是安装说明中写的数字。

遇到“在我的电脑上可以运行”的情况，应以相同栏目比较成功环境与失败环境。先确认代码版本、运行目录和输入文件是否相同，可以逐步缩小差异范围。不要照抄其他环境的命令，应以该项目说明的运行步骤为准。

如果复现需要账号信息，应先考虑能否制作保留失败条件的示例资料，而不是把真实密码或令牌像普通文本一样直接贴上。例如，可以将客户标识符替换为虚构值，但保留字符串长度或空格等错误条件。如果这种替换可能影响结果，也要在复现说明中注明。

3. 最小案例应保留失败条件，而非只追求文件数量少

下面是一个用于说明的Python函数，用来处理数量字符串。它将空字符串视为空值，但仅含空格的字符串会进入另一条路径。这里并不假定它是实际产品中的错误，而是用它来说明如何整理哪些输入应按同一类型处理的规则。

def parse_quantity(text):
    if text == "":
        return None
    return int(text)

如果将要求规定为“空字符串与仅含空格的字符串均返回None，数字字符串转换为整数，字母输入报错”，复现和验证的范围就明确了。现在可以分别确认“只修复了空格输入”和“同时保留了数字输入的原有行为”这两项主张。如果实际产品的空值规则不同，应先修改规则本身。

在大型项目中缩减案例时，应先删除无关画面或数据，并在每次删除后确认相同失败是否仍然存在。如果缩减后错误消失，删除的条件中可能包含相关因素。目标不是得到最短的代码，而是得到同时保留失败与预期行为的小型资料。记录缩减过程本身，也能为回到原项目提供依据。

4. 先请求复现结果，再进行修改的提示词

在第一次请求中，同时写明工作顺序与完成标准。下面是为上述函数案例自行编写的请求格式。文件路径和命令应填写实际项目的值；仅仅提交示例文字，并不意味着Codex已经访问该环境或执行了命令。

请先阅读相关代码，并按照提供的输入与步骤复现错误。在修改前，分别记录预期结果和观察结果，同时留下实际运行命令、退出状态和关键输出。如果无法复现，请在修改代码前说明缺少的环境条件。如果能够复现，请编写确认该失败的小型检查，提出最小修复方案，并使用相同输入再次确认。

这个请求并不是要求所有错误都必须新建测试文件的规则。如果需要反复确认计算或输入处理是否发生回归，自动检查会很有用。如果只是临时的环境设置问题，观察相关条件并确认恢复情况可能更合适。应选择能确认出错路径的证据，而不要把检查文件的数量当作成果。

OpenAI的代码现代化示例展示了一种流程：使用相同输入比较输出与行为，发现差异后进行小幅修改，再次验证。提示词指南也强调修改后进行实际检查。本文的请求格式是将这些原则应用于小型错误的写作示例，并非官方产品菜单，也不是规定必须使用的提示词。

5. 同时验证失败输入与正常输入

在数量示例中，可以分别检查空字符串、空格、数字和非数字字符。如果为了处理空格而将所有转换异常都改为None，字母输入也可能被悄悄置为空值。若实际要求是让字母输入报错，这样的修改即使减少了异常，也改变了规则。

用于说明的输入	规定的预期结果	检查目的
空字符串	None	保留原有空值规则
仅含空格的字符串	None	处理失败条件
字符串12	整数12	维持正常转换
字符串abc	转换错误	不掩盖无效输入

每项检查都应分别写明修改前与修改后的结果。如果修改前只检查空格输入，修改后却只检查数字，就无法对照确认是否修复了相同失败。两次运行的代码和输入也应按照相同标准对齐。如果尚未确认结果变化的原因就删除失败检查，可能会丢失用于确认回归的资料。

6. 规定无法复现时应停下的位置

无法复现时，应检查差异，而不是宣布成功。逐项比较运行目录、输入文件编码、依赖、当前设置和代码版本中可能改变结果的因素。如果原本的失败是间歇性的，可以记录运行次数以及成功、失败的条件，但不能凭任意一次成功就认定没有问题。

如果Codex无法执行命令，应将执行限制与代码分析结果分开理解。从代码中找到可能的原因虽有帮助，但不能替代复现证据。可以要求在最终回答中分别列出“通过静态分析找到的候选原因”“实际复现”“修改后确认”以及“未能确认的条件”。

如果缩减数据后能够复现，但原服务中仍有额外失败，应确认两个问题之间的联系。不要将小型案例的成功扩大解释为整个服务的成功。最小案例是帮助理解原因的工具；要判断实际问题已经解决，还需要确认原来的失败路径。

7. 阅读结果文件与修改内容的顺序

工作结束后，先阅读复现记录，再确认修改了哪些文件。然后对照相同失败输入的修改后结果与正常输入的结果。最后阅读未能执行的检查和剩余的不确定性。即使回答很长，只要缺少这四类证据，仍可以再次请求所需结果。

例如，报告写着“所有检查均通过”，却没有实际命令或检查对象，就应询问究竟确认了哪些条件。反过来，即使只执行了一项小型检查，只要明确确认了实际错误路径，在该范围内也能成为有用证据。如果需要扩大确认范围，应说明其必要性并指定额外条件。

复现记录的文件名可以附上代码版本或运行序号。如果用同一个文件覆盖修改前与修改后的输出，就会失去比较依据，因此应分别保存。发生异常的行会随着代码修改而移动，所以最好同时留下行号与对应的函数名称。

回退修改时，应区分工作开始前的状态与此次修改。如果用户已经修改的文件与Codex的修改混在一起，应先比较修改内容，而不是整体恢复。审查修复方案与实际应用到服务的阶段也应分开。请求复现错误，是建立原因与修复依据的起点。

官方来源与编写标准

• OpenAI：使用Codex实现代码库现代化
• OpenAI：提示词工程

资料确认日期：2026-10-06。本文是AI根据实际打开的官方资料编写的说明。另行标明的计算、代码与检查案例仅用于说明，并非直接测试用户环境或实际测量的结果。在准备发布的阶段，已再次检查功能与官方资料是否发生变化。