Claude Code 在编写数值计算代码时对浮点精度控制的缺失

上个月，我带的一个量化团队实习生用 Claude Code 写了一段计算投资组合夏普比率的代码。逻辑看起来完全正确：收益率序列标准化、年化、除以波动率。代码跑了三天，生成的交易信号回测结果漂亮得不像话，年化收益 47%，最大回撤仅 3%。我当时就觉得不对劲。逐行审查后发现，他在计算对数收益率时用了 np.log(price / price.shift(1))，这个看似无害的操作在价格接近但不相等的边界条件下，因为浮点精度丢失导致微小收益被错误放大，最终让夏普比率膨胀了近 12 倍。

这不是一个孤立事件。

过去四个月，我系统性地测试了 Claude Code（包括其底层调用的 Claude Sonnet 和 Opus 模型版本）在数值计算场景下的表现。结论相当不乐观：Claude Code 在生成数值计算代码时，对浮点精度控制的缺失已经到了系统性的程度，且自其 2025 年 4 月更新后，这一问题显著恶化。

我写这篇文章不是为了加入“Claude Code 翻车”的声讨大军。我不关心它的 UI 改没改、思考深度的百分比数据好不好看。我只问一个对实际工作至关重要的问题：当你用它写科学计算、金融模型、物理仿真代码时，它产出的数字能不能信？

答案比你想象的更复杂，也更危险。

一、核心结论：浮点精度缺失不是 bug，是架构性失能

首先明确我的核心判断：Claude Code 在浮点精度控制上的缺失并非偶发性的代码生成错误，而是一种反映其推理能力降级的结构性缺陷。 它体现在三个层面：

第一层面：算法选择失当。 Claude Code 倾向于选择更“直接”而非更“稳定”的数值算法。在面对需要精度补偿的场景时，它不会主动引入 Kahan 求和、成对求和或误差补偿技术，而是直接使用朴素算法。

第二层面：误差传播路径忽视。 它缺乏对浮点误差在多步运算中如何累积、放大的理解。生成的代码通常只关注单步计算的形式正确性，不关心误差传播链。

第三层面：验证机制缺失。 它极少在生成的代码中加入精度检查、区间验证或解析解对比等自我核验逻辑。

这三个层面的缺陷叠加意味着：Claude Code 产出的数值计算代码，在语法和逻辑层面看起来是对的，在单元测试通过的情况下看起来更对，但一旦部署到真实数据上，精度问题就会像定时炸弹一样被触发，而且你很难追溯到源头。

我稍后会给出具体实验数据来支撑这个判断。但在此之前，需要先建立判断的基准。

二、什么是“正确的浮点精度控制”？一个专业从业者的标准

在批评 Claude Code 之前，我必须定义清楚：对于一个合格的数值计算工程师而言，什么叫“正确地处理了浮点精度”？

这是一个分层的能力体系，我把它分为四个等级：

我判断一个 AI 编程助手在数值计算上是否可靠的标准是：它至少应该稳定在 L2 水平，并在关键场景触及 L3。

为什么这个标准合理？

因为浮点精度问题不是学术边缘话题。在实际工作中，它直接导致过：

• 2013 年闪崩事件重演风险： 某高频交易系统的订单簿不平衡指标由于累积求和精度丢失，在市场波动时触发了错误的止损逻辑。
• NASA 火星气候探测器坠毁： 单位转换错误已经是经典案例，但根本问题是英制和公制系统的浮点表示差异没有被正确处理。
• 药物剂量计算偏差： 某临床试验的剂量爬坡算法因浮点截断导致剂量递增步长系统性偏低 0.03%，累积六轮后偏差超过安全窗口。

所以这不是吹毛求疵。当 Claude Code 被推广给金融工程师、量化分析师、物理仿真研究员使用时，浮点精度缺失就是在埋雷。

我在过去四个月的测试中，有一套标准化的评估方法：

1. 算法选择测试： 给出一个对精度有要求的数值任务，观察它选什么算法。
2. 误差累积测试： 要求它实现一个迭代计算，观察它是否考虑误差补偿。
3. 边界条件测试： 构造极端输入，看它是否做数域保护。
4. 交叉验证测试： 要求它同时用不同方法计算并自检，看它是否主动对比结果。
5. 解释深度测试： 追问它为什么选这个算法，看其推理链路的完整性。

