AI TrendTrackers

软件行业正在经历一场“恐慌发作”。自 2026 年初以来，公开上市软件公司的 ETF 下跌了 30%，抹去了自 ChatGPT 发布以来的全部涨幅。像 Salesforce、Adobe、Intuit、ServiceNow 和 Veeva 这样的行业风向标——这些在过去十多年里为投资者持续创造复利回报的公司——在短短几周内下跌了 25% 到 30%。Substack 上的爆款文章描绘了一个企业软件客户基础被掏空、标普指数进入多年大幅回调的世界。他们把这称为“ SaaSpocalypse ”。这迅速成为市场共识：AI 将杀死软件行业。 是的，AI 很重要。但得出“AI 将摧毁垂直与功能型软件商业模式”的结论，完全说不通。真相是：AI 不会杀死软件公司。等这波恐慌过去之后，人们会发现，AI 是软件行业有史以来最好的事情。 为什么这么说？ 看空的逻辑建立在一个对软件公司本质的误解之上。市场把“软件”当成一种商品化的投入要素，仿佛软件公司的价值在于代码本身，好像代码变便宜了，竞争就会变激烈，公司价值就会缩水。但代码从来不是价值所在。如果代码才是价值核心，这些公司根本不可能成长到今天的规模——它们早就会被开源软件，或者被发展中国家的廉价软件工程劳动力击垮。 今天的悲观论调通常落在四种观点之一：也许基础模型实验室会上移到应用层，占据每一个功能型应用；也许企业会“氛围编程”（vibe code）替代内部工具，至少会用这种可能性来压低软件公司的定价权；也许现有玩家会利用 AI 大幅扩展产品边界，彼此碰撞；又或者会涌现出大量新进入者——那种“单人十亿美元公司”——用更低价格打击 incumbents。再加上一点：智能体不会在乎品牌忠诚或熟悉名称，它们只会为某个任务选择最便宜的选项。 AI 可能会增加竞争；但它也会极大扩展软件公司能做什么、做得多快，以及它们所服务市场的规模。最终结果不会是利润率归零。软件行业将变得更大，而那些真正赢得竞争优势的公司，将继续拥有持久的护城河。 真正重要的护城河不会消失 当代讨论商业护城河的经典著作是 Hamilton Helmer 的《Seven Powers》。他提出七种构建竞争优势的方式：规模、网络效应、反向定位、转换成本、品牌、被垄断的资源、流程能力。我们逐一来看。 转换成本，或许是唯一真正会发生变化的护城河。AI 确实降低了更换供应商的摩擦与成本：智能体可以协助完成许多过去令人头痛的迁移工作。这意味着那些“挟持客户而非赢得客户”的传统公司，会面临更大压力。 但这对整个软件行业来说是好事。当企业必须真正赢得客户忠诚，而不能仅仅依靠锁定机制时，结果是更好的产品、更快的创新，以及一个更健康、增长更快、为客户创造更多价值的竞争生态。AI 可能会让部分客户转向新的赢家，但不会削弱整个行业的利润池。公司只会变得更好。 网络效应是经典护城河，而且不会消失。我们通常在社交媒体或平台型市场中谈论网络效应——节点越多，网络越有价值。但应用软件同样存在生态、协作和数据网络效应。表面上看，Salesforce 只是一个 CRM 数据库；但任何在企业环境中工作过的人都知道，它也是一个生态系统。当所有人都使用同一个平台时，这个网络会自我强化：你使用 Salesforce，因为所有人都在使用 Salesforce。使用者越多，其第三方应用生态和管理员专家群体就越有价值。近几年，Figma 也是如此：设计师、工程师、产品经理、市场人员都在 Figma 上协作。参加一年一度的 Config 大会，你就能直观看到生态的力量。 这种动态在…

