AI TrendTrackers

是否可能发布得太多——或者太快？ 是的。大概是的。遗憾的是。 如今，只需要少数几个判断力不错、而且拥有大量 token 的人，就能完成过去需要整个产品组织才能完成的工作。结果是，由大语言模型（LLM）驱动的软件，比历史上任何时候都更便宜地被构建、也更快地扩展。 然而，一旦跨过某个阈值，产品速度就不再继续复利增长，而是开始彼此竞争。此时，限制你的不再是“你能发布多少新东西”，而是“你的用户能够吸收和采用多少”。 作为一家痴迷于快速发布的公司，我们对这个问题体会得非常深刻。因此，我想分享我们正在如何应对它，希望你也能从中受益。 约束理论（Theory of Constraints） 由于 PostHog 是一款工作工具，而不是生活方式品牌，即便是最狂热的用户，也不可能每周采用无限多个新功能。 在实践中，B2B SaaS 用户的采用节奏通常是： 其他一切，都会被忽略，直到有人明确解释清楚“为什么它重要”。这正是一个典型的瓶颈。 幸运的是，瓶颈是有解法的。制造业早已发现这一点，并将其总结为一个概念：约束理论（TOC）。其中有一条原则在这里尤其关键： 当上游产出增加，但下游能力没有相应提升时，系统就会失稳。 在我们的场景中，这种失配表现为： 当你意识到这一点，TOC 还能帮助你理解这种能力错配会带来哪些具体后果。 当发布速度超过采用速度时，会发生什么？ 1. 队列堆积 在制造业中，这种情况表现为库存积压；在软件中，它会形成一个“隐形待办清单”——你的工作已经完成了，但在“用户认知与理解”层面却尚未完成。 结果是影响力被稀释：发布了大量进展，但用户真正感受到的进展却更少。 2. 价值实现时间被拉长 随着这个隐形积压不断扩大，从“功能可用”到“真正有用”之间的时间差持续拉长。 你的团队不断发布新代码，但每一个新能力都需要更久才能被用户理解并真正使用。用户逐渐跟不上变化节奏；支持与销售花更多时间解释背景；市场营销开始追赶发布，而不是放大它们的影响。 3. 产品质量开始退化 当瓶颈被过载时，质量会通过被迫的权衡而下降。 在软件中，这种退化表现为： 你的产品不断变大、变强，但并没有成比例地变得更清晰。 那是不是意味着应该慢下来？ 绝对不是。 放慢速度，是公司在“没想法了”时才会做的事，而显然这并不是问题。幸运的是，约束理论对“不该做什么”说得也非常清楚： 提升非瓶颈环节，是在浪费资源。真正能改善系统的，是抬升瓶颈本身。 产品采用是一件“一个人一次”的事情，而每个用户的认知带宽都是有限的。所以真正的问题不是“要不要慢下来”，而是： 如何在不牺牲速度的前提下，提高采用能力？ 真正的瓶颈：用户注意力 如果你正在构建任何严肃的产品，并且正在用 AI 提高产出，你迟早都会撞上这堵墙。 在 PostHog，我们仍在不断摸索最佳路径，但有几件事已经变得异常清楚。 1. 把注意力当作稀缺资源（因为它确实是） 小型自治团队天然会围绕自己负责的那一小块产品进行优化。他们拥有某个功能，并持续把它做得更好。 但用户并不是以“功能所有权”的方式体验产品的。他们是通过有限的注意力，被动接收你所有的产品变化。 正是在这里，系统开始失衡。 常见的失败表现 这些方式能捕获的注意力是有限的。一旦发布速度足够快，就连最投入的用户也会产生“功能疲劳”。…

