在科学计算场景中用 claude code 加速 NumPy 代码撰写

去年秋天，我在处理一个气候模拟项目的数据管道时，遇到了一个让我抓狂的问题：需要对一个三维气压数据立方体（经度×纬度×时间，大约是 720×360×8760 的规模）进行分段归一化，同时还要应用基于阈值的异常值检测。我花了整整一下午调试代码，经历了三次索引越界、两次广播错误、一次内存溢出，最后写出了一段虽然能跑但自己都不敢再看的 NumPy 代码。

那天晚上我做了一件事：我把这个问题用自然语言描述给了 Claude Code，但没有说“帮我写代码”，而是说“帮我审查一下这段代码的逻辑，看看有没有更高效的向量化方法”。接下来的 20 分钟对话，让我重新思考了“编程”这个动作在科学计算中的本质。

核心结论其实很简单：在科学计算场景中，Claude Code 真正的价值不是“替你写 NumPy 代码”，而是作为一个“能理解数学语义的协作引擎”，帮你快速探索最优的向量化实现路径、识别广播陷阱、并加速从“公式到代码”的转化过程。

这个结论我在过去 8 个月里反复验证过。我统计了自己在 3 个科研项目中的数据：使用 Claude Code 辅助 NumPy 代码撰写后，从数学公式到可运行代码的平均时间从 47 分钟缩短到 19 分钟；代码中的广播错误率下降了约 60%；更重要的是，我在调试维度变换上的时间减少了 70% 以上。但这不是“一键生成”的魔法，而是一套需要训练的人机协作技能。

一、首先我们要明确一个问题：科学计算场景下的 NumPy 编程，到底难在哪里？

我在不同的技术社区做过一个非正式调查，收集了 200 多位经常使用 NumPy 的研究者和工程师的反馈。结果很有趣：大多数人最头疼的并不是“不知道用什么函数”，而是“我知道公式长什么样，但不知道如何高效地用 NumPy 表达出来”。

这个区别很关键。传统的 AI 代码补全工具擅长的是“根据上下文补全下一行代码”，这是对“打字效率”的优化。但科学计算场景的核心矛盾是语义转化效率，你脑子里有一个清晰的数学表达式，你知道要在每个时间切片上做 SVD 分解，你知道要沿着 axis=2 做累积和再做差分，但把这些语义精准地、高效地映射到 NumPy 的操作序列上，这个转化过程的摩擦成本很高。

举个实际的例子。去年我审过一个博士生的代码，他在处理卫星遥感数据时需要做这样一个操作：对每个像元的时间序列，找到第一次超过阈值的那个时间点，然后用这个时间点对齐所有像元重新构建矩阵。他用了三层嵌套的 for 循环，代码跑了 8 分钟。我们一起用向量化重写，核心部分变成了 4 行，跑完只用了 3 秒。

但这种重写对人的思维模式有很高的要求。你需要同时理解数学语义、NumPy 的广播规则、轴操作的习惯用法，还要预判内存分配。这就是科学计算编程的真正门槛，它不是语法问题，是思维模式问题。

Claude Code 在这里的角色就很有意思了。它不是一个写代码更快的打字机，而是一个可以跟你讨论“这段数学应该用什么 NumPy 模式表达”的协作者。这是根本性的区别。

二、我是如何重新理解“AI辅助NumPy编程”这个命题的

先讲一个反常识的观察。去年 11 月 Anthropic 发布 Claude Code 时，大多数人的关注点都集中在“它能不能替代程序员”这个层面。但我在实际使用中发现：在科学计算场景中，Claude Code 最有价值的能力不是你给它一个 prompt，它给你一段完整代码，而是“逐步对话式重构”的能力。

我做过一个对比测试。同一个任务，对不规则网格上的气象数据进行空间插值，我用三种方式来完成：

• 方式 A：自己从头写，包括推导 IDW 插值的向量化形式。
• 方式 B：直接用 ChatGPT/Claude 网页版提问，让它生成完整代码。
• 方式 C：使用 Claude Code 的对话模式，分五步走：先讨论数据结构和算法选择，再生成函数骨架，然后逐步填充核心计算逻辑，中途询问替代方案的性能差异，最后审查代码的广播正确性。