我热爱机器人。我从事人工智能和机器人相关工作已经大约 5 年了。所以从情感上讲，我当然非常希望家里能有一台类人机器人，帮我洗碗、洗衣服，甚至替我去买菜。谁不想要呢？ 但我真的不认为我们已经接近“通用型家用类人机器人”的时代。不知为何，在 2026 年，说出这样的观点竟然显得有些“有争议”。所以我决定把它写下来。 我的核心观点是：通用型类人机器人就像自动驾驶汽车——但实际上还要难得多。在解释原因之前，我们先谈谈好消息。 过去 5 年里，类人机器人领域确实取得了一些非常令人印象深刻的进展。我们现在已经拥有： 更好、更便宜的硬件。像 Unitree 和 Boston Dynamics 确实做出了非常出色的成果。尤其是 Unitree，价格已经大幅下降：Unitree G1 起售价 1.35 万美元，H2 起售价 3 万美元。1X 允许以 2 万美元预订 Neo。这只是我过去工作时使用的一只机器人手的成本的一小部分，而现在你能买到的是一整台机器人。 多模态基础模型与世界模型。所有前沿实验室现在都在用图像和文本训练模型；Google 还在 Gemini 的预训练中加入视频数据。我们有像 OpenAI 的 Sora 2 和 Google 的 Genie 3 这样的模型。这对机器人领域来说是个好消息，因为你完全可以把这些预训练模型作为具身智能（embodied AI）的基础，甚至可能用世界模型在无需大量真实世界数据的情况下训练它们完成多种任务。 巨额资本流入。人们对类人机器人非常兴奋，投资者正在向这个领域大量投入资金。比如 Figure（融资 10 亿美元，估值 390 亿美元）、1X（试图以 100 亿美元估值再融资 10 亿美元）、Neura（也在尝试以 80–100 亿美元估值融资…

在构建一个智能体框架（agent harness）时，最困难的部分之一，就是设计它的行动空间（action space）。 Claude 通过“工具调用（Tool Calling）”来行动，但在 Claude API 里，工具可以用很多不同的原语来构建，比如 bash、skills，以及最近加入的代码执行（想了解 Claude API 上“程序化工具调用”的更多内容，可以阅读 @RLanceMartin 的新文章）。 面对这么多选择，你要如何设计智能体的工具？你只需要一个工具，比如代码执行或 bash 就够了吗？还是你会准备 50 个工具，每个对应智能体可能遇到的一种用例？ 为了让自己更贴近模型的思维方式，我喜欢想象：你被给了一道很难的数学题。你会希望有什么工具来帮助你解题？答案取决于你自己的能力！ 纸和笔是最低配置，但你会受限于手算速度和准确度。计算器更好，但你必须知道如何使用它更高级的功能。最快、最强的选择是一台电脑，但你也必须知道如何编写并执行代码来使用它。 这个框架对于设计智能体非常有用。你想给智能体提供与它自身能力相匹配、形状合适的工具。但你怎么知道它的能力到底是什么？你需要去观察、阅读它的输出、不断实验。你需要学会像智能体一样去“看”。 下面是我们在构建 Claude Code 的过程中，通过认真观察 Claude 得到的一些经验教训。 改进追问能力与 AskUserQuestion 工具 在构建 AskUserQuestion 工具时，我们的目标是提升 Claude 提问的能力（通常被称为 elicitation，即“引出信息/追问”）。 当然，Claude 也可以直接用纯文本提问，但我们发现，用户回答这些问题常常会觉得花了不必要的时间。我们能不能降低这种摩擦，提高用户与 Claude 之间的沟通带宽？ 尝试 #1——修改 ExitPlanTool 我们最先尝试的是：给 ExitPlanTool 加一个参数，让它在输出计划的同时，附带一个问题数组。这是最容易实现的方法，但它让 Claude 感到困惑，因为我们同时在要求它给出计划，又要求它提出关于计划的一组问题。如果用户的回答与计划内容冲突怎么办？Claude 需要调用 ExitPlanTool 两次吗？我们需要换一种思路。（你可以在我们关于提示缓存（prompt caching）的文章里读到更多我们为什么要做 ExitPlanTool…

