红杉最近连续发了两篇值得读的文章，一篇是 Julien Bek 的 Services: The New Software，一篇是 Jack Dorsey 和 Roelof Botha 的 From Hierarchy to Intelligence。读完以后，一个判断越来越清晰：今天很多 AI 技术能力已经先到了，但组织接口、业务逻辑和评估体系还没有跟上。
这里说的组织接口，不只是人事上的汇报关系，也包括谁定义目标、谁判断结果是否达标、谁有权限让系统执行、出了问题之后谁承担后果。模型能力在往前推，成本在往下掉，但另一些部分的变化速度远慢于技术迭代。预算归属仍然按旧的部门线划定，授权边界在合同和流程里写死，审计要求由监管机构和行业标准决定，专业责任由持牌个人承担。这些约束各自有独立的演化节奏，不会因为模型变强就自动跟上。
红杉这两篇文章值得读，原因在于它们把这个落差说清楚了。一篇讲产品单位在变化，一篇讲组织单位在变化。放在一起读，能看到同一件事的两面。
下面先把两篇文章各自在讲什么梳理出来，再讲它们共同指向了什么，以及哪些问题仍然是 open question。
Julien Bek 这篇文章的核心命题：copilot 卖的是工具，autopilot 卖的是工作本身。
他用了一个很直观的例子。一家公司每年花一万美元买 QuickBooks，花十二万美元请会计师。下一代公司的做法不是再卖一个更好的记账软件给财务团队自己操作，而是直接把记账、对账、月结、出报表这整套工作交付掉。客户买的不再是工具，而是账结好了、报表出来了这个结果。
文章沿两个维度展开。第一个是 intelligence 和 judgement 的区分。Intelligence 指的是规则复杂但终归可以被规则覆盖的工作，比如写代码、翻译规格、做医疗编码；judgement 是需要经验和品味的决策，比如决定下一个 feature 做什么。Bek 认为两者的边界在移动，今天的 judgement 会变成明天的 intelligence，但这个转化是渐进的。
第二个维度是市场进入策略。Bek 的判断是 autopilot 的切入点不是直接替代公司内部岗位，而是先替代已经存在的外包合同。理由很直接：如果一项工作已经被外包，说明公司已经接受外部执行，有现成的预算线，买方本来就在为结果付费。替换外包是换供应商，替换内部编制是组织调整，前者的阻力小得多。他引用了一个数据：企业每花一美元在软件上，就有六美元花在服务上。按这个比例，autopilot 面对的市场空间远大于 SaaS。
在此基础上，Bek 给出了一张市场地图，按 intelligence 占比和外包比例对十多个垂直领域做了排序：保险经纪、会计审计、医疗账单、税务咨询、法律文书、IT 托管、招聘，等等。每个领域他都列举了已经出现的公司，从 Harvey 到 WithCoverage 到 Anterior。
这篇文章把一个很多人模糊感受到的趋势讲得具体了：产品的计价单位正在从 seat 和 feature 转向 workflow 和 outcome。对正在做 AI 产品的人来说，这个框架迫使你重新审视自己的产品到底在卖什么。
Jack Dorsey 和 Roelof Botha 的文章从组织侧切入，讲了一个更大胆的命题：层级制是一个两千年的信息路由协议，AI 可以直接替代它的协调功能。
文章从罗马军团讲起。罗马军队把士兵编成八人小队、百人队、联队、军团，每一层都有指挥官负责汇总信息和下达指令。这个组织形式的核心约束是 span of control：一个人能有效管理的下属数量有限，所以层级越深，信息流越慢。普鲁士总参谋部是现代中层管理的原型，美国铁路催生了组织图，泰勒把工厂变成了科学管理实验室，曼哈顿计划证明了跨职能协作的威力，麦肯锡推广了矩阵组织。两千年来，所有组织创新都是在 span of control 这个约束下做权衡。
Dorsey 和 Botha 的主张是：AI 可以打破这个约束。他们的方式不是给每个人配一个 copilot，而是把整个公司重构为一个智能体。以 Block 为例，它的架构有四层：能力原子（支付、借贷、发卡等基础构建块），世界模型（替代管理层做信息路由，包括公司世界模型和客户世界模型），智能层（在特定时刻为特定客户组合能力），界面（Cash App、Square 等交付面）。
文章里有一个值得注意的细节。Block 描述了一个场景：一个 Square 商户的税务申报即将到期，同时它的 Cash App 贷款额度快要过审。传统公司里，这两件事分属不同部门，彼此不知道。在 Block 的架构里，智能层识别到这个时刻，主动组合了税务工具和信贷能力，推送给商户。没有产品经理决定做这个功能，能力已经存在，智能层识别时机并组合了它们。
组织层面，他们把角色收敛为三种：IC（深度专家，世界模型提供以前只有管理者才有的上下文），DRI（任期制的跨领域负责人，比如 90 天为一个周期），player-coach（取代传统管理者，既做实际工作又培养人）。文章明确说：不再需要永久性的中层管理层。
产品路线图也被重写了。传统的 roadmap 是 PM 和管理层根据判断排列优先级，Block 的做法是看智能层在哪里失败：当它无法组合出解决方案时，那个 failure signal 就是 roadmap。
这篇文章值得读的原因在于，它不是在泛泛地说 AI 会改变组织，而是给出了一个具体的架构描述和角色定义。它把组织设计从管理哲学拉回到了信息系统设计的范畴，也让很多原本抽象的讨论第一次变得可以具体展开。
把两篇文章放在一起，能看到一个共同的判断。
Bek 说的是产品侧的变化：AI 产品的计价单位从工具变成了工作结果。Dorsey 和 Botha 说的是组织侧的变化：公司的协调机制从人类层级变成了由世界模型和智能层驱动。两者都建立在同一个前提上：intelligence 变便宜了，便宜到可以用它替代以前需要人来做的协调、执行和判断。
Bek 从产品经济学推导出 autopilot 是更大的市场；Dorsey 从信息论推导出层级制可以被 AI 替代。一个讲的是公司和客户之间的接口变了，一个讲的是公司内部的协调接口变了。方向一致，切面不同。
这个方向大概率是对的。模型能力在进步，成本在下降，经济压力推动着从辅助到执行的转变。但两篇文章都有一个共同的特征：它们把这个转变描述为主要由技术能力驱动的过程。模型够强了，所以可以卖结果；模型够强了，所以可以替代层级。
我的判断是，真正决定这个转变速度的，不只是技术能力，而是技术和组织接口之间那层尚未成形的中间层。也就是下面这些问题。
技术上从 copilot 到 autopilot 可能只是能力梯度的提升，但在组织和制度层面，这是一次根本性的转换。它涉及的问题远不止法律和合规，虽然法律合规是其中很明显的一部分。
从建议到执行是一次责任迁移。 在 copilot 模式下，AI 是工具，人对输出负责。律师用 Harvey 起草合同，律师签字；会计用 AI 做账，CPA 盖章。责任链和以前用 Word、Excel 没有本质区别。在 autopilot 模式下，AI 卖的是结果。当结果出错时，客户追责的对象从使用工具的人变成了提供结果的系统。但这个系统背后没有传统意义上的职业资质、职业保险和法律主体。这个空白在两篇文章里几乎没有被处理。
责任归属只是问题的起点。更深层的问题是以下几个。
怎么知道 AI 的表现够好到可以让它做决策？ 这个问题看似简单但极难回答。Bek 提到法律领域的工作产品足够标准化，质量可以被验证。但标准化和可验证之间隔着很大的距离。在会计领域，什么叫正确是有明确定义的，GAAP 这样的准则和审计标准提供了参照系。但在保险报价、法律策略建议、招聘筛选这些领域，什么叫达标本身就是一个判断，而这个判断目前由有经验的专业人士做出。当 AI 接管执行时，这个判断标准由谁定义、如何校准、多久更新一次？
evaluation 的 benchmark 怎么建？ 很多服务领域的质量评估不像软件测试那样有确定性的 pass/fail 标准。一份保险报价是否合理，取决于对风险的理解；一份法律建议是否恰当，取决于对客户具体处境的判断。这些 benchmark 的构建需要领域专家的参与，需要大量历史案例的回溯，需要对 edge case 的系统梳理。这更像是传统 consulting firm 和行业协会做的事情，而不是工程团队可以独立完成的。Bek 的市场地图按 intelligence 占比排列垂直领域，但没有讨论在每个领域里 evaluation 体系的成熟度。而这个成熟度可能才是决定 autopilot 能多快落地的关键变量。
这些工作越来越像管理认知，而不是软件工程。 当我们讨论 AI 如何定义执行边界、如何做质量验收、如何分配资源时，这些问题和传统的运营设计高度同构：定义 SLA、设计 escalation 流程、确定 sign-off 权限。Dorsey 和 Botha 的文章用技术语言重新描述了它们（世界模型、智能层、failure-driven backlog），但底层要回答的问题并没有因为换了术语就消失。如果把 Block 的架构翻译回传统管理语言，它是一套自动化的运营决策系统加一个非常扁平的人类治理层。技术部分（模型、API、数据管道）可以工程化，但治理部分（标准谁来定、异常谁来处理、后果谁来承担）本质上是组织设计和业务判断的问题。
最终谁拥有业务判断？ Bek 区分了 intelligence 和 judgement，认为 judgement 会逐步被数据化。Dorsey 描述了一个 failure signal 自动生成 roadmap 的世界。但在实际的商业环境里，很多重要的判断无法还原为数据和规则。比如在保险领域，是否承保一个边界案例，既涉及精算模型也涉及商业策略和客户关系；在法律领域，是否采取某个诉讼策略，需要权衡法律风险、时间成本和客户的商业目标。这些判断目前由有资质、有保险、可被追责的专业人士做出。当 AI 接管这些判断时，问题不只是法律意义上的归属：谁确认这个判断是对的，依据什么确认，确认错了谁兜底。
Block 的案例有多大的普适性？ Dorsey 和 Botha 以 Block 为核心案例，但 Block 有几个大多数公司不具备的条件。它是双边交易平台，Cash App 加 Square，每笔交易都能看到买方和卖方。金融交易数据是信噪比最高的行为信号之一。所以 Block 的世界模型建立在一个质量极高的数据基础上。对于没有类似高频、结构化数据的公司，世界模型的质量取决于什么信号？如果可用信号的质量不够，那个世界模型可能退化为一个更高级的仪表盘：看起来像智能层在协调，实际上人还是在做关键判断，只是换了一个界面。这不是坏事，但和文章描述的”公司即智能体”差距很大。
这些问题没有现成的答案，但并非完全无从下手。下面几个方向值得持续关注。
evaluation 体系可能是真正的基础设施缺口。 从 copilot 到 autopilot，最核心的过渡条件不是模型能力，而是有一套可信的方法来判断模型输出是否达标。这个 evaluation 体系在不同领域有完全不同的形态：会计有 GAAP，医疗编码有 ICD-10，但法律建议、管理咨询、招聘决策的 evaluation benchmark 远未成形。谁先在某个垂直领域建立起可信的 evaluation 标准，谁就更接近拿到那个领域从 copilot 走向 autopilot 的入口。这个方向的难度在于，它需要领域专家和技术能力的深度结合，而且成果不够显眼：它既不是一个更强的模型，也不是一个更好看的 demo。
授权和审计可能需要被产品化。 目前大多数 AI 产品对执行边界的定义依赖人工口头约定或模糊的 system prompt。但当 AI 从建议走向执行，执行边界需要变成系统的一部分：可被配置、可被追溯、可被审计。同样，当 AI 执行了一个动作之后，需要有完整的记录来回溯它看到了什么、为什么这么做、改了哪些状态。今天很多公司把这些功能当作合规附赠品，但长期来看，授权管理和审计追踪可能本身就是客户愿意付费的能力，而不是 autopilot 的附属品。
intelligence 和 judgement 之间的边界是动态的，但移动速度在不同领域差异巨大。 Bek 承认今天的 judgement 会变成明天的 intelligence，但没有展开讨论这个转化需要什么条件。在代码领域，这个转化很快，因为代码有明确的正确性标准（编译通过、测试通过）。在法律、保险、管理咨询领域，这个转化慢得多，原因各不相同：法律受判例体系和司法管辖区差异约束，保险受精算标准和监管审批约束，管理咨询的输出质量高度依赖对客户具体情境的理解，缺乏通用的验证基准。对 builder 来说，选择在哪个领域、以什么方式加速这个转化，可能是一个比”把 copilot 升级为 autopilot”更精确的产品问题。
从 copilot 到 autopilot 中间可能有一个被低估的过渡形态。 不是人直接把执行权交给 AI，也不是人事事审批，而是一种 AI 执行、系统约束、人类监督的混合模式。在这个模式里，AI 在明确的边界内自主执行，边界由业务规则系统而非 system prompt 定义，异常情况自动 escalate 给人类，人类的角色从逐条审批变成定义规则和处理异常。这可能比纯 autopilot 离商业化更近，也比纯 copilot 更有价值。
context infrastructure 可能是长期护城河。 如果 intelligence 持续商品化，真正稀缺的资源可能不在模型层，而在可被审计的业务上下文、可被验证的执行历史、经过授权的操作边界。这些东西的积累需要时间、需要领域深度、需要和客户的业务流程深度绑定，很难被竞争对手简单复制。模型能力是算力和资本的函数，这些上下文资产是时间和信任的函数。
红杉这两篇文章描述了一个 AI 直接交付工作结果、智能替代层级协调的方向。这个方向大概率是对的，经济压力、模型能力和客户期望都在推动它发生。
但对我来说，这两篇文章最有价值的地方，不是它们描绘了一个多么完整的终局，而是它们把真正困难的部分暴露出来了：当技术能力已经到位时，组织接口、评估体系、责任归属和业务判断的所有权怎么跟上。
这不只是法律和合规问题，也不只是工程问题。它涉及 evaluation 怎么定义、benchmark 怎么建、执行边界怎么管理、业务判断的所有权怎么分配。这些问题的答案更可能来自领域经验和组织设计，而不是纯粹的软件工程。
对我们来说，值得持续关注的不是 autopilot 何时全面取代 copilot，而是在这个过渡过程中，哪些基础设施层（evaluation、授权、审计、context）最先成熟，以及我们自己的工作流和产品设计应该如何为这个过渡做准备。