你是否曾遇到过这样的情况？代码运行一切正常，输出格式、返回类型、校验逻辑均无差错，可实际数值却始终对不上。这类问题排查起来异常耗时，因为表面上看似完美无缺，你甚至会怀疑自己是否看错了。
举例来说，一个用于计算订单折扣后价格的函数，返回了保留两位小数的数字，类型检查也顺利通过，格式校验全部显示绿色，但计算逻辑中却隐藏着细微的偏差，导致最终结果与业务预期不相符。这类错误极易被遗漏，往往需要人工逐项验算，或等到财务对账时才能发现。
要排查此类问题，常规做法是依据输入数据，逐行追踪代码中每一步的中间结果，找到变量值首次出现偏差的位置。难点不在于代码本身有多复杂，而在于追踪过程中很容易忽略某个分支条件、类型转换或业务假设。
下面通过一个具体案例，展示如何借助两个模型来完成这一任务：一个负责定位，一个负责复核，分工明确。
一段返回错误结果的代码
首先来看这段需要排查的代码。以下函数用于计算订单的折扣后总价：
def calculate_discounted_price(order_items, discount_rate):
"""
计算订单的折扣后总价。
order_items: 列表，每项包含 {'price': float, 'quantity': int, 'tax_rate': float}
discount_rate: 折扣率，如 0.15 表示 15% 折扣
"""
subtotal = 0.0
total_tax = 0.0
for item in order_items:
item_total = item['price'] * item['quantity']
subtotal += item_total
item_tax = item_total * item['tax_rate']
total_tax += item_tax
discounted_subtotal = subtotal * (1 - discount_rate)
final_price = discounted_subtotal + total_tax
return round(final_price, 2)传入以下测试数据：
order_items = [
{'price': 29.99, 'quantity': 2, 'tax_rate': 0.08},
{'price': 15.50, 'quantity': 1, 'tax_rate': 0.08}
]
discount_rate = 0.10我们不妨先手动验算一次：
- 商品 1 折前金额：
29.99 × 2 = 59.98元； - 商品 2 折前金额：
15.50 × 1 = 15.50元； - 商品小计：
59.98 + 15.50 = 75.48元； - 折扣后小计：
75.48 × 0.90 = 67.932元； - 商品 1 税额：
59.98 × 0.08 = 4.7984元； - 商品 2 税额：
15.50 × 0.08 = 1.24元； - 折前税额合计：
4.7984 + 1.24 = 6.0384元。
按照当前代码采用的“折前计税”规则，最终价格为：
67.932 + 6.0384 = 73.9704四舍五入后是 73.97 元。
不过，这里需要先确认一个关键的业务问题：税额究竟应根据折扣前金额计算，还是根据折扣后金额计算？
如果业务规则要求按照折扣后金额计税，那么税额应为：
67.932 × 0.08 = 5.43456最终价格应为：
67.932 + 5.43456 = 73.36656四舍五入后是 73.37 元。
由此可见，这段代码的问题并非语法错误或输出格式错误，而是默认采用了“折前计税”的规则。如果实际业务要求“折后计税”，当前结果就会与业务预期产生偏差。
用 Claude Opus 4.8 定位根因
Claude Opus 4.8 是 Claude 系列的旗舰版本，在推理和编码方面有全面改进。
这一阶段的目标不是笼统地判断“计算有误”，而是用测试数据逐行追踪变量，找出计算结果首次偏离业务预期的位置。
提交代码和测试数据时，可以使用以下分析 Prompt：
请逐行分析以下代码的计算逻辑，找出导致输出结果与业务预期不符的根因。
分析要求：
1. 使用提供的测试数据，逐步追踪每个变量在每行代码执行后的值；
2. 标注每一步计算结果与业务预期出现偏差的具体位置；
3. 区分“格式正确性”和“内容准确性”：代码在语法和类型上是否无误，但在计算逻辑上是否存在问题；
4. 明确列出分析过程中依赖的业务假设；
5. 定位根因后，解释为什么这个问题只会在部分输入数据下暴露；
6. 代码和测试数据如下：
[此处粘贴代码和测试数据]Claude Opus 4.8 逐行追踪后，可以得到下面的中间结果：
| 执行阶段 | 变量 | 数值 |
|---|---|---|
| 商品 1 计算完成 | item_total | 59.98 |
| 商品 1 计算完成 | subtotal | 59.98 |
| 商品 1 计算完成 | item_tax | 4.7984 |
| 商品 1 计算完成 | total_tax | 4.7984 |
| 商品 2 计算完成 | item_total | 15.50 |
| 商品 2 计算完成 | subtotal | 75.48 |
| 商品 2 计算完成 | item_tax | 1.24 |
| 商品 2 计算完成 | total_tax | 6.0384 |
| 应用折扣后 | discounted_subtotal | 67.932 |
| 计算最终价格后 | final_price | 73.9704 |
| 四舍五入后 | 返回值 | 73.97 |
从追踪结果可以看出，偏差来自税额计算基数。
代码在循环中使用下面这行逻辑计算税额：
item_tax = item_total * item['tax_rate']此时的 item_total 是折扣前金额。后续虽然对 subtotal 应用了折扣，但已经计算完成的 total_tax 没有同步调整。
换句话说，代码实际执行的是：
折扣后商品小计 + 折扣前税额如果业务规则要求折后计税，正确逻辑应该是：
折扣后商品小计 + 折扣后税额这个问题在折扣率为 0 时不会暴露，因为折扣前金额和折扣后金额完全相同。税率为 0 时也不会暴露，因为无论使用哪一种计税基数，税额都是 0。
当折扣率和税率同时大于 0 时，两种计税规则才会产生明显差异。折扣率、税率或订单金额越高，差异越明显。
Claude Opus 4.8 的分析还指出，这个问题的根本原因是“税额计算基数”没有被明确写进业务规则。代码假设税额始终根据原价计算，但实际应该采用折前计税还是折后计税，需要由业务方确认。
因此，这里首先是需求澄清问题，其次才是代码修复问题。
用 Claude Sonnet 5 验证分析完整性
根因定位后，切换到 Claude Sonnet 5。
Claude Sonnet 5 定位为 Agentic Sonnet，性能接近 Opus 4.8，但成本更低。在这个阶段，它的任务不是重新提出一套修复方案，而是检查 Claude Opus 4.8 的分析有没有遗漏其他风险，以及按照现有结论修改代码后是否可能引入新的偏差。
把原始代码、测试数据和 Claude Opus 4.8 的分析报告一起提交，并使用以下复核 Prompt：
请复核以下代码分析报告，检查是否存在遗漏的错误点。
复核要求：
1. 除了报告中指出的根因，代码中是否还存在其他计算逻辑问题或边界条件问题；
2. 报告中涉及的修复方向是否可能引入新的计算偏差；
3. 检查税率或折扣率为 0、订单只有一条记录、价格为 0、订单列表为空等场景；
4. 检查金额计算使用浮点数是否可能产生精度问题；
5. 检查输入参数是否缺少必要的范围校验；
6. 不直接修改代码，只列出所有需要确认的问题；
7. 代码、测试数据和分析报告如下：
[此处粘贴相关材料]Claude Sonnet 5 的复核确认，税额计算基数是需要优先确认的问题，同时还发现了几项潜在风险。
第一项是浮点数精度。
当前代码使用 float 保存并累加金额。由于部分十进制小数无法用二进制浮点数精确表示，订单项较多时，中间结果可能出现细微误差。函数末尾虽然调用了 round(final_price, 2)，但这并不能完全消除金额计算中的舍入风险。
对于涉及订单和财务结算的代码，通常需要考虑使用 Decimal，并明确采用哪一种舍入规则。
第二项是输入范围没有校验。
当前函数没有限制 discount_rate 和 tax_rate 的取值范围。如果传入负数、超过 1 的折扣率，或者不符合业务规则的税率，函数仍然会继续计算并返回结果。
类似地，代码也没有验证商品价格和数量是否为负数。
第三项是舍入时机没有定义。
当前代码只在最终返回时统一保留两位小数。但实际业务可能要求每个商品先计算折扣和税额并分别舍入，再汇总订单总价。两种方式可能产生几分钱的差异。
因此，除了确认折前计税还是折后计税，还需要确认以下规则：
- 按商品项计算，还是按订单小计统一计算；
- 每个商品项是否需要单独舍入；
- 税额和折扣金额分别采用什么舍入方式；
- 是否允许不同商品采用不同税率。
排查结论与待确认清单
综合两次分析，可以形成以下排查结果：
| 编号 | 问题描述 | 严重程度 | 状态 |
|---|---|---|---|
| P1 | 税额基于折扣前金额计算，可能与业务规则不符 | 高 | 需要业务方确认计税基数 |
| P2 | 金额使用浮点数计算，存在精度和舍入风险 | 中 | 建议评估使用 Decimal |
| P3 | 折扣率、税率、价格和数量缺少范围校验 | 中 | 需要明确合法输入范围 |
| P4 | 按商品舍入还是按订单汇总后舍入尚未定义 | 中 | 需要财务或业务方确认 |
| P5 | 不同商品税率下的计算规则需要进一步明确 | 低 | 根据后续产品规划评估 |
业务方需要确认以下事项：
- 税额应该按照折扣前金额计算，还是按照折扣后金额计算？
- 折扣和税额应该按商品项分别计算，还是根据订单小计统一计算？
- 中间金额是否需要保留固定小数位？
- 财务计算采用哪一种舍入规则？
discount_rate和tax_rate的合法范围是什么？- 单笔订单的商品项数量上限是多少？
- 是否计划支持不同商品采用不同税率？
这些问题确认后，才能确定最终修改方式。否则，即使代码在技术上能够正常运行，也可能继续与实际结算规则不一致。
验收标准
完成分析和修复后，可以按照以下标准验收：
| 验收项 | 通过标准 |
|---|---|
| 根因定位准确 | 明确指出税额计算基数对应的代码位置和业务假设 |
| 偏差可以复现 | 分析报告包含完整的中间变量追踪结果 |
| 业务规则明确 | 已确认折前计税或折后计税，以及具体舍入规则 |
| 修复边界清晰 | 明确列出受影响和不受影响的输入场景 |
| 边界测试完整 | 覆盖零税率、零折扣、空订单、单项订单和多税率场景 |
| 金额精度可控 | 使用符合业务要求的金额类型和舍入方式 |
| 输入校验完整 | 非法价格、数量、折扣率和税率能够被正确处理 |
| 独立复核完成 | Claude Sonnet 5 已检查潜在遗漏和修复风险 |
注意事项
本次分析使用的是模拟代码，不涉及生产环境中的真实业务逻辑。
如果实际排查中包含内部定价规则、用户订单、财务数据或未公开的代码，提交给模型之前需要先完成脱敏。除了用户身份和订单编号，也要检查代码注释、日志、测试数据和异常信息中是否包含敏感内容。
在这次排查中，Claude Opus 4.8 负责逐行追踪变量并定位根因，Claude Sonnet 5 负责独立检查边界条件、输入校验和浮点数风险。这样的分工适合对计算准确性要求较高的场景。
不过，模型只能帮助梳理代码行为和潜在风险。涉及价格、税额及财务结算规则时，最终采用哪一种计算方式，仍然需要由业务和财务负责人确认。
后续可以尝试的方向
遇到“输出格式正确，但内容有误”的代码问题时，可以先让 Claude Opus 4.8 逐行追踪计算过程，重点寻找变量值第一次偏离预期的位置，再交给 Claude Sonnet 5 做独立复核。
复核时不要只问“修复方案是否正确”，还应覆盖输入范围、空值、浮点数精度、舍入时机和业务假设。两个模型都指出的问题，通常需要优先处理；只有一个模型提出的问题，则可以结合代码和业务规则进一步验证。
完成分析后，还应把已经确认的业务规则写成自动化测试。这样以后即使折扣、税率或商品类型发生变化，也能在代码提交阶段及时发现计算结果的偏差。