# 后来我才明白，AI 真正难的，是让它好好干活

前几年，我也和很多人一样，谈起人工智能，总喜欢从模型讲起。

参数有多少，架构有什么变化，训练数据用了多少，排行榜又刷新了几个百分点。那些漂亮的曲线总让人兴奋，仿佛模型只要足够聪明，剩下的问题便会自动消失。

后来真正把 AI 接进业务系统，我才发现事情完全不是这样。

模型明明读过公司文档，回答时却依然一本正经地胡说；演示环境里表现惊艳，一到真实场景便频繁超时；测试几次觉得成本不高，调用量上来以后，账单却像忘了关的水龙头；好不容易搭起一个智能体，遇到稍微复杂的任务，它就在几个工具之间来回打转，忙得热火朝天，却迟迟交不出结果。

也是到了这个时候，我才慢慢想明白：

这个世界不缺能解释 AI 原理的人，真正稀缺的，是能让 AI 好好干活的人。

所谓 “干活”，不是让模型生成一段看起来不错的文字，而是让它进入真实世界，稳定完成任务，还能承担得起结果。

这意味着，我不仅要知道 AI 能做什么，也要知道它不能做什么；不仅要释放它的能力，还要在它与真实世界之间留下一道缓冲；不仅要给它足够多的资料，还要确保这些资料足够新、真正有用，并且整理得足够清楚。

再往后看，还要把模型、数据、工具、流程、评估和权限连接起来，让它们成为一个可以长期运行的系统。

这大概就是我所理解的 AI 工程。

# 从研究智能，到交付智能

AI 研究员关心的是：怎样让模型变得更聪明？

而我越来越关注另一个问题：怎样把已经存在的智能，变得好用、可靠，而且足够便宜？

这两件事都重要，只是解决的问题不同。

前者像是在实验室里研究一种性能更强的发动机，后者则要把发动机装进汽车，接好油路、电路、方向盘和制动系统，再确保它能在雨天、高速公路和拥堵的早高峰里稳定运行。

发动机马力再大，刹车失灵，也不能上路。

今天的大模型已经拥有相当惊人的能力。它能阅读、写作、总结、编程，也能调用工具完成多步任务。

但我越来越清楚，模型的能力并不会自动变成业务价值。

在 “它能够做到” 和 “它每天都能做好” 之间，还隔着一条很长的工程鸿沟。

数据从哪里来？知识怎样保持新鲜？资料之间发生冲突时该相信谁？答案如何验证？工具执行失败怎么办？敏感信息如何保护？成本和延迟怎样控制？哪些事情可以交给 AI，哪些决定必须由人负责？

这些问题不如模型发布会那样令人兴奋，却决定了一个 AI 系统究竟能不能真正落地。

# 演示不难，难的是第二天还能用

做一个 AI 演示其实并不难。

挑一个模型，写一段提示词，接上聊天界面，半天就能看到效果。它会礼貌地回答问题，偶尔还会冒出一句让人眼前一亮的话。

可演示和产品之间，隔着无数个异常分支。

用户没有按照预期提问怎么办？检索没有找到答案怎么办？文档之间互相矛盾怎么办？模型调用失败怎么办？工具执行到一半中断怎么办？同一个问题今天和明天给出不同答案怎么办？

演示只需要证明一次 “它能做到”，生产系统却要面对一万次 “如果没有做到，该怎么办”。

真正进入业务以后，我不能只盯着成功的那一次。我需要让系统能够处理失败，知道自己不知道，并且在出错时可以重试、降级、追踪和恢复。

我还要看得见每一步发生了什么：系统检索了哪些资料，模型为什么调用这个工具，成本花在了哪里，答案又是从哪个环节开始偏离事实的。

传统软件大多建立在确定性逻辑之上：相同输入，通常得到相同输出。

AI 系统却把一个具有概率性的模型放进了核心链路。它偶尔灵光闪现，也会偶尔自信地走错路。

这让我更加确信，过去积累的软件工程经验并没有失效，反而变得更加重要。