去网上搜一下“async agents（异步代理）”这个词，你会看到几十篇文章在用这个说法。那些少数愿意给出定义的文章，谈的似乎也都不是同一件事。它出现在产品发布里、HN 讨论串里、架构博客里，总是被很随意地提起，好像含义不言自明。所以我想搞清楚：到底哪一种定义才算“正确”。 我看到最常见的定义是：异步代理就是“会运行一段时间的代理”。一个长时间运行的任务会让人感觉“异步”。如果它能在你去上厕所或去续一杯水的时候继续干活，那就很像异步。确实，任务跑得足够久，你就有机会去做别的事。但那到底要跑多久才算？一个一秒就完成的代理和一个跑一小时的代理，前者是同步、后者才是异步吗？我能不能在运行代理之前加一个 sleep 语句，就把它变成异步代理？这听起来并不令人满意。 我反复遇到的第二种定义是：异步代理是“跑在云端的代理”。Devin 是远程运行的，所以它是异步。Claude Code 是本地运行的，所以它不是。但如果我开一台 EC2，SSH 进去，装上 Claude Code，然后在那台机器上运行——我是不是就把它“变成”异步代理了？工具本身没变，只是运行它的机器变了。这不可能是核心。 第三种定义则是：异步代理是“事件驱动”的——不是由你手动触发的那种。一条 PR 合并了，代理就启动。一个 cron 定时任务触发了，代理就到 Slack 给你发消息。这种感觉确实很异步，因为在那一刻不是你在敲命令。但 cron 也可以启动任何程序。触发是异步的，并不意味着被触发的程序本身就是异步。这是调度（scheduling），不是代理自身的属性。 这些定义都不能说“完全错”，但它们都不像定义。它们只是在描述一些特征——这些特征恰好与人们想指代的东西相关联。那我们回到最基本的概念。 什么是代理？什么是异步？正如 Simon Willison 所说，代理就是一个“在循环里调用工具的 LLM”。我会更进一步说：代理还需要“上下文的连续性”。如果我启动两个不同的 Claude Code 会话，那就是两个不同的代理。如果我在某个 Claude Code 实例里输入 /clear，我就杀死了一个代理并生成了一个新的代理。让它成为“那个代理”的，是上下文。 接下来是异步。技术上的定义是：事件会独立于主程序流程发生。关键洞见在于：一个 async 函数本身并不会“自带异步魔法”。它是否异步，取决于它相对于调用方（caller）的位置。调用方如果不等待，它就独立运行；调用方如果等待，它就等同于同步。异步的部分不在函数本身，而在调用方选择“不阻塞（not block）”的决定。 想想在代理出现之前，写代码是什么样：你在敲字；工作在发生。你停下敲字；工作就停。一次只能推进一个任务，一切都同步。 当编码代理出现后，它解锁了新东西：异步工作成为可能。你可以把工作委派出去，并不等待它完成。你可以给代理一个任务，去做午饭，然后回来看到一条完成的 PR。第一次，你的工作可以在你做别的事的时候继续推进。 但这并不意味着代理“天生异步”。你也可以转过头用同一个代理问一个很快的问题，然后等待它回答。在那一刻，你是同步地使用它。代理没有变，变的是你的行为。 所以大家总在说的“异步代理”到底是什么？它其实在观察者的眼里。真正的异步代理，其实是我们一路上交到的朋友。 不过认真说，没有任何代理是天生异步的。这取决于你等不等它做完。 异步地使用代理如果你选择异步地使用代理，你会解锁一个强大的能力：并发（concurrency）。你可以把多个任务委派给多个代理，让它们同时推进。但一旦这么做，你会撞上一个现实问题：它们都在你机器上的同一份代码库里工作。这不是真实工程团队的工作方式。每个工程师都有自己的电脑、自己的代码副本、自己的分支。 那为什么不让大家像 Google Docs 那样实时编辑同一份代码库呢？看起来似乎能消灭一整类问题：合并冲突、相互覆盖的修改、分支分叉……基本上就是 Git 逼你处理的那一堆事。协作式编码以前有人试过，而且没流行起来，是有原因的（Replit 早期就是这么做的）。问题在于：没有隔离，一个人的半成品就可能把另一个人的“可工作代码”弄坏。你需要让每个任务都活在它自己的环境里，这样它才能独立地构建、测试、验证。 代理也会遇到同样的问题。它们需要各自的代码库副本来推进，而不会踩到彼此。这就是为什么像…

