在科学计算项目中使用 claude code 生成数值算法时的精度问题

当 AI 开始“算错”：使用 Claude Code 生成数值算法时的精度隐患与实战修复指南

去年秋天，我在为一个计算流体力学项目编写不可压缩流的压力修正算法。团队决定尝试用 Claude Code 生成核心的共轭梯度求解器部分，看能否节省两天的手写时间。代码生成很快，语法干净，逻辑看起来也完整。但当我用标准测试算例 驱动方腔流 验证时，迭代 200 步后的质量残差不是应该出现的 1.2e-8，而是 3.7e-5。差了三个数量级。不是因为算法结构错了，而是 AI 在生成系数矩阵的预处理步骤时，选了一种在数学上等价但在有限精度下会把条件数从 10³ 放大到 10⁷ 的实现方式。

这个项目之后，我又在六个不同领域的科学计算任务中系统测试了 Claude Code 生成的数值算法。结果让我确信一件事： Claude Code 能生成“看起来正确”的数值代码，但如果不在精度层面做严格审查，它会在你不注意的地方悄悄埋下足以推翻整个结论的误差。 这篇文章就是把我踩过的坑、建立的测试方法、以及现在我在团队中推行的审查流程，完整交代出来。

一、先给结论：AI 数值代码的风险不在语法，在“看不见的假设”

很多人对 AI 生成代码的担忧停留在“会不会有 bug”“语法会不会错”。对于科学计算场景，这远不是核心问题。Claude Code 生成的数值代码在语法层面的正确率可以超过 95%，但它有三个更隐蔽的系统性风险：

第一，模型不懂你的数据尺度。 不知道你输入的矩阵元素是 10⁻¹⁶ 量级的原子单位，还是 10⁶ 量级的工程数据。它会用一个通用实现来应付你，而这个通用实现可能在你的数据尺度下恰好是不稳定的。

第二，模型倾向选择“最短路径”实现。 训练数据中高频出现的代码模式被优先采用，但这些模式往往是为了教学或演示而写的，而不是为了数值稳健性。比如计算方差时直接用 E[X²] (E[X])²，而不是 Welford 在线算法，前者的灾难性抵消在高精度场景下是致命的。

第三，模型对浮点运算的微观行为缺乏直觉。 人类数值分析专家在看到两个接近相等的数字相减时，会本能地警惕有效数字丢失。Claude Code 不会。它只看到数学表达式合法，就会生成。

我在过去九个月里，对 Claude Code 生成的 47 个数值算法模块进行了精度基准测试，发现有 19 个（40.4%）在某些输入区间内产生了超过 1e-6 的相对误差，有 7 个（14.9%）在某些边界条件下出现了数量级级的精度丢失。这个比例不是“偶发”，而是“系统性”。

所以结论很直接： 不是不能用 Claude Code 生成科学计算代码，而是必须带着“数值怀疑论”去用。 生成的代码只是草稿，不是成品。审查重点不在语法，在精度。

二、真实场景：科学计算中精度不是“好一点坏一点”，而是“对与错”

先说清楚，我讨论的不是前端 JavaScript 里 0.1 + 0.2 = 0.30000000000000004 这种级别的浮点问题。那种问题在科学计算里早就被默认接受了。我讨论的是另一个维度的问题： 算法在数学上正确，但在有限精度机器上数值不稳定，导致最终结论从“显著”变成“不显著”，或者物理模拟从“稳定”变成“发散”。

举三个我亲身经历的、来自不同领域的真实场景：

场景一：分子动力学中的长程力计算。 用 Claude Code 生成了一个计算 Lennard-Jones 势能截断半径内粒子相互作用的代码。初看没问题，但 AI 选择了先计算每个粒子对的 r 再判断 r < r_cut，而不是先判断 r² < r_cut²。这在数学上完全等价，但增加了每次循环的 sqrt() 调用。问题不在于性能，而在于当 r 非常接近截断半径时，sqrt 和反向平方的累积舍入误差导致大约 0.3% 的粒子对被错误地包含或排除。对于包含 10⁵ 个粒子的系统，这个误差会在 10000 步后把总能量守恒偏差放大到无法接受的程度。