结果很有意思。方式 B 生成的代码第一版就能跑，但存在两个隐蔽问题：它在处理 NaN 值时会静默传播错误，而且在边界条件上索引范围偏了一个像素。这两个问题我是在运行结果不对劲时才发现的。

方式 C 因为是逐步构建的，我在每一步都能“闻到”潜在的问题。比如在讨论 IDW 插值的权重归一化时，Claude Code 主动提到了“如果出现零距离（同一点），权重会变成无穷大，需要在分母上加一个极小值或者单独处理”。这个思考在我自己写的时候很容易遗漏，但它出现在对话中就成为了显式的检查点。

这就是我想强调的核心方法论：在科学计算场景中，Claude Code 的正确用法不是“生成式”，而是“对话式”。 你不是在索取代码，而是在和它一起“思考”这段计算该怎么写。

这和很多人的直觉相反。大多数开发者第一次用 AI 辅助编程时，都倾向于用一个长 prompt 描述需求，然后期待得到完整可用的代码。但在科学计算这个特定领域，这个策略的成功率其实很低。原因是科学计算的复杂性不在代码量，而在语义精确性上。一个 prompt 再详细，也很难完整描述你在维度变换、边值处理、数值稳定性这些细节上的考量。

三、从头搭建一个“科学计算协作环境”

先用一个月内我搭建的环境作为具体案例。这不是教程，是我摸索出来的配置策略。

3.1 为什么我放弃了 IDE 插件路线，选择了 Claude Code 的对话模式

我在 VSCode 上用了一年多的 GitHub Copilot，也试过 Codeium。这些工具对于写 Django API、写 React 组件确实好用，因为有大量重复模式可以学习。但当你写 NumPy 的科学计算代码时，它们的表现就急转直下。

原因我后来想明白了。代码补全工具的工作原理本质上是“模式匹配”，基于你当前文件和其他人代码库中的模式来预测下一行。 但科学计算代码的“模式”是很稀疏的，每个研究课题都是独特的问题，你的变量命名、张量形状、操作序列都高度定制化。模式匹配在这种场景下提供不了多少价值。

Claude Code 的不同之处在于，它的推理链路不是“猜下一行”，而是“理解你的数学意图”。当我说“我要对这个矩阵的每一行做 Z-score 标准化，但要排除掉标准差为零的行避免除零错误”，它能理解这里涉及几个操作：np.std 沿着 axis=1、处理 std==0 的掩码、np.divide 配合 where 条件。这不是模式匹配，是对数学语义的解析。

3.2 我的工作区配置策略

经过几个月的调整，我现在的工作环境是这样的：

• 主编辑器：依然是 VSCode，用来查看和手动修改代码。
• Claude Code 终端：在 VSCode 的集成终端里运行，保持对话在侧边可见。
• 工作流程：先在 Python 文件里写好函数签名和 docstring（用数学语言描述输入输出），然后在 Claude Code 对话中逐步讨论实现。

关键配置细节：

• 打开 Filesystem Access：我让 Claude Code 直接读取当前项目文件。这一步很重要，因为它能理解你已有的数据结构、导入的库、甚至你的代码风格。
• 设置自定义指令：我加了一条“在涉及 NumPy 操作时，优先使用向量化而非循环，如果无法避免循环，请明确说明原因”。这个小设置让它在推荐代码时会自检向量化的可行性。
• 分文件策略：我会把核心计算逻辑拆成小函数放在不同文件里，每次对话只聚焦一个函数。这避免了对话上下文过长导致推理质量下降。

四、实战：用五个真实案例理解协作模式

以下所有案例都是我亲自做过、反复迭代过的。每个案例我都不只是展示“最终优美代码”，而是复现我和 Claude Code 的对话过程，让你看到协作的节奏和关键决策点。

案例一：三维张量的分段归一化

背景：气候模式的输出是一个三维数组 data[time, lat, lon]，需要对每个空间网格点的时间序列做分段处理，按照季节切分成四段（DJF, MAM, JJA, SON），每段内做 min-max 归一化。

我的初始思路：写一个循环遍历每个网格点，用索引切片取出每个季节，逐段归一化，再写回。这是最直觉的做法，但明显会有性能问题，网格点数量是 720×360≈26 万个，这个循环会很慢。

与 Claude Code 的对话过程：

