AI TrendTrackers

AI 正在以一种非常奇怪的方式改变科学，而且这种变化既不是很多人想象中的“机器科学家取代人类”，也不是另一派人口中的“高级自动补全终于开始污染学术界”那么简单。真正发生变化的东西，其实是科学发现内部的一种结构，而且这个结构已经存在了几十年，只不过过去它运行得非常慢、非常昂贵、非常局部化，而今天，大语言模型突然让其中一个环节的成本急剧下降，于是整个系统的行为方式开始出现质变。 Donald Knuth，88 岁，《计算机程序设计艺术》的作者，算法分析领域的奠基人，出了名的 AI 怀疑论者，一个几乎代表“传统计算机科学黄金时代”的人物，居然认真阅读了一份 Claude Code 的对话日志，而且不是随便扫两眼，而是逐行检查，因为里面真的出现了让他感到意外的东西。数学家 Filip Stappers 用 Claude Opus 4.6 做了三十一轮组合数学探索，其中第十五轮里出现了一个此前没人明确写下来的结构模式。Knuth 不但认可这个模式，还亲自完成了证明，最后写成论文，并把它命名为 “Claude’s Cycles”。 很多人在这里会立刻滑向两个极端。 第一种叙事非常熟悉：AI 已经成为科学家，人类只是提示词操作员。模型提出了洞见，人类负责阅读结果，科学发现已经自动化。另一种叙事则完全反过来：语言模型根本不理解数学，它只是概率生成器，真正做科学的是研究者，模型只是一个会拼接 token 的随机鹦鹉。 这两种说法听起来都很完整，但问题在于，它们都在试图回答一个错误的问题：“AI 到底有没有在做科学？”真正值得观察的对象其实不是 AI，也不是人，而是两者之间形成的那个循环。 这个循环的结构非常稳定：人类提出问题，模型生成候选答案，某种验证机制过滤这些答案，然后人类决定哪些结果值得继续推进。这个结构在 Knuth 与 Claude 的案例里存在，在陶哲轩与 Lean 的协作里存在，在 AlphaFold 的蛋白质结构预测里存在，在 DeepMind 的 GNoME 材料发现系统里也同样存在。真正完成“发现”的，从来都不是某个单独主体，而是整个 loop。 这件事非常关键，因为它决定了我们应该如何理解 AI 对科学的影响。很多人习惯性地把科学发现想象成一种高度人格化的行为：某个天才突然洞察宇宙真理。但现代科学早就不是这种模式了。真正的大规模科学活动，本质上是一个由提问、生成、筛选、验证、迭代构成的复杂系统，而 AI 恰好在其中最适合“高吞吐量试错”的那个环节上表现出了惊人的效率。 Claude 的案例其实已经很典型。Stappers 做的不是一次“灵感对话”，而是三十一轮系统性探索。模型不断提出候选结构，人类不断筛选和判断，最终 Knuth 对其中幸存下来的结果完成严格证明。这里最重要的角色不是“科学家”或者“AI”，而是 proposer 和 verifier…

2026 年的 Android，正在迎来一次前所未有的 AI 大改造。 距离 Google I/O 开幕只剩下一周时间，但 Google 显然已经等不及了。由于今年关于 AI 的内容实在太多，这家公司决定提前“剧透”Android 的未来方向。而从目前公开的信息来看，未来 Android 的核心关键词几乎只有一个：AI。 Google 正在把 Gemini Intelligence 深度植入 Android 系统，让手机从“工具”逐渐转向“主动协助者”。它不只是帮你回答问题，而是准备真正接管部分操作流程、理解上下文、跨 App 执行任务，甚至提前预测你的需求。 最明显的变化之一，是 Android 即将全面强化 App 自动化能力。 事实上，Google 早在 2026 年初就已经开始测试相关功能，当时主要针对 DoorDash、Uber 等应用，并优先开放给 Pixel 与 Samsung Galaxy 用户。不过初版体验并不好，执行缓慢、识别错误频繁，也缺乏真正的实用性。但 Google 表示，在过去几个月里，他们一直在重新训练系统，并优化跨应用操作逻辑。 而现在，Android 想做的已经不只是简单点餐或打车。 举例来说，未来 Gemini 可以自动从 Gmail 中找到你的课程大纲，然后跳转到购物 App，把所需教材自动加入购物车。又或者你拍下一张旅行宣传册照片，Gemini 能够理解目的地、预算与旅行风格，再直接在 Expedia 之类的 App…

