Author: aitrendtrackers@rengongzhineng.io

软件行业正站在一个诡异的拐点上。AI 编程已经从“加强版自动补全”，进化成能够自主执行开发任务的代理（agents）。曾经推动科技行业大规模招聘的经济繁荣，如今让位于“效率优先”的指令：公司更常选择盈利而非增长、选择有经验的人才而非应届生、选择更小的团队但配备更强的工具。 与此同时，新一代开发者正在进入职场，他们的计算方式完全不同：更务实地看待职业稳定性，更怀疑拼命内卷文化，并且从第一天起就在 AI 辅助中成长。 接下来会发生什么，确实充满不确定性。下面是五个可能塑造 2026 年之前软件工程走向的关键问题，每个问题都给出两个对立的情景。这并不是预测，而是帮助你准备的“观察镜头”。目标是给出一条更清晰的应对路线图：基于当前数据，同时保留这个圈子惯有的健康怀疑。 传统的路径——“学编程 → 找初级岗位 → 成长为资深”——正在摇晃。一项哈佛研究分析了 6200 万名劳动者，发现当企业采用生成式 AI 后，初级开发者就业在六个季度内下降约 9–10%，而资深岗位几乎不动。过去三年，大型科技公司招聘的应届毕业生减少了 50%。有工程师冷笑说：“为什么要花 9 万美元雇一个需要培训的新人？一个 AI 编程代理更便宜。” 这不仅仅是 AI 的影响。宏观因素，比如利率上升和疫情后经济修正，大约在 2022 年就已经冲击了招聘，那时 AI 工具还没普及。但 AI 加速了趋势：一个资深工程师配合 AI，如今可以做出过去需要一个小团队才能完成的产出。很多公司并不是大规模裁掉新人，而是更“安静地”选择不招。 反转情景是：AI 释放出巨大的开发需求，推动软件进入所有行业，而不只是互联网公司。医疗、农业、制造、金融都开始深度嵌入软件与自动化。AI 不是替代开发者，而是让开发工作扩散到过去从未雇佣程序员的领域。这样一来，入门岗位会变多，但形式不同：你会看到更多“AI 原生”开发者，他们快速为特定行业构建自动化与集成。 美国劳工统计局仍然预测，2024–2034 年软件岗位增长约 15%。如果企业用 AI 扩大产出，而不是单纯削减人力，他们仍然需要人来抓住 AI 创造的机会。 悲观情景的长期风险常被忽略：今天的新人就是未来的资深工程师与技术领导。如果整个行业切断人才管道，5–10 年后就会出现领导力真空。业内老兵称之为“慢性衰退”：生态系统停止培养继任者。 怎么做： 初级开发者：让自己 AI 熟练且足够“多面手”。证明“一个新人 + AI”可以达到过去一个小团队的产出。用 AI 编程代理（Cursor/Antigravity/Claude Code/Gemini…

AI 并没有杀死代码审查。它只是让**“举证责任”变得更加明确了。在今天，发布代码时，你必须附带它能正常工作的证据——比如人工验证、自动化测试；而代码审查本身，则更多用于评估风险、意图与责任归属**。独立开发者依靠自动化来跟上 AI 的速度，而团队则通过审查来建立共享的上下文与所有权。 如果你的 Pull Request 里没有“它确实能工作”的证据，那你并不是在更快地交付——你只是把工作往下游推而已。 截至 2026 年初，超过 30% 的资深开发者表示：他们发布的代码中，大部分是由 AI 生成的。真正的挑战在于：AI 非常擅长起草功能，但在逻辑、安全性和边界条件上表现不佳——仅在逻辑错误这一项上，出错率就高出 75%。这直接分裂了工作流： 做得好的情况下，这两种方式都把 AI 当作加速器；但真正的分水岭在于验证——由谁来验证、验证什么、在什么时候验证。 我以前就说过一句话：如果你没有亲眼看到代码做了正确的事情，那它就还没工作。AI 不是这个原则的例外，而是把它放大了。 开发者如何使用 AI 进行代码审查 无论如何，当你是独立开发，还是在一个需要他人长期维护你代码的团队中，工作流和心态都会截然不同。 独立开发 vs 团队开发：快速对比 独立开发者：以“推理速度”交付 越来越多的独立开发者开始“相信 AI 的感觉”，他们只检查关键部分，其余交给测试来兜底，从而极快地发布功能。 在这种模式下，编程代理就像能力极强的实习生，可以在很少人工干预的情况下完成大规模重构。Peter Steinberger 就坦言： “我现在几乎不读代码了。我会看生成过程，有时扫一眼关键部分，但大多数代码我并不会读。” 此时的瓶颈不再是敲键盘，而是等待 AI 推理输出的时间。 但这里有个前提：没有强测试体系，所谓的速度提升会瞬间消失。如果你跳过审查，并不是省掉了工作，而是把它延后了。真正能用 AI 高速前进的开发者，并不是盲目信任它的人，而是那些已经建立起可靠验证系统的人。 这并不意味着独立开发者会鲁莽行事。负责任的独立开发者，往往会构建大量自动化测试作为安全网——目标通常是高覆盖率（常见 >70%），并使用 AI 实时生成测试来捕捉 bug。令人意外的是，现代编程代理在设计复杂的端到端测试方面表现相当出色。 对独立开发者而言，真正的杀手级能力是与语言无关、以数据为驱动的测试。只要测试足够全面，代理就能在任何语言中构建（或修复）实现，并在过程中不断验证。我个人的做法是：先写一个 spec.md，让 AI 起草，我来审核确认，然后进入循环：写 → 测 →…

