房间里的大象：AI大部分输出根本没被用户采纳，都浪费了

如今，每个人都感觉 AI “ 特别厉害 ”、“ 特别有用 ”。

但实际上，我们应该警惕一件事：AI 产品很容易给工作带来一种 “ 虚假的生产力膨胀 ” 。

在开发者群体中，AI 编程已经有了很高的采用率。比如据 IDC 2025 年 6 月发布的《 中国市场代码生成产品评估，1H25 》，彼时美国已有 91% 的开发者使用 AI 工具，而中国开发者的 AI 覆盖率在 30% 。

但另一方面，有一个核心指标却鲜被提及，这个指标其实更加接近个人和企业是否接受 AI 的核心目标，也就是 ROI 的提升。

这个指标叫采纳率。

采纳率是指，AI 生成的所有内容中，人类最终采纳的内容量的比例。比如 AI 生成了 1000 行代码，人类采纳了其中 300 行，那采纳率就是 30% 。

对内容量的量化方式可以有很多种，可以是最精细的 Token 级别，可以是代码行数，也可以是程序员在使用 AI IDE 时 Tab 键采纳数的占比，甚至是代码库中由 AI 生成的功能模块数的占比等等。

比如，基于 Zoominfo 2024 年 11-12 月的内部调研显示（ 团队涉及 400 多名开发者 ），他们对 GitHub Copilot 生成的代码的平均采纳率为 20%（ 按接受代码行数衡量 ）。

图源：https://arxiv.org/abs/2501.13282

基于 SoftDoc 2025 年上半年的内部调研显示，该公司的 AI 生成代码建议被接受比例在 13% 到 21% 之间（ 按接受代码行数衡量 ）。

图源：https://softdocs.com/blog/measuring-generative-ai-coding-adoption-in-softdocs-engineering

最新数据由 DX AI 提供，他们发布的《 AI-assisted engineering: Q4 impact report 》（ 对 13.5 万多名开发人员的分析 ）显示，合并代码中有 22% 是由 AI 编写的。

所以，按照目前公开数据显示，虽然从 24 年至今大家觉得 AI 一直在变强，但 AI 编程工具的输出采纳率总体还是偏低的，在 20% 左右。

并且，目前关于 AI 输出采纳率的相关数据极少。

知危接触并询问国内一些大模型厂商的工作人员，未能得到相关数据。并且不管是使用方还是供应商，都认为这个指标是不容易衡量和获取的。

这一点不难理解，如果每一个用户都回顾一下自己长期使用 AI 的经历，肯定能感受到自己在很多场景下对 AI 输出的采纳率其实并不高，但 AI 即时反馈的特性、类似抽盲盒的体验简直让人上瘾，使得人们醉心于跟 AI 来回纠缠或大量抽卡，很难注意到实际采纳率。

至此，AI 输出内容的采纳率实际上成了 “ 房间里的大象 ” 一般的存在，它很重要且不容忽视，但由于大家对 AI 的狂热，人们选择性的忽视掉了这个问题。

AI 产品设计师 John 告诉知危，“ AI 输出采纳率是需要被行业重视的，因为现在网络充斥着大量 AI 生成的低质量内容，很多发布者不关心内容是否对用户有价值。但 ‘ 是否提供价值 ’ 应该是所有产品需要面对的问题，也包括 AI 产品。”

“ 如果继续靠点赞、点踩这种方式，本身的边际效益已经很低，在现有的 AI 产品交互方式下，用户很少去做这种反馈。”

John 认为，采纳率指标对衡量 AI 赋能程度、采用 AI 的实际 ROI、资源浪费程度、合理使用 AI 的重要性非常高，“ 并且不仅是采纳率本身，更是要在意定义 ‘ 采纳 ’ 的逻辑，即 ‘ 我因为什么而觉得这个结果有用 ’。”

“AI 产品很容易给工作带来虚假的生产力膨胀，无论是因为大环境的 FOMO，还是因为过于放任 AI 自主执行导致项目失控的沉默成本，有许多的 ‘ 采纳 ’ 其实是个体为了迎合自己的某种情绪而做的，或是为了 ‘ 采纳的结果 ’ 而制造出来的问题。做的越多一定会产生更多要解决的问题，不想清楚的话就会在解决这些新问题的 ‘ 动作 ’ 里麻痹自己。”

