这两年总有人问我：我是干后端/前端/测试的普通程序员，现在转大模型应用开发是不是要从头学算法？我的回答一直很直接——不用。大模型应用开发和传统软件开发之间的墙，没有想象中那么高。它更像是在你已有的工程能力上，多接了一套“会说话的引擎”。这篇内容想解决的是：一个没有任何AI算法背景的普通程序员，怎么从零把大模型应用开发这件事落地。我把它拆成了六个步骤，覆盖认知、提示词、接口接入、知识库增强、工具调用、评测与成本控制。最后还会用一个小项目复盘整个过程。内容偏实操，适合想转方向但不知道怎么下手的人，也适合已经在做但总感觉哪里不对的开发者。1. 先搞明白：这行拼的不是“算法”，是“把模型拿来用”1.1 普通程序员手里其实已经握着一大半筹码很多人在转大模型应用开发之前，先把自己吓住了。看招聘要求上写着什么“熟悉深度学习原理”“了解Transformer结构”，就觉得这是算法岗的活。但实际上，大模型应用开发这个方向，绝大多数岗位做的事情是：把别人训练好的模型，通过各种方式集成到业务系统里，让它能回答你的问题、调用你的接口、处理你的文档。这件事的本质是什么？是工程。你想想传统开发里最熟悉的那套东西：需求拆解、接口设计、数据流转、异常处理、日志排查、部署上线。在大模型应用开发里一样都不能少。模型只是替你完成了一部分“文本理解”和“文本生成”的工作，但围绕模型做的那些脏活累活——怎么把用户问题包装好、怎么把检索结果塞进上下文、怎么保证它返回的JSON能被你的代码解析——全部还是你熟悉的工程活。我见过很多技术栈很传统的人，比如一直写管理后台的，转过来做知识库问答系统，上手速度比某些只懂算法不懂工程的还要快。原因很简单：他知道怎么把模型输出接到业务逻辑里，知道怎么处理超时和重试，知道怎么设计一套可维护的调用封装。所以第一件事，把心态摆正。你不是从零开始，你只是迁移。1.2 大模型应用开发的核心拆解：四层结构如果我们把一个典型的大模型应用拆开看，其实就四层。对普通程序员来说，每一层都有切入路径，不一定全都要精通。层级做什么对应传统开发经验模型接入层调接口、管Token、处理流式输出调用第三方REST API、处理网络IO增强层提示词设计、知识库检索、工具调用、Agent编排写模板、查数据库、调内部服务评测层建评估集、用量化指标卡质量写测试用例、做回归测试应用层业务功能、交互设计、权限控制、运营后台你最擅长的领域你不用一开始就四层全通。只要先把第一层跑通，再做第二层的某个点，你就已经迈进了这个圈子。之后逐步补全，是水到渠成的事。2. 转型第一步：先学会“把需求翻译成提示词”2.1 一个正经的提示词长什么样提示词工程是所有大模型应用开发的基础，也是门槛最低、见效最快的一步。很多人觉得提示词就是“用自然语言把需求写清楚”，这话对了一半。真正上生产的提示词，讲究的是结构化、可复用、结果可预期。我在实际项目中常用的一种写法是六要素模板：角色：你是一个专门处理售后工单的客服助手。 任务：根据用户描述，判断工单紧急程度。 约束：只能输出“高”“中”“低”三个字之一，不要解释原因。 已知信息：以下是用户提交的完整工单内容…… 输出格式：JSON，字段为 { "level": "high" | "medium" | "low" }。 示例：输入……输出……你可以看到，它不是一段散文，而是一份接口文档式的说明。这样写的好处有三个：模型更容易理解边界、你的代码后续解析输出更稳定、换了新模型之后提示词梯度更平滑。2.2 三个提升质量的实用技巧第一，给示例永远比给描述更管用。你写“请提取关键信息”，不如给它一个“输入-输出”对。模型本质上是在做模式匹配，你给它越清晰的对齐锚点，它生成内容就越准。第二，把复杂的任务拆成两步。比如要生成一份周报，不要让它一口气完成“总结+润色+排版”，而是先让它从聊天记录中提取关键事件，再单独用一段提示词做润色。拆得越细，每一步的可控性越强，出了问题也好定位。第三，让模型先写思路再给答案。有些任务需要推理，直接催它给结果容易出错。你可以在提示词里加上“请先列出验证步骤，再给出最终结论”。这类似于让模型在内部走一遍思考链，实测下来能明显减少低级错误。提示：提示词不是越长越好，冗余信息会稀释关键指令。核心原则是——每个词都在约束输出的一种可能性。3. 转型第二步：把模型“接进工程”，而不是人工粘贴复制3.1 最小可用调用代码，五分钟跑通现在主流的模型服务，基本都遵循同一套HTTP风格的接口规范。不管你用哪家，只要懂HTTP请求，就能调通。我用最基础的requests库给你演示一遍，去掉所有抽象封装：import requests API_BASE = "https://your-service-endpoint/v1" # 替换为你的服务地址 API_KEY = "your-api-key" # 替换为你的密钥 MODEL_NAME = "your-model-name" # 替换为你的模型标识 payload = { "model": MODEL_NAME, "messages": [ {"role": "system", "content": "你是一个简洁的技术问答助手，回答控制在100字以内。"}, {"role": "user", "content": "什么是RAG？"} ], "temperature": 0.2, "max_tokens": 500, "stream": False } resp = requests.post( f"{API_BASE}/chat/completions", headers={"Authorization": f"Bearer {API_KEY}"}, json=payload, timeout=30 ) resp.raise_for_status() data = resp.json() answer = data["choices"][0]["message"]["content"] print(answer)这段代码就是大模型应用开发里最核心的“水龙头”。你那套复杂的业务，本质上都是在这段调用前后做文章——前面准备消息，后面解析结果。3.2 工程化必须处理的四件事很多初学者跑通上面这段代码就觉得自己会了，但距离“能上生产”还差四个基本功。第一，超时与重试。模型服务经常慢，有时候三五秒，有时候二十秒。你要给请求设置超时时间，还要对限流、过载这类错误做退避重试。我的经验是：连接超时10秒，读超时60秒，重试最多3次，指数退避。第二，流式输出。生成长文本时用户一定不想盯着空白页面等。流式接口会按块返回内容，你需要把SSE格式的数据流解析出来，一边接收一边推给前端。调试流式的时候建议先打印原始报文，别直接处理解析后的结果，不然你根本不知道协议哪里出问题。第三，消息历史管理。模型是无状态的，你把整个聊天记录都塞进messages里。但上下文窗口是有限的，而且塞太多会又慢又贵。简单做法是只保留最近N轮，再加一个“历史摘要”塞进system里。这是每个大模型后端都要做的基础功课。第四，输出校验与兜底。模型输出不是严格约束的，总有意外格式。你在解析它返回的JSON时，一定要做容错处理，解析失败要设计重试或走人工兜底流程。你把模型当人看，它偶尔是会“犯迷糊”的。4. 转型第三步：用RAG让模型学会“查资料”4.1 为什么模型会一本正经地胡说模型有知识盲区。它的训练数据有截止时间，它没读过你公司的内部文档，它不知道你这套系统里刚上线的接口长什么样。可如果你是直接问它，它会因为“无法承认自己不知道”这个训练特性，编一个看似合理的答案出来，这就是幻觉。RAG要解决的问题，就是让模型在回答之前，先到你的文档库里检索相关资料，再把资料塞进上下文中，让它基于资料回答。你可以把RAG想象成“开卷考试”。模型不再凭记忆硬答，而是看着你递过去的参考材料作答。4.2 RAG落地五步法我建议你第一步不要碰那些复杂的检索算法，先把最简单的流程跑通，再逐步优化。整个链路是：文档切分。把大段文档切成固定大小的小块。常见做法是500到800个字符左右切成一段，段与段之间重叠100字符左右，保证上下文连贯。文本向量化。调用embedding接口，把每一小段文字变成一组向量。建索引存储。把向量和原文一起存进向量数据库。轻量级项目可以用文件型嵌入式向量库，数据量大了再考虑分布式方案。召回。用户提问时，把问题向量化，在库里找最相似的Top-K段。增强生成。把召回的原文片段拼接到提示词里，明确要求模型“只能依据以下材料回答，不得使用内部知识”。第五步的提示词模板我想给你一个可以直接抄的版本：以下是参考资料，用[source]包裹： [source]……参考资料1……[/source] [source]……参考资料2……[/source] 请只依据上面资料回答问题。如果资料中没有答案，请直接回复“资料中未找到相关信息”，不要自行编造。回答时注明内容对应哪个引用来源。4.3 切分和召回的真实经验，这是一般教程不讲的切分看起来简单，做起来全是坑。按字符硬切会把一句话切成两半，导致检索到无意义碎片。我的经验是要优先按段落和句子边界切。比如Markdown文档，先按标题层级分块，每个标题下内容宁可长一点，也别切碎。表格内容最好整块保留，切成一行一行的就没法看了。召回环节最常遇到的问题不是“没召回到”，而是“召回到的但没用”。你的文档可能包含大量相似描述，向量相似度并不能完全代表语义相关性。所以我后来都会加一道重排：先用向量召回Top-50，再用一个重排序模型或规则（比如关键词加权）从中筛出Top-5。这一步能明显提升答案质量，但初期可以不做，先把基础流程跑通。5. 转型第四步：用Function Calling把“手”交给模型5.1 模型永远在“说”，让它“做”才是关键大模型应用开发里最有突破感的一步，是让模型调用你的函数。模型本身不会执行任何代码，但你可以给它描述一系列工具，让它根据用户需求，输出一段结构化的“调用意图”，你的代码再根据这段意图去真正执行。举个简单例子，你的业务系统里有个查询订单状态的函数：def query_order_status(order_id: str) -> dict: return {"order_id": order_id, "status": "已发货"}你不直接告诉模型这个函数长什么样、内部怎么写的，而是给它一张“功能名片”：{ "type": "function", "function": { "name": "query_order_status", "description": "根据订单号查询订单当前状态", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号" } }, "required": ["order_id"] } } }你把这个名片随请求一起发给模型。模型分析用户的话之后，会返回一个特殊的tool_calls字段，里面写着“应该调用query_order_status，参数order_id是123456”。你的代码收到之后执行函数、拿到结果，再把结果拼进messages给模型生成最终人类可读的回答。5.2 工具调用的完整循环与常见坑完整流程通常是这个循环：用户提问。模型返回文本，或返回工具调用指令，或两者都有。你的代码检查有没有tool_calls。有就执行对应函数。把函数结果作为一条新的tool消息追加到messages里。再次调用模型，让它基于工具结果生成最终回答。循环，直到模型不再返回工具调用。这个机制能让你做出真正的“智能体”：订机票、查天气、读数据库、改动工单状态，全都能通过这一套完成。但这个环节有四个高频坑，提前告诉你：参数名必须和schema完全一致，差一个字母函数都可能挂掉，要做参数校验。给模型描述工具时不要用模糊语言，参数说明最好带示例值，减少模型猜错的概率。限制工具数量。你塞十个功能相似的工具，模型反而更容易选错。优先给少数几个高区分度的工具。设置循环次数上限。万一模型陷入“调用→看结果→再调用”的死循环，必须能强制中断，一般上限5到8次。6. 转型第五步：Agent是放大版的工具调度，但别迷信6.1 什么是Agent，以及一个容易翻车的建议最近Agent这个词特别热，好像不说自己在做Agent就落伍了。但我得给普通程序员提个醒：Agent本质就是“模型+规划+工具+记忆”的组合体，它比普通工具调用多了“规划”这一层。模型不是每次直接决定调哪个工具，而是先拆解子任务，再一步步推进。听起来很强大对吧？但也有代价：链路变长、错误被放大、调试难度翻倍。模型上一步判断错了，后面几步全跟着错。你兴致勃勃地写了一个“能自动做市场调研”的Agent，结果它中途把数据来源搞错，后面产出的报告完全不能用，这个问题非常常见。我给你的建议是从“限制”开始。别一上来就搞开放式Agent。先让它在固定流程里做规划。比如“只允许通过这三个工具完成这个固定任务”，而不是“随便你怎么做，把结果给我就行”。限制自由度，就是限制失控范围。6.2 最小可用Agent的骨架逻辑一个最小Agent的核心循环，用文字描述大概是这样的：1. 接收用户目标 2. 模型根据目标生成下一步行动（可能是调用工具/可能是给出最终回答） 3. 执行工具，观察结果 4. 把结果作为新的上下文，继续让模型决策 5. 重复直到模型输出最终回答，或达到步数上限你在实现的时候，不要想得太复杂。先做三个核心模块就够撑起一个demo：规划模块：就是一条提示词，要求模型“先列计划，再逐步执行”。执行模块：就是第5节写的Function Calling循环。记忆模块：用一个列表保存用户目标和前面每一步的结果。等这个最小骨架稳定跑通之后，你再去研究如何动态调整策略、如何引入复杂记忆管理。很多人Agent项目烂尾，根本不是技术不会，而是一开始目标定太大，我见过太多类似的案例了。7. 转型第六步：评测这件事，做得越早越省钱7.1 先建评估集，再做优化传统开发里，改代码要做回归测试。可大模型应用像一个“非确定性函数”，同一个输入，每次输出都可能不完全一样。如果没有评测机制，你根本说不清到底改好了还是改坏了。我强烈的建议是：从项目第一天开始，就建一个评估集。不需要多，先找30到50条典型问题，覆盖你业务里的主要场景，把对应的期望答案写好。之后你在调提示词、换模型、改检索参数的时候，把这个集子作为“回归测试”反复跑。看起来这是件费力的事，但回报极大。否则你很容易陷入“感觉这次效果好多了”的主观判断里，实际上换个输入就崩了。7.2 用大模型当裁判，省时又省力人工逐条评估太累，可以用大模型来当裁判，业内叫“大模型辅助评估”。逻辑很简单：让一个评测模型，对照参考答案，给被测模型的输出打分。我给你一个实用的评测提示词模板：你是严格的质量评审员。请比较候选回答与参考答案的一致性。 评分标准：5分=信息完全一致且无多余错误内容；3分=核心正确但有遗漏或表述混乱；1分=存在明显事实错误。 请只输出一个数字分数，不要输出任何解释。 问题：…… 参考答案：…… 候选回答：……实际项目中，我更建议你同时跑多个维度，而不是只打一个总分。下面这个表格是按维度打分的方法，可以借鉴：评测维度考察内容常见评分项准确率事实是否与参考一致是否引用正确资料、有没有新增错误内容完整性是否覆盖问题的关键部分有没有遗漏用户隐含需求可读性是否直接回答了问题有没有答非所问、过度冗长安全性有没有输出危险或违规内容涉及敏感指令时的拒绝表现稳定性同一问题多次回答是否一致结果一致性、逻辑连贯性自动化评测不是要替代人工，而是帮你在日常迭代里快速筛掉明显变差的情况，把人工精力集中在关键样本上。7.3 成本控制：让每个Token都花在刀刃上做应用开发，模型是按Token计费的。很多项目死因不是技术不成熟，而是没钱了。控制成本有几个成熟打法：缓存优先。相同或相似问题，优先命中缓存，不要每次都调模型。我可以告诉你，实际业务里大量问题是重复的。模型分层。高难任务用强模型，简单任务用轻量模型。比如判断用户意图这种简单分类，完全可以交给又便宜又快的轻量模型。Prompt瘦身。每次请求都带着一大段system指令，量大了成本很可观。定期检查哪些内容其实可以精简。批量处理。非实时场景，把多条请求打包成批处理任务，服务商通常有折扣。截断长对话。历史消息超过N轮就做摘要，别一股脑全带上。我见过一个团队，只做了“缓存+模型分层”这两条，月度模型调用成本直接降到原来的四成左右，效果一点没打折。8. 实操复盘：一个普通后端程序员的第一周8.1 需求与第一版为了让你更直观地看到整个路径，我用一个模拟场景完整复盘一遍。假设某团队需要一个“内部规章制度问答助手”，需求很简单：员工提问，助手基于制度手册回答，要附上制度出处。某后端同事A基础不错，但没做过大模型。他第一版方案是：把一份50页的Word制度手册全文复制进提示词，然后让模型回答。结果显而易见：提示词超长，接口直接报错，就算勉强能跑，Token开销也大，回答还前后矛盾。这就是典型的“还没学会走就跑”。8.2 逐步迭代的路径后来他按上面讲的六步重做了一遍：第一步，写清楚角色、任务、约束和输出格式的提示词，固定企业内部语气。第二步，把Word转成Markdown，按章节切块，每块控制在800字内，切好大概90块，调用embedding接口转成向量，存进轻量级嵌入式向量库。第三步，用户提问时，先召回Top-5文档块，拼进提示词里让模型基于资料回答。第四步，为了让回答“附出处”，他在提示词模板里明确要求“回答末尾列出参考资料的章节名”。第五步，收集了40条高频测试问题，搭了一个最小评估集，每次改动都跑一遍，用大模型打分。第六步，上线后加了个简单缓存，把前几天的高频问题命中率从零提到了将近一半。整个过程大概用了两周，其中一半时间花在数据清洗和切分规则调试上。最终的体验已经是：问“年假怎么算”，能两三秒内给出准确答案，并告诉你这在第几章第几条。8.3 最终技术栈回顾这个项目的技术栈非常朴素，没有用任何重型框架，我整理如下：模块选择说明后端语言Python生态成熟，AI相关库最多模型服务某云厂商标准接口兼容通用调用规范，后续可替换向量化embedding接口跟模型同厂商，省去拼接麻烦向量存储轻量级嵌入式向量库小数据量优先，不做运维负担前端简单聊天页面先跑通业务流程，UI后期补调度Function Calling用于后续接工单系统查状态可以看出，一个能落地的项目不需要你掌握什么“大杀器”。关键是每一步稳扎稳打，把基础能力的边界摸清楚。9. 转型路上的高发问题与避坑速查我把自己实操中遇到过的高频问题整理成了速查表，每个坑都配了解决办法，你遇到能少走很多弯路。现象根本原因解决思路回答总是泛泛而谈，不落地提示词缺少约束和示例补上角色、边界、输出格式、Few-shot示例同一个问题，每次答案都不一样temperature过高或上下文不稳定降低temperature，固定system指令，考虑用seed参数语言模型无法回答私域知识知识不在模型训练范围引入RAG，先检索再生成文档切了但检索不到答案切分策略不合理，语义被破坏按段落/标题切分，保留表格完整，调整重叠区召回内容相关但答案还是错的召回结果没有正确引导模型在提示词中明确“只依据材料回答”，必要时加重排工具调用返回错误或空值schema参数定义不清晰精简描述，给参数示例，增加解析校验模型调用越来越慢、费用越涨越高历史消息无限累积消息截断、历史摘要、相似问题缓存调完提示词，改好的效果变差了缺少评估集回归建好评估集，每次改动批量验证请求偶尔报超时、限流服务端不稳定加超时重试、退避策略、请求限流这些坑，我几乎每一个都踩过。比起“大模型很神奇”这种感受，解决这些工程问题才是你日常要面对的。最后说几句实在话看了那么多步骤，你可能会觉得内容量很大，有点焦虑。我特别想强调一点：你不必一次全学会。普通程序员转型大模型应用开发，最省力的顺序就是：先跑通一个API调用，再做一个小知识库问答，再试着加一个工具调用。你会发现每一步都在之前工程经验上自然生长。我个人这几年做下来最深的感受是：这个领域最值钱的不是所谓“模型魔法”，而是把模型能力稳定地嵌进业务流程的工程能力。你能让它在生产环境里稳定运行、可评估、可追溯、成本可控，这就已经超过大多数停留在“写个Demo玩一玩”阶段的人。如果你正在转型路上，可以先拿自己手头最熟悉的一个业务场景练手——库存查询、报表解读、内部规章制度问答，都行。把一个场景吃透，比跟风追新词有用得多。等到那个系统真正有人用起来，你会发现自己已经不再是“普通程序员”了。
这两年总有人问我：我是干后端/前端/测试的普通程序员，现在转大模型应用开发是不是要从头学算法？我的回答一直很直接——不用。大模型应用开发和传统软件开发之间的墙，没有想象中那么高。它更像是在你已有的工程能力上，多接了一套“会说话的引擎”。这篇内容想解决的是：一个没有任何AI算法背景的普通程序员，怎么从零把大模型应用开发这件事落地。我把它拆成了六个步骤，覆盖认知、提示词、接口接入、知识库增强、工具调用、评测与成本控制。最后还会用一个小项目复盘整个过程。内容偏实操，适合想转方向但不知道怎么下手的人，也适合已经在做但总感觉哪里不对的开发者。1. 先搞明白：这行拼的不是“算法”，是“把模型拿来用”1.1 普通程序员手里其实已经握着一大半筹码很多人在转大模型应用开发之前，先把自己吓住了。看招聘要求上写着什么“熟悉深度学习原理”“了解Transformer结构”，就觉得这是算法岗的活。但实际上，大模型应用开发这个方向，绝大多数岗位做的事情是：把别人训练好的模型，通过各种方式集成到业务系统里，让它能回答你的问题、调用你的接口、处理你的文档。这件事的本质是什么？是工程。你想想传统开发里最熟悉的那套东西：需求拆解、接口设计、数据流转、异常处理、日志排查、部署上线。在大模型应用开发里一样都不能少。模型只是替你完成了一部分“文本理解”和“文本生成”的工作，但围绕模型做的那些脏活累活——怎么把用户问题包装好、怎么把检索结果塞进上下文、怎么保证它返回的JSON能被你的代码解析——全部还是你熟悉的工程活。我见过很多技术栈很传统的人，比如一直写管理后台的，转过来做知识库问答系统，上手速度比某些只懂算法不懂工程的还要快。原因很简单：他知道怎么把模型输出接到业务逻辑里，知道怎么处理超时和重试，知道怎么设计一套可维护的调用封装。所以第一件事，把心态摆正。你不是从零开始，你只是迁移。1.2 大模型应用开发的核心拆解：四层结构如果我们把一个典型的大模型应用拆开看，其实就四层。对普通程序员来说，每一层都有切入路径，不一定全都要精通。层级做什么对应传统开发经验模型接入层调接口、管Token、处理流式输出调用第三方REST API、处理网络IO增强层提示词设计、知识库检索、工具调用、Agent编排写模板、查数据库、调内部服务评测层建评估集、用量化指标卡质量写测试用例、做回归测试应用层业务功能、交互设计、权限控制、运营后台你最擅长的领域你不用一开始就四层全通。只要先把第一层跑通，再做第二层的某个点，你就已经迈进了这个圈子。之后逐步补全，是水到渠成的事。2. 转型第一步：先学会“把需求翻译成提示词”2.1 一个正经的提示词长什么样提示词工程是所有大模型应用开发的基础，也是门槛最低、见效最快的一步。很多人觉得提示词就是“用自然语言把需求写清楚”，这话对了一半。真正上生产的提示词，讲究的是结构化、可复用、结果可预期。我在实际项目中常用的一种写法是六要素模板：角色：你是一个专门处理售后工单的客服助手。 任务：根据用户描述，判断工单紧急程度。 约束：只能输出“高”“中”“低”三个字之一，不要解释原因。 已知信息：以下是用户提交的完整工单内容…… 输出格式：JSON，字段为 { "level": "high" | "medium" | "low" }。 示例：输入……输出……你可以看到，它不是一段散文，而是一份接口文档式的说明。这样写的好处有三个：模型更容易理解边界、你的代码后续解析输出更稳定、换了新模型之后提示词梯度更平滑。2.2 三个提升质量的实用技巧第一，给示例永远比给描述更管用。你写“请提取关键信息”，不如给它一个“输入-输出”对。模型本质上是在做模式匹配，你给它越清晰的对齐锚点，它生成内容就越准。第二，把复杂的任务拆成两步。比如要生成一份周报，不要让它一口气完成“总结+润色+排版”，而是先让它从聊天记录中提取关键事件，再单独用一段提示词做润色。拆得越细，每一步的可控性越强，出了问题也好定位。第三，让模型先写思路再给答案。有些任务需要推理，直接催它给结果容易出错。你可以在提示词里加上“请先列出验证步骤，再给出最终结论”。这类似于让模型在内部走一遍思考链，实测下来能明显减少低级错误。提示：提示词不是越长越好，冗余信息会稀释关键指令。核心原则是——每个词都在约束输出的一种可能性。3. 转型第二步：把模型“接进工程”，而不是人工粘贴复制3.1 最小可用调用代码，五分钟跑通现在主流的模型服务，基本都遵循同一套HTTP风格的接口规范。不管你用哪家，只要懂HTTP请求，就能调通。我用最基础的requests库给你演示一遍，去掉所有抽象封装：import requests API_BASE = "https://your-service-endpoint/v1" # 替换为你的服务地址 API_KEY = "your-api-key" # 替换为你的密钥 MODEL_NAME = "your-model-name" # 替换为你的模型标识 payload = { "model": MODEL_NAME, "messages": [ {"role": "system", "content": "你是一个简洁的技术问答助手，回答控制在100字以内。"}, {"role": "user", "content": "什么是RAG？"} ], "temperature": 0.2, "max_tokens": 500, "stream": False } resp = requests.post( f"{API_BASE}/chat/completions", headers={"Authorization": f"Bearer {API_KEY}"}, json=payload, timeout=30 ) resp.raise_for_status() data = resp.json() answer = data["choices"][0]["message"]["content"] print(answer)这段代码就是大模型应用开发里最核心的“水龙头”。你那套复杂的业务，本质上都是在这段调用前后做文章——前面准备消息，后面解析结果。3.2 工程化必须处理的四件事很多初学者跑通上面这段代码就觉得自己会了，但距离“能上生产”还差四个基本功。第一，超时与重试。模型服务经常慢，有时候三五秒，有时候二十秒。你要给请求设置超时时间，还要对限流、过载这类错误做退避重试。我的经验是：连接超时10秒，读超时60秒，重试最多3次，指数退避。第二，流式输出。生成长文本时用户一定不想盯着空白页面等。流式接口会按块返回内容，你需要把SSE格式的数据流解析出来，一边接收一边推给前端。调试流式的时候建议先打印原始报文，别直接处理解析后的结果，不然你根本不知道协议哪里出问题。第三，消息历史管理。模型是无状态的，你把整个聊天记录都塞进messages里。但上下文窗口是有限的，而且塞太多会又慢又贵。简单做法是只保留最近N轮，再加一个“历史摘要”塞进system里。这是每个大模型后端都要做的基础功课。第四，输出校验与兜底。模型输出不是严格约束的，总有意外格式。你在解析它返回的JSON时，一定要做容错处理，解析失败要设计重试或走人工兜底流程。你把模型当人看，它偶尔是会“犯迷糊”的。4. 转型第三步：用RAG让模型学会“查资料”4.1 为什么模型会一本正经地胡说模型有知识盲区。它的训练数据有截止时间，它没读过你公司的内部文档，它不知道你这套系统里刚上线的接口长什么样。可如果你是直接问它，它会因为“无法承认自己不知道”这个训练特性，编一个看似合理的答案出来，这就是幻觉。RAG要解决的问题，就是让模型在回答之前，先到你的文档库里检索相关资料，再把资料塞进上下文中，让它基于资料回答。你可以把RAG想象成“开卷考试”。模型不再凭记忆硬答，而是看着你递过去的参考材料作答。4.2 RAG落地五步法我建议你第一步不要碰那些复杂的检索算法，先把最简单的流程跑通，再逐步优化。整个链路是：文档切分。把大段文档切成固定大小的小块。常见做法是500到800个字符左右切成一段，段与段之间重叠100字符左右，保证上下文连贯。文本向量化。调用embedding接口，把每一小段文字变成一组向量。建索引存储。把向量和原文一起存进向量数据库。轻量级项目可以用文件型嵌入式向量库，数据量大了再考虑分布式方案。召回。用户提问时，把问题向量化，在库里找最相似的Top-K段。增强生成。把召回的原文片段拼接到提示词里，明确要求模型“只能依据以下材料回答，不得使用内部知识”。第五步的提示词模板我想给你一个可以直接抄的版本：以下是参考资料，用[source]包裹： [source]……参考资料1……[/source] [source]……参考资料2……[/source] 请只依据上面资料回答问题。如果资料中没有答案，请直接回复“资料中未找到相关信息”，不要自行编造。回答时注明内容对应哪个引用来源。4.3 切分和召回的真实经验，这是一般教程不讲的切分看起来简单，做起来全是坑。按字符硬切会把一句话切成两半，导致检索到无意义碎片。我的经验是要优先按段落和句子边界切。比如Markdown文档，先按标题层级分块，每个标题下内容宁可长一点，也别切碎。表格内容最好整块保留，切成一行一行的就没法看了。召回环节最常遇到的问题不是“没召回到”，而是“召回到的但没用”。你的文档可能包含大量相似描述，向量相似度并不能完全代表语义相关性。所以我后来都会加一道重排：先用向量召回Top-50，再用一个重排序模型或规则（比如关键词加权）从中筛出Top-5。这一步能明显提升答案质量，但初期可以不做，先把基础流程跑通。5. 转型第四步：用Function Calling把“手”交给模型5.1 模型永远在“说”，让它“做”才是关键大模型应用开发里最有突破感的一步，是让模型调用你的函数。模型本身不会执行任何代码，但你可以给它描述一系列工具，让它根据用户需求，输出一段结构化的“调用意图”，你的代码再根据这段意图去真正执行。举个简单例子，你的业务系统里有个查询订单状态的函数：def query_order_status(order_id: str) -> dict: return {"order_id": order_id, "status": "已发货"}你不直接告诉模型这个函数长什么样、内部怎么写的，而是给它一张“功能名片”：{ "type": "function", "function": { "name": "query_order_status", "description": "根据订单号查询订单当前状态", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号" } }, "required": ["order_id"] } } }你把这个名片随请求一起发给模型。模型分析用户的话之后，会返回一个特殊的tool_calls字段，里面写着“应该调用query_order_status，参数order_id是123456”。你的代码收到之后执行函数、拿到结果，再把结果拼进messages给模型生成最终人类可读的回答。5.2 工具调用的完整循环与常见坑完整流程通常是这个循环：用户提问。模型返回文本，或返回工具调用指令，或两者都有。你的代码检查有没有tool_calls。有就执行对应函数。把函数结果作为一条新的tool消息追加到messages里。再次调用模型，让它基于工具结果生成最终回答。循环，直到模型不再返回工具调用。这个机制能让你做出真正的“智能体”：订机票、查天气、读数据库、改动工单状态，全都能通过这一套完成。但这个环节有四个高频坑，提前告诉你：参数名必须和schema完全一致，差一个字母函数都可能挂掉，要做参数校验。给模型描述工具时不要用模糊语言，参数说明最好带示例值，减少模型猜错的概率。限制工具数量。你塞十个功能相似的工具，模型反而更容易选错。优先给少数几个高区分度的工具。设置循环次数上限。万一模型陷入“调用→看结果→再调用”的死循环，必须能强制中断，一般上限5到8次。6. 转型第五步：Agent是放大版的工具调度，但别迷信6.1 什么是Agent，以及一个容易翻车的建议最近Agent这个词特别热，好像不说自己在做Agent就落伍了。但我得给普通程序员提个醒：Agent本质就是“模型+规划+工具+记忆”的组合体，它比普通工具调用多了“规划”这一层。模型不是每次直接决定调哪个工具，而是先拆解子任务，再一步步推进。听起来很强大对吧？但也有代价：链路变长、错误被放大、调试难度翻倍。模型上一步判断错了，后面几步全跟着错。你兴致勃勃地写了一个“能自动做市场调研”的Agent，结果它中途把数据来源搞错，后面产出的报告完全不能用，这个问题非常常见。我给你的建议是从“限制”开始。别一上来就搞开放式Agent。先让它在固定流程里做规划。比如“只允许通过这三个工具完成这个固定任务”，而不是“随便你怎么做，把结果给我就行”。限制自由度，就是限制失控范围。6.2 最小可用Agent的骨架逻辑一个最小Agent的核心循环，用文字描述大概是这样的：1. 接收用户目标 2. 模型根据目标生成下一步行动（可能是调用工具/可能是给出最终回答） 3. 执行工具，观察结果 4. 把结果作为新的上下文，继续让模型决策 5. 重复直到模型输出最终回答，或达到步数上限你在实现的时候，不要想得太复杂。先做三个核心模块就够撑起一个demo：规划模块：就是一条提示词，要求模型“先列计划，再逐步执行”。执行模块：就是第5节写的Function Calling循环。记忆模块：用一个列表保存用户目标和前面每一步的结果。等这个最小骨架稳定跑通之后，你再去研究如何动态调整策略、如何引入复杂记忆管理。很多人Agent项目烂尾，根本不是技术不会，而是一开始目标定太大，我见过太多类似的案例了。7. 转型第六步：评测这件事，做得越早越省钱7.1 先建评估集，再做优化传统开发里，改代码要做回归测试。可大模型应用像一个“非确定性函数”，同一个输入，每次输出都可能不完全一样。如果没有评测机制，你根本说不清到底改好了还是改坏了。我强烈的建议是：从项目第一天开始，就建一个评估集。不需要多，先找30到50条典型问题，覆盖你业务里的主要场景，把对应的期望答案写好。之后你在调提示词、换模型、改检索参数的时候，把这个集子作为“回归测试”反复跑。看起来这是件费力的事，但回报极大。否则你很容易陷入“感觉这次效果好多了”的主观判断里，实际上换个输入就崩了。7.2 用大模型当裁判，省时又省力人工逐条评估太累，可以用大模型来当裁判，业内叫“大模型辅助评估”。逻辑很简单：让一个评测模型，对照参考答案，给被测模型的输出打分。我给你一个实用的评测提示词模板：你是严格的质量评审员。请比较候选回答与参考答案的一致性。 评分标准：5分=信息完全一致且无多余错误内容；3分=核心正确但有遗漏或表述混乱；1分=存在明显事实错误。 请只输出一个数字分数，不要输出任何解释。 问题：…… 参考答案：…… 候选回答：……实际项目中，我更建议你同时跑多个维度，而不是只打一个总分。下面这个表格是按维度打分的方法，可以借鉴：评测维度考察内容常见评分项准确率事实是否与参考一致是否引用正确资料、有没有新增错误内容完整性是否覆盖问题的关键部分有没有遗漏用户隐含需求可读性是否直接回答了问题有没有答非所问、过度冗长安全性有没有输出危险或违规内容涉及敏感指令时的拒绝表现稳定性同一问题多次回答是否一致结果一致性、逻辑连贯性自动化评测不是要替代人工，而是帮你在日常迭代里快速筛掉明显变差的情况，把人工精力集中在关键样本上。7.3 成本控制：让每个Token都花在刀刃上做应用开发，模型是按Token计费的。很多项目死因不是技术不成熟，而是没钱了。控制成本有几个成熟打法：缓存优先。相同或相似问题，优先命中缓存，不要每次都调模型。我可以告诉你，实际业务里大量问题是重复的。模型分层。高难任务用强模型，简单任务用轻量模型。比如判断用户意图这种简单分类，完全可以交给又便宜又快的轻量模型。Prompt瘦身。每次请求都带着一大段system指令，量大了成本很可观。定期检查哪些内容其实可以精简。批量处理。非实时场景，把多条请求打包成批处理任务，服务商通常有折扣。截断长对话。历史消息超过N轮就做摘要，别一股脑全带上。我见过一个团队，只做了“缓存+模型分层”这两条，月度模型调用成本直接降到原来的四成左右，效果一点没打折。8. 实操复盘：一个普通后端程序员的第一周8.1 需求与第一版为了让你更直观地看到整个路径，我用一个模拟场景完整复盘一遍。假设某团队需要一个“内部规章制度问答助手”，需求很简单：员工提问，助手基于制度手册回答，要附上制度出处。某后端同事A基础不错，但没做过大模型。他第一版方案是：把一份50页的Word制度手册全文复制进提示词，然后让模型回答。结果显而易见：提示词超长，接口直接报错，就算勉强能跑，Token开销也大，回答还前后矛盾。这就是典型的“还没学会走就跑”。8.2 逐步迭代的路径后来他按上面讲的六步重做了一遍：第一步，写清楚角色、任务、约束和输出格式的提示词，固定企业内部语气。第二步，把Word转成Markdown，按章节切块，每块控制在800字内，切好大概90块，调用embedding接口转成向量，存进轻量级嵌入式向量库。第三步，用户提问时，先召回Top-5文档块，拼进提示词里让模型基于资料回答。第四步，为了让回答“附出处”，他在提示词模板里明确要求“回答末尾列出参考资料的章节名”。第五步，收集了40条高频测试问题，搭了一个最小评估集，每次改动都跑一遍，用大模型打分。第六步，上线后加了个简单缓存，把前几天的高频问题命中率从零提到了将近一半。整个过程大概用了两周，其中一半时间花在数据清洗和切分规则调试上。最终的体验已经是：问“年假怎么算”，能两三秒内给出准确答案，并告诉你这在第几章第几条。8.3 最终技术栈回顾这个项目的技术栈非常朴素，没有用任何重型框架，我整理如下：模块选择说明后端语言Python生态成熟，AI相关库最多模型服务某云厂商标准接口兼容通用调用规范，后续可替换向量化embedding接口跟模型同厂商，省去拼接麻烦向量存储轻量级嵌入式向量库小数据量优先，不做运维负担前端简单聊天页面先跑通业务流程，UI后期补调度Function Calling用于后续接工单系统查状态可以看出，一个能落地的项目不需要你掌握什么“大杀器”。关键是每一步稳扎稳打，把基础能力的边界摸清楚。9. 转型路上的高发问题与避坑速查我把自己实操中遇到过的高频问题整理成了速查表，每个坑都配了解决办法，你遇到能少走很多弯路。现象根本原因解决思路回答总是泛泛而谈，不落地提示词缺少约束和示例补上角色、边界、输出格式、Few-shot示例同一个问题，每次答案都不一样temperature过高或上下文不稳定降低temperature，固定system指令，考虑用seed参数语言模型无法回答私域知识知识不在模型训练范围引入RAG，先检索再生成文档切了但检索不到答案切分策略不合理，语义被破坏按段落/标题切分，保留表格完整，调整重叠区召回内容相关但答案还是错的召回结果没有正确引导模型在提示词中明确“只依据材料回答”，必要时加重排工具调用返回错误或空值schema参数定义不清晰精简描述，给参数示例，增加解析校验模型调用越来越慢、费用越涨越高历史消息无限累积消息截断、历史摘要、相似问题缓存调完提示词，改好的效果变差了缺少评估集回归建好评估集，每次改动批量验证请求偶尔报超时、限流服务端不稳定加超时重试、退避策略、请求限流这些坑，我几乎每一个都踩过。比起“大模型很神奇”这种感受，解决这些工程问题才是你日常要面对的。最后说几句实在话看了那么多步骤，你可能会觉得内容量很大，有点焦虑。我特别想强调一点：你不必一次全学会。普通程序员转型大模型应用开发，最省力的顺序就是：先跑通一个API调用，再做一个小知识库问答，再试着加一个工具调用。你会发现每一步都在之前工程经验上自然生长。我个人这几年做下来最深的感受是：这个领域最值钱的不是所谓“模型魔法”，而是把模型能力稳定地嵌进业务流程的工程能力。你能让它在生产环境里稳定运行、可评估、可追溯、成本可控，这就已经超过大多数停留在“写个Demo玩一玩”阶段的人。如果你正在转型路上，可以先拿自己手头最熟悉的一个业务场景练手——库存查询、报表解读、内部规章制度问答，都行。把一个场景吃透，比跟风追新词有用得多。等到那个系统真正有人用起来，你会发现自己已经不再是“普通程序员”了。