企业官网建设流程全解析

很多人问我，一个没接触过大模型开发的人，怎么系统进入AI工程（AI Engineering）。网上资料虽然多，但今天一个LangChain教程、明天一篇Agent论文、后天一个RAG实战，学完还是不知道怎么搭一个真正能上线的系统。我自己的感受是，AI工程这块，最缺的不是资料，而是一条能照着走的路线。

“from scratch”这四个字，很多人理解成“从数学原理开始”，我觉得这是误区。工程层面的from scratch，指的应该是：不依赖某个封闭平台的拖拽组件，不稀里糊涂地套模板，而是从提示词、上下文、工具调用、评估这些地基模块开始，一层一层自己搭起来。你只有亲手搭过一遍，后面用再高级的框架，心里才有底。

这篇文章就是我总结的完整路线。我会从提示工程讲到RAG，再讲到Agent，最后落到评估、部署和持续迭代。整个过程都以“能否跑通一个真实业务场景”为验收标准。写给谁？想系统上手AI工程的开发者和技术负责人，也包括那些已经用过模型API、但总觉得差一口气的独立开发者。全文没有高深公式，但每一步都是可以照着抄作业的实操。

1. 从零开始之前：AI工程到底在解决什么问题

1.1 模型能力与业务需求之间的三重断裂

先想清楚一个前提：现在的开源和闭源大模型，能力已经很强了，但“能力很强”和“在你业务里能用”之间，隔着三道断裂。

第一道断裂是表达断裂。模型听得懂人话，但对“交代不清的任务”只能猜。很多人觉得写提示词就是写一句“帮我写个总结”，其实根本不构。你让模型总结的是三万字的技术文档，还是客服对话记录，还是财务月报？要不要输出表格？格式有什么要求？如果你没说明白，模型就会给你一个“在所有场景下都差不多的通用废话”。这一道断裂靠提示工程解决。

第二道断裂是信息断裂。模型在训练时背下来的知识，到你上线那天已经过期了。你问一个2024年之后成立的公司的产品政策，它只能编。就算你愿意给它外部资料，怎么给？一次性全塞进去，token超限，性能下降；不塞进去，它就瞎说。这一道断裂靠RAG（检索增强生成）解决。

第三道断裂是行动断裂。模型能说话，但不能干活。它回答“我帮你查一下订单状态”，但实际上它连查询接口的地址都不知道，也没有权限调起这个接口。用户的真实诉求不是“聊到答案”，而是“把事办了”。这一道断裂靠Agent（智能体）加工具调用解决。

理解这三重断裂，你就理解AI工程的所有模块在补什么漏洞。这不是在追赶技术时髦，而是在做一件特别实在的事：把模型的语言能力翻译成业务系统的交付能力。

1.2 工程化的四个核心模块

既然断裂有三重，那对应的工程模块其实也就四个：提示、上下文、工具、评估。我这样划分可能跟教科书不一样，但实际操作里，你所有的工作都会归到这四个筐里。

提示（Prompt），是让模型明确执行指令的接口。上下文（Context），是把业务数据和规则接进模型的管道。工具（Tools），是让模型触达真实世界的杠杆。评估（Evaluation），是给可能出错的概率化行为上锁的关卡。

我用一句话概括它们的关系：提示是任务书，上下文是资料室，工具是手脚，评估是质检员。一个成熟的大模型应用，缺了任何一块都会出问题。

只说“我们做个AI客服”，这就不是一个工程方案。但你把这句话拆成四块：“用提示词定义客服的角色边界和话术规范”“用RAG把最新的售后政策喂给模型”“用工具调用让模型拉取订单状态”“上线前准备500条测试问题做回归评估”——这就是一个可以施工的工程方案。AI工程和普通API调用的分野，就在这里。

1.3 为什么第一步必须落在提示工程

我见过不少一上来就研究微调或者训练模型的团队，结果战线拉得很长，产出却很飘。我的建议是，别管后面想得多复杂，第一步老老实实把提示工程学扎实。

原因有三个。第一，提示工程的门槛最低、见效最快，一天就能看到明显的质量变化。第二，后面做RAG也好、做Agent也好，所有环节最终都要归结到一个提示词如何组织。第三，“能不能把需求说清楚”是AI工程师的基本功，这个能力练不出来，后面做任何回调、任何编排都会觉得别扭。