大约14年前，当我加入谷歌时，我以为这份工作就是写出优秀的代码。某种程度上我没错。但随着时间推移，我渐渐意识到，真正能茁壮成长的工程师，不一定是编程最强的人，而是那些懂得如何在代码之外应对一切的人：人与人之间的关系、团队政治、目标对齐，以及模糊不清的环境。 这些经验是我希望自己更早明白的。有些经验能帮我少走几个月的弯路；有些则花了多年才真正体会到。它们都与具体技术无关——因为技术变化太快，不值得执着。它们讲的是那些反复出现的模式：一个又一个项目，一支又一支团队。 我分享这些，是因为我曾受益于前辈工程师的经验分享。这是我想回馈的一次尝试。 1. 最优秀的工程师，痴迷于解决用户问题。人很容易沉迷于某项技术，然后到处找机会去应用它。我也犯过这样的错，几乎每个人都犯过。但真正创造最大价值的工程师，是那些从用户问题出发，深刻理解问题本质，并让解决方案从理解中自然浮现出来的人。 对用户的痴迷意味着要花时间在支持单中、与用户交谈、观察用户遇到的困难，并不断追问“为什么”，直到找到问题的根源。真正理解问题的工程师，往往能找到比所有人预期都更简单优雅的解决方案。 相反，那些从解决方案出发的工程师，往往会在寻找“合理化”的过程中，构建出复杂性。 2. “你是对的”很廉价，一起变得正确才是真正的工作。你可以赢下所有技术争论，却输掉整个项目。我见过聪明绝顶的工程师，因为总是“房间里最聪明的人”，而无形中积累了团队的怨气。这种代价会在后期以“神秘的执行问题”或“奇怪的阻力”形式体现出来。 真正的能力不在于“对”，而在于能否进入讨论以对齐问题、为他人留出空间，并对自己的确定性保持怀疑。 “强烈观点，弱持有”——不是因为缺乏信念，而是因为在不确定性中做出的决策，不该与自我身份绑定。 3. 行动优先。发布它。你可以修改一篇糟糕的文稿，却改不了一张空白页。追求完美是瘫痪性的。我见过工程师为一个从未实现的架构争论数周。完美的方案很少只靠思考得出——它诞生于与现实的接触。AI在这方面也能提供巨大帮助。 先做，再做对，再做得更好。把丑陋的原型拿给用户看；写下凌乱的设计文档初稿；发布那个让你略感尴尬的MVP。你从一周的真实反馈中学到的，比一个月的理论争论更多。 动力带来清晰。分析瘫痪带来空无。 4. 清晰即资深，聪明是负担。工程师都有写“聪明代码”的冲动，因为这让人感觉能力出众。 但软件工程真正发生的地方，是当时间和他人介入之后。在这种环境中，清晰不是风格选择，而是降低运营风险的手段。 你的代码是一份“凌晨两点陌生人会看的战略备忘录”。优化的目标不是你的优雅，而是他们的理解。我最尊敬的高级工程师，永远选择清晰胜于聪明。 5. 新奇是一笔债务，你将以宕机、招聘和心智负担偿还。把技术选择当作拥有有限“创新代币”的组织来管理。每采用一次非标准方案，就花掉一个代币，而你负担不起太多。 关键不是“永不创新”，而是“只在你被付费去创新的地方创新”。其他一切都应选择“无聊”的方案，因为“无聊”的系统有已知的失败模式。 “最好的工具”往往是“在多种情况下最不糟的工具”，因为技术动物园的维护成本才是真正的负担。 6. 代码不会替你发声，人会。早年我以为“好代码会自己说话”。错了。代码沉默地躺在仓库里。你的经理会不会在会议上提到你？同事会不会推荐你去参与项目？这些才决定你的影响力。 在大公司里，许多决策发生在你不在场的会议上，由你没写的总结报告决定，而参与者只有五分钟和十二个优先事项。如果没有人能在你不在时清楚表达你的价值，那你的影响几乎等于零。 这并不是“自我推销”，而是让价值链对他人——包括你自己——都清晰可见。 7. 最好的代码，是你根本不用写的代码。工程师文化常常歌颂“创造”。没人因为删除代码而升职——尽管删除代码往往比新增更能提升系统质量。你不写的每一行代码，都是你永远不必调试、维护或解释的一行。 在动手之前，先问自己：“如果我们什么都不做，会怎样？”有时答案是“也没什么坏事”，那这就是最好的解决方案。 问题不是工程师不会写代码或不会用AI写，而是我们太擅长写代码，以至于忘了问一句：“这段代码真的有必要存在吗？” 8. 当你的用户足够多时，连你的bug也会有用户。用户多到一定程度后，系统中每一种可观察行为都会被人依赖——无论你是否承诺过。有人会抓取你的API、自动化你的“怪癖”、缓存你的漏洞。 这带来一个职业级洞见：不能把兼容性工作当作“维护”，而把新功能当作“真正的工作”。 兼容性本身就是产品。 设计废弃时，要把它当作迁移：给时间、给工具、给同理心。多数“API设计”，其实是“API退休”。 9. 大多数“慢”的团队，其实是“错位”的团队。当项目进展迟缓时，人们的本能是怪执行力：是不是大家不够努力、技术选错了、工程师不够多。通常这些都不是根本问题。 在大公司里，“团队”才是并发的单位，而协调成本会随团队数呈几何级增长。多数的慢，其实是对齐失败——有人在做错的事，或者在错误方式下做对的事。 高级工程师花更多时间去澄清方向、接口、优先级，而不是“更快地写代码”，因为真正的瓶颈就在那儿。 10. 专注你能控制的，忽略你不能的。大公司中，很多变量都超出你掌控：组织调整、管理决策、市场变化、产品转向。纠结这些只会带来焦虑，却无助于行动。 那些保持冷静又高效的工程师，会聚焦于他们的影响范围。你无法控制重组是否发生，但你能控制工作的质量、应对方式，以及你从中学到什么。当面对不确定性时，把问题拆分成小块，明确你能采取的具体行动。 这不是被动的接受，而是战略性的聚焦。花在无法改变之事上的精力，就是被偷走的行动力。 11. 抽象并不能消除复杂性，只是把复杂性推迟到你值班那天。每个抽象层都是一种赌注——赌你永远不需要理解底层细节。有时你会赢，但抽象总会泄漏，当那一刻到来时，你必须知道自己脚下是什么。 高级工程师即使在技术栈越堆越高时，依然会去学习底层知识。这不是怀旧，而是出于对系统失败时那一刻的尊重。要善用你的技术栈，但也要理解它的崩溃方式。 12. 写作带来清晰。想更好地学会某件事，就尝试去教它。写作能迫使人理清思路。每当我试着向别人解释一个概念——不论是在文档、演讲、代码审查评论，还是和AI聊天——我都会发现自己理解中的空白。让别人能看懂，也让自己看得更清楚。 这不仅仅是“分享知识”的善意行为，更是一种自我学习的捷径。如果你觉得你理解了某件事，试着用最简单的方式解释它。你卡壳的地方，就是理解的盲点。 教学，是调试你的思维模型。 13. 让其他工作得以发生的工作，最有价值——也是最容易被忽视的。“粘合工作”——文档、入职培训、跨团队协调、流程改进——至关重要。但如果你不有意识地对待它，这些工作可能会拖慢你的技术成长，甚至让你精疲力竭。陷阱在于：你出于“好心”去做，而非将其视作有界、有价值的成果。 限定时间。轮换负责。让成果可见。 把它们转化为文档、模板、自动化脚本。并让这些产出以“影响”呈现，而非以“性格”呈现。…