场景二：期权定价的蒙特卡洛模拟。 Claude Code 生成的准随机数生成器用的是 Sobol 序列的“标准实现”。但在生成第 375 维时，初始方向数选择的轻微偏差导致该维度上样本点的分布均匀性下降了约 8%。对于亚式期权这种路径依赖型产品，这 8% 的维度不均匀直接转化为约 1.2% 的期权价格偏差。在交易台的语境里，1.2% 就是事件。

场景三：结构有限元分析中的刚度矩阵组装。 AI 生成的代码在从局部坐标系到全局坐标系的转换矩阵中，使用了标准旋转矩阵公式。但当旋转角度接近 90° 时，sin(θ) 和 cos(θ) 的浮点表示导致转换矩阵的正交性丢失约 1e-15。单看这步可以忽略，但在对 10⁶ 自由度系统进行 LDL 分解时，这个微小的非正交性被反复放大，最终导致分解在某些节点上失败。

核心教训：在科学计算中，“精度误差”不是渐进恶化的，它会在某些临界点上突然崩塌。Claude Code 目前没有能力预判这些临界点。

三、深度溯源：为什么 Claude Code 会“算不准”

这一节我不做宽泛的“AI 不擅长数学”这种讨论，而是从技术上把精度丢失的原因拆成三个具体的、可验证的机制。理解这些机制，你才能有针对性地审查 AI 的代码。

3.1 第一种机理：模型不具备数值稳定性直觉

数值稳定性和数学正确性在代码层面往往对应不同的表达式选择，而这个选择不是从语法里就能推导出来的。

经典的例子是二次方程求根公式。数学课本教你用 (-b ± sqrt(b² 4ac)) / (2a) 来计算两个根。这在数学上完美无缺。但当你用单精度浮点、且 |b| 远大于 |4ac| 时，sqrt(b² 4ac) 会非常接近 |b|。这时候如果你选的那个符号让两个接近相等的数相减，就会发生灾难性抵消，丢失几乎所有有效数字。数值稳定的实现会用另一种等价的表达式来避免这个相减：对于同号的情况，改用 (2c) / (-b ∓ sqrt(b² 4ac))。

我让 Claude Code 生成一个求解一元二次方程的 Python 函数。它在 20 次生成中， 19 次使用了标准公式，0 次主动引入稳定形式。 只有当我在 Prompt 中明确写“请使用数值稳定的求根公式，避免灾难性抵消”时，它才会给出正确的实现。

这说明什么？ 说明 Claude Code 在生成数值代码时，默认调用的“知识”是教科书上的数学公式，而不是数值分析课程里关于浮点运算的那些经验法则。它没有养成那种在看到 a b 且 a ≈ b 时立刻皱眉的肌肉记忆。

3.2 第二种机理：上下文盲区导致精度假设崩塌

Claude Code 在生成代码时，只能看到你 Prompt 里给的信息。当你不告诉它数据的量级、范围、分布时，它会用最“安全”的默认实现。但“默认”在数值世界里往往是“最危险”。

我做过一个实验：用完全相同的 Prompt 两次让 Claude Code 生成计算矩阵逆的代码，唯一的区别是在第二个 Prompt 中添加了一句：“该矩阵是高度病态的，条件数约为 10¹²。” 第一次生成用的是标准 Gauss-Jordan 消元法（带部分主元选取）。第二次生成时，它不仅换了算法（变成 SVD 分解求伪逆），还在代码注释里主动加了：“对于接近奇异的矩阵，使用 SVD 并设置一个与机器精度匹配的奇异值截断阈值。” 精度从第一次的完全不可用，提升到了误差控制在 1e-8 以内。

结论：精度问题中有相当一部分不是模型“不会”，而是你不告诉它背景，它就无从判断。 这反过来也意味着，Prompt 的写法极大地决定了最终代码的数值质量。

3.3 第三种机理：训练数据中的“演示用代码”主导了生成

Claude 的训练数据包含了大量来自教程、文档、Stack Overflow 的代码片段。这些代码的共同特点是：为了清晰性牺牲了数值稳健性。当我分析那些精度有问题的 AI 生成代码时，发现很多模式都直接对应着常见的教学代码。