如果你看到这样一句话： “AI Agent 才是软件开发的未来。开发者已经不再必要，他们只会拖慢企业前进的速度。” 你会有什么反应？ 我给出的答案可能有些反直觉。如果你是一位真正资深的软件开发者，而且你完全认同这句话，那么我反而会开始怀疑你的专业能力；但如果你并不是长期负责复杂系统的人，却觉得这句话非常合理，那么我认为，你大概率是正确的。乍一看，这种说法似乎自相矛盾，但它其实揭示了当前 AI 讨论里一个非常核心的问题：同一句话，在不同的人耳中，往往代表着完全不同的含义。 我本身是一名文案写作者，因此我习惯从“受众”角度理解问题。在我看来，现在关于 AI 的很多争论，并不是谁更懂技术，而是不同人实际上在面对不同的问题。对于许多资深开发者来说，他们已经亲自体验过各种 AI Agent、代码生成模型和自动化工作流，也确实感受到了这些工具惊人的效率，但与此同时，他们又隐约感觉到哪里“不太对劲”。问题在于，大多数人并不能准确地把这种直觉表达出来，于是这篇文章的目的，就是尝试替这些开发者把那种难以描述的不安翻译成人类语言。 很多人会感到疑惑：既然如此，为什么又有不少知名工程师、技术意见领袖，甚至经验丰富的开发者，也在不断宣称“程序员将死”？ 我认为，原因其实并不复杂，因为不同的人所面对的“工作循环”本身就不同，而这会彻底改变他们理解 AI 的方式。 为了说明这一点，我先讨论什么才是真正的资深开发者。很多人以为，资深开发者最重要的能力是写出复杂架构、设计高级系统、掌握大量技术细节，但我认为，真正成熟的资深开发者往往最擅长的事情，恰恰是“避免开发”。 我把自己在团队里见到的资深开发者分成了两类。 第一类人总是在讨论新的工具、新的框架、新的最佳实践，他们会不断提到某家公司采用了什么架构、某篇 HackerNews 文章推荐了什么技术方案，或者最近又出现了什么令人兴奋的新东西。这类人通常经验丰富，也很擅长社交，但我并不喜欢他们，因为他们的思维模式总是在往系统里“增加东西”。 而另一类开发者则完全不同。他们最常说的话是：“我们真的需要这个吗？”、“如果不做会怎么样？”、“能不能先凑合一下，等以后真正重要了再说？”我非常认同这种开发者，因为他们真正害怕的是一件事情：复杂度。 在真正长期维护过大型系统的人眼里，复杂度几乎是一切问题的源头。每增加一个特殊逻辑、一个新的数据库表、一个新的服务模块，系统都会变得更难理解一点、更难调试一点、更难维护一点。复杂度并不会立刻毁掉系统，它更像一种慢性病，刚开始时团队感觉不到问题，但随着时间推移，整个系统会逐渐变成没人真正理解的巨大黑盒。最终，任何小改动都可能引发连锁反应，每一次上线都像是在拆炸弹，而团队的开发效率也会被慢慢吞噬。 然而，令人尴尬的是，公司里的大多数人并不能真正理解这种恐惧。原因在于，他们害怕的根本不是复杂度，而是不确定性。 我把企业简化成两个循环。第一个循环属于市场、销售、产品经理和 CEO。在这个循环里，人们最关心的问题是：“这个方向到底行不行？”、“用户会不会买单？”、“这个功能有没有价值？”他们最大的敌人，是市场不确定性。因为没有任何商业决策能够保证成功，所以唯一能做的事情，就是不断尝试、不断上线、不断获取反馈，然后根据反馈快速调整方向。在这种环境里，速度自然就成了最重要的东西，因为谁能更快进入市场，谁就更有机会降低不确定性。 而 AI 恰恰极大强化了这种逻辑。AI 可以帮助团队更快生成代码、更快做原型、更快验证需求，因此从业务角度来看，它几乎像一种革命性的生产力工具。很多人因此开始相信：既然 AI 已经可以高速生成代码，那么软件开发本身似乎也会越来越廉价。 但问题在于，当公司真正拥有客户之后，第二个循环就会出现。 这个循环不再关心“探索”，而是开始关心“稳定”。系统必须持续运行，支付不能中断，线上服务必须可靠，Bug 必须有人能修，代码必须有人看得懂，新人也必须能够接手系统。于是，资深开发者开始拼命控制复杂度，因为他们真正负责的，并不是“把功能做出来”，而是“保证整个系统能够长期稳定运行”。 这时候，双方的矛盾就出现了。 业务团队关心的是如何更快降低市场不确定性，而资深开发者关心的是如何控制系统复杂度。于是双方虽然都在讨论“开发”，但实际上讨论的根本不是同一个问题。业务团队希望的是“更快上线”，而资深开发者担心的是“系统越来越危险”。当资深开发者不断强调维护成本、长期复杂度和技术债务时，这些话对于业务部门而言往往毫无说服力，因为他们真正焦虑的是：如果现在不上线，会不会直接失去市场机会。 我对此给出了一个非常精准的总结：你不能用自己的问题，去解释别人的问题。 资深开发者之所以总是显得“保守”“拖慢进度”，并不是因为他们不懂业务，而是因为他们一直在用“复杂度管理”的语言沟通，而公司其他人真正关心的，却是“如何更快减少不确定性”。这两套语言天然无法对接，于是沟通自然失败。 真正优秀的资深开发者，其实非常擅长一件事情：用尽可能少的建设，完成真正需要完成的目标。当团队想做复杂的新功能时，他们可能会先在现有界面放一个按钮测试用户行为；当团队想搭建完整的数据分析系统时，他们会先思考：“我们到底想验证哪个决策？”很多时候，他们甚至会直接使用 Google Forms 之类现成工具，因为他们非常清楚，公司真正需要的往往不是“完整系统”，而只是“验证问题”。 于是我提出，每个资深开发者都应该学会一句话： “Can we try something quicker?” “我们能不能先试一个更快的方法？” 这句话之所以厉害，是因为它同时满足了双方的需求。它既承认业务真正需要的是速度，也保留了工程上的克制；它没有直接否定需求，而是把“减少复杂度”重新翻译成了“更快降低不确定性”。我认为，这才是资深开发者真正缺失的沟通能力。 而文章最有意思的部分，其实是关于 AI 的最后讨论。很多人现在会说，既然…

