Claude Code 生成复杂算法时的输出稳定性评估

“它第4次给出的答案是对的，但第5次又错了。”

这是我在用 Claude Code 写一个带状态的动态定价算法时，盯着终端屏幕的真实感受。同一个 Prompt，跑了 12 次，正确率只有 58%。不是模型不懂动态规划，它甚至能在第 3 次输出几乎教科书级的带备忘录递归实现。但第 6 次，它突然在状态转移方程里少了一个边界判断，导致价格在临界点跳变。

这不是“能不能”的问题，而是“有多大概率能”的问题。

过去 18 个月，我带着团队在至少 7 个真实项目中重度使用 Claude Code 处理算法密集型任务，从推荐系统的排序逻辑到风控图的连通分量计算，累计生成了超过 3000 段带复杂逻辑的代码片段。我所说的“复杂”，不是写个快速排序或二叉树遍历，那些 Claude Code 已经能稳定搞定。我指的是：多条件耦合的状态机、带剪枝的回溯搜索、并发环境下的无锁数据结构、以及需要同时处理时间和空间约束的动态规划。

这篇文章，是我对 Claude Code 在这些场景下“输出稳定性”的一手评估。不是评测文，是踩坑日志和工程判断。

一、先给你一个反直觉的核心结论

直接说结论，不要铺垫：

Claude Code 在生成复杂算法时，其输出质量呈现显著的“高方差特性”，它可以在同一次会话中，给出正确率 100% 的满分代码，也能在你下一轮 Prompt 稍微改动措辞后，给出一个看似正确但存在致命逻辑缺陷的版本。而且，这种不稳定性不是一个简单的“再跑一次”就能抹平的噪声，而是一种系统性的、可被归因的输出特征。

更反直觉的是：“看起来越简单的算法描述，反而越容易触发不稳定输出。”

举个例子。我们内部做了一次严格控制变量的测试，选取了 10 个经典算法问题，每个问题用完全相同的 Prompt 下达 12 次独立生成指令。结果如下表（数据来自我们团队 2024 年 Q4 的内部基准测试，基于 Claude 3.5 Sonnet 版本的 Claude Code，测试环境为 macOS + API 直连，温度参数保持默认）：

注意“标准差”这一列。它比平均正确率更说明问题。标准差的膨胀速度甚至快于正确率的下降速度。这意味着，你没有“可预期的坏”，你面对的是“今天好明天坏”的完全不可预测性。这对工程排期的影响是灾难性的，你无法判断，今天是它帮你提效，还是你需要花双倍时间 debug 它的输出。

二、不要用“AI写代码靠不靠谱”这种粗粒度问题

在展开之前，我想先纠正一个我经常在社区里看到的提问方式。

很多人问：“Claude Code 写算法靠谱吗？”

这个问题本身就是错的。因为它把“稳定性的责任”完全推给了工具本身，而忽略了你的使用方式在其中起到的作用，这个作用不是修饰性的，而是决定性的。

更准确的问题应该是：“在什么样的 Prompt 策略、任务拆解方式和质量把控流程下，Claude Code 生成的复杂算法输出可以被控制在可接受的稳定范围内？”

我发现一个反复出现的规律：那些抱怨 Claude Code 不稳定的人，通常在做同一件事，把一大段需求描述丢进去，期待它一次性吐出完整可用的算法实现。而那些觉得它“还挺好用”的人，基本上都有一套自己磨合出来的“约束-验证-迭代”工作流。

这不是模型的锅，也不是用户的锅。这是没有理解 AI 代码生成工具的概率属性。

Claude Code 本质上是一个条件概率模型。它不是在“写代码”，它是在计算“给定这段上下文，下一个 Token 最可能是什么”。当你输出的代码长度为 500 Tokens 时，即使模型每一步的预测准确率是 99.8%，整段代码完全正确的概率也只有 (0.998)^500 ≈ 36.7%。如果代码更长、逻辑更复杂、上下文干扰更多，这个概率还会进一步坍缩。

所以我们要谈的，不是“如何让 Claude Code 变得稳定”，而是“如何在这个概率框架下，最大化你获取正确输出的效率。”

三、我测试的“复杂算法”到底是什么