我先描述数据结构：“我有一个形状为 (8760, 360, 720) 的数组，axis=0 是时间序列，时间步长是小时。我需要按气象季节分段，每个季节内独立做 (x-min)/(max-min) 归一化。”

Claude Code 第一步没有直接写代码，而是反问了我几个澄清问题：“时间序列的起始点是什么？是标准的 1 月 1 日开始吗？你指的 DJF 是当年 12 月到次年 2 月还是跨年定义？归一化是就地修改还是返回新数组？”

这个反问环节就是专业协作的标志。 它在帮我明确模糊的数学语义，而不是盲目输出代码。我澄清了起始时间和季节定义后，它给出了策略建议：用 np.reshape 和 np.repeat 构造季节掩码，然后用广播做分组归一化。

但第一次生成的代码有个效率问题：它创建了完整大小的季节索引数组，内存占用翻了一倍。我在对话中指出这个点后，它调整了策略，先用 np.unique 获取季节标签，然后在循环中只对每个季节内部做操作。虽然保留了一个季节级别的循环（4次），但去掉了 26 万个网格点的循环，性能提升了近 3000 倍。

最终代码的核心片段：

season_labels = get_season_labels(timestamps)  # shape (8760,)
unique_seasons = np.unique(season_labels)

result = np.zeros_like(data)

for season in unique_seasons:

mask = season_labels == season

season_data = data[mask]  # shape (n_hours, 360, 720)

data_min = np.min(season_data, axis=0, keepdims=True)

data_max = np.max(season_data, axis=0, keepdims=True)

处理除零情况

denominator = np.where(data_max != data_min, data_max - data_min, 1.0)

result[mask] = (season_data - data_min) / denominator

这个例子教会我的是什么？Claude Code 最佳的使用方式是“抛出你的思路，让它作为批判者来审视”，而不是“接收它给出的第一版方案”。

案例二：使用 einsum 替代复杂的矩阵乘法链

背景：在一个贝叶斯反演模块中，我需要计算一个形如 X.T @ inv(C) @ (y - y_model) 的表达式，其中 X 是 (n_params, n_obs)，C 是 (n_obs, n_obs) 的协方差矩阵，y 是 (n_obs,) 的向量。

与 Claude Code 的对话过程：

我一开始写成了：

result = X.T @ np.linalg.inv(C) @ (y - y_model)
这行代码能跑，但有两处糟糕的实践：显式求逆矩阵（数值不稳定且慢），以及两次矩阵-向量乘法没有优化结合顺序。

我当时对这个表达式的计算顺序拿不准，是应该先算 inv(C) @ (y-y_model) 还是该用什么别的技巧？我把这个困惑直接抛给了 Claude Code：“这段代码在 n_obs 超过 10000 时会很慢，而且我担心求逆的数值稳定性。有没有更稳健和快速的方式？”

它的回答让我很受启发。它指出：第一步是用 np.linalg.solve(C, y - y_model) 替代 inv(C) @ (y - y_model)，这避免了求逆且数值更稳定。第二步是用 np.einsum 来重写 X.T @ z 部分，因为在这个特定形状下，einsum 比默认的矩阵乘法有更好的内存访问模式。

更令我惊讶的是，它还主动分析了结合顺序。如果要计算 X.T @ inv(C) @ X（出现在高斯过程中的公式），先算 X.T @ inv(C) 再乘 X 的复杂度是 O(n_params²·n_obs)，而如果 n_obs >> n_params，用线性求解结合 Cholesky 分解会快得多。

这个过程不是“AI给我正确答案”，而是“AI帮我理清了我在数值线性代数中的盲点”。 这是代码补全工具永远做不到的事。

案例三：处理不规则索引时的幽灵广播错误

背景：这是我最喜欢讲的一个案例，因为它展示了 Claude Code 作为一个“调试对话者”的价值。

我在处理海洋模型输出时，需要用不规则索引（从外部读取的经纬度索引列表）从一个四维数组 data[time, depth, lat, lon] 中提取特定站点的时间序列。我的代码简化后是这样的：

station_indices = np.array([[10, 20], [15, 30], [18, 35]])  # 假设是[lat_idx, lon_idx]
extracted = data[:, :, station_indices[:, 0], station_indices[:, 1]]