Anthropic 最近因为一项安全研究登上了新闻头条：他们声称 Claude Mythos 完成了“首个由 AI 发现并成功利用的远程内核漏洞”。 这个说法听起来相当震撼。 于是我们开始追踪：Mythos 究竟是怎么做到的？ 结果发现，它找到的其实是一个已经存在了将近 20 年、几乎明晃晃摆在那里却没人注意到的老漏洞。 下面我们来拆解 Mythos 到底做了什么，以及这件事真正意味着什么。 Claude Mythos 到底发现了什么？ 在 Anthropic 关于 Claude Mythos 的最初文章中，他们提到了多个由 Mythos 发现并利用的漏洞。 其中技术细节最完整的，是 CVE-2026-4747 —— 一个存在于 FreeBSD 网络文件系统中的远程代码执行漏洞（RCE）。 这类网络文件系统广泛部署于企业和科研机构的本地存储系统中，因此影响范围并不小。 漏洞本身是一个非常经典的“教科书级”漏洞：栈缓冲区溢出（stack overflow）。 更关键的是，FreeBSD 默认并未启用某些现代安全防护机制，例如： 这使得漏洞利用难度进一步降低。 问题核心出现在 svc_rpc_gss_validate() 函数中。 函数内部会把 RPC Header 重建到一个仅有 128 字节的栈缓冲区 rpchdr[] 中： 其中： 但程序随后直接执行： 却完全没有检查 oa_length 是否超过剩余空间。…

