AI TrendTrackers

在过去大约十年里，当一名开发者……可以说是相当舒服。 如果你在过去 10 年的任何时候热爱开发者这份工作，那你基本就是活在梦里。高薪。机会无穷。你解决问题、交付代码，然后拿到相当不错的报酬。你不用太操心公司为什么存在、钱怎么赚。你是建造者。这样就够了。 但就像所有美梦一样，它也有到期日。 AI 时代登场到 2025 年，AI 不再只是玩具，开始变成一个真正的同事，更像是一个初级到中级的开发者。 它还不是替代者（至少现在还不是），但绝对是一个搅局者。“我会写代码”的护城河正在快速缩小。写代码不再稀缺，也不再神奇。它正在变得更便宜、更快，而且每个月都更容易被更多人做到。 以现在的速度，谁知道到 2026 年底我们会走到哪里。但有一件事已经很清楚：单纯的技术执行能力，本身已经不再是长期优势。 这听起来很吓人。刚开始确实如此。 好消息AI 是一种倍增器。而且难得的是，它不是那种被锁在企业级付费墙后面的能力——每个人都能用上。 普通开发者现在可以比以前交付更多东西。优秀开发者突然能交付以前根本做不到的东西，甚至用他们从未学过的语言。软件整体的门槛正在提高，而真正的赢家（希望如此）会是用户。 就我个人而言，我现在的交付速度前所未有，而且我也享受使用 AI。今年我对 SaaSykit 的计划，比 AI 出现之前我现实中能做到的多得多。这就是机会所在。 但这里有个前提条件。 当每个人都能更快地构建时，“只会构建”本身就不再够了。 那你该怎么保持自己的价值？ 你不需要停止当开发者。你需要停止“只当开发者”。 1. 业务领域知识是你的新盔甲多年里，很多开发者会很自豪地说：“我专注写代码。做生意的事交给业务的人就行。” 很遗憾，这种策略已经不成立了。 理解你所构建的业务，现在是一种非常强的竞争优势。不是“泛泛了解”，而是“深入理解”。 指标、激励机制、约束条件、客户、合规监管，这些不性感的东西——都算。 我和无数聪明绝顶的工程师共事过，他们拒绝关心领域知识。他们的编码能力很强……也因此很容易被替代，而且现在比以往任何时候都更容易。 把这种人和另一个开发者对比一下：后者真正懂得，比如说，金融科技（fintech）。不只是懂 API 和数据结构，而是懂为什么要那样构建、懂行业黑话、懂监管者在乎什么、懂公司到底在哪里赚钱。把这样的开发者放进另一家金融科技公司，在入职文档还没看完前，他/她就能开始产出。 AI 在写代码、搬运代码方面会变得异常强。但商业依然是由人构成的——人们的激励、恐惧、约束与政治。那一层很混乱、很情绪化、很依赖上下文，而那正是人类（你）仍然真正占优势的地方。 2. 变得更宽，而不只是更深很长一段时间里，建议非常简单：更努力地专精。 学会那个框架。精通那套技术栈。往深处钻。 深度专长依然有价值，但它本身已经不足以保护你。 后端工程师：你不必成为设计大师；前端工程师：浏览器也只是故事的一半。现在，从 A 到 Z 进行全栈思考（也真的做出来）比以往任何时候都更容易。你也不需要什么都懂——AI 可以替你补齐空白。 而且，懂 DevOps、安全、性能、可靠性，能让你的应用真的活着，也能让你保持价值。AI 可以整天疯狂产功能，但它无法处理线上事故、无法在半夜补安全洞、也无法保证你的应用对真实用户真的能用。能管理运行软件过程中那些混乱且不可预测问题的开发者，才是最难被替代的那群人。 别把视野停在代码里。像产品人一样思考。理解一点营销基础，让你的成果真的能被人看到。写得足够清楚，让别人读你的东西不用眯着眼。是的，也要学会跟用户沟通，而不是一开口就紧张到崩溃。这些技能可能不在你的岗位说明里，但当 AI 能写代码时，它们就是你保持相关性的关键。…