我认为这样能得到形状 (ntimes, ndepths, nstations) 的结果。但实际运行时得到一个形状完全出乎意料的数组，而且部分值是错误的。我花了 40 分钟用 print 大法排查，还是没搞懂广播到底是怎么走的。

我把这段代码和数据结构描述贴给了 Claude Code，并说明：“我认为应该得到形状 (8760, 40, 3)，但实际得到的是 (3, 8760, 40) 且数据对应不上。”

Claude Code 的反应让我很受触动。它不是直接告诉我正确答案，而是分了三步解释：

1. 它先画出了我的索引路径：station_indices[:, 0] 是一个一维数组 [10, 15, 18]，station_indices[:, 1] 是 [20, 30, 35]。
2. 然后指出 NumPy 的“高级索引”规则：当你用多个数组索引不同维度时，会触发广播和花式索引的组合效果，得到的结果是 data[times, depths, [10,15,18], [20,30,35]]，这等价于选择 3 个对角线元素，而不是 3 个任意位置的站点。
3. 最后给出解决方案：需要用一个二维索引器配合 np.expand_dims 或直接使用列表推导。

这个调试过程的深度，远超我使用过的任何传统调试工具。 Claude Code 不是在告诉我“哪里错了”，而是在解释“NumPy 的索引规则是如何导致这个行为差异的”。这种解释让我后来遇到类似问题能自己诊断。

案例四：将递归滤波转换为卷积操作

背景：我在处理时间序列的低通滤波时，最初直接翻译了一个 MATLAB 代码，用了 for 循环实现指数加权移动平均（EWMA）。问题在于这个 EWMA 的衰减因子是时变的，依赖于外部的时间戳间距，所以不能直接用 pandas.ewm。

与 Claude Code 的协作：

我的初始实现是一个纯 Python 循环，处理 10 年的小时数据要 12 秒。我把代码贴给 Claude Code 时说：“这个递归滤波的计算公式在这里，现在用纯循环太慢了。衰减因子 alpha 随时间步长 dt 变化，所以不能直接用固定参数的 EWMA。”

Claude Code 分析后指出了关键洞察：虽然 alpha 是时变的，但这个递归公式可以用 scipy.signal.lfilter 在特定条件下转为 IIR 滤波器的向量形式。它帮我推导了将时变系数近似为时不变分段常数的策略，把数据按月分段，每段内 alpha 取均值，用 lfilter 批量处理。

第一次尝试后精度损失有点大（在分段边界上），我又和 Claude Code 讨论了用重叠分段和线性插值来平滑边界的方案。最终版本既保持了足够的精度（与原始递归公式的最大偏差 < 0.5%），又将运行时间从 12 秒降到了 0.3 秒。

这个案例的特殊之处在于，Claude Code 参与了“算法转换”这个通常被认为是纯人类领域的思考过程。 它没有发明新算法，但它知道 lfilter 可以表达递归滤波，并建议了分段近似的工程技巧。这种知识广度，单个研究者很难自己覆盖。

案例五：编写自文档化的 NumPy 函数

背景：我之前的 NumPy 代码有一个坏习惯，写完就忘。三个月后回头看自己的函数，要花好久才能理解当时的意图。维度命名（axis=0 还是 axis=1）、归一化方式、NaN 处理策略，这些信息都丢失在一堆没有注释的数组操作里。

与 Claude Code 的协作：

我开始用一个新策略：写完一个计算函数后，让 Claude Code 审查并添加“面向未来自己的注释”。具体做法是把函数贴给它，问：“三个月后的我再看这段代码，会在哪里卡住？请帮我标注出需要解释的操作，并给出注释建议。”

这个用法看似简单，但产出很惊人。Claude Code 能识别出那些“看似简单但实际隐晦”的 NumPy 习惯用法。比如 np.diff(x, axis=1) 对于熟练用户是日常操作，但它标记说“如果 x 的 axis=1 不代表空间维度，这里的语义就不直观”，并建议在注释中明确写出维度含义。

更重要的是，它帮我总结函数的“输入输出契约”，shape 的变化、NaN 传播行为、是否修改原数组。这些我都知道应该写，但总是因为麻烦而省略。现在有 Claude Code 来做这个“脏活”，我只需要审查和微调。

五、拆解误区：我发现的最常见的三个错误使用方式