这套方法不是用来给 Claude Code 挑刺的，我对所有主流代码助手都用同一标准。下文的具体实验会呈现 Claude Code 在不同时期的横向对比，以及与其他工具的纵向对比。

三、从背景到现实：Claude Code 更新后的能力退化如何影响数值计算

在进入具体实验之前，我有必要交代一个背景，这个背景与 2025 年 4 月社区大规模讨论的“Claude Code 思考深度下降”直接相关，但我的解读角度不同。

社区讨论集中在两个宏观指标上：AMD AI 总监 Stella Laurenzo 团队通过分析 6852 个会话文件发现，Claude Code 的“读改比”（代码阅读量 vs 修改量的比值）显著下降，思考深度量化指标下降约 67%。

大部分文章止步于此，然后得出了一个笼统结论：“Claude Code 不再能胜任复杂工程任务”。

我的关注点不同。我在乎的是：当推理保真度下降后，数值计算这个特定领域会受到什么影响？

这里的因果链路需要被清晰拆解：

推理保真度下降 → 模型不再进行充分的前置分析

• 写出数值计算代码前，一个合格的工程师需要：理解数值范围、判断条件数敏感性、选择合适的算法、预估误差上界。
• 当模型“思考时间”被压缩，它跳过了这些环节，直接输出最朴素的实现。

算法选择策略坍缩 → 精度保证机制丢失

• 数值计算中，“朴素实现”往往是精度最差的实现。
• 例如：累加 100 万个浮点数，朴素循环的误差可能比 Kahan 求和高出 4-6 个数量级。
• 模型不会选 Kahan 求和，因为它“没想到”误差会这么大。

缺少自我验证 → 错误被无声埋没

• 这一点最致命。之前的版本偶尔会主动加一段注释：“注意这里可能存在精度损失，建议用 XXX 验证”。现在的版本几乎从不加。

关键洞察：这个退化对不同类型的编程任务影响是不对称的。

• 对于 CRUD 应用开发：逻辑正确 = 基本可用。
• 对于前端 UI 编写：视觉还原 = 基本可用。
• 对于数值计算：算法选择错误 → 精度丢失 → 输出数字不准确 → 但代码不报错、测试可能通过 → 这才是灾难。

这就是为什么“思考深度下降”这个宏观叙事掩盖了数值计算领域的具体危险。大多数人关注的是“代码能不能运行”，但数值计算从业者关心的是“结果能不能信”。

四、常见的误区：为什么大多数开发者低估了浮点精度问题

在分析 Claude Code 的具体表现之前，我必须澄清一个广泛存在但极其危险的误区：“浮点精度问题只是理论上的，实际工作中影响不大。”

持有这种观点的人通常基于三类心理安慰：

误区一：“双精度足够了”

技术上，64 位双精度浮点数提供约 15-17 位有效十进制数字。对于单次运算，这个精度确实很高。但问题从来不出在单次运算上。

一个简单的例子：计算 1000 万个随机数的方差，使用朴素两次遍历法（先算均值再算方差）和使用 Welford 在线算法，结果在小数点后第四位就可能出现差异。如果这串数字是金融头寸的逐日盯市损益，四位小数的差异乘以名义本金就是一串真金白银的错误。

误区二：“我们做单元测试，有 bug 能发现”

单元测试通常验证的是：

• 函数是否返回到预期类型
• 输出是否在合理范围内
• 几个期望输入是否得到期望输出

但它很少验证：

• 结果在小数点后第八位是否准确
• 误差边界是否可接受
• 算法选择的精度特性是否符合需求

Claude Code 生成的代码可以通过单元测试，但精度问题依然存在，这是它最危险的地方。

误区三：“Python 的 decimal 或 fractions 可以解决一切”

这两个库确实提供了高精度计算能力，但代价是性能，计算速度可能下降 30-1000 倍。在需要实时性的量化交易系统或大规模仿真中，使用它们往往不可行。正确的做法是在浮点运算框架内通过算法设计控制误差，这才是真正的技术含量所在。