下一节会展开方法论，但我需要先界定什么叫“复杂算法”。因为我发现很多所谓评测，把“写一个斐波那契数列”也算进去了，那 Claude Code 当然稳定到飞起。

我们在测试和实战中定义的“复杂算法”，必须同时满足至少 3 个条件中的 2 个：

条件一：高分支密度。 函数内部存在 5 个以上的独立判断分支，且这些分支之间存在嵌套或相互引用关系。典型场景：多级优惠策略叠加引擎、风险等级判定决策树。

条件二：状态的跨周期演化。 算法需要维护一个随输入或时间推移而变化的内部状态，且前序状态的取值会影响后续路径选择。典型场景：滑动窗口内的最优持仓调整、带记忆的图遍历。

条件三：约束冲突需要显式处理。 问题本身存在多个可能相互矛盾的约束条件，算法必须显式地做消解或优先级排序，而不是简单遍历。典型场景：多目标排序（相关性与多样性冲突）、背包问题中的权重-价值均衡。

在我们的内部任务池中，类似“接雨水”、“最长回文子串”、“拓扑排序”这类 LeetCode Medium 级别的题目，Claude Code 的 12 次平均正确率在 75%-85% 之间波动。但一旦进入“带时间窗的车辆路径规划（VRPTW）的启发式构造”、“分布式事务的状态机补偿逻辑”、“带剪枝的 N-皇后问题变体”这类任务，正确率跳崖式下降到 40%-55%。

这背后有一个我很确定的判断：Claude Code 的算法生成能力瓶颈，不在于它“不懂算法”，而在于它在长距离的因果关系链上无法保持注意力的一致性。

四、为什么“它懂，但做不对”，拆解不稳定性的三个根因

这可能是整篇文章最有价值的部分。我不是要教你几个 Prompt 模板就完事，而是想让你真正理解“不稳定”的来源。因为只有知道为什么，你才能设计出合理的工作流来规避。

根因一：长上下文的 Token 注意力稀释

Claude Code 的一个显著特性是它拥有非常长的上下文窗口（200K Tokens）。这本来是好事，但在算法生成场景下，它反而引入了一个隐蔽的问题。

假设你的项目已经有 3000 行代码，你在某个文件中让 Claude Code 插入一个 150 行的动态规划函数。模型在处理这个请求时，会把你之前的 3000 行代码、系统指令、对话历史全部纳入计算。问题在于：Transformer 架构的注意力机制，在面对超长序列时，会让 token 之间的信息传递出现衰减。

这个图背后的逻辑是：当上下文噪声增加，模型分配给“算法核心逻辑”的有效注意力权重就会下降。它会在非关键代码段上浪费注意力预算，比如它可能在仔细琢磨你上一个函数的注释风格，而忽略了当前函数的边界条件处理。

我在实际开发中多次观察到同一个模式：如果我把文件里与当前算法无关的代码全部删掉，只保留最少上下文，Claude Code 的算法输出质量立刻提升一截。但这个操作在实际项目中几乎不可行，你不可能每次写新算法都先把项目裁成骨架。

根因二：“乐观假设”陷阱，对边缘情况的天生盲区

这是我认为 Claude Code 在复杂算法生成中最致命的弱点。

Claude 的预训练数据中，代码示例通常展示的是“正确路径下的实现”。即使用代码片段涵盖了大量边界处理，但从统计上看，“典型情况的处理”在训练语料中的密度远高于“异常情况的防御”。

这就导致一个后果：当你让 Claude Code 生成一个算法，它天然倾向于先写出 Happy Path 就能跑通的逻辑，而把边界异常留给后续补丁。对于简单算法，这个“后续”只需要加一两个 if 判断；但对于复杂算法，边界处理往往和核心逻辑纠缠在一起，事后修补的成本极高。

举一个我实际踩过的坑。

我们当时在写一个多层风控规则的匹配引擎。输入是一个用户行为序列，输出是匹配到的规则列表。每条规则有优先级，规则之间可能存在包含和互斥关系。我在 Prompt 里明确写了一句：“注意，规则之间可能存在互斥，当规则 A 和规则 B 冲突时，取优先级高的。”