我有三个儿子，他们都知道我是一个计算机程序员，其中至少有一个对这个领域表达了兴趣。我热爱计算机编程，并且努力把这种热爱传达给我的儿子们、课堂上的学生，以及任何愿意倾听的人。 近来，我越来越频繁地从亲戚、朋友和学生那里听到一个问题： 在人工智能已经出现的今天，我还应该考虑成为一名计算机程序员吗？ 我对此的回答是：“是的，而且……” “是的” 从根本上说，计算机编程关乎两件事情： 使用计算机解决问题在解决这些问题的过程中学会控制复杂性 我很难想象在未来，懂得如何用计算机解决问题，以及如何控制解决方案中的复杂性，会比今天更没有价值。因此，即便有了人工智能工具，我仍然认为这会是一条可行的职业道路。 “你必须自己写代码” 话虽如此，我认为人工智能对初级程序员来说是非常危险的，因为它能够为许多问题高效地生成代码。如果一名初级程序员没有真正学会写代码，而只是生成代码，那么他们其实是在剥夺自己获得那种“身临其境”的代码理解力的机会——那种理解只有在一行一行敲代码、亲自踩坑的过程中才能形成。 因此，我会警告我的学生： “是的，AI可以为这次作业生成代码。但不要让它这么做。你必须自己写代码。” 我会解释，如果他们不写代码，就无法真正有效地阅读代码。而在一个以人工智能为基础的编程未来，阅读代码的能力很可能会变得更加重要。 如果你无法读懂代码，你就会掉入“魔法学徒的陷阱”：创建出自己并不理解、也无法控制的系统。 编程变成提示词，是否就像汇编变成高级语言？ 有些人说，从高级语言转向由AI生成代码，就像当年从汇编语言转向高级编程语言一样。 我不同意这种类比。 编译器在很大程度上是确定性的，而当前的AI工具并不是。给定一个高级语言结构，例如一个for循环或if语句，你通常可以相当确定地预测，在特定计算机架构下（至少在优化之前）生成的汇编代码大致会是什么样子。 但对于基于大语言模型的提示生成方案，却无法做到这一点。 高级编程语言是一种非常好的方式，可以用更少的文本创建高度明确的问题解决方案，这是汇编语言难以做到的。它们消除了大量“偶然复杂性”，留下的（如果代码写得合理）大多是“必要复杂性”。 而LLM生成的代码，往往并不能消除偶然复杂性，甚至可能通过选择不恰当的问题解决方法、走捷径等方式，引入更多的偶然复杂性。 如果你不能读懂代码，你又如何分辨这一点？ 而如果你想读懂代码，你就必须自己写代码。 AI是一个很棒的助教 我还会告诉学生，如果使用得当，AI是一个极其高效的助教。如果你不把它当成代码生成器，而是把它当成帮助你理解概念和技术的学习伙伴，它将极大地促进你的智力成长。 学习计算机编程最困难的事情之一，就是“卡住”。你看不出诀窍，也不知道该从哪里开始，无法取得进展。 更糟糕的是，你可能因为偶然复杂性而卡住：比如不知道如何使用某个工具链，甚至不知道什么是工具链。 这不是你的问题，而是环境的问题。毫无意义地卡住会剥夺你真正学习的时间，甚至会把人从计算机科学这个领域中击退。 （我在伯克利自学Unix时就曾经卡住，这也是我后来退出那里的计算机科学项目的原因之一。） AI可以帮助你跨越这些障碍，如果使用得当，它会是一个很好的助教。我发布过一个AGENTS.md文件，供学生配置编码代理，使其表现得像一个优秀的助教，而不是代码生成器。我鼓励他们以这种方式使用AI。 只要使用得当，AI不必成为阻碍你成长为优秀程序员的因素。 “而且……” 我确实认为AI会改变计算机编程。它的改变可能没有某些人想象得那么剧烈，但在某些根本层面上，它确实会带来变化。 纯粹写代码的价值可能会下降 写代码这一行为本身，可能会相对贬值。 我对此感到有些遗憾。我通常很享受写代码的过程，用（比喻意义上的）双手让某个东西动起来是一件很有乐趣的事情。把代码写好是一门艺术，也是一种满足，其中有许多审美上的选择。 然而，看起来纯粹的代码书写能力，在未来可能会变得相对不那么重要。 当这一点的重要性下降时，我认为其他技能会变得更加重要。 沟通能力 例如，清晰地写作、思考和表达——无论是与大语言模型交流，还是与人类交流——在未来很可能会变得更加重要。许多程序员本来就有文学倾向，而这项技能的价值很可能会随着时间推移而提升，非常值得刻意培养。 阅读书籍、撰写文章或博客，都是有助于提升这方面能力的活动。 理解商业 你还可以将部分精力投入到更好地理解商业（或者政府角色等）上。 计算机编程本质上是用计算机解决问题，而企业里充满了各种需要解决的问题。 有些商业人士看到AI会说：“太好了，我们不需要程序员了！”但在我看来，同样也可以设想程序员会说：“太好了，我们不需要商业人士了！” 我认为这两种观点都很短视。不过，我确实认为AI可能赋予程序员一种能力：在本质上仍然从事编程工作的同时，投入更多时间去理解他们正在解决的现实世界问题（无论是商业问题还是其他问题）。 这与提升沟通能力是相辅相成的。 系统“架构”能力 和许多程序员一样，我对“软件架构师”这个词持复杂态度。我见过一些“架构宇航员”给世界带来了很多痛苦。 不过，找不到更好的词语来形容的话，我认为软件架构能力会随着时间变得更加重要：即有效组织大型软件系统的能力，尤其是控制这些系统复杂性的能力。 对初级开发者来说，这其中的一个难点在于：传统上，良好的系统架构能力来自于构建小模块的经验——最初可能做得不好，但随着时间推移逐渐改进。 我遇到的大多数糟糕架构师，要么是糟糕的程序员，要么几乎没有编程经验。 如果你让AI接管“简单部分”的代码生成，你又如何培养成为优秀架构师所需的直觉？ 这就是为什么我再次强调：你必须自己写代码。 有效使用LLM…