没有扎实的软件工程，模型能力越强，系统有时反而越难控制。

# 我眼里的 AI 工程师：80% 软件工程师，20% AI 调教师

在我看来，AI 工程师并不是换了名称的算法研究员。

他首先是一名软件工程师，然后才是一名懂得驾驭模型的人。

那 80% 是什么？

是接口设计、数据管道、任务调度、权限控制、缓存、并发、日志、监控、测试和故障恢复；是把一个模糊需求拆成稳定的模块；也是在流量增长十倍以后，系统依然能够运行。

剩下的 20%，才是模型选择、提示设计、上下文组织、检索策略、工具编排和输出约束。

但这 20% 也不只是 “把提示词写得更漂亮”。

我需要理解模型在什么情况下容易犯错，再通过系统设计缩小它自由发挥的空间：需要事实时让它检索，需要计算时让它调用工具，需要结构化结果时限制输出格式，风险过高时加入人工审核。

说到底，我要搭建的是一套管道，让模型能够拿到新鲜、相关、可信的知识，在合适的时候调用合适的工具，对结果进行检查和修正，失败时安全退出或请求帮助，同时把准确率、延迟和成本控制在可以接受的范围内。

说得再直白一点：

就是让 AI 真正干活，不胡说八道，也不烧穿预算。

# 当工具越来越简单，真正的门槛还剩什么？

模型会越来越强，接口会越来越简单，现成的框架也会越来越多。

今天需要几个人折腾几周的功能，明天可能只需要调用一个接口。很多原本显得神秘的能力，正在迅速变成普通工具。

于是我也常常问自己：当模型和工具都变得触手可及，AI 工程真正的门槛还剩下什么？

想来想去，我觉得答案不是记住多少框架，也不是收藏了多少提示词。

真正的门槛，是架构思维。

架构思维不是画一张看起来复杂的系统图，而是看清每个环节的职责、边界和关系，并知道怎样把它们组合成一个能够长期运行的系统。

用户提出问题之后，要不要先识别意图？应该去哪里检索资料？检索不到怎么办？多个来源互相矛盾时如何选择？模型是否有权调用外部工具？执行之前是否需要确认？结果应该交给规则、另一个模型还是人工审核？某个环节失败以后，是重试、降级，还是立即终止？

这些问题单独看都不神秘，真正困难的是把它们串起来。

一个环节做到八十分并不难。难的是十个环节连接起来以后，整个系统仍然有八十分，而不是在误差与异常的层层累积中只剩二十分。

所以，我现在更愿意用几个朴素的问题衡量自己的能力：

我能不能把数据、知识、模型、工具、工作流和人连接成一条完整链路？

我能不能处理那些正常流程之外，却一定会在现实中出现的边界情况？

我能不能让 AI 在该发挥时发挥，在该停下时停下？

我能不能让今天做出的原型，半年以后仍然可以维护；让一百个人使用的系统，有机会扩展到十万人？

会调用模型，只是拿到了零件。

能把这些零件组装成一台长期稳定运转的机器，才是真正的工程能力。

# 先想清楚哪里能用，再考虑怎么用

接触 AI 越久，我越觉得，一个人最重要的能力可能不是会用多少模型，而是知道哪些问题应该交给 AI，哪些不应该。

AI 擅长处理语言、归纳资料、识别模式、生成草稿，也擅长在一定约束下完成具有模糊性的任务。当一个问题允许存在多个合理答案，错误又可以被发现和修正时，AI 往往能够显著提高效率。

但如果一项任务要求结果绝对确定，错误后果极其严重，或者涉及不可逆的现实操作，我就不能把决定权直接交给模型。

AI 可以帮助医生整理病历，却不应该在没有专业人员确认的情况下独立作出高风险诊断；可以帮助财务人员发现异常，却不应该绕过审批直接完成大额付款；可以生成代码，却不应该未经测试便自动发布到生产环境。

我习惯把任务分成三个层次：

