一个订单统计脚本报了KeyError。把错误贴给 AI它建议把字典取值改成.get()。重新运行红色报错没了。但这时应该多问一句如果一笔已支付订单没有金额程序把它当成零统计结果还可信吗用 AI 排查 Python 报错最容易漏掉的环节就是检查“代码能运行”和“结果符合业务要求”之间的差距。拿一个可以直接运行的例子把这个过程走一遍。一、先把错误缩小到能复现的代码假设我们要统计已支付订单的总金额单位为分。下面是教学用模拟数据不涉及真实订单orders[{status:paid,amount_cents:1200},{status:pending},]totalsum(order[amount_cents]fororderinorders)print(total)保存为demo.py运行python demo.py程序会报KeyError: amount_cents原因很明确第二条订单没有amount_cents代码却直接读取了这个键。Python 官方文档对KeyError的说明也是访问映射中不存在的键时会触发该异常。参考Python 内置异常文档不过定位异常还没完成业务分析。这段代码还遗漏了一个要求只统计已支付订单。第二条订单尚未支付本来就不应该参与金额汇总。如果只问 AIKeyError 怎么解决它拿到的信息不足可能只围绕“如何避免访问不存在的键”给建议。更有用的问法是我想统计已支付订单的金额但代码对未支付订单也读取了金额。请结合输入和预期结果定位问题。错误名称一样提供的任务上下文不同排查方向就不同。二、给 AI 的材料要能说明现场不必一开始就粘贴整个项目。先准备这些信息信息本例应该提供什么运行环境Python 版本、是否依赖第三方库任务目标只累计已支付订单的金额最小代码上面的两条数据和汇总代码实际结果KeyError: amount_cents预期结果输出1200单位为分业务约束已支付订单缺少金额时必须报错真实项目还应保留与问题相关的完整调用栈包括异常链。只截最后一行有时会漏掉错误从哪里传进来。提交前替换日志里的令牌、账号、客户数据和内部地址代码也只提供获准分享的部分。可以直接复制这段提示词再补上自己的代码和日志请协助排查一个 Python 错误。 【运行环境】 填写实际 Python 版本、相关依赖版本。 【任务目标】 统计订单列表中 status 为 paid 的金额总和。 金额字段为 amount_cents单位是分。 【实际结果】 出现 KeyError: amount_cents。 【预期结果】 示例数据应返回 1200。 【业务约束】 1. 未支付或缺少 status 的订单不参与统计。 2. 已支付订单必须提供 amount_cents。 3. 金额必须是非负整数不接受布尔值。 4. 已支付订单的数据不合法时抛出 ValueError。 5. 不安装新依赖不修改输入数据。 【最小复现代码】 在这里粘贴代码。 【完整相关报错】 在这里粘贴脱敏后的调用栈。 请按以下顺序回答 - 说明代码中可以直接确认的事实。 - 区分异常触发原因和业务逻辑遗漏。 - 信息不足时指出缺少什么不要补造背景。 - 给出满足约束的最小修改。 - 提供正常输入、边界输入、异常输入的验证用例。 - 不要通过捕获所有异常或随意填默认值掩盖问题。这段提示词的重点是把验收条件提前说清楚。AI 才能围绕具体条件提出修改而不是自行决定缺失数据应该怎么处理。三、为什么加一个默认值还不够常见的修改建议是totalsum(order.get(amount_cents,0)fororderinorders)在当前两条数据上它确实能得到1200。但换成下面的数据orders[{status:paid,amount_cents:1200},{status:paid},]结果仍然是1200。第二笔已支付订单缺少金额的问题被默认值零隐藏了。而且这段代码依然没有筛选支付状态。如果未支付订单也携带金额它也会被计入。.get()本身没有问题。要检查的是这个默认值是否符合字段含义。同一个示例碰巧算对不能证明修复正确。补充一个能区分不同实现的输入往往比再让 AI 解释一遍更有效。四、把业务规则写进修复代码按照前面的约束可以写成下面这样deftotal_paid(orders):total0forindex,orderinenumerate(orders):iforder.get(status)!paid:continueifamount_centsnotinorder:raiseValueError(f第{index}条已支付订单缺少 amount_cents)amountorder[amount_cents]iftype(amount)isnotintoramount0:raiseValueError(f第{index}条已支付订单金额必须是非负整数分)totalamountreturntotal orders[{status:paid,amount_cents:1200},{status:pending},]print(total_paid(orders))运行结果1200这里有几个值得看清的细节。先判断状态再读取金额。未支付订单被跳过因此不会因为没有金额而触发错误。已支付订单缺少金额时保留明确失败。程序主动暴露不满足约定的数据便于继续追查来源。金额使用整数分。示例无需处理浮点金额的舍入问题真实系统仍需约定币种、精度和退款口径。这里刻意使用type(amount) is int。目的是只接受整数类型并排除布尔值。它是本例的输入约束不是要求所有项目都采用这种类型检查方式。异常信息中的位置索引从零开始。示例还假定输入是字典组成的列表只演示已支付订单的金额校验。来自外部接口的任意数据仍需要在入口验证整体结构。五、用反例检查 AI 的修改把下面的代码接在total_paid函数后面保存后运行# 空列表asserttotal_paid([])0# 正常订单未支付订单即使有金额也不能计入asserttotal_paid([{status:paid,amount_cents:1200},{status:pending,amount_cents:9900},])1200# 零金额是允许的asserttotal_paid([{status:paid,amount_cents:0},])0# 按本例约定缺少状态的订单不参与统计asserttotal_paid([{amount_cents:999},])0# 已支付订单缺少金额必须明确失败try:total_paid([{status:paid}])exceptValueError:passelse:raiseAssertionError(缺少金额时没有报错)# 非法金额必须被拒绝forinvalidin[None,1200,-1,True,1.5]:try:total_paid([{status:paid,amount_cents:invalid},])exceptValueError:passelse:raiseAssertionError(f非法金额未被拒绝{invalid!r})print(验证通过)使用普通运行方式python demo.py看到“验证通过”说明这些用例满足预期。不要用python -O执行这段教学验证因为优化模式会移除assert检查。这些用例仍然不能覆盖所有生产场景。它们的作用是检查当前明确约定的行为并防止修改重新引入已知问题。回到真实项目还要运行现有测试检查上下游调用是否依赖旧行为。例如上层代码原来只处理KeyError现在主动抛出ValueError调用方的异常处理也需要评估。六、AI 改完后再追问一次修改范围拿到修复代码后可以继续问请审查刚才的修改 1. 每一处修改对应哪个已确认的问题 2. 是否改变了函数签名、返回值类型或异常类型 3. 哪些业务行为发生了变化 4. 哪些边界条件还没有验证 5. 是否加入了与本次问题无关的重构 请区分已经运行验证的结果和仅通过阅读代码得到的判断。 没有实际执行的测试不要描述为“测试通过”。然后自己查看修改前后的差异。一个金额汇总问题如果同时改了依赖版本、数据结构和多个无关模块就很难判断究竟是哪处修改起了作用。优先保留能解释清楚、能独立验证的修改后续再安排重构。七、把这套方法用到下一次报错遇到新错误时可以沿着这条顺序处理整理现场 → 最小复现 → 定位原因 → 最小修改 → 回归验证。AI 适合帮助解释调用栈、提出待验证的原因、补充边界用例。业务规则仍需要由了解系统的人确认修改结果也要靠实际执行检查。如果后续涉及 AI 工具订阅充值也可以了解 gptpro68.com。它是第三方 AI 会员充值平台使用前应查看套餐说明、账号要求、到账说明和售后规则。下次再碰到KeyError先保留触发错误的输入再写下应该发生什么。一个明确的反例和一条可执行的验收条件能让后续的排查更有方向。