工程已经逃离了代码库。工程工具、工程思维方式以及“工程师”这一身份，正在越来越多地塑造每一个职能岗位。只要你在创业圈子里待得够久，就一定会听到这种“万物工程化”的表达：“哦，我是一个设计工程师。”“我们正在遵循 GTM 工程的最佳实践。”“我需要和他们的销售工程师聊聊具体实现。”这自然会引出两个问题：为什么每个角色都在变成工程师？我是否应该为此感到担忧？本文将回答这两个问题。 所谓工程化，是指工程工具、工程技能以及工程身份向非工程岗位扩散的过程，这一现象由一个不断自我强化的反馈循环驱动：工具改变技能，技能重塑身份，而身份又反过来催生新的工具。以“设计工程师”为例，设计工具已经变得极为强大，它们不再只是用来画线框图。像 Figma、Tailwind，以及嵌入在各种框架中的设计系统，使得设计决策直接影响生产环境中的代码。一个按钮不再只是“一个矩形”，而是一整套具备响应式能力、可访问性支持，并与现有系统保持一致的多种变体。与此同时，这些工具的使用也变得复杂起来。想要真正发挥 Figma 或 Tailwind 的全部能力，你必须理解产品功能、配置方式、语法规则、快捷键、最佳实践、限制条件和各种技术约束，到了某个阶段甚至需要阅读代码。尽管如此，非技术人员还是学会了这些技能。由于工程资源稀缺、迭代速度至关重要，设计师开始学习足够多的技术知识，从而能够独立发布产品。大语言模型的出现进一步降低了门槛，它们可以生成 Tailwind 组件、用户界面甚至完整原型，而无需手写代码。随着技能的不断积累，身份也随之转变。设计师不再把工作交接给工程师，而是自己编写产品代码、调试布局、在设计与性能之间做权衡。此时，仅仅称之为“设计”已经不再准确，“设计工程师”这一标签随之出现，重度用户开始自我认同，像 Vercel 这样的公司开始招聘这一岗位，工具厂商也围绕这一身份进行市场推广，于是循环再次启动。工具改变技能，技能塑造身份，身份又进一步要求新的工具。 那么，为什么工程化偏偏发生在当下？长期以来，人们一直在为各类岗位打造强大的工具，但这一次的不同在于三个因素。首先，大语言模型让复杂、领域专用的工具变得更加可及。如今几乎每一个工具都配备了 AI 助手、MCP 服务器，或者推出了 AI 驱动的替代版本。非技术人员可以更快、更轻松地掌握那些曾经只属于工程师的强大工具，并借此生成应用和原型，自动化并优化市场推广流程，构建和配置复杂的工作流。其次，资本使这一趋势不可避免。工程化本身是一门极具吸引力的生意，它正成为 B2B SaaS 的发展方向。企业愿意为此付费，风险投资愿意为此下注，而且成功的方法论已经逐渐清晰。大量资本涌入这一领域，改善了工具能力，赋予用户更多功能，吸引更多创业者进入赛道，同时强化了对“工程化身份”的市场宣传，从而进一步加速整个循环。第三，身份认同使工程化变得持久。一旦人们开始把自己视为工程师，这个循环就会自我维持。越来越多的非技术岗位开始强调工程能力，工程化赋予个人更大的自主权，也为工程师节省时间。成功的案例鼓励非技术人员扩展技能、更多使用工具，当他们在“类似工程”的工作上投入越来越多时间时，原有的角色身份显得低估了他们的价值与技术含量。于是，人们更认同自己正在构建的事物，以及那些负责构建的人，也就是工程师。新的身份通过博客文章、会议演讲、线下聚会甚至一条推文逐渐固化，新身份的出现又会强化循环，人们采纳它，工具围绕它构建，市场营销强化它，整个周期再次运转。 与此同时，“工程师”这一称谓的含义也在发生变化。过去，工程意味着在边界清晰的领域内掌握特定技能，并经过正式训练与严格门槛筛选。在物理工程领域，这一点仍然成立，因为失败会带来现实世界的物理后果。但在软件领域，失败成本较低，门槛更难维持，边界正在逐渐模糊。“工程”的界定标准正在从“谁被允许建造”转向“谁有想法并愿意真正把它建造出来”。它越来越少地强调对全部理论的掌握，而更多强调将理论付诸实践。对一些人而言，这似乎是一种去专业化，意味着更多自学从业者、更少深度积累以及头衔意义的削弱；但对更多人来说，这是一种能力的扩张，是更大的自主权、更快的迭代速度、更强的杠杆效应，以及更好地将真实、有价值的问题转化为解决方案的能力。 那么，你是否应该为此担心？技术与非技术工作的界线并未消失，而是被重新划定。无论你是否是工程师，最终的赢家都会是那些具备“构建者思维”的人。对于非技术人员来说，不必害怕承担更多“工程化”的任务。工具已经变得更强大、更专业化，许多人已经成功掌握并使用它们，而大语言模型与 MCP 的结合，使学习和操作更多工具变得更加容易。对于工程师而言，整个世界正在投入大量资源，让你变得更加强大。善用这些工具，把自己打造为能够独立完成端到端交付的产品工程师，利用各种工具进行竞品研究、用户访谈、界面设计与产品数据分析。对于创业公司而言，应当为这些新型工程师构建产品，至少要让人们能够真正“做工程”：提供 API，使文档可被机器读取，发布 MCP 服务器，并与其他工具实现连接。工程已经不再局限于代码，它正在成为一种跨职能的通用能力，一种身份认同，也是一种新的构建方式。