当然，采纳率指标本身不能直接代表最终的目标，“ 单从采纳率这一个角度很容易迎合越来越多的 ‘ 生产力似乎提升了 ’（ 采纳高 ），但是人越来越忙且没真正带来什么改变。这时，实际 ROI 和资源浪费程度等指标就是一些很重要的客观补充视角。”

对于 AI 产品企业而言，需要更多意识到，采纳率最终会极大影响用户付费意愿。

“ 我经常对某知名通用型 Agent 产品有一个评价：如果它的 Token 价格能便宜 10 倍，它其实有机会成为团队内部做 Web Demo 的主流工具。”

“ 当然这句话还需要加很多前置定语，除了成本太高，它在使用过程中也需要大量试错，采纳率低，而这些消耗其实和最终的交付物并不直接相关，更多是Debug、潜在的网络崩溃等问题。”

“ 对于很多个人项目而言，它们往往是个人对现有的解决方案有些不满的地方，想要做出一个完美适配自己使用需求的体验。但这些 ‘ 不满的地方 ’ 往往没有那么疼，价值有限。尤其是假设我们把这种场景从小部分懂技术的极客推向大众的时候（ 所谓用动态定制 App 代替传统静态 App），Vibe Coding 所带来的不确定终点的 Token 投入 （ 产品往往都没有一个预算估计，可能上百美元 ）、潜在的时间与情绪投入，很容易就让人放弃个人的小需求，向现有产品妥协。”

另一方面，从模型角度，采纳率取决于模型在上限和下限的突破。宣传上大家一般更强调上限，但保证了下限才能让模型真正成为生产力，这其中的典型是代码生成领域的 Claude，图像生成领域的 Nano Banana，以及视频生成领域的 Seedance 2.0，实际上这几款模型也是用户付费意愿在第一梯队的。

John补充道，“这里需要划分劳务型（Labor Work）产品和信息型（ Informative ) 产品。对于劳务型产品，比如编程类 Agent，稳定性和可用性肯定是最基本的决定因素。我不可能为了一个不稳定的产品付费或者时间。”

“ 对于信息型的产品，比如问答或 AI 搜索，我是可以接受不稳定但可能会有极限表现的产品的，虽然不一定会付费，但因为不像劳务型产品一个方向只用一款，信息型我永远会用好几个产品来丰富视角和信源。所以我会把这样的产品尽可能加到我的‘信息池’里，不采纳也没关系。”

下文中，知危也将展示从不同企业零星地获得的一些相关数据，这些数据和上述公开数据相去甚远，或偏高或偏低，或者只能定性描述，却也值得注意。毕竟大模型发展太快，一个验证可行的场景真正的核心影响因素也还没被探索明白，以及还有大量未被验证的场景。

在个体体感上来讲，一名字节员工程磊（ 化名 ）告诉知危，其用 AI 写代码的采纳率基本上是 100%，即便有些微不足，也会用 Agent 来修改，“ 今年年后我已经没有印象自己亲手写过代码了。”

在程磊看来，采纳率本质上依赖模型能力，另外也取决于公司（ 或员工自己 ）肯不肯给员工花钱用最新最可靠的模型来完成任务，“ 我现在用的模型是 Claude Opus 4.6 + GLM5 + Kimi2.5，都是最新的、最贵的，会用在所有写代码场景。当然目前 AI 的视觉模态还不行，比如无法准确地操作和测试 GUI。” 而从当前行业更一般的认知看来，采纳率的主要影响因素不只是模型能力本身，还有企业的流程成熟度、信息化基础、管理模式等。

白鲸开源 CEO 郭炜则配合知危对公司内部员工使用 AI 编程的采纳率做了初步的调查，其中使用场景分为问答和 Agent。

数据显示，对于问答场景，主要使用 ChatGPT，调用失败率几乎为零，低复杂场景下 AI 输出采纳率（ 只看答案是否带来信息增益 ）接近 100%，中等复杂场景约 80%，高复杂场景约 60%，其中，三种复杂度场景的任务量占比为 1:7:2 。

郭炜表示，“ 问答场景还是简单的，一般是问产品相关问题以及写文章等场景，不要求结果，给我一些提示，我做就行。”