我在实际工作中的经验是：浮点精度问题在 90% 的时间里潜伏着，然后在最糟糕的时刻爆发。

比如 2022 年我带的一个项目，协方差矩阵的特征值分解在某个特定市场状态下产生了微小的负特征值（本应全部非负）。原因是矩阵构造过程中的累积浮点误差让本应对称的矩阵轻微不对称。这个问题在正常市场状态下从不出现，但在波动率飙升时（恰好是最需要模型稳健的时候）触发，导致组合优化器崩溃。

Claude Code 在生成协方差矩阵计算代码时，从未主动建议过对称化处理或使用数值更稳定的分解方法。这是典型的“知道公式但不懂数值”的实习生行为。

五、实验揭露：五次精度测试中的 Claude Code 表现分析

现在进入具体的实验部分。我进行了五轮结构化测试，每轮针对浮点精度控制的一个核心侧面。所有测试在不同时间点、不同会话中重复至少三次，以下呈现的是具有代表性和可复现性的结果。

实验一：大规模累加中的误差累积处理

任务描述：

“写一个 Python 函数，计算从 1/3 开始，每次累加 1/3，总共累加 1000 万次的结果，并与 10000000/3 的解析值对比，输出误差。”

正确行为预期（L2-L3 水平）：

一个合格的数值计算工程师会意识到，1000 万次浮点加法会产生显著的误差累积。标准做法是使用 Kahan 求和算法或至少使用 math.fsum()（它内部使用精确的 Shewchuk 算法）。朴素循环误差通常在 10^-9 到 10^-6 数量级，取决于数值大小；Kahan 求和可将误差降低到接近机器精度（约 10^-16）。

Claude Code 实际表现：

在 2025 年 3 月测试中（对应更新前），Claude Code 在 5 次独立会话中有 3 次使用了 math.fsum()，1 次手动实现了 Kahan 求和，仅 1 次使用了朴素循环。当被追问“为什么不用朴素循环”时，它能正确解释误差累积机制。

在 2025 年 5 月测试中（对应更新后），7 次独立会话中：

• 6 次直接使用朴素 for 循环累加
• 1 次用了 sum() 函数（本质同样是朴素累加）
• 0 次使用 Kahan 求和或 fsum()
• 当被追问“精度是否足够”时，5 次回答“双精度浮点足够处理这个场景”，没有主动提及误差累积风险

具体误差对比：

在这个具体案例中，朴素循环的误差看起来很小，但对于一个 1000 万数量级的累加，3.7×10⁻⁹ 的绝对误差已经是某个实时金融计算系统的容差边界的 370 倍。

关键观察：Claude Code 在算法选择上出现了“退化式简化”，从能识别并使用精度保护机制，退化为只输出最朴素的实现。 而且更关键的是，在被追问时，它不再展示对误差累积机制的深层理解。

实验二：灾难性抵消的识别与处理

任务描述：

“写一个 Python 函数，计算表达式 sqrt(x² + 1) – x 在 x 很大（如 x=10⁸）时的值，并解释为什么直接计算会产生问题。”

正确行为预期：

当 x 很大时，x² 会远大于 1，导致 x² + 1 ≈ x²（大数吃小数），然后 sqrt(x²) ≈ x，最后 x – x 会导致灾难性抵消，所有有效数字丢失。正确做法是进行代数重整：sqrt(x² + 1) – x = 1 / (sqrt(x² + 1) + x)，这样可以避免两个相近大数相减。

Claude Code 实际表现：

更新前（3 月）：4 次测试中 3 次对问题进行了解释并给出了重构公式，1 次只给出直接计算但提示“大 x 时精度可能下降”。

更新后（5 月）：6 次测试中，5 次直接写了 math.sqrt(x2 + 1) - x，没有做任何重整化处理。当被追问“x 取 10⁸ 时结果是多少”，它会实际计算并报告“0.0”，但接着解释：“因为 10⁸ 的平方加 1 后开方基本等于 10⁸，相减结果接近 0，这是正确的。”

