首页 文章 精选 留言 我的

精选列表

搜索[水平可扩展],共10000篇文章
优秀的个人博客,低调大师

马斯克称愿意帮助苹果,用 Grok 提升 Siri 智能水平

近日,马斯克在社交平台 X 上表态,表示愿意用 xAI 的最新模型 Grok 4.1 来“修复”苹果的语音助手 Siri。 起因是一位网友吐槽 Siri 表现迟缓、响应平平,并建议苹果直接改用 Grok,马斯克则回应 “I’m down(我愿意)”。 目前苹果方面尚未做出任何公开回应,双方也没有披露是否存在合作讨论。 马斯克旗下 AI 公司 xAI 近日正式推出 Grok 4.1,称这是一款前沿模型,为对话智能、情感理解和现实世界的实用性树立了新标准。 据介绍,Grok4.1 在创造性、情感互动、协作能力上大幅提升,同时保留此前的 “敏锐智能与可靠性”。为了实现上述提升,xAI 在 Grok 4 的大规模强化学习基础上,进一步优化了 “风格、人格、帮助性、与对齐”(alignment)等方面。其中特别使用了新的方法:以 “先进的代理(agentic)推理模型” 为奖励模型,自主评估并大规模迭代响应。

优秀的个人博客,低调大师

不吹不黑,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.0(Spring Framework 7.x)。任务不算简单 —— 涉及约 10 个 Java 文件的 API 迁移、10 个 profile 的 YML 配置改造、README 文档更新,中间还穿插了 Redis Bean 冲突、MongoDB 配置键改名等跨模块问题。 项目 旧版本 新版本 Spring Boot 3.5.5 4.1.0 Spring Framework 6.x 7.x Java 17 17 本以为 AI 能轻松搞定,结果两个模型各翻各的。 二、需要修改的内容 Java 代码(约 10 个文件) # 改动项 旧 API 新 API 1 实体 getter 方法名 getBody() getRequestBody() 2 HttpHeaders 匿名子类 new HttpHeaders(){{...}} 标准实例化 3 状态码方法 getStatusCodeValue() getStatusCode().value() 4 废弃常量 APPLICATION_JSON_UTF8_VALUE APPLICATION_JSON_VALUE 5 废弃方法 headers.containsKey(...) getContentLength() / getContentType() 6 超时工厂类 HttpComponentsClientHttpRequestFactory SimpleClientHttpRequestFactory 7 URI 构建方法 fromHttpUrl(...) fromUriString(...) 8 Redis Bean 冲突 两个同类型 Bean 加 @Qualifier 指定 9 MongoDB 配置键 spring.data.mongodb.uri spring.mongodb.uri 10 废弃属性删除 server.error.include-* 直接删除 YML 配置(10 个 profile 文件) 只需做两件事: MongoDB 配置键迁移:spring.data.mongodb.uri → spring.mongodb.uri,mongodb 从 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 计算有 bug) mybatis 被破坏成 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 ❌ 又漏了 setConnectTimeout 5 修复 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。如果用户没发现,这个错误版本号就会一直留在代码库里。 五、两种翻车,两种病因 维度 DeepSeek Claude 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 Code(Opus/Sonnet) 任务:JeecgBoot Spring Boot 3.5.5 → 4.1.0 升级(Java + YML + README 更新) 结论:DeepSeek 低级错误频发 —— 字符串拼 YAML、改完不编译、读不全代码、只看表面数字。Skills 兼容还行,小改能用,完整模块免谈。Claude 自家模型则基本不犯这些错误。 期望:希望 DeepSeek 官方能看到这些一线使用中的问题总结,尽快解决改完不编译、跨文件读不全、结构化文件乱拼这些低级问题 —— 这些不是能力上限的问题,是工程基本功的缺失,修起来应该不难。

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册