下面这段话： 除了忽略训练成本之外，Amodei 在论证中另一个非常可疑的假设，是推理（inference）的毛利率。在他的“风格化（stylized）”例子里，他假设毛利率为 67%，而这恰恰直接决定了他们是否有能力为下一代模型训练提供资金。可当资金更充裕的竞争对手明明知道，他们可以对 Anthropic 施加极大的压力，把推理毛利率压到……比如 30% 时，我们怎么还能假设毛利率会一直这么高？如果 Anthropic 无法从当下这一代模型获得足够的毛利润，那它训练下一代模型的手脚就会被绑住。 在我发布那篇文章三天后，《The Information》报道了 OpenAI 的财务情况，其中有一段摘录让我特别在意： “OpenAI 告诉投资者，其运行 AI 模型的成本——也就是推理（inference）——在 2025 年翻了四倍。因此，该公司调整后的毛利率（adjusted gross margin）——定义为收入减去推理成本——从前一年的 40% 下降到 33%。这低于其对 2025 年设定的 46% 毛利率目标。” 《The Information》提到，OpenAI 认为毛利率下降主要是因为“公司不得不在最后一刻购买更昂贵的算力，以应对其聊天机器人和模型需求高于预期的情况”。这一点确实在某种程度上支持了 Dario Amodei 关于推理与训练之间“地狱级需求预测（hellish demand prediction）”的观点。但很难不去想：即便你把需求预测做得更好，找到“正确平衡”可能仍然同样困难，这未必能缓解毛利率压力。 当然，OpenAI 随后面不改色地承诺，他们预计未来 5 年推理毛利率会提升到 52%–67%。我要强调这一点：**在今天，OpenAI（或任何其他公司）并不能单方面决定今年的毛利率是多少，更别说决定明年、甚至 2030 年的毛利率了。**除了“地狱级需求预测”的挑战之外，模型竞赛本身仍然极其竞争激烈，而这正是当下毛利率最核心的驱动力。 毛利率的本质：定价权与成本结构 归根结底，毛利率的提升主要取决于两件事： 即便你能对推理需求做到完美预测，你资金更雄厚的竞争对手仍然可以选择维持低价——因为他们有许多其他内部现金流来源。这当然可能迫使 OpenAI 与 Anthropic 更快地下调 API 价格，远快于他们愿意的速度。 当更富有的竞争对手（例如 Alphabet）不仅资金更充足，而且成本结构还更优时，这个问题会进一步恶化。原因是…