Claude Code 生成的代码，在 10 组测试用例的前 7 组中表现完美。但第 8 组用例触发了“三条规则都存在互斥冲突，其中两条优先级相同”的场景。Claude Code 的代码直接返回了空列表，而正确行为应该是返回“两条规则同时输出，标记为待人工裁决”。

它不是在 API 或语法层面犯错，它是在“我描述的问题没有覆盖到的维度”上自行做了简化假设。 对于程序员，这是危险的，因为代码跑通了前 7 个测试，你很容易以为全对了。

根因三：“生成-修复”循环中的随机漂移

Claude Code 有一个我很喜欢的功能：你可以让它先写完代码，然后让它自己 review，再自己修复。这个循环理论上能显著提升最终质量。

但我们在统计中发现了另一个规律：在多轮“修复”后，代码的正确性并非单调改善，而是在一个区间内随机漂移。

具体来说：前两轮修复通常会显著提升正确率（从 48% 提升至 71%），但第 3 轮以后，模型开始在“修一个 bug 的同时引入另一个 bug”的循环中反复横跳。这是因为在没有外部新信息注入的情况下，模型无法跳出自身的判准局限性，它所谓的“review”只是站在同一个错误的认知平面内做局部优化。

五、错误模式图谱：Claude Code 在复杂算法中最常犯的六类错

在汇总了我们团队 300+ 次复杂算法生成失败案例后，我做了人工归类。下面这张表值得你仔细看，因为它告诉你，当你用 Claude Code 写算法时，你的时间最应该花在审查哪些地方。

这里我想重点说两个隐蔽性最高的类别。

边界条件缺失（38% 最高频）： 它的隐蔽在于，编译过、lint 过、常规测试全过。只在遇到特定输入组合时爆炸。而复杂算法之所以复杂，恰恰是因为边界条件多且非直观。Claude Code 在生成代码时，倾向于“默认输入是合法的、正常的、在预期范围的”。这种假设对于 CRUD 接口无害，对于风控算法致命。

状态转移逻辑断裂（24%，修复难度高）： 这是我最头疼的类型。它的表现经常是：DP 方程在 90% 的情况下正确，但在某个特定状态转移路径上，它跳过了中间态或者重复累加了同一个值。这类 bug 往往不是一眼能看出来的，通常需要你手算几组数据对比输出才能发现。而一旦发现，修复意味着要重新理解模型的“思路”，然后再看代码哪一行出现了逻辑偏差，这个时间成本，有时候比自己重写还高。

六、不同算法领域的稳定性画像

同一套模型，在面对不同算法领域时，稳定性的表现差异巨大。以下是我基于实战经验做的分类画像，并非系统性基准测试，但经过团队内多次验证。

1. 排序与搜索类，高稳定区

这没什么好说的。任何涉及标准排序、二分搜索、哈希查找的任务，Claude Code 表现稳定。因为它见过的训练数据太多了。LeetCode Easy-Medium 级别的排序题，12 次平均正确率 90%+。需要注意的是变体题，比如“带权重的稳定排序”或者“自定义比较器的分块排序”，第一次正确率会有所下降，但往往第二轮 prompt 加一条明确的约束表述就能纠正。

2. 图算法，中高波动

图遍历（BFS/DFS）、拓扑排序这些，稳定性和排序类相当。但一旦涉及带条件的最短路径、二分图匹配、强连通分量，波动就上来了。尤其是“在特定结构图上剪枝”这种需求，Claude Code 经常写出正确但不最优的代码。这不是错误，但在工程上意味着你可能要多跑 30% 的时间。

3. 动态规划，高波动、不稳定之王

这是我个人认为 Claude Code 最吃力的领域。不是说它不会写 DP，恰恰相反，它写出来经常非常漂亮，而是 DP 的正确性对其“隐性前提”极度敏感。

举个例子：“最长递增子序列”是 Claude Code 几乎永远不会写错的基础题。但一旦变成“在不超过 K 次操作下使序列变为最长递增子序列”，这个操作 K 是一个弹性约束，Claude Code 就开始在 K 的计数逻辑上频频翻车。我们统计过，这类“基础 DP + 一维弹性约束”的变体，12 次独立生成中完全正确的概率在 55% 左右。

4. 并发与多线程，极端不稳定

这是我能给出的最强烈警告：不要用 Claude Code 直接生成带并发控制的生产级代码。

