能力现状

分档的依据是出错后果，不是演示效果。能力进步和可靠进步是两条速度不同的线，别把它们当成一回事。

判断一个能力能不能用，依据是出错以后会怎样，不是演示有多好看。这句话听着像常识，但团队讨论「AI 能不能做这件事」时，用的几乎总是后一个标准。

读完你能回答：

• 一个演示很惊艳的能力，你凭什么判断它现在还不能依赖？
• 为什么同一个模型能解出竞赛数学题，却数错表格里有几行？
• 「能做出一次」和「能稳定做一万次」差在哪一段工作上？

档位由出错的代价决定

问「AI 到底行不行」，很难问出答案。更有效的做法是拿手上这件事去对档：它错了会怎样，决定了它能放在哪一档。

• 第一档，当副驾驶用。 改写、摘要、翻译、抽取、代码补全、起草——共同点是输出能被快速检查，错了重做一次的成本极低。
• 第二档，加上护栏才用。 知识问答、文档分析、受控的工具调用、短流程——要给权威材料、限定可用工具，再配上评估、出处和人工兜底。
• 第三档，目前只能当演示。 长时间无人值守、高风险审批、开放网页上的自由操作——权限和范围都要严格收窄，关键动作必须有人确认。

第一档凭什么这么分，值得多看两眼。「用大模型处理发票」这句话本身不带档位——把发票上的字段读出来填进表单，它落在第一档；让它在没有人看着的情况下直接生成并发出付款指令，它就到第三档去了。技术没换、模型没换，挪动档位的是做错之后要付的代价。

还有一条常被漏掉：第三档说的是「眼下还托付不了」，不是「以后都不能用」。 落在这一档的能力，演示往往特别好看，因为演示只需要一条走得通的路。它短的不是本事，而是路走不通时该怎么办。

每一格能力都得单独验证

人对本领的判断习惯沿一条连续的线走：一个人既然解得出奥数题，算个百分比自然不在话下。这个默认站得住，是因为人的本领一层压一层地垒上去。模型身上不成立。

它的强弱由语料的统计分布塑造。某类文本量大、反馈密，对应那一块就突出，至于人眼里哪件事算「难」，它并不照这个来分配本事。于是出现这样的组合：竞赛数学题解得出来，表格里有几行却数不清；一整个模块写得下去，截图上的小字却认不出。业内给这种形状起的名字，是锯齿状能力。语料决定它偏向谁、缺哪一块，这是同一件事的另一个说法。stanford-ai-index

这既不矛盾，也不能归到它「不上心」。它给出的只是一条操作规则：能力按格存放，验证得一格一格做，旁边那一格的结论借不过来。「这么难的它都会，简单点当然也行」——恰恰是这种顺推，在模型身上最容易失手。上面那三档之所以不能靠演示效果去填，根子就在这里。

落差还有第二层。做出一次和每次都稳，从来不是同一件事。 演示只要有一条路走得通就算交差；产品要接住的，是那条路走不通时的全部分支。两者之间隔着任务怎么拆、效果怎么评、权限怎么给、出错怎么退、谁来复核——把模型变成产品，内容全在这一段里。 这一段产出不了惊艳的演示，因此最常被略过。

可靠性是另一条线，走得慢得多

每一轮能力跃升都遵循同一个顺序：先出现令人惊艳的演示，很久之后才出现评估、流程和安全工程。

原因不神秘。演示的成本是几天，可靠性工程的成本是几个季度——前者一个人就能做，后者要有人定义验收、收集失败样本、设计回退路径、盯上线之后的表现。所以在新能力刚出现的那段时间里，你看到的几乎全是演示，而演示的数量会被误读成可靠性的证据。

于是每次跃升都会重演同一幕：一批人相信「这次不一样，可以直接上生产」，然后在上线后的头几周里发现，真正卡住他们的不是模型不够聪明，而是没人定义过什么算完成、出错怎么发现、发现了怎么收回。

这不是让你对新能力悲观。它只是把判断顺序摆正：先看失败的后果，再看演示的效果。 前者决定你能放多少手，后者只说明上限在哪。

链条越长，成功率越是被乘出来的

三档之中，被高估得最厉害的就是 Agent。

这里并没有发生「模型忽然有了自主意识」这种事。真实情形是它在同一个循环里把一组动作重复执行：挑一个工具、看返回了什么、再决定接着做什么。于是整体成功率按连乘计算——每一步都有九成五的把握，连着走十二步，整体也只剩一半多一点。 演示给你的是一条顺利的路，你的产品要接住的现实则是：每一步都可能出岔，而且岔子会一层层叠加下去。

出路不在于等模型变强，而在于把链条剪短：长任务切成若干段，每段收尾处放一个能自动判定的检查点，过不去就交回给人。这里有个前置条件经常被跳过——验证能力得先有，放权才谈得上。 链条剪短、检查点自动化、失败能退回，三样都齐了，Agent 才算从第三档升进第二档。

两个问题，划出档位边界

拿不准某个功能该推到第几档，就把下面两个问题过一遍。它们同出一源，也是三秒三问的简化版：

它给的答案能不能被验证？ 能拿数据库比、有规则可依、或者找得到人帮你核一遍，自动化才立得住。既没法验证、出错又严重的结论，不能直接端给用户。

失败是不是可逆的？ 会议纪要写砸了重新生成一版就行；换成批量改客户账单、清理生产库、给全体用户发通知，就得先设一道闸。可逆的部分可以放手，不可逆的部分只能卡在人这里。

两条边界都划清楚之后，放权按顺序走：先只让它提建议，再让它填草稿，最后一步才放开执行。落到工程上就是两件事：先把「什么算完成」写成能机械判定的判据，先定义完成，再写第一行代码讲的是怎么定；再把放权过程拆成有回退的闸门，上线不是开关讲的是怎么发布。自治不是一次授权，是一段一段交出去的。

最后一句提醒：「已经能用」和「还只是演示」的边界一直在移。上面三档是本文的归纳，不是任何报告的结论；模型能力和可靠性两条线的速度不同，做决定前先回到你自己的验收标准上。stanford-ai-index-2026