对于 Agent 场景，主要使用 Claude Code，并且会有一定的调用失败率，低复杂场景（ 比如算法题、日志清洗、爬虫、API 封装等 ）为5%，中等复杂场景（ 比如用户系统、风控规则、缓存优化等 ）为 10%，高复杂场景（ 比如分布式数据库、云平台、模型训练等 ）为 20%；低复杂场景下 AI 输出采纳率（ 基于接受代码行数 ）也是接近 100%，中等复杂场景约 80%，高复杂场景约 50%，其中，三种复杂度场景的任务量占比为 2:3:5 。

“ 场景越复杂，采纳率越低，一般是因为高复杂场景下 AI 对需求的理解不够到位。要提升采纳率，相关经验已经很多，例如写好 Code Wiki、用好 Plan 模式等。”

“我们也很重视采纳率这个指标，但重视不是因为钱，因为采纳率低太浪费时间，要用 AI 写代码，就用全球最好的模型。对我们而言，时间比 Token 更值钱。”

“ 我们的 Agent 执行有较大量的高复杂场景，但要让 Agent 改代码很难，一般还是人来改。也可以让 AI 改，但需要掰开了揉碎了给 AI 讲，这个过程不容易，我们大概有 400 多万行代码，目前的 AI 上下文长度还是不太够用。”

至于更通用的 Agent，通过一个月的深度使用 OpenClaw，游戏制作人王鲸对龙虾在游戏开发的相关任务（ 比如办公、开发、数据分析、咨询等 ）的采纳率也有较深的体会。

不过在实际输出结果前，龙虾首先让人头疼的是较严重的执行失败问题。

王鲸表示，“ 龙虾还是比较经常翻车的，问题有大有小。其中比较严重的是让龙虾去做和网关、基础配置相关的工作，它会信誓旦旦给你保证执行顺利，但其实只是胆子大，实际上经常把自己配死。比如一个简单的增加新模型的操作，切换模型堪比机器人给自己换电池，拆下电池的那一刻它就死了（ 断网 ）。在配置文件这块，很多Agent会调用一个文件，但彼此之间如果没有很好调和（或沟通），容易把文件改坏。”

“ 记忆也存在调用问题，即便是人工强调过，也有可能因为没有调用记忆，然后犯下重复执行的错误。”

当然王鲸也认为，既然要用，就尽量授权都给龙虾，这样才能正常工作，“ 而且像飞书插件这种授权带时效性的，还需要经常手动检查授权。”

“ 但为了安全，一定要在虚拟机中使用。我自己使用的是两层虚拟机也就是虚拟机里的虚拟机，来保障安全。龙虾的潜在风险还是很高的，即便不提黑客的问题，它也是拿着刀的猴子，可以砍椰子，但是谁知道什么时候会不小心砍到人。”

“ 幻觉是必然存在的，当它说自己没有办法 ‘ 看 ’ 网页的时候，只要告诉它 ‘ 你自带一个浏览器 ’，就能解决很多问题。最后就是记得留各种帮助文档，让龙虾操作之前去读一下。”

虽然使用龙虾的起步有各种阻碍，但工作流跑通以后，采纳率还是挺高的，整体能达到七成。

“ 为什么采纳率高呢？一般我会把需求说清楚，比如详细说明格式要求，把偏好和原则都记下来，龙虾会记住，发现问题马上指出，龙虾会改进。”

“如果从 ROI 的角度看，龙虾的高 ROI 场景主要是办公场景，比如飞书群消息统计/群秘书、周报汇总整理、AI 公司团队（ 创建多个 AI 员工分工协作 ）、飞书文档批量处理、日程/任务管理、PM 项目管理助手等，能把 1-2 小时的工作时长压缩到分钟级，强烈推荐落地；中 ROI 场景主要是开发分析类，比如网页生成、代码片段生成、数据查询分析/透视，可用但有局限；低 ROI 场景比如复杂工作流编排，出错后处理复杂，维护麻烦，还有浏览器自动操作，只能查看页面，无法真正操作，这些都不推荐落地。

“ 龙虾最适合的场景有这些特性：文件/数据密集、重复性、本地集成、异步执行（ 接受分钟级延迟 ）等，而需要秒级响应、复杂UI操作、调用多个外部 API 的复杂流程、大量主观判断的场景则不适合龙虾。”

王鲸总结道，“ 综合来说，我现在把龙虾当做我的 AI 分身加入了公司，进入项目当 PM、秘书以及执行策划，极大节省了我个人的精力。并且在人际关系处理上，因为 AI 给人的刻板印象就是会得罪人的，所以很多流程化的、不讲人情的公式化要求，可以让 AI 替自己唱黑脸。”