而且，不要以为提示工程就是“语文题”。它本质上是接口设计。你在定义模型输入输出的协议，只是这个协议的语法是自然语言而不是编程语言。既然是接口设计，就要讲究结构、边界、异常处理和版本管理。下面那个章节，我们就把它系统化地拆开讲。

2. 第一块基石：Prompt Engineering的系统化方法

2.1 提示词的结构化拆解：角色、任务、上下文、边界、输出格式

我见过太多人写提示词，就是一句话扔进去。从工程视角看，一个可靠的提示词应该包含五个部分：角色（Role）、任务（Task）、上下文（Context）、边界（Constraint）、输出格式（Format）。我把这五个词的首字母合在一起，给它起个名字叫RTCFF，方便记忆。

• 角色：让模型进入一个特定的专业状态，比如“你是一名具备八年经验的跨境电商客服主管”。
• 任务：用动词开头的清晰指令，比如“根据用户问题，在下面政策文档中检索相关信息并给出答复”。
• 上下文：把需要的事实资料、用户问题、历史对话放进来，比如“以下是公司退货政策文档的片段”。
• 边界：明确什么不能做，比如“如果文档中没有相关信息，明确告知用户需转人工，禁止编造”。
• 输出格式：定义返回的字段和样式，比如“返回一段不超过150字的答复，并在结尾附上引用的政策条款编号”。

为什么要拆这么细？因为模型的回答质量，很大程度上取决于你给它的“约束密度”。角色约束减少风格漂移，任务约束减少跑题，边界约束减少幻觉，格式约束减少解析成本。每一层约束都在降低模型的自由度，而工程上我们恰恰需要“可控的创造性”。我问你一个问题：如果模型在100次回答里有5次擅自发挥，你敢把它接到用户面前吗？结构化提示词就是把这5次擅自发挥压缩到最低。

我放一个对比。普通提示词可能是“帮我写一个商品描述”，结构化之后是：“你是一名资深电商文案（角色）。为‘便携式户外电源’写一段详情页文案（任务），产品参数：容量1000Wh、重量4.5kg、支持太阳能充电（上下文）。不要夸大宣传，不要出现‘最’‘第一’等极限词，控制在300字以内（边界）。输出格式：第一行写卖点标题，第二行开始写正文字（格式）。”你自己感受一下，哪个版本的输出更靠近可直接上线的方案。

2.2 提示优化的迭代闭环：改一处测一处

很多人在调提示词时有个坏习惯：同时改好几个地方，结果效果变好了，但不知道是哪一处起的作用；效果变差了，也不知道是哪一处拖的后腿。提示工程的铁律是：一次只改一个变量。

我自己的迭代流程是：先准备一个固定的测试集，至少二十个覆盖不同难度的case。比如做一个客服问答，就准备正常咨询、政策边界、讽刺语气、信息不全、多个问题混在一起这五类场景，每个场景至少四五个例子。然后记录当前提示词在这些case上的通过率。接着改提示词的一个部分，跑同一组case，对比通过率变化。通过才保留，不通过就回滚。

这里有一个关键点：不要只靠“感觉回答变好了”。如果你没有测试集，你就是在掷骰子。哪怕只是一个小改动，也要用同一条问题从头到尾跑一遍，看最终输出和预期答案的差距。我见过太多团队在提示词上“每次上线都靠运气”，本质就是缺了这一轮“回归测试”。

还有一个很实用的技巧：把“坏例”直接写进提示词。不要只告诉模型“不要胡说”，而是给它一个具体的错误示范。比如：“反面示例：用户询问某型号充电宝是否有3C认证，模型回答‘该产品通过了所有安全认证’——这是错误的，因为文档中只提到该型号有CE认证，没有提到3C认证。如果文档中未出现3C认证字样，只能回复‘以官方信息为准’。”坏例比抽象规则有效得多，因为模型学到的是模式，不是一个标签。

2.3 从单轮提示到多轮上下文管理

等单轮提示词调稳了，你马上会遇到一个新问题：用户跟模型多聊几轮之后，模型把前面的对话忘了。这时就要处理多轮上下文管理。

现在主流模型接口都提供了system、user、assistant三种消息角色。你的system消息放常驻规则（人设、边界、格式），user消息放用户输入，assistant消息放模型之前的回复，也可以放你想引导的历史消息。这个结构本身不复杂，真正的难点在于历史太长，塞不下。