对大型语言模型（LLMs）的一个常见批评是：它们可能会剥夺我们的认知能力。典型的论点是，把某些任务外包出去，很容易导致某种形式的心智能力退化。关于这种说法在多大程度上成立，神经科学家、心理学家以及其他领域的研究者仍在持续讨论，但对我而言，“某些技能如果不用就会退化”这一理解在直觉上和经验上似乎都是合理的。 更相关的问题在于：是否存在某些使用方式比其他方式更好或更糟？如果是这样，哪些方式更好，哪些更糟？在博客文章《认知总量谬误》（The lump of cognition fallacy）中，Andy Masley 对此进行了详细讨论。他切入问题的方式，是质疑“思考的总量是固定的”这一观念，以及它如何导致人们得出这样的结论：把“思考外包”给聊天机器人会让我们变得懒惰、更不聪明，或者在其他方面损害我们的认知能力。他将这种观点类比为经济学中的一个误解，即认为经济中只有有限数量的工作需要完成，这通常被称为“劳动总量谬误”（the lump of labour fallacy）。他的看法是，“思考往往会引出更多需要思考的事情”，因此我们不必担心让机器替我们思考——我们只是会转而去思考别的事情。 阅读 Masley 的博客文章促使我把自己长期以来反复思考的一些想法写下来。我意识到，以他的文章作为参考和出发点可能是有建设性的，因为其中包含了这一讨论中经常被提及的论点。我将使用他文章中的一些例子，来说明我在这些问题上的不同看法，但我会把讨论范围扩展到“思考总量有限”这一所谓的谬误之外。我已尽力让这篇文章在不需要事先阅读 Masley 的文章的情况下也能理解。我的目的并不是反驳他的所有论点，而是解释为什么这个问题远比“思考往往会引出更多思考”要复杂得多。总体而言，这篇文章的目的，是指出“外包思考”这一做法中存在的一些关键问题。 什么时候我们应该避免使用生成式语言模型？是否有可能界定某些活动类型，在这些活动中使用 LLM（通常以聊天机器人的形式）弊大于利？Masley 列出了一些在他看来显然不应当外包思考的情形。为了完整地描述我自己的观点，我将冒昧引用他列表中的这些条目。他写道，当外包认知行为符合以下情况时，这是“不好的”： —— 会构建你未来在世界中行动所需的复杂隐性知识。—— 是对他人关怀与陪伴的一种表达。—— 本身就是一种有价值的体验。—— 伪造它具有欺骗性。—— 聚焦于一个至关重要、必须做对的问题，而你又无法完全信任你外包对象的时候。 让我感到惊讶的是，尽管我们在其他方面持有根本不同的观点，但在这份清单上，我们在很大程度上是达成一致的。我认为分歧主要在于：究竟有多少活动会落入上述这些类别之中，尤其是其中的三个。 个人交流与写作让我们从“伪造它具有欺骗性”这一点开始。Masley 使用了这样一个例子： “如果有人在约会软件上给你发消息，他们想知道真实的你是什么样的。” 这一点当然非常正确，但在我看来，不仅仅是在这样亲密或私人的情境中，伪造“你是什么样的人”才具有欺骗性。个人交流本身就是一个非常重要的领域，在这里，我们如何表达自己，对我们自身以及我们交流或写作的对象都至关重要。当我们彼此交流时，整个互动都被某些隐含的期待所框定。让我们的措辞和表达被机器所改写，实际上是对这些期待的一种破坏。我们所选择的词语，以及我们构造句子的方式，承载着大量意义；如果我们让语言模型污染这种类型的互动，直接交流必然会受到损害。直接交流不仅仅关乎信息的交换，它同样关乎交流者之间的关系，而这种关系正是由“我们是谁”以及“我们如何表达自己”所塑造的。 我认为，这一点不仅适用于人与人之间的交流，也适用于那些有明确个人作者、面向人类读者的文本。在一定程度上，同样的原则依然成立。最近，挪威媒体中就未披露使用 LLM 进行公共写作的问题展开了讨论，各种指控和观点四起。我非常高兴看到这场讨论进入公共视野，因为在聊天机器人被如此广泛使用的当下，我们确实需要澄清自己对交流的期待。尽管我个人非常清楚地认为，人与人之间的交流应当尽量避免经过机器转换这一中间步骤，但并非所有人都持有相同看法。如果未来我们的书面交流大多将由 AI 模型“共同创作”，那么我们就需要意识到这一点，并相应地调整我们的期待。一些人已经开始在写作中披露自己是否使用了 AI，我认为这是朝着更好理解 LLM 使用方式迈出的重要一步。知道一篇文本是由人类独立写成，还是由 LLM“共同创作”的，会对读者如何看待它产生重要影响；假装不存在这种差异，本身就是不诚实的。 许多人将 LLM 视为一种巨大的福音，认为它们可以帮助人们更清晰地表达自己的观点，尤其是那些不是使用母语写作的人，或有学习障碍的人。只要意义源自于人，LLM 就可以帮助用正确而有效的语言表达这种意义。对此我有两个主要反对意见。第一个关乎文本本身会发生什么：在大多数情况下，几乎不可能将意义与其表达方式分离开来。这正是语言的本质——词语本身就是意义。改变措辞，就会改变信息。第二个反对意见关乎我们自身会发生什么：我们剥夺了自己在没有“辅助轮”的情况下成长和学习的机会。LLM 确实可以帮助人们改进文本，但当把措辞完全交给 AI 模型时，思考过程——也就是发展想法的过程——将被严重截断。它们很快就会从“帮助”变成“替代”，从而剥夺我们发现自己声音的机会，也剥夺我们探索“当我们真正独立站立时，自己可以成为谁、变成谁”的可能性。 在极其谨慎的情况下，人们或许能够使用聊天机器人而不受到这两个问题的影响，但问题在于：在 LLM 的使用中，从“获得拼写或语法方面的帮助”到“让模型基本上替你写作”之间的界线异常之薄。以当前聊天机器人和基于 LLM 的工具设计方式，这一点几乎无法避免；从传统的自动更正到生成式语言模型，这一步跨得实在太大了。如果我们真的设想 LLM 是一种帮助人们提高写作能力的工具，那么我们就需要一种比当下聊天机器人更加审慎、更加周到的界面设计。 与此同时，我也意识到，许多人持有更加功利主义的态度。他们只是想把事情做完，完成工作，提交报告，递交投诉，回复邮件，用尽可能高效的方式，然后继续他们的一天。借助…