相对于标准化程度高的开发、办公领域，由于主观性和创意要求高，设计领域的 AI 输出采纳率特点呈现出极大的不同。

接下来，我们将跟随 John 的视角，来看看在产品设计领域的不同场景下，AI 输出的采纳率的现状和特点，由于在该领域很难像代码一样进行简单快速的采纳率统计，所以这部分大多是主观或者体感上的描述，但我们认为依旧很有价值，值得分享。

首先要清楚一点，要在各种场景把采纳率量化是很难的事情，比如基于代码行数的量化指标肯定不适用于产品设计领域。

John 表示，“ 采纳率不好清晰定义，因为很难将内容颗粒度拆得很细来衡量，毕竟你很难把 AI 的一个输出一刀切分，说这一部分全部是 AI 生成的，那一部分完全不是。目前只能定性描述为主。”

要更精确理解工作场景的采纳率情况，可以先以生活场景为参考。AI 在生活场景中的应用和搜索引擎没太大区别，目前落地是比较成熟的。

“ 在生活场景中，AI 基本只有一类使用方式，就是信息查询，一般是查询比较简单的事实型信息。”

“ 比如挑选男性维生素的时候，会提问：应该注意配料表里的哪些成分？但一般不应该直接将 AI 提供的结果拿来用，而是把它当作一个搜索或了解问题的起点。”

“ 模型在回答中通常会提到一些关键词，我会先评估这些关键词或者整段描述的可信度，再通过搜索引擎做一次 Double Check。在 Double Check 之后，如果觉得基本是正确的，就会采纳这些信息。”

“ 总体来说，目前这个场景下幻觉率已经相对比较低，尤其是在非常具体的事实型问题上，采纳率其实是比较高的。”

“ 这里说的 ‘ 采纳 ’，是指我会把这些信息记在脑子里，比如知道男性维生素在配料上可能需要注意什么，之后在实际购买时，会刻意去注意这些信息。” 由于 AI 反馈有即时性，这就催生了一个很重要的新场景，就是灵感探索，这是传统搜索引擎无法很好支持的。

“ 如果涉及到一些比较主观的问题，夹杂在工作和生活之间比如创意相关的场景，我对 AI 的用法是：要的不是输出，而是输入。”

“ 我会把和AI一来一回对话的过程当成一种 ‘ 思考实验 ’。”

“ 比如我会先描述一个问题或想法，看它怎么回应，再反复重启这轮对话，不断修改 Prompt，逐渐逼近我要表达的东西。前几轮输出的结果哪怕很差，我也能接受。”

“ 一般平均情况下，可能需要输入 10 轮才能得到自己想要的结果。之所以会超过 10 轮，是因为想法一开始是很模糊的，而讨论过程中又会不断产生新的点。有时候我会发现一些自己之前完全没有想到的东西。这是在对话中被激发出来的。但当这些新的点加入之后，又会产生新的模糊之处，所以这个过程会不断延伸。”

“ 直到我把 Prompt 修改到一个程度，使得 AI 的回答足够接近我真正想表达的东西，说明我对这个问题或想法已经想得足够清楚，表达也足够准确。”

“ 这时我其实也不会去用它给出的答案，只会拿走最后写出来的 Prompt，一般来说，这个 Prompt 会分成两部分：一部分是我想要什么，另一部分是怎么验收它。然后，用画图、原型设计、用户调研等方式来实现我的想法。”

“ 至于AI给我的那些具体建议，比如AI可能说 ‘ 基于我们刚才讨论的内容，你可以这样设计，或者在这个界面上做这样的调整 ’，这些我基本不看。”

“ 所以在这种场景下，如果说的是 ‘ 结果的采纳率 ’，那基本是 0。不过这种场景在创意工作的使用频率非常高。”

事实查询和灵感探索可以说是 AI 场景的两个相反的端点，也就呈现出采纳率的极大区别，“ 总体来说，信息越 ‘ 薄 ’ ，也就是越简单、越偏事实型的内容，采纳率就会越高；越主观的内容，采纳率就会更低。”

John 对 AI 的采纳相比普通用户是克制很多的，因为在他看来，大语言模型生成的内容本质上只是一种观点，是对很多观点的一种抽象总结，而不是真理，“ 我从来不会把它当成一种 ‘ 真理机 ’，不会觉得它说出来的东西天然就是对的。对我来说，它更像是一种非常廉价地获取一个视角的方式。”