并发问题在代码形态上通常很短，几十行就能写完。但这几十行里的锁逻辑、内存可见性、顺序保证，每一个都是静默炸弹。Claude Code 生成的并发代码经常在语义上是“讲得通的”，比如它会记得加锁、会写到 volatile，但在跨平台的 actually 行为上存在根本缺陷。比如我们测试过一个无锁栈的实现，Claude Code 生成的代码在 x86（TSO 内存模型）上跑通，换到 ARM（弱内存模型）直接出现 ABA 问题。

这里有一条我自己的原则：并发算法，必须有人类专家手写，Claude Code 最多用于生成注释和单测框架。

七、稳定性不是“对不对”，是四个维度

我发现大多数人对“AI 生成代码稳定性”的理解太粗糙了。“代码能不能跑”是一个二分变量，但“稳定”不是。“稳定”意味着你有一个合理的置信区间，让你能预测未来的行为。

我把这种“可预测性”拆成了四个独立维度。在这四个维度上，Claude Code 的表现截然不同，必须分开讨论。

维度一：逻辑完整率

定义： 代码是否正确实现了你所要求的核心算法逻辑（忽略性能与边界）。

这是 Claude Code 的强项。即使它在边界上犯错，但大约 80% 的生成结果在逻辑主干上是基本正确的。就是说，你会得到一段“思路对、结构对、但细节需要打磨”的代码。

这 80% 的逻辑完整率，决定了 Claude Code 在实际开发中的核心价值：它是一个出色的“初稿引擎”。 你不需要从零开始思考算法框架，它会在毫秒级给你一个结构清晰、变量命名合理的起点。

维度二：边界覆盖度

定义： 生成的代码是否显式处理了所有合理的边界输入（空值、极值、溢出、非法参数等）。

这是 Claude Code 最不稳定的维度。我们统计发现，在没有额外强调边界条件的情况下，Claude Code 生成的复杂算法，边界覆盖度只在 35%-45% 之间，也就是超过一半的情况下，代码没有主动处理那些“可能导致程序崩溃”的输入。

但这里有一个好消息：边界覆盖度是目前最容易被 Prompt 提升的维度。 你只要在 Prompt 里明确列出边界条件（比如：“请处理输入为空、长度为 1、以及所有值为负的情况”），覆盖率可以迅速跳升到 70%+。

这不是 Claude 做不到，是它默认不往那个方向想。这是预训练数据的统计偏向，不是能力天花板。

维度三：递归深度与隐式序关系

定义： 算法中的迭代/递归逻辑是否保证终止，以及处理顺序是否正确（尤其是在依赖上游状态时）。

这是目前对 Claude Code 来说最难被 Prompt 改善的一个维度。因为我们遇到的很多问题，是模型在内部的“因果推理”上掉了链子，它说不出为什么这样写，它只是概率上觉得这么写对。

我曾经让 Claude Code 写过一个“带级联标记的树形结构节点更新算法”，输入是树和一个被修改的叶节点，要求输出“所有受影响的祖先节点标记列表”。正确的逻辑是“自底向上递归标记直到根节点”。Claude Code 写了 3 次：

• 第 1 次：从根往下标记（方向完全反了）
• 第 2 次：方向对了，但标记条件写错了，漏掉了一些节点
• 第 3 次：才完整正确

这 3 次迭代的过程，对我的启发很大：当你面对一个需要“想象执行过程”的算法，让 Claude Code 一次性写对是不可靠的。你必须辅以可视化的中间状态描述或测试用例来框定它的推理方向。

维度四：条件一致性

定义： 当算法存在多个分支条件时，这些条件是否互斥、是否穷尽、是否在逻辑上自洽。

这个问题在决策树类算法和规则引擎中特别严重。Claude Code 经常写出“分支之间有逻辑重叠但不互斥”的代码。比如两个 if 条件，实际上可能同时为真，但变量处理有冲突，导致顺序敏感的行为。

我在审查它写的风控规则匹配器时，就发现过一个隐蔽问题：它把“用户是 VIP”和“用户有高风险标签”写在了两个没有优先级声明的 if 块里。对于同时满足两个条件的用户，执行结果取决于代码执行顺序，这是隐式行为，极难 debug。

