让 Codex 帮忙修复代码报错时，怎样提供信息并验证修改是否有效？

关键是提供可复现的问题、相关代码和明确的预期，再用实际运行结果验证修改。只给最后一行报错，通常不足以判断根因。

先说明问题如何出现。写清执行了什么命令或操作、预期结果是什么、实际发生了什么，以及问题是否每次都能复现。如果最近修改过依赖、配置或相关代码，也应说明。环境信息可以包括操作系统、编程语言版本、框架和相关依赖版本，以项目实际信息为准。

提供足够但精简的材料。粘贴完整的相关错误堆栈、出错位置附近的代码、调用入口和必要配置。代码较多时，可以先提供能触发问题的最小示例，同时保留与错误有关的输入和条件。不要发送密码、访问令牌、私钥或真实用户数据；使用脱敏内容替代，并保留原有数据结构。

明确修改范围。例如：“请先根据报错和代码解释可能原因，再给出最小修改；保持现有接口不变，不升级依赖。如果信息不足，请指出缺少什么。”这样的要求能帮助控制改动范围，但仍需检查最终方案。

验证时分三步。第一，审查改动，确认没有无关重构或意外删除。第二，用原来触发错误的操作重新运行，检查结果是否符合预期。第三，运行与修改相关的现有测试，并检查正常输入、边界输入及错误输入。涉及公共函数时，还应检查主要调用方。

如果无法运行代码，应把方案视为待验证的建议。若验证失败，将新的报错、执行命令和实际输出继续补充给 Codex；不要仅以“代码看起来合理”或“报错消失了”作为修复成功的依据。