降低期待其实更有利于提升采纳率，很多 AI 输出未被采纳，除了技术问题，也经常和使用方式不当或者期待过高有关，“ 用户对大模型理解越少，反而期待越高。尤其是如果把它当成一种 ‘ 真理机 ’，也就是 ‘ 一次提问就能把答案完善地给出来 ’，就很容易出现极端的情况：要么全部采纳，要么完全不采纳，或者直接觉得它没有什么用。”

“ 关于使用方式不当，比如在写 Prompt 的时候，其实很多人自己都没有把问题想清楚，没有经历反复迭代的过程。很多时候他们给出的需求非常抽象，既没想清楚要什么，也没想清楚怎么验收。这种情况下，其实很难判断输出质量，因为连评价标准都没有。”

“ 写 Prompt 还是一种挺难的能力，而且是需要花时间的，但很多人不太愿意花这个时间，他们会把这件事当成一个 One-Shot 的过程。” “ 即便现在的大模型产品在不断积累用户记忆，也没法让模型很准确地判断用户意图，更何况模型还经常引用不相关的记忆。”

“ 还有另外一个问题，是记忆本身解决不了的。”

“现在的 AI 记忆更多是 ‘ 事实型记忆 ’，而不是 ‘ 行为型记忆 ’，最多是在缺少上下文的时候，帮用户补充一点背景信息。但很多用户的问题其实不是缺少背景，而是表达本身。如果用户从一开始就说不清楚自己的需求，那模型就算记住再多也没用。”

“所以，更理想的情况其实是 ‘ 行为型记忆 ’，比如模型能记住这个用户经常会漏掉什么信息，或者表达上有哪些习惯，目前我还不确定哪个模型具备这种能力。如果没有的话，过度依赖历史上下文，反而可能让体验越来越差。”

多去探索 AI 生成的新玩法其实也能提高采纳率，“ 这其实就是探索 AI 产出在一些不同场景的可能性。同样的内容用在不同场合确实可以发挥出不同的价值。比如生成视频用作内容消费的采纳率，和生成视频用作用户调研的采纳率，可能在前者被淘汰的内容可以用在后者场景里。”

“ 对于近期大火的 Seedance 2.0，我也有一个比较感兴趣的场景：比如 Figma 的交互原型可能都不需要做，只需要准备几张关键画面，然后让视频模型生成一个 ‘ 用户在使用这个产品原型 ’ 的视频，再把这个演示视频拿给别人看。这样别人看到的是一个动态的演示过程，而不是几张静态图。对于早期测试来说，这种方式其实更容易理解。”

“ 尤其是在游戏领域，这种方式可能很有价值。比如游戏开发里有一个概念叫 ‘ 垂直切片 ’：开发团队会把核心玩法和一个关键场景做成一个可玩的版本，然后拿这个去做融资或者找发行商。但其实在更早期阶段，很多验证完全可以用视频来完成，甚至不需要真正开发。”

“ 我印象特别深的一个案例是 TikTok 上曾经很火的一个游戏概念叫《 Bird Game 3 》，当时很多短视频都在传播，看起来像一个真实存在的游戏，但后来发现它根本不存在，只是大家基于一个梗想象出来的 ‘ 虚构游戏 ’。很多用户其实是在 ‘ 云游戏 ’，看视频觉得好笑就会转发。这种传播本身就已经验证了这个游戏创意具有传播性。对于现在很多高度依赖传播属性的游戏来说，用视频生成来做这种早期验证，其实是一种非常有效的方法。”

如果要再深入到交付阶段，则涉及界面设计、原型开发等场景。“ 界面设计过程主要涉及图像素材的生成，采纳率大概是 50%，大部分生成的图像是不可用的。”

“ 至于是否需要做后期修复，很难一概而论。因为这类内容覆盖的范围比较广，比如在设计的不同阶段，插图的需求也不一样，需要修复的程度也不同。举一个比较具体的例子：如果我让它生成一个像素风格的 icon，那AI生成的几乎是永远不可用的。因为像素风 icon 的核心是每一个 Pixel 都非常清晰、非常规则，而模型生成出来的本质上是渲染的一整幅图，只是 ‘ 看起来像 ’ 像素风。它的边缘不是真正的像素结构。所以像这种需求，采纳率基本就是 0。” “ 我一般会把 AI 生成的图拖到 Figma 或 Illustrator 里，再自己重画一遍，AI 图更多是作为一个参考底板。”

