AI采用率停滞不前？问题可能出在"上下文"上
在使用AI工具时，你是否有过这样的体验：AI明明能读邮件、回邮件，却始终像个不了解你项目的陌生人，给出的答案总是"差点意思"？Stack Overflow最新一期"No Dumb Questions"节目中，数据科学总监Michael Foree与主持人Phoebe Sajor深入探讨了这个现象背后的核心原因——AI上下文缺失，以及为什么"上下文工程"（Context Engineering）正成为AI落地的关键瓶颈。
AI能力不缺，缺的是"上下文"
Foree在一次技术会议上对参会者做了调研，对象从CTO、工程师、分析师，到平面设计师、项目经理，跨越了技术岗与非技术岗。他发现一个共性问题：AI本身能力足够，但在与你日常工作的"连接"上严重不足。 一个典型例子是邮件回复。AI可以理解"这是一封别人发来的邮件"，但它不知道对方是谁、你们之前在邮件里聊了什么、在Slack上有什么相关讨论、最近开了哪些与此相关的会议。AI缺失的，是邮件本身之外的所有信息。
结果是，用户不得不手动把相关背景信息复制粘贴进AI工具，然后才能得到一个勉强可用的回复初稿——即便如此，通常还要来回修改一两轮，才能最终发送。整个流程下来，花的时间可能比自己写还多。
"上下文工程"成了AI落地的最大短板
Foree将这个问题定性为上下文工程（Context Engineering）缺失。在他看来，AI目前无法做到：
- 理解"为什么这封邮件需要现在回复"
- 判断"哪些相邻对话与当前邮件相关"
- 主动调用工具权限完成发送动作
想让AI像一个真正的助手那样工作，需要人类提前做大量配置工作：授予AI访问邮件的权限、连接Google Drive获取文档、同步Slack频道、开放发送邮件的接口……每一步都需要人工介入。用户自己也在算一笔账：我每天最多用一两次，值得花这么大力气配置吗？
Foree坦言："说实话，我不确定是否值得为偶尔写封邮件去完成这套配置。"
企业场景的成本更高，瓶颈更突出
在企业环境中，配置新软件的门槛远高于个人用户。你要评估的东西更多、合规要求更严、跨部门协调更难。Foree认为，这正是当前AI采用率无法进一步提升的根本原因：人们对"这套投入今天能带来多少回报"心存疑虑，最终选择放弃折腾，自己动手。
本段要点：AI工具能力本身不是问题，上下文缺失与上下文工程的高门槛才是阻碍AI广泛落地的核心瓶颈。企业用户的配置成本尤其突出，导致不少人选择绕开AI、直接上手。
Context Engineering的隐性成本：为何企业级AI应用比想象中更烧钱
对于普通用户而言，向AI助手提一个问题只是几秒钟的事，但真正的幕后工作远不止于此。以回复一封邮件为例，人类大脑会本能地完成大量上下文整合：判断发件人的重要程度、回忆此前的往来记录、在邮件、Slack、Jira、会议记录等多个系统中交叉检索相关信息。这一连串动作对人类来说是自然而然的，但对于AI系统而言，每一个判断节点都意味着一次Context Engineering——而这正是企业级AI应用的核心瓶颈。
上下文工程：人类觉得简单，AI却要"拼尽全力"
以给同事Joe回邮件为例，人类处理流程看似简单，实则涉及多个数据源的实时整合：
- 关系判断：根据对Joe的了解，立刻判断是否需要优先回复。
- 历史检索：意识到存在被遗忘的邮件串，需要回溯整个往来记录。
- 关联扩展：搜索是否还有其他涉及Joe的邮件，判断哪些与当前回复相关。
- 跨系统查询：确定项目XYZ的最新进展位于哪个系统——Slack、Jira还是会议纪要。
对于人类，这些判断在毫秒间完成。但AI系统需要逐一访问这些数据源，每一步都产生token消耗。更关键的是，AI容易在无关信息中迷失——它会检索所有提及Joe的邮件、所有关于项目XYZ的Slack消息，并将这些"干扰项"一并纳入上下文，最终给出一份缺乏针对性的回复。这些干扰不仅浪费时间，更直接推高了token成本。
大模型正在学会"筛选"，但私有数据仍是硬伤
近年来，头部大语言模型在对抗干扰内容方面有明显进步：更擅长说"Yes, and..."、更主动地提出追问。但这些能力的提升主要建立在公开可获取信息的训练基础之上。
以"跳过木头"这个场景为例：可以训练AI学会追问"木头有多大"，但这与理解某家企业私有流程完全是两码事。AI实验室无法获取企业的专有数据来训练其特定流程，而企业本身也不会愿意将这些核心资产拱手让人——毕竟那是竞争优势所在。
这正是Context Engineering被视为"AI圣杯"的原因：谁能解决私有信息的上下文整合问题，谁就掌握了企业AI应用的关键。MF在访谈中提到，其团队正在通过Stack Internal构建知识连接器，让AI在不直接训练私有数据的前提下获得所需上下文，同时引入人类专家对AI生成内容进行验证校准。
跨行业：Context Engineering的痛点表现各异
当被问及"context engineering是否是所有人的AI采用瓶颈"时，MF给出了肯定答案，但强调各行业的表现形式存在差异。
在面向非技术人群的访谈中，最突出的问题是工具连接性的缺失。例如一位用户希望重新设计客厅：AI确实能识别窗帘与蔷面的配色方案、建议家具重新摆放以优化动线，但当用户想根据建议快速迭代调整时，系统之间的断点导致流程无法顺畅衔接。AI给出了正确答案，但工作流在工具层面断裂了。
对于工程总监、设计师等不同角色，AI采用的障碍本质相同——都是context与distraction的博弈——但具体症状各异。这提示企业引入AI时，不能只关注模型能力，还需要重新审视内部工具链的连接状态。
那么问题来了：技术明明已经存在，为什么没有真正落地？
以"买油漆"为例。你想重新粉刷蔷壁，让AI推荐配色方案——它完全可以调出附近有对应颜色油漆的门店，甚至直接帮你完成下单，而无需切换到其他应用。Google Maps早就解决了"我在哪、附近油漆店在哪"的问题，而某家油漆店也完全乐意向一个AI bot卖货。这是一个多赢的局面，却至今没有变成现实。
同理，用AI生成购物清单并不难——你只需说"家里有几口人、各有什么过敏、每天需要早中晚三餐、我很忙没太多时间做饭"——AI就能帮你列好清单。但一旦你说"那帮我下单所有食材吧"，立刻就卡住了。虽然许多超市支持自家App在线订购，但它们不会对外开放API。对超市而言，允许外部AI直接调用下单接口是安全隐患；而单独一个AI购物助手，也不足以激励任何一家超市为此开放接口。Instacart几乎是唯一提供这类激励机制的玩家——你创建一款满足上述需求的App，用户通过它购物时你能获得少量佣金。但绝大多数超市并没有动力去激励第三方开发者为此投入。结果就是：没人愿意做，因为投入产出不成正比。
实际上，这些问题并非技术难题，而是激励机制的问题。正如设置AI自动回复邮件一样——如果你一个月只用上一两次，那实际收益微乎其微。为了一次AI买油漆的操作，你需要将它接入Google Maps、绑定信用卡、共享本地油漆店的偏好信息……这些工作量是否值得？
换个角度：如果你是读者，完全可以尝试用"振动编程"（vibe coding）快速搭建一个满足上述需求的App，接入本地超市的API，不需要多少成本就能完成。发布出去，一定有人觉得好用。未来的样子应该是：不必每个人都亲自去超市、不必每个人都自己列购物清单——有更好的方式，而我们完全有能力做到。
观察与追问：上下文工程的核心思维
"上下文工程"（Context Engineering）并非高深莫测的概念，其核心方法可以追溯到小学课堂——观察、停顿、追问。Matt Fristchfeld在一次对话中分享了这一观点：孩子被教导观察周围世界，然后停下来问自己"这里发生了什么？有什么值得注意的？"这一训练迫使孩子先深呼吸、暂停，再得出结论。他建议，在使用AI时也应该采用同样的方式。
具体操作步骤如下：
- 停下来思考：在让AI辅助回复邮件之前，先问自己"如果我要写这封邮件，我会参考哪些信息来源？又会忽略哪些？"
- 列出所需信息：将AI需要访问的数据源和内容逐条记录。
- 明确排除项：标注哪些信息可能干扰AI判断，应该被过滤掉。
- 测试与迭代：用模拟场景验证AI的回复，观察它关注了哪些信息、忽略了哪些，据此调整上下文设计。
这一过程看似简单，真正困难之处在于：人类每天处理大量邮件时，这些判断是自动完成的，但AI不会。 如果不刻意教导，它就无法自动掌握。
AI时代的"逆向操作"
当下AI浪潮中，许多人追求的是"不要想，直接做"。然而Fristchfeld认为，上下文工程恰好要求我们"逆向而行"——先停下来思考，再动手构建。他将这一过程形容为"Vibe Coding"：先凭直觉搭建，再通过测试发现问题、迭代优化。
进阶玩法包括：记录曾发送过哪些主题的邮件，从而构建更完善的上下文架构；或者在测试中主动问自己"它为什么会关注这部分而忽略那部分？"——这本身就是一种创造性问题解决过程。
AI的未来：摆脱极端叙事
关于AI的未来走向，Fristchfeld指出一个关键瓶颈：人们对AI的认知两极化。有人认为它万能，有人认为它将毁灭人类——两种极端都不准确。
他的判断是：
- AI在某些事情上优于人类，那就充分发挥这一优势；
- AI在某些事情上不如人类，那就坦然接受这一事实。
AI只是一项新技术，社会终将学会与之共处。关键在于了解它的适用场景和不适用场景，在该用的时候用它，不该用的时候不用。
评论