编程工作流。鉴于最近一轮大语言模型编程能力的明显跃升，和许多人一样，我在极短时间内完成了一个非常陡峭的转变：11 月时，我大概还是 80% 手写代码 + 自动补全、20% 使用代理；而到了 12 月，已经变成了 80% 代理编程、20% 编辑和修修补补。也就是说，我现在基本上是在用英语写程序了——有点不好意思地用“人话”告诉 LLM 要写什么代码。说实话，这对自尊心有点伤害，但能够以“大块代码动作”的方式操控软件，整体收益实在太高了，尤其是在你逐渐适应它、配置好它、学会如何使用它，并真正理解它能做什么、不能做什么之后。这无疑是我将近二十年编程生涯中，对基础编程工作流影响最大的一次变化，而且它是在短短几周内发生的。我预计，现在已经有相当一部分工程师（很容易达到两位数百分比）正在经历类似的转变，而这种变化在普通大众中的认知度，却仍然停留在个位数的低水平。 IDE / 代理蜂群 / 易错性。在我看来，现在无论是“已经不需要 IDE 了”的炒作，还是“代理蜂群”的炒作，都有点言过其实。模型确实仍然会犯错，如果你在写任何你真正关心的代码，我都会建议你像鹰一样盯着它——在旁边开一个清晰、完整的 IDE。错误的类型已经发生了很大变化：不再是简单的语法错误，而是那种略显草率、赶时间的初级开发者可能会犯的概念性错误。最常见的一类问题是，模型会替你做出错误假设，然后毫不质疑地一路跑下去。它们不擅长管理自己的困惑，不会主动寻求澄清，不会指出不一致之处，不会展示权衡取舍，在该反驳的时候也不会反驳，而且仍然有点过度迎合用户。在 plan 模式下情况会好一些，但我觉得还需要一种轻量级的、内联的 plan 模式。它们也非常喜欢把代码和 API 过度复杂化，抽象层次膨胀，不会在完成任务后清理死代码，等等。它们可能会用 1000 行代码实现一个低效、臃肿、脆弱的结构，而你必须提醒一句：“呃，这里不能直接这么做吗？”然后它就会说：“当然可以！”并立刻把代码压缩到 100 行。它们有时还会作为副作用，修改或删除自己“不喜欢”或“没完全理解”的注释和代码，即便这些内容与当前任务并不相关。所有这些问题，即使我在 CLAUDE.md 里用了一些简单指令试图纠正，依然会发生。尽管如此，这依然是一次巨大的正向提升，几乎无法想象再回到纯手写编码的状态。简单总结一下：每个人都在形成自己的工作流，我目前的配置是——左边在 ghostty 的窗口/标签里开几个 CC 会话，右边开 IDE 用来查看代码和进行手动编辑。 韧性。观察一个代理不知疲倦地啃一个问题，真的非常有意思。它们永远不会累，永远不会泄气，只会不停地尝试，而人类早就会在很久之前放弃、留待下次再战。看着它在一个问题上挣扎很久，最后在 30 分钟后取得胜利，是一种“感受到 AGI”的瞬间。你会意识到，耐力本身是工作中的一个核心瓶颈，而有了 LLM 之后，这个瓶颈被极大地抬高了。 加速效应。要如何衡量 LLM 带来的“速度提升”，其实并不清楚。当然，我确实感觉自己在原本打算做的事情上快了很多，但更主要的效果是：我做了大量原本根本不会去做的事情。原因有两个：第一，我现在可以去实现各种以前完全不值得花时间去写的东西；第二，我可以去接触、处理一些以前因为知识或技能不足而完全无法下手的代码。所以这当然是加速，但更像是一种扩张。 杠杆。LLM 非常擅长在循环中反复尝试，直到满足明确的目标，这正是大多数“感受到 AGI”的魔力所在。不要告诉它具体该怎么做，而是给它成功标准，然后看着它自己去跑。让它先写测试，再让它把测试跑通；把它接入浏览器 MCP 的循环里；先写一个极有可能正确但朴素的算法，然后再要求它在保持正确性的前提下进行优化。把你的思维方式从命令式转为声明式，让代理跑得更久，从而获得更大的杠杆。 乐趣。我原本没想到，用代理编程反而会变得更有趣，因为大量填空式的苦差事被移除了，剩下的主要是创造性的部分。我也更少被卡住（而被卡住一点都不好玩），而且会感到更有勇气，因为几乎总能找到一种方式与它并肩作战，取得一些正向进展。我也见过完全相反的感受；LLM…