一个真实的场景：客服机器人，用户聊了十轮还在追问，但token上限到了。策略无非三种：截断（只保留最近N轮）、摘要（把前面的对话压缩成一段事实清单）、关键信息抽取（只提取用户ID、诉求类型、订单号这类结构化信息）。工程上最常用的是摘要加截断的组合。

我个人推荐：把“会话摘要”做成一个独立方法。每轮对话结束时，判断当前token总量，超过阈值就调用一次摘要模型，把历史压缩成“用户已确认退款方案为原路退回，预计3-5个工作日到账，用户情绪平稳”这样的事实记录，再作为系统消息塞回下一轮。这样既保住关键事实，也控制成本。这里要提醒一点：摘要不是随便让模型复述一遍，而是明确要求“只提取与任务相关的决策、结论、事实参数，丢弃寒暄和重复内容”。

3. RAG：让模型学会翻书再说

3.1 为什么优先选RAG而不是微调

很多人一提到“让模型知道我的业务知识”，第一反应是微调（Fine-tuning）。但在绝大多数应用场景里，RAG是更优的起点。原因很简单：RAG是让模型“考试时翻书”，微调是让模型“考前背题”。

背题的问题是：第一，价格贵，训练一次成本不低，而且每次数据更新都要重新训练；第二，时间慢，从准备数据到训练完成，按天算；第三，有遗忘风险，模型可能学会新知识、忘记旧知识，或者在有冲突时产生幻觉。而翻书的好处是：知识更新只需要替换文档库；不改变模型权重，成本低；模型被要求“只能依据提供的文档回答”，幻觉概率显著降低。

我把两者的取舍整理成下面这个表，方便你对照决策。

微调不是没用，它适合做“语言风格”和“输出范式”的定制，比如让模型学会写某个行业的专业报告。但知识的事实性来源，RAG永远是优先选项。你要记住一个工程原则：能检索到的知识，不要让它进权重。

3.2 RAG的标准流程与关键参数

RAG的标准流程看起来就八步：采集、清洗、切块、向量化、建索引、召回、重排、注入生成。但真正拉开差距的是细节。尤其切块和召回，它们决定了上限，而生成只是把检索结果用掉而已。

先说切块。很多项目把业务文档原样切块，或者按固定字符数硬切，结果一句话被切得七零八落。比较可靠的做法是“结构感知切块”：优先按Markdown标题、段落、列表项来切，让每个chunk尽量是一个语义完整的小节。chunk_size建议在512到1024 token之间，overlap（重叠）建议设成10%到20%。重叠的作用是避免关键句正好落在切缝上被截断。举个例子，政策文档里“退款金额以实际支付金额为准，不含优惠券抵扣部分”这句话，如果被切到两个块里，模型就各看到半句，后面必然出错。

再说召回。TopK设多少，不是拍脑袋。设小了容易漏，设大了容易塞进无关信息干扰模型。我常用的方案是：先用向量召回Top 20，再用重排模型（Reranker）按相关性精排取Top 3到5，注入提示词。重排这一步非常值得加，它能把“大概相关”的那批结果里真正有用的挑到前面。没有重排的RAG，就像一个图书馆只按书名关键字找书，找到一堆名字像但内容不对的。

向量的选择上，现在很多国产和开源模型提供的Embedding接口都已经够用了。需要注意，你的正则、清洗、切块代码，在开发环境和生产环境必须用同一套。我踩过一个坑：开发时用的PDF解析库在线上环境版本不同，导致线上切块质量直线下降，检索准确率掉了十几个点。后来我写了一组单元测试，专门校验“预处理模块在数据不变时输出是否一致”。

3.3 一个客服知识库问答的落地示例

我拿一个实际项目举例。之前做一个跨境电商的售后客服问答，知识库里有两千多份政策文档和市场准入要求。业务方要求：用户问“这个产品能不能寄到英国”，必须答出来“能，但需符合UKCA认证要求”，并附上政策原文出处。

步骤是这样的：先把PDF和Word统一转成Markdown，按目录结构切块，生成向量索引；然后用户提问时，用一个重写模块把“它能不能寄英国”改写成更利于检索的查询词“物流限制+英国+认证要求”；接着取回Top 20，过重排取Top 3；最后把检索结果拼进一个提示词模板，要求模型“仅依据提供的文档内容回答，并在末尾以‘[依据：文档名-条款编号]’的格式引用来源”。

