距离我写下这个系列的第一篇已经过去整整一年。如果翻翻当时的评论区会发现大多数人的担忧还停留在“ChatGPT会不会让翻译、文案、客服集体失业”而现在大家问得最多的问题变成了“我该怎么把它塞进我的业务流里并且别给我整出幺蛾子”。这个提问方式的转变本身就说明了人工智能正在从一个需要“防备”的新闻事件变成手边实实在在可以调度、评估、纠错的工具。作为系列的第二篇我不想再堆一遍“大模型改变世界”的宏大叙事只想聊聊这一年来我在实际项目和行业观察中看到的东西大模型的能力边界到底在哪里落地时最容易在哪个环节翻车以及下一阶段最值得下注的方向是什么。1. 从“聊天玩具”到“工作流组件”这一年的变化比想象中更本质1.1 真正值钱的不是模型参数而是上下文工程一年前大家用ChatGPT的方式绝大多数还是“你问一句它答一句”本质上把它当成一个更聪明的搜索引擎。但后面你会发现单轮问答能解决的事情非常有限因为模型不了解你的业务背景、数据格式和验收标准。这一年来我和很多团队交流下来发现大家开始把重点从“这个模型行不行”转向“我能不能把业务信息装进它的上下文里”——也就是所谓的上下文工程。举个最常规的例子。你想让模型帮忙提取客户邮件中的关键诉求并生成结构化回复。如果你只是把邮件原文粘贴过去然后问“这封邮件说了什么”模型大概率会给你一段干巴巴的摘要格式还不稳定。但如果你在提示词里明确写出你是一位客户成功专员请提取邮件中的客户姓名、订单号、问题类型、紧急程度以JSON格式输出字段名分别为customer_name、order_id、issue_type、priority如果信息缺失对应字段填“unknown”不要自行推断。同样一个模型输出质量立刻变得可用。这告诉我一个很直接的道理模型参数是别人训练好的但上下文是你自己的。谁能把业务规则、数据形态、输出约束清楚地写进提示词谁就能把同一个模型的产出质量拉开一个档次。这里还有一层容易被忽略的细节上下文窗口并不是越长越好。很多新模型把上下文窗口从几千 token 扩到几十万 token看起来能一次塞进整本手册但模型对远处内容的注意力权重会显著衰减。实践中的体感是如果喂进去的资料超过一定篇幅模型往往会漏掉关键信息反而更容易出现自相矛盾。我现在的习惯是先让模型对长文档做分段摘要或关键词提取只把最相关的片段拼进上下文而不是一股脑把整本手册丢给它。这就像让一个实习生做报告你不能把手推车那么厚的资料全部堆在他桌上而是要先把相关页码折好角。1.2 工具调用让大模型从“说话”迈向“动手”如果说上下文工程是这一年的基本功那么工具调用机制的出现才是真正把大模型从聊天玩具推向工作流组件的那一步。所谓工具调用就是模型在生成文本时不再仅限于输出自然语言而是可以输出一段结构化指令——比如调用某个接口、执行一段代码、查询一次数据库——程序收到指令后替它执行再把结果返回给模型继续下一步。最简单的一个例子你让模型“帮我查一下当前库房库存如果A物料低于100件就生成补货单”。模型本身不会连接库存系统但你可以提前配置一个查询库存的函数并告诉模型“当你需要库存数据时调用get_inventory(物料编号)这个函数”。模型在推理过程中一旦判断需要库存数据就会生成一条调用指令程序执行并返回结果模型再基于这个数决定要不要生成补货单。整个过程有点像把模型当成一个会“使唤人”的项目经理——它不必亲自干活但它知道该找谁干活、什么时候找。这一机制的商业意义非常大。过去我们做AI应用还停留在“机器人聊天”的层面用户说什么它答什么最后还得人工去点按钮完成操作。现在通过工具调用大模型可以被嵌入真实的业务流程用户说“把上周的项目周报用邮件发给参与人员”模型可以调用搜索周报的接口、获取通讯录的接口、调用邮件发送接口一气呵成。当然工具调用也会带来新的风险——模型可能误调用、连环调用甚至把自己绕进死循环。所以我个人建议任何涉及真实写操作的工具调用最前面一定要加一道“人工确认”的闸门。你可以让模型把所有待执行动作先列出来用户点一下确认再真正放行。代价是多了一次点击收益是挡住了大量灾难性失误。1.3 评判标准变了从“像不像人”到“能不能用”还有一个微妙但重要的变化大家对AI产品的接受门槛已经从“这个机器人说话像不像真人”变成了“这个流程跑下来的成本、出错率、人工介入频率到底划不划算”。图灵测试式的浪漫逐渐褪去取而代之的是非常朴素的投产比思维。我听到过不止一个业务负责人说“我不需要它跟我寒暄我要它把我给它的那堆电子表格读准确别把客户的电话号码串行就行。”这种心态转变反而让技术选型变得更清晰模型偶尔说错一句不痛不痒的客套话没人会追究但如果它把进货数量从1000错写成10000那才是真正的重大事故。所以现在做AI项目第一步永远是定义“什么样的错误不可接受”而不是追求“什么都能回答”。这个定义会直接影响后续所有的技术决策——是上检索增强还是做人工复核还是干脆限制模型的自由发挥只让它做单选或填空。2. 大模型的“聪明”是检索式联想不是真正的推理2.1 概率生成机制决定了它的优点和硬伤很多人觉得大模型无所不知是因为它回答问题时的语气实在太自信了。但从底层机制来看它的核心任务非常单纯在一个巨大的概率空间里搜索最可能出现在当前位置的那个词一个词一个词地把句子“接”出来。它读过的文本量确实惊人可以覆盖几乎所有学科和语言但它本质上是在做模式匹配和联想而非像人类那样基于逻辑规则和物理常识进行推导。我用一个比方来理解这件事大模型像一个读过海量文献的实习生。你问他任何问题他都能马上组织出一段听起来很专业的回答因为他脑海里存了太多类似的话题。但他并不真正理解这些文字背后的因果链条和现实约束。你问他“昨天的报纸头条是什么”他会编一个很像头条的标题你让他做一道三阶行列式的计算他可能用错公式然后还振振有词。这不是因为模型“坏”而是因为它的工作机制里本来就没有一个“与外部事实逐条核对”的环节。这就引出了幻觉的根源模型输出的每一句话都是概率博弈的结果。它会选择语义上最通顺、分布上最可能的词而不会去“检查”这个词是否对应真实世界里的某个数据。除非你在上下文里额外给了它可引用的参考资料或者给它接上能调用的数据库工具否则它根本没有渠道去验证事实。理解了这一点你就不会再寄希望于“换个更大参数的模型就能彻底消灭幻觉”因为只要生成机制不变幻觉就永远存在我们能做的只是降低概率、增加校验手段。2.2 用思维链与工具化补齐推理短板既然模型的强项是语言联想而不是逻辑推理那我们在实际使用中就要扬长避短。最有效的手段之一是引导模型把推理过程“写下来”而不是直接给结论。这招在业界叫思维链提示本质上非常简单在提示词里加一句“请先列出你的分析步骤再给出最终答案”。比如你让模型做一道应用题“A班和B班一共有80人A班比B班多12人求两个班各有多少人。”如果直接问模型可能真的会一本正经地算出奇怪答案。但如果让模型先设未知数x再列方程再求解它的正确率会高出很多。原因在于当模型把中间步骤显式地写出来时每一步的选择都在上下文里留下了线索后面的生成会更容易受前面步骤的约束——这和人做数学题时“打草稿”的逻辑是相通的。更重要的是如果需要处理高精度的计算我强烈建议不要指望模型的心算能力而是让它调用代码解释器或计算器工具。你可以告诉模型“遇到数学计算请生成Python代码并运行把运行结果作为答案。”这一招几乎可以完全消除计算类的低级错误。模型擅长的是把自然语言问题翻译成代码逻辑而代码执行结果是确定性的两侧结合性价比极高。我在客户的财务对账场景里验证过用这种方法处理金额汇总、税点计算准确率能稳定到和人工差不多并且效率高出几十倍。2.3 别被排行榜带偏很多评测成绩其实是“备考成绩”很多技术团队选型时会下意识把模型在公开排行榜上的分数当成硬指标。这个思路可以理解但非常危险。原因有两点第一公开榜单的测试集很可能被模型开发者提前用于训练或调优相当于考试题在考前被泄了题第二榜单上的题目大多是知识问答、逻辑推理、代码生成这类通用任务和你自己业务里的长尾、方言、非结构化文档几乎没有重叠。我见过一个很典型的案例某团队选了一个在代码评测榜上分数极高的模型结果拿去做企业内部运维工单分类准确率反而比一个“分数低一些但支持私有化部署”的模型差不少。原因也很简单——运维工单里充满了内部缩写、设备型号和特定的情绪化表达公开训练数据里这些内容占比极低。后来他们花了一周时间整理了自己业务中一百条真实工单做一个“回归测试集”每次模型版本更新都跑一遍。别看这个测试集小它的指导意义远远超过任何公开大榜单。所以我的建议是任何项目启动时都应该建立一个至少包含20个典型业务样本的“私有评测集”这些样本必须是从真实生产环境里抽样出来的而不是自己现编的。把待选模型都跑一遍人工打分对比维度包括准确度、格式符合度、拒答率、响应时间。这个过程虽然土但它是唯一不会被“刷榜”现象干扰的选型依据。3. 下一站多模态、Agent 与“有手有脚”的AI3.1 多模态不是“看图识字”而是打开物理世界的数据入口过去一年大模型从只能读文字进化到可以读图片、图表、音频和视频。很多人觉得多模态的进步只是“能看图了”但在实际业务里它的价值远不止于此。我们做过一个供应链项目需要从供应商发来的上百张送货单照片里提取品名、数量、批次号。传统做法是配OCR再写一堆规则遇到印章遮挡、手写备注就抓瞎。后来换成多模态模型直接把整张图片丢进去让它理解版式并输出结构化字段准确率提升了一个量级。不过要泼一盆冷水多模态模型的理解能力远没有它在演示视频里那么神奇。对于空间关系复杂、质量很差的图片比如一幅多层嵌套的架构图或者一张细颗粒度很小的工程图纸模型依然会犯“看错位置”“认错线条”的毛病。它更擅长的是对整体语义做概括而不是像素级的精确分析。所以我的建议是多模态适合做“哪里有问题就大概知道往哪查”的粗筛不适合做需要百分之百精确的终审。所有关键字段最好加一道规则校验或人工抽检。3.2 Agent的三大组件规划、记忆、工具如果要在未来一年的技术趋势里选一个最值得关注的方向我会投给Agent。通俗地说Agent就是把大模型从“回答问题的人”变成“分派任务的人”让它能够自主把一个复杂目标拆解成多个小步骤逐步执行并汇总结果。拆开来看一个能干活儿的Agent必须拥有三大组件规划能力把“写一份竞品分析报告”拆成“查找竞品名单、逐个浏览官网、提炼核心卖点、对比差异、生成结构化报告”记忆能力既包括当前任务里的短期上下文也包括可以长期复用的知识库例如公司过去沉淀的战略文档和客户反馈工具调用能力驱动搜索接口、代码解释器、内部业务API甚至其他专用模型。这三个组件缺一不可。规划能力不够Agent就会一条道走到黑比如搜索不到信息时反复用同一个关键词硬搜记忆能力不够它就会在长任务执行到一半时忘记最初的约束条件导致输出风格和格式前后不一致工具调用能力不够它就永远停留在“纸上谈兵”只能给出建议而无法真正完成操作。我自己尝试搭建过一个“行业动态日报”Agent每天自动搜索某几个细分赛道的关键词抓取相关新闻用模型做摘要和分类再按固定格式输出到企业内部群。整个链路跑通并不难真正难的是让它“稳定地不出错”。搜索接口偶尔会返回一堆无关内容模型摘要偶尔会张冠李戴文件输出偶尔会丢一个段落。这些错误单独看都很小但如果无人值守地跑一个月累计起来就是一场灾难。所以我的结论是Agent可以提升效率但现阶段必须保留“人在环上”的监督位。你可以让Agent每天按时交付初稿但发布之前至少要有人扫一眼。3.3 别急着上全自动先做“半自动”人机协同关于Agent化我见过太多团队冲得太猛希望AI自动读取所有邮件、自动回复、自动下单结果上线第一天就出了乌龙——把客户投诉邮件归类错误自动回复了一段价格优惠的话术场面一度非常尴尬。所以我现在的原则是自动化程度要和“错误代价”成正比。如果任务的错误代价很低比如生成草稿、整理格式那就上全自动如果任务的错误代价很高比如支付、法务审核、对外发布那就做人工确认的“半自动”。具体操作上我会在Agent流程里设置两个关键节点一个是任务启动前的“方案确认”即Agent先把执行计划和可能调用的工具列表展示给用户用户确认后再执行另一个是任务完成后的“结果摘要”即Agent把执行了哪些动作、每个动作的结果如何汇总出来用户只需花30秒扫一眼。这样一个简单的“两步确认”能把绝大多数风险拦截在产生实际影响之前。4. 落地项目里最常见的三个坑幻觉、成本、数据安全4.1 幻觉问题压不干净但可以管理幻觉是所有大模型应用绕不开的第一座大山。先说结论以当前技术条件无法让模型在任何情况下都百分之百不说假话。但我们可以通过一套组合拳把它的负面影响压制到业务可接受的范围。目前最主流的企业级方案是检索增强生成英文缩写是RAG。思想很简单模型回答之前先从你自己的知识库或文档库里检索出与问题最相关的若干片段把这些片段塞进上下文再让模型“基于这些片段回答”。听起来很完美但实际落地时坑比想象中多。第一个坑是检索质量不高。企业内部文档多到上万份关键词检索常常把大量无关片段捞出来模型只好挑几个看着顺眼的来答。第二个坑是片段之间本身存在矛盾例如不同版本的制度文件对同一个报销额度的描述不一样模型会毫无意识地把两个版本的内容缝合起来。第三个坑是模型有时会跳过上下文里的正确答案反而偏好自己训练时见过的高频说法。排查这类问题时我的经验是遵循一条固定的链路第一看模型回答中引用的原文片段是不是真实存在于知识库中第二看这个片段本身是否包含了用户问题的答案第三看提示词是否明确要求“只能引用上述片段”。如果这三步都正常但输出还是错的再考虑调整模型或升级知识库的分块策略。最怕的是跳过排查直接开骂模型这样既解决不了问题还会把问题掩盖起来。4.2 算不过账的成本token消耗是一座隐形金矿很多项目在技术验证阶段顺风顺水一到商业化阶段就卡住了核心原因是没算清楚“每个任务到底要烧掉多少token”。现在主流大模型API按token计费输入要钱输出也要钱。一次简单问答可能只要几百token但如果你的业务需要处理长文档、多轮对话或者复杂的Agent调用链单次任务的token消耗会被放大十倍甚至几十倍。给你算一笔很直观的账假设每个业务请求平均消耗2000 token每天有1万次请求那一天就是2000万 token。按目前市场常见的费率估算折算成人民币大概在数百元级别。单看一天似乎还能接受但一个月下来就是数万元而且这还没算上流式输出和中转成本。更麻烦的是随着业务量增长这笔费用会线性膨胀如果毛利润率本来就不高那AI带来的那点效率提升很可能全被API账单吃掉。针对这个问题我一般会给团队开三剂药第一剂不要所有请求都上大模型。先用规则或小模型过滤掉明显的重复、简单和异常请求只把真正复杂的任务转给大模型。第二剂做好缓存。很多用户提的问题高度相似完全可以把第一次回答和当时的输入摘要存起来后续命中直接返回。第三剂压缩上下文。长文档进来后不要原文全塞先做一次事实提取和摘要只保留与任务相关的细节。这三板斧用下来API成本通常能降到原来的三分之一而效果影响很小。4.3 数据安全与隐私企业内部落地的头号隐形门槛如果说幻觉和成本是看得见的坑数据安全就是那个等你跳下去才发现的坑。很多办公场景的数据高度敏感合同金额、薪资表、未公开的产品计划、客户联系方式。一旦这些数据被发送到公有云模型的处理队列就相当于被第三方机构托管了一份副本。哪怕服务方承诺不留存企业在合规层面也很难向审计解释清楚。目前企业落地最常用的三种模式一是完全私有化部署把开源大模型跑在自己的内网数据不出门但对硬件和运维团队的要求高二是混合架构敏感数据走本地小模型通用数据走云端大模型中间由网关做分流三是用支持本地知识库的私有化RAG服务把文档向量化和检索环节留在内网只把不含原始内容的中间表示传到外部模型。三种方案没有绝对好坏取决于企业规模和数据敏感程度。我还想提醒一个容易被忽视的点即便模型服务商承诺“不用于训练不保留长期副本”日志和排查工具往往还是会记录一部分请求内容。因此生产环境里一定要做数据脱敏比如先把姓名、电话、身份证号替换成占位符模型处理完再还原。这不仅是技术问题更是底线问题。在这个问题上宁可牺牲一部分效果也不要抱着侥幸心理。5. 未来不会突然冒出AGI但“窄AI”会静悄悄渗透进一切流程5.1 模型即平台而不是某一个超级应用胜出聊到未来很多人喜欢问“哪个AI应用会像微信一样成为超级应用”。我的判断是超级应用的机会窗口恐怕会越来越窄真正的主流形态是“模型即平台”。也就是说大模型会像水电和云服务一样嵌入到无数现有软件和业务系统中。你不会单独打开一个“AI对话框”而是不知不觉地在报表工具、开发环境、会议软件、供应链系统里和AI交互。这种形态对开发者的要求会更高。过去你会调API就能做出一个演示Demo现在你需要理解模型的能力边界需要设计好数据回流、效果评估和故障降级方案。一句话AI的能力会普及但把AI用好的人会一直稀缺。这其实是个好消息因为它意味着“懂业务懂AI”的复合型人才价值会越来越高。5.2 人机协作的新分工人是目标制定者和最终责任人当AI能写出合格的周报、整理出清晰的会议纪要、甚至给出初步的行业分析时人的角色不可避免地从“亲手做”变成“做决策”。但这个转变并不轻松。你需要更清楚地定义目标否则AI做出来你不满意你需要更强的鉴别能力否则AI偶尔胡说八道会变成你的锅你还需要更细的验收标准否则你拿到手的结果参差不齐反而比自己做还要累。打个比方过去你是写作者现在你更像主编。你要负责定选题、定结构、定风格底线然后让AI去铺陈文字和收集素材你最后通读把关。很多传统岗位的员工会抱怨这种转变增加了责任但其实它同时把我们从重复性劳动里解放了出来。关键就在于愿不愿意花时间学习“主编式”的协作方式。5.3 分享三条我现在觉得最值得做的事回到这个系列的延续主题“人工智能的未来”我不想给空洞的预言只想写三条我现在正在采用且亲身验证有效的经验。第一条先梳理流程再选模型。很多团队一上来就比模型参数其实更重要的是把业务流拆开找到哪些环节适合AI介入哪些环节坚决不动。大多数情况下AI只是替代其中一个信息处理节点而不是整套流水线。第二条建立自己的回归测试集。不管你是用开源模型还是商业API都要把公司里最典型的几十个业务case沉淀成一个固定测试集。每次模型版本更新、提示词修改、知识库升级都跑一遍这个测试集用规则或人工打分防止“修好了A问题弄坏了B问题”。第三条控制自动化野心。第一版先让AI做低风险的辅助工作比如草稿、摘要、分类等高可靠运行一段时间再逐步放开操作权限。走得慢一点反而能走得更远。最后分享一个我个人的小习惯每次接手新的AI项目我会拿一张纸写下“如果模型在这里错了会造成什么损失”再根据这个损失的等级去设计复核机制。这张纸看似简陋却救过我很多次。人工智能再聪明也只是一个能力很强但偶尔掉链子的协作者明白这一点我们才能真正驾驭它而不是被它的光芒晃花了眼。