最近我和妻子需要叫一辆车，于是掏出手机，用几个打车应用对比价格。平时价格总会有一点差异，但这一次的差别却格外明显。 我妻子的 Uber 应用给出的报价是 28 美元，而我的却是 47 美元。同一个应用、同一时间、同一地点——却是两个天差地别的价格。 原因谁也说不准。我通常比她更愿意花钱，我敢打赌这一点体现在我的用户画像里。我是用礼品卡付款的，这肯定也有影响。也许是价格抓取更新、比价行为识别，或者某种先抛出“试探性高价”、再慢慢回落的系统。从外部来看，没人真正知道。 这正是让我担心的地方。当价格基于行为来决定时，它会激励我们进行表演式的行为——毕竟，爱吱吱作响的轮子才会被上油。 为不同的人收取不同价格并不新鲜 价格歧视几乎自古以来就存在——比如老年折扣，或者优惠券手册。商家可以通过选择性地给那些愿意多走几步、否则可能不会购买的人降价，从而多赚一点钱。 （想象一张经济学需求曲线图：有 4 个人愿意以 10 美元的价格购买，另有 1 个人只愿意以 9 美元购买。图中文字写着：折扣在蓝色区域捕获了 9 美元，而不影响绿色区域的 40 美元。） 在这个简化的需求曲线中，如果价格定为 9 美元，商家总共只能赚 45 美元。但如果对大多数人定价 10 美元，同时给那位价格敏感的“蓝色买家” 1 美元的折扣，商家就能赚到 49 美元。 基于行为的差别定价也并不是什么新做法。当你的网络服务商告诉你他们要涨价时，你会直接接受吗？还是会打电话给客服、排队等待、威胁要取消服务、被转接到“挽留部门”，然后才发现原来你“符合条件”享受一些令人兴奋的新折扣？并不是每个人都有时间或耐心跑完这一整套流程——而这正是企业这么做的原因。 当价格歧视进入数字世界时，单个案例本身并没有什么不同。但正如那句被归于斯大林的名言所说：数量本身就具有一种质的变化。技术带来的不仅是数量，还有无处不在——任何一丁点行为背景，都可能被纳入你的定价之中。 无处不在的价格歧视，其基础已经就绪 与现实世界不同，每一次数字化行为都可以被低成本地记录和分析。 一个例子就是“放弃购物车”折扣，这已经标准到 Shopify 和 Etsy 都为卖家提供了手把手的设置指南。如果你把商品加入购物车却没有结账，之后可能会收到一封提醒邮件，附带一个小折扣，推你一把完成购买。知道了这一点之后，我发现自己即便一开始就觉得价格合理，也会刻意放弃购物车，碰碰运气，看看会不会冒出个折扣来。 如果你尝试取消 Amazon Prime 会员，他们会让你穿过一连串网页和优惠，竭尽全力把你留下。上一次我取消一个小众 SaaS 工具时，也惊讶地看到了同样的流程：再免费用一周？一个月只要一美元？求你别走！我没想到一家小公司也能有这种复杂程度。当然，这并不是 100% 定制的结果——而是 Churnkey 的功劳，这是一家“留存自动化”公司，把经典的“求你别取消”的折扣流程做成了标准化产品。…