这个“引用来源”的设计极其重要。它不只是一个格式要求，它让模型的输出变成可验证的。质检人员只要人工抽查答案里的引用编号，就能判断回答是不是真的基于文档。有一次系统上线后，业务方指着一堆差评说“它答错了”，我做的第一件事不是调模型，而是检查引用编号——果不其然，两份政策文件对“保修期”的定义有冲突，而检索排序把过时的那份排在了前面。后来我在预处理时给每个文档加了“生效日期”字段，在重排阶段把“生效日期在用户购买时间之前”作为硬性过滤条件，这个问题才彻底解决。

3.4 RAG的经典翻车现场与规避清单

翻车现场一：检索丢失关键信息。症状是模型回复“文档中没有相关信息”，但文档里其实明明有。原因多半是切块把关键句子拆散了。解法是：第一，增大overlap；第二，对用户问题做“查询词重写”，把口语化的问法转成更贴近文档术语的问法；第三，增加关键词检索作为第二路召回，跟向量检索合并去重。

翻车现场二：检索到了但没用到。也就是向量TopK里确实包含正确答案，模型却恰好忽略。这通常是因为提示词里“检索内容”和“系统规则”混合在一起，模型分不清。解决办法是在提示词里明确写“以下是被检索到的资料片段”，并且把“若片段中无答案，直接说不知道”写进边界约束。

翻车现场三：多份文档互相矛盾。政策类场景特别容易发生，比如“公示版规则”和“内部执行版规则”同时入库。解法是建立文档的版本字段和覆盖规则，在检索前或重排后做“时效性优先”的过滤。记住一句话：RAG系统的质量，一半取决于检索，一半取决于数据治理。数据不干净，检索和生成再强都救不回来。

4. Agent：从问答到自动干活

4.1 理解Agent的三层能力：规划、工具、记忆

把RAG做踏实之后，你会发现用户的需求又往前了一步：不只是“回答我的问题”，而是“帮我把事情办了”。比如“帮我查这几天的订单汇总，生成一份周报草稿，放到指定目录”。这就进入Agent的范畴。

Agent，通俗讲是“能干活的大模型应用”。它有三个核心能力：规划（把大任务拆成小步骤）、工具（调用系统接口、API、代码执行器）、记忆（跨步骤保留状态）。三样缺一不可。没有规划，模型只会一步到底；没有工具，它只能嘴上说不能真的做；没有记忆，它做着做着就忘了前面已经拿到什么数据。

我拿“生成业务周报”这个需求拆解一下：规划阶段，模型要识别出“获取本周各渠道销售数据”“套用周报模板”“填充数据并形成摘要”“保存文件”这四个步骤。工具阶段，它需要调用数据查询接口、模板读取函数、文件保存接口。记忆阶段，它至少要记住“数据源ID”和“已生成的中间统计结果”。这一整个链条，就是技术圈常说的harness engineering——不是模型单打独斗，而是把模型、工具、数据像走线一样编排进同一套工程框架里，每根线从哪来到哪去，都要清清楚楚。

4.2 结构化输出与工具调用：先让模型“说人话”再“干人事”

想让模型调用工具，第一步不是让它“干活”，而是让它“把要干什么说清楚”。也就是说，让它输出一个结构化的“行动计划”，而不是自由描述的句子。

现在主流模型厂商都提供了函数调用能力（Function Calling），本质就是：第一，你给模型一份可调用函数的清单，每个函数有名字、参数说明、参数类型；第二，用户提出需求；第三，模型输出一个JSON，表示“我要调用函数X，传入参数A和B”；第四，你的代码执行真正的函数调用，把结果反馈给模型；第五，模型基于真实结果生成最终答案。

我之前用一个轻量化实现替代了部分复杂框架，效果也不错。核心逻辑就是让模型输出一个带type字段的JSON，type是“action”时，里面紧随其后的就是需要调用的函数名和参数。我让模型只认白名单里的函数名，一旦参数格式不对就触发重试。这一层“参数校验”极其重要：模型生成的JSON虽然格式正确，里面的日期、编号、用户名可能是编的。如果不去校验，轻则返回空结果，重则在系统里写入脏数据。

4.3 多步任务循环：一个可运行的最小Agent骨架