你可能已经注意到，Anthropic正在发生一些事。他们就像一艘即将点火升空的宇宙飞船。整篇文章只是“蜘蛛感应”（spidey-sense）之类的东西。别想太多。只是直觉。说白了，就是“氛围感”（vibes）。 如果你做一做“信封背面”的粗算（back-of-envelope math），估一估作为业内人士进入Anthropic有多难，再把它与你在高中或大学球员阶段进入美式橄榄球联盟（NFL）的概率相比，你会发现两者相当。到目前为止，我见到的Anthropic同事都是“最强中的最强中的最强”，甚至比谷歌巅峰期还要夸张。（证据：谷歌录用了我。我就是最“刮锅底”的那批。） 大家都在向那里聚拢，而这部电影我之前已经看过不止一次。 过去四个月里，我有幸与Anthropic里将近40人做过相对坦诚的长谈——从联合创始人和高管，到整支团队，再到公司各部门的个体：AI研究、工程、GTM（go-to-market）、销售、编辑、产品等等。那里也有不少我的朋友，曾在以前的项目里共事过。 Anthropic作为一家公司，非同寻常地“难以渗透”。那里的员工都明白，只要闭嘴、埋头干活，他们就会成为亿万富翁甚至更进一步，所以他们有充足的动机照做。即便他们愿意跟你聊天，也很难真正撬开他们的话匣子。 但我还是做到了。通常在人们跟我接触14秒内，就会意识到我“无害”。到了我这把年纪，我长出了一种好奇的能力：无论对方是谁，只要聊上几句就能让人感觉良好，同时也让我们俩都感觉良好。（你大概也有这种能力，只是不知道怎么用。） 和足够多的人聊过、听过他们的长谈视角后，我开始怀疑：软件开发的未来，是“蜂群思维”（Hive Mind）。 又喜又悲 要想勾勒此刻Anthropic的完整画面，你得变成克洛德·莫奈，用印象派的方式去画，一笔一笔的大笔触。这一节就是一笔，讲的是“情绪”。 在我看来，几乎所有人都洋溢着鲜活的快乐。那股空气里的电火花，和1998年亚马逊的感觉一样。只是那会儿还没有厄普顿·辛克莱（Upton Sinclair）和所谓“人力资源（HR）”，所以电火花大多来自一楼酒吧的电线短路。 但无论是早期的亚马逊，还是今天的Anthropic，所有人都知道，某件了不起的事情即将发生，它会永远改变社会。（同时，他们也知道，无论接下来什么降临，对社会来说都将“极度阿拉丁”（极端复杂/矛盾/黑色幽默）。） 在Anthropic，我遇到的每一个人、每一支团队，无一例外，都带着一种甜中带悲的超然之感。他们给我的感觉像是一群被赋予“把与文明层面同等重要的某物带入现实”的人；他们兴奋，但也都带着一种古老精灵式的、旧世界将逝的庄重。我说不清那究竟是什么。 但我开始怀疑，他们对很多公司真的抱有“同情”。因为我们没把这件事当回事。2026年将会是几乎把很多公司“打到崩溃”的一年，而许多公司毫无所觉。Anthropic试着提醒大家，可这就像对百年没见过海啸的村庄大喊“海上地震来了”。 “氛围思维”（Vibe Mind） 只要你和Anthropic的人聊，总会聊到“混沌”。这家公司并不像同体量的公司那样运营。其他公司在这个规模上往往很快就变得“专业化”、部门化、可问责、成熟、诸如此类。我不觉得Anthropic现在对那些“套装流程”有多少兴趣。 当然啦，涉及他们的生产系统时，他们当然极其严肃，板起脸来，有世界级的SRE和扩展工程师。只不过，你也懂。让这条“大狗”摇尾巴的，其实是各式各样形态的Claude，那才是让蜂巢嗡嗡作响的“工作生成器”。 所以当我笼统地说“Anthropic完全靠氛围运行”时，我相信在靠近外缘的地方一定有例外：在那里他们会与外部世界建立更硬化的接口，无论是生产、GTM，还是产品营销。公司在那些边缘位置可能更“正常”。 但在核心，他们显然正处在（也许刚刚进入）一个“黄金时代”，下一节我会讲。那里既翻涌又起泡。 员工们常把它描述为“完全靠氛围驱动的蜂群思维”，这不是我强加给他们的词汇，而是他们自己的观察。组织会反映领导者的样子，所以这显然是由领导层在引导，而且大概率是刻意为之。并不是所有蜜蜂体型都一样，你能看到蜂群里分布着一些“图中的枢纽节点”，在维持整体稳定。 但如果你干扰蜂群的运作，打破这种平衡，你就会被温柔地推到边缘，甚至更外面。离心机会把你甩到外围，被“氛围”席卷着远离。 它看起来很脆弱，也许存在我们尚未知晓的“规模天花板”。但他们迄今一直维持着它，我也对他们的做法有一些想法。 如何终结一个黄金时代 我要插一句，与“蜂群思维”并不完全同向，但Anthropic把另一种属性展现得太清楚了，值得暂停一下，一起审视。 “黄金时代”是指一段持续数年的密集创新、品类创建、速度与产出暴涨的时期。公司层面的黄金时代有个特性：会在很短时间内吸引全行业的顶尖人才。Anthropic如今正经历着这一点。 我在亚马逊时经历了他们的黄金时代——我2005年离开时，那股劲头还没过去。后来我在谷歌也经历了他们的黄金时代，持续到2011年4月。之后，我眼看着谷歌钙化、分隔、几乎无法跨职能协作；与此同时，亚马逊还在持续执行与创新。 再给你第三个例子：在2000年代初，微软因为打输了Sun的Java诉讼，于是聚集了行业内无数顶尖人才，去用CLR与C#/.NET重塑软件开发的未来。那可能是他们能遇到的“最好的坏事”，有好几年一切都很魔幻，他们产出的东西塑造了整个行业。那几年他们是思想领袖。后来很多人“出逃”去了谷歌，一切烟消云散。 我花了很多年琢磨谷歌为何、如何会走到那一步。直到我看到Anthropic正在发生的事，一切才“咔哒”对上。 谷歌在转向利润为中心时，就扼杀了他们的创新机器——这导致“工作量与人数”的比例发生了转折。 谷歌早期CEO埃里克·施密特的口号是“让一千朵花盛开”。他的解释是：通过鼓励创新、下注许多项目来“制造运气”，希望其中一些会开花结果。谷歌能这么干，是因为他们在Web这片新绿地里财源滚滚。 2011年4月，拉里·佩奇接任CEO，他的口号变成：“把更多木头放到更少的箭上”（More Wood Behind Fewer Arrows）。他觉得——事实上也没错——那些不受约束的20%项目和Google Labs并没有产出真正的“爆款”。所以拉里大幅约束被资助的工作，20%项目逐步消亡。自那以后，公司变得“政治化”，丧失了大部分创新引擎，黄金时代也随之结束。 杀死20%项目本身，是导致崩塌的原因吗？未必。反例是亚马逊从未有过20%项目。它的创新与兴奋的黄金时代持续了很久，远远超过我2005年离开后的那些年。所以问题不在这里。那么亚马逊拥有而谷歌没有的是什么？ 一个线索来自我的同事雅各布·加布里尔森，他大概在2015年前后是亚马逊的首席工程师。当时谷歌已经像混凝土一样坚硬。我跟他说，谷歌的人常常会为了项目争斗，雅各布告诉我亚马逊从不这样，因为——用他的话说——“这里的每个人都总是略微超额订阅（slightly oversubscribed）。” 现在你就明白魔法如何开始、又如何结束了。黄金时代里，“工作多于人”。而当它崩塌，是因为“人多于工作”。 我知道我在“混单位”，但不这么说就很难把话说顺。你懂的。 拉里·佩奇在2011年4月对公司说：“别做新东西了，我们只做X、Y、Z。”可他们一个工程师都没裁，只是把“可做的工作量”砍掉了足足50%甚至更多。你再也不能随便做你想解决的问题了。于是，很快大家“分不到活”。 那就是终局的起点。一旦“活儿”不够，人们就开始为剩下的活儿争斗。接着就是帝国搭建、领地意识、政治斗争、土地掠夺，以及莉迪娅·阿什教我的“舔曲奇”（Cookie Licking）——微软人发明的说法，指那些“占着项目但永远不做的人”。 这些“坏事”，在今天许多公司里是常态。有人形容在微软就像一粒金属中的分子，你的胳膊肘与别人的紧紧卡在一起。具有讽刺意味的是，微软的曲奇如今似乎都被舔过了。 在Anthropic，他们正处在黄金时代的正中央：几乎所有方向上，“可做的活儿”都远多于“能做的人”。就像他们站在一个不断膨胀的球体表面。 因此，尽管有混乱、也不可避免地有成长的阵痛（跟我在亚马逊IPO后“Get Big Fast”阶段时的体验颇为相似），但从来没有理由为“工作”争斗。工作是无限的。 于是每个人都能有很多机会把自己的想法拿到阳光下，而“蜂群思维”会对其做出评判。 “小结版” 我非常怀疑，Anthropic的运作方式，很快会成为所有成功公司在未来几年里的主流，尽管它与当今大多数公司的运作方式大相径庭。…

