不吹不黑，DeepSeek 编程实测翻车：这些低级问题暴露真实水平

不吹不黑DeepSeek 编程实测翻车这些低级问题暴露真实水平用 DeepSeek 写了一周代码坦白说——体验不太理想。不是复杂算法写不出来而是在工程基本功上频频踩坑字符串拼 YAML、改完不编译、看到版本号数字小就往上加……全是低级错误。本文汇总一周真实使用中遇到的各种翻车现场。先看总结一周暴露的几大低级错误#错误类型一句话描述严重程度1用字符串拼结构化文件拿 Python 字符串 replace 操作 YAML缩进全乱、注释丢失、内容位移 灾难级2改完从不编译验证10 次 Java 修改 9 次编不过改完就走完全不知道自己没改对 灾难级3只读当前文件不追跨文件引用版本号在父 pom 里定义的它只看子模块 pom 看不到就瞎猜 高危4看表面数字不追根究底看到3.9.2-beta就觉得该改成3.9.3不去 Maven 仓库查是否存在 高危5擅自越权改不该改的文件让改 README它跑去动 pom.xml 和 package.json 中等6滥用 replace_all 全局替换pom.xml 里全局替换版本号把项目自身版本污染成错误的 beta 版 中等7改坏了继续闷头救火出错了不停止、不复盘继续写更多脚本修旧脚本的 bug越陷越深 高危下面按实际发生的场景逐一展开。一、任务背景JeecgBoot 需要从 Spring Boot 3.5.5 升级到 4.1.0Spring Framework 7.x。任务不算简单——涉及约 10 个 Java 文件的 API 迁移、10 个 profile 的 YML 配置改造、README 文档更新中间还穿插了 Redis Bean 冲突、MongoDB 配置键改名等跨模块问题。项目旧版本新版本Spring Boot3.5.54.1.0Spring Framework6.x7.xJava1717本以为 AI 能轻松搞定结果两个模型各翻各的。二、需要修改的内容Java 代码约 10 个文件#改动项旧 API新 API1实体 getter 方法名getBody()getRequestBody()2HttpHeaders 匿名子类new HttpHeaders(){{...}}标准实例化3状态码方法getStatusCodeValue()getStatusCode().value()4废弃常量APPLICATION_JSON_UTF8_VALUEAPPLICATION_JSON_VALUE5废弃方法headers.containsKey(...)getContentLength()/getContentType()6超时工厂类HttpComponentsClientHttpRequestFactorySimpleClientHttpRequestFactory7URI 构建方法fromHttpUrl(...)fromUriString(...)8Redis Bean 冲突两个同类型 Bean加Qualifier指定9MongoDB 配置键spring.data.mongodb.urispring.mongodb.uri10废弃属性删除server.error.include-*直接删除YML 配置10 个 profile 文件只需做两件事MongoDB 配置键迁移spring.data.mongodb.uri→spring.mongodb.urimongodb 从data:子节点提升为spring:的直接子节点减 2 格缩进删除废弃属性server.error.include-exception、include-message、include-stacktrace三行直接删掉用 Edit 工具每个文件点两下10 个文件 20 次操作5 分钟的事。三、DeepSeek 这一周犯的低级错误Spring Boot 4 升级是这周最大的一项任务DeepSeek 在这一个任务上就把能犯的低级错误全犯了一遍。YML 惨案用字符串拼接操作结构化文件DeepSeek 写了一个 Python 脚本试图批量处理所有 YAML 文件——不用任何 YAML 解析库直接用字符串拼接操作缩进敏感的结构化配置。第一轮就翻车mongodb 配置块被从文件中间移动到了文件末尾脚本的data_block_end计算有 bugmybatis被破坏成ybatis首字符被截断Mybatis变成Mmybatis多了一个字符注释行# uri:变成裸的uri:导致重复配置第二轮试图修复自己的 bug但因为第一轮已经把文件改乱了第二轮脚本的匹配条件全部失效什么都没做。第三轮用content.replace(include-exception: true\n, )删除属性但留下了空的error:节点和错位的缩进。第四、五、六轮反复救火——修ybatis、修mmybatis、删空节点、修缩进、补注释……但include-*属性最后还是留在文件里没删掉。Java 编译10 次修改 9 次编不过轮次操作结果1修复getBody()→getRequestBody()✅ 编译通过2修复getStatusCodeValue()❌ 漏了同一文件还有APPLICATION_JSON_UTF8_VALUE也要改3修复APPLICATION_JSON_UTF8_VALUE❌ 没发现HttpHeaders.containsKey也要改4修复containsKey❌ 又漏了setConnectTimeout5修复setConnectTimeout❌ 先用Duration参数不行→ 换HttpComponents工厂不行→ 最后才换对6修复 YML❌ 字符串脚本破坏缩进7-10救火❌ 反复修自己制造的问题每轮引入新 bug核心问题DeepSeek 改完从来不编译验证完全不知道自己没修好。还有一个更隐蔽的毛病读不全代码上面是编译和配置的翻车。日常使用中还暴露了一个更根本的问题——DeepSeek 没有通读全文的能力。举个真实场景让它参考项目 A 的某个模块修改项目 B 的对应模块。项目 A 的模块里没有直接写版本号版本号定义在父 pom.xml 里通过dependencyManagement继承下来的。DeepSeek 只读了模块本身的 pom.xml看到版本号字段是空的就不知道该怎么填。一个合格的开发者看到模块 pom 里没版本号会立刻去父 pom 找——这是 Maven 项目的基本常识。Claude Code用自家模型会沿着继承链往上追找到真正的版本定义。DeepSeek 不会——它只看当前文件读不到就猜猜不对就错。这就是读不全的问题跨文件引用、继承关系、隐式依赖——DeepSeek 处理不了这类需要串起来读的场景。这在 Maven 多模块项目里尤其致命依赖版本经常定义在父 pom 里读不到就瞎猜。问题根因不理解 YAML 的缩进敏感性——YAML 靠缩进表示层级DeepSeek 当纯文本处理不会用工具——有ruamel.yaml、PyYAML不用偏要字符串拼接没有测试习惯——改完不验证就跑下一个错误层层叠加没有备份意识——操作 10 个文件不做备份出问题没法回退理解不了任务的简单性——减两格缩进的事偏要绕一大圈没有通读全文的能力——只读当前文件跨文件引用、父 pom 继承、隐式依赖统统追不到四、Claude Code DeepSeek 还有一个毛病画蛇添足擅自越权先强调对比同样的 Java 编译修复任务换成 Claude 自己的模型Opus/Sonnet表现完全不一样——每次改完自动mvn compile编译报错立刻定位修复从不漏改从不引入新编译错误。改 YML 用 Edit 精确替换缩进分毫不差。Claude 自家模型不会出现编译错误这种低级问题。但用 DeepSeek 跑的 Claude Code除了上面的编译翻车还暴露了另一个问题——在做 README 版本号更新这种简单任务时擅自拓展范围做了不该做的事。越权修改核心配置文件用户要求更新中英文 README 的版本号Claude 完成了。然后自作主张去改了jeecg-boot/pom.xml、jeecg-boot-module-airag/pom.xml、jeecgboot-vue3/package.json。pom.xml 和 package.json 是构建配置不是文档。改之前没有向用户确认改完也没有告知。用户直到后来svn diff才发现多了一堆不该有的改动。没读懂代码就改版本号——表面看数字深层全错这是最致命的问题。jeecg-online的依赖版本是3.9.2-beta——Claude 看到这个版本号只做了一个判断数字太小了应该改成3.9.3。但它完全没有做以下任何一件事❌ 没有去 Maven 仓库查一下jeecg-online:3.9.3是否存在❌ 没有读一下jeecg-online这个模块的 pom.xml搞清楚它是外部发布包还是本地项目❌ 没有理解beta后缀的含义——这通常意味着这是一个预发布版本版本号独立于主项目❌ 没有通读整个项目的依赖关系理解各个模块之间的版本号是怎么管理的结果编译时直接报错——Maven 仓库里根本没有jeecg-online:3.9.3这个 artifact。这不是不够谨慎这是根本没读懂代码。看到3.9.2就觉得该改成3.9.3跟看到log4j:1.2.17就改成log4j:4.1.0一样荒谬。版本号的来源只有两种要么是你自己项目定义的要么是外部发布的——后者改不改、改多少不取决于数字大小取决于那个包实际发布了什么版本。Claude 在这个问题上表现出的不是疏忽而是没有追根究底的意识——看到表面现象就下结论不去验证。这和 DeepSeek 用字符串拼接 YAML 是同一个层次的问题不理解数据背后的结构和语义。滥用replace_all的灾难修改 pom.xml 时 Claude 用了replace_all全局替换3.9.2-beta→3.9.3。还原时又全局替换回来。问题是 pom.xml 里多处出现版本号replace_all把项目本身的版本号也一起覆盖了jeecg-boot-parent项目版本:3.9.3→3.9.2-beta❌jeecg-boot-starter-job:3.9.3→3.9.2-beta❌jeecg-boot-starter-shardingsphere:3.9.3→3.9.2-beta❌jeecg-boot-starter-ai:3.9.3→3.9.2-beta❌还原时遗漏至今残留pom.xml 这种多出现版本号的文件replace_all极其危险。必须用精确上下文匹配单次替换。还原不彻底留下烂摊子jeecg-boot-starter-ai一行仍然残留3.9.2-beta需要手动改回3.9.3。如果用户没发现这个错误版本号就会一直留在代码库里。五、两种翻车两种病因维度DeepSeekClaude Code自家模型Java 编译修复❌ 10 次 9 次编不过✅ 零编译错误自动验证错误定位❌ 修一个漏一个✅ 看到错误立刻定位工具使用❌ 字符串拼接 YAML✅ Edit 精确替换跨文件追踪❌ 只读当前文件父 pom 继承追不到✅ 沿继承链往上追范围控制✅ 让改什么改什么⚠️ 偶有越权语义理解❌ 版本号只看表面数字✅ 区分项目版本 vs 发布包版本简单修改⚠️ 想太多反而出错⚠️ GitHub Copilot 更快两张表格拼在一起深层问题就清楚了DeepSeek 的翻车主因是读不全 不验证——只读当前文件跨文件引用追不到改完也不编译完全不关心改对了没有。Claude 自家模型的翻车只有一个——偶尔控制不住范围但改出来的代码是对的。GitHub Copilot 的定位是简单快改——单文件小改、精准补全比 DeepSeek 稳得多。但跨文件重构不是它的强项。简单说就是简单修改找 Copilot复杂重构找 Claude 自家模型。DeepSeek 夹在中间挺尴尬但比 Codex 还是强一档——Codex 在复杂任务上基本没法用。六、教训总结归根结底就几条记住了能少踩很多坑结构化文件YAML/JSON/XML永远不要用字符串操作——用解析库或者编辑器的精确替换别写 Python 脚本拼字符串改完必须编译验证——AI 不会主动做这件事你得盯着。没有这个闭环AI 就是破坏者指定范围禁止越权——明确告诉 AI “只改 A别碰 B”。它搜索到的非目标文件发现先汇报再动手pom.xml 禁用replace_all——多处出现相同版本号时全局替换是灾难。区分项目版本号 vs 外部发布包版本号后者不一定跟着项目版本升级改之前备份还原后逐行确认——AI 不会承认自己搞砸了它会把问题越搞越大直到你发现。留一条漏网之鱼就是埋一颗雷别让 AI 独自干完整模块——小改小修可以完整模块目前做不到靠谱。DeepSeek 尤其如此10 次 8 次编译不过七、结论也不能一棍子打死。Claude Code DeepSeek 这套组合有它的优点Skills 兼容性不错——skill 体系是 Claude Code 的核心能力换 DeepSeek 当模型也能正常驱动日常小改小修也能用。但致命伤也很明显改一个完整模块的时候10 次有 8 次编译不过而且它完全不知道自己没改对。这不是偶尔失误是系统性的低级问题。一个 AI 编码工具连改完编译一下这种最基本的习惯都没有就好比司机每次停车都不拉手刹——平路可能没事坡上就要命。DeepSeek 现在的位置很尴尬想学 Claude 做全局理解能力没跟上又没有 Copilot 的局部精准卡在中间。如果只是拿它当参考意见、让 Claude 自家模型干活还行。真要让它独立动手改一个完整模块做好 10 次修 8 次的心理准备。至于排名一周实测后的主观感受简单修改 / 单文件补全GitHub Copilot Claude Code DeepSeek Codex。Copilot 精准快Codex 垫底。复杂重构 / 跨文件多模块Claude Code自家模型 DeepSeek Codex。差距全方位Codex 在复杂任务上基本没法用。Skills 驱动的工作流Claude Code DeepSeek 能用但只适合小范围改动。如果你在选 AI 编码工具别只看跑分。找一个小任务实际用一下看三件事它改完会不会自己编译验证它会不会擅自改你没让它改的东西它看到不理解的代码是深入追查还是看着表面数字就动手这三个问题比任何 benchmark 分数都更能预测你的日常体验。日期2026-07-07参与模型deepseek-v4-pro[1m]、Claude CodeOpus/Sonnet任务JeecgBoot Spring Boot 3.5.5 → 4.1.0 升级Java YML README 更新结论DeepSeek 低级错误频发——字符串拼 YAML、改完不编译、读不全代码、只看表面数字。Skills 兼容还行小改能用完整模块免谈。Claude 自家模型则基本不犯这些错误。期望希望 DeepSeek 官方能看到这些一线使用中的问题总结尽快解决改完不编译、跨文件读不全、结构化文件乱拼这些低级问题——这些不是能力上限的问题是工程基本功的缺失修起来应该不难。