以下内容根据用户上传文件进行翻译整理： 《推理架构的转变》 2026 年 5 月 11 日，星期一 如果你正在寻找一家最适合 IPO 的公司类型，那么在 2026 年 5 月成为一家芯片公司，几乎没有比这更好的时间点了。路透社周末报道称： Cerebras Systems 计划最快于周一提高其首次公开募股（IPO）的发行规模和发行价格。两位知情人士向路透社透露，由于市场对这家人工智能芯片制造商股票的需求持续攀升，公司正在考虑将 IPO 价格区间从此前的每股 115 至 125 美元提高至 150 至 160 美元，并将发行股票数量从 2800 万股提高到 3000 万股。由于相关信息尚未公开，消息人士要求匿名。 推动半导体股票持续上涨的根本动力，当然仍然是 AI，尤其是市场逐渐意识到：Agent（智能体）将需要极其庞大的计算能力。不过，Cerebras 所代表的意义，其实远不止于此。过去 AI 的计算故事几乎完全围绕 GPU 展开，尤其是 Nvidia 的 GPU，但未来的计算架构将越来越趋向异构化。 GPU 时代 关于 GPU（图形处理器）如何成为 AI 核心基础设施的故事，其实已经被反复讲述过很多次了，但简单概括如下： 由于在计算机屏幕上绘制像素本身就是一个并行化过程，因此处理单元数量与图形渲染速度之间存在直接关系；而 AI 相关计算同样也是并行化过程，因此处理单元数量与 AI 运算速度之间也存在直接关系。 Nvidia 通过让图形处理器具备可编程能力，实现了这种双用途特性，并构建了…

在最近一轮融资中，OpenAI 允许员工每人出售最高 3000 万美元的股份，使他们成为 AI 浪潮中最早真正兑现财富的人之一。 去年 10 月，超过 600 名现任与前员工一次性出售了手中的股份，总计套现 66 亿美元。根据知情人士透露，其中大约有 75 人直接卖满了 3000 万美元的上限。 有些人在套现之后，甚至选择把剩余股份捐出去——他们将股票放入 donor-advised fund（捐赠建议基金）中。这类账户既可以用于慈善事业，同时还能让捐赠者在当年获得税务减免。 这场股份出售，其实也提前揭示了一波即将席卷旧金山以及全球科技中心的财富洪流。 OpenAI 和 Anthropic 正在为未来可能成为史上最大规模 IPO 的上市做准备。届时，成千上万普通员工将能够出售股票，许多人会直接变成千万富翁。 OpenAI 要求员工必须等待两年后才能出售股份，因此这次股票出售，也是许多在 ChatGPT 发布后加入公司的员工第一次真正“落袋为安”。 OpenAI 员工持股价格增长轨迹： 也就是说，早期员工手中的股票，7 年间价值上涨超过 100 倍。 相比之下，同一时期纳斯达克综合指数大约只涨了三倍。 历史上从未有任何一轮科技繁荣，在公司上市之前，就已经向如此大规模的普通员工释放如此巨大的财富。 互联网泡沫时期，虽然也有数百家公司 IPO，但大多数员工即使上市之后，还得等待很长时间才能真正卖出股票。 而对于很多人来说，在他们终于能卖股之前，泡沫就已经破裂，他们最终什么都没得到。 而 AI 时代不同。 针对某些高度专业化人才的薪酬规模，在现代历史上几乎没有先例。 Google 和 Facebook 的早期员工在公司上市后确实赚到了数百万美元，但这一次 AI 领域财富创造的规模——尤其是针对非创始人员工——已经远远超越过去。 去年，Meta 为了抢顶级研究员，曾开出高达 3…