MCP 已死，技能万岁！ 最近关于 MCP 的各种误解让我有点烦，所以我决定写下这篇文章，尽量帮大家理清一些概念。让我们来拆解一下 MCP、Skills、Commands、Agents（及 Sub-Agents）。 如果你还没跟上最近的热潮：现在大家都在讨论 “skills”（技能）——这其实只是对类似 Claude Code 那样东西的一个华丽称呼。像往常一样，很多人一见新概念就宣布它能解决所有问题，所有旧技术都可以丢掉了。显然，这不是真的。本文我会分享我对它们的看法。 一、定义（Definitions） 我们先统一一下概念： Skills（技能） 是可复用的提示（prompt），可以附带脚本或其他文件等资源。系统通常会在提示开头告诉模型： 这些技能只在系统提示中以名称与描述形式出现，真正的内容（如 SKILL.md）在需要时才被“加载”（即动态插入对话上下文）。 技能可以捆绑其他辅助内容，比如脚本或说明文档。一般来说，它们在系统提示中占用的上下文非常少。 Tools（工具） 是另一类功能扩展。它们像函数调用一样暴露在代理（agent）中，比如： 工具的实现方式各不相同，可以在提示中立即暴露，也可以按需加载。工具通常比技能多占一些上下文 tokens，但差距并不大。 MCP（Model Context Protocol） 是一个“被过度设计的协议”。它能做的事情很多，但多数人只用它来把 RPC 暴露为工具（tools）。 举个例子，Sentry 的 MCP 服务器可以暴露十几个工具，其中有一个其实是一个子代理（sub-agent）。它们最终都注册为“工具”，但作用完全不同。 Agents / Sub-agents（代理与子代理）代理本质上就是被当作“工具”的独立智能体。例如 Sentry 的 MCP 暴露了一个 use_sentry 子代理，它可以访问所有 MCP 工具，但对主代理来说，它只是一个工具。 代理的优势在于上下文是隔离的——但这也是缺点。这意味着调用代理时必须把所需上下文作为参数全部传入。 有些实现会自动继承上级上下文，有些会延迟加载，还有的甚至能实现上下文分叉与复杂协作。 到这里，应该都能跟上了吧？希望没有什么有争议的。 二、Skills（技能） 你可能注意到定义中“技能”和 “MCP 工具” 看起来很相似。没错！两者都是为了让代理拥有更多能力。区别主要在于实现方式与使用场景。 最近大热的 Skills，本质上是把常用任务模板化、可共享化。比如常见任务：“简化这段代码”，或者更复杂的，“创建一个 Pull…