2025 年，真是非同寻常的一年。如果说作为一家创业公司的创始人，正常的一年已经像是经历了四到五年的时间密度，那么这一年更接近整整十年。我们这个行业的变化速度异常疯狂。“vibe coding” 这个概念甚至还不到一年历史。Apple 首次在美国被迫允许应用内使用外部支付链接。应用变得前所未有地容易构建。孩子们现在想成为开发者，好开兰博基尼。市面上出现了各种课程，承诺只要学会做应用就能赚到数百万，把应用开发变成了几年前的“无货源电商”。 我们被迫迅速适应，并不断扩展“开发者”的定义。我们从最初帮助开发者赚更多钱，逐渐转向帮助应用赚更多钱，最终又演进为帮助 vibe coders 赚更多钱。 就在这一切变化的正中央，我的CostDog公司差点被收购。 所以，请允许我继续这一年一度的年终反思。又一年，我们继续学习如何打造一家我们希望能成为世代级的公司。 房间里的大象 在去年的博客文章中，我遗漏了一个重要细节。事实上，那篇文章完全可能成为这个系列的最后一篇。因为在 2024 年底，我们收到了一份非常严肃的收购要约，想要收购 CostDog。 作为一名创始人，这是你会在脑海里反复想象、却从不真正相信会发生的事情，直到它真的发生。一家我们由衷敬重的大公司希望与我们合并。这种感觉极具肯定意义。我和联合创始人 Jim多年前做的那个“小玩具”，已经成长为别人真正想要的东西。不是 VC 在幻灯片上放大的数字，而是一场真实、有意义的流动性事件。 接下来的几周，用“情绪化”和“压力巨大”来形容都远远不够。要约到来时，我们的状态并不好。我们很疲惫。Jim刚刚摔断了脚踝，一边承受身体上的疼痛，一边承受康复过程带来的心理负担。一切都显得比平时更加沉重。 有些日子，我醒来时确信我们应该卖掉公司；而另一些日子，我又百分之百确定绝不能卖。事情变得更复杂的原因在于，Jim和我经常不同步，在兴奋和怀疑之间交替摇摆。一个人觉得头脑清晰，另一个却充满犹豫。 我们从未以出售公司或快速套现为目标来创业。但当真正严肃的报价摆在面前时，你有责任认真对待。这笔交易意味着我个人将获得九位数的回报。说实话，这对我来说是一大笔钱。这对创始人而言是一个极好的结果，但对部分投资人和团队成员来说，就未必如此。 继续独立前行 最终，在权衡了一切之后，我们决定不卖。 当时，我们手上有一件明显正在奏效的事情，而且它正在变得越来越好。我们面前的机会巨大。我们已经成为应用经济中一个至关重要的组成部分。我们拥有优秀的用户、强劲的增长势头，以及一支花了多年时间才组建起来的世界级团队。而一旦出售，你就真的卖掉了。不管交易结构如何，公司都不再属于你。那些让它与众不同的东西，那种文化，一切都会不可避免地发生变化。 如何走得更远 真正的问题随之而来：我们该如何让这件事在未来十年甚至更久的时间里，对我们来说是可持续的？ 我们写下了一份“会让我们选择退出的原因清单”。当我们认真审视它时，发现其中大多数问题要么可以用钱解决，要么完全在我们自己的控制之中。对我来说，最重要的是只和那些能激励我的人一起工作，而不是消耗我能量的人，同时确保我的家庭被妥善照顾。 于是，我们决定再融资一轮。这轮融资包含了一个有意义的二级交易部分，帮助我们降低了决策风险，也移除了大量反复犹豫。我们把这件事坦诚地告诉了整个团队，然后继续建设。 这是一个非常个人化的决定，每个人的情况都不同。除了写下利弊清单之外，对我帮助最大的一件事，是去联系那些曾经有机会出售公司、但最终选择不卖的创始人，那些几十年如一日坚持走下去的人。 我们往往在公开场合庆祝“退出”，尽管其中许多并未给创始人或投资人带来真正有意义的结果。对选择出售的人，我完全尊重，毕竟创业真的非常艰难。但我们很少庆祝那些年复一年、持续推进、打造持久事业的人。 其中一位创始人对我说过一段话，让我至今难忘。他说，冲浪或者做你喜欢的事情六个月听起来很棒，但最终你会感到无聊，想再做点什么。大多数人低估了打造一个真正有人需要的东西有多难。这需要多年的努力和高度一致的投入。他意识到这家公司是他最大的资产，而如果他留下来，它的价值会更高。所以他试着在公司内部找到一个仍然能让自己感到乐趣的位置。 我是一个创造者。环游世界、冲浪六个月听起来确实很诱人，但我内心深处知道，两周之后我就会开始感到无聊。 家庭的支持 另一场关键的对话发生在我和妻子之间。她对我说，如果你卖掉公司，会有点可惜，这是你和 Jacob 的孩子。我回答她，如果我们继续走下去，就意味着未来十多年更多的牺牲，更多的压力，更多的出差，以及更多我精神疲惫地回家的夜晚。 她想了一会儿，然后对我说，这正是我们过去十年一直过的生活，而且它是有回报的。我们为你和 Jim感到非常骄傲。 你必须有点疯狂，才会心甘情愿地放弃这次收购本可以为我们家庭带来的世代财富。但她相信我们能把这件事做得更大，也应该继续向前。这些年她承受了很多，没有她的支持，CostDog不可能走到今天。如果你想打造一家世代级的公司，结婚一定要慎重。 我的角色 也许这是我角色变化最小的一年。我的日常工作和前一年几乎完全一样，职责也没有太大变化。我是不是终于变成了一个“真正的高管”？也许吧，谁知道呢。最大的不同在于，我只是把所有事情都做得更多了。我也愿意相信，我做得更高效，也稍微更好了一些。规模变大了，影响力也随之放大。 年初，我给自己定下了四个简单的目标：用 CostDog真正向 App Store 发布一个应用；更多前往旧金山，与高管和创始人建立更深的联系；每天至少与一位客户交谈；以及每周至少锻炼三次。我很高兴地说，这四个目标我全部完成了。 成为“吉祥物” 这是我在公司历史上对外活动最多的一年。我在 2024 年已经出差很多，而 2025 年更多。Jason Lemkin…