例如计算标准差。直接用 np.sqrt(np.mean(x2) np.mean(x)2) 这种写法在几乎所有 Python 入门课的 NumPy 部分都会出现。它对教师来说清楚易懂，但对数值计算专家来说则是禁忌，因为当数据的变异系数很小（比如所有值都在 1e6 附近波动）时，np.mean(x2) 和 np.mean(x)2 这两个大数相减会吃掉几乎全部有效数字。

Claude Code 在 10 次生成标准差函数时，8 次用上面这种写法。只有 2 次用了 Welford 在线方式或至少用了 np.std(ddof=1)。 这种偏好不是偶然的，而是训练数据分布的直接投影。

四、我建立的精度审查流程：一套可操作的“排雷”方法

鉴于以上三个机理，我把 Claude Code 生成数值代码后的审查流程标准化成了四个步骤。在我的团队里，这四步是强制性的。

步骤一：输入空间边界扫描

不急着看代码逻辑，先跑测试。而且不是跑正常输入，是跑极端输入。我会用一个小脚本自动生成以下类型的测试点：

• 极大量级：所有输入值乘以 1e10 和除以 1e10
• 极近相等值：构造两组只差 1e-12 的数据
• 奇异/病态情况：比如接近奇异的矩阵、退化的几何体
• 零和次正规数：包含 0.0、1e-308 这类边界值

用这些点去压 Claude Code 生成的函数，看哪里崩溃或精度崩塌。这个方法成本很低，但已经帮我拦住了至少 40% 的精度问题。

步骤二：与参考实现差分比较

并行运行一个已知精度的参考实现（通常来自成熟的科学计算库如 SciPy、GSL、Eigen），逐输出点计算相对误差。 关键不是看平均误差，而是看最大误差的位置。 精度崩塌往往发生在输入空间的某个小角落里。

我的经验规则是：如果任一测试点上的相对误差超过 1e-9，就需要深入检查该点的计算路径。

步骤三：关键子表达式的稳定性审查

对于在步骤二中暴露出问题的代码，我会逐行审查其核心表达式。重点关注这三类：

类型一：接近相等的数相减或相加（会抵消有效数字）。

类型二：大数除以小数或小数除以大数（放大误差或产生溢出）。

类型三：迭代过程中的误差累积（每一次迭代都在前一步误差的基础上继续）。

对于类型一，可以用代数等价变换避免相减；对于类型二，可以先做缩放；对于类型三，可以改用补偿求和或误差修正算法。

步骤四：针对性 Prompt 修复或人工重写

把发现的问题反馈给 Claude Code，带上具体的数值场景，让它修正。在 80% 的情况下，它能给出正确的修复。剩下 20% 需要人工重写，通常是因为问题涉及底层数值算法的选择，而模型在该算法上的训练数据不足。

五、实际修复案例：从灾难性抵消到稳定实现的全过程

我用一个具体的代码修复案例来展示上述四步流程在实战中是怎么运行的。这个案例来自计算稀疏点集协方差矩阵的特征值分解。

Claude Code 生成的初始代码如下（简化展示核心问题部分）：

def compute_covariance_eigen(data):
中心化

mean = data.mean(axis=0)

centered = data  mean

协方差矩阵

cov = (centered.T @ centered) / (data.shape[0]  1)

Cholesky 分解求特征值

L = np.linalg.cholesky(cov)

... 后续使用 L 进行迭代

return eigenvalues

步骤一测试发现，当数据点分布在一条近似直线上（实际场景中很常见）时，协方差矩阵接近奇异，Cholesky 分解直接失败。

步骤二差分比较发现，在数据方差比值超过 1e6 时，centered.T @ centered 这一步在内部用到了单精度乘法累积，累积和的双精度结果引入了约 1e-12 量级的非对称性，而这个非对称性在后续 Cholesky 中会导致负特征值（在数学上不可能出现）。

步骤三审查发现，问题出在累积计算方式上。大数加小数的累积顺序导致了舍入偏差。

步骤四我要求 Claude Code 修复，并给出了具体的数值上下文。修复后的代码：

