很久没更新了感觉更新中间件使用和八股文细节也没太多意义。加上最近几年AI技术栈膨胀的很快什么提示词工程、MCP、Skills新名词一天一个新模型、新框架、新协议、新概念一波接一波信息密度高到足以让很多开发者在真正动手之前先陷入学习焦虑是不是得先补完 Transformer、注意力机制、训练流程、微调算法、向量数据库原理才能谈“做 AI 应用”作为一个重度AI使用者这两年也接入过不少AI大模型做应用今天就先讲一讲如何做AI应用开发、需要掌握哪些技术吧明天我会继续分享一下个人这一年多VibeCoding的一些浅薄经验。如果目标是做基础模型研发答案当然是肯定的但如果目标是做一款真正可用的 AI 应用答案恰恰相反。对绝大多数应用开发者来说真正需要掌握的不是“模型如何被造出来”而是“模型如何被接进系统、约束进流程、放进真实业务里并且稳定地跑起来”。AI 应用开发本质上不是一门纯算法工程而是一门新的应用工程。模型当然是核心能力之一但决定成败的往往不是模型参数量而是上下文组织、工具接入、知识获取、工作流设计、评测体系和工程边界。很多项目最后效果不佳并不是因为模型不够强而是因为系统设计没有把模型的能力用在最合适的位置上。本文不做具体学习教程只做一些学习经验。这篇文章我主要回答一个很具体的问题如果只是做 AI 应用而不是研究 AI 底层那么到底该学什么哪些必须学哪些理解即可哪些可以先放一放。一、先把问题说清楚什么叫“AI 应用开发”先区分两个概念。一种工作是“做 AI 模型本身”训练、微调、对齐、推理优化、模型架构改进。这类工作偏算法、系统和算力基础设施。另一种工作是“做 AI 驱动的软件”让模型参与搜索、问答、写作、客服、数据处理、流程自动化、代码辅助、知识助手、办公助手、运营工具、业务中台甚至只是某个产品中的一项功能。这类工作更接近传统软件工程只不过系统中多了一个高度不确定、但能力极强的组件大模型。后者才是大多数开发者眼下真正会接触到的领域。从工程视角看AI 应用开发更像是在回答以下问题模型应该在系统的哪一步被调用调用前要提供哪些上下文模型输出怎么约束成可用结果私有数据如何接进去工具如何让模型安全调用结果如何评测、回归、监控和迭代换句话说AI 应用开发不是把“模型”单独学会而是把“模型作为一个能力组件”学会。二、做 AI 应用真正绕不过去的核心能力1. 提示词工程定义接口很多人第一次接触 AI 开发最先学的是提示词工程。但“提示词工程”这个词已经被说烂了甚至被误解成某种靠经验和玄学堆出来的技巧集合。实际上它更接近接口设计。一个成熟的提示词本质上要完成四件事第一定义任务。模型要干什么不干什么目标是什么评判标准是什么都必须明确。模糊描述会直接转化为模糊输出。第二补齐上下文。模型不是在真空中工作的。它需要知道当前场景、输入格式、已有信息、业务规则、角色视角有时还需要知道上一轮状态和可用工具。第三约束输出。输出是自然语言、JSON、Markdown、SQL、代码还是结构化字段字段是否必填是否允许解释过程是否允许不确定回答这些都应提前写清楚。第四规定边界。遇到信息不足怎么办遇到歧义怎么办超出职责怎么办发现输入不合法怎么办。这些不是异常情况而是生产环境里的常态。所以真正值得练习的不是“会不会几个万能 prompt 模板”而是能否把提示词写成一份接近产品规格说明的东西。很多人写 prompt 的方式仍然像在聊天而实际可用的 prompt 更像一份函数签名加调用约定。提示词工程之所以重要不仅因为它影响效果更因为它往往是 AI 应用中最便宜、最直接、迭代速度最快的一层。很多问题看上去像模型不行其实只是任务没有定义清楚。2. 上下文工程用于提升AI 应用质量如果说提示词定义了任务那么上下文工程决定了结果上限。绝大多数真实场景中模型的问题不是“不会推理”而是“缺信息”。用户问一个业务问题模型如果看不到私有知识库、近期文档、业务规则、数据库数据、历史会话和当前状态那么它再强也只能猜。这就是为什么现在越来越多开发者开始用“上下文工程”这个词而不只是“提示词工程”。很多项目到后面会发现瓶颈并不在 prompt而在上下文组织方式给少了不够用给多了噪音太大给错了会误导给得无结构会稀释重点。上下文工程通常包括几部分用户当前输入会话历史系统规则外部知识检索结果工具执行结果当前任务状态输出格式要求这意味着做 AI 应用的人必须开始具备一种新的设计能力为模型构造工作记忆。传统软件更多是在组织程序状态而 AI 应用同时还要组织“模型理解所需的状态”。很多应用体验差不是因为没接模型而是因为没有把模型放进一个信息充足且边界清晰的上下文里。3. RAG多数业务问题先别想着微调先把知识接进去RAG 被谈得很多但落到实践里仍有不少项目把它做成了“文档丢进去 向量检索 拼 prompt”的简化版本然后很快发现效果并不好。原因通常不是 RAG 这个思路有问题而是实现过于粗糙。RAG 的价值不在“模型会查资料”而在“模型终于能使用原本不在参数里的知识”。对于企业知识问答、文档助手、客服答疑、合同解析、规范解读、产品知识支持、研发知识查询这类场景RAG 往往比微调更先解决问题。但要把 RAG 做好开发者至少需要理解以下环节文档清洗。原始文档并不天然适合检索。重复页眉页脚、目录噪音、错位表格、扫描件残缺、无关说明这些都会直接污染召回结果。RAG 的第一步不是“嵌入”而是清理输入。切块策略。切太大检索命中后信息过载切太小上下文断裂。不同文档类型需要不同策略。API 文档、制度文件、会议纪要、FAQ、产品说明书其适合的 chunk 方式并不一样。元数据设计。仅靠语义相似度通常不够。标题、时间、来源、版本、部门、标签、文档类型等元数据往往决定了后续能否做过滤、重排和可信引用。召回与重排。多数失败不是“查不到”而是“查到的不是最该排前面的”。向量检索负责找相关内容关键词检索负责兜底精确匹配重排则决定最终喂给模型的是哪几段。答案合成与引用。RAG 的目标不是把检索结果原封不动贴给用户而是把信息组织成可信答案。什么时候该引用原文什么时候该总结什么时候该保留不确定性这是应用层必须负责的事情。说到底RAG 更像一套知识接入工程而不是一项插件功能。如果只是做 AI 应用这部分必须掌握到能独立设计和排查的程度。因为很多业务系统里知识质量就是产品质量。4. 工具调用与工作流AI 应用从“会说”到“会做”的关键一步很多人理解 AI 应用仍停留在“对话”和“生成”层面但真正能进入生产环境的系统往往不是只会回答问题而是能调用工具、执行操作、处理状态、串联流程。例如根据自然语言创建工单读取数据库生成日报从邮件里提取信息并更新 CRM读取文档后生成结构化摘要查询日历并安排会议从代码库检索后解释变更影响调用业务接口完成审批、查询、写入这类能力的本质不是模型更聪明而是模型被放进了一个工具化环境中。因此AI 应用开发者必须具备工作流思维哪些步骤应该由代码做哪些步骤交给模型判断哪些步骤必须由工具执行失败如何重试状态如何保存怎么避免模型乱做决定。一个常见误区是上来就追求“全自动 Agent”。实际上大部分可交付系统更适合从“半确定性工作流”做起。也就是用代码管控流程骨架在特定节点调用模型做理解、提取、归纳、分类、规划在明确授权的节点调用工具执行动作对每一步结果做日志、校验和回退这样设计的系统通常比“让模型自由发挥”更可靠。因为 AI 最怕的不是能力不足而是无边界。工作流的价值正是把模型放进可控边界中。5. 模型选择不是追最新而是做权衡做 AI 应用并不意味着要深挖模型原理但至少要具备模型选择能力。这项能力看似简单实际上非常关键因为它直接影响成本、时延、效果和部署架构。选模型时至少要看这几个维度推理能力是否够用指令遵循是否稳定输出格式化能力是否可靠上下文窗口是否满足需求工具调用能力是否成熟成本是否可接受延迟是否符合产品体验是否需要多模态能力是否支持私有化或特定部署要求很多应用不需要“最强模型”只需要“最适合当前任务的模型”。例如分类、提取、重写、规整输出这类任务更重要的是稳定和成本而复杂问答、多步规划、代码理解则可能更依赖强推理能力。真正成熟的系统通常不会只有一个模型而是会做任务分层简单任务用便宜模型复杂任务再调用强模型。这其实和传统系统中的缓存、分层调用没有本质区别只是资源单位从“服务”和“CPU”变成了“模型能力”和“token 成本”。6. 评测体系AI 项目最容易被忽视也最该先补的一课传统软件里一个功能对不对很多时候是可以被明确断言的AI 应用则不同结果常常带有概率性、模糊性和场景依赖。也正因此评测在 AI 项目里比在普通项目里更重要。没有评测提示词改得再勤、模型换得再快、RAG 调得再细最后都只能靠“感觉”判断效果。而一旦进入多人协作、持续迭代、线上运营阶段“靠感觉”会迅速失效。AI 应用至少要建立两类评测功能评测。系统是否能完成任务接口是否可调用结构化输出是否满足格式要求工具调用是否成功异常输入是否被正确处效果评测。答案是否准确摘要是否覆盖重点分类是否稳定召回是否相关风格是否一致流程决策是否合理。进一步再细分就会涉及提示词回归测试检索命中率与召回质量评测结构化字段准确率工具调用成功率幻觉率用户满意度反馈线上失败样本采集与再评测这套能力并不花哨却是 AI 应用从 demo 走向产品的分水岭。很多项目前期做得很快后期却越改越乱本质原因通常就是没有构建评测闭环。7. 日志、监控和可观测性AI 系统的排错方式和普通系统完全不同在普通 Web 应用里排错往往围绕请求链路、异常堆栈、数据库状态和服务日志展开。而 AI 应用还要多面对一层不确定性提示词变了、模型变了、上下文变了、检索结果变了、工具调用参数变了最终输出就可能完全不同。因此AI 应用必须高度重视可观测性至少要能追踪这些信息使用的是哪个模型和版本系统 prompt 是什么传入了哪些上下文检索返回了哪些片段工具调用了哪些参数模型输出了什么哪一步失败用户最终是否接受结果只有这些信息足够完整线上出现“偶发性错误”时才有可能复盘。否则很多问题在表面上都长得差不多回答不准、格式错、调用失败、无关答案、偶发超时但根因完全不同。在 AI 应用里日志不是上线后再补的而应从第一版开始就进入系统设计。三、这些概念很热但不必一上来就学太深1. LangChain值得了解但别把框架当起点LangChain 对 AI 开发者的吸引力很强因为它把 prompt、memory、tool、retriever、agent 等常见能力组织成了一套统一抽象。对快速试验和原型开发来说这类框架确实能省下很多胶水代码。但不少项目的问题也恰恰出在这里还没搞清楚自己的任务边界就先把复杂框架搬进来结果系统结构被框架牵着走排错成本和理解成本都很高。更务实的学习方式是先理解 AI 应用里有哪些基本组件再用 LangChain 或类似框架去提高开发效率而不是反过来通过框架认识问题。如果一个项目只需要简单的 prompt 调用、结构化输出和少量工具接入直接用官方 SDK 或轻量封装往往更清晰。只有当链路变复杂、需要可复用编排时框架才会真正体现价值。所以LangChain 该学但优先级不应高于提示词、上下文、RAG 和评测。它是工具不是前置条件。2. 微调理解适用边界比掌握训练细节更重要很多刚入门 AI 应用的人会自然地把“效果不好”归因到“是不是要微调”。这其实是一个很典型的思维惯性过去做传统机器学习数据不准就训练于是到了大模型时代也会本能地认为效果不稳就应该调模型。但在大多数应用场景里微调并不是第一解。很多问题更适合先通过以下方式解决明确任务定义优化 prompt增加 few-shot 示例做结构化输出约束改善 RAG 质量把复杂任务拆成工作流增加规则校验层微调更适合用在这些场景输出风格和格式高度固定特定术语和表达要求一致分类标签稳定且样本充分通用模型在某类任务上长期不稳定已有可持续积累的数据集和评测集如果只是做 AI 应用不需要一开始深挖微调算法细节但至少要具备判断能力什么时候该继续做系统层优化什么时候才值得进入模型定制阶段。3. MCP是工具接入协议不是新一代“万能框架”MCP 这类协议之所以受到关注是因为 AI 应用越来越需要接入外部世界。模型光会说没有意义它需要看到文件、数据库、文档、代码库、消息系统、业务接口甚至要在特定权限下调用这些资源。MCP 可以理解成一层标准化的上下文与工具接入协议。对应用开发者而言重要的不是把协议规范逐条背下来而是理解它解决的问题如何把工具暴露给模型如何把资源安全地供模型读取如何在不同系统之间统一接入方式如何减少每个工具都单独写一套胶水层的重复成本如果项目已经进入“多工具、多数据源、多集成系统”的阶段那么理解 MCP 这类协议会非常有帮助。但如果还停留在单一页面、单一模型调用层面也没必要为了追热点而提前复杂化系统。4. Skill不是功能模块而是经验封装Skill 这个概念本质上是在做方法复用。它不是“某个具体 API”而更像把一套成熟的操作流程、提示词约束、输出规范、可用资源和使用场景封装起来让系统在合适的时机自动调用。对团队而言Skill 的意义很大它能把个人经验沉淀成团队能力把一次成功实践变成可以反复复用的组件。例如把客服回复规范封装成一个 Skill把合同摘要流程封装成一个 Skill把某种研发文档解析规则封装成一个 Skill把某个项目的知识查询和答复方式封装成一个 Skill如果说 MCP 更关注“接入”那么 Skill 更关注“复用”。前者是让模型拥有手和眼后者是让模型拥有稳定的工作习惯。对只做 AI 应用的开发者来说理解 Skill 的价值已经足够等项目进入团队协作和流程沉淀阶段再进一步做规范化封装会更自然。四、如果不做底层研发哪些能力必须掌握哪些理解即可如果把学习路径压缩成一个更现实的版本可以分成三层。第一层必须掌握这是做 AI 应用绕不过去的能力提示词工程上下文工程RAG 基础与知识接入工具调用与工作流设计模型选型与成本意识评测与回归日志与可观测性部署与基础工程化只要项目要上线这些迟早都要补。第二层建议掌握这层会显著提升效率但不是所有项目的必需品LangChain / LangGraph 或同类编排框架多模型路由与任务分层结构化输出与 schema 驱动开发安全策略、内容过滤和权限控制更完整的 RAG 优化手段比如重排、混合检索、查询重写第三层理解边界即可这层有价值但如果当前重点是做应用不必先钻进去微调训练细节Transformer 数学原理推理引擎优化自研向量数据库大规模训练与分布式系统低层模型对齐方法它们并不无关只是和“尽快做出可靠 AI 应用”相比不是最优先投资。五、一个经常被忽略的事实AI 应用首先是产品其次才是 AI很多技术讨论喜欢把注意力放在“用了哪个模型”“接了什么框架”“参数怎么调”但对最终用户来说他们并不在乎这些。用户只在乎三件事它是否真的解决问题它是否稳定可信它是否比原来的方式更省时间这意味着AI 应用开发者最终仍要回到熟悉的产品和工程问题需求是否清晰交互是否自然成本是否可控延迟是否可接受错误是否可解释系统是否可维护结果是否可验证AI 只是让软件系统拥有了更强的理解和生成能力但并没有取消软件工程本身。相反它让工程的重要性变得更高了。因为模型越强系统越不能放任它无边界地工作。六、结语不要先把自己学成算法研究员再开始做应用对应用开发者来说眼下最容易走偏的有两条路。一条是过度轻视 AI以为“调个 API 就够了”另一条是过度敬畏 AI以为必须先补完整套底层原理才有资格开始做产这两条路都不对。更可行的路径是先把 AI 当成一个新的系统组件来看待围绕它补齐应用层真正需要的能力。理解提示词学会上下文组织掌握 RAG知道何时用工作流、何时接工具建立评测和监控能判断微调是不是必要能理解 MCP 和 Skill 这种新抽象在系统里各自扮演什么角色。做到这一步已经足够做出很多真正有价值的 AI 应用。而且越早开始做越容易看清楚一件事AI 应用开发最难的从来不是调用模型而是把模型放进一个正确的系统里。如果第一代互联网应用的核心命题是“把信息搬到线上”移动互联网的核心命题是“把服务装进手机”那么这代 AI 应用的核心命题大概就是把模型能力编排进真实世界的流程。这件事值得每一个应用开发者认真学一遍。