1. 从零开始学 AI 工程到底在学什么我把话先说在前头AI 工程不是调个 API 把聊天机器人接上那么简单也不是会写两段 prompt 就算入行。我见过太多人拿着大模型玩了几个月一问到你的系统怎么评估效果模型输出不稳定的兜底方案是什么立刻卡壳。这个项目标题里的from scratch三个字才是真正的分水岭——它意味着你要把从数据准备、模型选型、prompt 设计、Agent 编排、效果评估到上线运维的整条链路都亲手过一遍而不是只停留在能跑通 demo的层面。我得先给这篇文章定个位。那些刚接触 AI 工程、想系统入门的人看这篇最合适已经在做 AI 应用开发、但觉得自己的方案总在能跑和好用之间差一口气的人也能从里面找到一些查漏补缺的点。这篇文章不跟你谈那种玄乎的AI 思维我就讲我踩过的坑、验证过的做法、以及每一步背后到底为什么要这么干。先破一个常见的误解很多人以为 AI 工程的核心是模型于是把大量时间花在追新模型、比参数上。实际上从工程落地角度看模型只是整个系统里替换成本最低的一环。真正决定一个 AI 应用好不好用的是你对问题的拆解能力、数据处理的扎实程度、以及围绕模型搭起来的那层工程骨架。用大白话说模型是发动机但车子能不能跑得稳、坐得舒服看的是底盘和悬挂。另外必须说明从零开始不是让你从线性代数、反向传播开始啃。除非你要做模型训练和底层框架研发否则 90% 的工程实践场景里你把调用逻辑、上下文管理、输出校验、效果评估这些工程问题搞明白就已经能做出非常实用的东西。这篇文章就是按照这条务实路线展开的后面每一节都会回应一个具体的工程环节。2. 动手前的核心拆解需求、边界与方案选型2.1 先把要解决什么问题翻译成模型能处理的任务我见过最典型的失败案例是上来就搞一个大而全的智能助手恨不得一个入口解决所有问题结果做出来什么都干不好。AI 工程的第一步不是选模型而是做需求拆解。你得把用户的原始诉求拆成 AI 能执行的最小任务单元。举个例子。假设你要做一个合同审查助手表面上是一个需求拆开看其实是好几类任务合同要素抽取甲方乙方、金额、日期、风险条款识别违约责任是否失衡、合规性检查是否符合特定法规表述、以及生成修改建议。这些任务对模型的难度、需要的上下文、评判标准都不一样混在一起做你连评估指标都定不清楚。实操中有个很实用的方法把需求写成输入是什么、输出是什么、怎么判定对错三行描述。如果某个需求你写不出怎么判定对错说明它还没拆到位。比如写一段吸引人的文案判定标准模糊你得细化成根据产品卖点生成 50 字以内、包含行动号召的推广文案这样才具备可评估性。我把需求拆解之后通常还会做一件事给每个子任务打分维度是频率、价值、技术可行性。频率高、价值大、用现有模型能解决的优先做。那些又难又低频的需求果断砍掉或者降级为人工兜底。这个取舍过程就是 AI 工程和 AI 玩具的分界线。2.2 模型选型的三个真实判断标准选模型这件事我不建议跟着热度走。我自己内部有一套判断标准按优先级排列稳定性、成本、可控性最后才是效果上限。稳定性指的是同一个输入在不同时间、不同并发下输出质量是否波动。公共 API 偶尔抽风是常态你要考虑的是你的业务能不能承受这种波动如果不能就得在设计上加一层重试、降级和缓存机制。成本不只是 token 费用还包括开发成本、延迟成本、以及模型迭代后你需要重新回归测试的成本。可控性则关系到你能不能对输出做结构化约束这直接影响下游解析的复杂度。具体到技术指标有几个我实际用下来觉得靠谱的参考维度。上下文长度不是越长越好长上下文意味着更高的成本和更慢的速度你要算的其实是业务单次请求真正需要多少上下文。工具调用能力function calling要看它能不能稳定输出符合 schema 的结构化参数。指令遵循能力怎么测你别看榜单自己拿 30 条真实业务 prompt 跑一遍对比各家输出的差异性这个比任何 benchmark 都可信。实操建议是准备一个固定的评测集里面放 20 到 50 条覆盖你主要场景的真实输入每次换模型或者换 prompt 都在这个集上跑用统一的标准打分。这样你选模型就有数据支撑而不是感觉这个回答更聪明。2.3 为什么说成本规划要从第一行代码前开始成本这件事最好从项目启动那天就纳入考量。很多人做完 prototype 才发现每月的 API 账单高得离谱然后开始慌乱地改方案。AI 应用的成本大头往往不在 token 单价而在你的设计是否浪费。我总结过几个常见的成本黑洞。第一个是上下文冗余每次请求都塞进大量不相关的历史记录却还美其名曰让模型更懂用户。第二个是无效重试模型偶尔输出不符合格式要求代码直接无脑重试三次等于把随机波动放大了三倍成本。第三个是过度设计明明用不上也要上多 Agent 协作每个 Agent 都是一次独立调用。正确的成本思维是按请求价值分配资源。高频低价值的请求用便宜的小模型低频高价值的请求才启用大模型。具体做法是在入口做意图分类简单任务走轻量路径复杂任务才走完整链路。这套思路放到今天依然非常管用而且和技术栈无关纯粹是工程取舍。3. Prompt 工程不是写提示词是设计交互协议3.1 结构化 Prompt 的底层逻辑很多教程教你 prompt 要清晰、具体、给例子这话没错但没说到根子上。我的理解是prompt 的本质是你和模型之间的接口协议它跟 HTTP 协议没本质区别都需要定义请求格式、约束响应格式、约定错误处理方式。一套好的生产级 prompt应该包含这些层次角色与目标定义、任务输入格式、输出格式约束最好用 JSON Schema 或示例强约束、边界条件说明什么情况该拒绝回答、以及少样本示例。注意示例不是随便放的每个示例都要对应一类典型边界情况比如放一个用户输入信息不足时该如何回应的例子比放三个正常例子有用得多。关于角色设定我多说一句。给模型设定角色通常能明显提升输出的风格一致性和专业感。有一个细节容易被忽略角色设定最好同时说明不该做什么。比如你设定你是一名资深的专利工程师光有这个不够你还要补一句不得编造专利法律条款不确定时应明确说明需要人工核实。模型对齐的是你给的整个上下文负面约束和正面指令同等重要。3.2 让模型输出能直接喂给程序的内容工业级应用和聊天玩具最大的区别之一就是你是否能让模型输出结构化数据。我强烈建议凡是需要程序继续处理的内容都用 JSON 输出并给出严格的 schema 约束。实际上多数主流模型的 JSON 输出能力已经足够稳定但前提是你必须在 prompt 里给到具体格式说明最好是一个完整的示例。单纯说请输出 JSON是不够的模型不知道你的 JSON 长什么样。我的模板一般是请以 JSON 格式输出结果严格遵循以下结构 { summary: 一句话总结, items: [ {name: 项目名, risk_level: high|medium|low, reason: 判定理由} ] } 注意不要输出任何 JSON 以外的内容包括 Markdown 代码块标记。这里有个反直觉的经验你在 prompt 里写不要输出代码块标记有时候反而会诱导模型输出代码块。更可靠的方案是拿到输出后做一次后处理或者用支持结构化输出的 API 参数来约束不少平台的函数调用机制就支持。工程上永远默认模型输出不可 100% 信任该加解析容错就得加。3.3 少样本示例的最佳实践别停留在给例子少样本学习few-shot是 prompt 工程里效果最稳定的技巧但很多人用得不对。关键不在于例子的数量而在于每个例子是否覆盖了独立的困难模式。我自己整理 prompt 示例时会遵循三个原则。第一示例要展示推理过程而不只是输入输出对。第二每个示例最好对应一个容易出错的反面情况让模型见过坑。第三示例的顺序有讲究通常把最典型的放在最前面把最特殊的放最后实验表明这个顺序会影响效果。以信息抽取为例你放三个正常抽取成功的例子不如放一个含混淆信息的例子。一个文本里既有甲方XX科技有限公司又有乙方联系人张三模型容易把张三抽成甲方。你在示例里专门放一条这种并标注正确结果是甲方为空模型学到这个模式后处理类似情况的准确率会明显提升。4. Agent 与工具调用让模型从会聊天变成能干活4.1 Agent 到底是什么以及为什么要引入它说实话Agent 这个名词被炒得神乎其神但工程视角下它就是一个循环模型根据当前任务状态决定调用什么工具拿到工具结果后更新状态再决定下一步动作。它的本质是把任务的推理过程从一次调用变成多步决策。什么时候需要上 Agent我给自己定了一个判断标准如果任务可以分解成明确的、顺序固定的步骤那就用普通程序串联不要上 Agent只有当步骤顺序不固定、需要根据中间结果动态决策时才考虑让模型来编排。前者是流程后者才是智能。很多失败项目的问题不是模型不够聪明而是把能写死的流程交给了不会死记硬背的模型。举个例子。你要做一个文档调研助手输入一个主题它需要搜索、读文档、总结、再搜索、再补充。每一步搜什么取决于上一步读到了什么这种动态性适合 Agent。反过来如果只是读文档、总结、导出固定三步那就用代码写死调用链简单、稳定、便宜。4.2 工具调用的工程实现细节现在平台基本都支持结构化工具调用工程上你需要做两件事定义工具 schema以及处理模型返回的工具调用请求。定义 schema 时我踩过不少坑。第一个坑是描述写得含糊。工具的 description 会直接影响模型何时调用、以及如何传参所以描述里要写清楚什么场景下调用参数含义是什么有什么约束。第二个坑是参数类型不够严格能枚举的尽量枚举比如搜索工具的搜索类型字段你用枚举就比自由文本稳定得多。拿到模型返回的 tool_call 后常规的循环是把工具执行结果拼回上下文让模型基于结果继续生成。这个环节有个常被忽略的点——工具执行结果要经过提炼再放回上下文而不是把原始返回全塞进去。搜索可能返回 10 条结果但只有 2 条是有效的你让模型自己挑既浪费 token 又影响判断。最稳妥的做法是写一个提炼函数把原始结果压缩成要点再交给模型。4.3 多 Agent 协作一个需要谨慎使用的模式我公众号后台经常有人问多个 Agent 协作是不是更强大这里我泼点冷水多 Agent 的收益往往被高估而复杂度被低估了。在我接触的项目里涉及多 Agent这个模块最常见的结局是在演示时很唬人一上生产就问题不断——因为每个 Agent 都可能出错Agent 之间的信息传递又会放大错误。什么时候我会认真考虑多 Agent首先是多个角色确实需要不同的系统提示和工具集比如一个负责检索的 Agent 和一个负责写作的 Agent它们的上下文需求完全不同。其次是任务天然有多轮人类参与的节点。除此以外我更推荐单 Agent 显式工具序列让程序控制流程模型负责每个节点的决策。这套组合拳的总体稳定性通常优于自由编排的多 Agent。如果真的要做多 Agent 协作我建议严格遵守一条设计原则Agent 之间的通信必须通过结构化消息而不是自然语言文本。你可以定义 message 有明确的 type 和 payload比如{type: retrieval_result, payload: [...]}。如果用一段自然语言把检索结果转述给下游 Agent信息的丢失和曲解会让你追 bug 追到怀疑人生。5. 从原型到落地一个可直接复制的完整实践5.1 场景设定与技术选型我拿一个真实做过的项目来走一遍全流程企业内部的技术文档问答助手。用户输入一个问题系统在内部文档库里检索相关内容然后基于检索结果生成答案并且要求答案必须标注引用来源。这个场景很典型因为它同时涉及检索增强生成、输出约束、效果评估和权限管理几乎涵盖了 AI 应用的大部分核心环节。技术路线上我选择了向量数据库 重排序模型 大模型生成的三段式结构。为什么不直接让模型读全量文档成本高、速度慢、而且权限无法控制模型不能只看用户有权限的文档。为什么不用关键词检索而用向量检索因为自然语言提问和文档用词经常对不上比如你问报销流程文档里写的是费用申请向量检索能跨表达方式匹配语义。但纯向量检索也有短板所以后面我会加一个重排序环节。基础设施选型我建议从工具类的底层适配开始。如果有预算优先考虑成熟的托管向量库如果只是本地小规模验证用轻量的向量索引库也够了。存储层面注意元数据设计文档 ID、权限组、更新时间这些字段必须能过滤否则后续做权限控制时会很被动。5.2 完整的落地方案与关键配置检索增强生成RAG的核心链路是这样用户提问 → 改写与意图识别 → 向量检索候选集 → 重排序精排 → 拼接上下文 → 模型生成 → 输出校验。每一步都有可讲的细节。先说文档切分。我验证下来的经验是固定字符数切分的效果通常不如按语义边界切分按标题、段落、句子边界切尽量保持语义完整性。切分的块大小要根据你的检索场景定技术类文档我用 300 到 500 字一块块与块之间保留少量重叠避免把关键信息切散。然后是检索的混合策略。我把关键词检索BM25和向量检索做并集再用重排序模型统一精排。为什么多这一步向量检索对语义相关但用词不同的匹配很强但对精确术语的匹配反而不如关键词两者取并集召回率更稳重排序模型再负责把最相关的排到前面。实测下来加了重排序之后最终答案的引用准确率能提升 15% 到 20%这个提升在关键业务场景里意义不小。生成环节的 prompt 我特别强调引用约束要求模型只基于给定上下文作答并且每句话都要能对应上引用编号。如果模型判断上下文不充分允许它明确回答上下文未提供该信息。这个兜底设计看起来简单实际是减少幻觉最有效的手段之一——因为幻觉的第一来源就是模型想用自己知道的知识来补全答案。5.3 评估体系没有评估就没有优化我在前面反复提评估这个词这里展开说。评估是 AI 工程里最容易被跳过的环节但它恰恰决定了你能走多远。没有评估你就不知道改了一版 prompt 到底是变好了还是变差了。我的做法是建立三层评估。第一层是单元指标针对每个子任务定义自动化的打分规则。抽取类任务可以算字段级准确率分类任务算准确率或 F1。第二层是端到端评估把完整流程输出和标注好的参考答案做对比可以用大模型当裁判让一个中立模型给答案的完整性和准确性打分但要注意裁判模型自身也有偏差需要人工抽检校准。第三层是线上指标比如用户对答案的点赞点踩、答案被复制的次数、以及未找到答案的比例。评估集的建设我有一个独家经验不要只收集正常问题一定要故意加入刁钻问题。比如同一个问题换三种问法、包含错别字的问题、超出范围的问题、需要多文档信息聚合的问题。这些边界样本才是测试系统真实能力的关键。我一般按 60% 正常、40% 边界来配比评估集别觉得边界占比高实际生产里边界问题占比就是这么高。6. 常见问题与排查技巧实录6.1 输出格式不稳定先怀疑 prompt再怀疑模型这是出现频率最高的问题。模型偶尔不按约定的 JSON 输出或者字段名发生变化。我的排查顺序是这样的第一步检查 prompt 里是否给了完整示例特别是输出必须只包含 JSON 本身这类约束有没有写清楚第二步确认是否用了支持 JSON 模式的调用参数第三步在解析层做容错比如用宽松的 JSON 解析库能处理部分格式变异。这里有一个容易掉进去的坑模型输出偶尔会带 Markdown 代码块标记你用正则把它摘掉就行但别把这个逻辑写得太死因为模型偶尔还会输出其他的装饰内容。更稳健的做法是在 prompt 层面约束直接输出原始 JSON不要包裹任何标记同时在代码里做双重保险。6.2 检索结果相关但不准确问题大概率不在模型很多 RAG 项目表现不佳一顿排查发现生成模型没错是检索环节把不相关的内容送了上来。如果你遇到答案引用了不存在的观点这种问题先别甩锅给幻觉多半是检索召回的内容里混了相似但不正确的文档。我的排查方法是逐层验证单独把用户的 Query 拿去跑检索看召回结果本身是否合理。如果召回列表看起来还行说明问题在重排序或生成阶段如果召回列表就歪了那就得调整切分策略或检索方式。另一个常见原因是查询本身太模糊可以加一个查询改写步骤让模型把用户的自然提问改写成更适合检索的若干关键词组合实测这个技巧对检索质量提升非常明显。6.3 成本超标的排查打开日志看 token 流向成本问题在项目上线初期最容易暴露。排查思路也很直接看每个请求的 token 消耗构成。大多数情况下你会发现不是模型太贵而是上下文中塞了太多历史消息和无关工具结果。我把这个问题的应对方案总结成两条。一是上下文瘦身只保留必要的对话记录可以每次把之前的结论压缩成一两句话再传给模型实现滚动摘要。二是缓存相同或高度相似的请求可以直接从缓存取结果不必再次调模型。这里有个关键判断——你可以在入口做语义哈希把相似输入归并到同一组命中缓存就跳过模型调用。实测在问答类场景里缓存命中率能到 20% 到 30%这对成本优化的贡献是非常可观的。6.4 稳定压倒一切超时、限流与降级策略生产环境的 AI 应用和 Demo 最大的区别在于你必须处理大模型服务不可用的情况。我把模型服务不可用分成两种一种是大面积故障另一种是单个请求超时或触发限流。前者靠多供应商冗余后者靠超时控制和优雅降级。超时控制要结合业务场景设置比如用户在等一个即时答案那单次调用最多给它 10 秒超时就返回一个友好的占位结果如果是异步任务可以放宽到 60 秒但要有重试和失败通知。降级策略也要提前设计好模型挂了怎么办至少得有缓存兜底 默认回复两层。我见过很多项目在降级方案上偷懒结果一次上游抖动整个功能瘫痪这个教训非常深刻。7. 最后分享几个我自己的土办法文章写到这儿主体内容讲得差不多了我额外说几个办公室不会写在文档里的小心得。第一个是我一直坚持的慢请求双跑在做大模型输出的单元测试时不要只跑一次就下结论。同一个 prompt 连续跑 5 次看输出的一致性。AI 工程和传统软件工程一个很大的不同是传统代码同样输入输出基本恒定而模型输出天然有随机性。你的系统设计必须接受并处理这种随机性设计目标不是输出永远一样而是输出质量永远在可接受范围内。第二个是关于调试时的最小化原则。很多人调试 AI 应用喜欢从完整流程的开始一路看到结束这样出问题根本定位不到。我的做法是把每一步单独拎出来喂固定输入检查中间产物。检索就用固定的 Query 测生成就用固定的上下文测一步步缩小范围。这个思路跟排查传统 bug 的思路完全一样但很多人一上手 AI 项目就把这些基本功忘了。第三个是关于学习路径的反直觉建议不要急着上最新模型和框架。先把一个模型研究透把 prompt、检索、评估这套基本功打扎实。你会发现一旦你真正理解了模型输出不可控这个底层约束你设计系统的方式会发生根本性变化——你会更早考虑边界条件、更认真地做结构约束、更频繁地做回归测试。这套意识和能力比任何具体的模型和框架都值钱。如果你正在从零开始走这条路我的建议是把每一步都写下来尤其是踩坑记录。AI 工程这个领域的知识更新太快但底层的方法论和踩坑经验是长期有效的。你手头正在解决的问题大概率别人也遇到过——多交流、多分享你会发现自己成长的速度远超闷头苦干。