Category: Uncategorized

我至今仍对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…

最近我和妻子需要叫一辆车，于是掏出手机，用几个打车应用对比价格。平时价格总会有一点差异，但这一次的差别却格外明显。 我妻子的 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…