如果你不想一上来就用重型框架，我强烈建议先自己写一个几十行的Agent循环。它能帮你理解所有框架的本质。我用伪代码描述一下，你拿任意语言都能翻译出来：

def run_agent(user_task): messages = build_initial_messages(user_task) for step in range(max_steps): response = call_llm(messages) action = parse_action(response) # 解析模型输出中的函数调用 if action is None: # 模型认为任务已完成 return response.final_answer result = execute_tool(action) # 真实执行函数 messages.append(assistant_response) messages.append({"role": "user", "content": f"函数返回结果:{result}"}) return response.final_answer

这一段逻辑里，最核心的是while循环：模型观察当前状态，决定下一步动作，调用工具，拿到结果，继续观察。任务没完成就循环，完成就退出。很多人问我要不要限制循环次数，我的答案是要，而且上限设得保守一点，默认8步就够。因为模型偶尔会在同一个错误动作上反复横跳，不设上限会导致死循环和成本飙升。

代码组织上，我会把“工具注册表”独立出来。每个工具是一个函数加一份JSON描述，包含名称、描述、输入参数类型。Agent循环不关心工具的细节，它只通过description来判断何时调用。这种“注册表”模式的好处是新增能力时不用改Agent主循环，只需要注册新函数。工程上这叫开闭原则，你要保持循环体稳定，能力持续扩展。

4.4 Agent落地中的边界、风险与审批机制

Agent的能力越强，破坏力越大。我见过一个团队上线了一个自动处理退款申请的Agent，逻辑是“若用户符合退款条件，自动调用退款接口”。某天因为上游数据错了一位，几千单被错误标记为“符合条件”，差点批量打款。那之后我给自己定了一条铁律：高风险的写操作，必须加人工审批。

这个审批机制不复杂：Agent负责把所有前置工作做完，比如“检索政策、核对条件、生成退款建议”，但真正按下“执行”按钮的，永远是一个走审批流的人。你可以让Agent生成一个审批工单，包含依据、结果、风险等级，然后由人工在后台点“通过”。低风险动作可以自动执行，比如查天气、翻译、生成普通文档；高风险动作一律卡一道人工确认，比如发邮件、转账、删除数据、修改数据库。

还有权限最小化。给Agent的工具权限，应该比给员工的最低权限还低。它不值得拥有“所有用户订单”的查询权限，只应该有“当前对话中相关订单”的查询权限。权限的口子收得越紧，出事之后的爆炸半径就越小。另外，任何Agent的对外动作，都要保留完整的可审计日志：“什么时候、谁授权的、调了哪个工具、传了什么参数、返回了什么结果”。

4.5 关于Agent框架选型：先原生调试，再框架编排

我刚接触Agent时也纠结过：用LangChain？用LlamaIndex？还是自研？后来我的结论是：第一次做，不要用框架，直接用模型接口手写那个while循环。你先体验一遍“从模型输出里解析函数调用、手动拼上下文、处理异常”的完整细节。这些细节不亲手做一遍，你永远不知道框架里的那些抽象层在替你掩盖什么。

等跑通一个最小闭环后，再用框架来提升效率。这时框架对你来说就不是黑盒，而是一个能看懂、能改装的工具箱。我团队现在生产环境里，有一部分是自研的最小编排，有一部分是开源框架加大量定制。关键是你要清楚每次编排中“模型决定什么”“代码决定什么”“人在哪里兜底”。

再补充一点，很多Agent项目死于“配置地狱”。你把太多逻辑写死在代码里，改一个业务规则就要发版。我的做法是：Agent的提示词、工具描述、可用工具列表都放到配置中心或者数据库里，运营人员可以在后台调整。模型的能力边界是个动态问题，你的系统架构也必须是动态的。

5. 评估、部署与持续迭代：工程闭环的最后一块拼图

5.1 评估集：AI工程的回归测试

我在前文反复提到“测试集”，这里展开讲。传统软件工程有单元测试和回归测试，AI工程必须有评估集（Eval Set）。模型的行为是概率化的，你改一个提示词，可能对其他case没影响，但对某个case造成灾难。没有评估集，你就无法回答一个最基础的问题：新版本到底比旧版本好还是坏？

构建评估集有三个来源。第一个来源是历史真实case，从线上日志里抽最常见的用户问题。第二个来源是边界case，专门挑那些容易翻车的类型，比如问题里混着多个意图、问题短到只有四个字、涉及敏感词规则等。第三个来源是bad case，也就是之前模型答错的案例，它们必须进回归集，防止同一处错误再次发生。