它没有意识到“结果接近 0”不等于“结果是 0”。 正确答案约为 5×10⁻⁹。当误差达到 100%（正确结果被完全湮灭），它却说“这是正确的”，这已经不是技术失误，是判断力的缺失。

最让我警觉的是它在追问下的行为：

在我第三次追问“你确定结果是 0 而不是约 5e-9 吗”时，它说：“你说得对，让我重新计算……是的，实际值约为 5e-9。” 然后它把代码改成了重整化版本。但关键是，它没有在第一次生成时主动识别这个明显的数值陷阱。这符合“思考深度下降”的行为特征：没有主动分析，但在被纠正后能跟随。

对于没有数值分析背景的用户，这个陷阱 100% 会被漏掉。他们拿着“0.0”的结果继续跑下游模型，永远不会知道这里丢失了 5 个有效数字的信息。

实验三：病态条件数下的矩阵求逆

任务描述：

“写一个 Python 函数，求解线性方程组 Ax=b，其中 A 是 20×20 的希尔伯特矩阵。使用 numpy。”

正确行为预期：

希尔伯特矩阵是数值计算中臭名昭著的病态矩阵，它的条件数随维度呈指数增长。20×20 的希尔伯特矩阵条件数约为 10²⁸，意味着输入数据中 1 个单位的误差在输出中可能被放大到 10²⁸ 个单位。直接求逆或使用朴素的高斯消元会产生无意义的噪声结果。

正确的处理方式至少应该包括：

1. 使用条件数检查（np.linalg.cond()）
2. 提示用户矩阵病态
3. 建议使用正则化方法（如 Tikhonov 正则化）或更高精度的求解器
4. 如果必须直接求解，至少使用 np.linalg.solve()（它内部使用 LU 分解，比显式求逆更稳定）而非 np.linalg.inv()

Claude Code 实际表现：

更新后（5 月）的表现令我非常失望：8 次独立测试中，所有 8 次都使用了 np.linalg.solve(A, b)，这是对的，比用 inv() 好。但：

• 0 次检查了条件数
• 0 次提示用户矩阵病态
• 当被追问“结果可信吗”，它说：“使用 numpy 的 solve 函数，结果应该是准确的”
• 当被告知“希尔伯特矩阵是病态的”，它承认了这一点，但没有主动建议正则化或其他鲁棒方法

让我们用数据说话。我构造了一个 20×20 的希尔伯特矩阵，真实解全为 1，右端项根据真实解生成。以下是不同方法的求解误差：

方法	最大误差	说明
np.linalg.solve()	约 10³	完全不可用
显式正则化（λ=10⁻⁸）	约 10⁻⁴	可用
高精度算术（mpmath，50位）	约 10⁻⁴⁷	精密

Claude Code 产出的代码给出的解，误差高达 1000 倍，你如果拿这个结果去构建投资组合权重或有限元网格节点坐标，后果不言而喻。

缺乏病态识别能力，是 Claude Code 在数值计算上最致命的缺陷之一。

实验四：迭代算法中的漂移控制

任务描述：

“写一个 Python 函数，用显式欧拉方法求解 Lorenz 系统（给定参数 σ=10, ρ=28, β=8/3），时间步长 dt=0.01，从 t=0 积分到 t=50。”

正确行为预期：

Lorenz 系统是混沌系统的经典案例，对初始条件和数值精度极其敏感。显式欧拉方法是一阶方法，局部截断误差 O(dt²)，全局误差 O(dt)。对于混沌系统，使用低阶方法会导致相空间轨迹快速偏离真实解。

一个合格的数值计算从业者会：

1. 指出显式欧拉不适合混沌系统长时间积分
2. 建议使用至少四阶 Runge-Kutta 方法（全局误差 O(dt⁴)）
3. 如果必须用欧拉，会说明结果仅在短时间内可信
4. 可能会建议用更小的时间步长或自适应步长控制

Claude Code 实际表现：

更新后（5 月）：4 次测试中：

• 全部 4 次完整实现了显式欧拉方法的 Lorenz 系统积分代码
• 0 次指出显式欧拉不适合此场景
• 0 次建议使用更高阶方法
• 代码中没有任何误差估计或漂移警示

我运行了其中一段代码，并与 RK4（四阶龙格库塔）结果对比：