上个月，我帮一个朋友把他的 LLM API 成本削减了 80%。 他是一个非技术出身的创业者，正在打造一个由 AI 驱动的业务。和大多数人一样，他选择了 GPT-5，因为它是默认选项：API 已经有了、基准测试数据不错、大家都在用——那还用考虑什么呢？ 但随着使用量增长，他的账单也涨了。仅 API 调用费用就达到了 每月 1500 美元。 于是我们针对他的实际提示词（prompts）对 100 多个模型 进行了基准测试。很快我们发现，虽然 GPT-5 表现稳健，但几乎从不是最划算的选择——总能找到成本更低、质量相近的替代方案。找到合适的模型后，他节省了上千美元。以下是我们如何做到的。 问题：公开基准无法预测你自己的任务表现 选择 LLM 时，大多数人只是挑一个熟悉的服务商。比如我习惯用 Anthropic，根据任务选择 Opus、Sonnet 或 Haiku。稍微讲究点的，会查查各种排行榜：Artificial Analysis、LM Arena、GPQA Diamond、AIME、SWE Bench、MATH 500、Humanity’s Last Exam、ARC-AGI、MMLU…… 但让我们面对现实：这些指标并不能预测模型在你具体任务上的表现。 一个在推理类 benchmark 中得分最高的模型，可能在损害费用估算上表现平平，或在多语言客服、网页数据提取等方面完全不行。 它们充其量只能作为“粗略参考”，而且完全没有考虑成本。 唯一真正知道性能的方法，就是在你自己的提示词上测试，同时考虑质量、成本和响应延迟。 自建基准测试 为了弄清楚这一点，我们自己搭建了基准系统。以下以一个客户支持场景为例： 步骤 1：收集真实示例 我们通过 WHAPI 提取了真实的客服对话：包含历史聊天记录、客户的最新消息，以及朋友实际回复的内容。他还提供了手动与自动生成的提示模板。基于此，我们选取了约 50 个聊天案例——既包括常见问题，也包含希望模型能正确应对的特殊情况。 步骤 2：定义预期输出 每个示例的“理想答案”就是朋友实际回复的内容。我们还定义了具体的评分标准，例如：…

在进行数据库优化时，开发者往往会拿出那套老工具箱：改写查询、在列上加索引、做反规范化、执行 analyze、vacuum、cluster，然后重复这一过程。这些传统手段确实有效，但有时候，如果能跳出常规思路，创造性地思考，往往能获得意想不到的优化效果。 本文将介绍 PostgreSQL 中一些非常规的优化技巧。 图像来自 abstrakt design 目录 基于 Check 约束消除全表扫描 假设我们有一个用户表： 这个表保存用户的姓名以及他们使用的套餐类型。由于套餐只有 “free” 和 “pro” 两种，我们添加了一个检查约束。 生成一些数据并分析表： 现在系统中有 10 万个用户。 无心之失 现在你要让分析师通过报表工具访问这张表。你为某位分析师开通了访问权限，他写了第一条查询： 查询结果为空，这让分析师感到困惑：怎么会没有 “Pro” 套餐的用户呢？ 原来套餐名是 “pro”，而不是 “Pro”。这是个很常见的误会。但这个小错误代价不小。 执行计划如下： PostgreSQL 扫描了整个表！但是我们有个检查约束规定 plan 只能是 ‘free’ 或 ‘pro’，数据库理应知道这个条件永远为假，为什么还要扫描呢？ 使用 constraint_exclusion PostgreSQL 其实能做到跳过永远为假的查询，但默认没有开启。要让 PostgreSQL 在生成执行计划时考虑约束，需要打开参数 constraint_exclusion： 再次执行同样的查询： 这次 PostgreSQL 直接跳过了表扫描，因为它知道该条件永远为假。 何时使用 constraint_exclusion 默认情况下，constraint_exclusion 仅对基于继承的分区表启用，以支持“分区修剪”。如果全局开启，会带来明显的规划开销。 文档解释说，对于简单查询，评估所有约束条件的代价可能高于它带来的性能收益。但在 BI…