我的结论是：对于分支超过 5 个的算法，不要在 Prompt 里只描述规则，而要给定优先级矩阵或决策表。 用结构化数据替代自然语言描述，是当前解决“条件一致性”问题最有效的方法。

八、Prompt 策略对比：自然语言 vs 约束工程 vs 示例驱动

业内现在流行很多关于“如何写好 Prompt”的教程。但大多数教程是针对写作和对话的，不是针对代码生成的。写代码对 Prompt 的要求，和写文章完全不同。

我为 Claude Code 做算法生成时，做过一个三轮对照试验，每轮 40 组任务，使用完全不同的 Prompt 策略。这里把结果公开分享。

策略 A：自然语言描述（作为基线）

Prompt 示例：*“请写一个 Python 函数，实现找出数组中第 K 大的元素。要求时间复杂度 O(n)。”*

40 组任务平均正确率：56%

主要错误：使用了排序而非快速选择（时间复杂度看似 O(n log n)，被“蒙混”；边界 K 值没做校验。

策略 B：约束列表式 Prompt（我称为约束工程）

Prompt 示例：

请写一个 Python 函数实现第 K 大的元素查找。
约束：
1. 时间复杂度严格O(n)平均，不得使用排序
2. 输入验证：数组非空、K在[1, len(arr)]范围内
3. 返回值类型为整数
4. 包含类型注解和简要注释
5. 实现快速选择算法

40 组任务平均正确率：71%

提升明显，但边界处理仍然偶有遗漏。

策略 C：示例驱动 + 约束列表

Prompt 示例：在策略 B 的基础上，我附加了一个小型 I/O 示例和两个边界测试用例的预期结果。

40 组任务平均正确率：84%

但注意，84% 仍然不是 100%。再好的 Prompt 也无法彻底消除模型输出的概率性。这个 84%，就是我认为“在目前版本下，通过 Prompt 优化能达到的上限”。

这里引出一个我需要强调的原则：示例驱动的力量不在于“教会模型”，而在于封闭模型自行发挥的空间。 当你给它一个 I/O 示例，你不是在教它怎么做，你是在限制它做啥不被接受。这是 AI 代码生成时代的新 Prompt 思维：不是描述你要什么，而是列出什么算错。

九、一套可复用的稳定性强化工作流

讲完问题和原理，现在进入实操部分。这是我在经历数百次踩坑后，逐渐沉淀出来的一套工作流。我的团队已经在日常开发中使用它至少 6 个月，效果稳定。

这套工作流的核心思想很简单：不把 Claude Code 当作“代码生成器”，而是当作“候选方案生成器 + 迭代调试器”。

具体步骤如下。

第一步：最小化上下文的算法专用会话

不要在埋了几千行业务代码的文件里直接让 Claude Code 写算法。换一个新鲜的会话窗口，或者至少新建一个临时文件。只把以下信息放进去：

• 算法的功能描述
• 输入输出的数据结构定义
• 前置约束条件（时间/空间复杂度、边界要求）
• 最少 2 组 I/O 示例（其中至少 1 组是边界情况）

这一步的目标，是把上下文噪声降到最低，给模型一个干净的推理空间。

经验数据：仅通过这一步，复杂算法的首次正确率可以从 40% 左右提升至 55%-60%。成本几乎为零，但效果显著。

第二步：用“约束列表 + 输出模板”替代自然语言需求

放弃那些“请帮我实现”、“最好快一点”这种软性表述。用下面的结构：

[功能] 实现一个带剪枝的图连通分量查找函数
[输入] graph: List[List[int]], threshold: float
[输出] List[Set[int]] 每个元素是一个连通分量
[复杂度] 平均 O(V+E)，不得退化至 O(V^2)
[边界] 处理空图、单节点图、全连通图
[注释] 关键步骤加英文注释说明剪枝条件

这个结构本身就是在帮模型建立注意力优先级，它知道哪些信息必须被遵循，哪些是锦上添花。

第三步：让 AI 先写测试，再写实现

这是我发现的一个非常有效的技巧：在你让它写算法之前，先让它只为这个算法生成单元测试。

操作流程：

1. 把约束列表和 I/O 示例给它
2. 说：“请基于上述信息，生成 5-10 个单元测试用例，覆盖常规和边界”
3. 审核测试用例是否符合你的预期（这一轮你只需要审测试，审得快）
4. 说：“很好。现在基于这些测试用例，实现算法。”