我算是 AWS 刚诞生时最早的一批倡导者之一——SQS、S3、EC2、SimpleDB——那时候 AWS 的规模还小得多。事实上，当年 AWS 的美国 evangelist 第一次来到墨尔本宣传 AWS 时，我还组织了墨尔本第一场 AWS 活动。 云计算当时简直是一场令人震撼的革命——一家创业公司突然之间就能在几分钟内拥有自己的计算系统，而不需要再去数据中心安装和维护自己的机器。这完全改变了游戏规则，而我当时彻底喝下了 AWS 的 Kool Aid，连杯底都舔得干干净净。我对 AWS 是彻底 All In 的。 之后大概整整 15 年，我一直都是 AWS 的超级粉丝——真正意义上的信徒——我彻底押注 AWS。 关系的崩坏，总是一点一点开始的——有那么一两件事情开始让你不爽，但整体上你还是爱它，对吧？虽然这里那里会有一些小缺点，但没关系！它依然超级棒，你依然热爱它，对吧？但渐渐地，你开始注意到越来越多不对劲的地方，越来越多你不喜欢、已经坏掉、或者设计糟糕的东西。直到某一天，最后一个细节出现，天平终于彻底倾斜，你会突然意识到： “我已经不再喜欢这段关系了。” 下面这些事情，就是一点一点侵蚀我对 AWS 感情的原因： AWS 在存在的前六年里，居然不愿意自己构建官方客户端库，而是把这件事甩给“我们伟大的社区”，让 Python 等语言的开发者在周末和夜晚免费帮 AWS 写 SDK，为 AWS 的利益白打工。这件事真的让我非常恼火。 AWS 在从 Python2 迁移到 Python3 这件事情上拖延了荒谬般长的时间，这也让我极度不爽。 DynamoDB —— 我其实很少真正“恨”某个软件，但天啊，DynamoDB 真的是一坨滚烫的垃圾。我试了一天，结果当天账单就到了 75 美元。问题不仅仅是贵，它几乎在每一个层面上都烂到极致。…

