先整理复现信息
准备最小代码片段、完整错误信息、运行环境和操作步骤。说明预期行为与实际行为。去掉令牌、密码和私人数据；需要示例数据时可以用虚构数据替换，并明确标注。
要求先解释根因
不要直接接受一大段替换代码。先让模型列出可能原因，指出对应代码位置，再提出最小修改方案。对于依赖版本和接口调用，请回到该软件的官方文档核对。
在自己的环境中验证
运行修改后的代码，测试正常输入、边界输入和原来的失败场景。模型给出的代码未经你的运行验证，不应被当作已修复。记录最后有效的修改，方便以后回溯。
最小复现应该包含什么
最小复现需要别人按你的步骤也能看到同一个问题。保留触发错误的输入、必要的函数、依赖版本和完整报错；移除与问题无关的页面和业务数据。如果删掉某段代码后错误消失，就需要重新判断它是否属于关键条件。
不要提交真实密钥、数据库密码或用户信息。用虚构值替换后，要确认替换没有改变数据类型或长度等导致问题的条件。
实操案例：字符串被当成数字相加
虚构的 JavaScript 示例是 const total = "12" + 3，结果是字符串“123”，而预期是数字 15。可以要求 Claude 解释输入类型、指出触发位置，再给出最小修改建议。
如果该字段本应是金额，就不能只加 Number() 而不检查非法输入。需要决定空字符串、字母、负数和小数如何处理，再验证修改是否符合业务规则。例子中的修复思路应在你的实际运行环境中测试。
如何阅读修复建议
先看建议是否对应原始报错，再看它是否引入了新依赖、改变返回类型或吞掉异常。要求模型列出修改前后的行为差异；如果它无法说明为什么这处修改能解决问题，先补充复现信息。
涉及第三方 SDK 时，提供你当前安装的版本，并检查对应版本的官方接口文档。模型可能给出不同版本的写法，不能只凭代码看起来熟悉就直接替换。
验证至少覆盖四种情况
运行原来失败的输入，确认问题消失；运行普通输入，确认原有功能正常；运行空值或极端值，确认边界行为；运行非法输入，确认报错可理解。若修复影响数据库或外部服务，先在测试环境验证。
常见问题：可以把整个项目交给模型吗
上下文越多不一定越容易定位。先提供相关文件和调用链，按模型提出的问题补充。修复完成后记录根因、修改位置和验证方法，避免以后只能重复粘贴同一份报错。