2025：大语言模型之年 这是我年度系列回顾过去 12 个月里 LLM 领域发生的一切 这一年充满了许多不同的趋势 ： 这就是 2025 年的总结 。 “推理”之年 OpenAI 在 2024 年 9 月通过 o1 和 o1-mini 开启了“推理”——即推理缩放（inference-scaling）或称“来自可验证奖励的强化学习”（RLVR）革命 。他们在 2025 年初通过 o3、o3-mini 和 o4-mini 加倍投入，此后“推理”已成为几乎所有其他主要 AI 实验室模型的标志性功能 。+1 关于这一技巧重要性，我最喜欢的解释来自 Andrej Karpathy ： 通过在许多环境（例如数学/代码谜题）中针对自动可验证的奖励训练 LLM，LLM 会自发地产生在人类看来像是“推理”的策略——它们学会将问题解决分解为中间计算，并学会了许多用于来回思考以弄清楚问题的策略（参见 DeepSeek R1 论文中的示例） 。 运行 RLVR 被证明提供了极高的性价比（能力/$），这吞噬了原本打算用于预训练的算力 。因此，2025 年大部分的能力进展是由 LLM 实验室消化这一新阶段的“红利”所定义的。总体上，我们看到了模型规模相似但 RL 运行时间长得多的 LLM 。+1…

