这两年我接触了不少从其他技术栈转过来做AI应用开发的朋友，大家最普遍的一个困惑是：资料看了几百篇，教程也跟了不少，可真到自己动手做一个带点智能的应用时，却不知道从哪儿下手。LLM、RAG、Agent、记忆系统、向量数据库，这些词每个单独拿出来都有人讲，但它们在真实项目里到底怎么分工、怎么衔接，很少能有一篇文章讲透。这篇文章我想把AI开发这条路上的7个核心领域摊开揉碎说一遍——从大模型的基础认知与Prompt编写，到RAG检索增强生成，再到Agent智能体的规划与工具调用、记忆系统的设计实现，最后落到开发框架选型和一条适合小白的实战路线。目标只有一个：让你读完脑子里能有一张完整的地图，知道每个环节解决什么问题、什么时候该上什么技术，而不是看到一个教程就盲目抄一个。
1. 先看懂AI开发的能力地图：7大核心领域各自解决什么问题
很多人对AI开发的认知是"调一下大模型的接口，传个prompt，拿到结果就完事了"。这种思路在做一个Demo时确实成立，可一旦要做成一个真正的产品，你会发现事情远没有这么简单。举个最直观的例子：你让大模型回答"我们公司最新的报销流程是什么"，它大概率会一脸茫然甚至编造一套流程。因为它的知识停留在训练数据截止那天，而且从不认识你公司。
1.1 一个比喻：大模型像个"会聊天但不会干活"的新员工
我特别喜欢用这个比喻来解释AI应用的技术栈：大模型本质上是一个知识面很广、但有点健忘、也不太会用工具的新员工。他读过很多很多书，聊起天来头头是道；但你没告诉他的内部信息，他真的不知道，却又不好意思说"不知道"，于是就开始顺着你的话编。你让他帮忙订个会议室、统计一份数据，他嘴上答应，但手里没工具、也不知道该按什么步骤执行。更麻烦的是，他每次见到你都像第一次见面，完全不记得你上周提过什么需求。
后面这四层技术，本质上就是在给这位"新员工"补能力：
- RAG是给他外挂一个公司知识库，让他遇到不确定的问题先查资料再回答，而不是瞎编。
- Agent是给他配上双手和工具，让他能调用各种接口去执行具体任务，而不是只动嘴。
- 记忆系统是治他的"健忘症"，让他在多次对话里记住你是谁、你关心什么、任务进展到哪一步。
- Prompt工程则是给他一本"工作手册"，把说话和干活的规矩写得清清楚楚。
1.2 七块拼图与它们之间的关系
基于这个比喻，我把完整的AI应用开发拆成7个局部，这也是本文不断提到的"7大核心领域"。它们不是并列的技术名词，而是一个有依赖关系的分层结构：
| 核心领域 | 解决的痛点 | 你能得到的产出 |
|---|---|---|
| 1. LLM基础与API调用 | 不了解模型能力边界，调用都不会 | 第一个跑通的对话程序 |
| 2. Prompt工程 | 输出不稳定、格式不可控 | 一套可复用的提示词模板 |
| 3. RAG检索增强生成 | 知识截止、私有知识缺失、幻觉严重 | 能基于文档库回答问题的系统 |
| 4. Agent智能体 | 模型只会聊天不会干活 | 能自主调用工具完成任务的应用 |
| 5. 记忆系统 | 模型没有跨会话记忆、上下文受限 | 记得用户与业务状态的智能应用 |
| 6. 开发框架与工具链 | 集成多组件时效率低、重复造轮子 | 一套稳妥的工程脚手架 |
| 7. 部署与评估 | 上线后效果不可控、问题不直观 | 可监控、可度量、可迭代的线上服务 |
1.3 为什么按这个顺序学习最省力
很多初学者的误区是一上来就追Agent，甚至直接啃某个开源大项目的源码，结果被各种抽象概念砸晕。我的建议是按依赖顺序来：先把1和2做扎实，理解你正在跟一个什么样的模型打交道；再叠加3和4，让应用从"能说"变成"会做"；然后补上5和7这两个工程化能力，让应用真正"可商用"。第6点其实是贯穿全程的，我会在教程后面单独展开，因为框架选错了，前期有多爽后期就有多痛。
2. 第一层地基：LLM基础认知与Prompt工程的"配方"打法
2.1 理解大模型的三个弱点，你才知道后面技术为什么存在
动手写代码之前，我强烈建议你先花一天时间搞清楚大模型的工作原理。它不是一个数据库，也不是搜索引擎，它的本质是一个"给定前文、预测下一个词"的概率模型。这个底层机制决定了它有三个天然弱点：
第一，知识有截止日期。模型只记得训练数据里出现过的东西，训练完之后的世界它一无所知。你以为它在给你讲今天的新闻，其实它在根据历史规律"合理推测"，这跟编造只有一线之隔。
第二，幻觉是原生的。因为它本质是概率生成，遇到不知道的事情，它不会诚实地说"不知道"，而是会生成一段听起来非常自信、逻辑自洽的内容。越是不懂，越敢说。
第三，上下文窗口有限。模型能"记住"的上下文长度是有限制的，几千到几万token不等。你不可能把一本书都塞进一次请求里，更不可能让它记住上个星期的对话。
理解这三点之后，你会瞬间明白后续章节里的每个技术选择：为什么要做RAG？因为要补知识、治幻觉。为什么要做记忆系统？因为上下文窗口装不下所有历史。为什么要做Agent循环？因为一次调用只能做一件事，复杂任务需要多次规划执行。
2.2 Prompt不是"说话"，是配方：角色、任务、约束、示例缺一不可
很多人把Prompt理解成"跟模型好好说话"，这是最大的误区。Prompt的核心是配方——它是一份结构化的控制指令，而不是一段聊天文本。我在实战中总结了一个四段式配方：
【角色】你是一位具备X领域经验的专业人士。 【背景】用户正在做某件事，当前遇到了某类问题。 【任务】针对以下输入，完成某个具体产出。 【约束】 - 输出必须包含哪些字段 - 不允许出现什么内容 - 如果信息不足，应该怎么处理举个例子，我要让模型帮忙做代码审查：
你是一位资深的前端开发者，擅长分析React应用中的状态管理问题。 背景：用户的项目在不该重新渲染的地方出现了频繁重渲染，导致页面卡顿。 任务：分析下面的组件代码，找出可能导致重渲染的写法，并给出修改建议。 约束： 1. 先给出结论，再给修改后的代码，最后用100字以内解释原因。 2. 只关注性能问题，不要修改业务逻辑。 3. 如果代码中没有明显问题，明确说明"未发现明显问题"，不要为了找问题而找问题。 组件代码： 【待粘贴的代码】这个Prompt为什么有效？因为它把"模型知道的"和"我需要的"之间的边界画清楚。特别是第三条约定了"查不出问题就说查不出"，直接压制了幻觉的源头。
2.3 Prompt调优里的4个坑，我每个都踩过
坑一：指令堆叠导致模型"选择困难"。我早期写Prompt喜欢把几十条要求全塞进去，结果模型反而忽略关键约束，输出一些四不像。后来我把约束精简到5条以内，并且把最重要的约束放到靠前的位置，效果立刻提升。大模型对长Prompt里的细节本身就是"选择性注意"。
坑二：只写"输出JSON"，但不给结构。解析永远是Prompt工程里最疼的问题。你告诉模型"输出JSON"，它可能给你一个带注释的JSON、一个markdown包裹的JSON，甚至一个漏了括号的JSON。后来我学会了在Prompt里直接给出JSON Schema或示例模板，让模型照着填值，解析成功率从60%直接跳到95%以上。
坑三：temperature设置永远用默认值。如果你的场景是数据抽取、格式转换，temperature设为0.2以下会大幅降低随机性；如果是头脑风暴类的创意生成，调高到0.8以上才有惊喜。不少初学者不知道这个旋钮是干嘛的，白白被随机性折磨。
坑四：没有输出校验环节。这里是工程思维和Demo思维的分水岭。线上应用必须在拿到模型输出之后加一层校验，字段缺失就重新生成或走降级逻辑，而不是拿着脏数据继续往下走。我记得有次线上问答应用把模型的幻觉输出直接存进了业务数据库，排查了好几天才发现是输出校验缺失。
3. RAG检索增强生成：让模型学会"先查资料再回答"
3.1 RAG要解决的核心问题与整体链路
RAG这个名字听起来高大上，拆开就是Retrieval-Augmented Generation，检索增强生成。它做的事情用大白话讲：在模型回答之前，先从你自己的知识库里检索出相关的资料片段，再把这些资料连同问题一起交给模型，让它依据资料作答。
这个技术之所以成为AI应用开发的标配，是因为它同时解决了三个问题：知识截止日期、私有领域知识缺失、以及幻觉。模型不用再猜测答案，它会像开卷考试一样，先把参考资料摆在眼前，照着抄。
RAG的整体链路是一个完整的数据管线，跑通它你才算真正入了门：
文档加载 → 文本切分（chunking） → 向量化（embedding） → 存入向量库 → 用户提问时向量化问题 → 召回（retrieval） → 重排（rerank，可选） → 拼接Prompt交给LLM生成答案
这八个环节里，任何一个出了问题，最终回答质量都会打折扣。而大多数人的RAG效果不好，原因往往不在模型，而在前面的"数据"环节。
3.2 文档切分与向量化：决定RAG效果的地基环节
切分方式直接影响召回质量。我见过太多人直接把整本PDF丢进去切，每500个token硬切一刀，结果一句话被拦腰截断，丢失语义。更合理的做法是按文档结构切：先按标题分块，每个标题下的内容作为一个语义完整的段落；段落太长再按固定长度切，并设置overlap（重叠区域）。overlap的作用是让相邻块之间保留上下文衔接，避免一句话因为换块而"失忆"。
关于chunk_size，我给你一组经验值：通用业务文档选300到600个token，技术文档可以适当扩大；如果文档里都是短段落，200个token就够。不要迷信某个固定数值，用你的真实数据跑一遍，看看召回结果的命中情况再调。
向量化模型的选择也很关键。不同embedding模型对中文的支持差异很大，有的在中英混合场景表现非常差。建议用至少两个模型在你的业务数据上做一个召回对比，不要只看网上谁火就选谁。向量模型输出的维度也影响存储成本，768维和1536维的存储开销差一倍，小项目够用就行，别盲目上大模型。
3.3 召回到生成之间的调优经验：参数、重排与问题排查
链路跑通之后，就到了最磨人的调优阶段。我最常调的几个参数列成表格给你参考：
| 参数 | 作用 | 我的经验值 |
|---|---|---|
| chunk_size | 检索单元大小 | 200-600 token |
| chunk_overlap | 块间上下文重叠 | 10%-20% |
| top_k | 召回数量 | 3-8 条 |
| temperature | 生成随机性 | 0.1-0.3 |
| 重排开关 | 是否对召回结果精排 | 数据量大时必须开 |
一个值得单独提醒的参数是top_k。有些人以为召回越多越好，一下子把top_k调到20，结果Prompt被大量无关片段塞满，模型反而抓不住重点，回答质量直线下降。我先用top_k=5做基线，再逐步增减，找到效果拐点。
如果RAG效果不理想，问题排查要按照"数据 → 召回 → 生成"的顺序拆解，而不是一上来就怀疑模型：
- 看召回结果里有没有包含问题的关键段落。如果没有，那是切分或向量化的问题，去检查chunk大小、embedding模型和文档本身的格式。
- 如果召回了，但生成答案没用上，那是Prompt组装的问题。很多框架默认的RAG模板要自己改，你得明确要求模型"只能依据提供的资料回答，资料中没有的内容不要编造"。
- 如果上下文里有干扰信息，那就考虑加重排，或者动态调整召回阈值。
记住一个排查原则：召回决定上限，生成决定下限。召回阶段就漏了，后面再怎么调Prompt都是徒劳。
4. Agent智能体：从"回答问题"到"主动完成任务"
4.1 Agent的本质：模型从对话者变成执行者
如果说RAG是让模型"会查资料"，那么Agent就是让模型"会干活"。两者的思维模式完全不同：在普通的对话场景里，模型是一个回答者，你说一句它答一句；在Agent场景里，模型变成了一个决策者和执行者，你给它一个目标，它自己拆解步骤、选择工具、执行动作、观察结果，并在必要时调整计划，直到完成任务或到达最大步数。
Agent的核心组件就三个：大模型作为大脑、工具集作为手脚、循环控制作为躯干。模型负责"下一步该做什么"，工具负责"把事儿做出来"，循环负责"检查结果并决定是否继续"。
理解了这个结构，你就知道为什么Agent的代码量其实不大，难的是设计好它的思考边界和工具边界。工具不是越多越好，你用到的场景大概就那几类：查数据库的、调外部API的、算数据的、发消息的、控制浏览器的。每个工具都要有清晰的描述，因为模型是靠描述来决定"什么时候该调它"的。
4.2 用ReAct循环实现一个最小Agent
ReAct是目前最简单的Agent范式，思路是让模型在每一步输出"我想了什么（Thought）→ 我决定调用什么工具（Action）→ 我期待得到什么结果（Action Input）"，然后由程序去执行这个工具，把观察结果（Observation）还给模型，如此循环，直到模型输出"Finish"。
这里给你一个最小可运行的伪代码结构：
def run_agent(goal, tools, max_steps=10): messages = [{"role": "system", "content": "你是任务规划与执行助手，只能使用给定的工具完成任务。每次按格式输出Thought/Action/Action Input。"}] for step in range(max_steps): response = llm.chat(messages) messages.append({"role": "assistant", "content": response}) action = parse_action(response) # 解析Action字段 if action.type == "finish": return action.answer if action.type not in tools: messages.append({"role": "system", "content": f"工具{action.type}不存在，请重新选择"}) continue tool_result = tools[action.type](action.args) messages.append({"role": "tool", "content": tool_result}) return "任务未在最大步数内完成"跑通这个最小Agent的关键在于行动输出格式必须极其严格。模型很擅长在Action里自由发挥，用了各种不同的格式，导致parse_action直接摔跟头。我的做法是在系统Prompt里给出一个"标准输出模板"，并且每一轮都把上一个工具的结果原样放回上下文，让模型的下一步决策有据可依。同时务必加上max_steps限制，不然模型会在某些任务里无限循环，白白消耗你的API预算。
4.3 Agent失控的4个常见原因与工程防护
Agent开发者的主要工作不是写代码，而是"防止模型胡来"。我在项目里踩过的坑归纳下来就四种：
一是死循环。模型反复调用同一个工具，得到相同结果，然后再调用一次。防护办法是设置最大步数，以及对重复动作做去重检测，发现连续N次相同的调用就强制终止。
二是动作格式漂移。前面几轮还规规矩矩按格式输出，几轮之后就开始加注释、换措辞、甚至用markdown包裹动作。我的经验是不要在上下文里放太多无关历史，每轮执行完把"刚刚这一步的结果"摘要放进去，减少模型的发散空间。
三是工具权限失控。给Agent的工具越多，安全隐患越大。有一次我给Agent接了一个"执行任意代码"的工具，它直接循环执行了几十次耗时的计算。现在我对每个工具都做白名单和参数校验，能读不能写的绝不放开写权限，能用只读查询的绝不给执行权限。最小权限原则在Agent场景里尤其重要。
四是目标理解偏差。用户说的目标跟模型理解的目标经常不是一回事。比如"帮我整理这份数据"，模型可能直接开始删数据而不是统计汇总。防护办法是在任务启动前加一个"目标确认"环节，让模型先复述一遍它对任务的理解，用户确认后再真正开跑。
5. 记忆系统：让AI应用从"失忆"到"记事儿"
5.1 为什么需要单独的"记忆系统"设计
你做过那种用户每次打开都得重新介绍自己的应用吗？我做过，效果非常糟糕。大模型的上下文窗口天然有限，它天生是"健忘"的，要想让应用有连续对话能力、个性化体验，必须专门设计一套记忆机制。
记忆系统要解决的问题有三类：第一类是会话内的短期记忆，比如用户刚刚说了什么，这些内容要一直保留在上下文里；第二类是跨会话的长期记忆，比如用户一个月前说过的偏好、历史偏好、业务状态；第三类是任务状态，比如一个多步骤流程走到哪一步了，中间产出的临时数据放在哪。
没有记忆系统的AI应用，就像一个每次见面都假装不认识你的客服，用户用两次就烦了。有了记忆系统，应用才可能从"能用"升级到"好用"。
5.2 短期、长期、工作记忆的工程实现方案
短期记忆是最简单的：直接把对话历史作为消息数组传给模型。但要注意上下文窗口有限，不可能无限累积，所以通常的做法是只保留最近N轮对话，更早的内容做摘要压缩。你可以用模型把前面的对话生成一个"对话小结"，在下一轮放进system message里，这样既保留关键信息又省token。
长期记忆的通用方案是"向量数据库 + 结构化数据库"组合：把用户说过的重要事实、历史操作、偏好摘要存成两类数据——结构化的字段（比如用户ID、创建时间、偏好标签）放关系型数据库，叙事性的内容（比如"上次讨论过某项目的技术选型"）向量化之后放进向量数据库。等到新对话开始时，系统用当前问题去检索相关的历史记忆，把命中结果注入Prompt。
工作记忆管理的是当前任务的状态，最简单的实现是一个JSON文档或一张任务状态表，记录"任务ID、当前阶段、已完成步骤、下一步动作、已完成的结果"。Agent每执行一步，更新一次状态表；任务中断后重新拉起，可以从状态表恢复进度。
5.3 记忆的写入、召回与更新：一个轻量级设计
给你一个可以直接抄作业的轻量级记忆模块设计思路：
class MemoryService: def __init__(self, sqlite_path, vector_store): self.db = sqlite_path # 结构化信息 self.vectors = vector_store # 语义记忆 def save_interaction(self, user_id, query, response, important_facts): # 1. 把important_facts存入SQLite，作为带标签的结构化记忆 # 2. 把query+response写入向量库，作为可检索的语义记忆 # 3. 触发一次"记忆摘要更新"，合并旧的摘要与本次新内容 def recall(self, user_id, query, top_k=5): # 1. 先从SQLite取出用户标签/画像 # 2. 再从向量库召回语义相似的历史交互 # 3. 合并两组结果，按时间衰减权重，返回给上层这里有一个时间衰减权重的细节值得展开：长期记忆不能平等对待。三个月前的偏好可能早变了，但"用户当前项目使用的技术栈"这类短期事实反而更准确。我的做法是在召回时对记忆打一个时间衰减系数，近7天的记忆权重给1.0，30天前降到0.5，90天前降到0.2，再用这个权重参与排序。这样既保留长期画像，又不会被过期信息误导。
5.4 记忆场景里容易被忽视的3个问题
记忆系统做出来不难，做对很难。三个问题我建议你提前想清楚，不然后面早晚返工。
一是隐私合规。你存了用户多少历史对话，就必须承担起保护这些数据的责任。用户在设置里关闭记忆功能时，你真能把他所有记忆痕迹删干净吗？设计阶段就要把"删除逻辑"做进去，而不是事后补救。
二是记忆污染。模型提取"重要事实"的过程可能出错，它可能把用户随口说的一句话当成事实存下来，然后在下一次对话里用它作为推理依据，错误就被放大了。我的应对方案是：记忆写入前加一个置信度门槛，只有模型判断为"明确提出且对后续对话有影响"的内容才入长期记忆。
三是记忆检索失败不能影响主流程。如果召回记忆的服务超时或者返回空结果，应用应该"优雅降级"到普通对话模式，而不是直接抛错。做个简单的try-except，让用户感知不到技术故障，只把他当成第一次对话的正常人。
6. 开发框架、向量数据库与环境准备：少走弯路的关键选型
6.1 先写原生代码再上框架，理解永远比工具重要
聊到工具链之前，我想先说一个反常识的建议：学习阶段，不管框架多方便，都先写一遍不依赖框架的原生代码。我见过太多"框架熟练工"，会用LangChain的链式调用，却不知道一个RAG请求真正经历了哪些环节；出了问题只能网上搜，搜索不到就彻底卡住。用原生API把第三节里那个RAG链路完整写一遍，把Agent循环自己实现一遍，你会发现框架只是个封装，底层逻辑一点都不神秘。
这不是说框架不好，而是说理解要在抽象之前。框架帮你省掉的重复劳动，建立在你已经理解它帮你做了什么事的前提下。否则你省掉的不是麻烦，是理解。
6.2 主流框架与向量数据库怎么选
开发框架我用自己的经验给你一个客观的评价：
| 框架/工具 | 定位 | 适用场景 | 注意事项 |
|---|---|---|---|
| LangChain这类编排框架 | 全链路组件编排 | 项目里组件多、集成复杂 | 版本更新频繁，抽象层多，排错成本高 |
| LlamaIndex这类数据索引框架 | 文档索引与RAG | 知识库密集、召回场景多 | 索引优化方便，Agent能力不如通用编排框架 |
| 原生代码 + 必要库 | 自由可控 | 学习原理、做精细定制 | 代码量大，但最透明 |
| Chroma/FAISS | 轻量向量存储 | Demo、中小规模 | 简单易用，数据量大要换分布式方案 |
| Milvus这类分布式向量库 | 生产级向量存储 | 大规模、高并发 | 部署运维成本高，初创期别急着上 |
我的项目选型原则很简单：Demo期怎么做最简怎么做，上线前再根据真实瓶颈做取舍。不要因为某个框架"未来能扩展到百万数据量"就在第一天选它，你的第一个版本可能连一千条文档都没有。过早引入重型基础设施，只会拖慢迭代速度。
6.3 环境准备：虚拟环境、依赖管理与密钥管理
很多教程跳过了环境配置，直接到代码，结果新手第一步就摔跤。这里给你一份足够稳的准备流程：
# 1. 创建并激活虚拟环境 python -m venv venv source venv/bin/activate # 2. 安装核心依赖（按需增减版本号） pip install openai python-dotenv pip install langchain chromadb tiktoken # 3. 用.env管理密钥，绝不要写进代码 echo "OPENAI_API_KEY=sk-xxx" > .env在密钥管理上我说个血的教训：有一次我把API密钥直接写进了共享的代码仓库，不到两小时就被扫描程序捞走了，当天账单直接爆掉。现在我的所有密钥都放环境变量或密钥管理服务里，代码仓库里只放.env.example模板，并且把.env加进.gitignore。这类事一次都赌不起，新手尤其要养成习惯。
7. 小白7天入门路线与避坑清单
7.1 7天路线图：每天学什么、交付什么
如果你完全没有经验，又想快速建立完整的动手能力，我建议你按下面这份路线走。每一天的产出都是"一个能跑的东西"，而不是"看完了某个文档"。
| 天数 | 学习主题 | 当日交付物 |
|---|---|---|
| Day 1 | LLM API调用与基础认知 | 用代码完成一次真实的模型调用，拿到回复 |
| Day 2 | Prompt工程 | 针对一个具体场景写出一套四段式Prompt，并验证稳定性 |
| Day 3 | RAG最小实现 | 加载3个文档，跑通"检索+生成"问答 |
| Day 4 | 向量化与检索调优 | 调整chunk方式，对比检索结果并记录差异 |
| Day 5 | Agent最小实现 | 让模型能调用两个工具完成"查询天气并整理成日报" |
| Day 6 | 记忆系统 | 实现跨对话记住用户名字与偏好的Demo |
| Day 7 | 综合项目 | 做一个"带记忆的、可回答私有知识的、能调用工具的助手" |
到了第7天，你其实已经把7大核心领域的核心串起来了。这个综合项目不用大，但一定要完整。
7.2 我给新手的10条避坑建议
- 别在没跑通Demo前纠结"最优架构"。架构是为可维护性服务的，你的第一版还没有维护负担。
- 别把大模型当数据库用。事实查询交给RAG或传统存储，模型只负责理解和生成。
- 别忽略输出校验。模型输出是"概率性正确"，必须有程序层面的兜底。
- 别把密钥写进代码。一次泄露就可能被薅掉大量API额度。
- 一定要设计日志。模型输入输出、耗时、成本、召回结果全都要留痕，不然线上问题无从查起。
- 别盲目追逐最新版本。框架大版本升级经常破坏API，能用稳定的就别当小白鼠。
- 密切关注上下文长度与成本。同样功能，不同Prompt方案token消耗能差好几倍。
- 先保证召回质量，再调生成效果。RAG系统里召回是根，生成是叶。
- 做好输入输出的Schema校验。非结构化数据是系统地雷。
- 给自己定义一个"最小可用"标准，别憋大招。7天学不会完美，但完全足够学完"能跑通"。
7.3 从"跑通Demo"到"做成产品"：评估、监控与成本
很多人的项目止步在Demo，是因为没有往下走产品化的那几步。第一个要解决的是效果评估。RAG系统不能只靠"感觉回答得还行"，要建立一批测试问题集，给每个问题标注标准答案，自动记录模型的回答、召回结果、准确率和漏检率。我一般准备50到100条线上真实问题作为评测集，每次改参数都重新跑一遍，用自己的评测数据判断改动方向，而不是拍脑袋。
第二个是监控。上线之后至少要看三件事：API调用的成功率与延迟、用户真实Query里的Bad Case、每天的token消耗成本。我见过不少团队，模型表现时好时坏却毫无察觉，等用户投诉了才去翻日志，非常被动。
第三个是成本控制。大模型API的账单是按token算的，而在Agent和RAG场景里，每次任务动辄消耗几万token。如果不做缓存、不做上下文压缩、不限制Agent最大步数，一个看起来很简单的功能也能烧出让你肉疼的费用。建议从第一天就养成记录token的习惯。
我在做综合项目的阶段，最大的体会是把上面这些"无聊的工程问题"处理好，反而比追求更花哨的模型能力提升更快。因为产品体验的短板，往往不在模型的聪明程度，而在工程链路的可靠性。
最后再分享一个实际项目里被验证过的小技巧：把项目中的Prompt模板、参数配置、知识库版本全部纳入版本管理。模型效果和Prompt文本强相关，你改了Prompt却说不清改了什么，回滚和排查都会变成灾难。哪怕只是加了一个换行符，也记录下来。AI开发很多时候不是"一次写好"，而是"持续调对"，而调对的前提，是每一次改动都留痕。这条习惯，越早养成越受益。
