ai-engineering-from-scratch 这个仓库名我用了快两年。一开始我从后端转过来觉得大模型应用开发不就是调 API、写提示词、然后扔上线么。直到第一个真实项目交付我才发现自己错得离谱模型输出不稳定、上下文塞满后开始失忆、评测全靠肉眼比对、上线第二天成本就超标。这不是一篇教学大纲而是把我从零开始做 AI 工程的完整路径、每一步背后的判断逻辑、以及踩过的坑原原本本写出来。刚入门的朋友能知道该往哪使劲已经在写提示词但卡在评测、部署、成本控制上的工程师也能找到可以直接抄的作业和要绕开的坑。1. 先重新定义“AI 工程”它和普通软件工程差在哪1.1 模型不是代码而是“概率性组件”我在第一个项目里犯的最大错误就是把大模型当成了一段“输入什么就稳定输出什么”的代码。写函数、跑测试、断言结果这是我过去十年做后端养成的肌肉记忆而它在大模型面前完全不适用。后来我才想明白LLM 本质上是一个概率系统。同样的 prompt两次调用可能给出不同的答案稍微改一个词可能从正确变成错误同一个问题换个问法模型的理解就可能跑偏。传统软件工程里我们习惯用单元测试、类型系统、异常处理来保证确定性但这些东西在“概率性组件”面前统统失效了。这就是 AI 工程和普通软件开发最本质的差异你不再是在写“逻辑”而是在设计“系统与一个概率黑盒的协作方式”。你需要考虑的不是“这段代码会怎么执行”而是“模型在什么条件下更可能给出好结果、在什么条件下会崩、崩了怎么办”。这个思维转换是很多资深工程师转型时最难受的地方。1.2 AI 工程的三层结构提示层、应用层、基础设施层我把 AI 工程拆成三层这也是我后来给自己做学习规划和项目复盘时一直用的框架提示层Prompt Engineering指令设计、少样本示例、思维链、输出约束。这是最基础的一层决定了模型发挥能力的上限。应用层RAG、Agent、工作流编排把模型接到业务里让它能检索知识、调用工具、多步推理成为一个真正可用的功能。基础设施层评测 Harness、部署、观测、成本工程让系统可衡量、可上线、可维护。这一层最容易被新手忽略但恰恰是区分“Demo”和“产品”的分水岭。很多人学 AI 工程只盯着第一层热衷收集各种“神仙提示词”结果模型换了一个版本提示词就废了。我的经验是提示层决定下限应用层决定上限基础设施层决定你能不能活到上线。1.3 一个从零开始的典型项目拆解拿一个我最近做的“内部文档问答机器人”举例它完整覆盖了这三层也最能说明“AI 工程到底在干什么”。提示层我写系统提示词规定模型只依据提供的文档回答不知道就说不知道输出格式固定为“结论 引用出处”。应用层接入公司文档库做切片、向量化、检索再把检索结果拼进 prompt也就是标准的 RAG 流程后面用户多了我又加了追问改写功能。基础设施层建了 50 条回归问题集搭了简易评测脚本每次改 prompts 或换模型都要跑一遍上线后记录每次请求的 token 消耗和响应时间。这个项目让我意识到AI 工程师真正干的活不是“玩模型”而是围绕模型的不可靠性构建一套可靠的系统。模型只是一个零件整个系统的稳定性来自零件之外的设计。2. 基础层怎么打提示词工程与上下文管理的实用方法论2.1 提示词工程的四个核心杠杆我自己实践下来提示词工程真正起作用的杠杆就四个其他的花招都是锦上添花甚至添乱。第一个是角色与指令清晰度。别写“帮我分析这段日志”要写“你是一个 SRE 工程师以下是生产环境日志请按时间线梳理异常原因并按影响程度排序”。角色设定不是玄学它是在给模型一个先验的搜索空间让它在正确的知识区域里找答案。第二个是少样本示例Few-shot。与其费劲描述你要的格式不如直接给 2-3 个“输入-输出”的完整例子。模型对例子的理解远比抽象描述可靠。我做过对比抽象描述要调五六次还不稳换成示例一次就收敛了。第三个是思维链Chain-of-Thought。遇到推理型任务让模型“先把推导过程写出来再给结论”。这个技巧本质上是把模型的中间计算暴露出来既提高了正确率也方便你定位它错在哪一步。我调试 Agent 时靠模型打印的思考过程定位问题比看最终答案高效得多。第四个是输出约束。强制 JSON 结构、限制答案长度、要求“如果不确定就回答不知道”。这些约束能大幅减少解析报错和胡编乱造尤其是在代码生成、结构化抽取这类下游要接自动化处理的场景里。这四个杠杆我直到现在写每个 prompt 之前都会逐条过一遍比收藏一百个模板有用。2.2 上下文窗口是稀缺资源如何设计和压缩上下文窗口是 AI 应用里最容易被浪费的资源也是新手最没感觉的资源。大家总觉得“窗口是 128K我随便用”结果越塞越多模型记住开头忘了结尾响应时间变长成本还翻着倍涨。我的处理原则有三条能不放就不放。先问自己这段信息模型必须知道吗很多固定背景信息应该写进系统提示词而不是每次塞进用户消息。要放就压缩。长文档先做摘要或分段检索只把相关片段放进去这就是 RAG 的雏形。动态裁剪。记录对话历史的总 token 数超阈值时用摘要替换最早的历史而不是简单截断——截断容易把关键信息一刀切掉。我见过一个团队上线前才发现他们的对话历史从不清理用户聊了二十轮之后每次请求要往模型里塞 8000 多 token成本直接翻三倍。上下文管理不是优化项是必修项。你写的每一行 prompt、塞进去的每一段文档都在花真金白银。2.3 模型选型不要一上来就上最强模型很多人默认选最强的大模型理由是“效果最好”。但 AI 工程是成本工程不是效果竞赛。上线之后每一分钱成本都是你的利润页面上每一次卡顿都是你的流失率。我一般按下面的维度做选型维度小模型中模型最强模型推理质量够用但易错大多数场景够用复杂推理更强响应速度快较快复杂任务明显更慢单次成本低中等高适用场景分类、抽取、改写问答、摘要、客服复杂推理、多步 Agent我的经验是先拿最强模型跑通业务逻辑、验证可行性再逐步降级到小模型用评测集确认效果没有明显退化。一个查询分类任务我用小模型就稳定跑到了 97% 的准确率成本只有大模型的十分之一。选型不是一步到位而是持续优化的过程前提是你必须有一套评测体系来告诉你“降级之后到底行不行”。3. 把模型变成产品RAG 与 Agent 的工程化实践3.1 RAG 不是“文档进、答案出”这么简单RAG检索增强生成现在几乎是企业 AI 应用的标配但它绝不是把文档丢进向量数据库、搜到就拼进 prompt 那么轻松。我踩过的坑主要在四个环节每一个都能让结果从“看起来不错”变成“完全不能用”。切片策略。直接在固定长度切会把一个完整知识点切成两半检索时命中的往往是残缺片段模型拿到残缺信息自然只能编。我现在优先按标题、段落、列表等语义边界切长度控制在 300-500 token 左右切片之间保留少量重叠防止边界信息丢失。检索质量。只靠向量相似度不够尤其是专业术语多的场景。向量搜索召回的是“语义相近”而不是“答案正确”这两者差得很远。我会把检索结果过一遍重排序Rerank让更精准的片段排到前面再截取 top-k。没有重排之前我的问答准确率只有 70%加上一个轻量重排模型之后直接到了 88%。引用与溯源。强制模型在输出里标注引用的文档片段编号用户能点进去核对来源。这不仅是体验问题更是可信度问题——没有出处的生成和胡说八道没有区别。更新与失效。文档改版后旧切片还在向量库里模型会一本正经引用过时内容这是最隐蔽的坑。我现在会给切片打版本号和更新时间检索时过滤过期数据。RAG 的复杂度不在模型而在数据工程。谁能把数据切好、管好、检索准谁的 RAG 就赢了一半。3.2 Agent 的本质是“决策循环”如果说 RAG 是给模型“配了资料库”那 Agent 就是给模型“配了工具箱和大脑循环”。我去年开始大量做 Agent 项目最大的认知转变就在这里Agent 不是一个能独立工作的“魔法体”它更像一个需要你精心设计的“决策循环”。这个循环是理解任务 → 拆解计划 → 调用工具 → 观察结果 → 根据反馈修正 → 直到完成。每一次循环都是一次“行动-反思”。模型先行动再看结果发现自己错了再修正计划。这个“反思”环节是整个循环的灵魂。这里最容易犯的错是把 Agent 当成“一个能自动完成一切的框架”给它装上十几个工具就指望它自己干活。实际上Agent 的每一步都可能出错计划拆错、工具参数传错、结果解读错。工程化的关键是把“反思”做扎实。最近看到 DeepSeek 公开的智能体训练新方法核心思路也是在训练模型学会在每个行动节点进行自我评估和计划修正方向跟我的实践体会完全一致Agent 的能力上限很大程度取决于“模型能在多大程度上发现自己做错了”。所以我在项目里宁可少给工具也要把“观察结果 → 判断对错 → 决定下一步”这个闭环跑稳。3.3 多 AI 协作与工作流编排单个 Agent 能力有边界于是就有了“多 AI 协作”。这里说的不是那种“几个模型同时回答然后投票”的炫技玩法而是真正按业务分工编排出来的工作流。我常用的编排模式有三种模式思路典型场景流水线Pipeline任务按固定顺序拆给多个模型先抽取、再总结、再翻译编排-执行Orchestrator-Worker主 Agent 拆任务子 Agent 执行报告生成、多源信息汇总讨论/评审Debate/Critic多个模型互相检查、打分代码审查、文案润色在设计多 AI 工作流时我的原则是“每多一个模型就多一份延迟和成本必须换来可衡量的质量提升”。不是模型越多越好而是每个环节都要能说清楚“非它不可”。我做过一个内容生产工作流用了三个模型一个生成初稿、一个做事实核查、一个改标题和摘要。整体耗时增加了一倍但输出质量从“要改半天”变成“基本能直接用”这个交换是划算的。反过来如果只是让两个模型互相“优化”一段文案效果往往还不如一个模型一次生成成本和延迟却翻倍了。4. 最容易跳过的关键环节Harness Engineering 与 AI 测试开发4.1 为什么常规单元测试在 LLM 应用里失效很多从传统开发转过来的工程师上手 AI 项目的第一反应是写单元测试。我在第一节写过这个思维本身不坏但落地方式必须变。传统单元测试断言的是“返回值等于预期值”而 LLM 的输出是自然语言没有唯一正确答案。你没法断言“模型必须输出两行、每行必须包含某个词”这太脆了稍微换个表达就挂了。所以 AI 应用的测试核心不是断言字符串而是判断“语义上是否正确”。这就需要一套评测基座行业里叫 Harness Engineering。我理解的 Harness Engineering就是用工程手段把“主观、模糊、随机的模型输出”变成“可跑、可量化、可回归的测试结果”。没有这个 Harness你所谓的“效果不错”就永远只是体感不是数据。4.2 搭一个最小可行的评测 Harness不需要一开始就上工业级的评测框架比如那个著名的 lm-evaluation-harness从一个小而实用的脚本开始就行。我的做法是三步第一步准备黄金测试集Golden Set。挑 30-50 条代表真实业务场景的输入每条配一个“正确答案”和评分规则。第二步写一个评测脚本批量跑模型输出。第三步用规则或大模型裁判打分输出评分报告。下面是一个最简化的评测脚本骨架我在项目里写过很多次类似的东西核心思路就这么多import json from llm_client import generate # 封装好的模型调用函数 test_cases json.load(open(golden_set.json)) def score(output, expected): # 简单版检查关键得分点是否出现后续可升级为 LLM 裁判 expected_keys [k.strip() for k in expected.split() if k.strip()] hit sum(1 for k in expected_keys if k in output) return hit / len(expected_keys) results [] for case in test_cases: output generate(case[prompt], temperature0.2) s score(output, case[expected]) results.append({id: case[id], score: s, output: output}) failures [r for r in results if r[score] 0.8] print(f通过率: {(len(results)-len(failures)) / len(results):.1%})这个脚本虽然简陋但已经能帮你做最关键的一件事回归。以后每次改系统提示词、换模型、加新功能都跑一遍分数掉了立刻知道而不是靠“感觉好像还行”。我在没有这套东西之前调提示词全靠玄学有了它之后每一次改动都有数据反馈。4.3 完整案例给客服机器人做回归评测以我之前做的客服答疑机器人为例说明一个完整评测流程长什么样这也是“用代码助手实现 Harness 工程”的一个典型过程。我建了 45 条黄金测试集覆盖六类场景常见问题、售后流程、多轮追问、未知问题应该拒绝回答、敏感表达、复杂组合问题。每条都定义好了期望答案的“关键得分点”。写完测试集我没有手动去一条条跑而是让 AI 编程助手类似 CodeBuddy 这类工具帮我生成批量调用脚本和失败样本聚类脚本我负责设计评测逻辑和看报告。第一次全量跑完通过率只有 71%。逐条看失败样本我发现问题出在系统提示词太短模型经常凭自己的知识回答而不是基于知识库。我把系统提示词改成“必须引用知识库文档编号不能回答知识库之外的内容”同时给每条输出加了解析校验第二次通过率到了 89%。再往后我让代码助手批量生成失败样本的聚类分析脚本快速定位剩余 11% 的失败集中在“多轮追问”上。用户的第二个问题往往是“那怎么退款”这种省略主语的话直接检索知识库什么都搜不到。于是我加了追问改写逻辑把历史用户问题改写成独立问题再检索通过率终于稳定在 95% 左右。整个过程没有靠肉眼一条条看而是靠评测 Harness 一步步量化追出来的。4.4 评测指标怎么定才不骗自己定义指标是 Harness Engineering 里最考验判断力的部分。我常用的指标矩阵如下指标说明怎么测回答准确率关键信息是否命中关键得分点匹配或 LLM 裁判忠实度Faithfulness是否忠实于提供的资料有没有编造检查引用是否有对应来源拒答率对超出范围的问题是否拒绝规则判断是否存在“不知道”类输出业务达成率用户的问题是否被实际解决人工抽检 业务转化数据成本与延迟每次请求的 token 和耗时服务端日志统计我只提醒一点不要迷信“LLM 当裁判”。大模型自己也有偏好和误判同一个输出换个评分 prompt 分数可能就差很多。我会让裁判模型输出评分理由再抽 20% 人工复核确保裁判是稳定的。还有评测指标是会“骗人”的单一指标变好往往意味着另一个指标在悄悄变差。比如你把拒答率调高了准确率可能就掉了因为部分原本能答的问题也被拒了。所以要组合着看而不是追求某一个分数好看。5. 从原型到上线模型部署与成本工程5.1 API 调用和自部署的取舍很多项目在原型阶段用大模型厂商的 API到了上线前就开始纠结要不要私有化部署。这是个现实问题我的判断维度很简单取舍因素走 API自部署数据合规要求取决于厂商条款数据不出内网单量规模前期划算量大后贵前期投入高量大后边际成本低技术团队能力几乎零门槛要会模型服务、GPU 运维版本迭代厂商自动更新自己升级模型、自己回归我的建议是日请求量没到几万级别之前别急着自部署先把业务跑通、把评测体系建好。自部署的坑不在“把模型跑起来”而在“把模型长期稳定地跑好”GPU 运维、显存管理、模型版本切换每一样都能消耗掉一个全栈工程师的所有精力。等到确实需要自部署时再考虑量化、批处理这些优化手段一步到位反而容易把自己搭进去。5.2 部署链路里的关键参数如果你决定把模型部署到生产环境有几个参数和配置是最容易被忽略的温度temperature和采样参数。绝大多数业务场景应该把 temperature 调低比如 0.1-0.3减少随机性。只有创意生成才往上调。我见过很多团队上线时忘记改默认值导致同一个问题每次答案都不一样用户体验极差。并发与限流。给模型服务配好并发上限和排队策略否则流量一来响应时间直接飙升。我见过部署后第一次压测就把服务打挂的情况就是因为没设并发闸门。缓存。完全相同的用户提问直接用缓存命中能省一大笔 token 费用。我的经验是热门问题的缓存命中率能到 30% 以上对于客服、FAQ 这类高频重复场景缓存就是最便宜的优化手段。批量推理。离线任务用批量接口成本比实时推理低不少。比如日报总结、批量文本分类完全不需要实时返回用批量模式能省下可观的费用。5.3 上线后盯哪些指标模型上线不是终点是监控的开始。我每次上线都会同时盯五类指标每请求成本token 消耗 × 单价、响应延迟P50 和 P95 要分开看P50 平滑、P95 卡脖子、错误率超时、限流、解析失败、无效输出率空回复、格式错误、拒绝回答、用户侧反馈投诉、重试、放弃率。有一次我发现无效输出率突然从 2% 涨到 15%排查后才发现是上游文档更新后检索结果质量下降模型拿到了一堆不相关片段开始胡编。如果没有无效输出率这个指标这个问题要等用户大面积投诉才能发现。AI 应用的可观测性核心就是“模型的每一次失败都要能看见、能定位、能追踪回是哪一环变了”。部署这件事代码只是入口监控体系才是真正让你睡得着觉的东西。6. 从零开始的路线图我重新整理的学习与实践顺序6.1 五个阶段的产出物与验收标准最后把方法论落地成一条路线这是我走了弯路之后重新整理的顺序也是我后来带新人时实际在用的。每个阶段都有明确的产出物而不只是“学完了某本书”阶段主要任务产出物验收标准一提示词与模型能力边界3 个以上场景的 Prompt 方案能说清每个 Prompt 的四个杠杆分别起什么作用二端到端小产品一个可公网访问的问答/摘要工具完整走通调用、解析、部署、监控的闭环三RAG 与 Agent一个带知识库的机器人和一个多步 Agent能解释检索切片、重排、反思循环的设计理由四评测 Harness 与测试开发一套可复用的回归评测脚本和指标报告每次改动都有量化数据不再靠“感觉”五部署、成本与监控带缓存、限流、监控告警的生产服务能回答每请求成本、P95 延迟、失败率第一阶段花两周把基础模型的 Prompt 玩熟掌握角色设定、少样本、思维链、输出约束同时搞清楚你常用的模型擅长什么、不擅长什么。第二阶段做一个不超过 1000 行代码的小应用比如个人知识问答或文章摘要工具目标不是做好而是把链路跑通。这一趟走完你对 AI 工程的体感会比读十篇文章都强。6.2 我踩过的最典型的三个坑第一个坑是只收集提示词、不建评测体系。我早期收藏了几百个“效果惊艳”的提示词真正用的时候一半失灵。后来才明白提示词和环境强相关同一个提示词换个模型、换个语境效果可能完全不同。没有评测你分不清是提示词的问题还是模型的问题。第二个坑是一上来就想做 Agent。我第一个 Agent 项目给模型接了六个工具结果它在工具之间来回乱调像喝了酒一样成本一天烧掉几百块。后来我把工具减到两个把每个工具的输入输出约束写死再逐步加回来才稳定下来。Agent 这种复杂形态一定要在有基础提示层和评测体系之后再碰。第三个坑是上线前才想成本和监控。我的一个项目在原型阶段一天成本几块钱上线后用户量一大一天成本直接破千全靠临时抢修。从那以后我把成本模型的估算和监控指标的埋点放到了项目启动阶段而不是上线前。6.3 我的最后一点体会我对“从零开始”的最终理解是不要试图先学完所有东西再动手而是先做一个极小的闭环再在每个环节迭代加深。AI 工程没有捷径但有一条清晰的路——提示词到应用到评测再到部署一层一层往上搭。那些被跳过的环节总有一天会回来找你。如果让我给刚开始的朋友一句最实在的建议那就是第一个项目一定要小小到一周能上线然后老老实实给这个最小项目配上测试集、监控和成本记录。从这个小闭环里长出来的经验和判断力比任何课程和模板都值钱。 AI工程从零到上线：提示词、RAG、评测与部署的完整实践路径
ai-engineering-from-scratch 这个仓库名我用了快两年。一开始我从后端转过来觉得大模型应用开发不就是调 API、写提示词、然后扔上线么。直到第一个真实项目交付我才发现自己错得离谱模型输出不稳定、上下文塞满后开始失忆、评测全靠肉眼比对、上线第二天成本就超标。这不是一篇教学大纲而是把我从零开始做 AI 工程的完整路径、每一步背后的判断逻辑、以及踩过的坑原原本本写出来。刚入门的朋友能知道该往哪使劲已经在写提示词但卡在评测、部署、成本控制上的工程师也能找到可以直接抄的作业和要绕开的坑。1. 先重新定义“AI 工程”它和普通软件工程差在哪1.1 模型不是代码而是“概率性组件”我在第一个项目里犯的最大错误就是把大模型当成了一段“输入什么就稳定输出什么”的代码。写函数、跑测试、断言结果这是我过去十年做后端养成的肌肉记忆而它在大模型面前完全不适用。后来我才想明白LLM 本质上是一个概率系统。同样的 prompt两次调用可能给出不同的答案稍微改一个词可能从正确变成错误同一个问题换个问法模型的理解就可能跑偏。传统软件工程里我们习惯用单元测试、类型系统、异常处理来保证确定性但这些东西在“概率性组件”面前统统失效了。这就是 AI 工程和普通软件开发最本质的差异你不再是在写“逻辑”而是在设计“系统与一个概率黑盒的协作方式”。你需要考虑的不是“这段代码会怎么执行”而是“模型在什么条件下更可能给出好结果、在什么条件下会崩、崩了怎么办”。这个思维转换是很多资深工程师转型时最难受的地方。1.2 AI 工程的三层结构提示层、应用层、基础设施层我把 AI 工程拆成三层这也是我后来给自己做学习规划和项目复盘时一直用的框架提示层Prompt Engineering指令设计、少样本示例、思维链、输出约束。这是最基础的一层决定了模型发挥能力的上限。应用层RAG、Agent、工作流编排把模型接到业务里让它能检索知识、调用工具、多步推理成为一个真正可用的功能。基础设施层评测 Harness、部署、观测、成本工程让系统可衡量、可上线、可维护。这一层最容易被新手忽略但恰恰是区分“Demo”和“产品”的分水岭。很多人学 AI 工程只盯着第一层热衷收集各种“神仙提示词”结果模型换了一个版本提示词就废了。我的经验是提示层决定下限应用层决定上限基础设施层决定你能不能活到上线。1.3 一个从零开始的典型项目拆解拿一个我最近做的“内部文档问答机器人”举例它完整覆盖了这三层也最能说明“AI 工程到底在干什么”。提示层我写系统提示词规定模型只依据提供的文档回答不知道就说不知道输出格式固定为“结论 引用出处”。应用层接入公司文档库做切片、向量化、检索再把检索结果拼进 prompt也就是标准的 RAG 流程后面用户多了我又加了追问改写功能。基础设施层建了 50 条回归问题集搭了简易评测脚本每次改 prompts 或换模型都要跑一遍上线后记录每次请求的 token 消耗和响应时间。这个项目让我意识到AI 工程师真正干的活不是“玩模型”而是围绕模型的不可靠性构建一套可靠的系统。模型只是一个零件整个系统的稳定性来自零件之外的设计。2. 基础层怎么打提示词工程与上下文管理的实用方法论2.1 提示词工程的四个核心杠杆我自己实践下来提示词工程真正起作用的杠杆就四个其他的花招都是锦上添花甚至添乱。第一个是角色与指令清晰度。别写“帮我分析这段日志”要写“你是一个 SRE 工程师以下是生产环境日志请按时间线梳理异常原因并按影响程度排序”。角色设定不是玄学它是在给模型一个先验的搜索空间让它在正确的知识区域里找答案。第二个是少样本示例Few-shot。与其费劲描述你要的格式不如直接给 2-3 个“输入-输出”的完整例子。模型对例子的理解远比抽象描述可靠。我做过对比抽象描述要调五六次还不稳换成示例一次就收敛了。第三个是思维链Chain-of-Thought。遇到推理型任务让模型“先把推导过程写出来再给结论”。这个技巧本质上是把模型的中间计算暴露出来既提高了正确率也方便你定位它错在哪一步。我调试 Agent 时靠模型打印的思考过程定位问题比看最终答案高效得多。第四个是输出约束。强制 JSON 结构、限制答案长度、要求“如果不确定就回答不知道”。这些约束能大幅减少解析报错和胡编乱造尤其是在代码生成、结构化抽取这类下游要接自动化处理的场景里。这四个杠杆我直到现在写每个 prompt 之前都会逐条过一遍比收藏一百个模板有用。2.2 上下文窗口是稀缺资源如何设计和压缩上下文窗口是 AI 应用里最容易被浪费的资源也是新手最没感觉的资源。大家总觉得“窗口是 128K我随便用”结果越塞越多模型记住开头忘了结尾响应时间变长成本还翻着倍涨。我的处理原则有三条能不放就不放。先问自己这段信息模型必须知道吗很多固定背景信息应该写进系统提示词而不是每次塞进用户消息。要放就压缩。长文档先做摘要或分段检索只把相关片段放进去这就是 RAG 的雏形。动态裁剪。记录对话历史的总 token 数超阈值时用摘要替换最早的历史而不是简单截断——截断容易把关键信息一刀切掉。我见过一个团队上线前才发现他们的对话历史从不清理用户聊了二十轮之后每次请求要往模型里塞 8000 多 token成本直接翻三倍。上下文管理不是优化项是必修项。你写的每一行 prompt、塞进去的每一段文档都在花真金白银。2.3 模型选型不要一上来就上最强模型很多人默认选最强的大模型理由是“效果最好”。但 AI 工程是成本工程不是效果竞赛。上线之后每一分钱成本都是你的利润页面上每一次卡顿都是你的流失率。我一般按下面的维度做选型维度小模型中模型最强模型推理质量够用但易错大多数场景够用复杂推理更强响应速度快较快复杂任务明显更慢单次成本低中等高适用场景分类、抽取、改写问答、摘要、客服复杂推理、多步 Agent我的经验是先拿最强模型跑通业务逻辑、验证可行性再逐步降级到小模型用评测集确认效果没有明显退化。一个查询分类任务我用小模型就稳定跑到了 97% 的准确率成本只有大模型的十分之一。选型不是一步到位而是持续优化的过程前提是你必须有一套评测体系来告诉你“降级之后到底行不行”。3. 把模型变成产品RAG 与 Agent 的工程化实践3.1 RAG 不是“文档进、答案出”这么简单RAG检索增强生成现在几乎是企业 AI 应用的标配但它绝不是把文档丢进向量数据库、搜到就拼进 prompt 那么轻松。我踩过的坑主要在四个环节每一个都能让结果从“看起来不错”变成“完全不能用”。切片策略。直接在固定长度切会把一个完整知识点切成两半检索时命中的往往是残缺片段模型拿到残缺信息自然只能编。我现在优先按标题、段落、列表等语义边界切长度控制在 300-500 token 左右切片之间保留少量重叠防止边界信息丢失。检索质量。只靠向量相似度不够尤其是专业术语多的场景。向量搜索召回的是“语义相近”而不是“答案正确”这两者差得很远。我会把检索结果过一遍重排序Rerank让更精准的片段排到前面再截取 top-k。没有重排之前我的问答准确率只有 70%加上一个轻量重排模型之后直接到了 88%。引用与溯源。强制模型在输出里标注引用的文档片段编号用户能点进去核对来源。这不仅是体验问题更是可信度问题——没有出处的生成和胡说八道没有区别。更新与失效。文档改版后旧切片还在向量库里模型会一本正经引用过时内容这是最隐蔽的坑。我现在会给切片打版本号和更新时间检索时过滤过期数据。RAG 的复杂度不在模型而在数据工程。谁能把数据切好、管好、检索准谁的 RAG 就赢了一半。3.2 Agent 的本质是“决策循环”如果说 RAG 是给模型“配了资料库”那 Agent 就是给模型“配了工具箱和大脑循环”。我去年开始大量做 Agent 项目最大的认知转变就在这里Agent 不是一个能独立工作的“魔法体”它更像一个需要你精心设计的“决策循环”。这个循环是理解任务 → 拆解计划 → 调用工具 → 观察结果 → 根据反馈修正 → 直到完成。每一次循环都是一次“行动-反思”。模型先行动再看结果发现自己错了再修正计划。这个“反思”环节是整个循环的灵魂。这里最容易犯的错是把 Agent 当成“一个能自动完成一切的框架”给它装上十几个工具就指望它自己干活。实际上Agent 的每一步都可能出错计划拆错、工具参数传错、结果解读错。工程化的关键是把“反思”做扎实。最近看到 DeepSeek 公开的智能体训练新方法核心思路也是在训练模型学会在每个行动节点进行自我评估和计划修正方向跟我的实践体会完全一致Agent 的能力上限很大程度取决于“模型能在多大程度上发现自己做错了”。所以我在项目里宁可少给工具也要把“观察结果 → 判断对错 → 决定下一步”这个闭环跑稳。3.3 多 AI 协作与工作流编排单个 Agent 能力有边界于是就有了“多 AI 协作”。这里说的不是那种“几个模型同时回答然后投票”的炫技玩法而是真正按业务分工编排出来的工作流。我常用的编排模式有三种模式思路典型场景流水线Pipeline任务按固定顺序拆给多个模型先抽取、再总结、再翻译编排-执行Orchestrator-Worker主 Agent 拆任务子 Agent 执行报告生成、多源信息汇总讨论/评审Debate/Critic多个模型互相检查、打分代码审查、文案润色在设计多 AI 工作流时我的原则是“每多一个模型就多一份延迟和成本必须换来可衡量的质量提升”。不是模型越多越好而是每个环节都要能说清楚“非它不可”。我做过一个内容生产工作流用了三个模型一个生成初稿、一个做事实核查、一个改标题和摘要。整体耗时增加了一倍但输出质量从“要改半天”变成“基本能直接用”这个交换是划算的。反过来如果只是让两个模型互相“优化”一段文案效果往往还不如一个模型一次生成成本和延迟却翻倍了。4. 最容易跳过的关键环节Harness Engineering 与 AI 测试开发4.1 为什么常规单元测试在 LLM 应用里失效很多从传统开发转过来的工程师上手 AI 项目的第一反应是写单元测试。我在第一节写过这个思维本身不坏但落地方式必须变。传统单元测试断言的是“返回值等于预期值”而 LLM 的输出是自然语言没有唯一正确答案。你没法断言“模型必须输出两行、每行必须包含某个词”这太脆了稍微换个表达就挂了。所以 AI 应用的测试核心不是断言字符串而是判断“语义上是否正确”。这就需要一套评测基座行业里叫 Harness Engineering。我理解的 Harness Engineering就是用工程手段把“主观、模糊、随机的模型输出”变成“可跑、可量化、可回归的测试结果”。没有这个 Harness你所谓的“效果不错”就永远只是体感不是数据。4.2 搭一个最小可行的评测 Harness不需要一开始就上工业级的评测框架比如那个著名的 lm-evaluation-harness从一个小而实用的脚本开始就行。我的做法是三步第一步准备黄金测试集Golden Set。挑 30-50 条代表真实业务场景的输入每条配一个“正确答案”和评分规则。第二步写一个评测脚本批量跑模型输出。第三步用规则或大模型裁判打分输出评分报告。下面是一个最简化的评测脚本骨架我在项目里写过很多次类似的东西核心思路就这么多import json from llm_client import generate # 封装好的模型调用函数 test_cases json.load(open(golden_set.json)) def score(output, expected): # 简单版检查关键得分点是否出现后续可升级为 LLM 裁判 expected_keys [k.strip() for k in expected.split() if k.strip()] hit sum(1 for k in expected_keys if k in output) return hit / len(expected_keys) results [] for case in test_cases: output generate(case[prompt], temperature0.2) s score(output, case[expected]) results.append({id: case[id], score: s, output: output}) failures [r for r in results if r[score] 0.8] print(f通过率: {(len(results)-len(failures)) / len(results):.1%})这个脚本虽然简陋但已经能帮你做最关键的一件事回归。以后每次改系统提示词、换模型、加新功能都跑一遍分数掉了立刻知道而不是靠“感觉好像还行”。我在没有这套东西之前调提示词全靠玄学有了它之后每一次改动都有数据反馈。4.3 完整案例给客服机器人做回归评测以我之前做的客服答疑机器人为例说明一个完整评测流程长什么样这也是“用代码助手实现 Harness 工程”的一个典型过程。我建了 45 条黄金测试集覆盖六类场景常见问题、售后流程、多轮追问、未知问题应该拒绝回答、敏感表达、复杂组合问题。每条都定义好了期望答案的“关键得分点”。写完测试集我没有手动去一条条跑而是让 AI 编程助手类似 CodeBuddy 这类工具帮我生成批量调用脚本和失败样本聚类脚本我负责设计评测逻辑和看报告。第一次全量跑完通过率只有 71%。逐条看失败样本我发现问题出在系统提示词太短模型经常凭自己的知识回答而不是基于知识库。我把系统提示词改成“必须引用知识库文档编号不能回答知识库之外的内容”同时给每条输出加了解析校验第二次通过率到了 89%。再往后我让代码助手批量生成失败样本的聚类分析脚本快速定位剩余 11% 的失败集中在“多轮追问”上。用户的第二个问题往往是“那怎么退款”这种省略主语的话直接检索知识库什么都搜不到。于是我加了追问改写逻辑把历史用户问题改写成独立问题再检索通过率终于稳定在 95% 左右。整个过程没有靠肉眼一条条看而是靠评测 Harness 一步步量化追出来的。4.4 评测指标怎么定才不骗自己定义指标是 Harness Engineering 里最考验判断力的部分。我常用的指标矩阵如下指标说明怎么测回答准确率关键信息是否命中关键得分点匹配或 LLM 裁判忠实度Faithfulness是否忠实于提供的资料有没有编造检查引用是否有对应来源拒答率对超出范围的问题是否拒绝规则判断是否存在“不知道”类输出业务达成率用户的问题是否被实际解决人工抽检 业务转化数据成本与延迟每次请求的 token 和耗时服务端日志统计我只提醒一点不要迷信“LLM 当裁判”。大模型自己也有偏好和误判同一个输出换个评分 prompt 分数可能就差很多。我会让裁判模型输出评分理由再抽 20% 人工复核确保裁判是稳定的。还有评测指标是会“骗人”的单一指标变好往往意味着另一个指标在悄悄变差。比如你把拒答率调高了准确率可能就掉了因为部分原本能答的问题也被拒了。所以要组合着看而不是追求某一个分数好看。5. 从原型到上线模型部署与成本工程5.1 API 调用和自部署的取舍很多项目在原型阶段用大模型厂商的 API到了上线前就开始纠结要不要私有化部署。这是个现实问题我的判断维度很简单取舍因素走 API自部署数据合规要求取决于厂商条款数据不出内网单量规模前期划算量大后贵前期投入高量大后边际成本低技术团队能力几乎零门槛要会模型服务、GPU 运维版本迭代厂商自动更新自己升级模型、自己回归我的建议是日请求量没到几万级别之前别急着自部署先把业务跑通、把评测体系建好。自部署的坑不在“把模型跑起来”而在“把模型长期稳定地跑好”GPU 运维、显存管理、模型版本切换每一样都能消耗掉一个全栈工程师的所有精力。等到确实需要自部署时再考虑量化、批处理这些优化手段一步到位反而容易把自己搭进去。5.2 部署链路里的关键参数如果你决定把模型部署到生产环境有几个参数和配置是最容易被忽略的温度temperature和采样参数。绝大多数业务场景应该把 temperature 调低比如 0.1-0.3减少随机性。只有创意生成才往上调。我见过很多团队上线时忘记改默认值导致同一个问题每次答案都不一样用户体验极差。并发与限流。给模型服务配好并发上限和排队策略否则流量一来响应时间直接飙升。我见过部署后第一次压测就把服务打挂的情况就是因为没设并发闸门。缓存。完全相同的用户提问直接用缓存命中能省一大笔 token 费用。我的经验是热门问题的缓存命中率能到 30% 以上对于客服、FAQ 这类高频重复场景缓存就是最便宜的优化手段。批量推理。离线任务用批量接口成本比实时推理低不少。比如日报总结、批量文本分类完全不需要实时返回用批量模式能省下可观的费用。5.3 上线后盯哪些指标模型上线不是终点是监控的开始。我每次上线都会同时盯五类指标每请求成本token 消耗 × 单价、响应延迟P50 和 P95 要分开看P50 平滑、P95 卡脖子、错误率超时、限流、解析失败、无效输出率空回复、格式错误、拒绝回答、用户侧反馈投诉、重试、放弃率。有一次我发现无效输出率突然从 2% 涨到 15%排查后才发现是上游文档更新后检索结果质量下降模型拿到了一堆不相关片段开始胡编。如果没有无效输出率这个指标这个问题要等用户大面积投诉才能发现。AI 应用的可观测性核心就是“模型的每一次失败都要能看见、能定位、能追踪回是哪一环变了”。部署这件事代码只是入口监控体系才是真正让你睡得着觉的东西。6. 从零开始的路线图我重新整理的学习与实践顺序6.1 五个阶段的产出物与验收标准最后把方法论落地成一条路线这是我走了弯路之后重新整理的顺序也是我后来带新人时实际在用的。每个阶段都有明确的产出物而不只是“学完了某本书”阶段主要任务产出物验收标准一提示词与模型能力边界3 个以上场景的 Prompt 方案能说清每个 Prompt 的四个杠杆分别起什么作用二端到端小产品一个可公网访问的问答/摘要工具完整走通调用、解析、部署、监控的闭环三RAG 与 Agent一个带知识库的机器人和一个多步 Agent能解释检索切片、重排、反思循环的设计理由四评测 Harness 与测试开发一套可复用的回归评测脚本和指标报告每次改动都有量化数据不再靠“感觉”五部署、成本与监控带缓存、限流、监控告警的生产服务能回答每请求成本、P95 延迟、失败率第一阶段花两周把基础模型的 Prompt 玩熟掌握角色设定、少样本、思维链、输出约束同时搞清楚你常用的模型擅长什么、不擅长什么。第二阶段做一个不超过 1000 行代码的小应用比如个人知识问答或文章摘要工具目标不是做好而是把链路跑通。这一趟走完你对 AI 工程的体感会比读十篇文章都强。6.2 我踩过的最典型的三个坑第一个坑是只收集提示词、不建评测体系。我早期收藏了几百个“效果惊艳”的提示词真正用的时候一半失灵。后来才明白提示词和环境强相关同一个提示词换个模型、换个语境效果可能完全不同。没有评测你分不清是提示词的问题还是模型的问题。第二个坑是一上来就想做 Agent。我第一个 Agent 项目给模型接了六个工具结果它在工具之间来回乱调像喝了酒一样成本一天烧掉几百块。后来我把工具减到两个把每个工具的输入输出约束写死再逐步加回来才稳定下来。Agent 这种复杂形态一定要在有基础提示层和评测体系之后再碰。第三个坑是上线前才想成本和监控。我的一个项目在原型阶段一天成本几块钱上线后用户量一大一天成本直接破千全靠临时抢修。从那以后我把成本模型的估算和监控指标的埋点放到了项目启动阶段而不是上线前。6.3 我的最后一点体会我对“从零开始”的最终理解是不要试图先学完所有东西再动手而是先做一个极小的闭环再在每个环节迭代加深。AI 工程没有捷径但有一条清晰的路——提示词到应用到评测再到部署一层一层往上搭。那些被跳过的环节总有一天会回来找你。如果让我给刚开始的朋友一句最实在的建议那就是第一个项目一定要小小到一周能上线然后老老实实给这个最小项目配上测试集、监控和成本记录。从这个小闭环里长出来的经验和判断力比任何课程和模板都值钱。