2026年Claude 3.7与DeepSeek R1软件开发能力评测

大家好，我是讯享网，很高兴认识大家。

Claude 3.7与DeepSeek R1软件开发能力评测

引言

Anthropic推出最新的Claude 3.7 Sonnet 模型之后，引起了业界的广泛关注。官方报告显示该模型在编码能力上有了显著提升，各方面用户对此评价也很高。此外，近期我们刚经历过DeepSeek的爆火，其在慢思考和强推理方面的表现令人印象深刻。同时，马斯克旗下人工智能公司xAI推出的Grok-3也引发了很大反响。为此，我们很好奇这几个模型在代码生成和软件开发能力上表现如何，同时Claude 3.7 Sonnet在代码能力上是否真的有那么出众。

为了满足我们的好奇心，同时也帮助我们更好地理解大模型在软件开发能力上的长处和短板，我们针对包括Claude 3.7 Sonnet、DeepSeek-R1等在内的多个大模型进行了软件开发能力评测，其中既包括基础模型（如Claude 3.7 Sonnet、DeepSeek-v3、GPT-4o、Grok-3）又包括推理模型（如Claude 3.7 Sonnet (extended)、DeepSeek-R1、GPT-o3-mini、Grok-3(thinking)）。我们的评测考虑了以下几种不同的软件开发场景。

・片段级代码生成和理解：相对独立的程序片段生成和理解，规模较小但要求精确生成符合要求的代码以及产生精确的程序分析结果；

・仓库级代码生成和理解：针对具有一定规模的代码仓库开展代码生成和理解任务，需要在综合理解整个代码上下文的基础上生成代码或产生分析结果；

・仓库级代码问题定位：针对具有一定规模的代码仓库进行问题（issue）定位，需要在理解代码上下文的基础上确定问题描述与实现代码之间的相关性；

・新应用开发：从头开始一次性或者以迭代化的方式生成一个完整应用，除了基本的代码生成能力之外还涉及软件设计决策的考虑以及迭代化演进的能力。

一、片段级代码理解和生成

针对片段级代码生成，我们通过一道竞赛级算法编程题来评测大模型的深度推理和精准代码生成能力。针对片段级代码理解，我们要求大模型针对给定的一段代码进行数据流分析，评测其精确代码理解能力。

1.1、片段级代码精确生成

算法题目：给定三个字符串 S_1,S_2,S_3，要求判断是否存在一个字符映射方式 F，使得 F(S1)=F(S2)≠F(S3)。

原题链接：

https://codeforces.com/gym//problem/A

求解思路：理解题目给出的数学形式限制，之后可以使用无向图数联通块或并查集方式实现解法。

对于这道算法题，不同大模型的完成情况如下表所示。

模型思维链展示

我们专门针对 Claude 3.7 Sonnet (extended) 的结果进行了分析，发现其中这段分析是错的：

OK, I got it now. If S₁ and S₂ have the same structure, and S₃ only contains characters present in S₁ or S₂, and S₃ has the same length as S₁, then under any cipher that ensures F(S₁) = F(S₂), we would also have F(S₁) = F(S₃). We can‘t design a cipher such that F(S₁) ≠ F(S₃) in this case.

✓ DeepSeek和Grok成功秘诀：理解题目时主动简化问题+举例子验证（可以认为在实践测试驱动开发以及实例化需求的思想），从而快速抓住核心；

✗ Claude3.7失败原因：刚开始就生成了错误版本并被其限制了思路，结果卡在测试样例2并始终没发现根源问题。

1.2、片段级代码精确理解

给定一段代码，要求大模型开展活跃变量分析。

注：活跃变量分析（活跃性分析）是编译器中的关键数据流分析技术。其核心任务是判断程序中每个位置点的变量是否“存活”——即该变量存储的值是否会在后续代码中被读取使用，或者在下次被覆盖前仍可能被调用。这种分析需要精确追踪程序执行路径和变量使用关系，从而优化资源分配。

我们提供给大模型33行c++代码，要求其推测每行代码后的活跃变量并计算准确率（活跃变量预测正确的行数/总行数）。对于每个大模型，我们都使用同样的提示运行三次，实验结果如下：

结果显示， Claude 3.7 Sonnet的数据流分析能力最强。

我们专门针对 Claude 3.7 Sonnet的结果进行了分析。

