大多数创业者以为自己在构建AI产品，其实他们真正在做的是构建上下文选择系统。
近期，旧金山举办了一场高规格AI圆桌讨论，嘉宾包括来自Uber、WisdomAI、EvenUp和Datastrato的工程师和机器学习负责人。这场名为“Beyond the Prompt”的活动吸引了600多位报名者，主要是创始人、工程师和早期AI产品构建者。
讨论的核心议题是上下文工程、推理栈设计，以及在企业环境中扩展智能体系统需要什么。如果说“提示词”只是冰山一角，这场讨论深入到了水面下那片冰冷而复杂的巨大部分：上下文选择、语义层、记忆编排、治理和多模型路由。
现实很残酷：一位嘉宾提到，95%的AI Agent部署在生产环境中都失败了。不是因为模型不够聪明，而是因为它们周围的脚手架——上下文工程、安全性、记忆设计——还没到位。
当晚一个比喻让人印象深刻：
“基础模型是土壤；上下文是种子。”
业内人士普遍关注语义层，不是因为它们酷炫，而是因为这正是创始人悄悄地将信任、实用性和差异化构建到LLM系统中的地方。太多团队把提示词和产品混为一谈。这场讨论标志着一个重要时刻，真正的工程工作开始得到应有的重视。
以下是核心要点——不只是引用，而是在认真的AI团队中反复出现的模式。如果你在基础设施、工具链或垂直AI层构建产品，这些就是需要做对的脚手架。
一、上下文工程 ≠ 提示词黑客技巧
几位嘉宾都表达了同样的洞察：微调很少做，检索增强生成(RAG)做好了就够了。但今天的大多数RAG系统太过简陋。
三种常见的“翻车”方式：
* 索引所有内容 → 检索太多 → 让模型困惑
* 索引太少 → 让模型缺乏信号
* 混合结构化+非结构化数据 → 破坏嵌入或扁平化关键schema
那么，高级上下文工程实际上是什么样的？
-
LLM的特征选择
一位演讲者将上下文工程重新定义为LLM原生的特征工程：- 选择性上下文剪枝 = 特征选择
- 上下文验证 = schema/类型/时效性检查
- “上下文可观测性” = 追踪哪些输入改善/恶化了输出质量
- 带元数据的嵌入增强 = 类型化特征+条件
这个框架很重要。它意味着可以把上下文当作可版本化、可审计、可测试的制品，而不是一个字符串blob。
-
语义+元数据分层
几个团队描述了双层架构：- 语义层 → 经典向量搜索
- 元数据层 → 基于文档类型、时间戳、访问权限或垂直本体强制过滤
这种混合层有助于规范化混乱的输入格式(PDF、音频、日志、指标)，并确保检索的不仅仅是“相似内容”，而是相关的结构化知识。
-
Text-to-SQL的现实检验
当主持人问观众“你们中有多少人构建了text-to-SQL并将其投入生产？”时，没有一只手举起来。
这不是因为问题太小众，而是因为查询理解很困难。自然语言是模糊的。业务术语是领域特定的。而且如果没有大量的上下文工程，LLM不知道公司对“收入”或“活跃用户”的定义。
成功的团队不只是把SQL schema扔给模型。他们构建：- 业务词汇表和术语映射
- 带约束的查询模板
- 在执行前捕获语义错误的验证层
- 随时间改善理解的反馈循环
二、为什么95%的AI都挂在了“权限”这道坎上
很多团队做AI的时候，只想着“怎么答得对”，却忽略了一个致命问题：这个答案该不该告诉他？
现场一位工程师分享了一个真实案例：公司上线了一个AI数据助手，结果第二天就被紧急下线。
原因很简单：
* 销售总监问：“上季度各区域业绩如何？”→ AI完整回答
* 普通销售问：“上季度各区域业绩如何？”→ AI也完整回答
问题出在哪？ 普通销售只能看自己负责区域的数据，但AI把所有区域的敏感业绩都透露了。这不是技术问题，是严重的数据泄露事故。
一句话点醒梦中人
那位演讲者说了一句让全场安静的话：
“同样的问题，不同的人问，AI给的答案就该不一样。”
听起来简单，但大部分AI系统根本做不到。为什么？因为它们只关心“语义理解”，不关心“谁在问”。
三道必须跨越的门槛
如果你想让AI真正在企业里用起来，这三件事必须做到：
* 可解释性与可追溯性：AI的回答必须能追溯源头。
* 这个数据从哪来的？
* 是基于哪些文档、哪些记录得出的结论？
* 出了问题能不能找到责任源头？
* 基于角色的差异化访问：同样的问题，不同权限的人应得到不同范围的答案。
* CEO能看完整财报
* 部门经理只能看自己部门的
* 普通员工可能只能看公开的季度总结
* 数据层级的权限检查：权限检查必须在数据检索的源头进行。
* 在数据入库时就标记权限
* AI检索时自动过滤掉用户无权访问的内容
* 从源头杜绝泄密可能
技术再牛，用户不敢用也白搭
一位嘉宾分享了他的亲身经历：他买了特斯拉，很想体验自动驾驶。但每次要开启，家人都坚决反对。
不是因为技术不行，而是因为“不信任”——家人觉得把命交给机器，心里没底。
他感慨地说：
“当AI要碰你的安全、你的钱这种要命的东西时，技术好不好是一回事，敢不敢用是另一回事。我们能做出AI Agent，但问题是：用户真的敢让它做决定吗？”
这句话戳中了所有人的痛点。
企业AI面临同样的信任危机，不只是自动驾驶，财务对账、医疗诊断、法律文书等企业场景更严重。其核心矛盾：AI可能做对了，但没人敢完全相信它。
成功的5%是怎么破局的？
那些真正在生产环境跑通的AI，有个共同特点：它们从不让AI“独自做主”，而是设计成“人机配合”模式。
* 将AI定位为助手，而非自主决策者
* 建立反馈循环 — 让系统能从人类的纠正中学习
* 设计易于验证和覆盖的流程 — 让人类能够轻松介入和最终决策
三、记忆不只是存储，它是架构决策
每个人都想“添加记忆”。但记忆不是一个功能，它是一个设计决策，涉及UX（用户体验设计）、隐私和系统影响。记忆的层级有如下几种：
* 用户级：偏好（如图表类型、风格、写作语气）等
* 团队级：高频查询、仪表板、运行手册等
* 组织级：机构知识、策略、先前决策等
大多数创业公司将记忆硬编码到应用逻辑或本地存储中。但最好的团队将其抽象为上下文层+行为层，可版本化和可组合。
一位演讲者这样描述：
“语义记忆+分类法+运行手册 = 上下文
个人偏好 = 记忆”
记忆作为个性化
在应用层，记忆有两个目的：
* 根据个人用户定制行为 —— 用户的写作风格、偏好、领域专长
* 基于事件和元数据的主动协助 —— 而不仅仅是被动聊天响应
一个团队分享了在Uber构建对话式数据分析工具的经验。他们遇到了一个典型难题：用户打开工具后不知道该问什么。
这就是所谓的“冷启动问题”——就像你第一次用一个新工具，面对空白对话框发呆，不知道从哪里开始。
他们的解决方案很巧妙：系统会分析用户过去的查询记录，然后主动推荐相关问题。
比如，如果你上周查过“北京地区的订单量”，这周打开工具时，系统会主动提示：“要不要看看本周北京订单的最新数据？”或者“上海地区的情况要对比一下吗？”
就像一个贴心的助手，记得你上次关心什么，这次主动帮你准备好了话题。
个性化的边界在哪里？
AI记忆功能带来了一个棘手的问题：记得太少不好用，记得太多又让人害怕。
个性化的边界问题
一位嘉宾分享了亲身经历：他问ChatGPT推荐适合全家看的电影，结果AI回答说：“根据Claire和Brandon的年龄，我推荐这几部动画片……”
他当场就不舒服了：“你怎么知道我女儿叫Claire、儿子叫Brandon？这也太吓人了吧！”
这就是个性化的边界问题：
- 记住用户喜欢的图表样式 → 贴心
- 记住用户常问的业务问题 → 高效
- 记住用户孩子的名字 → 越界了，感觉被监视
三大设计矛盾
矛盾1：功能 vs 隐私
* 记忆让AI更好用，但用户会担心隐私泄露。
矛盾2：个人 vs 团队
* 如果记忆在团队间共享，可能会泄露个人信息。
* 例如，你的搜索记录被同事看到。
矛盾3：锁定 vs 自由
* 当前的AI记忆大多绑定在各家平台上。
* 你在ChatGPT建立的“记忆”，换到Claude就没了。
* 数据控制权在厂商手里，不在用户手里。
理想的解决方案：用户拥有自己的记忆
嘉宾们提出一个大胆设想：能否建立一个“记忆银行”，让用户自己管理AI记忆？
* 就像通讯录、照片存在手机里，而不是锁在某个App里。
* 你可以授权任何AI工具读取这些记忆。
* 你随时能查看、修改、删除。
* 数据归你，不归平台。
但目前没人做出来。 一位嘉宾甚至表示：如果不是正在创业做别的项目，他下一个就想做这个。
四、多模型推理与编排模式
另一个被忽视的关键设计是模型选型与编排。
许多团队的做法是：无论什么问题，都扔给GPT-4、Claude等最强（也最贵）的模型。但真正运行良好的系统并非如此，而是基于以下因素进行模型动态选择：
* 任务复杂度
* 延迟约束
* 成本敏感度
* 数据本地性/监管问题
* 查询类型（如摘要 vs 语义搜索 vs 结构化QA）
一些典型的编排模式如下：
* 对于琐碎查询 → 本地模型（无网络调用）
* 对于结构化查询 → 调用DSL → SQL翻译器
* 对于复杂分析 → 调用OpenAI/Anthropic/Gemini
* 回退或验证 → 双模型冗余（判断者+响应者）
这不是简单的if-else判断，而像一个智能调度系统，根据：
* 问题有多复杂
* 用户能等多久（延迟要求）
* 预算够不够（成本控制）
* 数据能不能出境（合规要求）
来决定调用哪个模型。
为什么这很重要？
如果做错了：
* 简单问题用大模型 → 浪费钱，响应慢
* 复杂问题用小模型 → 答错了，用户体验差
* 所有问题都用同一个模型 → 成本失控，难以扩展
如果做对了：
* 成本降低50%以上
* 响应速度提升
* 准确率还更高
一个团队的经验是：这套路由策略本身也可以学习优化——系统会记录哪些类型的问题用哪个模型成功率高，然后自动调整策略。
就像使用导航软件：
* 不是所有路线都走高速（贵但快）
* 也不是所有路线都走小路（省钱但慢）
* 而是根据距离、时间、路况，智能选择最优方案
AI的模型选型与编排，道理是一样的。
五、 AI就一定要做成聊天框吗？
并非所有问题都适合通过“打字聊天”来解决。
一位观众提出了灵魂拷问：
“我不确定自然语言总是比GUI更可取。如果我在叫Uber，我不想对着手机说话。我就是点、点、点，车就来了。”
这句话点醒了很多人。大家都在做AI聊天机器人，但真的每个场景都需要聊天吗？
嘉宾们讨论后，总结出聊天真正有用的两种情况：
场景1：你不会用的复杂工具
以前做数据分析要学SQL、学Excel高级函数，门槛很高。现在直接问AI：“帮我看看上个月北京的销售额”，秒出结果。
这时候聊天有价值——因为它降低了学习成本。
场景2：需求很难用按钮表达的时候
比如你想订民宿，需求是：“加州海边、一线海景、有蓝天白云、适合拍照的那种”。这种复杂、模糊、个性化的需求，用传统筛选器要点20个选项，但说一句话就搞定了。
聊天不适合什么场景？
当用户已经明确知道想要什么时，点击比打字快得多。例如：
* 把饼图换成柱状图 → 不需要打字“帮我换成柱状图”，直接点按钮就行
* 调整字体大小 → 不需要说“把字体调大一点”，拖动滑块更直观
* 选择日期范围 → 不需要输入“2024年1月到3月”，日历选择器更好用
最好的方案：聊天+界面，让用户自己选
- 用聊天作为入口 → 降低上手门槛，让小白也能用
- 用界面作为工具 → 让熟练用户快速操作
- 让用户自己选 → 想打字就打字，想点就点
两个最适合自然语言的场景
嘉宾特别强调了两种情况，自然语言是最佳选择：
* 情绪化的场景：如客服投诉、求助，用户就是想发泄、想被理解，强迫他们点菜单选项会更生气。
* 探索式的需求：如“帮我找个加州海边、一线海景、有蓝天、适合拍照的民宿”，这种需求太复杂，用传统筛选器根本没法表达。
核心洞察
不要为了AI而AI。
问问自己：用户为什么想用自然语言？
* 如果是因为不会用工具 → 聊天有价值
* 如果是因为需求复杂 → 聊天有价值
* 如果只是简单操作 → 别强行用聊天，按钮更好
最好的产品，是让用户根据场景自由切换，而不是强迫所有交互都变成打字聊天。
六、四个被忽视的大机会
这场讨论中，几位嘉宾不约而同地提到：有些明明很重要的东西，居然还没人做好。这些可能就是下一波创业机会。
1. 上下文可观测性
当前问题：你喂给AI的那些背景资料，到底哪些有用、哪些有害？没人知道。就像炒菜时倒了一堆调料，但不知道哪个让菜变好吃，哪个搞砸了味道。
如果有人能做出：
* 告诉你“这段上下文提升了20%的准确率”
* 告诉你“这段上下文导致了幻觉”
* 像测试代码一样测试上下文
这会是个刚需工具。目前大家都在“盲飞”。
2. 你自己的“AI记忆银行”
这是最大的机会，但还没人做出来。想象一下：
* 你在ChatGPT里建立的记忆，换到Claude就没了
* 你在这个工具里的使用习惯，换个工具要重新来
* 你的数据被锁死在各个平台里
如果有人能做出一个像“云盘”一样的记忆存储，你可以：
* 授权任何AI读取你的偏好
* 随时查看、修改、删除这些记忆
* 换工具也能带着记忆走
* 数据归你，不归平台
3. 别再让AI“猜”SQL了
现在Text-to-SQL为什么没人敢用？因为太不靠谱！你问“给我看看收入”，AI不知道：
* 你们公司“收入”的定义是啥
* 该查哪张表
* 要不要排除退款
更好的方案——与其让AI瞎猜SQL，不如：
* 建立一个“业务术语词典”
* 让“Q4收入”直接对应一个验证过的计算公式
* 不是每次都现场翻译SQL，而是调用预定义好的、靠谱的计算逻辑
4. 让AI学会“察言观色”
一位嘉宾描述了一个有趣的产品：一个聊天机器人，虽然响应慢，但用户特别喜欢。为什么？因为它会主动关心你。
例如：
* 你打开工具，它说：“上周你问了XX，今天有新数据了，要不要看看？”
* 你要开会了，它提前把相关资料准备好
* 你的数据出现异常，它主动提醒你
关键洞察：
* 讲笑话要秒回，但深度分析慢一点没关系，只要让用户感觉“它在认真思考”
* 不是所有AI都要即时回复，有些场景提前准备、主动推送更有价值
护城河在哪里？
这场讨论传递出一个强烈信号 —— 未来AI产品的竞争，拼的不是谁用了GPT-4还是Claude，而是这四样东西：
- 上下文质量 → 喂给AI的资料有多靠谱
- 记忆设计 → 能记住多少、记在哪里、怎么用
- 编排可靠性 → 如何聪明地选择和组合模型
- 信任UX → 用户敢不敢把重要的事交给AI
基础设施的春天要来了
嘉宾们的共识是：接下来会有一大波工具出现，专门解决这些“脏活累活”。就像当年做网站，从手写HTML到用WordPress；做App，从写原生代码到用各种框架。
AI也会经历这个过程，谁先做出这些基础工具，谁就占据了生态位。
给创业者的灵魂拷问
如果你在做AI产品，问自己五个问题：
- 你的上下文策略是什么？ 给AI多少背景资料？怎么选的？
- 你的记忆存在哪里？ 用户级、团队级、公司级，怎么划分的？用户能看到吗？
- 你能追踪AI为什么这么回答吗？ 出了问题能调试吗？知道哪段输入导致了错误吗？
- 你用几个模型？ 是不是所有问题都扔给最贵的那个？有没有根据情况选择？
- 用户敢把钱交给你的AI吗？ 如果不敢，是安全问题？可解释性问题？还是反馈机制不够？
这五个问题，决定了你的AI产品能不能真正用起来。
写在最后
如果你正在做AI基础设施，或者在其他人意识到之前就在解决这些问题，这篇文章希望能给你一些共鸣。
对于技术从业者，尤其是在做AI/ML的朋友：你会想看关于这些话题的深度内容吗？
- 如何设计上下文剪枝策略
- 如何构建双层上下文系统
- 如何抽象记忆层
-
如何在设计阶段就考虑治理问题
- LLM文本摘要评测实战指南
- 姚顺雨成名作“智能体评测集τ-bench”上手指南
- DeepSeek-V3.2-Exp非思考模式实测
- DeepSeek-V3.2-Exp思考模式实测：开源模型王者
- 深度拆解：为什么通用 Agent 的下一站是 Agentic Browser？
- 每月AI大模型更新速递（25年9月）
- 每周AI大模型更新速递10.1~10.12
- 大模型智能体评测综述【Benchmarks解读】
- 智谱GLM-4.6硬刚豆包、DeepSeek：速度快40%，为何还是输了？
- 腾讯混元turbos实测：Agent能力暴跌25.7%，2元成本却让全行业沉默了
关于大模型评测诊断NoneLinear
https://nonelinear.com
- 评测榜单——已囊括300+大模型、300+评测维度，每周更新大模型评测结果
- 模型选型降本——一键选出最合适模型，效果更优，成本降低50%以上
- 智能模型超市——统一API，一键调用全球所有大模型，GPT5 / Gemini2.5 / Claude4.5免费体验，高并发，自动故障切换，实时监控模型调用效果
关注“鲸栖”小程序，掌握最新AI资讯
本文来自网络搜集，不代表鲸林向海立场，如有侵权，联系删除。转载请注明出处：http://www.itsolotime.com/archives/14706