“它是文本的，所以它是可访问的”这一神话 在有视力的开发者中，存在一种根深蒂固的误解：只要应用运行在终端中，它就天然是可访问的。这种逻辑认为，由于没有图形界面、没有复杂的 DOM，也没有 WebGL 画布，内容不过是原始的 ASCII 文本，因此屏幕阅读器可以轻松解析。 现实却完全不同。大多数现代文本用户界面（TUI）往往比设计糟糕的图形界面更不友好。那些本应提升开发者体验（DX）的终端工具——例如 Ink（JS/React）、Bubble Tea（Go）或 tcell——实际上正在破坏盲人用户的使用体验。 架构缺陷：流 vs 网格 要理解这一失败，我们必须区分两种常被混淆的概念：“终端应用”中的 CLI 和 TUI。 CLI（流）：基于标准输入/输出（stdin/stdout），用户输入命令，系统将结果按顺序追加在下方，光标持续向下移动。这种线性、按时间排列的结构，对于屏幕阅读器（尤其是内核级阅读器如 Speakup）来说是理想的。 TUI（网格）：将终端窗口视为一个二维字符网格，每个字符单元就像一个像素。它放弃了时间顺序，转而使用空间布局。 案例研究：gemini-cli 的混乱 以一个具体例子来看：gemini-cli，这是一个基于 Node.js 并使用 Ink 框架开发的工具。表面上它看起来像一个简单的聊天界面，但实际上，Ink 正在尝试将 React 组件树渲染到终端网格中。 当你使用 Speakup（Linux）或 NVDA（Windows）时，这个应用不仅无法正常工作，甚至会“骚扰”用户。 由于框架将屏幕视为一个响应式画布，每次更新都会触发重绘。当 AI 在“思考”时，工具会更新计时器或加载动画。为此，它不断移动硬件光标到计时器位置，写入新时间，然后再移回。 对于有视力的用户，这几乎是瞬间完成的。但对于屏幕阅读器用户，你听到的却是： “正在响应……已用时1秒……正在响应……已用时2秒……[聊天记录片段]……正在响应……” 这种体验会让屏幕阅读器“发疯”。光标在屏幕各处跳跃，阅读器试图读取当前光标所在位置的内容，结果就是你听到的是杂乱的对话片段与计时信息混合，根本无法专注于输入内容。 更糟糕的是，如果你尝试在不同环境之间切换，例如使用 NVDA 粘贴错误信息到远程终端，结果往往是屏幕阅读器崩溃或系统严重不稳定。 原因在于，每次输入或粘贴都会触发状态变化，框架会重新渲染界面。由于聊天历史是状态的一部分，应用会尝试即时重绘数千行内容。对话越长，问题越严重。而且，即便使用抑制动态内容朗读的快捷键，也无法避免。 延迟循环 此外，像 Ink 这样的单线程框架在处理大量历史记录时性能会严重下降。如果粘贴大段文本，系统需要计算成千上万行的差异。 这会导致输入延迟：按下一个键，可能需要等待数秒才显示。系统忙于重绘界面，而无法及时处理输入。 为什么“老工具”反而有效（nano、vim、menuconfig） 有视力的开发者常问：“如果 TUI 不好用，那为什么你们还使用 nano、vim 或…

终端用户界面（TUI）正在重新流行起来。DHH 的 Omarchy 由三种用户界面构成：TUI（用于即时反馈以及额外的“极客加分”）、Web 应用（因为他的公司 37signals 主营 SaaS Web 应用），以及那些不可避免的 GNOME 风格原生应用——但这些原生应用实际上并不太符合该发行版的整体风格。 类似的模式在大约十年前也曾出现于代码编辑器领域。我们从 BBEdit、TextMate（同样由 DHH 推广）、Notepad++ 和 Sublime 这些原生编辑器，转向基于 Electron 的应用，如 Atom、VSCode 以及它们的各种分支。而一部分“硬核”用户则转向 vim 或 emacs，在更高学习成本的代价下，换取即时反馈与更高效率。 Windows 教训已经很清楚：原生应用正在失去优势。Windows 在 GUI 库方面不断重复一个“标准笑话”：当一个 API 不成功时，就再推出一个新的，然后这个新的也在众多替代方案中失败。 从 1992 年的 MFC（用 C++ 封装 Win32）开始，如果说 Win32 本身已经不优雅，那么 MFC 就像是“穿着西装的 Win32，而那件西装还是由更多西装拼起来的”。随后出现了 OLE、COM、ActiveX——这些虽然不完全是 GUI 框架，但它们渗透进 Windows 开发的各个角落，带来了极高的认知复杂度。 此后，微软又经历了 WinForms、WPF、Silverlight、WinUI、MAUI 等一系列框架，但都未能形成统一成功的生态。许多企业级和个人桌面应用仍然依赖 Electron，而用户最后一次感受到操作系统整体视觉一致性的时代，或许还停留在 Windows…