1. 思考过程的内容并不一定代表了模型真正的“思考”过程，如下图思考过程输出中Line 7中所“思考”的结果和实际输出结果并不一致。

思维过程输出

实际输出结果

2. 基础模型中，Claude 3.7 Sonnet表现最好（甚至好于对应的extended模型)，其他模型则可能会对活跃变量的定义不够理解而造成准确率较低。

3. 推理模型中，Claude 3.7 Sonnet (extended) 三次运行中取得了最高准确率(0.9)，而Grok-3-thinking的平均准确率最高。这些模型展现出了较强的控制流/数据流理解能力，模型的思考过程中能够意识到活跃变量分析适合用逆向分析。但是对更加复杂的情况（例如包含复杂的循环或嵌套结构）则会发生一些遗漏的情况。同时，模型的能力也会有随机性。Claude 3.7 Sonnet (extended)也会犯一些很低级的错误，例如第3次运行中将宏定义“#define MAX ”中的MAX 识别为变量，造成大量分析错误。

二、仓库级代码理解和生成

针对仓库级代码理解任务，我们选择了GitHub上开源的一个微服务商城系统mall-swarm（11k+star），其技术栈包括Spring Cloud Alibaba、Spring Boot 3.2、JDK17和Kubernetes。受限于大模型上下文长度的限制，我们只选取了其中mall-admin这个服务（包括100个左右的类以及近1万行代码）进行分析。

2.1、仓库级代码理解

我们导入仓库上下文，进行常规提问。

Prompt:

分析整个项目，使用PlantUML给我绘制整个项目的UML类图

Claude 3.7 Sonnet:

Claude 3.7 Sonnet（extended）：

Grok-3（thinking）：

注：DeepSeek上下文超出长度限制，没有进行测试。

从我们的评测结果看，三个模型结果的准确度大致在60%左右，召回率大致在30%左右，没有太大区别。但是Grok-3初次回答召回率只有10%左右，因为在它的回答里提到了只找了关键类，我们追问几次让它生成全部的类，但是它会找各种理由说难以生成。Claude 3.7 Sonnet（extended）也并没有特别突出的表现：一开始找到的类只有50个左右，如果持续追问那么可以陆续生成更多的类（需要分多次输出），最终召回率达到80%左右，没有找到的类可能都是一些大模型认为相对不关键的类。

2.2、仓库级代码生成

为了评价仓库级代码生成能力，我们在mall-admin服务中选取了一个操作数据表的方法，只保留方法头并添加了部分注释后，要求大模型补全该方法。

这是该方法原本的样子。

删除方法体并增加注释：

从人类开发者的角度看，完成该任务需要考虑的上下文信息如下。

・上下文中相关的方法：此例中需要考虑setId、setProductId、insertList方法，功能分别是设置表项id、设置关系id和批量插入dao。

・来自调用方的语义约束：分析上下文中对该方法的每个调用可以看出，参数dao代表的是某个和产品有关的关系表，datalist表示一些要与该产品建立联系的数据（可能是满减价格、会员价格或者库存等），而参数productId表示产品的 id。同时，调用者不保证datalist不为空，因此在方法中要对此进行异常处理。

由于窗口限制，给大模型提供的上下文信息仅包含一些必要的相关代码文件。在此基础上，Claude 3.7 Sonnet 的生成结果如下。

对于DeepSeek-R1，我们将实现这个方法所需要的相关上下文拼接成一个176k的文本文件作为输入，最终的生成结果如下。

可以看出，两个模型都能够较好地还原原本的方法实现代码，仅在细节风格上有所不同。正确补全所需要的setId、setProductId、insertList等方法，模型也都能正确地从上下文中找到。

我们后续进一步提升了难度，要求模型一次性生成相关联的多个方法或者一个类（需要靠实例化后被使用的逻辑来判断类包含的属性），结果都还不错。总体上看，该任务限制在单个微服务内部，而且所实现的逻辑较为简单，因此大模型可以较好的完成。我们猜测对于一些涉及更复杂的项目上下文及业务逻辑的问题，例如包括满减、满赠、阶梯折扣、会员等级、积分等多种规则和复杂依赖的优惠计算逻辑，现在的大模型在完成上可能有一定难度。

三、仓库级代码问题定位

为了评测大模型的问题定位能力，我们在mall-swarm项目中选择了一个与网关白名单相关的issue（https://github.com/macrozheng/mall-swarm/issues/45）。我们在网页版 Claude 3.7 Sonnet上提供相关的代码文件后，要求模型定位并解决该问题。