• AI 可以直接执行的低风险任务；
• AI 可以提出建议，但结果需要验证的中风险任务；
• AI 只能提供辅助，不能独立决策的高风险任务。

真正成熟的 AI 系统，不是让 AI 接管一切，而是把它放在最合适的位置。

我需要做的，不只是给 AI 增加能力，还要为它画出边界。

# 我想在 AI 与真实世界之间，留下一道缓冲

模型生活在语言和概率的世界里，现实世界却充满权限、责任、金钱、设备，以及许多不可逆的后果。

一句错误的回答可以重新生成，一笔错误的付款却不能当作什么也没发生。

因此，我始终觉得，AI 不能毫无阻隔地连接真实世界。在模型和业务系统之间，需要留下一道缓冲。

这道缓冲可以是输入检查、权限控制、规则校验和结果验证，也可以是操作预览、人工确认、限额机制、沙箱执行与审计日志。

AI 可以起草一封退款邮件，但真正退款前，系统还要检查订单状态和退款额度；AI 可以生成数据库操作建议，但执行前必须经过权限验证和风险检查；AI 可以规划一组任务，但每次调用外部工具，都应该受到明确的范围约束。

缓冲层不是为了拖慢 AI，而是为了吸收它的不确定性。

它很像汽车里的刹车和安全气囊。我们不会因为发动机性能很好，就认为刹车多余。相反，正因为汽车跑得快，可靠的制动系统才更加重要。

我想做的，就是把模型偶尔出现的聪明，变成一个系统长期可以依赖的可靠。

# 我正在补上的四项能力

# 动态 RAG 与高级检索：让 AI 找到 “此刻正确” 的知识

大模型知道很多，却未必知道公司内部刚更新的制度、昨天新增的产品功能，或者某位客户当前的合同条款。

RAG 解决的是 “让模型先查资料，再回答” 的问题。但真正有效的 RAG，远不只是把文档切成小块，再塞进向量数据库。

我需要关心资料是否足够新、来源是否可信、内容是否仍然有效；也要考虑文档之间发生冲突时以哪一份为准，以及不同问题究竟应该查询说明文档、实时数据库，还是历史工单。

一套可靠的知识系统，至少要持续收集新资料，筛掉重复、过时和缺乏依据的信息，按照主题、时间、来源与可信度进行组织，最后再把复杂内容整理成人和模型都容易理解的形式。

知识量足够，并不等于把所有资料堆在一起。

一间仓库可以塞满书，却不一定能让人找到答案。好的知识库更像一间有人认真打理的图书馆：资料充足，分类清楚，更新及时，重要结论还能追溯到原始来源。

这也让我意识到，AI 工程师还需要一种知识策展能力。

我要判断什么信息值得进入系统，怎样保留上下文，怎样标记时效性和可信度，又怎样把零散资讯整理成结构清楚、容易理解的知识。

AI 的上限或许由模型决定，但它在具体业务里的表现，往往取决于我给了它怎样的资料。

# 智能体工作流：让模型从 “会说” 走向 “会做”

聊天机器人负责回答，智能体则需要完成任务。

它可能要读一封邮件，识别客户意图，查询订单，生成解决方案，再把结果写回工单系统。这已经不是一次模型调用，而是一条包含判断、执行、校验和恢复的工作流。

我见过一些智能体项目失败，原因不是模型不够强，而是给了模型过多自由。

一句 “请自行规划并完成任务”，听起来很智能，运行起来却可能变成一场昂贵的随机游走。模型反复思考、重复调用工具，最后既没有完成任务，也很难解释问题究竟出在哪里。

我现在更相信，可靠的智能体不是完全自治，而是 “受约束的自治”。

确定性的步骤交给代码和工作流引擎；需要语义理解与灵活判断的环节交给模型；高风险动作则加入权限检查或人工确认。每一步都应该有明确的输入、输出、终止条件和失败策略。

好的智能体，不是最像人的那个，而是最能把事情稳定做完的那个。

# 评估体系：最难，也最重要