“ 如果是用作演示内容的配图，大概也是 50% 的采纳率，比如 Placeholder 型的插图，只要整体风格大体能接受，其实就可以采纳。”

“ 如果是在实际生产中，已经把 AI 整合进一个自动化 Workflow ，那生成的内容基本都会被采纳。”

“ 当然，在生产级工作中，主要的界面设计工具还是 Figma，而围绕 Figma 的整个工作流程，目前没有任何一个其它工具能在关键环节上做到生产级别的可用生成，比如设计系统、具体界面的设计等。”

“有些产品会号称可以做设计系统，也可以自动生成界面，能把流程跑通并做到生产级别。但这些产品往往脱离了 Figma 生态。对我来说，这其实没有意义，因为我最终还是要在 Figma 里完成很多后续工作。它们最多只能在一种情况下有用：对界面要求不高，或者是让一个完全不懂界面设计的人快速做出一个 ‘ 看起来还行 ’ 的页面，用来达到一个非常低的基础标准时。”

Figma 本身其实也在逐渐加入一些 AI 或 Agent 功能，比如 “ Figma Make ”，对此 John 的期待也不高，“ 我基本不用。我会用的更多还是一些比较传统的或更接近 Machine Learning 的功能，比如移除背景、向量化功能等（ 比如输入一张普通图片，输出一张矢量图，这样原本不能修改的图片就可以修改了 ）。”

在界面设计以外，有时候 John 需要把一些想法快速做成原型，比如一个 Web Demo，这样在和前端、后端沟通时，可以更清楚地表达视觉、数据关系等需求，“ 不然仅靠设计师的语言，其实他们很难想象具体是什么样子。”

“ 如果使用一些通用型 Agent 或代码类 IDE 来实现，采纳率是非常高的。”

“ 毕竟我的要求是只要能演示效果，不太在意它是否能上生产环境，也不太在意代码质量或数据安全问题。这种原型基本就是一次性的 APP（ Disposable APP ）。” “ 但会根据原型的复杂程度有所区别。有的原型需要尝试很多次，而且迭代结果不是线性的过程，只想微调局部元素却导致整个页面布局完全改变，这种情况其实一直都存在，不管用什么 AI 产品。当然最终的结果基本都会被采纳，毕竟要求不高。”

还有一个比较特殊的场景，要求会更低一些，就是 John 的个人项目开发，“ 很多时候是用部署在纯本地环境的模型，这时不需要考虑数据安全问题。在这种情况下，和原型开发有一定相似性，对可靠性的要求也不高，只要能跑起来就可以。”

“ 比如我会根据自己家庭的需求做一个记账软件。因为我发现市面上的很多记账软件，其实都不能完全满足我的需求，总是缺一些我需要的功能。”

” 而且，这个软件不止我一个人在用，还需要让家庭里的其他人也能用，所以把这个应用部署在了自己家的网络，相当于是在内网部署一个小型业务系统，这种级别的项目基本上可以完全用 AI ‘ Vibe ’ 出来，我只负责提需求。” 在界面设计中，AI 的视觉理解瓶颈目前还很明显，“ 任何想把设计往上提升比如加入风格、加入自己对界面的理解的需求，AI 其实都做不到。”

“ 主要问题是调整成本非常高。一种情况是，比如只让它把某个按钮往旁边挪两个 Pixel，结果整个页面的布局都会发生变化。”

“ 另一种情况是表达需求的成本很高。很多设计需求其实很难用语言准确表达，比如希望页面有一些孟菲斯设计风格，大语言模型往往会用一种非常肤浅的方式去理解这种概念。比如它会理解为：孟菲斯风格就是大量鲜艳的颜色，比较突出的几何形状，轮廓明显的图形。然后，它就会把整个界面铺满各种彩色元素，看起来非常幼稚。”

“ 相比之下，在我脑子里的想象，可能只是一些很细微的调整：某些元素的颜色要更鲜亮一点，颜色选择要更大胆、更跳跃；或者让页面的轮廓线更加明显一些。”