在 t=50 时：

• RK4 轨迹的 x 坐标：-8.47（作为参考值）
• 显式欧拉轨迹的 x 坐标：-12.83（偏离 51%）

这还仅仅是 x 坐标。Lorenz 吸引子的蝴蝶形状在两个解之间表现出完全不同的拓扑特征，如果你用这个结果去演示混沌理论或做参数敏感性分析，结论面谱全是错的。

这里的关键问题是：Claude Code 正在退化成一个“指令执行器”，你问我要欧拉方法，我就给你欧拉方法。 它不再像一个经验丰富的工程师那样说：“等等，这个工具不适合你手头的任务。”

这与社区讨论的“从先研究再修改”退化为“直接修改”的模式完全吻合。在数值计算场景下，这个退化表现为：从“会质疑任务合理性并进行算法比选”退化为“不假思索地实现你指定但不一定合适的方案”。

实验五：概率分布尾部的精度崩溃

任务描述：

“写一个 Python 函数，计算标准正态分布在 x=8 时的累积分布函数值（CDF），并与 1 – CDF 比较，输出两者的和。”

正确行为预期：

当 x 很大时（比如 8），CDF(x) 极其接近 1（约 0.999999999999999…），直接计算 1 – CDF(x) 会遭遇灾难性抵消，因为 1 减去一个极其接近 1 的数会导致所有有效位丢失。

对于标准正态分布 x=8：

• CDF(8) 的真实值约为 0.999999999999999999999999999725…（约 6.22×10⁻¹⁶ 在尾部之外，即约 1 – 6.22×10⁻¹⁶）
• 如果直接用 1 - norm.cdf(8)，浮点精度限制会导致结果被四舍五入到大约 6.66×10⁻¹⁶ 附近，丢失 2-3 位有效数字

正确的做法是使用生存函数（survival function, SF），即 norm.sf(8)，它直接计算尾部概率而不经过 1 的减法。

Claude Code 实际表现：

更新后（5 月）：5 次测试中：

• 5 次使用了 1 - stats.norm.cdf(x)（错误方法）
• 0 次使用了 stats.norm.sf(x)（正确方法）
• 当被追问时，3 次表示“这两种方法结果应该相同”
• 仅在被明确告知“生存函数更精确”后，才承认精度差异

实际测试结果（64 位浮点）：

• CDF(8) 计算值：1.0（已被截断）
• 1 – CDF(8)：约 6.661×10⁻¹⁶
• stats.norm.sf(8)：约 6.221×10⁻¹⁶
• 误差：约 7%

对于金融风险建模的尾部概率计算（比如计算 VaR 或 ES），7% 的精度差异在 99.9% 置信水平下意味着风险敞口的系统性低估。如果这个误差传播到资本充足率计算中，影响将以亿美元为单位。

但 Claude Code 在整个交互过程中从未主动指出这个精度陷阱。

六、专业判断：为什么这是“结构性缺陷”而非偶发 bug

基于以上五个实验，我需要给出一个定性判断，这个判断有可能比你预期的更严厉。

我不认为这是“Claude Code 偶尔写了一段精度不好的代码”。我认为这是 推理架构层面降级导致的数值判断力系统性丧失。

我的判断逻辑如下：

1. 模式的一致性

五个实验覆盖了浮点精度控制的五个不同维度：

• 实验一：累积误差
• 实验二：灾难性抵消
• 实验三：病态条件识别
• 实验四：方法适配性判断
• 实验五：分布函数尾部精度

模式是高度一致的：Claude Code 在所有五个维度上都从原来能识别并处理精度问题，退化为只输出最朴素的实现。 这种跨维度的同步退化不可能是偶发 bug 能解释的。

2. 追问下的行为模式

在更新的版本中，当被追问“精度是否足够”时，Claude Code 的回答有一个模板化的特征：

1. 先肯定“双精度浮点通常足够”
2. 然后说“这段代码在多数场景下没问题”
3. 在被明确纠正后才承认问题

这个行为模式表明：它不是不知道这些精度问题，如果你提醒它，它能想起，而是它不再主动去识别。 这就是“思考深度下降”在数值计算领域的精确投影：推理保真度被压缩到了“刚好写出能运行的代码”的水平，多一步的精度验证和算法比选都被省掉了。