停止生成，开始思考2026年2月8日标签：AI、工程 在我的职业生涯中，我一直自认为能紧跟行业的最新发展：参加各种会议、关注并结识那些撰写技术规范的聪明人、在Slack上第一个向同事分享CSS或JS新特性的消息。能在只需兼容最新版Chrome的内部工具上工作、在生产环境中尝试仍属实验阶段的“锚点定位”功能——那种乐趣无与伦比。 因此，当我发现自己开始觉得“被时代甩在后面”、好像“错过了什么”时，这种感觉相当不安。尽管我不愿承认，但越来越多的人疯狂依赖由大语言模型（LLM）生成的代码，而我却无法理解其中的逻辑。 我一直在用Copilot——最近也用Claude——把它们当作“加辣版自动补全”或偶尔的调试助手。但每次我尝试让它做一点稍微复杂的事，它就完全崩溃。别误会，我知道很大一部分问题在于我使用方式不对，但我很难说服自己花大量时间去琢磨如何让一台机器写出我自己在更短时间内就能完成的代码。 你得给它足够的上下文——但又不能太多，否则它会“过载”。你得写出一大段提示词来安抚AI那脆弱的自尊心，比如“你是一位分布式系统专家”，仿佛它是一个不自信的平庸程序员。 可我何不直接写那段代码，反而更快？ 看到越来越多工程师选择“生成代码”而不是“写代码”，我开始纳闷：为什么大家愿意放弃工作中最有趣的部分（写代码），而只留下最无聊的部分（代码审查）？ 也许有人真的喜欢给计算机写角色扮演剧本吧。我不知道。但我觉得危险的是，人们正心甘情愿——甚至自豪地——让生成代码充斥他们的产品。 我听过的几种辩解 “这就是我们的工业革命！就像机械化一样。”在很多方面，这话确实没错。 首先，想想工业革命对气候变化的贡献，再看看支撑AI软件的数据中心的能源消耗，这种相似性很明显。诚然，如今并非所有电力都来自化石燃料，这算是点进步，但我们仍在浪费惊人的资源，用来生成“虾仁耶稣”的图片。 机械化让商品更便宜、更普及，但质量却下降：自19世纪末以来就是一场“向下竞赛”。如今你能在SHEIN上花比一杯咖啡更少的钱买到一条“易燃”的裤子。机械化导致技能劳动的衰退，公司把工厂外包到欠发达国家，剥削低薪工人赚更多钱。 生成代码就像快时尚：乍看之下还行，但经不起时间考验，仔细一看漏洞百出。而且，就像快时尚一样，它常常抄袭别人的设计，对环境造成负担。 但有个关键区别。机械化是用机器取代了制造流程中的人力，让机器完成同样的工作。就像用脚本或代码生成工具写模板代码。这类过程的关键在于可重复——每次输出一致。如果出错，人类能打开机器，找到问题。 而LLM的输出是非确定性的，内部机制又不透明。一个每次结果都不同、还充满“幻觉”的机械化过程——根本没用。 “LLM只是另一层抽象，就像高级语言取代汇编一样。”确实，写Java或Go时我不必了解汇编。我最接近“汇编”的，大概就是编织图案说明书吧。 编程语言的演变，让我们逐渐不必操心底层细节：我不用管理内存回收或分配——运行时会自动处理。但我仍需思考代码结构、性能、系统架构、可维护性与交付速度之间的平衡。做Web开发时，我们得考虑浏览器兼容性、可访问性、安全性与性能。 我见过LLM造成的最大问题是：工程师把原本该自己思考的部分外包给机器。LLM不能推理系统架构该如何设计——因为它不会思考。如果我们不思考，而它也不思考，那就没人思考。没人思考的软件，绝不会有好结果。 以英国“邮局丑闻（Horizon scandal）”为例：因为软件漏洞导致员工被错误指控挪用公款，许多无辜职员入狱。我们比以往任何时候都更需要对软件负责。 十三个人因为那个系统的错误而失去了生命。 问题在于我们自己糟糕的代码 你也许会说：现在的人类开发者写的代码也一样糟糕——不可访问、性能低下、臃肿的JavaScript。那又有什么区别？ 没错。这正是问题所在。LLM是在未经我们明确许可的情况下，从这些糟糕代码中学习的。我们教会了它输出同样糟糕的东西。它注定会重复人类的错误——再加上别的LLM生成的错误——这正是有人戏称的“人类蜈蚣式知识链”。我们自己代码都不够好，哪来资格要一台机器更快地写出同样糟糕的东西？ 如果你觉得“到目前为止还行”，那就去问问使用辅助技术的人；问问网络连接差的国家；问问在英国城市里靠移动数据上网的人；问问被人脸识别或甚至自动干手机系统歧视的人；再问问那些邮局职员。 我们没有学习、没有改进，反而把错误交给了不懂思考的算法。 “四只眼睛好，两只眼睛坏” 去年在FFConf上，Jessica Rose和Eda Eren做了一场精彩的演讲，讲述AI编程助手如何让我们逐渐失去技能。其中有一张幻灯片让我印象深刻： “你没有亲手写的代码，你就无法理解。你无法维护你不理解的代码。” 当我审查同事提交的PR时，会有一种信任感——因为那是一个经过思考的人写的代码。虽然也有例外，但若某人总提交糟糕的PR，经理自然会介入。 而开源维护者如今面对大量低质量的AI生成PR。作为贡献者，无论代码是否由LLM生成，你都要为自己提交的代码负责。审查者也有部分责任，但至少有两双眼睛在看。 现在有公司在社交媒体上炫耀他们让Claude在Slack里生成代码并直接创建PR。Claude自动写完代码，再自动发起PR。这时责任全落在审查者身上。如果规则不够严格，一个人就能让Claude生成并自己批准——于是我们失去了一双“人眼”，团队的知识共享也随之减少。 代码审查不仅仅是查漏洞，更是分享理解。虽然有公司完全不做PR、直接提交到主分支，但我见过唯一可行的做法是工程师持续配对编程——这样才能保持对改动的共同理解。 我不是反对进步，我是反对炒作 我必须强调：我并不“反对LLM”。我反对的是把它们包装成“人工智能”——因为它根本不智能。它只是机器学习的一种形式。“生成式AI”不过是一个非常强大的马尔可夫链，人们对它的期望远远超过现实。 我也不反对用生成式AI快速制作原型——比如线框或交互演示，这很合理。我的担忧在于：有些人以为可以靠“感觉提示”（vibe code）直接生成可上线的软件，或者把编程中最重要的“思考过程”完全交给机器。 Mikayla Maki提出了一个非常好的观点：始终让人类参与其中，把AI代理当作一个你不完全信任的外部协作者。 只让它执行你自己已经掌握的任务——因为理解才是关键。 我会继续使用我的“加辣自动补全”，但我绝不会把思考外包。停止生成，开始理解——也别忘了我们当初为什么热爱这份工作。