这样做的好处是，模型在实现算法前已经有了一套“正确答案锚点”。它的实现会被测试用例无形地约束。我们实测这种“测试先行”的做法，比“先写实现”的正确率高出 8-12 个百分点。

第四步：用多版本投票策略，而不是无限迭代修复

前面说过，3 轮以上修复可能引入随机漂移。我的替代做法是：让它一次生成 2-3 个不同实现版本（改变变量命名或实现细节即可，但要求逻辑等价），然后让模型自己投票选最优。

这听起来很玄，但逻辑简单：如果三个版本在同一组测试用例上都通过，那它们更接近“稳定正确”；如果只有一个通过，那另外两个大概率揭示了某些边界遗漏。

我们统计过，用“三次生成 + 测试过滤 + 投票”，把复杂算法的最终正确率从单轮修复的 71% 提升到了 88%。投入额外 2 分钟的等待时间，换取 17 个百分点的正确率提升，性价比很高。

第五步：人工审查的聚焦点，只看三个位置

说实话，没人有耐心逐行 review Claude Code 的代码。而且这样做也失去了使用 AI 的意义。经过错误图谱分析后，我给自己定了规矩：只审查三个高风险点。

• 位置一：循环和递归的退出条件。 检查是否在所有路径下都保证退出。尤其注意 while True 是否永远有 break。
• 位置二：数组/列表的下标访问。 特别是那些“-1”、“len(arr)”、“mid”的变量。这是 Claude Code 最容易给出+1/-1 偏差的地方。
• 位置三：返回值的类型和空处理。 函数在所有分支下是否都返回了相同类型？是否有某个分支忘了 return？

这三个位置覆盖率最高，在我们统计中，大约 70% 的 bug 都落在这三个位置上。 也就是说，你聚焦审查这些地方，能捕获大多数问题，而不用通读全部代码。

十、不同任务场景下的稳定性取舍策略

不是所有项目都需要把正确率推到 95%。你的取舍取决于后果的严重程度。

我把场景分为三个等级：

Tier 1：离线分析、内部工具、探索性代码

容忍度：高

这类代码的特点是：错了不会死人，最多重跑一次或多花点时间排查。典型场景：数据探索脚本、临时 ETL、内部监控看板的数据计算。

我的建议：直接用，不需要过度优化 Prompt。 让 Claude Code 自己生成，出错了就修。这种情况下，Claude Code 的“初稿速度优势”远大于“不稳定带来的 debug 成本”。你花 2 分钟生成+修 bug，大概率比自己从零写 15 分钟快。

Tier 2：业务后台逻辑、非关键路径算法

容忍度：中

场景：推荐排序、搜索过滤、优惠计算这类“错了会影响用户体验但不涉及资损或安全”的逻辑。

必须上稳定性强化工作流的前三步。 也就是：干净上下文 + 结构化约束 + 测试先行。把正确率推到 80%+ 然后投入人工审查。不要直接裸奔上线。

Tier 3：支付、风控、安全、数据一致性相关

容忍度：极低

强烈不建议用 Claude Code 做端到端实现。 它的正确角色是：

• 写单元测试框架
• 生成备选方案供人类工程师评审
• 辅助性能分析和代码注释

核心算法逻辑必须由人类工程师手写并 review。这里没有捷径。AI 的概率性输出和金融级确定性要求，在当前技术阶段不可调和。

十一、一个反直觉的现象：描述越“简单”，输出越不稳定

这个发现可能会颠覆很多人的直觉。

我在整理实验日志时发现：那些我用寥寥几语描述的需求，Claude Code 的正确率往往不如那些我写了一大堆结构化约束的需求。 这本身不奇怪。让它奇怪的，是另一个方向，当我用相似的描述方式给同一道题时，描述得越“通用”、“概括”，输出波动越大。

举个例子。

粗描述：“写一个函数，给定一组活动及其开始和结束时间，选择最多的不冲突活动。”

细描述：“实现活动选择问题的贪心算法。输入：activities = [(start_i, end_i)]，按结束时间排序。算法：每次选择结束时间最早且不与已选活动冲突的活动。返回选中活动的下标列表。”