Claude 3.7 Sonnet的回答如下。很遗憾，结果中仅仅是提供了多个可以帮助进一步调试的选择，而没有直接指出根本原因。

对此问题，Claude 3.7 Sonnet (extended) 的回答如下。可以看出模型成功通过调用链定位了有问题的application.yml文件，并提供了正确的解决方案，即将“/mall-protal/sso/*”从白名单中去除，并改成具体的无需授权的端点。在此过程中，模型先定位到出问题的API入口，再针对后续执行的代码以及调用的方法进行分析，最后联系到另一个相关文件filter以确认问题所在。由此看出模型确实具有一定的仓库级问题定位和修复能力。

此外，我们也尝试利用DeepSeek-R1解决这个 issue，但是由于DeepSeek-R1支持上传文件的大小更小，因此没有实现。此外，由于项目整体规模和逻辑复杂度有限，我们没有找到更复杂的例子来进一步验证Claude 3.7 Sonnet推理模型的能力上限。

四、新应用开发

为了评测大模型的新应用开发能力，我们尝试在给定需求的情况下要求大模型通过多次迭代完成完整应用的生成式开发，我们会验证应用的功能是否都正确实现了。在此过程中，大模型需要展现一定的模糊需求理解和分析能力以及迭代化的应用实现和完善能力。

这部分评测我们采取了以下两种模式。

・一次性生成+迭代完善：将完整需求一次性提供给大模型，希望生成接近完整的应用实现，在此基础上不断发现问题并提出完善意见并希望大模型能迭代完善。

・逐步细化的演进式开发：在明确同样的最终需求的前提下以一种逐步细化的方式推动大模型演进式地生成完整应用，最初给出较模糊的初始需求然后逐渐明确和完善各方面要求。

4.1、一次性生成+迭代修复

我们为Claude3.7 Sonnet准备了如下这样的详细需求说明，并要求它生成代码。

请你根据以下需求文档，为我编写一个可以直接运行的完整的网页小游戏：
射箭小游戏需求文档
1. 游戏概述
本游戏是一款简单的单机射箭小游戏，玩家控制一个自动前进的角色，角色会自动射箭。游戏的目标是通过射箭消灭路上的怪物，同时通过升级门提升自己的能力，最终获得尽可能高的分数。
2. 游戏规则

界面视图：适合手机界面，并且y轴方向为前进方向，且镜头随玩家移动而移动。
* 角色移动：角色自动向前移动，玩家无法控制角色的速度，但是可以左右移动方向。
* 自动射箭：角色会自动向前方射箭，箭的发射频率固定。
* 升级门：路上会随机在某一位置并排出现三扇不同颜色的门，每扇门占据1/3宽度，代表不同的升级策略，门的种类和顺序都是随机的。玩家通过左右移动选择触碰门来选择升级。
* 红色门：增加箭的伤害。
* 蓝色门：增加射箭频率。
* 绿色门：增加角色的移动速度。
* 黄色门：角色水平方向多发射一只箭。

* 怪物：路上会随机出现静止的怪物，怪物不会移动或攻击，但有血量，不同怪物的血量不同，最低为5。角色碰到怪物会死亡，游戏结束。
* 玩家需要用箭消灭怪物，箭击中怪物会减少怪物的血量，血量降为0时怪物消失。
* 得分：
* 移动得分：角色每移动一定距离会增加分数。
* 击杀得分：每消灭一个怪物会增加分数。
3. 游戏流程
1. 游戏开始：角色从起点出发，自动向前移动并射箭。
2. 遇到升级门：角色触碰升级门后，玩家选择一种升级策略。
3. 遇到怪物：角色射箭消灭怪物，若角色碰到怪物则游戏结束。
4. 游戏结束：当角色碰到怪物时，游戏结束，显示最终得分。
4. 游戏界面
* 主游戏界面：
* 角色、箭、怪物、升级门等元素显示在屏幕上。
* 显示当前得分、角色血量（如果有）、怪物血量、箭的伤害、射箭频率等信息。
* 游戏结束界面：
* 显示最终得分。
* 提供“重新开始”按钮，点击后重新开始游戏。
5. 数据记录
* 一局内数据记录：
* 当前得分。
* 当前箭的伤害。
* 当前射箭频率。
* 当前移动速度。
* 游戏结束时：
* 记录本局最终得分。
* 不保存跨局数据（如历史最高分等）。
6. 游戏操作
* 键盘操作：玩家通过键盘按键进行左右移动。
7. 游戏难度
* 怪物血量：随着游戏进行，怪物的血量逐渐增加。
* 怪物密度：随着游戏进行，路上怪物的密度逐渐增加。

和网上展示的效果一样，Claude3.7 Sonnet一次性就生成了可运行的游戏并且几乎满足了所有需求。但细看还是发现有一些潜在需求没有实现，例如怪物血量太多、角色攻击力差、游戏可玩性低。于是，我们进一步给出如下提示以要求Claude3.7 Sonnet改进结果。

现在这个游戏精英怪根本无法击败获取奖励，其他怪的击杀难度也太高了，游戏性很差，如果你有觉得不明确的需求可以主动跟我说。
然后生成的游戏实况如下：

通过演示视频可以看到，到此为止游戏已经实现的不错了，但是依旧存在一些问题，例如：

・我希望生成一个射击游戏，但是最后由于数值不合理，怪物血量太厚，并且怪物等级增速高于角色，导致无法玩；

・存在一些简单常识错误，例如并发的子弹增加后子弹会向后射击，角色在向前移动但是背景画面是左右移动（如下图）。

为此，我们补充了如下指令，其中明确指出如果有不明确的需求可以寻求我们的解释，但是它没有执行这个指令。同时，我们还指出，游戏难度曲线不平衡导致游戏后期角色无敌后没有可玩性，同时也不会结束游戏（因为原始需求里没有说明）。

现在有几个我觉得不合理的地方希望你再优化一下，首先增加的子弹会向后射击，这个没有必要；由于角色只能左右移动，所以增加角色的移动速度时应该只有左右移动的速度，如果是前后移动，那么就变成怪物速度变快了，游戏反而更难了；最后就是游戏曲线还是不平衡，进行到最后角色无敌之后，游戏无法结束而且没有可玩性。此外，任何你觉得不合理的需求或者不明确的需求都要跟我提。下次迭代我明确给你。

经过本次迭代后子弹向后射击和加速问题依旧没有解决。更严重的是，大模型理解错了之前提示中提到的“游戏无法结束”这个问题：现在角色移动1000m就会游戏结束，结果导致角色还没有经过几次升级游戏就结束了。

此后又继续尝试了几轮，试图让大模型修复这些问题，但结果是不仅现有问题没有得到很好的解决，而且一些之前正确实现的功能也出现了问题。最后的结果是，游戏无法开始，背景展示全是代码（如下图）。于是，我们也失去了耐心，本次尝试以失败告终。

本阶段评测后，我们的感觉是Claude3.7 Sonnet一次性应用生成能力不错，但是在此基础上的精细化需求完善和问题修复上表现不够好。同时，虽然Claude3.7 Sonnet编码能力不错，但对潜在需求的挖掘和理解不够，似乎只停留在对需求的表面理解上。

其他模型方面，DeepSeek-R1通过几次迭代可以实现完整需求，但是界面稍微简陋一点（如下图）。Claude3.7 Sonnet (extended)效果和Claude3.7 Sonnet 差不多，这里就不再展示了。GPT-4o由于不是推理模型，效果比较差，这里也不作展示了。

4.2、逐步细化的演进式开发

4.2.1 Claude Sonnet 3.7

我们从一个模糊的初始需求开始然后逐渐迭代完善。

第1轮需求

请你为我编写一个小游戏,下面是游戏概述本游戏是一款简单的单机射箭小游戏，玩家控制一个自动前进的角色，角色会自动射箭。游戏的目标是通过射箭消灭路上的怪物，同时通过升级门提升自己的能力，最终获得尽可能高的分数。

生成了一次性可玩的游戏，但还和我们头脑里“理想”的模样（模式1里的需求）相差甚远。

第2轮需求

目前所有需求均已满足，于是我们开始迭代新需求：

1.界面视图适合手机界面，并且y轴方向为前进方向，且镜头随玩家移动而移动。
2.角色自动向前移动，玩家无法控制角色的速度，但是可以左右移动方向。
3.角色会自动向前方射箭，箭的发射频率固定。
4.升级门：路上会随机在某一位置并排出现三扇不同颜色的门，每扇门占据1/3宽度，代表不同的升级策略，门的种类和顺序都是随机的。玩家通过左右移动选择触碰门来选择升级。 * 红色门：增加箭的伤害。 * 蓝色门：增加射箭频率。 * 绿色门：增加角色的水平方向的移动速度。 * 黄色门：角色水平方向多发射一只箭，箭不会向后射击。 * 黑色的门，会扣减一个升级的技能。

在给Claude Sonnet 3.7提出以上4点新需求之后，模型并没有完全按照我们的要求进行改进。经过几轮迭代后，游戏已经无法点击运行。人工检查代码后发现模型在更新代码的过程中把下面的关键代码删掉了（这个问题在模式1评测的时候也碰到多次）。

// 当页面加载完成后初始化游戏
window.addEventListener(’load‘, () => {
const game = new ArcheryGame();
});

我们提示模型补充上之后，游戏可以成功运行。如果不明确提示，估计模型无法自我迭代解决问题。

第三轮需求

1.由于角色是可以左右移动方向的，所以画面的怪物应该是由上至下的方向。
2.升级的每扇门占据1/3宽度，一次出现3个随机的门，角色可以左右选择。
3.修复bug，在点击重新开始后，游戏确实重新开始了，但是点击的界面和图标没有消失。

怪物是从下往上移动的，角色也处于画面居中的位置，而且还有进入门升级的瞬间画面整体消失的 bug。

继续进行迭代。

还是有几个点需要优化：
1.现在怪物是从底部出现，往顶部移动，我希望反过来
2.角色应该往顶部射击
3.角色与升级门的碰撞后所有元素会消失，只剩下蓝色背景。

之后经过多次迭代依旧没有完全解决。现在的问题包括：

・箭的方向从正常位置出现，但角色没有；

・原本碰到怪物会游戏结束，现在也不会了

・碰到升级门后游戏界面会消失的bug确实修复了，但是碰到之后没有任何反应（这个功能本来已经正确实现了）。

至此，本轮评测实验结束，总计进行了15轮迭代，完成了3轮新需求。我们选取了两个代表性的问题分析为什么迭代总是有问题以及难以修复的可能原因。

1.在修复射箭方向不对问题时产生游戏蓝屏 bug：人工验证只需要修改箭的发射方向就行，但大模型修改了多余的代码。

// 关键代码是updateArrows函数里的下面这行，-=修改成+=即可
arrow.y -= arrow.speed * deltaTime / 16;

// 模型也确实修改了这行，但是还改动了speedY。
arrow.y += arrow.speedY * deltaTime / 16;

// … 此外在别的函数里还有大量虽然和发射相关但是不必要的逻辑被修改了。

2.怪物移动方向不对的问题：代码里给角色赋予初始速度，并且这个值大于怪物的移动速度，由此导致怪物虽然移动方向正确但是角色相对速度更快，看起来就成了反方向移动了。

const y = this.player.y - this.canvas.height * 0.8; // 在屏幕上方生成
// 把代码从上面这行生成为下面这行，还是有问题。应该是+号不是-号。
const y = this.player.y - this.canvas.height - size; // 怪物出现位置的修改

monster.y -= monster.speedY * deltaTime / 16; // 怪物移动方向的修改

// 此外还需要一处修改
speedY: 0, // 自动向上移动的速度，这个是角色属性。之前可能存在怪物移动方向修改正确，但是由于速度慢于角色速度，导致怪物看起来移动方向还是错误的。

后续尝试了Claude3.7 Sonnet (extended)，效果也差不多，很难迭代出我们想要的游戏。

4.2.2 DeepSeek-R1

第1轮需求

按照在Claude Sonnet 3.7上进行的实验同样的流程，我们首先给模型提供了如下初始需求。

请你为我编写一个html小游戏,下面是游戏概述本游戏是一款简单的单机射箭小游戏，玩家控制一个自动前进的角色，角色会自动射箭。游戏的目标是通过射箭消灭路上的怪物，同时通过升级门提升自己的能力，最终获得尽可能高的分数。

根据原始需求，DeepSeek-R1生成了如下应用：

根据该需求，DeepSeek-R1生成了如下应用。尽管离我们的目标应用相去甚远，但是它确实完成了原始需求中的全部内容（自动前进、自动射箭、升级门等）。

第2轮需求

我们继续增加关于游戏界面和角色移动逻辑的需求。

很好，现在添加这些需求：
（1）游戏界面应该全屏显示（现在只显示在了左上角）
（2）游戏界面应适合手机界面，并且y轴方向为前进方向，且镜头随玩家移动而移动。
（3）角色移动：角色自动向前移动，玩家无法控制角色的速度，但是可以左右移动方向。

DeepSeek-R1很快实现了所有的新增功能。但此时也开始出现一些问题，包括：角色应该位于页面最底端；子弹应该从角色位置射出，现在的射出位置会逐渐往上移动；用户应该能控制角色左右移动。

反馈以上问题后，DeepSeek-R1生成了新一轮的应用代码，不料此时页面突然开始一片空白。我们要求模型先进行自查：

页面突然一片空白了。只显示了左上角的分数、攻击和攻速值。请修复

DeepSeek-R1顺利修改了代码，游戏画面重新显示，并且所有要求的功能都已经得到实现。

第3轮需求

接下来我们增加了升级门的功能需求：

添加新需求：
现在修改升级门。升级门应该呈现以下形式：
路上会随机在某一位置并排出现三扇不同颜色的门，每扇门占据1/3宽度，代表不同的升级策略，门的种类和顺序都是随机的。玩家通过左右移动选择触碰门来选择升级。
* 红色门：增加箭的伤害。
* 蓝色门：增加射箭频率。
* 绿色门：增加角色的移动速度。
* 黄色门：角色水平方向多发射一只箭。

在随后生成的应用中，升级门是从页面底端出现并向下移动的，这显然不符合常理。

我们反馈了这一问题。

问题：升级门当前是从页面最底端出现的，应该从上往下移动，然后被用户接触后获得对应升级。

在接下来的迭代中，DeepSeek-R1提供的代码一直无法运行，页面始终一片空白，尽管我们要求它自查并修复，但三轮过后依然无法修复。手动检查后发现，在console中有一条代码报错，显示它生成的代码中，有一个“变量先使用再定义”的问题，但模型一直没有检查出这一问题，反而在思考一些高层逻辑是否有误。

反馈了这一报错信息后，模型才终于修复了这一问题。这反映了即使是DeepSeek-R1这样的深度推理模型，也依然不能只靠阅读代码发现问题（哪怕是一个如此基础的问题），需要结合代码执行信息等来发现和解决问题。

console报错信息：Uncaught ReferenceError: Cannot access ’player‘ before initialization at resizeCanvas (arow_man_iteractive_DeepSeek_R1.html:46:13) at arow_man_iteractive_DeepSeek_R1.html:50:9

在此后的迭代过程中，我们又花了3轮迭代修复了升级门的其他bug，包括升级门没有显示、黄色门的效果从增加一支箭变成了双发箭、绿色门效果是增加移动速度但当前移动受鼠标控制时无法反映出移速的增加等。

这之后我们开始修复一个新的问题，即多发箭矢时左侧的箭矢总是落后于其他箭矢。这个细节问题对模型来说难度颇高，模型用了4轮才修复完成。值得注意的是，为了验证自己修改的方法是否有效，DeepSeek-R1输出了一个debug版本，在用户确认这个版本中的箭矢是一直齐平的之后，又合并到了原代码中。

第4轮需求

在第4轮需求，我们增加了关于敌人和得分的需求点。

添加关于敌人和得分的新需求：
* 怪物：路上会随机出现静止的怪物，怪物不会移动或攻击，但有血量，不同怪物的血量不同，最低为5。角色碰到怪物会死亡，游戏结束。
* 玩家需要用箭消灭怪物，箭击中怪物会减少怪物的血量，血量降为0时怪物消失。
* 得分：
* 移动得分：角色每移动一定距离会增加分数。
* 击杀得分：每消灭一个怪物会增加分数。

在实现过程中，DeepSeek-R1再次出现了简单代码错误（一个方法没有定义），必须依靠工具反馈才能修复以及输出debug版本供用户进行检查的情况。同时，随着对话轮次的增加，无论我们如何要求模型输出全部代码，模型都只会输出修改的代码，需要人工进行合并。这也导致我们感觉交互体验上的急转直下。

在25轮迭代后，DeepSeek-R1还是没有完成目标应用的开发。总的来看，DeepSeek-R1展示出了出色的迭代开发能力，例如大部分需求都能一次性代码实现、懂得孤立问题开发一个DEBUG版本进行检查等。通过多次迭代，最终DeepSeek-R1顺利完成了完整应用的生成，但也暴露了很多问题，例如多次出现修改代码导致系统无法运行、没有工具反馈就无法发现简单代码错误（如变量先定义后使用、方法没有定义），以及多轮交互始终无法修复问题。整体来看，很多时候DeepSeek-R1依然需要人类和工具的介入和辅助才能顺利进行迭代开发。

五、整体评价

根据以上评测，我们对这几个大模型的软件开发能力评价如下。

在片段级代码生成任务中，我们发现，同样都是推理模型，Claude3.7 Sonnet（extended）的“思维模式”和DeepSeek-R1、Grok-3有很大的不同：

・Claude3.7 Sonnet（extended）在遇到这样一个比较复杂的问题时会倾向于先通过发散思维来生成一个初始版本的解法和代码，再通过多次的 “wait” 和利用样例、题目细节来验证；

・DeepSeek-R1、Grok-3 则先进行一定程度的问题简化和举例思考。

按照类人比喻的话，Claude像是熟练编码（记住了很多典型的代码实现模式和界面风格）但对问题思考不足的工程师，而DeepSeek和Grok则更倾向于先对问题进行仔细推敲（例如进行问题拆解并构建实例化理解）然后再开始编码。

在片段级代码理解任务中，Claude3.7 Sonnet的整体表现还比较亮眼，展现出较强的控制流和数据流理解能力，在思考过程中也使用了逆向分析的方式更好地进行活跃变量分析。美中不足的是，模型能力并不稳定，偶尔也会犯一些“低级错误”。

在仓库级代码理解任务中，由于项目本身具有较为清晰的MVC架构，Claude 3.7 Sonnet生成出的UML类图较为准确，同时相比Grok-3等模型更加完整，但是最终的类图同样会遗漏一部分的类和关系。在仓库级代码生成任务中，Claude 3.7 Sonnet能够根据方法提示信息生成完整的方法实现，当然这个任务的难度并不高。

在仓库级代码问题定位任务里，Claude 3.7 Sonnet (extended) 能够根据较为模糊的issue描述，从对应的代码入手并结合上下文分析，最后准确找到引发bug的代码段并给出修复方法。在这类问题涉及的调用链相对简单的场景下，Claude 3.7 Sonnet具有较好的问题定位和修复能力。

在新应用生成任务中，我们发现Claude 3.7 Sonnet的一次性代码生成能力不错，但在后续的功能完善和问题修复过程表现不够好。看起来虽然它有着不错的编码能力，但对潜在需求的挖掘和分析不够，经常停留在对需求的表面理解上。我们的具体感受包括：

・大模型设计能力很弱，同时很容易犯常识性错误；

・大模型每次都是完整的再生成一次代码，在迭代功能时可能把一些没问题的代码改成有问题的从而导致迭代无法收敛；

・Claude经常会自作主张实现一些我们没有提及的内容（如画面背景和特效），虽然可能会给我们带来意外之喜但也经常带来“惊吓”（如意外引入bug）。

六、总结与展望

经过本次评测，我们感觉Claude的代码生成能力确实有提升，但在复杂软件问题的分析和设计上仍然薄弱。

在一次性代码生成能力上，当前Claude表现确实出色，这也使得大家对其评价很高。但要注意，真实的软件开发与随意的尝试不一样，当你有着明确且细致的需求并且不断补充和调整需求时，Claude可能会在迭代中迷失方向，让我们从最初的惊喜逐渐堕入无休止的迭代完善中直至崩溃（程序崩溃了，我们也崩溃了）。此外，与DeepSeek等其他推理模型相比，Claude似乎更倾向于直接用“代码化”的思维考虑问题，就像一个接到任务就迫不及待地写好代码再逐步调整的程序员。我们猜测，这可能是因为Claude在代码上进行了强化训练，但这也导致它在问题本身的分析、理解与推敲方面做得不好。

总的来看，包括Claude 3.7 Sonnet在内的最近这些新的大模型在代码能力上又有了一些进步，但我们感觉它们仍然没有突破大模型在软件开发上的本质性不足，即在需求分析和软件设计上的“概念级”构思能力以及对于大规模复杂软件的整体理解能力。因此，我们团队将在大模型以及Agent等AI技术的基础上，继续深入探索软件工程的核心问题，力争构建能够更好服务于复杂企业软件开发的智能化工具。