基于与 OpenAI Codex 团队工程负责人一次对话的洞察：他们如何协作、如何使用 AI、团队结构、开发理念，以及更多内容 引言 AI 不再只是工程师手里的工具，它也正在深刻影响工程团队的组织结构、决策方式，以及软件是如何被构建出来的。 我在许多初创公司和中型公司里都看到了这种变化：它们试图通过创建“AI 原生”的工程团队来调整组织结构。但在我看来，真正把这件事做到位的团队并不多，而 OpenAI 的 Codex 团队是其中最典型、最彻底的例子之一。 在 Codex 应用、IDE 扩展、以及开源编码智能体等产品背后，是一个相对精简的小团队——大约 40 人——却以极高的自治度、速度与信任运行。他们的工作覆盖低层系统工程、大规模分布式基础设施、产品设计、研究与用户体验等多个方向，并且在几乎所有工作中都大量使用 AI。 Codex 团队最有趣的地方不仅是他们做什么，而是他们如何做。他们把 AI 当作工作流的核心层：从规划与入职培训，到代码审查、测试、优先级管理，AI 都深度参与其中。 Codex 团队规模约 40 人 Codex 团队大约 40 人，内部又划分为多个更小的子团队，分别负责不同项目，比如：开源编码智能体、Codex 的 IDE 扩展、Codex 应用本体，以及其他项目。 他们强调授权与本地决策。整体感觉更像“现代版本的贝尔实验室（Bell Labs）”。 个体被充分信任去做决定，因为变化的速度要求他们必须如此。 整个 Codex 团队只有 1 位产品经理，2 位设计师，其余大多是具备不同专长的工程师。 Thibault 提到一个例子，能非常具体地说明他们的产品经理为什么效率惊人。 他们的产品经理为什么能如此高效 Codex 团队的产品工作几乎由一位产品经理在驱动。这位 PM 借助 Codex，把自己“扩展”成了类似…

编译器在计算机科学里占据着一个特殊的位置。它是计算机科学教育中的经典课程。亲手写一个编译器，几乎像是一种成人礼。因为你必须直面软件到底是如何工作的：语言、抽象、硬件，以及人类意图与机器执行之间的边界。 编译器曾经帮助人类与机器对话。如今，机器开始帮助人类构建编译器。 我职业生涯中很大一部分时间都在做编译器与编程语言相关的工作，所以当 Anthropic 发布 Claude C Compiler（简称 CCC）时，我格外留意。我的基本结论很简单：这是真正的进步，是行业的一个里程碑。我们并没有走到世界末日，但这也绝不是纯炒作，所以大家先深呼吸一下。 AI 能构建一个 C 编译器并不“彻底革命”，但它确实揭示了 AI 编程已经走到什么程度，以及下一步可能走向哪里。 在展开之前，我先给出我的核心要点总结： 什么是编译器？为什么它能成为 AI 的基准测试？ 要理解 Claude C 编译器为什么重要，我们得先理解：为什么编译器本身是一个如此“揭示智力”的测试对象——无论是对人类还是对人工系统。 编译器位于多个困难领域的交叉点：形式语言设计、大规模软件架构、严苛的性能约束，以及毫不留情的正确性要求。 大多数应用程序可以容忍一些 bug，编译器不行。一个错误的变换可能悄无声息地产生错误程序，影响无数用户的生产力。编译器的每一层都必须维持严格的不变量，并与其他层配合协作。 历史上，这也是编译器成为计算机科学教育“成人礼”的原因。它迫使工程师跨越抽象层思考：把文本变成结构，把结构变成意义，把意义变成经过优化的机器行为。 这个过程映射到更深的一件事：把人类意图翻译成精确执行。这也是为什么编译器对于 AI 系统整合来说，是一个独特而有趣的基准。 更早一代的 AI 编程工具，在局部任务上已经很厉害：写函数、生成脚本、补齐缺失代码。这类任务主要考验模式识别与短程推理。 Claude C 编译器则代表了不同层级的进展。它展示了一个 AI 系统能够在整个工程系统范围内保持连贯性：协调多个子系统、维持架构结构、通过测试与失败在时间维度上迭代逼近正确性，并在复杂反馈回路中运作。AI 正在从代码补全走向工程参与。 更深层的原因在于：编译器的工程架构通常高度清晰且结构化。编译器有分层抽象、一致命名、可组合的 pass，以及确定性的反馈标准（“能工作”或“不能工作”，成功标准很清楚）。这些属性让编译器对人类可学，也让在海量源码上训练的机器学习系统同样更容易“学会”。 从这个角度看，CCC 其实也是对几十年软件工程实践的一次验证：编译器工程师发展出的抽象足够结构化，以至于机器如今能够在其中推理并行动。这是一个非常惊人的里程碑。但它同样暗示着一个重要限制。 走进 Claude C 编译器内部 CCC 最有趣的一点在于：Anthropic 公开了完整的源码历史。与许多 AI 演示不同，这不是一个“包装好的成果”或单一基准分数，而是一个任何人都能检查的工程产物：整个仓库，包括提交历史、设计文档与未来计划，都可以直接审阅。这意味着我们能真正研究系统是如何构建一个编译器的。我也确实花了一些时间做了这件事。 第一个重要提交几乎是“一次性”把系统的基本架构定了下来。从一开始，CCC 就遵循经典编译器结构。仓库里的主要子系统都配有相当出色的设计文档，包括： 整个仓库里做出的选择，几乎都反映了成熟的编译器实践：大学课程里教的东西，以及…