通过这 8 个月的密集使用，我在我自己和身边的同事身上，逐渐总结出了 三种对 AI 辅助 NumPy 编程的高频误解。这些误区直接决定了你是在“加速”还是在“添乱”。

误区一：把 Claude Code 当成“代码生成器”来用

这是我见到的最普遍的用法，把一个复杂的科学计算需求塞进一个长 prompt，期待得到完整可运行的代码。这种用法的问题不在于 AI 不够强，而在于科学计算的复杂度不可能在一个 prompt 里完全描述清楚。

当你写“请编写 NumPy 代码对一个三维数组进行归一化”时，你没有说明的隐含假设至少有十几个：归一化是沿着哪个轴？min-max 还是 Z-score？NaN 怎么处理？零标准差怎么办？in-place 还是返回新数组？数据类型是 float32 还是 float64？内存够不够？

正确的做法是把 Claude Code 当成一个会主动问你这些澄清问题的同事。 不要一次性描述完所有需求，而是先给出核心计算任务和数据结构，让它反问，然后再逐步细化。这种“对话式需求澄清”的产出质量远高于“一次性生成”。

误区二：假定生成的向量化代码一定比循环快

我看到很多人在 Claude Code 生成了一段使用复杂广播或 einsum 的代码后，就默认它是“高性能的”。但在 NumPy 的世界里，不是所有向量化都等价于快速。

我遇到过一个实际案例。Claude Code 为一个小批量时间序列的协方差矩阵计算生成了非常炫技的代码，使用 np.einsum('ijk,ilk->jl', ...) 一行完成。但实际运行后发现，在小样本量下（比如 n<100），一个简单的 for 循环版本反而快 3 倍。为什么？因为 einsum 的初始化开销在小规模下占比很高，而它的内存复用优势要到大规模才显现。

关键教训：Claude Code 的代码建议需要经过实际性能测试验证。 我现在的工作流是：让 Claude Code 生成一个向量化版本和一个循环版本，用 timeit 实际对比后再决定用哪个。而且我会把这个测试结果反馈给它，帮助它在后续对话中调整对性能的假设。

误区三：忽略内存布局对 NumPy 性能的影响

这个误区很隐蔽。Claude Code 生成的代码通常在“算法正确性”上没问题，但在“内存访问模式”上可能不优化。NumPy 在 C-contiguous 和 Fortran-contiguous 数组上的操作性能差异可达 5-10 倍，但 Claude Code 默认假设都是 C-contiguous。

我给一个实际数据。在上面的案例一中，Claude Code 最初的代码对 data[mask] 的结果进行了后续操作。这个索引结果可能不是 contiguous 的，导致后续的 np.min 和 np.max 操作触发了不必要的内存拷贝。加了 np.ascontiguousarray 后性能提升了 40%。

解决方案：我在自定义指令中加了一条“在对索引结果的数组进行密集计算前，考虑是否需要确保内存连续性”，Claude Code 之后会在关键位置提醒我这个点。但最终决策还是要我自己根据实际数据规模来判断，这就是我强调的“协作”而不是“委托”的核心含义。

六、专业判断逻辑：如何评估“这段 NumPy 代码是否值得优化”

这是我在和 Claude Code 长期协作中逐渐形成的一个判断框架。当 Claude Code 建议我“这段代码可以进一步向量化”时，我不会立刻接受，而是用这个框架走一遍。

判断维度一：这段代码在实际运行中占了多少时间？

这听起来像废话，但很多人（包括以前的我）会花大量时间优化一个占总运行时间 3% 的代码段。我现在的铁律是：先用 line_profiler 或者简单的 time.time() 确认瓶颈，再决定是否优化。

Claude Code 的一个好用法：让它帮你插入计时代码。直接说“请在关键操作前后加上计时，输出到日志”，它会生成规范的 timing 代码。这比手动写省很多时间。

判断维度二：向量化的可读性代价有多高？

这个权衡在科学计算中特别重要，因为代码需要被同行审查、被未来的自己理解。我见过一段用 np.stride_tricks 实现的滑动窗口操作，性能提升了 4 倍，但三个月后作者自己都看不懂了。

我的判断标准是：如果一个向量化版本的注释行数超过了代码行数，就需要认真考虑是否值得。 科学计算的正确性往往比性能更重要，一个你能理解并正确修改的慢版本，好过一个你看不懂的快版本。

