说实话，我第一次看到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 约 7GB，INT4 约 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 Thought，CoT）在数学、逻辑推理类任务上是明确有效的，做法很简单，就是在 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 也好，真正变成你能掌控的系统。一步一步来，这条路并没有那么玄乎。