几十年来，我们都很清楚什么样的代码才算“好代码”。完善的测试。清晰的文档。小而边界明确的模块。静态类型。无需举行一场小型宗教仪式就能启动的开发环境。 这些东西一直都是“可选的”，而在时间压力之下，“可选项”通常最先被砍掉。 但智能代理（agent）却需要这些“可选项”。它们并不擅长先把事情弄得一团糟，再事后清理。代理更像是一台扫地机器人，直接从狗屎上碾过去，然后把脏东西拖得满屋都是。 唯一的护栏，就是你设置并强制执行的那些规则。如果代理所处的上下文不完整，护栏又不够坚固，你很快就会陷入痛苦的境地¹。相反，如果护栏足够扎实，大模型就可以不知疲倦地反复尝试，直到唯一能走出的路径就是正确答案。 我们这个六人团队，为了适配“代理式编码”，做了很多具体、而且有时颇具争议的投入。下面聊聊其中一些不那么显眼，但非常关键的点。 100% 的代码覆盖率 我们最具争议的一条规范，恰恰也是最有价值的一条：我们要求 100% 的代码覆盖率²。 几乎所有人在第一次听到这条规则时都会持怀疑态度，直到他们真正体验上一天。那时你会发现，它有时简直像一件秘密武器。 在我们的语境中，覆盖率并不只是为了防止 bug；它的核心作用，是保证代理已经对它写下的每一行代码的行为进行了“双重确认”。 一个常见的误解是：别人以为我们相信 100% 覆盖率等于“没有 bug”。或者以为我们是在追逐指标，而指标总是会被“刷”。这两点都不是我们的出发点。 为什么一定要 100%？在 95% 的覆盖率下，你仍然需要判断哪些代码“重要到值得测试”。在 99.99% 时，你甚至不知道 ./src/foo.ts 里那一行没覆盖到的代码，是不是在你开始这个新功能之前就已经存在的。而当你达到 100% 时，会发生一次“相变”，所有这些模糊性都会消失³。只要有一行没被覆盖，那一定是你刚刚主动引入的。 覆盖率报告会变成一份简单直观的待办清单，告诉你还有哪些测试需要补齐。这同时也减少了一个需要交给代理去权衡和推理的自由度。 在 100% 覆盖率下，测试带来的杠杆效应会出现一次阶跃式的提升。当模型新增或修改代码时，我们会强制它展示那一行代码是如何工作的。它不能停留在“看起来是对的”，而必须用一个可执行的例子来证明。 还有一些额外的好处：不可达代码会被删除；边界情况会被显式表达；代码评审也变得更容易，因为你能看到系统中每一个部分被期望如何行为、以及将要如何变化的具体示例。 命名空间是个了不起的想法，让我们多用一点吧 代理式工具在你的代码库中进行导航的主要机制，其实是文件系统。它们会列出目录、读取文件名、搜索字符串，并把文件拉进上下文。 你应该像对待任何其他接口一样，认真对待你的目录结构和文件命名。 一个叫做 ./billing/invoices/compute.ts 的文件，即使内部代码完全一样，也比 ./utils/helpers.ts 传达的信息要丰富得多。帮一帮 LLM，好好组织你的文件结构。 此外，尽量使用数量更多、范围更小的文件。 这会改善上下文加载的效果。代理在把大文件拉进工作集时，往往会进行摘要或截断。小文件可以显著降低这种风险。如果一个文件足够短，能够被完整加载，模型就可以在上下文中始终保留它的全部内容。 在实践中，这会加快代理的工作流，并消除一整类性能退化的问题。 快速、短暂、并发的开发环境 在旧世界里，你通常只生活在一个开发环境中。你会在那里精雕细琢解决方案，反复调整，运行命令，重启服务，逐步收敛到最终结果。 而在代理时代，你做的事情更像是养蜂：在不了解每个进程内部具体发生了什么的情况下，协调多个进程的运作。因此，你需要培育一个健康、良好的蜂巢。 快速你的自动化护栏必须运行得足够快，因为你需要频繁运行它们。目标是让代理始终处在一条“短绳”上：做一个小改动，检查它，修复它，重复这个过程。 你可以通过多种方式来运行这些检查：代理钩子、git 钩子，或者仅仅通过提示词（比如在 AGENTS.md 里）。但不管采用哪种方式，你的质量检查都必须足够“便宜”，以至于频繁运行它们不会拖慢整体节奏。 在我们的配置中，每一次 npm test…