在软件开发领域，最稳健的职业发展路径通常包括两点：（1）在解决问题时务实且高效；（2）不要把现有代码当作“黑箱”。 第一点意味着，作为一个稳健的开发者，你应该会熟练地使用现有的技术栈，比如 PostgreSQL 或 MySQL（或其他数据库）、Rails 或 .NET（或其他框架），并且懂得借鉴来自 Stack Overflow 或大型语言模型（LLMs）的代码。第二点则意味着你要有好奇心，愿意随着时间的推移去深入理解网页服务器、数据库、操作系统和浏览器的工作原理。这样，当你在借鉴他人代码和思路时，才能做出更好的判断与调整。 从更宏观的角度看，借助 LLM 编程，本质上与使用 Rails 或在 Stack Overflow 上查找代码并无根本不同。它更快、更直接，但归根结底仍是人类在“改写现有代码”。 那些只愿意把现有框架、库或应用程序当作黑箱看待的人，本来在求职与留任方面就不具竞争力。而那些真正有技术深度的公司，总是倾向于招聘理解基础原理的开发者，因为他们要么：（1）在足够大的规模上运行，应用程序的实现方式会直接影响性能与稳定性；要么（2）他们本身就在构建 PostgreSQL、MySQL、Rails、.NET、Stack Overflow 或 LLM 等底层技术。 软件行业的发展一直遵循一个方向——持续降低中小企业（SMBs）乃至大型团队雇佣开发者以解决问题或提升效率的需求。LLM 的出现只是这场“自动化进程”的延续。但这并不意味着企业就不再需要开发者。当业务复杂度或客户规模扩大到一定程度时，企业仍然必须招聘开发者来支撑系统的成长。 那些依赖软件基础原理的工作，不会因为 LLM 的普及而不再依赖这些原理。相反，随着越来越多非开发者开始使用 LLM 来构建工具、系统与应用，真正懂得软件底层原理的工程师反而会变得更重要——因为他们将承担维护、优化、扩展这些基础系统的责任。 总而言之，如果你热爱软件开发，不必担心“有趣的开发工作”会消失。继续学习，继续动手——去编译器、数据库、操作系统这些核心领域探索；去寻找那些因为规模或复杂性而需要扎实基础的公司；或者去挑战那些在底层上构建未来的团队。真正有趣的工程，总是存在于那些让基础原理再次重要的地方。

“所有干净的家都相似；而每个凌乱的家则各有各的混乱。” 2017 年，来自 Nest 与 Flutter 的资深工程师 Navneet Dalal 与 Mehul Nariyawala 环顾四周，发现当时有超过 200 家自动驾驶汽车创业公司，却没有任何一家认真致力于解决家庭中最重复、最耗时的事务。家庭成员花在家务上的时间是驾驶的三到四倍，而我们拥有的只是那些圆盘状、只会撞家具的机器人。受到《杰森一家》中家用机器人 Rosie 的启发，他们萌生了一个不同的愿景——打造一款能理解、能导航、能在我们杂乱、复杂、却又极具私密性的生活空间中自主清洁的家庭机器人：Matic。 走进加州山景城的 Matic 总部，首先映入眼帘的是一面美国国旗，接着是约七十台桌面电脑前忙碌的工程师、实习生与生产助理。地面上摆放着多个用于测试和演示的 7 英寸地面机器人，它们在由木板分隔、铺有地毯与家庭障碍物的不规则方格中穿梭。墙上的大屏幕显示着“清洁总面积（百万平方英尺）：54.0”“上周活跃机器人数量：2160”等数据。墙上还挂满了满意客户的感谢信。Mehul 指着那些与 Matic 一起成长的孩子与宠物说：有个小女孩曾经害怕机器人，直到他们寄给她一个更小的玩具版本，她用贴纸装饰了它。如今的 Matic 随机附送“可爱装饰贴纸”。 往右拐是食堂，侧墙上有一面“时间线墙”，展示着从 2018 到 2025 的原型与照片。“我们快没空间了，也许得把整个房间都变成时间线墙。”Mehul 半开玩笑地说。更往里走，是生产区。那里同样悬挂着美国国旗。员工大多在现场走动作业，一排排 Matic 正在不同阶段装配——有的已停用，有的待发货，有的半组装状态。这里的房间用于测试不同环境（炎热、潮湿、寒冷）、噪音等级与镜头调校。另一间房间正进行面试，外面摆满了 NVIDIA 计算机，用于运行 1500 个虚拟家庭环境的仿真。整栋单层建筑里有上千台 Matic，因当月摄像头发货延迟，停在装配流程的第四步。 Matic 体验当客户订购 Matic 时，不需要自己把它从箱子里拿出来——它会自动滑出并向你问好：“你好，Arena Mag！”或者“你好，[你的姓氏]。” 机器人会像初到新家的访客一样先进行探索。你可以通过应用程序控制它。它会在 15–20 分钟内完成一栋约 3000 平方英尺的住宅的三维建模，学习房间布局、地板类型、地毯、电线与常见障碍。用户可以为各个房间标注名称——厨房、客厅、卧室——然后通过应用精确指示它清扫或拖地的位置。如果遇到地毯，Matic 会自动避开，不会误拖。整个过程无需过多干预。 建图并非一次性操作。就像常来你家的客人会越来越熟悉环境一样，Matic 会不断更新认知。如果搬家，也只需重置或让它重新建图即可。它能轻松识别新环境并管理多层空间。 更令人惊讶的是，它能在黑暗中工作。机器人配备了 RGB-IR…