我至今仍对AI用户之间的巨大差异感到震惊。我认为，这种差距很大程度上解释了媒体对AI及其生产力影响的报道为何常常令我困惑。 现在我很清楚地看到，AI用户（以及他们所在的组织）大致分为两类。 首先是“高级用户”，他们全身心投入到新AI技术的应用中——例如Claude Code、MCPs、各种技能系统等。令人意外的是，这些人往往并非技术背景出身。我看到的非技术背景用户远比我想象的多，他们在终端中使用Claude Code处理各种非软件工程任务。金融岗位似乎从中获得了巨大的价值（这也不奇怪，因为一旦习惯了像Python这样完整的编程生态系统，Excel在金融分析中的限制就会显得格外明显）。 其次，是那些只用ChatGPT或类似聊天AI的人。我认识的许多人仍属于这一类，这让我颇为意外。 M365 Copilot的困境 让我震惊的一点是：微软的Copilot表现非常糟糕。它在企业市场拥有庞大的份额，因为它被捆绑在各种Office 365订阅中，但它的体验却像一个拙劣克隆的ChatGPT界面（而ChatGPT本身在企业效率上也并不算出色）。其中的“智能代理”功能更是令人发笑，与命令行中的代码代理（包括微软自己GitHub上那个名字混乱的Copilot CLI）相比简直天差地别。 更具讽刺意味的是，微软自己正在向内部团队推广Claude Code[1]——尽管他们几乎可以零成本使用Copilot，并且还是OpenAI的重要股东。这恰恰说明他们已经落后了多远。 问题在于，在许多企业环境中，Copilot往往是唯一被允许使用的AI工具。你若使用其他AI工具，轻则要花费巨大精力去申请审批，重则可能会丢掉工作。Copilot运行缓慢，其代码执行工具功能不完善，在处理稍大一些的文件时几乎必然崩溃——显然是因为内存与CPU资源被极度限制。 这对很多企业来说正成为一种“生存风险”。高层决策者使用这些工具得不到理想效果，于是干脆否定AI的价值，或者花费巨资请大型咨询公司协助，却依旧收效甚微。 企业面临的结构性风险 大型企业的IT政策往往造成一系列灾难性的限制，使得员工无法有效使用更先进的AI工具。 首先，他们通常拥有极为封闭的工作环境，本地连最基本的脚本解释器都无法运行（若幸运的话，能用VBA，但往往也被组策略限制）。其次，他们依赖的传统软件缺乏“内部API”，这意味着即使能运行智能代理，代理也无从连接关键工作流程。 最后，他们的工程部门往往高度割裂，甚至被完全外包，所以即便想构建一个安全的AI代理运行环境，内部也无人能实现。 安全顾虑确实存在。没人希望员工随意让代码代理直接操作生产数据库——风险太高。而我之前也提到，构建安全的沙盒代理并不容易[2]。 但问题是，缺乏内部工程能力，就无法打造能安全调用企业数据的AI基础设施。 巨大的差距 我与一些规模较小、没有这些“包袱”的公司交流过，他们在AI应用上发展极快。两种公司之间的差距非常明显。 一方面，你能看到微软那糟糕的Excel Copilot整合（公平地说，谷歌Sheets的Gemini整合也不好）。你可以想象财务总监尝试用它时，它把最基本的任务都搞砸，于是他们再也不会碰它。 另一方面，你会看到一个非技术出身的高管，却能熟练使用Claude Code并在本地运行Python。我最近就帮过一位高管，几乎“一次成型”地把一个包含30个工作表、复杂到令人头疼的Excel财务模型转换成了Python脚本。 当模型进入Python后，借助Claude Code，你就等于拥有了一个随身的数据科学团队。你可以轻松运行蒙特卡洛模拟、导入外部数据、构建网页仪表板，并让Claude Code与你一起分析业务模型的弱点。这种体验令人惊叹——看到一个人意识到自己竟能如此高效，而不再被Excel束缚。 结果是，小公司员工的生产力远远高于大型企业中的同类岗位。过去，小公司的人常常羡慕大企业的资源与团队，但如今我觉得情况正在反转。 未来的趋势 我逐渐看清了未来工作的形态。首先，真正的突破往往来自员工自发的尝试，而非高层制定的“AI战略”。我看到的最大生产力提升，来自小团队自己为熟悉的流程打造AI辅助系统——他们对流程了如指掌，因此能快速见效；而外包的软件团队往往对业务一无所知，效率极低。这与过去企业“数字化转型”项目的自上而下模式完全相反。 其次，拥有内部系统API的公司，远比没有API的公司更具优势。这可能只是一个只读数据仓库，供员工通过AI查询；也可能是复杂的业务流程都通过API暴露出来。 再次，这一切都需要安全机制包裹。我认为，运行代码代理的托管虚拟机（配合合理的网络限制）会是一个不错的方案——至少在只读报表场景下可行。而对于创建或编辑数据的操作，我们还没找到非技术用户能安全使用的模式（至少目前还没有）。 最后，那些老旧的企业SaaS供应商要么拥有强大的客户锁定力，要么极度脆弱——这取决于视角。多数产品并非“API优先”设计，它们的API多为开发者准备，不适合成千上万的员工以各种低效方式调用。但如果这些系统是企业的“真相源头”，就几乎不可能迁移，也因此成为生产力提升的瓶颈。 相比之下，小公司使用的现代产品往往天生拥有完善的API——因为它们不是几十年前拼凑出来的。 知识工作的未来 未来的知识工作模式将是：用户发出指令，AI代理连接系统API，实时生成结果。 换句话说，用户发出提示（prompt），代理综合信息、连接API、并按需输出结果。 我逐渐意识到：当你拥有一个带编程语言与API访问权限的安全沙盒环境，再配合智能代理框架，其结果之强大令人难以置信。它几乎可以替代现有的所有生产力软件——无论是传统的Microsoft Office，还是各类网页应用。它可以生成任何报告，并以任何格式导出。对我而言，这正是知识工作的未来。 如今，这种分化是真实存在的，而且正在迅速加速。我不认为历史上曾有任何一个时代，小团队能如此轻松地击败规模比自己大一千倍的公司。