没有任何专家能够逃脱“专业能力对数式增长”的曲线。无论是星舰企业号的工程官乔迪·拉福吉少校（前景），还是莉亚·布拉姆斯博士（中景），当然也包括舰载计算机本身（背景）。图片来源：screenrant，wikipedia（本文最初是在 LinkedIn 风格的平台上随手写成的，下面版本略作修订，以便更好地“掌控所有权”和保持理智。） 一切专业能力都是对数增长的，而不是指数增长 星舰企业号的工程官——乔迪·拉福吉少校——几乎就是“使用生成式 AI 的工程师与高管”的原型人物。他时时刻刻都在使用那台由反物质驱动的舰载 LLM，甚至经常在生死攸关的时刻，用它来解决全新、一次性的复杂问题。 但他之所以能如此成功地使用这些系统，并不是因为 LLM 本身多么强大，而是因为他能够识别极其细微的错误，并用自己顶级的训练背景和多年一线实战经验进行补偿与增强。 换句话说，他拥有通过长期磨炼获得的高度专业化的隐性知识（tacit knowledge），而这种知识是任何静态数据语料库——无论多么庞大、详尽——都不可能具备的。品味、判断力和直觉不是天生的，而是后天培养出来的：通过系统训练、刻意练习，以及与现实世界的频繁、剧烈碰撞。是的，是频繁而暴力的现实碰撞。 然而，不论是人类还是计算机，其专业能力的增长都遵循对数曲线：最初进步飞快，持续一小段时间；随后进步放缓但仍可感知；最终，增长几乎变得不可察觉——再多的投入，也难以带来有意义的产出。 换句话说： 专家系统，需要专家用户。 我将这一现象称为：乔迪·拉福吉悖论（The Geordi LaForge Paradox）。 语言模型越大、越复杂，用户自身的世界模型就必须越成熟。只有受过严格训练的放射科医生，才有能力去审视计算机模型给出的影像分类结果。也只有乔迪，才能同时挑战舰载计算机与布拉姆斯博士那种高度专业、深度信息化的判断——因为只有他，是通过唯一可行的方式学会那些真正困难的东西的：那条漫长而艰辛的道路。 而这一科学事实，具有深远的影响。 关于“2030 年及以后”的故事，其实正在当下发生 只是，人们并没有在正确的地方寻找那串“丢失的钥匙”。他们只盯着那根炽热的路灯柱——也就是由核电驱动的、抽象化的大型 LLM 机器。像飞蛾扑火一样，被自己制造出来的引力井所困：既包括情绪与心理注意力上的沉没成本，也包括现实世界中的实际投入。 我对 LLM 技术的乐观判断是： 到大约 2030 年左右，我们将从 Transformer 架构、规模化与压缩中，获得一些并非微不足道的直接收益，例如： 然而，真正巨大的收益将来自间接效应：当 GPU 投资开始“变形”为服务于当今严重被忽视、却足以重塑世界的科学与工业应用领域时。 可以想象这样一个场景：“校园级 GPU 超级计算机，便宜到几乎可以忽略计量成本。” 巨量 GPU 基础设施 → 工业应用的嬗变 我真诚地希望，我们能看到类似历史上铁路、电信或云计算繁荣之后发生的那种局面： 巨额资本投入，通过资产减记、贱卖、破产式并购等方式，重新分配基础设施所有权，从而催生完全出乎意料的工业、经济乃至社会政治现象。 或许（我希望如此），我们会看到数据中心的去中介化：整柜整柜的计算设备被运往私营企业、大学等地方——后院里堆着超级计算机。 一个全新的“Oxide Computer Company”式企业生态，随之诞生。 突破性科学与工业工程，需要“周期时间”的压缩 如果真的进入一个“GPU 便宜到不计成本”的阶段——假设持续十年，直到…

在假期期间，我一直在思考：2025年AI编程工具的进展，将会在2026年如何影响软件的设计、构建与运行方式。 到目前为止，大语言模型（LLM）工具带来的最主要影响，是高质量代码的边际生产成本——无论是时间成本还是金钱成本——都显著下降了。当然，写代码只是软件工程整体工作的一部分，因此工程时间的瓶颈会自然转移到其他环节。 那么，作为软件工程师，我们到底在做什么？给出一个模糊但或许有点用的定义：构建、演进并运营分布式软件系统，从而提供明确的商业价值。在这三点中，“构建”随着LLM的出现明显变得更便宜，“演进”系统也变得更容易；而从我目前的观察来看，“运营”系统受到LLM影响最小。 至于“商业价值”，它会因公司不同、工程组织不同而变化。一个最明显的区分是基础设施团队与产品团队。我预计产品团队会从LLM编程中获得更大的提升——LLM似乎对前端理解得尤其好，而且产品团队往往有更多从零开始（greenfield）的工作，而基础设施则较少。 市场将会期待软件工程师能够真正从LLM中榨取生产力红利。整体来看，这个行业正走向更高度的机械化，但也因此变得更高效。再技能化（reskilling）与思维方式的转变已经加速了几个月，但其大多数影响仍尚未完全显现。 以下是我预计在2026年会进一步加速的一些变化： 基础设施抽象良好的基础设施抽象，其回报会以更快的速度复利增长。你是否能快速发布二进制文件，并同样快速地回滚？你是否拥有开箱即用的方式，能够迅速为所服务的功能启动新的计算资源或后端？ 所有核心基础设施组件仍然至关重要：指标、日志、事故管理、功能开关、发布系统、自动扩缩容、编排、工作流引擎、配置、缓存、网络等等。企业若能让这些核心基础设施既易于人类使用，也易于LLM使用，将会获得巨大收益。基础设施应尽可能做到自助化，提供友好的CLI或支持MCP的API，并尽量减少必须由基础设施工程师亲自介入才能解锁进展的情况，无论面对的是人类还是AI。 CI基础设施随着AI代理编写的代码越来越多，CI基础设施的质量、保真度与速度将变得更加重要。我们或许需要重新思考“单元测试”本身，在技术栈的底层更多投入诸如性质测试（property testing）和形式化验证等方法。 人类通常不喜欢写测试——它们不好玩、机械，而且常常让人觉得是在为本可以用来写炫酷实现代码的精力缴税。但LLM对此毫无心理负担。我们已经没有任何借口不去实现几乎穷尽的测试场景覆盖。 人类引导的抽象清晰、由人类引导的抽象将变得愈发重要。如果没有强有力的指导原则，LLM往往会用贪婪、填空式的方式生成代码，只要能通过CI检查就好，长期来看会不断制造“意大利面式”的代码结构。前期仍然需要良好的直觉与成熟的“系统品味”。模块边界、库接口、基础设施层与产品层之间的契约，这些都会成为维持长期代码质量的高杠杆因素。缺乏清晰边界的系统，将会更快地积累技术债。 LLM生成的代码并不天然等同于高质量代码。尽管过去一年中质量提升显著，但只需几个构造不佳的PR，就依然可能让团队迅速淹没在技术债之中。 人工代码评审人工代码评审将越来越成为一个重要瓶颈，并且需要形成一种新的“评审品味”。在可能的情况下，样式层面的争议应尽量下沉到自动化lint中，在合并前运行，理想情况下甚至由LLM代理在提交前完成。人工评审应当重点关注那些之后无法轻易通过代码生成来弥补的决策：例如接口变更、涉及数据持久化的敏感代码、以及性能关键路径代码，这些仍然需要高度审慎的审查。 这也给初级工程师带来一个悖论：他们需要更早培养“评审品味”，但却在“写代码”这一传统上用于形成直觉的环节中参与得更少。 我们需要集体回答一些问题：哪些代码即便不完美，但在风格上是可以接受的？哪些代码是绝对不允许提交的？哪些是新的“滑坡式”坏味道？代码评审本身，又有多少是可以自动化的？ 项目时间预期的方差上升我预计项目时间预估的方差会显著增大。一项任务在多大程度上可以被LLM化，将越来越直接地影响其实际耗时。这会对高价值项目产生压力，推动它们被设计成更适合LLM参与的形式，但这种调整往往并不可行。 最有价值、也最需要降低风险的项目，往往恰恰是最不适合LLM辅助的：它们需要深厚的上下文理解，涉及底层系统，或者具有极高的爆炸半径。 一些过去需要长期投入的任务现在变得容易得多（例如以代码为中心的迁移，或跨语言、跨系统的转换）；而另一些任务的难度则相对稳定（例如网络相关工作）。 AI对“自建 vs 购买”决策的影响代码成本的下降，会在多大程度上影响SaaS领域的“自建还是购买”决策？我的猜测是：在边际上会有影响，但在结构性上影响有限。对于主要是CRUD加一层薄UI的商品化SaaS，中大型技术公司在具备成熟IT能力的情况下，决策会更多倾向于自建。 但对于基础设施即服务（IaaS）或合规即服务（compliance-as-a-service），决策逻辑不会发生太大变化，因为这些系统的运营成本并未像开发成本那样大幅下降。 一些尚待回答的问题：我们是否仍然需要对每一行代码进行人工审查？这件事到底有多关键？哪些系统需要“放大镜级”的审查，哪些真的可以完全靠“vibe coding”？软件工程师最好的“用更多信息对抗低质量输出（Add bits to beat slop）”方式是什么？当模型变得快100倍、便宜1000倍时，又会发生什么变化？ 一个让我豁然开朗的想法是：在每一条服务日志上运行一个LLM将变得足够便宜。现在这听起来仍然有些荒谬或多余，但可以想象它在某些场景下会非常有用，比如辅助调试事故。我已经开始看到一些很有前景的演示：针对事故排查而设计的、自动化的LLM副驾驶工具。