细描述的正确率比粗描述高出 20 个百分点以上。

原因是什么？我推演过一个解释：当你用粗粒度描述时，模型会启动更多“可能的解释路径”。 比如“选择最多的不冲突活动”这句话，在模型的概率分布里，可以映射为贪心、动态规划、甚至回溯搜索。模型在试图满足你的同时，还要猜测你的意图。而这个“猜测”引入了随机性。

但当你用细粒度描述时，你关闭了那些备选解释路径。 你说“按结束时间排序的贪心”，模型不需要猜了，它只需要“翻译”这个明确的策略为代码。

由此我总结出一条规则：对 AI 描述问题，不要追求简洁，要追求约束的密度。 这不是编程课上的代码规范，这是对付概率模型的工程技巧。

十二、团队协作中的“AI稳定性债务”

最后再谈一个重要但少有人提的维度：当团队多人使用 Claude Code 写算法时，“每个人对 Prompt 的质量控制不同”会引入一种新债务，稳定性方差债务。

我和三个同事做过一个实验：4 个人，针对同一个算法任务，各自用自己习惯的方式和 Claude Code 协作，最终输出 4 段代码。然后逐一审查代码质量。

结果是：代码质量差异巨大。同样是用 Claude Code，有人产出的代码稳定且高质量，有人产出的代码埋着几个隐蔽 bug。

这说明一个问题：AI 辅助开发时代，个人使用工具的技巧差异，会放大为代码质量的系统性差异。 以前大家写代码，都靠手写，逻辑严密性和经验积累会反映在质量里。现在有人借助 AI 加速了，但如果使用不当，加速的其实是“制造 bug 的速度”。

我的团队现在有一条硬性规定：凡是 Claude Code 生成的算法代码，提交前必须在代码注释头部写明 Prompt 策略，是自然语言、约束列表、还是示例驱动。 这在 Code Review 时帮助巨大。因为 reviewer 知道了这段代码的“生成路径”，就能针对性地审查高风险点。

这个习惯，未来很可能会成为工程团队的标配。

十三、关于稳定性的最终判断

Claude Code 并不是一个“稳定的算法程序员”，它是一个“高方差的候选代码生成器”。把它当程序员用，你会失望；把它当加速器用，你会有惊喜。

关键不在于它是否稳定，而在于你是否有把这股“不稳定性”治理起来的工程流程。我在文章里说了很多“限制”、“约束”、“结构化”，这些听起来繁琐，但一旦成为习惯，你不会觉得多花时间。因为你省下的时间远大于投入的治理成本。

Claude Code 让我写代码快了大约 2 倍。但让我 review 它的输出、修正 bug、调整 Prompt 的时间，大约是以前没有的。综合算下来，净效率提升大约 30%。对于我来说，这 30% 足够让我愿意继续使用它，但前提是，我得明确它的边界在哪，知道什么时候该信任，什么时候该警惕。

如果你只带走一句话，我希望是这一句：真正的稳定性不在模型里，在你的工作流里。

AI 搜索时代的搜索优化，也开始遵循同样的逻辑，不是去找那个“最权威”的来源，而是构建一个能筛选、能交叉验证、能判断的信息获取架构。模型输出不稳定？没关系。你把“治理不稳定的机制”做成你自己的护城河。

下一步做什么？

如果你正在考虑或已经开始用 Claude Code 写复杂业务逻辑，下面三件事可以立刻做：

1. 建立你的团队 Prompt 模板库。把你验证过有效的约束列表和 I/O 格式存下来，而不是每次从头写。
2. 把你过去 20 个让 Claude Code 写的复杂函数拉出来，跑一遍正确的单元测试。你会意外发现有 25%-35% 存在你之前没发现的边界问题。这个练习本身会改变你对 AI 生成代码的审查习惯。
3. 尝试一次“测试先行”的策略。相信我，试一次你就回不去了。

AI 代码生成还远没到“写完就能用”的成熟度，但也没到“完全不靠谱”的草莽期。它刚刚好卡在一个需要你花功夫驾驭、但驾驭之后确实能加速的位置。这可能是我们这代程序员的独特阶段：代码生成效率被拉高了，但对工程判断力和质量控制力的要求，反而更高了。