当 CEO 给我打来电话时，我接起电话，手不自觉地攥紧，身体因为期待而僵住了。 他先是绕了一会儿弯子：“我们面试了很多候选人……” 就在我开始怀疑自己的时候，他说出了那句话：“我们希望向你发出一份录用通知。” 30 万美元的基础薪资，外加股权和搬迁补贴。而且这是一家位于旧金山的初创公司，我将有机会参与最前沿技术的开发，真正产生影响。 电话一挂断，我立刻跑到公寓楼顶的热水池里。我给认识的每一个人打电话，分享这个令人振奋的消息。我问大家我是否应该接受这份新工作，但在内心深处，从我拿到 offer 的那一刻起，我其实已经做出了决定。钱本身就说明了一切。我又在热水池里待了一个小时，沉浸在这份好消息里，确信自己再也不需要为当前的工作担心什么了。 我对亚马逊有很多美好的评价。我在 Alexa 上做的工作很有意思——参与了新 AI 技术的开发并准备上线，团队也很友好。我住在离公司步行几分钟的一套很酷的公寓里，作息灵活，每天都有时间打网球，周末也过得很惬意。但在那个时候，我满脑子想的却都是：我为什么想离开。 一切都太慢了。发布一个功能需要经过层层审批——先是团队对设计文档的初步认可，再是产品经理确认你的改动符合规格要求，然后是团队对上线计划的再次批准，中间还有无数与其他团队协作时的审批流程。晋升也很慢——不管你多有天赋，通常都要等一到两年。 我还觉得我们并不在技术前沿。内部工具很陈旧，而且公司禁止使用许多初创公司用来加速工作的 AI 工具。我有很多改进想法，但我在其中并没有太多话语权。政治因素也常常妨碍事情推进。会议多得离谱，很多人似乎只是为了展示自己做了什么而出席，而不是为了真正推动工作。 抵达旧金山。 我接受了那家初创公司的 offer。一个月后，我把行李装进车里，开车搬到了旧金山。第一天走进办公室时，我注意到的第一件事就是这里的活力和个性。销售人员不停地打电话，工程师们彼此讨论代码问题，还在吐槽 Cursor 的表现达不到他们的标准。团队已经挤爆了办公室，我不得不和其他工程师围坐在一张桌子旁。 第一周里，我就看到了与亚马逊之间的巨大反差。老实说，这几乎无法与亚马逊相提并论。它更像是我和几个朋友为了黑客松临时拼凑出来的一个项目。入职第一天就完成了 onboarding，然后我就被要求在第一周交付一个功能。代码库是用 Cursor 草草拼起来的，我被告知：凡是我觉得需要修的地方都可以修。我们用 DoorDash 把饭点到办公室，很多同事一起吃晚饭，有时还会一起打匹克球。团队成员之间的打趣，仿佛他们已经认识了很多年。这和亚马逊那种冷冰冰、企业化的氛围形成了鲜明对比。 不过，我对待工作的方式却和在亚马逊时差不多。我并没有和同事建立非常紧密的关系，至少一开始没有。我把这份工作当成一份“完成本职、按时下班”的工作，而不是当成人生使命。当我不得不为了截止日期埋头苦干时，我很难从中获得乐趣——这份工作里并没有让我觉得“非做不可”的东西。但对创始团队来说却不是这样。这就是他们生活的全部，是他们呼吸的一切。 在我入职第三周的那个星期一，两位创始工程师把我叫到外面。他们说，我的工作方式存在一些问题。第二天就要到截止日期了，而我却说我晚上想去打网球，而不是竭尽全力把事情交付出来。我的心开始狂跳。接下来的一段对话，在我脑海里几乎模糊成了一片。 然后他们问我：“你喜欢你现在做的工作吗？” 我停顿了一下。那一刻，我已经没有心力去编造任何说辞。 “没有。”我说。 “那就到此为止吧。你可以回去把剩下的代码提交了。” 事情就这样结束了。我走回办公室，提交了代码，一句话也没说就离开了。我一边走，一边想象着所有人的目光都落在我身上。 就这样。我在旧金山，没有朋友，没有工作。接下来的一天里，我一直处于否认状态，无法理解一场成真了的美梦，怎么会以如此糟糕的方式结束。我曾经拥有一切，而现在却一无所有。但这段经历将影响我此后所有的职业决策。不论好坏，这都是一次改变人生的经历。 也许我本可以在正式入职前做一次工作试用，先感受一下氛围。当我问创始工程师们他们喜欢公司什么时，一个人说他喜欢这里的人，另一个说他喜欢做新技术。但我既没有和这些人产生共鸣，也谈不上对技术本身有多大的热情。如果有过一次工作试用，我或许能更早发现自己是否真的有动力投入他们期望我付出的工作强度。 也许我本可以用更聪明的方式和团队合作。我对自己正在做的一些工作的必要性持怀疑态度，但与其在一开始就过于挑剔，我本可以先慢慢融入，在赢得信任的同时更主动一些。我本可以通过沟通来更好地理解期望值，并讨论提升我表现的解决方案。我入职时还在找公寓，所以在最初几周里，我本可以再多拼一把。 总体而言，我学到了一点：在选择初创公司时一定要格外谨慎。亚马逊以高强度著称，但我依然能够完成自己的工作。而在旧金山的这段时间让我意识到，初创公司的强度完全不在一个量级——每个人不仅聪明，而且极度投入。过去的人生中，我一直靠自己的聪明才智过关，但在这家初创公司里，这远远不够。而我也不想把自己的血汗和眼泪，奉献给一家并不能让我产生共鸣的公司。尤其是在我感觉：如果我愿意，我随时都可以创办自己的公司，并且很快达到同样的阶段，只不过是以 CEO 的身份，而不是员工。 直到现在，我内心仍然有一部分感到愤怒、后悔和苦涩。有时我会想：“如果当时我做了［某件事］会怎样？”但同时，我也有一部分感到庆幸——我敢于纵身一跃，并亲眼看到了结果。 我在旧金山的那段时间，可能是我人生中最具转变意义的时期。我只工作了三周就失业了，但随后几个月教会我的东西却无比宝贵。