构建软件的入门门槛已坍塌，但要构建“有意义的东西”的门槛一寸未移。 Claude Code 和 Claude Opus 4.5 把油直接泼进了火里。LLM 工具以前就有，但现在比以往任何时候都更好，所以更多人开始关注。不过我们并没有进入 SaaS 的黄金时代。我们正进入一个“个人、一次性软件”的时代——工程从“写代码”转向“塑造系统”，也正因如此，工程师仍然不可或缺。 现代开发的转向Claude Code 最近铺满了我的信息流，而且理由充分。有趣的不只是开发者都在用它——而是此前依赖 Lovable 或 Replit 这类平台的“构建者”和 maker 们，正在迁移到它上面。 别误会，那些工具仍然非常适合快速交付。但我们正在见证一个清晰的转变：人们重新发现了以 CLI 为先的工作流本身的优雅。一旦把交互移到终端里，抽象层就被压薄了。你不再只是沿着托管式 UI 的“幸福路径”往前走；你在亲手掌舵。 入门门槛的崩塌人们实际上在用这些工具做什么？环顾四周，答案是：几乎什么都做。事实上，我们已经来到饱和点。一方面，我们真切地见证了软件创造的民主化。入门门槛几乎消失。史上第一次，非开发者不只是软件的消费者——他们是自己工具的建筑师。 过去，如果你有一个特定问题，你会花好几个小时去找一款能解决 80% 需求的 SaaS。今天，工作流变了。人们打开一个 CLI 或语音界面，直接描述自己需要什么。我们正在看到“个人软件”的激增： 一款按特定预算方式量身定制的订阅跟踪器一个只解决某个极其小众数据录入问题的 Chrome 扩展一个界面完全按照用户心意设计的健身应用这是一场巨变。软件正从“你购买的商品”，变成“你生成的个人效用”。 从 SaaS 到“草稿本”我们正进入一个新的软件开发时代，其目标并不总是“长寿”。多年来，行业痴迷于构建“平台”和“生态”，但潮水正在转向更为短暂的东西。我们正从 SaaS 转向“草稿本”（scratchpads）。 许多新软件就不是为了永远存在。事实上，恰恰相反。人们越来越多地构建只为一次性解决单一、具体问题的工具——然后把它丢弃。这是一次性效用型的软件，为“当下”而设计，而非遥远的“以后”。 让这一切今天变得可行的是一种具体的技术哲学：CLI 优先、数据本地、零上手成本。当你移除注册、配置数据库、或穿行复杂 UI 的摩擦，构建一个工具的成本就低到“临时性”反而成了特性，而不是缺陷。如果花五分钟就能为一次性任务做出一个定制方案，你就不需要它长久存在。 这与传统 SaaS 模式形成了鲜明对比。SaaS 天生就是为留存、锁定与扩张而优化的。它的商业模式是把你留在生态里并扩大你的足迹。反之，定制化的小工具追求的是即时性和掌控。它们不关心你作为客户的生命周期价值；它们只关心把眼前的任务办成。 在很多方面，这也是对电子表格最初用法的回归。你不会打开表格去构建一个永久、跨多年的数据库；你把它当草稿本，用来推理问题、算出结果，然后继续前行。 在这个新格局里，Claude Code 对开发者而言就像 Excel——一件强大而灵活的即刻解决问题的工具——而不是对创业者而言的 Shopify，那是为了成为业务的长期地基。它关乎把事情做成，然后让工具退场。…