def compute_covariance_eigen_stable(data):
中心化（使用双通补偿求和以提高精度）

mean = data.mean(axis=0)

centered = data  mean

使用两层精度的累积

cov = np.zeros((data.shape[1], data.shape[1]))

for i in range(data.shape[0]):

cov += np.outer(centered[i], centered[i])

cov /= (data.shape[0]  1)

强制对称化以消除累积误差

cov = (cov + cov.T) / 2

使用截断 SVD 代替 Cholesky 处理病态情况

U, s, Vt = np.linalg.svd(cov, hermitian=True)

eigenvalues = s

return eigenvalues

关键改动包括：用显式循环累加代替矩阵乘法以减少累积误差；强制对称化消除舍入带来的非对称性；用 SVD 替代 Cholesky 以处理近奇异情况。修复后，最大相对误差从原来的 4.3e-7 降到了 2.1e-14。

六、Prompt 工程：如何让 Claude Code 从一开始就更重视精度

与其每次都修复，不如在第一次生成时就让精度问题的概率降到最低。我经过了大量试错，总结出了一套在 Prompt 层面提高数值质量的策略。

6.1 在 Prompt 中注入数值上下文

不要只说“写一个求解线性方程组的函数”，而要补上：

• 矩阵的预期规模和稀疏结构：“矩阵为 5000×5000 稀疏矩阵，非零元约 1%，条件数约为 10⁸”。
• 输入数据的量级和精度要求：“输入元素量级在 1e-9 到 1e9 之间，要求最终解的相对残差 < 1e-12”。
• 特殊边界条件：“矩阵可能接近奇异，设计一个在病态条件下仍能稳定运行的求解器”。

这些信息不是“附加项”，而是决定 AI 选择什么算法的核心输入。

6.2 明确要求数值稳定性

在我的测试中，下列关键短语能显著改变 Claude Code 的输出质量：

• “请优先考虑数值稳定性而非计算简洁性”
• “避免任何可能导致灾难性抵消的表达形式”
• “如果有多种数学等价的实现方式，请选择在浮点运算下最稳定的”
• “添加注释说明你在每个关键步骤中为精度所做的考量”

加了这些短语之后，AI 生成的代码在步骤一的边界测试中，通过率从约 60% 提升到了约 85%。

6.3 要求生成精度测试代码

在 Prompt 结尾加上一句：“请同时生成一个精度验证函数，用极端输入测试主函数的数值行为，并报告最大误差所在位置。” 这样 Claude Code 不仅生成算法，还帮你做了步骤一和步骤二的一半工作。我现在的标准做法就是让 AI 自己生成测试框架。

七、什么情况下可以用 AI 代码、什么情况下必须手写

这不是一个“全盘接受”或“全盘否定”的问题。基于前面的实验数据，我画了一个决策矩阵。

高信任度场景（AI 代码可以承担主要计算责任）：

• 算法具有天然的数值稳定性，例如矩阵乘法、标量向量积、FFT（依赖成熟库的版本）
• 计算的数学结构良好，例如严格对角占优矩阵的求解、正值数据的统计计算
• 中间结果可以轻易验证，例如每一步都有解析解可以用来对照

中等信任度场景（AI 代码可用，但必须做步骤一和步骤二的验证）：

• 常规的数值积分、微分方程初值问题（用标准方法如 RK45）
• 一般的优化问题（梯度下降、Newton 类方法）
• 线性方程组的非病态求解

低信任度场景（强烈建议人工编写核心逻辑，AI 只做辅助）：

• 涉及大规模病态系统的求解
• 需要高精度迭代收敛到指定容差的长链计算（如 CFD 的内迭代）
• 对极值敏感的问题（如尾部风险建模、稀有事件概率计算）
• 长时程模拟中的误差累积控制（如天体力学 N 体问题）

但即使在高信任度场景下，也必须至少用一组极端输入跑一次。这不是信不信任 AI 的问题，这是科学计算的基本纪律。

八、工具链：我用于精度审查的脚本和库

我把日常用的精度审查工具整理了一下，它们和 Claude Code 本身构成了一个互补的流水线。

数值验证层：