“ 我目前试过的很多模型，没有一个真的能理解这些东西，而且做界面生成的Token 成本通常也比较高。很多时候，如果我把时间花在和模型反复解释这些需求上，还不如自己直接在设计工具里试几种方案，很快就能得到结果。”

“ AI 对界面的理解，很难做到结构化地拆解再理解再生成，更多是直接给你一个整体性的效果。”

“ 有一个场景我也一直比较期待：在设计早期，只有一些风格关键词，再加上一个很粗略的结构草图，我希望有一个工具能把这些信息结合起来，模拟出一个可能的界面，这样可以帮助我们在早期确定视觉方向。但目前没有产品能做到这一点。”

“ 当然，如果你让它生成一个 Dashboard，这是结构性非常强、功能性强于美术表达的界面类型，模型其实是可以做出来的。”

“ 但又会出现另一个问题：它生成的界面往往不遵循你的设计系统。所谓设计系统，其实就是一整套规范。比如界面里的颜色、线条粗细、间距、边框宽度等，通常不会直接用具体数值标注，而是用变量来定义。比如边距可能是 1px、2px、4px，或 S、M、L 这样的等级，圆角也可能是 2%、4%、6% 等不同级别。”

“ 如果让生成式工具来做界面，它虽然能生成看起来类似的界面，但实际上用的都是具体数值，而不会调用你定义好的变量。从设计系统的角度来说，它并没有真正遵循你的规范。”

“ 如果模型不能直接使用我的设计系统，我基本不会去用。原因很简单：后续的调整成本会非常高。”

“ 比如现在觉得整个页面的矩形圆角太硬了，想把圆角从 2 Pixel 改成 4 Pixel。在设计系统里，只需要改一个变量，整个界面里的相关元素都会一起更新。但如果界面没有使用变量系统，我就必须一个一个去找页面里的矩形，把它们的圆角逐个改掉，这就变成了完全手动的工作。”

“ 目前我还没有发现一个 Figma 工作流能解决这个问题。这个问题的技术难度其实未必很高，可能只是没有找到一套合适的工具流或者工具链能够实现它。”

因此，总体而言，以设计场景为典型，其实在除了代码生成以外的大部分场景中，人们都感觉 AI 的实际采纳率并没有特别高。客观因素比如模型能力有限、记忆类型不完备等自然很重要，主观因素特别是不合理的期待却较少为人注意，如果大模型不是 “ 真理机 ” 而是 “ 观点机 ”，那它本质是面向未来的，幻觉是基本属性，知识再丰富，也不是可靠的百科全书，执行能力再强，验收环节也必不可少，这一点倒和人类没太大区别。

现实层面看，近几个月 SaaS 市场被全面看空，在 John 看来，这更多还是市场对于 “ SaaS 泡沫 ” 的情绪波动，有不少恐慌的成分，有点非理性。

“ 一方面，人们都觉得 AI 很有前景，叙事也很庞大，但另一方面，很多人心里都有点虚，不确定它的潜力边界。”

“ 我之前听过一句话，感觉挺有道理的：如果你现在去问大家，有多少人觉得 AI 可能存在泡沫，其实有不少人是有这种担心的。但如果回看 2000 年互联网泡沫的时候，当时其实很多人并不觉得有泡沫。所以换个角度看，如果现在已经有这么多人在担心泡沫，反而说明可能离真正的泡沫阶段还有一点距离。因为这至少说明整体市场还是比较谨慎的。”

在过去几年，问答场景和人类监督的 Agent 场景下，Token 消耗一般不为人过度关注，但在龙虾时代，24 小时在线烧 Token 的龙虾直接点燃了大家的 Token 焦虑。

王鲸表示，“ 传统对话式 AI 一句话消耗一两千 Token，现在用龙虾随便一句话就 20 万 Token，就算和其他 Agent 场景相比也是消耗更大的，比我写代码用的 Qwen Coder 高了很多倍。”

“ 究其原因，还是因为 Skill 装的多，工具调用的多。毕竟长了手，工作范围广，比起纯文本操作，基础消耗自然高了很多。”

“ 而且现在很多操作不是软件化的、模块化的，而是 AI 现场思考以后去操作的，类似于每次按按钮都全屏截图识图一次，每一次操作都要思考一次，能效比很差，就像大炮打蚊子。”

用得少怕落后，用得多怕看账单。

从这个节点开始，AI 输出的采纳率这个 “ 房间里的大象 ”，或许会越来越被人们在意。