说实话我第一次看到ai-engineering-from-scratch这个项目标题的时候脑子里第一反应是这不就是一个人人都懂的又大又空的词吗AI工程说着好听最后还不是调接口、写提示词、套框架三件套。但等我真正深入去做才发现工程这两个字的重量远不是会用能撑起来的。过去一年我带着团队从零开始把一个又一个基于大模型的应用从概念验证做到线上稳定运行。踩的坑比写下的代码多被模型背刺的次数比被产品经理催更的次数还多。如果你也想从会写几句 prompt走到能交付一个可靠的 AI 系统这篇文章就是你缺的那张地图。我会把整套思路拆开揉碎从大模型基础原理讲到提示词工程再到 Harness Engineering、AI 编程与 AI 测试开发以及最容易被忽视的评估监控闭环全给你过一遍。1. 从零开始的 AI 工程全景图1.1 AI 工程不是调 API重新理解边界先说一个最常见的误区。很多人觉得AI 工程就是把 GPT-4 之类的模型 API 接进来然后写点业务代码包一层完事。但我见过太多这样的项目demo 跑得飞起一上线就稀碎。为什么因为真正的大模型开发和传统软件开发有本质区别它输出的不是确定性的结果而是一个概率分布。同一个 prompt同一个模型两次调用可能给出完全不同的回答。这意味着你不能像写普通函数那样假设输入输出是稳定的。你需要为不确定性设计一套工程体系——怎么让输出尽量稳定怎么在它偶尔抽风的时候兜底怎么衡量它到底变好了还是变坏了这一整套东西才是 AI 工程的核心。说白了AI 工程解决的不是怎么让模型能说话而是怎么让模型在业务里持续稳定地干活。所以我的第一个建议是先把心态从算法研究员切换成系统架构师。你不是在调一个模型你是在设计一套包含模型、数据、工具、评估、监控在内的完整系统。你的模型只是这个系统里的一个组件虽然是很重要的组件但它不是全部。1.2 从零搭建 AI 工程的能力地图如果把 AI 工程画成一张地图我认为可以分成三层。底层是模型和理论基础中间是方法和框架层上层是平台和流程层。很多人一上来就钻到 langchain 之类的框架里结果框架会用了底层原理一塌糊涂出了问题根本不知道往哪查。我建议的学习路线是这样的先花少量时间搞懂大模型的核心原理不用太深但要知道它的能力边界和缺陷来源再系统学提示词工程然后进阶到 Harness Engineering怎么给模型装上工具和流程最后是评估、监控、迭代这一套工程闭环。你有 Copilot 那样的插件不用三个月就能上手写业务代码。但你要是想系统地掌握 AI 工程请按这个顺序走理论 → 提示词 → Harness/Agent → 评估迭代。每层都别跳跳了后面必然会回头补课。2. 地基大模型基础理论绕不开的那些为什么2.1 从 Token、上下文窗口到幻觉的成因研究 AI 工程第一个要搞明白的概念是 Token。Token 是大模型处理文本的最小单位它不是一个一个字而是一段一段的词块。英文一个单词可能就是一个 Token中文一个字可能是 0.5 到 2 个 Token。这不是小事因为Token 直接决定你的成本、速度还有上下文窗口的容量。我实测过同样一段中文文本不同分词器产生的 Token 数量差距可以超过 50%。所以代码里做文本截断的时候千万别只按字数截要先估算 Token。很多项目上线后账单爆炸一查才发现是某些超长文档每天被反复塞进上下文白白烧钱。上下文窗口也不是越大越好。很多模型官宣有几十万 Token 的上下文但实测下来把它塞到接近上限时模型对中间部分内容的注意力会明显下降这种现象叫lost in the middle。我做过一个文档问答场景文档 3 万字把全文都塞进上下文问中间章节的内容答案经常不准。后来改成检索式方案反而好了很多。再说幻觉。幻觉不是简单的模型不靠谱它的成因主要有三类训练目标本身是预测下一个词而不是确保事实正确、训练数据里本身存在矛盾和错误、解码策略为了多样性引入了随机性。理解成因之后你就知道工程上怎么应对了——不要试图消除幻觉要通过引用溯源、检索增强、可控输出等方式把幻觉控制在不影响业务的范围之内。2.2 模型选型的关键参数与实践判断选模型是 AI 工程第一道关卡我见过太多团队在这上面反复横跳。先给个我的选型原则能买的就别自己训能用小的就别用大的。除非你有非常特殊的数据和完全不可接受的隐私风险否则在云 API 和开源模型之间我优先推荐先试云 API等业务验证成功了再考虑私有化。如果要选开源模型有几个参数你必须看得懂。第一是参数量7B、13B、70B 差别非常大。第二是量化精度INT8、INT4 能大幅降低显存但会带来一定效果损失。有一个非常重要的估算公式推理时显存占用约等于 参数量 × 每参数字节数FP16 下 7B 模型需要约 14GB 显存INT8 约 7GBINT4 约 3.5GB还要额外加上 KV Cache 的部分。翻车经验我试过在 16GB 显存的老卡上直接跑 13B 模型的 FP16结果加载模型就 OOM 了白折腾半天。后来换 INT8 量化才勉强跑起来但推理速度慢得感人。所以选模型之前先算显存已经是我的条件反射了。分类来看对话聊天、代码生成、内容总结不同任务对模型的偏好完全不同。代码生成这个场景我实测下来某些专门的代码模型比通用模型胜率高很多但自然语言理解又反过来。建议把你要做的任务整理成一个小测试集把候选模型都跑一遍用一套固定评分标准量化对比而不是凭感觉选。3. Prompt Engineering第一门必修课3.1 结构化提示词设计从随便问问到专业表达很多人写 prompt 是想到哪写到哪模型发挥全靠运气。Prompt Engineering 不是玄学它有一套系统的设计方法论。我自己的模板逻辑是角色你是谁资深律师/数据分析师/图书编辑一句话给模型设定位任务目标是什么要尽量具体上下文背景信息、业务约束把它需要的都给它要求输出的格式、长度、风格、语气示例给一到三个输入输出的范例比你说一百句都管用边界明确告诉它不要做什么比如不要编造数据、如果不知道就直说不知道这个模板看起来简单但它解决了大模型输出最让人头疼的不确定性问题。它不依赖运气而是通过明确的结构把输出空间往你期望的方向收窄。比如我之前做一个法规问答应用最初的 prompt 是请回答以下法律问题。后来改成结构化模板明确告诉模型你是一名专注于劳动法的律师助理请基于我给出的《劳动合同法》条文回答问题如果问题不在条文中请明确回复检索范围外请补充条文回答必须包含对应的条文编号。同样一个模型回答的专业感肉眼可见地提升了。3.2 少样本、思维链与温度参数的实测心得少样本Few-shot是我个人认为性价比最高的调优手段。给模型看两个正面例子比你在 prompt 里写一百字解释都管用。但少样本也不是越多越好我实测过一个分类任务给了 8 个例子之后模型反而在纠结例子之间的细微差异准确率轻微下降。给 2-4 个高质量示例通常是甜点区。思维链Chain of ThoughtCoT在数学、逻辑推理类任务上是明确有效的做法很简单就是在 prompt 里加一句请一步步思考并把思考过程写在最终回答之前。但要注意思链不总是好事。在需要简短回答的客服场景模型可能真的就把庞大的推理过程抛给你了用户根本不想看。而且思维链会显著增加输出 Token成本和延迟都上去了。所以我的经验是越需要推理的任务越用 CoT越需要快速响应的任务越别用。温度参数Temperature是个细节活。上到 0.7 以上回答多样性高但对事实类任务来说就是灾难调到 0.0-0.2输出稳定但会比较刻板。知识库问答、代码生成这类对确定性要求高的任务我常年设置 0.1 左右头脑风暴这类创意任务可以拉到 0.8。别小看这个参数改一个温度有时候比改十版 prompt 都管用。3.3 提示词也值得版本管理新手最容易犯的错prompt 改来改去上线后出了问题都不知道是哪个版本在线上。Prompt 就是代码是真的要放进 Git 仓库管理的而且要有版本号和回归测试。我的习惯是每个 prompt 单独一个.md文件放在项目的prompts/目录下。文件头部写清楚版本号、适用模型、温度参数、修改人、修改日期。任何一次改动都必须跑一遍同一套回归用例确保没有把之前好的行为改坏。这套流程刚开始看起来麻烦但当你过了三两个月回头想调优的时候你就知道它的价值了。你不需要重新猜当时为什么这么写一切都有记录改起来敢下手。4. Harness Engineering给模型装上轮子4.1 从 Prompt 到 Harness到底在装什么把 Prompt 做到极致之后你会撞到一堵墙有些任务不是靠一段提示词能搞定的它需要模型行动起来。这时候就轮到 Harness Engineering 登场。这个词网上叫法挺多有人翻译成工程管线有人叫模型外挂我自己的理解是Harness 是把原始模型封装成一套可控制、可扩展、可观测的系统的所有工程手段。你可以把它想成赛马的马具——马还是那匹马但你要给它装上缰绳、鞍具才能让它按你的路线跑而不是漫山遍野乱窜。那 Harness 具体包含哪些东西至少这四样工具调用Function Calling、检索增强RAG、记忆管理、控制流设计。工具调用让模型可以去查数据库、调接口RAG 让它能基于你的私有数据回答记忆让它可以记住之前的会话控制流则是把前三个按业务编排起来。这一整套合起来就是最近很火的 AI Agent 的实现基础之一。我见过很多团队一听到 Agent 就兴奋恨不得所有场景都用上。但我必须泼一盆冷水80% 的场景根本不需要完整的 Agent。如果你的业务流程是固定那几步那用确定性代码编排比让模型自由决策稳定一百倍。Harness 的价值在于它让你有选择——简单场景用轻管线复杂场景上完整 Agent而不是一开始就无脑上最强的方案。4.2 工具调用、RAG 与数据流设计实战先说工具调用。主流大模型 API 都支持 Function Calling就是让模型从你定义的若干函数里选一个合适的并生成调用参数然后你的代码真正执行这个函数再把结果回传给模型生成回答。核心工程问题有两个一是你的函数描述JSON Schema要让模型看得懂描述不清楚模型就乱选二是函数返回的结果格式一定要干净否则模型二次生成时容易被垃圾信息带偏。我这边的习惯函数描述里对每个参数都写上取值范围和示例值返回结果统一带头尾标识符方便模型辨认。这个看起来只是细节但实测能让工具调用成功率提升约 20 个百分点。再说 RAG。RAG 基本链路是把文档切分成块Chunking→ 用 Embedding 模型转换成向量 → 存进向量数据库 → 用户问题也向量化 → 检索最相似的 TopK 块 → 拼进 Prompt。这里最容易被忽视的是切分策略。我一开始直接按字数切块每块 500 字结果很多语义完整的段落被切断检索效果很差。后来改成按 Markdown 标题结构切块同时保留段落元数据效果好了不少。通用经验是中文文档单块在 200-500 Token 之间比较合适太短缺上下文太长噪声大。检索回来的 TopK 也别贪多3-5 块比较合适太多了 prompt 被无关内容占据反而不准。RAG 进阶玩法是加一个 Reranker 重排序。召回阶段先拉回来 20 个候选用重排序模型精排取前 3 个算力成本稍高但准确率提升明显。如果你做的是企业知识库这种对准确率要求高的场景这个钱值得花。数据流设计这块关键点是把读取上下文和执行动作拆开。我一直强调检索器、工具函数、LLM 输出这些模块之间要做好解耦。检索器就是一个可以独立测试的函数给它一个问题看它返回哪些内容工具函数也独立测试。只有每个模块是可信的组合起来系统才是可信的。4.3 从 CodeBuddy 看 Harness 的完整案例我最近研究了很多 AI 编程工具CodeBuddy 这类产品的实现给了我很大的启发。很多人以为 AI 编程助手就是你把需求打进去它把代码吐出来实际完全不是。它本质上一个非常典型的 Harness 系统第一步它要构建上下文。AI 编程助手会分析当前打开的文件、整个仓库的目录结构、相关依赖、甚至 Git 变更记录把它们组装成模型需要的上下文。这一环做得好不好直接决定代码生成的准确率。我自己实测在同样的模型下上下文构建做得好坏可以让生成代码的可运行率高出一倍。第二步它要调用工具。AI 编程助手会调用文件读写、命令执行、代码搜索这些工具。模型不是直接在编辑器里打字而是决定我应该先读一下这个函数定义我应该跑一下这个测试每一步都生成工具调用你的 IDE 后台真正执行它把结果再喂回给模型。第三步是验证与反馈闭环。生成的代码有没有报错测试跑没跑过这些信息会回传给模型让它自行修复。这就是一种人机协同时代的调试。看到这里你应该明白了所谓 AI Native 研发范式其实不是让 AI 替你写代码而是把编码这件事改造成一个由 Harness 支撑的循环上下文提取 → 生成 → 工具执行 → 反馈 → 迭代。你在 CodeBuddy 里面做过的每一次让它帮我改一下这个函数背后都是这套循环在运转。理解了这一点你再看任何 AI 编程工具都不会觉得它神秘了。5. AI 编程与 AI 测试开发把 AI 嵌进研发流水线5.1 AI 编程的实际落地提示词技巧与上下文构建很多开发者的 AI 编程初体验是这样的打开对话窗口输入帮我写一个登录页面啪地一下代码出来了拿过来一粘贴报错一堆。问题出在哪模型根本不了解你的项目它不知道你用的框架版本、不知道你的 UI 组件库、更不知道你有没有现成的工具函数。指望一个没有上下文的模型直接写出可运行的业务代码那不叫 AI 编程叫抽盲盒。我现在的做法是把 AI 编程当成结对编程的实习生先给它足够的上下文再让它动手。比如改一个函数我先贴出来这个函数所在的文件内容再说明改动目标然后再补充一句注意项目里已经有用 axios 封装好的请求方法优先复用。模型在完整上下文中生成代码的成功率远高于你只给一句需求。AI 编程的提示词也有讲究。一个我实测好用的结构是这样项目背景 相关文件内容 具体任务 约束条件 目标输出形式完整函数/改动 diff。别嫌麻烦你在 prompt 里花的那一分钟能省下次级排错的一小时。而且 CodeBuddy 这类带上下文的工具已经把一部分工程做掉了你要做的就是把业务意图表达清楚。再提一个关键技巧让 AI 写代码时把验收标准一并给到它。具体来说你可以在 prompt 里加上写完代码后请同时生成对应的单元测试或者请确保函数输入为空时返回空数组而不是抛异常。这种带验收条件的 prompt 会把 AI 编程的输出质量明显拉高因为它知道你不只是要一段看起来对的代码而是要能跑、能测、符合预期的代码。5.2 测试开发被 AI 重塑从生成用例到测试自身把 AI 用在测试上是我觉得性价比极高的一件事。传统测试开发最耗时的是写测试用例代码。用 AI 辅助之后让模型帮你生成 pytest/JUnit 测试函数你把被测函数贴进去描述一下业务规则它能给你产出一版覆盖正常场景、边界场景和异常分支的用例框架。但我要提醒AI 生成的测试用例不能直接无脑用。我踩过最大的坑是AI 生成的测试用例全是基于它自己的完美假设根本不考虑数据依赖、权限、并发这些现实约束。所以我的流程是AI 生成初版 → 人工审查关键断言 → 补上业务特有场景 → 再进 CI。这样既省了时间又不会丢掉测试的灵魂。另外AI 不仅帮人做测试更要被测试。大模型应用怎么测试这条我先简单说你不能用传统断言返回结果等于预期的方式测大模型因为同一个输入它每次输出可能有轻微差异。对于大模型应用要测的是语义是否达标你可以用规则断言比如输出必须包含某个关键词、相似度断言计算输出和期望答案的文本相似度或者用另一个模型当裁判LLM-as-a-judge。这套东西没有银弹需要根据场景设计合适的断言策略但绝不能不上。6. 评估、监控与迭代闭环工程化的灵魂6.1 离线评估Golden Set 是你的护身符前面聊了那么多原理、框架、技巧最后必须得收敛到工程上最核心的话题——你拿什么证明你的系统是好的。答案就是建一套 Golden Set黄金评估集。它是一批输入 - 期望输出的高质量样例覆盖你业务里的典型场景和边角情况。每次你改 prompt、换模型、调 RAG 参数都拿 Golden Set 跑一遍用同一套评分标准打分。分数涨了说明改动有效跌了说明改动引入了回归。这个思路看起来朴实但真正执行过的人知道它有多重要。我见过太多团队在调优阶段凭感觉结果所有人对同一版系统的感觉都不一样吵来吵去也没有结论。有了量化评估集讨论就变成这周的分数比上周高了 5 个点沟通成本直线下降。Golden Set 的维护有讲究量不需要特别大但一定要精。我建议初期 50-100 个用例就够了每周从线上抽样补充新的 bad case持续滚动。评分标准用 1-5 分制由至少两个人标注遇到分歧讨论统一这样才不会有标注者的个人偏好污染数据。6.2 在线监控别等用户骂了才知道模型崩了评估集管的是离线环节上线之后靠的是在线监控。大模型应用和传统应用最大的区别在于你很难实时知道模型输出对不对但你至少可以监控这些信号接口延迟和落库延迟模型推理慢是常态但突然暴涨一定有问题输出长度输出突然变长可能是 prompt 被污染了报错率工具调用失败率、 RAG 检索空结果率这些都是早期预警用户反馈显式的差评隐式的复制提问后重新生成成本Token 消耗突变经常是上下文被塞入了超大内容线上监控的目的不只是报警更是为了采集坏例。每次出现低质量回答把当时的输入、上下文、模型输出、模型版本、prompt 版本全部记录下来形成坏例库。这个坏例库就是你的评估集的增量来源。我踩过一次特别惨的坑模型供应商升级了底模我们什么都没改结果回答风格整个变了用户大量投诉。从那天起我们每次上线前都先跑一遍 Golden Set 做回归而且专门把明天 API 是不是又换了模型当成一个重要监控项。6.3 迭代闭环与真实踩坑记录离线评估 在线监控合在一起就形成了迭代闭环线上坏例 → 収集归类 → 针对性修复改 prompt、调 RAG、换模型、加工具→ 在坏例库上验证 → 跑全量评估回归 → 发布 → 观察线上指标。最后分享几个逼真到疼的踩坑经验。第一个评估集太小时真实场景会翻车。我刚开始只拿了 20 个精心挑选的正例做评估上线前分数漂亮上了线被用户花式输入直接打爆。后来把评估集扩到 200 个、涵盖了各种口语化表达和奇怪格式回归价值立刻体现出来。第二个过度依赖 prompt 而不修数据是死路。有一阵我为了回答一个高频问题在 prompt 里反复打补丁最后 prompt 变得又臭又长效果却越来越差。后来我把这些内容重新做成知识库走 RAG 检索不仅 prompt 清爽了效果还明显提升了。数据问题应该优先用数据手段解决不要在 prompt 里硬堆。第三个不要迷信某个模型版本永远最好。模型更新本来是好事但每次升级都需要走一遍完整回归流程。即便厂商说效果全面增强也一定有你业务场景上反而变弱的部分。把模型版本也当作系统配置的一部分来管理变更前必须过评估。我在实际操作中最深的体会是AI 工程从零到一最难的从来不是某一个技术难点而是把模型、提示词、工具、评估这些环节组装成一条可信的流水线。参数调不好可以再调模型效果差点可以换但你没有一套工程化的方法来确认改没改对所有努力都像是在黑夜里扔飞镖。现在开始从最小的 Golden Set 建起从第一条监控看板建起把一个模型也好、一个 Agent 也好真正变成你能掌控的系统。一步一步来这条路并没有那么玄乎。