有三个多月没给机核投稿了。中间痛苦迷茫了一段时间（听轻音乐才能睡着的地步，不然脑子转得停不下来），7月又赶上娃暑假来深圳，周末陪陪家人。
今天得空给大家分享下最近几个月关于大模型的阶段思考。算是从年初对数据工程领域未来趋势的设想，到年中遇到和看到的困境，再到模型能力认知进一步加深，以现在我觉得在当下模型能力范围内，什么样的应用方式才算更优解。
希望这些分享对在正做大模型应用的朋友们带来一点参考或启发。
一、当前AI大模型应用发展困境
年初DeepSeek的开源，让大家对模型能力有了一个全新的基准。因为是开源，企业可以直接本地部署，更多数据就可以安全地传给模型，内部自然就会诞生出更多机会和应用场景，所以大家都觉得2025年一定会出现越来越多的Agent应用。
我自己当时对数据工程领域（或者说数据中台部门）在这个趋势下可能的演变：
1、传统的底层ETL等平台，可能会逐渐退化成一堆原子的Tools / MCP Servers，上游则会长出一个类似Dify的WorkFlow平台，封装这些原子能力；
2、基于WorkFlow平台，面向数据工程进一步做除了写SQL之外的提效工作；面向游戏业务运营策划让他们能自助取数分析；
3、当应用和Flow行为数据积累到一定量后，就有机会演化出更智能的AI Agent，真正成为开发或业务的专家助手
随着WorkFlow平台逐步成型，确定已经跑出来不少应用。但真要做好其实还挺难的：
1、业务自助分析助手虽然有一些效果，但是存在两个核心卡点：
它往往只能落在一些很小的场景里，本质上和过去做的专题看板差别不大。对业务来说，它可能在一个阶段性的分析周期里挺有用，但缺少后续演化空间，很难长久
模型给的分析思路经常不稳定，大多数时候和预期对不上
2、提效层面停留在固定Flow的散点应用，不知道如何过渡成真正的Agent
二、大模型产品的设计范式
其实对于第一个问题，之前在做的Text-to-SQL产品已经遇到类似困境，发现是走到了一条死胡同：模型能力存在天花板（或者说没办法让模型和人的知识对齐） -> 模型的输出不符合预期 -> 用户逐渐失去信任 -> 最后慢慢流失
相信很多实际在做大模型产品的同学都会遇到类似困境。但是有意思的是，如果把这个对于数据工程同学来说有点“鸡肋”的能力，转而推给给更上游、具有一定SQL能力的业务运营策划时，结果有些出乎意料，这些用户的留存反而很高。
思考为什么会出现这个现象，大概类似下面的图：
数据开发因为本职工作是编写SQL，熟悉一段时间业务后，搜索空间就会收敛到很小的范围，而模型并没有经过这样的训练（暂时大家也都不知道怎么训练），搜索空间会远远大于有经验的数据开发人员
但是对于运营策划来说，他们的本职工作是游戏数据分析。对他们而言，SQL本身就是工具，他们的搜索空间和模型的搜索空间反而比较接近，所以在一些场景下模型的帮助能真正发挥作用
进一步看，在业务分析领域，模型的搜索空间又会远远大于运营策划人员本身的认知范围。
那怎么解这个问题？
前段时间Andrej Karpathy演讲提到，从当前模型能力看，核心还是应该构建半自助的辅助产品更合理。
“在现阶段，鉴于与易犯错的LLM合作，你想构建的与其说是钢铁侠机器人，不如说是钢铁侠战衣。与其构建自主代理的华而不实的演示，不如构建拥有定制GUI和UX的半自主产品。”
调研业内比较火的AI产品，比如Cursor或Granola，发现它们都有一个设计范式。
总结看：
1、分为3个主区域：用户本职工作区 + Chat区 + 隐藏的知识区
2、用户基于工作经验，在自己已经收敛固化的搜索空间内主导，渐进式完成内容创作，模型并不会干预（这里用“内容创作”，是觉得未来AI产品应该都能让用户觉得自己在创作，类似我们游戏的MOD，很多好玩的游戏诞生于MOD）
3、搜索过程中必然会遇到拓展到其他小空间内搜索的需求，比如查一下表的数据、查一下函数写法、检查代码对不对，这些能力可以由模型提供，模型只起到一个辅助作用
这里衍生提一个疑问，为什么是「通过对话」来连接“我”和“模型”呢，而不是把模型原子能力封装成一个个Tool，我在产品上手动执行选择点击等操作？
自己的一些朴素的推理：
如果终极形态：“我”的语言输入指令 -> Agent作出思考和响应 -> 预期完全一致
那么反过来： Agent语言输入指令 -> “我”做出思考和响应 -> 预期完全一致 也应该同样成立
这样就得到一个和“我”一样的Anget，也是AGI的最终目标
因为人类收到的第三方指令只能来源于语言（意识可能是另一个层面的事），Agent不可能对“我”进行点击等操作，所以只能是语言作为核心媒介
所以，在当前大模型能力下，产品遵循这个设计范式可能是更合理的选择。
三、未来发展
和年初判断相比，其实整体方向没有变，但是这几个月的体会是：在WorkFlow应用 和 真正的Agent之间，还需要有一个工作平台承载，所以：
短期：大概率还会持续依赖WorkFlow，产出一堆垂类场景应用
中期：在这些应用的经验和产品设计范式积累上，逐渐孕育出一个新的AI工作平台
长期：在这个平台里，将“Chat自然语言 -> 调用工具 -> 获取预期结果” 的全过程数据沉淀下来，再用这些数据对模型进行微调或强化，本质是让基础模型收敛在用户本职工作的搜索空间内，这样才有机会迭代成开发或业务自己的小模型专家助手。
写在最后
最后还想再谈一谈AI工作台：
1、「本职工作区」应该怎么设计？
对于代码开发同学来说，设计成一个IDE足够了。现在比较火的Claude Code，大家喜欢的应用方式就是集成在VS Code或者Cursor中，保留了IDE工作区不变，只把Claude Code作为Chat区和工作区交互。但是对于数据工程领域，这个本职工作区也是一个IDE么？
2、隐藏知识区，怎么更合理地给到模型？
最近国外比较火的Kuse这个产品，采用无限画布来管理context（context工程，是说模型能力逐步进化，让模型知道哪些context知识更重要），将任意内容都可以丢到画布里作为知识，哪些知识让哪些模型看到，用户自己决定。这是最合理的方式么？
3、Context知识，哪些应该训到模型内，哪些应该放在知识区？
这其实就是大家讨论的RAG和微调的区别。如果从人的角度类比：有些知识我们完全可以背下来；有些知识只记得目录索引，用到的时候根据索引查出正确的内容；有些知识则完全依赖搜索才能获得。模型应该也有类似的“三层记忆”，但这三者之间应该流转？
这些问题暂时还想不明白，先记录在这里，后续如果能实践出一些结论再分享给大家。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。