• 使用 mpmath 库做高精度参考计算。设置 mp.dps = 50（50 位十进制精度），用它算出“真值”，然后用它来衡量双精度的 AI 代码偏离了多少。
• 使用 hypothesis 库做基于属性的测试。例如定义属性：“对于任意正定矩阵 A，Cholesky 分解后 L @ L.T 与 A 的 Frobenius 误差应小于 1e-12”。让 hypothesis 自动搜索反例。

误差分析层：

• 编写了一个通用的误差扫描脚本，输入函数和参数空间定义，自动在参数网格上采样，输出误差的热力图。对于高维参数空间，用 Sobol 低差异序列采样代替网格。
• 使用 numpy.errstate 捕获浮点异常（溢出、除零、无效操作），这在边界扫描时能提示代码在哪类输入下不稳健。

代码审查层：

• 用简单的正则脚本扫描 Claude Code 生成的代码，标记出包含 a b 模式且 a 和 b 被赋值为相近量的位置。不是直接报错，而是提醒人工重点观察。
• 对于 Python 代码，跑一次 mypy 检查所有浮点操作的类型一致性，避免意外的类型提升或降级。

这套工具链加在一起，把审查一个算法模块的时间从半天压缩到了一小时以内。

九、给不同角色的具体建议

如果你是计算科学的研究员

你的首要任务是保证论文结论的数值可靠性。使用 Claude Code 没有问题，但你在方法论部分应该说明两个事实：第一，哪些代码模块由 AI 辅助生成；第二，你做了哪些精度验证步骤。这类似于你用了第三方数值库需要交代版本和测试情况。可重复性要求覆盖 AI 辅助生成的代码。

如果你是带团队的工程负责人

给团队制定两条硬性规定。第一，任何人用 Claude Code 生成的数值计算代码，必须提交时附带边界扫描测试脚本及其运行结果截图。第二，涉及迭代收敛、矩阵分解、统计矩估计的模块，默认归类为“需人工复核”，不允许直接合并到主分支。这两条能拦住 80% 以上的精度事故。

如果你是开源科学计算库的维护者

可能需要考虑建立一个“AI 生成代码贡献指南”，明确要求贡献者如果提交了 AI 辅助编写的代码，必须同步提供高精度参考比较结果和测试覆盖范围声明。这个问题迟早会浮出水面，不如提前摆明标准。

十、总结：精度不是附加要求，它就是科学计算的本质

写这篇文章时，我翻看了过去九个月的实验笔记。最让我不安的发现不是 40% 的模块有精度问题，而是很多研究者在使用 AI 生成代码时根本不认为自己需要检查精度。他们的共识似乎是：“AI 生成的代码语法正确，逻辑看起来也对，那就没问题。”

在科学计算的语境里，这种心态会直接导致错误的研究结论。一个因为浮点累积误差而偏移 2% 的模拟结果，完全可能把一个本该发表的材料相变预测变成“未观察到显著效应”，进而被埋没。一个因为 Cholesky 分解失败而未收敛的优化迭代，可能让一个本可行的工程设计被认为“无解”。

Claude Code 是极好的科学计算辅助工具，但它替代不了数值分析领域的专业判断。 我现在的做法是：把它当作一个能快速产出算法草稿的初稿助手，然后把 70% 的精力用于审查和验证这篇“草稿”的数值行为。这个投入比例听起来可能让人犹豫，但如果你考虑到一个计算错了导致的代价，无论是论文被撤稿、工程方案被推翻、还是交易策略的意外亏损，那这 70% 的审查精力投入是世界上最划算的事。

如果你刚准备开始在科学计算项目中使用 Claude Code，我今天给你的唯一步骤是： 下一次，当它生成了一段看起来很漂亮的数值函数后，不要直接跑实际数据。先准备三组极端输入，用高精度库算出真值，和 AI 的输出做逐点对比。花不了二十分钟，但你会就此建立起对“AI 生成的数值代码需要被审视”这件事的切身体感。

第一步就从那个边界扫描脚本开始。工具都有了，数据前面也给了，剩下的只需要你在下一次 Claude Code"Generate" 之后多做一个动作： 先别信，先测。