搞大模型应用开发这件事，我最近被身边好几个朋友问过同一个问题：零基础不懂机器学习算法，到底能不能做？我的答案很直接——能。所谓大模型应用开发，核心是调用已经训练好的模型能力，而不是自己从头训练一个模型。你要做的是把模型的文本生成、理解、推理等能力接入你的业务场景，配上有用的数据和流程，最终变成一个真正解决用户问题的应用。这篇指南会从认知、环境、提示词、RAG、微调、上线评估到踩坑排查，完整讲清楚。
1. 大模型应用开发到底在做什么：先建立整体认知
1.1 应用开发的本质是“调用能力”，不是“训练模型”
很多刚开始接触这个领域的人，一上来就觉得自己得把机器学习、深度学习和损失函数全都啃一遍。其实应用开发跟模型训练是两个流派。你不需要知道Transformer里的注意力权重怎么更新，但你得知道给定一段输入，模型会返回一段输出；你不需要会写训练框架，但得会设计输入输出和异常处理。换句话说，大模型应用开发更接近传统后端开发，只是把“业务逻辑”的一部分外包给了模型。
那么“外包”到什么程度？现在的通用模型能完成摘要、翻译、分类、信息抽取、代码生成、角色扮演等大量任务。你可以把模型当作一个懂得很多但偶尔会犯错的“实习生”：你要给它清晰的指令，提供必要的材料，检查它的产出，在它跑偏的时候纠正它。应用开发者的核心能力，就是做好这个“写指令、给材料、查结果、做纠偏”的闭环。谁把这套闭环做得扎实，谁的产品体验就好。
这也是我不建议新手一上来就折腾本地部署的原因。先从模型API开始，把调用逻辑跑通，理解请求和响应里的每个字段，再逐步考虑私有化部署、微调这些进阶问题。我见过有朋友一上来就折腾本地部署，环境装了两天还没跑出第一句话，最后直接把项目搁浅了。反过来，先调API，当天就能看到模型回复，这个正反馈非常重要。等你对模型的输入输出有了手感，再回头考虑私有化部署，心态会完全不同。先走通“模型即服务”这条路，你对整个应用开发的感知会快很多。
1.2 常见的大模型应用形态：从聊天机器人到智能体
从产品层面看，围绕大模型最常见的应用形态有几种：第一种是对话助手，比如客服机器人、个人助理，直接以聊天窗口为交互界面。第二种是知识库问答，让模型基于你提供的文档、网页或数据库内容来回答问题，这背后通常会用到检索增强生成（RAG）。第三种是流程自动化，模型从文本或表格里提取结构化信息，再触发下游任务，比如自动分类工单、生成周报、整理邮件。还有一种是智能体，模型自主地决策调用哪些工具，完成多步骤操作。
这些形态并不是完全分开的，很多真实项目会混合使用。比如一个客服系统，先做知识库检索，找不到正确答案再让模型转人工；一个办公助手，既要做语义理解，也要调用日历接口、邮件接口来执行操作。作为新手，我建议你先选一个最贴近工作场景的小需求下手，比如做一个“文档问答机器人”或“周报生成助手”。这种项目不大，但能训练你走完“提示词设计→接口调用→解析结果→异常处理”的完整链路。
1.3 入门需要哪些基础：其实比想象中少
如果你问我要学什么，我的清单大概是：熟练使用Python处理字符串和JSON，会写基本的HTTP请求，明白什么是环境变量和命令行，再看一遍高中英语。没错，就这些。深度学习理论你暂时可以放到一边，数学公式也可以先不碰。模型API返回的数据基本都是JSON结构，你更多时间花在数据清洗、格式约定、字段映射这些常规编程任务上。
不过有两样东西我建议你多花点时间：一是“结构化思维”，把模糊的需求拆成明确的输入、输出和约束条件；二是“测试意识”，因为模型的输出有随机性，你不能只测一次就上线，得积累一批用例反复验证。这两项能力不是靠背理论得来的，而是在亲手做过几个小程序之后自然提升的。所以别等“学完再动手”，直接动手比什么都强。
2. 从零搭开发环境：选对模型、配好工具链
2.1 最快的起步方式：申请模型API并跑通第一个请求
大模型应用开发最省力的起步方式是使用模型服务商提供的API。你需要去某个模型开放平台注册账号，创建API密钥，然后在本地用Python发起请求。虽说各家平台接口细节不一样，但现在的接口设计基本都在向同一个规范靠拢：用POST请求，传一个包含模型名称、消息列表和参数的JSON体，然后得到包含回复内容的JSON响应。我建议你优先选择接口兼容性好的平台，方便以后切换模型或使用代理服务。
下面这段代码是最小调用示例，几乎每个大模型项目都会用到。重点是理解请求结构：messages是对话消息数组，每条消息有role和content两个字段。role可以是system、user、assistant。先用system设定角色和规则，再传user消息，是提示词工程的基础姿势。
import os import requests api_key = os.environ["LLM_API_KEY"] api_base = os.environ["LLM_API_BASE"] # 例如 https://api.example.com/v1 model = "your-model-name" payload = { "model": model, "messages": [ {"role": "system", "content": "你是一位资深技术写作助手，回答需简洁专业。"}, {"role": "user", "content": "用三句话解释一下什么是大模型应用开发。"}, ], "temperature": 0.3, "max_tokens": 500, } 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() print(data["choices"][0]["message"]["content"])第一次跑通这个请求后，我希望你多做的几件事是：打印完整响应体，观察除了content外还有哪些字段；故意把temperature调高和调低，比较输出的变化；把system内容换成不同的角色，看模型回答风格如何改变。这样一圈下来，你对模型API的“脾气”就有数了。这些字段和参数在后期的每一个项目里都会反复出现，越早熟悉越好。
2.2 私有化部署：什么时候才需要自己跑模型
调API用久了，你可能会遇到三个痛点：数据不能出内网、单次调用的量级太大成本扛不住、需要离线运行。这时候就要考虑私有化部署。最简单的方式是下载一个开源模型，用推理框架在本地或自己的服务器上跑起来。好处是数据可控、没有按次计费，坏处是你得有GPU资源，还得自己处理部署、并发和模型更新。
对于新手，我建议不要一开始就陷入部署细节，先明确你的需求到底是“合规要求”还是“成本优化”。如果是合规要求，可以先用开源模型跑通一个原型；如果只是觉得API贵，先算清账单再决定是否迁移。部署环境里，显卡显存决定你能跑多大的模型：通常7B到14B参数量的量化模型需要8GB到24GB显存，更大的模型动辄需要多卡。你还需要把模型放进一个带并发控制的推理服务里，不能图省事直接裸跑脚本，否则线上一压测就出问题。
2.3 模型选型：除了效果还要看哪几个维度
模型选型是决定开发体验的关键动作。很多人的第一反应是“哪个模型效果最强选哪个”，但在实际项目里，效果只是众多因素之一。我常用的选型清单包括：任务效果、推理速度、成本、上下文窗口长度、数据合规性、生态兼容度。你可以把它做成一张评分表，对每个候选模型打分。
| 维度 | 说明 | 建议权重 |
|---|---|---|
| 任务效果 | 在你自己的测试集上的准确率/可用率 | 高 |
| 推理速度 | 首字延迟、每秒生成token数 | 中高 |
| 成本 | 每千token单价、对账单增长的影响 | 中高 |
| 上下文长度 | 能一次性处理多长的文档或对话 | 中 |
| 数据安全 | 是否支持私有化、数据是否用于训练 | 高 |
| 生态兼容 | SDK、工具链、社区资料是否丰富 | 中 |
我的经验是，先用自己手里的20到50条真实业务问题做“同题对比”，而不是只看榜单分数。榜单测的是通用能力，你的项目要的是特定场景下的表现。比如做一个面向客服的问答，拿一批真实用户问句去测候选模型，统计模型给出可用回答的比例，这个数字比任何排名都更有参考价值。同一类模型在不同语言、不同领域上的表现差异很大，别盲目追新。
3. 提示词工程：把模型能力调教到位的关键
3.1 为什么提示词质量直接决定应用效果
模型的能力上限很像一个“潜力范围”，提示词决定了它能发挥出多少。同一个模型，你用“帮我写个方案”能收到一段泛泛而谈的文字，但用一段交代了背景、受众、篇幅、结构、约束条件的提示词，输出质量会明显上一个档次。这不是玄学，而是因为模型本质上是在做下一个词的预测，它需要从你的指令里推断出你真正想要的答案。指令越明确、示例越具体，它猜测的范围就越小。
做应用开发时，提示词不只是“写得好不好看”的问题，而是产品功能的一部分。你需要把用户输入、业务规则、输出格式全部塞进一段可复用的提示词模板里。如果提示词经常不稳定，你的产品就会时好时坏，用户很难产生信任。所以我会把提示词当作代码一样对待：写版本、做测试、持续迭代，而不是随手改。
3.2 一个可复用的提示词模板：角色、任务、约束、示例
我给你一个我项目里经常用到的基础模板。它分为四块，系统提示词里放角色和全局规则，用户消息里放具体任务和上下文。第一块是指定角色，比如“你是某电商平台的售后客服助手”；第二块是明确任务目标，你要说明输入是什么、输出是什么；第三块是写清楚约束条件，比如“只能基于给定资料回答，不知道就说不清楚”；第四块是给一两个输入输出的示例，也就是Few-shot，让模型照着你的格式走。
下面是一个文档问答机器人的提示词模板示例：
system_prompt = """ 你是公司内部知识库问答助手。 请严格依据下面的【参考资料】回答问题。 如果参考资料中找不到答案，请回答：资料中暂无相关信息，请转人工处理。 回答控制在200字以内，使用中文，用编号列表输出结论和依据。 """ user_prompt = f""" 【参考资料】 {retrieved_documents} 【用户问题】 {user_question} 请按要求回答。 """你也可以把示例直接放到提示词里，比如“示例1：问题：... 回答：...”，模型会模仿示例的格式和口吻。示例的选择比数量更重要，两三个有代表性的正反例就足够。很多新人容易忽略“禁止做什么”，比如要明确告诉它“不要编造来源”“不要重复问题”，这些负面约束在长上下文场景下尤其重要。
3.3 调优提示词的具体操作技巧与温度参数
提示词调优不是拍脑袋，我常用的顺序是先做“任务拆解”：把你希望模型完成的任务拆成几段自然语言指令，然后逐一检查每段是否足够明确。比如“提取客户邮件里的诉求并分类”就不够明确，你还要定义类别清单、输出格式、无法判断时怎么办。其次，把关键信息从用户的长文本里提前抽出来，放到提示词靠前的位置，因为模型对上下文中间部分的注意力有时会弱一些。
temperature参数也值得好好理解。这个参数控制的是采样随机性：值越低，输出越稳定，但可能缺少创意；值越高，输出越多样，但更容易跑偏。做分类、抽取、格式化这类任务，我一般把temperature设为0到0.3；做文案创作、头脑风暴，可以调到0.7到1.0。另外还有top_p等参数，很多平台都支持，不过对一般应用来说，调好temperature就够用了。进阶玩法是输出JSON时要设置响应的格式约束，不同平台的参数名不同，记得看文档。
4. 完整走通一个应用：从文档问答到检索增强生成
4.1 需求拆解：以“内部知识库问答机器人”为例
前面讲了一堆概念，现在拿一个最常见的需求走完整条链路。假设你现在要做一个“内部知识库问答机器人”，用户上传文档或者知识库里有几百篇产品说明、制度文件，机器人需要基于这些材料回答员工问题。这个需求听起来简单，但如果不做设计，直接用模型对话，模型就会用训练时见过的东西瞎编答案。真正能解决这个问题的架构叫RAG。
RAG的核心思路是：不直接把问题丢给模型，而是先从知识库里检索出与问题最相关的几个片段，再把片段和问题一起交给模型生成答案。这就像开卷考试时先翻书再答题，模型不再凭记忆硬编，而是看着材料作答，答案的可信度会高很多。整体流程可以拆成四步：文档解析、切片并向量化、检索、拼接提示词生成。每一步都有讲究。
4.2 文档切片与向量化：为什么要先把文档变成“可检索”的片段
知识库里的文档往往很长，不能整篇塞给模型。所以第一步是把文档拆成合适大小的切片，再为每个切片生成向量索引。切片大小没有固定标准，一般按几百个字或几个段落切。切得太小，上下文不完整，检索结果零散；切得太长，检索精度下降，还容易超token限制。我常用的经验是每个切片512到1024个字符左右，相邻切片保留一点重叠，防止关键信息被拦腰截断。
向量化就是把文本转换成一组数字向量，语义相近的文本向量距离也近。你需要准备一个文本嵌入模型，把切片逐条转换后存储到向量数据库里。查询时，把用户问题也转成向量，然后做相似度检索，找出top-k个最相关的切片。这里的k值一般取3到8，取决于你的切片大小和任务复杂程度。k太小可能漏答案，k太大会导致提示词过长，模型反而抓不住重点。
4.3 检索并构造上下文：让模型基于资料回答
检索到了相关切片后，下一步就是把它们拼成“参考资料”塞进提示词。这一步看起来简单，但我吃过不少亏：比如把检索到的几十个片段全部塞进去，结果模型被无关内容带偏；或者没有标注来源，回答里出现了资料外信息你也查不出来。所以我在拼接时会给每个切片加标题和序号，并让模型在回答中标注引用了哪个片段。这样既能提高准确率，又方便人工核对。
下面是一个简化版的检索问答循环。代码里省略了向量化和检索的具体实现，但流程是通用的：先检索，再拼装，再调模型。真实项目里，你还需要处理文档更新、删除旧索引、并行切片等问题，但核心不要变：模型永远只能看到检索后的有限材料，而不是整个知识库。
def answer_with_rag(question: str, retriever, llm_client) -> str: # 1. 检索最相关的k个文档切片 chunks = retriever.search(question, k=4) # 2. 拼装参考资料 context_parts = [] for idx, chunk in enumerate(chunks, 1): context_parts.append(f"[{idx}] {chunk.content}") context = "\n".join(context_parts) # 3. 构造提示词并调用模型 prompt = f"""请根据下面的资料回答问题。 资料： {context} 问题：{question} 如果没有相关信息，请直接说“资料中无相关信息”。""" return llm_client.chat(prompt)4.4 进阶：函数调用让模型能操作真实系统
当你的应用不满足于“说”，还要“做”的时候，就需要函数调用能力。函数调用允许你在请求里声明一组可用工具，模型会根据对话内容输出一个结构化的调用请求，代码收到后再真正执行这个工具，并把结果交回给模型。一个典型场景是：用户说“帮我查一下明天有没有会议室”，模型不直接回答，而是选择调用“查询会议室”函数，传入参数“日期=明天”，你的代码调用日程系统，再把结果交给模型生成自然语言回复。
实现函数调用的关键是函数定义要写清楚：函数名、参数类型、参数说明、必填项。模型根据这些描述做选择，所以描述写得越详细，选错函数的概率越低。新手最容易犯的错是让函数做太多事情，导致模型传参不准。我建议每个函数职责单一，比如一个查询函数只查会议室，另一个预定函数只做预定，不要搞一个“全能接口”。调用过程中还要校验参数格式，模型偶发会输出不存在的参数名，代码要做好容错。
5. RAG不够用时，再谈微调和智能体
5.1 先判断问题：什么时候才真的需要微调
RAG能解决很多“外部知识”问题，但有些场景它解决不了。比如你要让模型模仿特定的写作风格、输出固定的业务术语、执行严格的分类规则，或者模型经常在你的任务上效果很差。这时候可以考虑微调。但在动手之前，我强烈建议你回答一个问题：你遇到的是“知识缺乏”还是“行为不一致”？如果是知识缺乏，补充RAG就够了；如果模型行为不符合预期，微调才可能有效。
微调也不是万能药。它成本高、周期长、需要标注数据，而且微调后模型可能在通用能力上有所下降。很多团队做微调前没做量化评估，微调后凭感觉觉得“变好了”，实际上换了测试集可能更差。我的建议是，微调前先固定一个评估集，记录原始模型的效果，微调后用同一套数据比较，确认提升再上线。如果不能明显提升，优先回头优化提示词或检索质量。
5.2 微调的基本流程与数据准备要点
微调的基本流程并不神秘：准备一批高质量的对话样本，把样本处理成模型训练需要的格式，然后调用微调接口或本地训练脚本，最后做效果验证。对话样本通常需要包含system、user、assistant三部分，assistant内容是标准答案。数据量没有硬性标准，有人几百条就能纠正格式问题，有人几万条才能稳定学到一个领域的表达。关键是数据质量，宁可少而精，不要多而杂。
准备数据时我踩过几个坑，给你提个醒：第一，标准答案不要有大量重复和模板化内容，否则模型会学会“念稿”；第二，负样本也要保留，让模型知道不该说什么；第三，样本里的user问题要足够多样，覆盖真实用户的各种说法，不要用一套书面语刷几千条。微调后的验证也很关键，要拿一批模型没见过的问题去测，看它是否把风格学歪了，是否在相关领域外也乱用新术语。
5.3 智能体应用：让模型自己规划步骤、调用工具
智能体是目前特别火的应用形态。它的核心不是单一问答，而是让模型像一个项目经理一样，把用户目标拆成若干子任务，逐个调用工具去完成，并根据执行结果调整计划。打个比方，你要处理一份合同摘要，模型可以先调用文件解析工具读取PDF，再调用信息抽取工具提取关键条款，最后调用摘要模型生成结论。它自己决定先做什么、后做什么。
做一个能稳定运行的智能体，你需要具备几个模块：任务规划器、工具注册表、执行器和记忆模块。工具注册表就是前面讲的函数调用；执行器负责真正运行工具并返回结果；记忆模块让智能体记住前几步说了什么。新手不要一上来就做大而全的自主智能体，先做“按固定流程执行”的伪智能体，把每一步都写死在代码里，等流程可靠了再逐步放权给模型。自主性越高，出错的可能性越大，越需要成熟的可观测机制。
6. 上线前必须做的评估与调试
6.1 评估大模型应用，不能只看“感觉不错”
我见过很多项目在演示阶段效果惊艳，一上线就翻车，原因就是没有建立系统化的评估。模型的每次输出都有概率性，同一个问题今天好用、明天可能跑偏，所以上线前一定要有“评估集”。评估集不需要太大，但覆盖面要广，至少包括正常问题、边界问题、恶意或无关问题、长文本问题。每一条都预先准备一个理想回答或评分标准，然后批量跑模型，统计达标率。
评估维度也要分开看。对问答系统，我常用四个指标：准确性，回答是否与标准答案一致；忠实度，回答是否严格基于给定资料而未编造；相关性，回答是否解决了用户问题而不是答非所问；格式合规性，输出是否符合预先约定的JSON或标记格式。另外还要监控成本和延迟。你可以做一张表格，把每条测试用例的评估结果填进去，不同模型版本放在不同列对比，这样每次迭代都看得见变化。
6.2 用自动化测试集和模型辅助评估搭建回归体系
有了评估集之后，最好把评估过程自动化。你可以写一个脚本，逐条把测试问题发给被测应用，拿到回答后调用一个评判模型给回答打分或做“对错”判定。这种方式能帮你快速迭代提示词和检索策略。不过要注意，拿模型评判模型也有偏差，比较稳妥的做法是让评判模型输出判断理由，再由人工抽样复核一批，确保评判标准没有漂移。
自动化回归测试不用等到上线前才做。我建议每修改一次提示词、每更换一次模型版本、每调整一次检索逻辑，都跑一遍回归测试，把通过率的变化记录下来。这跟传统软件测试的道理相通，只是判断标准从断言变成了“语义是否符合预期”。一套好的回归测试，能让你敢于频繁调优，而不是每次改完都提心吊胆。
6.3 日志、监控与反馈闭环是上线的最后一块拼图
很多新手把应用开发的重心都放在“让模型输出更好”上，却忽略日志和监控。大模型应用一旦上线，问题往往是异步发生的：用户反馈某类问题回答得很差，但你不知道是提示词问题、检索问题还是模型问题。没有日志，排查就只能靠瞎猜。所以我强调，每一个请求都要记录：输入的原始问题、最终提示词、检索到的片段、模型原始输出、清理后的输出、耗时、token用量和错误信息。
拿到了日志，还要设计反馈闭环。在应用里埋一个“赞同/反对”按钮，或者让用户提交“未解决问题”，把负反馈自动回流到一个待分析队列。每周抽出时间看一批负反馈，把它们补充进回归测试集，再继续优化。我自己的习惯是每个迭代周期都跑一次全量回归，把“新增问题案例”作为最重要的优化依据。时间一长，应用质量会以肉眼可见的速度提升。
7. 常见问题与踩坑排查：从超时到输出格式不稳定
7.1 请求超时、连接失败和限流怎么处理
做模型API调用时，最常见的报错就是超时和限流。网络波动、模型负载高、请求体过大都可能让你等很久。处理方式不是只会设置一个timeout参数就完事，而是要区分情况。如果是偶发超时，可以做一个带指数退避的重试：第一次失败后等1秒再试，再失败等2秒、4秒，最后放弃。如果是模型服务端限流，报错信息里一般会标明，你要降低并发，或者把请求排队。
另外，流式输出能显著改善体验感，也能防止长时间无响应。流式输出就是让答案逐字返回，用户看到文字在“打字”，心理等待时间短很多。代码上只需要设置stream参数为true，再按行解析返回的数据。但要注意，流式返回的内容可能拆成多行，你要自己把片段拼成完整答案。并发控制同样重要，不要因为延迟高就无限开线程，否则很容易触发限流，甚至影响数据源稳定性。
7.2 回答突然截断或token超出限制怎么办
模型输出长度受限，长文档或长对话经常触发token上限。遇到截断，先检查提示词长度和max_tokens设置。如果提示词已经很长，需要考虑压缩：去掉重复示例、精简系统提示词、用更短的小标题替代完整句子。如果回答本身需要很长，可以分段生成，比如让模型先生成大纲，再分段展开。还有一种情况是上下文窗口满了，你可能要启用“历史摘要”或“滑动窗口”，把早期对话压缩成一小段摘要继续往下聊。
token数量并不是按字数算的，一个汉字可能占一到两个token甚至更多，数字和英文也可能拆成多个token。你可以在调用前用分词器工具统计提示词和回答的token数，做到心中有数。我见过不少项目因为没限制max_tokens，一次回答生成了几千字，不仅慢还贵。给输出设置一个业务上合理的上限，既能控成本，也能减少跑题。
7.3 模型输出格式飘忽不定，如何拿到干净的JSON
业务系统经常需要模型返回JSON，但模型偶尔会在JSON前面加解释、文字后面多补一句，导致解析失败。解决办法有三个层次：第一，在提示词里明确“只输出JSON，不要任何解释”；第二，利用平台自带的JSON模式或响应格式约束，让模型从结构上保证输出合法；第三，在代码里做后处理，比如用正则截取大括号内的内容，或者把解析失败时的报错信息重新丢给模型修正。三层一起用，成功率能接近100%。
不过你也要意识到，对于复杂嵌套JSON，模型偶尔会漏字段或给错类型。我一般会在系统提示词里给一个JSON Schema示例，然后要求字段严格按示例来。收到结果后，做一层字段校验，发现缺字段就补一次修正请求。最好把“修正请求”也做成函数，统一处理，不要散落在各个地方。
7.4 成本飙高、数据隐私和内容安全的合规经验
大模型应用上线后，很多人会被账单吓一跳。控制成本的方法包括：对简单任务用小模型，对复杂任务用大模型；在系统提示词里告诉模型“回答不超过多少字”；给输出设置max_tokens；对重复度高的请求做缓存，相同的用户问题可以直接返回上一轮答案。还有一类成本来自检索，不要把知识库所有切片都塞给模型，只塞检索后最相关的几段，成本会成倍下降。
数据隐私和内容安全是另一个不能省的部分。凡是涉及用户个人信息和内部敏感数据的请求，都要在架构层面做隔离，优先选择私有化部署或合规模型服务。输出侧也要做内容过滤，加一道关键词和分类模型校验，防止模型生成风险内容。这部分功夫看起来不产生“效果”，但上线后一旦出问题，代价远比你前期投入大得多。合规红线从第一天就要设计进去，不要等出事再补。
8. 经验沉淀：给入门者的一些实在建议
最后分享几条我自己的感受。第一条，先从“调用API+提示词”起步，不要一上来就搞微调和本地部署。我用最朴素的API做过的第一个值班总结脚本，虽然只有几十行代码，但它让我理解了模型调用的完整流程，比看一百篇教程都有用。第二条，把提示词当代码来管理，每个版本都留档并跑回归测试。我见过太多人上线前一天还在手工调提示词，结果改坏之后不知回滚到哪个版本。第三条，评估集是你的定心丸，提前准备五六十个真实问题，每次调整后都跑一遍，通过率涨了就继续，跌了就回滚。
还有一个容易被忽视的点：多跟真实的用户问题打交道，而不是只在理想测试环境里打磨。找几个人试用你的应用，把他们的吐槽和反问问出来，往往比你自己想的测试用例更有价值。大模型应用开发的技术栈还在快速变化，但“明确问题、小步迭代、用评估说话”这套方法论，在哪个阶段都成立。你踩过的每一个坑，都会变成下一次少走弯路的经验。