自从单克隆抗体在阿尔茨海默症（Alzheimer’s Disease, AD）治疗中效果令人失望以来，学界围绕其真正病因的讨论持续升温。许多人在问：“如果不是β-淀粉样蛋白，那是什么？”在癌症中，我们消灭癌细胞；在心血管疾病中，我们降低LDL颗粒，从而显著降低风险。那么，在阿尔茨海默症中，“LDL”对应的是什么？ 作者认为——这个问题没有唯一答案。AD的成因是多因素的（multifactorial），没有单一机制能解释所有病例。每种因素都可能在不同个体中增加患病风险，但都不是决定性的。同时，预防AD与治疗AD应当分开思考： 作者目前在Retro Biosciences公司从事相关研究，但他对阿尔茨海默症的兴趣远早于此。过去在观察AD研究时，他发现其复杂性远超心血管疾病：在心血管病中，LDL升高导致动脉粥样硬化，降低LDL风险显著下降；而在AD中，去除β-淀粉样蛋白并没有同样效果。 一、关于“阿尔茨海默症”的定义 根据阿尔茨海默症协会（AA Workgroup, 2024）的定义：AD的出现以脑内β-淀粉样蛋白（amyloid-β）积聚为标志，此后出现tau蛋白缠结与神经退行性变化。若仅出现tau缠结而无β-淀粉样蛋白，则被归为“与年龄相关的原发性tau病变（PART）”或其他非AD类型。 因此，即使患者认知正常，只要脑中存在大量β-淀粉样蛋白，也会被定义为AD患者。该定义的目的不是“客观”，而是为了在研究与诊断上统一标准。尽管有人批评这是“淀粉样假说偏向”，但这种定义仍有实用意义，因为大多数认知退化病例确实伴随淀粉样沉积。 然而，当抗体疗法能够清除脑内淀粉样蛋白，却仍无法阻止神经退行时，这一定义就暴露出局限：疾病的根本机制显然仍在继续。 二、什么是“成因”？ 作者提出几个常见的“因果”定义，并指出AD都无法完美符合： 因此，与其说AD有单一病因，不如说是多种失衡过程叠加的结果。在多数情况下，是β-淀粉样蛋白的产生与清除失衡，导致其积聚；而炎症反应又会抑制清除机制，使淀粉样越积越多。随着年龄增长，神经细胞对炎症信号更敏感、修复能力更差，最终形成一个“恶性平衡”：细胞持续死亡而缺乏修复。 三、主要风险因素 以下因素都可增加AD的发病几率（非决定性）： 这些因素共同说明：AD不是由“单一病原体”引起的，而是炎症、遗传、病毒感染与衰老交织的产物。 四、病理模型与治疗启示 在许多病例中，病毒或慢性炎症会激活脑内免疫反应，引发β-淀粉样蛋白的生成——后者可能具有抗微生物功能（Gosztyla et al., 2018）。但炎症本身缺乏“精确控制”，随着年龄增长，这种反应会变得过度且持久。 更复杂的是，这种炎症“记忆”可能写入细胞的染色质结构，使细胞即便在刺激消退后仍保持高炎症水平。这解释了为何动物模型疗效良好而人体试验失败——在老年人中，炎症与代谢退化已根深蒂固，单纯清除淀粉样或病毒并不能逆转病程。 因此，Retro Biosciences等团队转向新的策略： 这些方法与过去“清除单一病理物质”的思路不同。过去数十年，研究几乎被“β-淀粉样+tau”药物所主导（Cummings et al., 2024），而现在制药业开始探索炎症调节、细胞复活、代谢重建等多维方向。 五、总结与展望 从遗传学、流行病学与干预研究的综合证据看，AD并无单一“成因”。在疾病尚未发生时，控制风险因素（感染、炎症、创伤等）是可行的预防手段；但一旦疾病启动，再去修改这些外部风险因素的收益极小。 作者在推文中写道：“阿尔茨海默症没有原因（Alzheimer’s has no cause）。”真正的意义是：我们应放弃寻找单一罪魁祸首的执念，转而理解疾病的动态机制——包括细胞老化、自噬衰退、慢性炎症与代谢失衡——并从这些过程入手设计治疗方案。 未来真正有效的疗法，或许不会是“清除β-淀粉样”或“抑制tau”，而是让神经系统重新获得年轻状态与稳态。唯有如此，阿尔茨海默症的治愈才可能成为现实。