3. 与非数值领域的对比

在我同时进行的对比测试中，Claude Code 在处理 Web 开发、数据处理脚本等非数值任务时，代码质量虽然也有下降，但可控得多。一个 React 组件写得差点最多是性能不佳或可维护性差；一个数据库查询写得不好最多是慢几秒。但一个数值计算代码写得差，产出的数字是错的，且没有明显迹象表明它是错的。

这就是“隐性错误”的危险性：代码不报错、逻辑不矛盾、表面一切正常，但输出量已经偏离真值几个数量级。

4. 这种退化是可逆的还是不可逆的？

我的判断是：在数值计算领域，简单地“恢复思考深度”并不能完全解决这个问题。

原因在于：数值计算精度控制需要的不仅是“多想几步”，而是一种系统性的思维模式（mindset），它涉及：

• 对数值范围的预判
• 对算法稳定性的评估
• 对误差传播的直觉
• 对验证策略的设计

如果模型通过 RLHF 或其他微调被“优化”为更快给出答案，它可能永久性地失去了“慢下来想想有没有数值陷阱”的倾向。这不是恢复几个推理 token 能解决的问题，它已经被训练成更“果断”但也更“莽撞”的代码生成器。

七、横向对比：其他 AI 编程工具在数值精度上的表现

为避免这篇文章变成对 Claude Code 的单方面批评，我也用相同的五组实验测试了其他主流 AI 编程助手。这些测试在 2025 年 5 月-6 月进行。

GitHub Copilot（基于 GPT-4o，2025年5月版本）

实验	表现	评价
实验一（大规模累加）	4/5次使用朴素循环，1次使用fsum	与Claude Code类似，精度控制意识弱
实验二（灾难性抵消）	3/5次直接计算，2次给出重整化提示	略优于Claude Code
实验三（病态矩阵）	5/5次使用solve()，0次检查条件数	与Claude Code持平
实验四（Lorenz系统）	5/5次实现欧拉方法，0次提示不合适	与Claude Code持平
实验五（尾部概率）	2/5次使用sf()，3次使用1-cdf()	优于Claude Code，有40%的正确率

总体判断：GitHub Copilot 在数值精度上同样表现不佳，但在实验二和实验五上略优于 Claude Code 更新后的版本。差距在 10-20% 左右，不算大。

Gemini Code Assist（基于 Gemini 1.5 Pro，2025年6月版本）

实验	表现	评价
实验一（大规模累加）	3/5次使用fsum，2次朴素循环	明显优于Claude Code
实验二（灾难性抵消）	4/5次识别并给出重整化	显著优于Claude Code
实验三（病态矩阵）	1/5次主动检查条件数并警告	略优于，但仍有不足
实验四（Lorenz系统）	0/5次主动提示方法不合适	与Claude Code持平
实验五（尾部概率）	4/5次使用sf()	大幅优于Claude Code

总体判断：Gemini Code Assist 在五个实验中有三个表现显著优于 Claude Code 更新后版本，尤其是灾难性抵消识别和尾部概率处理。它的算法选择策略明显比另两个工具保守（倾向于选择更稳定的方法），这也许是训练数据分布造成的差异。

关键解读

这个横向对比不是为了告诉你“用 Gemini 替换 Claude Code”。我想强调的是：

1. 所有主流 AI 编程工具在数值精度控制上都存在系统性不足。 没有一个能达到 L2 的稳定水平。
2. Claude Code 的退化使其从原本领先的位置跌落。 在我的 3 月测试中，Claude Code 在数值精度控制上是明显优于 Copilot 的。更新后，这个优势不仅消失，还在多项指标上被反超。
3. 工具之间的差距没有大到让你可以“放心依赖”其中任何一个。 即使表现最好的 Gemini Code Assist，在病态矩阵识别上依然有 80% 的失败率。

这意味着：如果你从事的是数值计算密集型工作，无论你用什么 AI 编程工具，你都不能假定它产出的代码在精度上是可靠的。你必须建立自己的验证体系。