Claude Code 在这里的价值是：它可以生成两个版本，同时解释清楚向量化版本的原理。如果我理解了它的解释，说明这段代码是可维护的；如果我需要反复追问才能搞懂，说明可读性代价太高。

判断维度三：能否使用 Numba 或 JAX 作为替代？

这是 Claude Code 给我带来的一个认知升级。有几次它建议我用 Numba 的 @jit 装饰器替代复杂的向量化重写，因为某些算法（如递归、条件分支多的操作）用循环 + Numba 比硬向量化更清晰且同样快。

我现在有一个简单规则：如果向量化需要引入大量的维度变换和中间数组，而循环逻辑本身很清晰，优先考虑 Numba。 Claude Code 能帮我评估这两种方案的权衡，因为它了解各自的优缺点。

七、不同场景下的行动建议：你的使用策略

基于这 8 个月的经验，我总结了不同场景下使用 Claude Code 的具体策略。这套策略不是一次性摸索出就知道的，而是根据不同计算任务的特性调整出来的。

场景一：探索性数据分析（EDA）

策略：快速迭代，接受非最优代码。

在这种场景下，你需要的是快速验证想法，而不是生产级代码。我的做法是：用自然语言描述“我想看这个变量的分布按时间分组的样子”，让 Claude Code 生成一个包含分组聚合、归一化、可视化的代码块。跑通后立即进入下一步分析，不纠结于代码质量。

关键点：在这种场景中不要陷入优化陷阱。 很多研究者（包括我）会在 EDA 阶段就开始优化代码效率，这其实在浪费注意力资源。Claude Code 在这里就像一个不会累的助手，承担了琐碎的拼写工作，让你专注于分析逻辑。

场景二：算法原型开发

策略：分步对话，每步验证。

这是我最喜欢的 Claude Code 使用场景。当我在开发一个新的统计算法或者实现一篇论文的方法时，我的工作流是：

1. 先用数学语言写出算法步骤，包括输入输出的维度。
2. 和 Claude Code 讨论 NumPy 实现策略，特别是关键步骤的向量化方式。
3. 让它生成函数骨架，我手动填充核心计算。
4. 对于不确定的 NumPy 操作，让它单独生成小例子验证行为。
5. 代码写完后，让它做审查，标注潜在的广播陷阱和数值问题。

这个流程的核心是“小步快跑”。每一步都有验证，错误不会累积。这比一次性生成整个算法再调试要高效得多。

场景三：性能优化

策略：带上性能剖析结果，要求对比方案。

这是最需要人类专业判断的场景。我的做法是：

1. 先用 profiling 工具找出真正慢的部分。
2. 把这段代码和耗时数据一起给 Claude Code。
3. 要求它给出 2-3 种优化方案，并说明每种方案的原理和预期的性能提升（用大 O 或者操作数来估算）。
4. 让它同时标注每种方案的可读性代价和内存开销。
5. 我根据自己的场景选择最合适的，或者混合两种方案。

关键的思维转变：不追求“性能最优”，而是“在可维护性约束下的性能充分优”。 Claude Code 能帮你列出选项，但选哪个取决于你对自己代码库的理解。

场景四：代码维护与文档

策略：让 Claude Code 作为“陌生读者”来审视你的代码。

当一段代码需要归档或者转交给合作者时，我的做法是把整个模块贴给 Claude Code，问它：“作为一个不熟悉这个项目的人，你在哪里会卡住？请列出所有你不理解的变量命名、没有解释的操作序列、以及隐藏的假设。”

它能识别出我习以为常但外人无法理解的模式。比如我用 data[valid_mask, :][:, sorted_indices] 做掩码加排序，这是清晰的 NumPy，但它会指出：“这里的排序是沿着哪个轴的？sorted_indices 来自哪个排序操作？为什么需要两步索引？”

基于它的反馈，我会添加注释或者重构为更显式的表达。这个过程让我的代码文档化程度提升了不止一个档次。

八、不同情况下的取舍：当“理想”和“现实”冲突时

这部分我想讲几个我在实际工作中遇到的“两难”场景，以及我是如何在 Claude Code 的辅助下做出最终决策的。

取舍一：性能 vs. 可重复性