引言 你的 PostgreSQL 数据库不断增长，即使表中的行数基本保持不变。磁盘占用持续上升，查询开始变慢，你开始怀疑到底发生了什么。 这不是 Bug——这叫做 bloat（膨胀），而且它是 Postgres 核心设计的一部分。 要理解它为什么会发生，我们必须跟随一行数据的生命周期：从它被写入物理文件的那一刻开始，到它变成“死亡空间”为止。这段旅程始于最底层的物理存储结构：页（Page）与元组（Tuple）。 目录 1. 物理层：页与元组 Postgres 将表存储为磁盘上的文件，这些文件被划分为固定大小的页（8KB 块）。在每个页内部，存放的是 元组（tuple）——也就是你的行在磁盘上的物理版本。 可以把一个页想象成一个容量有限的盒子。当你插入一行数据时，Postgres 会把一个元组写入第一个有空闲空间的页。如果该页已满，就会分配一个新页并追加到表文件末尾。 每个元组不仅包含你的业务数据，还包含元数据，用于决定哪些事务可以看到这条数据（这将在 MVCC 部分解释）。 这种基于页的架构对膨胀的形成有关键影响： 💡 关键洞察 磁盘使用量由元组版本的总数决定，而不是你能查询到的行数。一个有 100 万行的表，如果存在大量死亡元组，可能和一个 1000 万行但干净的表占用同样的空间。 但页本身并不会导致膨胀。真正的根源，是 Postgres 如何处理并发：MVCC。 2. MVCC 与旧数据为何不会立即消失 Postgres 使用 多版本并发控制（MVCC），使读操作不会阻塞写操作，写操作也不会阻塞读操作。 机制很简单：不原地修改数据，而是创建新版本。 在物理层面发生的事情如下： UPDATE 不会修改原数据 当你更新一行时，Postgres 不会找到原有元组并修改它，而是创建一个全新的元组（可能位于不同页）。旧元组会被标记为过时，其 xmax 字段记录执行更新的事务 ID。 DELETE 不会真正删除数据 删除一行时，Postgres 不会从页中移除元组，只是设置 xmax 表示哪个事务删除了它。数据仍然留在磁盘上，占用空间。 结果：元组不断累积…