评估标准不是“对还是错”的二分法，我建议分三档：正确（答案完全匹配预期）、可接受（信息不完整但不误导、可以重试）、不合格（事实错误、离题、格式错误）。评分方式上，初期可以人工标注，跑两百条case花两三个小时，这个过程会逼你审视自己的设计；后期可以引入LLM作为裁判，让一个大模型对系统输出进行打分，再辅以人工抽检。

我还建了一个“评估报告自动生成”的脚本，每次改动后跑一遍，输出“当前版本通过率、每个bad case的原文与模型回复、与上一版本的差异”。这样当你跟业务方对齐时，拿得出一份可量化的对比，而不是“我觉得效果好多了”。请你务必养成这个习惯，它会让你在无数个“我明明调好了为什么又不行”的夜晚里，至少有一个确定的判断依据。

5.2 从评估到监控：上线后不能当甩手掌柜

评估集管的是“上线前”，上线之后还要做“持续监控”。原因很简单：线上用户的真实输入，比你准备的测试集更野，永远有新花样。

我建议在核心应用里接一个最小监控面板，至少包含五个指标：调用量、成功率、平均响应时长、用户反馈率、bad case量。前三个是性能指标，后两个是质量指标。用户反馈率尤其关键，无论你的系统是web端还是IM，都要在界面上留一个“回答是否有帮助”的按钮。别看按钮小，它是你发现线上问题最便宜的方式。

我举一个真实失败的例子。我们做过一个营销文案生成工具，上线第一周各项指标都很漂亮，第二周“用户反馈不佳”突然上升。查监控发现调用量没降、延迟正常，看日志才发现某个提示词版本在当天被运营误改了一个标点，导致输出格式全部偏掉。因为日志里有版本号，十分钟内锁定是配置改动，回滚后恢复正常。这个教训告诉我：没有日志版本和监控面板，你连“自己改坏了”都发现不了。

5.3 部署与成本控制：别让AI账单吃掉利润

AI应用的成本是个容易忽视的大坑，特别是Agent跑了多轮循环之后，一个用户的一次请求，背后可能是五六次模型调用。我在预算评估阶段用的公式很简单：日均用户数×平均每用户请求轮次×每次调用的token消耗（取输入和输出之和）×单价×1.5（预留波动）。这算出来是一个保守预估，你要是想精细一点，把tokens按输入和输出分开乘单价再相加。

降成本有几个百试不爽的手段。第一，缓存。完全相同的用户请求，可以直接复用之前的回答。更进一步可以上语义缓存，即用户的问法和历史问题意思相近时，直接返回历史答案。第二，模型分级。不是所有请求都需要最强模型。比如“判断用户问题属于哪个分类”这种简单任务，用一个便宜的小模型就够了；只有“生成退款答复并综合判断”这种复杂任务，才用旗舰模型。我做过一次优化，把80%的简单分类请求从旗舰模型迁移到小模型，P95延迟下降了60%，成本降低了大约70%。第三，控制上下文长度，跟业务确认哪些历史内容可以丢弃，避免每轮都重新塞入整篇对话。

部署架构上，如果只是做内部工具或中小流量应用，一个API网关加无状态服务就足够了。需要关注的是超时和重试逻辑，模型接口偶尔会慢，你的服务要有合理的超时时间（比如15到30秒），超时后给用户一个友好的失败提示，而不是无限地等下去。

5.4 持续迭代的节奏：以小步快跑代替大爆炸

当评估、监控、部署都到位，剩下的就是迭代节奏。我强烈建议把“AI应用开发”当作数据产品来迭代，而不是当作一次性项目来上线。固定一个节奏，比如每周一个版本。

流程是这样的：周一从线上bad case和用户反馈里挑出本周要解决的问题；周二改提示词或调RAG配置；周三跑评估集，看通过率变化；周四灰度上线到5%流量；周五看数据，决定全量或回滚。这听起来很平常，但真正做到位的团队很少。多数团队是“憋一个月憋一个大版本，上线当天翻车”。