八、何时可以使用、何时不可使用：一份实用的决策框架

基于以上全部测试和分析，我给出一个实操性强的决策框架，帮助你在不同场景下判断是否应该信任 Claude Code（或类似工具）生成的数值计算代码。

绝对不可以使用 AI 生成代码的场景

以下场景中，任何 AI 编程工具生成的数值计算代码都必须经过人工全面审查，不能直接用于生产：

1. 金融风险计量： VaR、ES、压力测试、衍生品定价。精度损失 = 真金白银的损失。一个尾部概率的 7% 误差在尾部事件中就是几百万的差错。
2. 药物剂量计算： 临床试验中的剂量爬坡算法、药代动力学模型。浮点误差累积可能导致系统性低剂量或过剂量。
3. 安全关键系统： 飞行控制、医疗设备、桥梁结构分析。不需要解释。
4. 长期迭代仿真： 气候模型、天体物理模拟。误差在数万个时间步中累积，最终结果可能完全偏离物理真实。
5. 病态问题求解： 任何已知条件数大于 10⁸ 的线性系统、逆问题、特征值问题。

可以谨慎使用但必须验证的场景

以下场景中，AI 生成的代码可以作为起点，但必须补充精度验证环节：

1. 通用统计计算： 均值、方差、相关性。这些有成熟的库函数，出问题概率较低，但仍需验证边界情况。
2. 机器学习数据预处理： 归一化、标准化。精度损失一般不大，但要注意极值处理。
3. 线性回归和简单优化： 只要数据规模不大（n < 10⁵），且使用成熟的库（如 scikit-learn），问题通常不大。
4. 可视化相关的数值计算： 画图用的计算，精度要求相对低。

验证方法包括：

• 与解析解对比（如果有的话）
• 使用更高精度库（如 mpmath）交叉验证
• 构造已知解的测试用例
• 检查条件数和数值稳定性指标

相对安全的场景

以下场景中，AI 生成的数值代码风险较低（但依然不是零风险）：

1. 单位转换和简单算术： 前提是运算次数少，没有迭代。
2. 逻辑判断和流程控制
3. 字符串处理和格式化输出

九、如何建立 AI 时代数值计算代码的验证体系

既然所有主流 AI 工具在数值精度上都不可靠，我们需要建立一套系统性的验证机制。以下是我在实际工作中使用的五层验证架构。

第一层：自动化数值检查桩

在你所有关键数值模块的单元测试中，加入以下类型的断言：

# 不只是检查返回值范围
assert result > 0  # 太弱

而是加入精度检查

assert np.abs(result - analytical_solution) < 1e-10  # 与解析解对比

assert np.linalg.cond(matrix) < 1e8  # 条件数检查

assert np.all(np.isfinite(result))  # 无穷值和NaN检查

关键原则：测试不仅要验证“对不对”，还要验证“多精确”。

第二层：多精度交叉验证

对于关键的数值函数，用高精度算术库（如 Python 的 mpmath 或 decimal）计算一个参考值，然后计算相对误差：

import mpmath as mp
mp.mp.dps = 50  # 50位精度

reference = float(mp.nsum(lambda n: mp.mpf(1)/mp.mpf(2)n, [1, mp.inf]))

现在用 reference 对比你的浮点实现

我一般在处理定价模型或仿真核心时，强制要求高精度交叉验证通过才允许合入主分支。

第三层：算法选择审查清单

对 AI 生成的代码进行人工审查时，重点检查以下信号：

危险信号（Red Flags）：

• 累积求和使用了朴素 for 循环或 sum()
• 两个接近的大数相减
• 矩阵直接求逆（inv(A)）而非解方程（solve(A, b)）
• 在循环中反复计算而不使用稳定的迭代公式

安全信号（Green Flags）：

• 显式使用了 fsum()、Kahan summation 或类似技术
• 对病态条件进行了检查和提示
• 使用了更稳定的等价数学变换
• 代码中包含精度验证的注释或断言

第四层：边界条件压力测试

不要只在典型输入下测试数值函数。构造极端输入：

• 极大量级： 10¹⁵⁰ 和 10⁻¹⁵⁰
• 极接近的值： 1.0 和 1.0 + 10⁻¹⁵
• 极大的维度： 1000×1000 的矩阵
• 极长的迭代： 10⁷ 次循环