去年有个项目，我需要从 500GB 的 NetCDF 文件中做空间聚合统计，计算时间需要控制在 5 分钟以内以匹配交互式分析的节奏。Claude Code 帮我推导了一个使用 np.lib.stride_tricks 的滑动窗口方案，避免了循环，性能刚好达标。

但在代码审查时，一位合作者明确表示“看不懂”。我面临的选择是：保留这个高效但晦涩的版本，还是回退到一个稍慢但清晰易懂的版本？

我的解决方案是混合策略。 我保留了高效版本作为“性能模式”，但用 20 行注释详细解释了 stride_tricks 的工作原理。同时，我保留了注释掉的循环版本作为“参考实现”，并在测试中验证两者结果一致。

Claude Code 在这里的贡献是：它帮我生成了那段清晰的注释。我告诉它“请给这段 stride_tricks 代码写一个面向 NumPy 中级用户的注释，解释每一步的内存布局变化”。它产出的注释质量远高于我自己能写出的，因为它知道如何用从“新手视角”来看这段代码。

这个案例的教训是：可读性和性能不是二选一。 用注释搭建理解桥梁，是完全可行的中间路线。

取舍二：用新的 API 还是用大家熟悉的旧方法？

科学计算领域有一个张力：新的 NumPy 方法和函数不断出现（比如 np.einsum_path、np.block），但很多研究者还习惯于用老方法。我在使用 Claude Code 时发现它倾向于推荐更现代、更高效的 API，这在技术上没错，但在团队协作中可能造成摩擦。

比如它在处理矩阵拼接时推荐了 np.block 而不是 np.vstack 和 np.hstack 的组合。技术上 np.block 确实更灵活优雅，但我的合作者们熟悉的是 vstack/hstack。如果全换成 block，合作的阻力会增加。

我的取舍原则是：当新 API 的性能提升超过 30% 或代码行数减少超过 50% 时，才值得引入学习成本。 否则，继续用大家熟悉的旧方法。我在 Claude Code 的自定义指令中加入了这条规则，之后它的建议更贴合实际协作需求。

取舍三：GPU 加速还是继续留在 CPU 上？

这可能是科学计算中最大的“诱惑”。当 Claude Code 建议用 CuPy 或者 JAX 的 GPU 版本来加速计算时，很多人的第一反应是“太好了，迁移！”

但我吃过亏。迁移到 GPU 的成本不仅仅是改几行代码。你需要考虑数据传输开销（PCIe 带宽是瓶颈）、内存是否足够装下你的数组、你的算法是否真的适合 GPU 的并行模式（大量分支操作在 GPU 上反而慢）。

我的实用主义原则：只有当单次计算在 CPU 上超过 30 秒，且操作是“大量同质并行”的（比如大规模的矩阵乘法、逐元素运算），才值得考虑 GPU。 对于探索性分析和原型开发，CPU 的灵活性优势远大于 GPU 的性能优势。

Claude Code 在这个决策中帮我的方式是：当我问“能不能用 GPU 加速这段代码”时，它会追问“你的数据量多大？一次运行的数据传输频率是多少？算法中是否有大量分支？”这些问题的答案决定了是否值得 GPU 化。

九、边界与限制：Claude Code 不是什么

经过 8 个月的密集使用，说说我认为的边界。

限制一：算法创新≠算法实现

Claude Code 能帮你“实现已知算法”，但不能帮你“发明新算法”。它可以用 NumPy 写出教科书上的卡尔曼滤波，但不能提出一种新的非线性滤波方法。这不是技术限制，是“理解”和“创造”之间的鸿沟。

科学计算的创新部分，依然需要人类的数学直觉和领域知识。 Claude Code 的价值在于装修环节，把粗坯的数学思想变成高效的、可运行的代码。

限制二：数值稳定性的“暗知识”

Claude Code 生成的代码在“正常数据”下跑通常没问题，但在边缘情况（极大值、极小值、NaN 传播、除零）下可能不够鲁棒。我曾让它生成一个对数似然函数的实现，它在第一版中直接用了 np.log(data)，没有处理可能出现的零或负值。

这说明 Claude Code 缺乏那种“吃过亏才知道”的数值经验。 你需要主动问它“这段代码在什么情况下会出错？”，它才能联想到边缘情况。如果你不问，它默认假设输入是“良态”的。

限制三：无法替代领域专家的代码审查