传统软件可以断言一个函数的返回值是否正确，AI 输出却常常没有唯一答案。

一段摘要可以有多种写法。一条客服回复既要准确，也要完整、得体并符合公司政策。仅仅凭感觉判断 “看起来还不错”，远远不足以支撑生产系统。

因此，我越来越觉得，AI 工程最难的一步往往不是开发，而是先定义 “什么叫做好”。

一套成熟的评估体系，需要覆盖离线测试、线上表现、链路分析和版本回归。评估指标也不能只有回答准确率，还要关注引用是否可靠、知识是否过时、任务是否完成、风险是否被拦截、延迟是否可以接受，以及一次任务究竟花了多少钱。

没有评估体系，AI 开发就像在雾里开车。

我一直在调整方向，却不知道自己是在前进，还是只是在左右摇摆。

# 模型蒸馏与边缘 AI：让智能跑在成本允许的地方

不是所有任务都需要调用最强、最大的模型。

分类、信息抽取、意图识别、格式转换等高频任务，往往可以交给更小的模型。通过蒸馏、微调、量化和任务专用优化，大模型的一部分能力可以迁移到更轻量的模型上。

这不仅能够降低调用成本，也能减少延迟，并改善数据隐私。

我想象中的成熟 AI 系统，不是一个超级模型包办一切，而是多种模型相互协作：小模型处理高频、明确的任务，大模型负责复杂推理，规则系统守住确定性边界，人类处理高风险与模糊决策。

工程能力，恰恰体现在知道什么时候应该使用大模型，什么时候根本不必使用。

# 到最后，我是在管理不确定性

把这些事情放在一起，我慢慢发现，AI 工程师真正管理的，其实是各种各样的不确定性。

RAG 管理知识的不确定性；智能体工作流管理行动的不确定性；评估体系管理质量的不确定性；蒸馏和边缘计算管理成本与部署的不确定性；缓冲层管理 AI 进入真实世界以后带来的风险。

而架构思维，负责把这一切连接起来。

模型可以有创造力，系统不能没有边界。

一个优秀的 AI 产品，并不是从不犯错，而是知道错误可能发生在哪里，能够尽早发现，并把后果控制在可以接受的范围内。

它应该知道什么时候回答，什么时候查资料；什么时候可以自动执行，什么时候必须等待确认；什么时候可以继续尝试，什么时候应该坦率地说：“我无法确认，需要人工处理。”

我想，这或许就是 AI 工程师最重要的能力：

不是盲目追求一个更聪明的模型，而是设计一个值得信任的系统。

# 会用 AI，不等于能交付 AI

接下来的几年，大模型还会越来越强，调用成本也会继续下降。今天需要复杂提示和流程才能完成的任务，明天也许只需要一次简单调用。

但我并不觉得 AI 工程会因此变得不重要。

恰恰相反，模型能力越普及，竞争越会从 “谁能接入模型”，转向 “谁能把模型嵌进真实业务，并持续产生结果”。

到那时，真正稀缺的不会只是知道 Transformer 原理的人，也不会是收藏了几百条提示词的人，而是那些具有架构思维，能够把数据、知识、模型、工具、流程、评估和现实责任连接起来的人。

我希望自己也能成为这样的人。

既知道 AI 能做什么，也清楚它不应该做什么；既能让系统获得最新、最有用的资讯，也能把庞杂资料整理成容易理解的知识；既敢于释放模型的能力，也愿意在它与真实世界之间留下一道可靠的缓冲。

能够把各个环节串起来，处理那些演示中不会出现、现实中却无处不在的边界情况；让 AI 在规则内工作，也让系统在需求变化、用户增加和模型升级之后，依然可以维护和扩展。

会解释 AI，说明我理解了一项技术。

能让 AI 真正干活，才说明我完成了一项工程。

研究员推动智能的边界。

而我更想做的，是把这种智能带进现实。

毕竟现实世界最终奖励的，从来不只是最聪明的技术，而是那些找对位置、守住边界，并真正解决了问题的系统。