“周末属于哲学。”——@ramahluwaliaRam说得对。让我们暂时离开芯片规格表，从更宏观的角度看看我们到底正在见证什么。 本周，Andrej Karpathy发了一条推文，让我震惊： “我从未觉得自己在编程领域如此落后。这个职业正在被彻底重构，程序员能贡献的部分越来越稀疏、零碎。如果我能正确地把现有工具串联起来，我的效率至少能提高10倍。” 这可是Karpathy——打造特斯拉自动驾驶系统的人，仅两个月前他还在Dwarkesh的播客上对现有模型持怀疑态度。如今他却说自己“跟不上了”。发生了什么变化？推理层的能力突破了关键门槛——而且还将迎来更大的飞跃。 同一周，《电子时报》爆料：英伟达（NVIDIA）已向三星、SK海力士、和美光下达16层堆叠HBM的交付订单，计划在2026年第四季度投入量产。这不是研究阶段，而是真实的生产计划。 这两个信号其实是同一个故事的两面。16层HBM、3D堆叠SRAM、英伟达收购Groq的200亿美元授权交易——这些构成了让Karpathy“提升10倍威力”的基础设施。而这也揭示了：AI芯片之战，或许已经结束。 为什么AI正在“饥饿”——记忆的瓶颈 AI模型的增长速度远快于数据供给能力。例如，Llama 3（700亿参数）光是权重就需140GB内存；若使用128K上下文窗口，每个用户的KV缓存需要40GB。并发10个用户？光缓存就400GB。 当上下文扩展至100万tokens时（类似Gemini级模型），单个用户的KV缓存达到约312GB。服务100个用户意味着31TB内存需求。 GPT-4估计有1.76万亿参数，FP16格式需约3.5TB内存；到2028年，10万亿参数模型将至少需要5TB。 99%空转问题 AI推理的秘密是——价值4万美元的H100在解码阶段利用率不到1%。 原因在于算力与带宽的不匹配。H100拥有990 TFLOPS计算力和3.35 TB/s带宽，设计目标是295 FLOPs/字节。但推理解码时，每生成一个token都要从HBM中加载整个模型权重，只执行约2 FLOPs/字节，然后GPU就在等待内存。 训练阶段能达到百倍以上的算术强度，但推理阶段是串行的，核心单元大多在空转。这就是“记忆墙”——也是训练与推理在架构上必须分离的根本原因。 HBM vs SRAM：物理极限 两种存储的取舍如下：HBM（高带宽内存）：容量大（80 GB → 192 GB → 1 TB 预计2027年）、延迟高（100–150 ns），适合训练与大模型权重。SRAM（片上静态存储）：容量小（50 MB → 230 MB），但延迟极低（0.5–2 ns），适合低延迟推理。 问题在于：算力每两年提升约750倍，而内存带宽仅提升1.6倍。结果是，从V100到H100，计算与带宽比翻倍，使GPU在推理任务上越来越“力不从心”。 关键拼图 1️⃣ 16层HBM之战英伟达要求在JEDEC 775 μm封装高度内堆叠16层DRAM。这意味着晶圆要薄至30 μm，层间键合小于10 μm，热管理几乎没有工业先例。三星、SK海力士、美光正拼命攻关。胜者将在2028年前占据500亿美元年营收市场。 2️⃣ SRAM扩展的物理极限SRAM密度几乎停滞，N3E与N2制程提升有限。Groq的LPU通过230 MB SRAM实现80 TB/s内部带宽，在Llama 3.3 70B上每秒生成276 tokens（GPU仅60–100），但要容纳整个模型需576颗芯片、8个机柜。 3️⃣…