1. “AI 工程”究竟在工程什么一个从业者的重新定义1.1 先放下一个执念AI 工程不等于训练模型很多人一听到“AI 工程”第一反应是机器学习、深度学习、炼丹调参。这个印象在五年前是对的在今天已经严重过时。自从基础大模型把“从零训练一个能理解语言的模型”这件事变成了一件普通开发者不需要再碰的事之后AI 工程的重心已经从“造模型”转移到了“用模型造产品”。我自己就是从零开始走这条路的。最开始我以为要先把 Transformer 结构吃透、把反向传播手写一遍才能动手结果花了两周看理论代码一行没写。后来调整策略先学会调 API、先做出一个能跑的聊天机器人再回头补原理。实践一上手很多理论名词突然就通了。所以我建议所有从零起步的人别把理论学习放在动手之前两者要并行但动手永远优先。那 AI 工程到底在做什么我现在的理解是把一个大模型或者多个大模型接入真实的业务场景让它在约束条件下稳定、可控、可评估地完成特定任务。这里面涉及提示词设计、上下文组织、工具调用、数据回流、效果评测、成本优化、错误兜底是一整套系统工程而不仅仅是“发个请求拿个结果”。这也是我想写这篇文章的原因。市面上的教程要么太偏理论上来就是注意力机制要么太偏工具教你怎么装框架却不说为什么。我想用自己从零到一的完整经历把 AI 工程这个命题拆开讲清楚到底该学什么、怎么练、坑在哪。这篇文章适合那些已经决定投身 AI 应用开发但不清楚第一步该往哪迈的人。1.2 从零起步需要的能力地图我把 AI 工程需要的能力拆成了六块按重要程度和上手顺序排列能力模块具体内容入门难度模型调用理解 API 参数、流式输出、结构化输出、模型选型低提示词设计系统提示词、少样本示例、任务拆解、格式约束低但精通难上下文管理对话历史截断、记忆压缩、知识注入中检索增强RAG切分、向量化、召回、重排、融合中Agent 编排工具定义、多步决策、循环控制、错误恢复中高评测与监控评测集建设、指标设计、回归测试、线上监控高最容易被忽略这六块不是并列的而是层层递进。前三块是地基第四块是多数文档类应用的核心第五块是当前最有想象力的方向第六块则是决定你能不能长期维护一个 AI 产品的关键。我见过太多人花大力气做了一个 Agent却完全答不上来“它比上一个版本好在哪里”这就是没做评测的后果。对零基础的人我的建议是不要一上来就追 Agent、追多智能体协作。先把地基打牢把一次 API 调用做到极致再谈编排。后面我会详细讲我自己的练手路径每一步都附上我踩过的坑和验证过有效的做法你可以直接照着走。2. 我的从零练手路径从第一个 API 调用到能上线的产品雏形2.1 起步动作先把一个接口用熟、用透我给自己定的第一个目标非常朴素只用一个模型接口做出五个不同的小应用。这一阶段我完全不碰框架不用任何大模型应用层封装就用最原始的 HTTP 调用写。原因很简单封装库帮你省掉的代码恰恰是理解原理的最佳教材。从最简单的开始先是一个聊天补全接口。我建议你做这几件事来练手感写一个脚本连续发十条不同风格的请求观察 temperature、max_tokens 这些参数对输出的影响把流式输出改成非流式对比响应时间和体感差异在 system prompt 里放一段很长的背景说明测试模型对指令的遵循程度给自己建一个“变量控制清单”每次只改一个参数记录输出变化。这一步看起来幼稚但价值非常大。很多人在这一步之前就急着上 Agent、上 RAG结果遇到输出不稳定、幻觉百出根本不知道是提示词的问题、参数的问题还是上下文的问题。变量控制的能力是 AI 工程调试的基础功。另外我要推荐一个很实用的习惯从第一天起就用“结构化输出”。让模型返回 JSON而不是自由文本。你可以在 system prompt 里直接声明输出格式再用代码做一层校验解析失败就重试或降级。这会让你的应用稳定性上一个台阶。很多新手直接拿自由文本去解析一个标点符号差异就崩了这都是可以提前避开的。2.2 五个由易到难的练手项目我全部做过一遍我建议的练手项目顺序是这样的每一个都有明确的目的做完之后能力是叠加的第一个做一个人设固定的聊天助手。目的就是练提示词和参数控制。我给助手设计了角色、语气规则、知识边界然后反复测试它会不会“出戏”。这个项目让我真正理解了 system prompt 的约束力。测试过程中我发现光说“你是客服”是不够的必须把“遇到无法回答的问题时如何回应”也写清楚否则模型会硬答。第二个做一个文档问答工具。把几本书切成片段做向量检索把命中片段塞进上下文让模型基于片段回答。这个项目练的是 RAG 的完整链路切分策略、检索质量、答案组织都会暴露出来。做完之后你会对“上下文才是关键”有切身体会——模型表现得聪明还是笨很大程度上取决于你塞给它的材料质量。第三个做一个信息抽取管线。给模型一堆非结构化的邮件或聊天记录让它输出结构化的字段比如客户名称、诉求类型、紧急程度。这个项目练的是结构化输出和错误处理你会开始认真设计 JSON schema 和校验逻辑也会发现少样本示例对输出质量的影响有多大。第四个做一个带工具调用的 Agent。让模型能查天气、能算数学、能查数据库核心是把“模型决策调哪个工具”这件事做对。这个项目练的是函数调用和循环控制难度上一个台阶但做完之后对 Agent 的理解会完全不同。第五个给自己前面做的某个应用写一套评测脚本。定义一组测试用例每次改完代码自动跑一遍对比输出质量。这个项目练的是评估思维是 AI 工程里最值钱也最少人愿意做的事。我做完这五个项目大概花了两个月每天晚上两三个小时。进度不算快但每一步都有实打实的产出。关键是每个项目都要留文档记录你改了什么、效果如何、为什么这样改这份记录后来成了我自己的“经验库”。2.3 从第一天起就建评测集这是很多人漏掉的关键我在做完第一个聊天助手的时候就发现一个问题每次改完提示词感觉输出“好像更好了一些”但过两天又觉得不对劲说不清哪里退步了。后来我才意识到没有评测集的改进全是幻觉。评测集的建设其实不复杂拿 30 到 50 个有代表性的输入为每个输入写好期望的输出标准然后每次改动之后跑一遍人工打分。打分维度可以很简单比如准确性、完整性、格式符合度每项 1 到 5 分。不需要什么高级工具一个表格就够。等你有了一批真实用户输入之后评测集要持续扩充把线上出过问题的样本都加进去。这就是回归测试的思路和传统软件开发里的单元测试是一个道理。我后来把所有线上翻车案例都沉淀成了评测条目每次新版本上线前先跑评测集低于某个分数就不允许发布。这个机制帮我避免了很多次灾难性上线。3. 核心技能拆开看提示词、Agent 与 RAG 的真实用法3.1 提示词工程本质是结构化沟通不是咒语网上关于提示词的文章很多但大部分把这件事讲玄了。我的理解非常朴素提示词工程就是把你对任务的全部要求用模型最容易遵循的方式表达出来。它像跟一个极其聪明但容易误解你意图的新同事沟通关键是消除歧义。我自己的提示词结构一般是这样先定义角色和任务目标再给出约束条件和输出格式接着给少量高质量示例最后说明边界情况怎么处理。这套结构几乎适用于所有任务。示例的作用往往被低估同一段指令配不配示例效果能差出一大截。还有一个容易被忽略的点提示词也要版本化。我见过很多团队提示词直接写在代码里每次改动都靠复制粘贴保存根本说不清线上跑的是哪一版。我的习惯是把提示词当作独立的版本化资产和代码一起提交每次改动都带着变更说明。这样当线上效果波动时你能快速定位是代码问题还是提示词问题。我强烈建议你把提示词当代码来管理。写一段好的提示词有时比写一段代码更费力它的调试过程也更依赖“实验和观察”。没有版本控制你就是在用感觉做工程。3.2 Agent 设计把大模型装进决策循环Agent 是当前 AI 工程最热的方向但也是最容易被过度包装的概念。剥掉所有花哨的说法Agent 的本质就是一个循环模型根据当前状态决定下一步动作执行动作观察结果再决定下一步直到任务完成或者达到某个终止条件。我做的第一个 Agent 特别简单只挂了两个工具一个查询接口一个计算函数。模型每轮输出两个东西一是思考过程二是要调用的工具和参数。我拿到之后执行工具把结果拼回对话历史继续下一轮。这个循环看起来简单但真正写起来全是细节工具返回结果太长怎么办、模型连续调用同一个工具怎么办、某一步调用失败要不要重试、最多跑多少轮就强制停止。这些都是我在实际写代码时反复调整过的控制点。举个例子工具返回结果我一开始全量塞回上下文一次数据库查询返回几百行记录模型直接蒙了决策质量急剧下降。后来我改成只返回前十条加一个总数字段效果立刻稳定。Agent 的工程含量就在这里——不是模型有多聪明而是你为模型设计的环境有多清晰。还有一个原则永远设最大轮数。没有轮数上限的 Agent 就是一颗定时炸弹账单和延迟都会失控。我建议所有做 Agent 的人先把“最大轮数、超时、重试策略、异常兜底”这四个参数想清楚再谈智能不智能。3.3 RAG 的适用边界与落地细节RAG 是让大模型基于私有知识回答问题的标准方案但很多人对它有不切实际的期待。RAG 不是万能的它解决的是“模型不知道的信息怎么让它知道”的问题而且效果上限取决于检索质量不是模型能力。切分策略是第一个坑。PDF 按固定字数硬切经常把一句话从中间劈开检索召回质量直线下降。我后来改用按标题层级和段落边界切分每个片段尽量保持语义完整重叠区间控制在少量字符效果立刻改善。第二个坑是检索只做向量相似度。向量检索对同义改写很友好但对精确关键词匹配反而敏感度不足最好的做法是向量检索和关键词检索做混合召回再用重排模型把结果重新排序。还有一点我必须强调RAG 的答案必须可溯源。在输出里附上引用的原文片段让用户能自己核对。这不仅是产品体验问题也是信任问题。我做文档问答工具时强制要求每句话都能对应到来源否则视为不合格。这一步让我避开了很多幻觉投诉。适用边界方面如果知识库更新频率很高、内容很短、或者问题对时效性极其敏感RAG 可能要配合其他机制。RAG 适合的是“静态知识为主、答案需要依据”的场景。别指望它解决一切问题。4. 从零到一踩过的五个大坑每一个都让我返过工4.1 坑一把模型当成数据库用我最早的文档问答工具为了实现快直接把用户的问题抛给模型指望它凭“记忆”回答。结果模型一本正经地给出了好几段看起来毫无破绽、实际全是编造的内容。那一刻我意识到模型是概率性的文本生成器不是数据库。数据库里没有的记录会明确说不存在模型没有的记录会帮你编一个。这个坑的解法就是引入 RAG并且强制答案溯源。同时我学到一个经验永远不要让模型回答它没有足够上下文支撑的问题。当检索结果为空或者相关性太低时直接告诉用户“没有找到相关资料”而不是让模型硬答。这个经验后来扩展成了我所有项目的通用原则不确定就承认不确定。这比让模型硬编一个答案体面得多也安全得多。4.2 坑二技术栈先堆满需求还没想清楚这是我早期最蠢的一次返工。我当时想做一个通用问答平台还没想清楚用户是谁、要解决什么问题就先把向量数据库、容器化部署、监控告警全部上了。结果光环境搭建就花了两周核心功能一个字没写。后来我复盘问题出在把技术选型当成了项目进度。正确顺序应该是先用最笨的方式把核心流程跑通验证需求真实存在再逐步替换掉不合适的组件。一个只有几十个用户的产品根本不需要一开始就上分布式向量库。轻量级方案完全够用。从那以后我给自己定了一条规矩任何组件要在“没有它已经跑不动了”的时候才引入。这条规矩让我少做了大量无用功。4.3 坑三没有评测就上线改来改去全凭感觉这个坑我前面提过但值得单独再说一次。没有评测集的迭代本质上是随机游走。你今天把提示词改了一版觉得输出变好了发布上线三天后用户反馈变差了你又改回去来回折腾浪费的不仅是时间还有用户的耐心。我现在对任何 AI 功能的改动都坚持三条铁律先写评测用例再改代码或提示词最后跑评测集对比分数。分数没有提升就回滚。这套流程让我从“感觉主义”变成了“证据主义”迭代质量和速度反而都上去了。可能有人觉得 30 到 50 条评测用例太少代表性不够。但起步阶段哪怕只有十条用例也比零条强得多。评测集的价值在于“可对比”不在于“完备”。你先有一个基线再逐步扩充这比追求一步到位实际得多。4.4 坑四上下文管理与成本控制双双失控AI 应用的账单是随着上下文膨胀线性增长的。我做过一个多轮对话产品早期为了保留完整对话历史每一轮都把从头到当前的全部消息发给模型。对话超过二十轮时单次请求的 token 数已经翻了好几倍响应延迟和成本一起飙升。解法是分层管理上下文最近的对话完整保留较早的对话做摘要压缩摘要再超长就继续摘要。还有一个经验是给每个请求设置 token 上限超了就自动触发压缩策略。成本控制不是上线后才考虑的而是一开始就要设计进架构里。我见过很多团队在产品上线后才发现成本失控然后急急忙忙加缓存、加压缩改得手忙脚乱。其实这些在设计阶段花半天就能规划好。上下文管理不是优化项是必选项。4.5 坑五一个人闷头造轮子从零学 AI 工程最大的风险不是技术难而是闭门造车。我有很长一段时间自己闷头搭框架写了大量没人用过的封装。后来我把代码给一个做后端的朋友看他一眼就指出我的错误处理设计有问题——模型输出校验失败时我的代码会崩溃而不是优雅降级。从那以后我养成了一个习惯每完成一个模块就找至少一个人做代码评审或者产品体验。AI 工程里很多问题比如延迟体感、输出质量、边界情况自己测一百遍也发现不了别人用一次就能暴露。找到愿意当“小白鼠”的朋友比任何教程都重要。如果你身边没有懂技术的朋友那就去社区、去论坛。把你的项目丢出去让陌生人用。他们的反馈可能很糙但每一条都是真实的。这些真实反馈比你自己脑补的完美体验有价值得多。5. 给同样从零开始的你三个月到半年的路线图参考5.1 第一个月练 API 手感打磨提示词基本功第一个月的目标只有一个把一次模型调用做到自己能掌控的程度。这阶段不要碰 Agent不要碰复杂框架。找一个大模型 API写脚本跑通非流式和流式两种模式掌握参数含义然后完成一个带人设的聊天助手。同时开始积累提示词模板什么场景用什么结构整理成自己的文档。第一月底的验收标准是你能在三个不同任务上稳定地让模型输出符合格式要求的结果并且说得清每个参数为什么这样设置。这个月最容易犯的错误是贪多。看到别人做 Agent 很酷就想跳过基本功直接上。我劝你忍一忍地基不牢后面的每一层都会晃。5.2 第二到三个月做带状态的应用开始碰 Agent第二个月做文档问答工具完整走一遍 RAG 的链路。这一步你会把切分、检索、重排、答案组织、溯源全部过一遍对“上下文决定上限”有深刻理解。第三个月做带工具调用的 Agent重点不是功能多而是把循环、轮数限制、错误恢复这些控制逻辑写好。这两个月你会不停地遇到“为什么输出不稳定”的问题。我的建议是把所有不稳定案例记下来归因到提示词、检索、参数或代码形成自己的排查清单。这份清单的价值会随着你的项目越来越多而指数级上升。做文档问答工具时别急着换各种花哨的向量数据库。先把切分和检索调明白你会发现大部分效果问题根本不在数据库层面而在数据准备层面。这个认知能帮你省下一大笔迁移成本。5.3 第四个月起找一个真实场景做给真人用三个月之后你的基本功基本够了这时候最该做的不是继续学新技术而是找一个真实的小场景做一个有真人用户的产品。哪怕是给朋友做一个会议纪要工具给团队做一个知识库问答都行。真实用户会带给你教程里永远学不到的东西真实的数据分布、真实的边界情况、真实的反馈循环。从零开始做这个产品时记得用上前面说的所有经验先建评测集再写代码先跑通核心流程再考虑扩展每次改动都做对比评测。我认为 AI 工程从来不缺技术缺的是把一个 AI 功能做成一个可靠产品的判断力而这种判断力只能从真实项目里长出来。6. 最后几句实在话写到这里我回头看自己从零到一走过的这段路最大的体会是AI 工程的门槛不在数学不在框架而在“愿不愿意用工程的纪律去对待一个本身就不稳定的技术”。我在实际踩坑中形成的几个习惯最后再分享一次永远让模型返还结构化输出永远给生成结果留一个校验层永远先写好评测用例再动手改永远对上下文长度和成本保持敏感永远在发布前找一个人做体验评审。这五条没有一条是高级技巧但每一条都让我少走了很多弯路。如果你也是从零开始别怕慢也别贪多。把一个简单的功能做到可靠比把十个花哨的功能做到半吊子有价值得多。这条路没有捷径但每一步都是实打实的积累。
AI工程实战：从零构建大模型应用的完整路线图
1. “AI 工程”究竟在工程什么一个从业者的重新定义1.1 先放下一个执念AI 工程不等于训练模型很多人一听到“AI 工程”第一反应是机器学习、深度学习、炼丹调参。这个印象在五年前是对的在今天已经严重过时。自从基础大模型把“从零训练一个能理解语言的模型”这件事变成了一件普通开发者不需要再碰的事之后AI 工程的重心已经从“造模型”转移到了“用模型造产品”。我自己就是从零开始走这条路的。最开始我以为要先把 Transformer 结构吃透、把反向传播手写一遍才能动手结果花了两周看理论代码一行没写。后来调整策略先学会调 API、先做出一个能跑的聊天机器人再回头补原理。实践一上手很多理论名词突然就通了。所以我建议所有从零起步的人别把理论学习放在动手之前两者要并行但动手永远优先。那 AI 工程到底在做什么我现在的理解是把一个大模型或者多个大模型接入真实的业务场景让它在约束条件下稳定、可控、可评估地完成特定任务。这里面涉及提示词设计、上下文组织、工具调用、数据回流、效果评测、成本优化、错误兜底是一整套系统工程而不仅仅是“发个请求拿个结果”。这也是我想写这篇文章的原因。市面上的教程要么太偏理论上来就是注意力机制要么太偏工具教你怎么装框架却不说为什么。我想用自己从零到一的完整经历把 AI 工程这个命题拆开讲清楚到底该学什么、怎么练、坑在哪。这篇文章适合那些已经决定投身 AI 应用开发但不清楚第一步该往哪迈的人。1.2 从零起步需要的能力地图我把 AI 工程需要的能力拆成了六块按重要程度和上手顺序排列能力模块具体内容入门难度模型调用理解 API 参数、流式输出、结构化输出、模型选型低提示词设计系统提示词、少样本示例、任务拆解、格式约束低但精通难上下文管理对话历史截断、记忆压缩、知识注入中检索增强RAG切分、向量化、召回、重排、融合中Agent 编排工具定义、多步决策、循环控制、错误恢复中高评测与监控评测集建设、指标设计、回归测试、线上监控高最容易被忽略这六块不是并列的而是层层递进。前三块是地基第四块是多数文档类应用的核心第五块是当前最有想象力的方向第六块则是决定你能不能长期维护一个 AI 产品的关键。我见过太多人花大力气做了一个 Agent却完全答不上来“它比上一个版本好在哪里”这就是没做评测的后果。对零基础的人我的建议是不要一上来就追 Agent、追多智能体协作。先把地基打牢把一次 API 调用做到极致再谈编排。后面我会详细讲我自己的练手路径每一步都附上我踩过的坑和验证过有效的做法你可以直接照着走。2. 我的从零练手路径从第一个 API 调用到能上线的产品雏形2.1 起步动作先把一个接口用熟、用透我给自己定的第一个目标非常朴素只用一个模型接口做出五个不同的小应用。这一阶段我完全不碰框架不用任何大模型应用层封装就用最原始的 HTTP 调用写。原因很简单封装库帮你省掉的代码恰恰是理解原理的最佳教材。从最简单的开始先是一个聊天补全接口。我建议你做这几件事来练手感写一个脚本连续发十条不同风格的请求观察 temperature、max_tokens 这些参数对输出的影响把流式输出改成非流式对比响应时间和体感差异在 system prompt 里放一段很长的背景说明测试模型对指令的遵循程度给自己建一个“变量控制清单”每次只改一个参数记录输出变化。这一步看起来幼稚但价值非常大。很多人在这一步之前就急着上 Agent、上 RAG结果遇到输出不稳定、幻觉百出根本不知道是提示词的问题、参数的问题还是上下文的问题。变量控制的能力是 AI 工程调试的基础功。另外我要推荐一个很实用的习惯从第一天起就用“结构化输出”。让模型返回 JSON而不是自由文本。你可以在 system prompt 里直接声明输出格式再用代码做一层校验解析失败就重试或降级。这会让你的应用稳定性上一个台阶。很多新手直接拿自由文本去解析一个标点符号差异就崩了这都是可以提前避开的。2.2 五个由易到难的练手项目我全部做过一遍我建议的练手项目顺序是这样的每一个都有明确的目的做完之后能力是叠加的第一个做一个人设固定的聊天助手。目的就是练提示词和参数控制。我给助手设计了角色、语气规则、知识边界然后反复测试它会不会“出戏”。这个项目让我真正理解了 system prompt 的约束力。测试过程中我发现光说“你是客服”是不够的必须把“遇到无法回答的问题时如何回应”也写清楚否则模型会硬答。第二个做一个文档问答工具。把几本书切成片段做向量检索把命中片段塞进上下文让模型基于片段回答。这个项目练的是 RAG 的完整链路切分策略、检索质量、答案组织都会暴露出来。做完之后你会对“上下文才是关键”有切身体会——模型表现得聪明还是笨很大程度上取决于你塞给它的材料质量。第三个做一个信息抽取管线。给模型一堆非结构化的邮件或聊天记录让它输出结构化的字段比如客户名称、诉求类型、紧急程度。这个项目练的是结构化输出和错误处理你会开始认真设计 JSON schema 和校验逻辑也会发现少样本示例对输出质量的影响有多大。第四个做一个带工具调用的 Agent。让模型能查天气、能算数学、能查数据库核心是把“模型决策调哪个工具”这件事做对。这个项目练的是函数调用和循环控制难度上一个台阶但做完之后对 Agent 的理解会完全不同。第五个给自己前面做的某个应用写一套评测脚本。定义一组测试用例每次改完代码自动跑一遍对比输出质量。这个项目练的是评估思维是 AI 工程里最值钱也最少人愿意做的事。我做完这五个项目大概花了两个月每天晚上两三个小时。进度不算快但每一步都有实打实的产出。关键是每个项目都要留文档记录你改了什么、效果如何、为什么这样改这份记录后来成了我自己的“经验库”。2.3 从第一天起就建评测集这是很多人漏掉的关键我在做完第一个聊天助手的时候就发现一个问题每次改完提示词感觉输出“好像更好了一些”但过两天又觉得不对劲说不清哪里退步了。后来我才意识到没有评测集的改进全是幻觉。评测集的建设其实不复杂拿 30 到 50 个有代表性的输入为每个输入写好期望的输出标准然后每次改动之后跑一遍人工打分。打分维度可以很简单比如准确性、完整性、格式符合度每项 1 到 5 分。不需要什么高级工具一个表格就够。等你有了一批真实用户输入之后评测集要持续扩充把线上出过问题的样本都加进去。这就是回归测试的思路和传统软件开发里的单元测试是一个道理。我后来把所有线上翻车案例都沉淀成了评测条目每次新版本上线前先跑评测集低于某个分数就不允许发布。这个机制帮我避免了很多次灾难性上线。3. 核心技能拆开看提示词、Agent 与 RAG 的真实用法3.1 提示词工程本质是结构化沟通不是咒语网上关于提示词的文章很多但大部分把这件事讲玄了。我的理解非常朴素提示词工程就是把你对任务的全部要求用模型最容易遵循的方式表达出来。它像跟一个极其聪明但容易误解你意图的新同事沟通关键是消除歧义。我自己的提示词结构一般是这样先定义角色和任务目标再给出约束条件和输出格式接着给少量高质量示例最后说明边界情况怎么处理。这套结构几乎适用于所有任务。示例的作用往往被低估同一段指令配不配示例效果能差出一大截。还有一个容易被忽略的点提示词也要版本化。我见过很多团队提示词直接写在代码里每次改动都靠复制粘贴保存根本说不清线上跑的是哪一版。我的习惯是把提示词当作独立的版本化资产和代码一起提交每次改动都带着变更说明。这样当线上效果波动时你能快速定位是代码问题还是提示词问题。我强烈建议你把提示词当代码来管理。写一段好的提示词有时比写一段代码更费力它的调试过程也更依赖“实验和观察”。没有版本控制你就是在用感觉做工程。3.2 Agent 设计把大模型装进决策循环Agent 是当前 AI 工程最热的方向但也是最容易被过度包装的概念。剥掉所有花哨的说法Agent 的本质就是一个循环模型根据当前状态决定下一步动作执行动作观察结果再决定下一步直到任务完成或者达到某个终止条件。我做的第一个 Agent 特别简单只挂了两个工具一个查询接口一个计算函数。模型每轮输出两个东西一是思考过程二是要调用的工具和参数。我拿到之后执行工具把结果拼回对话历史继续下一轮。这个循环看起来简单但真正写起来全是细节工具返回结果太长怎么办、模型连续调用同一个工具怎么办、某一步调用失败要不要重试、最多跑多少轮就强制停止。这些都是我在实际写代码时反复调整过的控制点。举个例子工具返回结果我一开始全量塞回上下文一次数据库查询返回几百行记录模型直接蒙了决策质量急剧下降。后来我改成只返回前十条加一个总数字段效果立刻稳定。Agent 的工程含量就在这里——不是模型有多聪明而是你为模型设计的环境有多清晰。还有一个原则永远设最大轮数。没有轮数上限的 Agent 就是一颗定时炸弹账单和延迟都会失控。我建议所有做 Agent 的人先把“最大轮数、超时、重试策略、异常兜底”这四个参数想清楚再谈智能不智能。3.3 RAG 的适用边界与落地细节RAG 是让大模型基于私有知识回答问题的标准方案但很多人对它有不切实际的期待。RAG 不是万能的它解决的是“模型不知道的信息怎么让它知道”的问题而且效果上限取决于检索质量不是模型能力。切分策略是第一个坑。PDF 按固定字数硬切经常把一句话从中间劈开检索召回质量直线下降。我后来改用按标题层级和段落边界切分每个片段尽量保持语义完整重叠区间控制在少量字符效果立刻改善。第二个坑是检索只做向量相似度。向量检索对同义改写很友好但对精确关键词匹配反而敏感度不足最好的做法是向量检索和关键词检索做混合召回再用重排模型把结果重新排序。还有一点我必须强调RAG 的答案必须可溯源。在输出里附上引用的原文片段让用户能自己核对。这不仅是产品体验问题也是信任问题。我做文档问答工具时强制要求每句话都能对应到来源否则视为不合格。这一步让我避开了很多幻觉投诉。适用边界方面如果知识库更新频率很高、内容很短、或者问题对时效性极其敏感RAG 可能要配合其他机制。RAG 适合的是“静态知识为主、答案需要依据”的场景。别指望它解决一切问题。4. 从零到一踩过的五个大坑每一个都让我返过工4.1 坑一把模型当成数据库用我最早的文档问答工具为了实现快直接把用户的问题抛给模型指望它凭“记忆”回答。结果模型一本正经地给出了好几段看起来毫无破绽、实际全是编造的内容。那一刻我意识到模型是概率性的文本生成器不是数据库。数据库里没有的记录会明确说不存在模型没有的记录会帮你编一个。这个坑的解法就是引入 RAG并且强制答案溯源。同时我学到一个经验永远不要让模型回答它没有足够上下文支撑的问题。当检索结果为空或者相关性太低时直接告诉用户“没有找到相关资料”而不是让模型硬答。这个经验后来扩展成了我所有项目的通用原则不确定就承认不确定。这比让模型硬编一个答案体面得多也安全得多。4.2 坑二技术栈先堆满需求还没想清楚这是我早期最蠢的一次返工。我当时想做一个通用问答平台还没想清楚用户是谁、要解决什么问题就先把向量数据库、容器化部署、监控告警全部上了。结果光环境搭建就花了两周核心功能一个字没写。后来我复盘问题出在把技术选型当成了项目进度。正确顺序应该是先用最笨的方式把核心流程跑通验证需求真实存在再逐步替换掉不合适的组件。一个只有几十个用户的产品根本不需要一开始就上分布式向量库。轻量级方案完全够用。从那以后我给自己定了一条规矩任何组件要在“没有它已经跑不动了”的时候才引入。这条规矩让我少做了大量无用功。4.3 坑三没有评测就上线改来改去全凭感觉这个坑我前面提过但值得单独再说一次。没有评测集的迭代本质上是随机游走。你今天把提示词改了一版觉得输出变好了发布上线三天后用户反馈变差了你又改回去来回折腾浪费的不仅是时间还有用户的耐心。我现在对任何 AI 功能的改动都坚持三条铁律先写评测用例再改代码或提示词最后跑评测集对比分数。分数没有提升就回滚。这套流程让我从“感觉主义”变成了“证据主义”迭代质量和速度反而都上去了。可能有人觉得 30 到 50 条评测用例太少代表性不够。但起步阶段哪怕只有十条用例也比零条强得多。评测集的价值在于“可对比”不在于“完备”。你先有一个基线再逐步扩充这比追求一步到位实际得多。4.4 坑四上下文管理与成本控制双双失控AI 应用的账单是随着上下文膨胀线性增长的。我做过一个多轮对话产品早期为了保留完整对话历史每一轮都把从头到当前的全部消息发给模型。对话超过二十轮时单次请求的 token 数已经翻了好几倍响应延迟和成本一起飙升。解法是分层管理上下文最近的对话完整保留较早的对话做摘要压缩摘要再超长就继续摘要。还有一个经验是给每个请求设置 token 上限超了就自动触发压缩策略。成本控制不是上线后才考虑的而是一开始就要设计进架构里。我见过很多团队在产品上线后才发现成本失控然后急急忙忙加缓存、加压缩改得手忙脚乱。其实这些在设计阶段花半天就能规划好。上下文管理不是优化项是必选项。4.5 坑五一个人闷头造轮子从零学 AI 工程最大的风险不是技术难而是闭门造车。我有很长一段时间自己闷头搭框架写了大量没人用过的封装。后来我把代码给一个做后端的朋友看他一眼就指出我的错误处理设计有问题——模型输出校验失败时我的代码会崩溃而不是优雅降级。从那以后我养成了一个习惯每完成一个模块就找至少一个人做代码评审或者产品体验。AI 工程里很多问题比如延迟体感、输出质量、边界情况自己测一百遍也发现不了别人用一次就能暴露。找到愿意当“小白鼠”的朋友比任何教程都重要。如果你身边没有懂技术的朋友那就去社区、去论坛。把你的项目丢出去让陌生人用。他们的反馈可能很糙但每一条都是真实的。这些真实反馈比你自己脑补的完美体验有价值得多。5. 给同样从零开始的你三个月到半年的路线图参考5.1 第一个月练 API 手感打磨提示词基本功第一个月的目标只有一个把一次模型调用做到自己能掌控的程度。这阶段不要碰 Agent不要碰复杂框架。找一个大模型 API写脚本跑通非流式和流式两种模式掌握参数含义然后完成一个带人设的聊天助手。同时开始积累提示词模板什么场景用什么结构整理成自己的文档。第一月底的验收标准是你能在三个不同任务上稳定地让模型输出符合格式要求的结果并且说得清每个参数为什么这样设置。这个月最容易犯的错误是贪多。看到别人做 Agent 很酷就想跳过基本功直接上。我劝你忍一忍地基不牢后面的每一层都会晃。5.2 第二到三个月做带状态的应用开始碰 Agent第二个月做文档问答工具完整走一遍 RAG 的链路。这一步你会把切分、检索、重排、答案组织、溯源全部过一遍对“上下文决定上限”有深刻理解。第三个月做带工具调用的 Agent重点不是功能多而是把循环、轮数限制、错误恢复这些控制逻辑写好。这两个月你会不停地遇到“为什么输出不稳定”的问题。我的建议是把所有不稳定案例记下来归因到提示词、检索、参数或代码形成自己的排查清单。这份清单的价值会随着你的项目越来越多而指数级上升。做文档问答工具时别急着换各种花哨的向量数据库。先把切分和检索调明白你会发现大部分效果问题根本不在数据库层面而在数据准备层面。这个认知能帮你省下一大笔迁移成本。5.3 第四个月起找一个真实场景做给真人用三个月之后你的基本功基本够了这时候最该做的不是继续学新技术而是找一个真实的小场景做一个有真人用户的产品。哪怕是给朋友做一个会议纪要工具给团队做一个知识库问答都行。真实用户会带给你教程里永远学不到的东西真实的数据分布、真实的边界情况、真实的反馈循环。从零开始做这个产品时记得用上前面说的所有经验先建评测集再写代码先跑通核心流程再考虑扩展每次改动都做对比评测。我认为 AI 工程从来不缺技术缺的是把一个 AI 功能做成一个可靠产品的判断力而这种判断力只能从真实项目里长出来。6. 最后几句实在话写到这里我回头看自己从零到一走过的这段路最大的体会是AI 工程的门槛不在数学不在框架而在“愿不愿意用工程的纪律去对待一个本身就不稳定的技术”。我在实际踩坑中形成的几个习惯最后再分享一次永远让模型返还结构化输出永远给生成结果留一个校验层永远先写好评测用例再动手改永远对上下文长度和成本保持敏感永远在发布前找一个人做体验评审。这五条没有一条是高级技巧但每一条都让我少走了很多弯路。如果你也是从零开始别怕慢也别贪多。把一个简单的功能做到可靠比把十个花哨的功能做到半吊子有价值得多。这条路没有捷径但每一步都是实打实的积累。