提示词要纳入配置管理。我现在所有提示词都放在独立的配置目录里，带上版本号。代码和提示词分离的好处是：运营可以独立修改话术，工程师不需要为了一个标点符号去发版；同时每次改动都留痕，出问题能定位到具体版本。类似的做法也可以延伸到RAG的知识库和Agent的工具配置上：任何一次行为变化，都应该能追溯到“谁在什么时候改了什么配置”。

6. 从零开始的六周实操路径与我的最后真心话

6.1 一条可直接执行的六周路线

如果你看完前面这些内容，觉得还是不知道从哪下手，我给你一条自己验证过的路线。不需要一步登天，每星期交付一个能演示的demo，你会越走越有感觉。

第一周：提示工程。挑一个你熟悉的业务场景，比如“工作总结生成器”。自己写提示词模板，做二十个测试case，每天迭代两个版本，记录通过率变化。这周的目标是掌握结构化提示词和回归测试的方法。

第二周：RAG。给场景配上知识库。比如“基于公司产品手册的客服问答”。重点练数据清洗、切块、召回和引用输出。这周的目标是跑通一个完整的检索问答流程。

第三周：Agent。在问答基础上加工具。比如“客服代理不仅能答政策，还能查订单状态、生成工单”。手写一个Agent循环，注册三个工具，实现带流程审批的闭环。

第四周到第五周：评估与部署。把前三周成果组装成完整系统，建评估集，接监控面板，封装API，加缓存和限流，做一次成本估算。这周的目标是让它像个产品，而不是Notebook。

第六周：综合项目。选一个真实业务痛点，不限题目，自主设计。要求包含至少一个工具调用、一个知识库、一个评估方案。这周的目标是“离开模板也能独立设计系统”。

我见过很多同事按这个路径走完五周后，已经能独立承接公司的AI应用需求。走不完整个路径也没关系，哪怕只完成前三周，你对“from scratch”的理解也会完全不一样。

6.2 学习中最常见的三个心态陷阱

我必须说几句真心话，因为“AI工程”这个词现在太热了，热到很多人还没开始就焦虑。

第一个陷阱是资料囤积症。收藏了三百篇教程、关注了五十个博主、存了十个G的PDF，但一个demo都没跑通。这类人不是缺资料，是缺“关闭浏览器开始写代码”的决断。每周给自己一个目标，哪怕很小的目标，然后逼自己交付。

第二个陷阱是框架依赖症。总觉得等LangChain生态更成熟、等某个新框架出来、等官方更新了再做。但框架是工具，不是捷径。你今天用原生API写一个Agent循环花三天，三天后你收获的是框架给不了的内功。反过来，如果你一上来就调框架，遇到问题根本不知道是模型的问题、工具的问题、还是编排链的问题。

第三个陷阱是调参赌徒心理。把温度调到0.7、换了一个模型版本、把top_p改成0.9，就期待效果突变。这不是调优，这是赌博。真正的调优是：每次改变有明确假设，有测试集，有对比指标。你对自己说“我觉得换成GPT-5会好”，那好，先测上五十个case再说。

6.3 我做AI工程这几年最深的几点体会

第一点体会，AI工程的第一性原理是可控性。模型天生不可控，工程的作用不是“让它更聪明”，而是“让它的聪明落在边界之内”。你校验输出格式、你加引用来源、你上审批流、你建评估集——这一切动作，本质上都在做一件事：压缩不确定性。

第二点体会，提示词不是玄学，它是一门接口设计。我在前面写的五部分结构拆解，就是一套接口协议的设计方法。你越早把这套方法内化，越少经历“玄学调参”的痛苦。当你把提示词当作代码来写，你就再也不会问“用什么工具能自动优化提示词”这种问题了。

第三点体会，不要被风口推着走。从零开始学AI工程，真正的难点从来不是理解Transformer，而是建立起“边交付边学习”的工程习惯。今天的大模型半年换一代，今天框架三个月换一次，但工程方法、数据处理思维、评估闭环、风险意识，这些是不会过时的。

最后分享一个小技巧：在你开始任何AI项目前，先写一句“验收口号”——一句话说清楚“当什么发生的时候，这个项目就算成功”。我自己的例子是：“用户在客服对话框里问退款，五分钟内收到一份带政策依据和预计到账时间的回复，且人工抽检一百条不出现事实错误。”这句话比任何需求文档都有力。当你把口号的每一个要素拆到技术方案里时，你已经不是一个只会调接口的人，而是一个真正在做AI工程的人了。