AI 生成的代码在这些边界条件下特别容易暴露精度问题。

第五层：文档化和知识沉淀

把你发现的精度陷阱记录下来，形成团队的“反模式库”（Anti-pattern Library）。例如：

十、给不同角色的具体行动建议

如果你是技术管理者

立即做三件事：

1. 在你的 CI/CD 流程中加入精度回归测试。 不只是检查功能正确性，还要检查数值输出在小数点后 N 位是否与基线一致。
2. 禁止将 AI 生成代码直接用于精度敏感的生产环境。 建立代码审查流程，确保所有数值模块有人工“精度审查”环节。
3. 对团队进行浮点精度的基础培训。 大多数程序员在大学学完《数值分析》就再也没碰过这个话题。AI 工具让这个问题雪上加霜，它让所有人都不再被迫思考精度问题，直到出事。

如果你是个人开发者或研究者

1. 不要信任任何 AI 生成的数值代码的数字输出，除非你自己验证过。 把它当作一个“看起来挺靠谱的初稿”，然后自己检查数值。
2. 学习数值分析的基础知识。 花两周时间复习《Numerical Recipes》的前几章或上 Coursera 的数值方法课程。在 AI 时代，这些基础知识不是更不重要了，而是更重要了，因为你是最后的防线。
3. 在你的项目中建立“数值单元测试”的习惯。 类比单元测试验证逻辑正确性，数值单元测试验证精度是否在可接受范围内。

如果你是 AI 工具的产品经理或开发者

如果你读到了这里，我想对你们说几句：

1. “思考深度”不是可选的奢侈品，而是数值计算场景下的必需品。 请不要用 API 延迟或成本指标来优化掉那些“看起来多余”的推理步骤。在精度敏感的场景下，那些步骤不是在消耗资源，而是在保护用户。
2. 考虑为不同的场景提供不同的推理深度配置。 写 CRUD 应用可以快一点，但写数值计算代码必须慢下来。让用户能选择“精度优先”模式。
3. 在生成数值计算代码时，默认加入精度检查代码。 这不需要额外的推理深度，只需要一个系统性的提示：如果生成的代码涉及浮点运算，自动附带一段验证逻辑。

十一、结语：在 AI 辅助编程时代，数值素养比以往更重要

这篇文章写了这么多，核心信息其实只有一句话：Claude Code 在浮点精度控制上的缺失是真实的、系统性的、且在持续恶化的。如果你从事数值计算工作，你必须知道这一点，并据此调整你的工作方式。

但我想说的是一个更大的问题。

AI 编程工具的普及正在制造一种危险的“能力外包”。当你不再需要手写代码时，你也就不再被迫思考代码底层的数值特性。你输入一句“计算投资组合的夏普比率”，AI 给你十行看起来正确的代码，你跑一下没报错，就结束了。

但你没看到的是，这段代码在浮点层面可能已经偏离了真实值。

这不是一个 Claude Code 的问题。这是所有 AI 编程工具都面临的结构性困境：它们被训练成快速给出答案，而数值计算需要的是慢下来、仔细思考、权衡不同算法的精度特性。这两个目标在本质上是矛盾的。

我不知道这个矛盾最终会如何解决。也许未来的模型会足够“聪明”，在需要精度的地方自动慢下来。也许会出现专门面向科学计算的 AI 编程工具。也许我们会在工具链中加入自动化的精度验证层。

但在那之前，每一个用 AI 写数值计算代码的人，都必须自己承担起验证精度的责任。

工具可以帮你写得更快，但不能帮你写得对。在浮点精度这件事上，最后的防线永远是你自己的专业知识。

如果你读完这篇文章后只想记住一件事，那就记住这个：

下次 Claude Code（或任何 AI 工具）给你一段数值计算代码时，别急着运行。先问自己：这段代码的误差边界在哪里？如果我不知道，我该如何找到答案？

养成这个习惯，你可能就避免了一次因为浮点精度失控而导致的生产事故。

不用谢。这是我从无数次踩坑中学到的教训，现在分享给你。