对认知债务与能力退化保持警惕。 “AI 负责写代码，人类则作为在环中的协调者。” 这是当前行业中被大力鼓吹的一种观点：传统编程几乎已经走向终结，而规格驱动开发（SDD）才是未来。你只需要生成一份计划，然后完全脱离代码编写。智能代理更懂，它们会处理所有实现细节。你作为专家的角色，是提供“良好的品味”，审核输出结果，并不断引导这些代理去执行你精心制定的计划。 这种工作流程目前有多种形式，但总体而言，它通常是这样一个过程：某个人定义项目需求（同时涵盖宏观与微观层面），生成计划，然后像拉老虎机一样不断重复操作，通过多次迭代、甚至多个代理实例反复尝试，直到完成。在整个过程中，“协调者”与实际生成并提交的代码之间的距离越来越远。 编码代理确实强大且有用，但已经出现了一些可以量化的权衡问题，值得认真讨论： 为应对AI非确定性带来的模糊性，周边系统复杂度显著增加；大量人群的技能正在退化；个人与团队面临供应商锁定（例如 Claude Code 宕机时，整个团队停摆）；使用这些工具的成本波动且不断上升——员工成本是固定的，而 token 成本却难以预测；这种模式能否成功，取决于一个关键前提：必须由具备批判性思维、能够从架构层面理解系统的熟练开发者来识别成千上万行生成代码中的问题，并在问题扩大之前加以修正。 然而，具有讽刺意味的是，AI 工具已经被证明会削弱个人的批判性思维能力和认知清晰度，而这些正是成功使用编码代理所必需的能力。 这不仅仅是“另一种抽象” 社区中常见的一种说法是：程序员只是“向更高层抽象移动”。但这些工具是否真的属于抽象层仍存在争议——更高的不确定性并不等同于更高的抽象层级。 当然，程序员历来对新语言和新编程方式持谨慎态度。例如 FORTRAN 刚发布时，也遭到质疑，人们认为它可能带来更多错误，直接写汇编更高效。后来编译器的引入也曾被批评为增加了“魔法”。这些担忧大多是基于对未知的恐惧，是一种规范性判断。 但如今的不同之处在于，这些影响已经不再是理论推测。在 AI 工具出现的短短几年里，我们已经看到了显著的实际影响，而且不仅限于初级开发者，甚至包括拥有十年以上经验的工程师。 编码代理悖论 对于初级开发者而言，学习曲线变得更加陡峭，因为他们与代码直接接触的机会被削弱，转而变成审查生成代码。代码审查固然重要，但它最多只占学习过程的一半。如果缺乏亲自编写代码所带来的摩擦与挑战，学习能力将被严重削弱。 这一现象需要时间研究，但目前已有大量轶事证据和研究报告表明，这确实是一个真实存在的问题。 这一次，确实不同。 当 C++ 开发者转向 Java 或 Python 时，他们并不会抱怨大脑混沌；当系统管理员迁移到 AWS 时，也不会觉得自己失去了对网络的理解能力。 资深工程师随着转向管理岗位而逐渐“生疏”的现象并不新鲜。这是经验积累后的自然结果——他们已经通过几十年的实践建立了扎实的理解，可以在更高层面做架构决策。但这些人本就极其稀少，而如果我们现在普遍放弃编写代码、解决问题和调试的过程，就无法培养出下一代资深工程师。 当前的趋势是，那些尚未经历长期积累、尚未建立深度理解的开发者，被提前推向需要高级技能的工作流程，以管理 AI 代理，而这些技能原本需要数十年才能获得。 甚至资深工程师也无法完全免疫。拥有近30年经验的开发者 Simon Willison 表示，他已经不再拥有对应用能力和运行机制的“清晰心理模型”，这使得新增功能越来越难以推理。 “熟练协调者”的问题 Anthropic 的一项研究中曾坦率指出一个风险： 代码能力退化令人担忧的原因之一在于“监督悖论”——有效使用 Claude 需要监督，而进行监督本身又需要那些可能因过度使用 AI 而退化的编程技能。 LinkedIn 软件工程总监 Sandor Nyako（管理50名工程师）也观察到这一问题正在扩散，并要求团队不要在需要批判性思维或问题解决的任务中使用这些工具。…