即使 Claude Code 的代码审查能力已经很强，但它审查的维度限于“NumPy 语法正确性”和“常见模式优化”。它无法判断你的物理模型假设是否正确、你的统计推断是否合理、你的地学数据是否适合作某个标准化。

在科学计算中，最危险的错误不是语法错误（代码会报错），而是语义错误（代码能跑但结果不对）。 Claude Code 帮不了你识别第二类错误。领域知识审查，依然是你和你的同行评审者的责任。

限制四：推理成本的现实考量

虽然这个话题在技术社区讨论不多，但实际使用中必须面对。持续使用 Claude Code 的对话模式，每个月的 API 调用费用可能达到几十到上百美元（取决于对话频率和复杂度）。

我从“用 AI 编程”转变为了“关键环节用 AI 编程”。 简单的循环改写、基础的 API 查询，我用文档或传统搜索引擎解决。只在涉及复杂的向量化设计、多维索引逻辑、性能权衡分析时，才转向 Claude Code。这个使用策略让我的月度开销控制在预算内，同时抓住了最高价值的应用场景。

十、总结：从“编码员”到“架构师”

回到文章开头那个气候模拟项目的例子。那次经历之后，我逐渐形成了一个新的工作哲学。

在科学计算中，Claude Code 最大的价值不是让你写代码更快，而是让你在更高的抽象层次上思考问题。 当我不用再花时间纠结“这个维度该用 expand_dims 还是 reshape”时，我的注意力可以投入到“这个空间聚合方案在物理上合理吗？有没有更好的统计模型？”这些真正需要人类判断力的问题上。

但这里有一个微妙的地方需要警惕。当你习惯性地把实现细节“外包”给 AI 时，你的底层技能会减退。 我现在会刻意地每周抽出一段时间，完全不用 AI 辅助，手写 NumPy 代码。这是为了保持对底层机制的“手感”，理解 broadcasting 的规则、记住 einsum 的语法、感知内存布局的影响。

这种“手感”是你和 Claude Code 有效协作的基础。 如果完全不懂 NumPy 的广播规则，你就无法判断它生成的代码是否正确。如果完全不理解向量化的原理，你就无法在性能和可读性之间做出正确取舍。Claude Code 是你的“扩展知识库”，不是你的“替代大脑”。

你接下来可以这样开始

如果你的研究或工作也涉及大量 NumPy 代码，我建议你从以下几步开始：

1. 先做一次“痛点审计”：回顾你最近三个月的编码经历，找出最让你挫败的 3-5 个 NumPy 相关任务。是维度变换老出错？是向量化难以上手？是调试广播太耗时？明确你的核心痛点在哪个环节。
2. 从一个真实但低风险的任务开始：不要在生产项目上直接尝试。找一个你已经完成的任务，用 Claude Code 的对话模式重新做一遍，对比两种方式的体验和产出质量。
3. 建立你的“自定义指令库”：根据你的领域特点，准备几条固定的指令。我的常用指令包括：“解释你的索引策略”、“标注潜在的广播陷阱”、“提供性能测试代码”、“为三个月后的我写注释”。这些指令会显著提升对话质量。
4. 保持“协作”心态，而非“委托”心态：你是最终决策者。Claude Code 的建议是用来被你审查、挑战、混合、拒绝的。每一次对话都是一次“技术讨论”，而不是“接受任务委派”。
5. 记录你的使用日志：每次重要的协作对话，记录下你的输入、Claude Code 的输出、以及最终你采取了什么方案。3 个月后回看，你会惊讶于自己的成长轨迹，你不仅学会了更好地使用工具，也通过工具的“镜子”反观到了自己的思维盲点。

科学计算正在经历一波静默但深刻的变化。Claude Code 这类工具不是来替代科学家的，而是来重新定义“编程”这个动作在科学研究中的位置。未来的科学计算，可能不再是一个“输入代码、输出结果”的单向流程，而是一个“表达数学意图、协作构建实现、审查正确性、迭代优化”的人机对话过程。

我花了 8 个月才逐渐适应这个新模式。它不是更简单了，但它所释放的创造力和减少的挫败感，让科学计算重新变回了一种“探索的乐趣”，而不是“和维度变换的战斗”。

希望你在自己的科学计算旅程中，也能找到这种状态。