目前，Project Silica 的硬件距离商业化还差一步。 长期归档存储一直面临诸多挑战。我们希望存储介质既拥有极高的密度，又能在数百年甚至更长时间内保持稳定，并且理想情况下，在未被访问时不消耗任何能源。围绕这一目标，业界提出过许多设想——甚至连 DNA 都曾被考虑过——但其中一个最简单的思路，是将数据刻写进玻璃中。许多类型的玻璃在物理和化学层面都非常稳定，而且在其内部刻写结构相对容易。 此前已经有大量前期研究，展示了玻璃存储系统的不同技术环节。而在本周三发表于《Nature》的论文中，微软研究院宣布推出 Project Silica，这是一个完整的工作系统演示，能够在小块玻璃板中读写数据，其存储密度超过每立方毫米 1 Gigabit。 写入玻璃 我们通常认为玻璃易碎、容易破裂，甚至有人误以为玻璃会在几个世纪内缓慢“流动”——尽管后者其实是个神话。事实上，“玻璃”是一类材料，不同的化学物质都可以形成玻璃态结构。通过选择合适的原材料，可以制造出一种如研究人员所描述的那样“在热学和化学上高度稳定，并且能够抵抗水汽渗透、温度波动以及电磁干扰”的玻璃。当然，它仍然需要小心处理以避免物理损伤，但在长期存储的需求下，玻璃提供了理想的稳定性。 将数据写入玻璃，理论上只是“刻写”而已。但刻写传统上是一个缓慢的过程，这一直是挑战之一。飞秒激光的出现改变了这一局面。飞秒激光的脉冲持续时间仅为 10^-15 秒级别，每秒可发射数百万次脉冲。这不仅显著缩短了写入时间，还能将刻写精确聚焦在极小区域，从而提高潜在的数据密度。 读取数据则有多种方案。我们已经成功利用激光从光盘中读取数据，尽管速度较慢。理论上，只要能够识别玻璃内部刻写的微小结构，就可以实现读取。 在这些技术基础之上，Project Silica 在理论层面已经具备条件。关键问题在于：如何将这些技术整合为一个可运行的系统。出于谨慎考虑，微软决定以两种不同方式来回答这一问题。 构建真实系统 这两种方案的核心区别，在于如何将一个数据单元（称为“体素”，voxel）写入玻璃。 第一种体素方案基于“双折射”（birefringence）原理。双折射是指光子在材料中的折射率取决于其偏振方向。利用偏振激光，可以在玻璃中刻写出具有双折射特性的体素，并生成小于衍射极限的微结构。具体实现中，首先用一个激光脉冲在玻璃内部形成椭圆形空洞，然后再用第二个偏振脉冲诱导双折射特性。体素的“身份”由椭圆的方向决定。由于可以区分多个方向，每个体素就能够存储多于 1 bit 的信息。 另一种方法则通过调节激光脉冲能量，改变材料的折射程度。同样，这些体素也能够区分超过两种状态，从而在单个体素中存储多个数据位。 微软 Flight Simulator 的地图数据被刻写在 Silica 存储介质上。图片来源：Microsoft Research 读取数据时，Silica 使用能够识别折射率差异的显微镜技术。对于显微成像爱好者来说，这意味着他们采用的是“相差显微镜（phase contrast microscopy）”。显微成像的能力决定了在一块玻璃中可以堆叠多少层体素。刻写时，各层之间保持足够间距，确保显微镜每次聚焦时只对准单一层面。刻写过程中还会加入特殊标记符号，帮助自动化显微系统精确定位玻璃中的特定区域。随后系统逐层调整焦平面，逐步扫描堆叠结构并捕获包含不同体素层的图像。 为了分析这些显微图像，微软使用了卷积神经网络。该模型会整合位于焦平面内以及临近焦平面的图像数据。之所以有效，是因为邻近体素会以微妙方式影响当前体素的呈现形态，而 AI 系统在获得足够训练数据后，可以识别这些细微差异。 系统的最后一个关键部分是数据编码。Silica 在存储原始比特流之前，会加入低密度奇偶校验码（LDPC）进行纠错——这与 5G 网络所使用的纠错方式相同。随后，相邻比特被组合成符号，以充分利用体素能够存储多位信息的能力。当符号流生成后，数据就可以被写入玻璃。 性能表现 写入过程仍然是系统的瓶颈。因此，微软开发了能够同时使用四束激光对单块玻璃进行写入的硬件，并控制热量不过度积累。这使写入速度达到 66 兆比特每秒。研究团队认为，未来还可以再增加多达十几束激光。 之所以需要更高写入速度，是因为单块玻璃板的存储容量可高达 4.84TB（尺寸为 12 厘米 × 12…