周一，SpaceX 收购了 xAI，组成了一个市值高达 1.25 万亿美元的巨型联合体，其目标是把数据中心送入太空。他们并不孤单：Google 以及一大批初创公司，比如 Lonestar、Axiom，还有获得 Nvidia 投资的 Starcloud，也都在争先恐后地进入这一领域。无穷无尽的太阳能、免费的“地产”，最重要的是——巨大的火箭！你还能想要什么？ Google 去年发表的一项研究探讨了在太空中运行 AI 的可行性。作者设想了一个由 81 颗近距离编队飞行的卫星组成的星座，并认为，如果把物资送入近地轨道的成本降到每公斤 200 美元，那么它就有可能与等规模的地面数据中心竞争。他们预测，如果 SpaceX 的 Starship 项目成功，这种情况大约会在 2035 年左右出现。 但即便我们假设辐射、防护、散热、延迟以及发射成本等问题全部被解决，至少在 SpaceX 所理解的那种形式下，轨道数据中心仍然在其他一些根本性问题上完全是幻想。有三个问题尤其突出： 第一，在规模上训练和部署前沿 AI 需要几十万块 GPU。xAI 的 Colossus 集群据称拥有 20 万块 GPU。OpenAI 则计划使用数百万块。要在这个市场中竞争，就意味着需要把几十万、甚至上百万颗卫星送入太空。这将彻底压倒目前大约只有 1.5 万颗卫星在绕地运行的现状。如此规模的卫星部署，会极大地增加凯斯勒综合症（Kessler syndrome）的风险——即碎片发生级联式爆炸，最终瘫痪我们进入太空的能力。 第二，卫星无法进行大规模升级。今天，当新一代 AI 硬件发布时，公司几乎可以立刻开始在数据中心中逐步部署。而在太空中，你只能发射一整套新的、数量庞大到难以想象的卫星舰队。 第三，太空中的数据中心只有在相对于普通数据中心具备成本优势时才有意义。这意味着，即便在 2035 年，火箭和高度特制的卫星硬件成本真的下降到可以与当今的 AI 服务器竞争，它们仍然需要与 2035 年、以及只要数据中心仍然存在期间的地面 AI 服务器运行成本保持竞争力。几十年来，地面太阳能电池板的成本一直在持续下降，而且看不到放缓的迹象。随着常规能源生产效率的不断提升，太空数据中心的合理性只会越来越弱。 （1975 年至…

在过去大约十年里，当一名开发者……可以说是相当舒服。 如果你在过去 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…