两年前我接手第一个AI项目时最大的困惑不是模型效果不好而是根本不知道从哪一步开始。找开源代码、跑通Demo、调API、拼提示词这些动作单独拿出来我都会但距离工程化交付还差着十万八千里。项目一多问题就暴露了模型输出不稳定怎么兜底评测指标怎么定提示词改了之后如何确认没把别的场景搞坏Agent调工具失败怎么重试这些问题没有一个能靠再调调参解决它们属于同一门学科——AI工程AI Engineering。这篇文章想把我从零构建AI工程能力的过程完整拆开讲一遍先厘清AI工程到底是个什么东西再讲哪些基础知识必须打牢、哪些可以边做边补然后给出我实际跑通一个项目的完整链路最后花大篇幅聊提示词工程、Agent/Harness工程、以及最容易被忽视的测试与监控。内容偏实战适合两类人一是刚转行AI方向的开发者手里有编程基础但不知道系统学什么二是已经在用大模型API做功能、但总觉得差点意思的工程师。读完你应该能对自己缺什么、下一步补什么有一个清晰的判断。1. 从会调API到会做AI工程我理解的本质转变1.1 为什么这个话题值得单独写一篇从零开始学AI工程这句话听起来很宏大但落到日常就是一连串具体的抉择学深度学习框架还是先学推理框架transformer原理要掌握到什么程度RAG、Agent、Fine-tuning到底先学哪个市面上90%的教程都在教用一个框架跑通一个功能但AI工程的核心恰恰不在跑通而在稳定地跑、可衡量地跑、可维护地跑。我见过太多开发者包括我自己早期陷入一个误区把模型效果当成了全部。模型答得好就欢呼答不好就换更贵的模型。但真实业务里模型只是系统中的一个组件和它打交道的还有输入校验、上下文组装、结果解析、缓存、降级、日志、用户反馈回收。这些组件的工程质量往往决定了AI功能的生死。AI engineering from scratch这个主题真正的价值就是让我们把视角从模型切换到系统。这个转变是我认为AI工程师和会调用AI的软件工程师之间的本质分界线。1.2 AI工程与传统软件工程、机器学习研究的边界要搞清楚AI工程是什么最好的方式是把它和两个相邻领域做对比。传统软件工程Software Engineering处理的是确定性逻辑输入A永远得到输出Bbug可以复现测试可以穷举。AI工程面对的是概率性系统同样的输入模型可能给出三种都合理的回答错误难以稳定复现测试只能用覆盖率而不是穷举法。这意味着工程实践的底层逻辑质量保障必须换一套打法。机器学习研究ML Research关注的是模型还能不能更强以论文、基准测试、实验为核心产出。AI工程关注的则是这个模型能力放进业务里能不能持续产生价值以服务稳定性、用户满意度、成本、迭代效率为核心指标。研究者可以接受模型输错十次然后改进一次工程上输错十次用户早就走了。AI工程的位置恰好是这两者的交集要用工程手段约束概率性输出同时要用模型能力解决传统规则写不清的问题。这也解释了为什么它难学——因为它要求一个人同时具备软件工程师的严谨和数据分析师的实证思维。1.3 从零开始的真实起点很多人以为从零开始意味着从数学、从tensorflow手写反向传播开始。我个人的结论是不需要也不建议。我在项目中实际用到的知识按频率排个序的话大概是Python数据处理与工程化每天 大模型推理与调用的机制理解每周 提示词工程/结构化输出每天 基础评估与数据分析每周 机器学习训练原理偶尔 数学推导几乎不涉及。所以真实的起点是能熟练处理数据和写工程代码然后把大模型当成一个概率性的外部组件去构建系统。底层数学可以后续按需补而不是前置拦路虎。这一点想清楚学习路径会轻松一半。2. 知识底座哪些基础必须打牢哪些可以边做边补2.1 编程与数据基础最省时间的补法如果现在让我给一个从零学习者划红线我会说Python语言、JSON处理、SQL、基础Linux命令这四样必须熟练掌握到不用想的地步。因为AI工程日常工作就是三件事准备数据、调用模型、处理结果。这三件事全都建立在上述四样基础之上。数据操作的熟练度尤其重要。我在实践中总结过一个比例一个AI项目里真正写模型调用代码的时间大概占20%剩下80%的时间全在清洗数据、拼接上下文、解析输出、修格式错误。如果你对Pandas、json库、正则表达式不熟那这80%的时间会变成灾难。这里给一个自测标准给你一个包含用户对话记录的JSON文件要求你把每轮对话组装成一个系统提示词用户消息历史上下文的新请求格式并处理掉其中的空字段和超长文本你能不能在半小时内写出干净可运行的代码这个能力比背下来transformer的公式有用得多。2.2 语言模型原理从词向量到注意力机制很多人问我要不要读《从零构建大语言模型》这类书我的回答是读但要有策略地读。你不需要理解每一个矩阵运算的推导但必须建立四个核心心智模型第一Token与上下文窗口。语言模型不是按词处理文本而是按子词Token切分。上下文窗口就是模型一次能看到的Token上限。这直接决定了你的工程策略超长文档怎么截断、历史对话怎么压缩、RAG怎么决定检索多少片段。不理解Token你就不可能做好上下文工程。第二Embedding嵌入与语义检索。模型会把Token映射到高维向量空间语义相近的内容向量距离近。RAG检索增强生成、语义搜索、聚类去重全都建立在这个原理上。理解了这一点你就知道为什么关键词匹配和向量检索是不同维度的东西什么时候该用哪个。第三注意力机制与信息稀释。Transformer的核心是注意力模型在处理每个Token时都会关注上下文中的其他Token。但注意力不是均匀分布的长文本中中间部分的信息容易被稀释。这就是为什么把重要信息放在提示词开头和结尾是有效的不是玄学。很多上下文工程技巧本质上都是围绕注意力特性设计的。第四自回归生成与不可能完美。大模型是逐Token预测下一个Token的这意味着每一次生成都是一次概率采样天然存在随机性。把温度调到0可以减少随机但不能消除不确定性。接受这一点你才会在设计系统时主动加校验、重试、兜底而不是祈祷模型表现稳定。2.3 从零构建一个推理模型值得做但要知道目的热词里build a reasoning model from scratch很多人搜我也实际带过一个小项目用几万条推理数据微调了一个小型模型。这个过程的真正收获不是模型本身而是把上面说的原理亲手验证了一遍数据质量如何决定效果上限、训练与推理的内存开销差异、量化后效果损失来自哪里、为什么大模型涌现的能力在小模型上就是没有。如果你也想做一次我建议目标设置成复现一个小而完整的训练-评估-部署流程而不是做出一个能用的模型。推荐路径用Hugging Face Transformers加载一个1-3B的开源模型准备5000-20000条SFT监督微调数据用LoRA做参数高效微调再部署到vLLM上做推理服务。这条链路走完你对于模型生命周期的感觉会和只看教程完全不同。但我也要泼一盆冷水不要把训练模型当成AI工程学习的主线。在绝大多数业务场景里直接用成熟的商用API或7B以上的开源模型远比从零训练划算。训练模型是为了理解不是为了让业务跑起来。3. 第一个能落地的AI项目从选型到上线的完整链路3.1 项目选型的三个原则我的第一个正式AI项目是一个内部知识库问答系统选它的原因现在回头看非常正确业务场景清楚、数据可控、评估相对容易、不需要处理太复杂的Agent逻辑。给从零开始的人推荐首选项目我一般建议满足三个原则。第一单点能力项目优于复合能力项目。先做一个模型调用完成一个明确任务的项目比如文档分类、信息抽取、文本润色、客服问题路由。不要一上来就做Agent、多轮对话、复杂工作流——那些是多个单点能力的叠加出问题时你根本分不清是哪个环节坏了。第二有明确的对错标准。信息抽取类任务特别适合入门因为你可以人工标注一批标准答案用精确匹配或相似度来量化评估。而生成一段广告文案这类开放生成任务评估难度就高很多不适合作为第一个项目。第三使用频率高、影响范围小。内部工具优于面向外部用户的产品。影响范围小意味着即使模型出错代价也可控敢上线、敢迭代学习速度才快。3.2 最小可行系统的搭建拿我当时的客服问题路由项目举例最小可行系统长这样用户输入问题 → 调用模型给它归类到预定义的10个业务标签 → 输出JSON格式结果 → 程序解析后路由到对应人工处理队列。完整代码核心部分其实只有几十行。import json from openai import OpenAI client OpenAI() SYSTEM_PROMPT 你是客服问题分类器。将用户问题归类到以下标签之一 [订单查询, 退换货, 支付问题, 物流进度, 发票开具, 投诉建议, 产品咨询, 其他] 只输出JSON格式{label: 标签名, confidence: 0.0-1.0} def classify_user_query(query: str) - dict: response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: query} ], temperature0, response_format{type: json_object}, ) return json.loads(response.choices[0].message.content)就这么简单。但工程化的关键在于它周围的那层壳我在生产落地时依次补上了五个部分输入预处理清洗特殊字符、截断超长文本、敏感信息脱敏。输出校验模型返回的JSON可能字段缺失或格式错误必须写schema校验和默认值兜底。重试与降级API超时或限流时退避重试连续失败切换到备用模型或规则匹配兜底。日志与追踪记录每次调用的输入、输出、耗时、Token数、confidence方便后续分析。人工复核机制confidence低于阈值的样本自动进入人工处理池同时回收为标注数据。这五个壳加完才可以说这个AI功能能交付。它们也恰好印证了前文说的观点模型只是组件系统才是产品。3.3 模型评估我踩过的看起来有效的坑第一个项目上线前我犯过一个典型错误用20条测试用例验证准确率95%就以为可以上线了。结果上线第二天就翻车——用户实际问法和测试用例风格差异很大真实准确率可能只有70%。这个教训让我建立了AI评估的三个基本认知第一测试集必须贴近真实分布。最好从真实历史数据中采样而不是自己编造。我当时自己编的用例用词太规范用户真实提问则是口语化、带错别字、夹杂情绪化表达完全是两个分布。第二评估标准必须预先定义。在动手写代码之前就要确认准确的定义。多标签分类怎么算对部分匹配算不算错误标签和其他标签哪个代价更高这些问题没有标准答案但不提前想清楚评估就是一笔糊涂账。第三评估要留出足够的样本量。分类任务至少准备200条以上测试集才能对真实准确率有一个置信度较高的估计。20条只能算冒烟测试不能作为决策依据。4. 提示词工程与Harness Engineering工程化的关键能力4.1 提示词工程不是写话术很多初学者把提示词工程理解为把需求说得好听一点这是一大误解。我做了大量提示词迭代后认为它的本质是结构化地约定模型的输入输出行为类似于给模型设计一份接口协议。一份工程化的系统提示词我通常会拆成四个模块角色与任务边界模型是什么角色、能做什么、绝对不能做什么。输入输出格式协议输出的结构、字段定义、枚举值范围必要时附上正反例。处理规则与优先级遇到边界情况怎么处理规则冲突时以哪条为准。约束与底线拒绝回答的范围、长度限制、引用要求等。举一个信息抽取场景的片段你是一个合同信息抽取助手。 目标字段合同编号、签约双方、合同金额、生效日期、有效期。 规则 1. 金额只取阿拉伯数字并统一单位为万元若原文为壹佰万需转换为100万。 2. 日期统一输出为YYYY-MM-DD格式。 3. 若字段在原文中不存在输出null禁止猜测。 4. 输出JSON不要输出任何解释性文字。你会发现这里面的每一条规则都是在减少不确定性。写提示词的功夫不在于辞藻而在于把业务规则翻译成模型能理解并严格执行的约束。所以提示词工程本质上是需求分析和规则设计只不过表达介质从代码换成了自然语言。4.2 Harness Engineering模型之外的脚手架热词里harness engineering最近讨论度高这个叫法虽然新但描述的事情并不神秘把模型能力接入业务系统所需的所有外部机制。Anthropic在讲Agent设计时反复强调harness——模型是引擎harness是底盘、油箱、方向盘、仪表盘。我理解harness工程包含四个核心模块上下文工程Context Engineering决定模型每轮调用能看到什么。包括指令、检索结果、历史对话、工具描述、示例以及它们如何排序、截断、压缩。这是AI工程里最微妙也最影响效果的部分。工具与行动空间Tools Actions定义模型通过函数调用能对外界施加哪些操作。工具的命名、参数Schema、返回格式的设计直接影响模型能否正确使用它们。控制流Control Flow单次调用之外的循环、分支、终止条件。比如最多重试3次检索不到就换关键词再搜一次用户确认后再执行写入操作。安全与权限Safety Permissions模型能访问什么、不能访问什么、敏感操作是否需要人工二次确认。一个只调一次API的RAG问答harness是检索→组装→生成→校验这条短链。一个能自主完成数据分析的报告Agentharness就是规划→调工具→观察结果→修正→再执行的循环。AI工程能力的差距很大程度上就是harness设计能力的差距——同样的模型不同的harness产出质量天差地别。4.3 从单次调用到工作流编排当我从第一个项目走向更复杂的功能时最先学会的是把单次调用拆成工作流Workflow。举一个我常讲的例子从非结构化简历中抽取候选人信息并生成评估报告。单次调用的做法是把简历全文塞给模型让它一次输出结构化信息加评估意见。这样做的问题很明显简历太长超出上下文窗口信息抽取和主观评估混杂在一起模型容易顾此失彼结果不稳定且难以定位问题。工作流做法的设计是前置清洗管线解析PDF/Word去掉页眉页脚分段。抽取模块模型只负责抽取结构化字段输出严格JSONtemperature设为0。质量校验模块用代码检查必填字段是否存在、日期格式是否合法不合格则触发带错误信息的二次抽取。评估模块将抽取结果与岗位要求一起送入模型输出结构化评分和评语。汇总模块把评分数据写入表格对低分项生成提醒。这个设计把一个复杂任务拆成多个简单任务每一环的输出都是下一环的输入而且每一步都有独立的校验点和日志。好处是出问题能迅速定位到具体环节单环节可以独立优化可以针对不同环节使用不同模型抽取用便宜的小模型评估用更强的大模型。我给这个阶段的学习者的建议是先别急着上Agent。用工作流方式把两三个单点项目串起来你会彻底理解工程化三个字的分量。Agent不过是在工作流上加了自主决策的循环没有工作流的掌控力直接上Agent只会得到一个失控的黑盒。5. AI Agent与多智能体协作的工程实践5.1 Agent的本质与边界Agent智能体最近是热度最高的词之一但也是被滥用最严重的词。我个人的定义很简单Agent是一个能根据目标自主决策、调用工具、观察结果并迭代行动的AI系统。工作流是预定轨道上的列车Agent则是带着目的地、自己选择路线的驾驶员。工程上Agent和普通提示词调用的核心区别是那个循环业界常称agent loop提出计划 → 执行工具调用 → 观察工具返回结果 → 根据结果调整下一步 → 直到达成目标或到达终止条件。每一轮循环都是一次完整的大模型调用因此Token消耗、延迟、失败概率都会成倍增加。这不是坏事前提是你清楚这些代价。我在决定要不要上Agent时有一个判断标准如果任务的步骤可以被预先穷举就用工作流只有步骤无法预判、需要根据中间结果动态决策的任务才值得用Agent。比如按固定模板生成周报用工作流给我做一份本市咖啡店市场调研才用Agent。5.2 工具调用与记忆设计Agent工程的两个硬骨头Agent能不能跑起来很大程度上取决于工具调用设计。我踩过几个坑现在沉淀成四条规则第一工具描述要写清楚什么时候用和返回什么。模型是靠描述来决定是否调用工具的描述含糊它就会犹豫或者用错。比如search_documents(query: str) → List[Document]用于在知识库中进行语义检索就比搜索文档明确得多。第二工具返回结果要结构化并可被模型消费。原始数据库记录、完整网页正文这些直接丢给模型会撑爆上下文。好做法是让工具返回精简后的摘要或者只返回元数据加正文片段。第三工具要有失败反馈机制。工具执行失败时必须返回可读的错误信息如API超时服务端无响应模型才能据此调整策略。返回一个空结果会让模型误以为搜不到从而给出错误结论。第四工具数量要克制。给Agent暴露的工具越多它选错的概率越高。一次对话暴露5-8个核心工具就够其余可通过子Agent或分步展开。记忆设计是另一个难点。Agent的记忆在工程上有三层上下文窗口内的短期记忆、外部存储中的长期记忆向量库、KV数据库、以及系统设计层面的状态管理。我踩过的最大教训是不要试图把全部历史都塞进上下文Token一旦太长模型会越来越健忘且延迟飙升。靠谱做法是定期对历史对话做摘要压缩只保留最近几轮原文加压缩后的关键事实。5.3 多AI协作一个实际案例与教训多智能体协作Multi-Agent我实际做过一个案例两名子Agent配合处理客服投诉一个负责情绪安抚与话术沟通一个负责查询订单与退款规则中间由一个主Agent协调。结果确实能处理一部分复杂场景但代价也不小。第一个教训是角色之间如果没有明确的信息传递协议协作就会变成互相扯皮。我从第一个版本就开始要求子Agent所有产出都以结构化JSON传递比如{“action”: “query_order”, “order_id”: “xxx”, “result_status”: “found”, “summary”: “...”}。这样主Agent才能可靠地读取并使用。第二个教训是多Agent的调试成本呈指数级上升。单Agent出错可以看日志定位多Agent协作出错你得还原整个决策链——谁先说了什么、另一个基于什么信息行动了。没有一套完善的trace机制排查问题会变成噩梦。建议任何多Agent项目第一优先级就是做完整的调用链路追踪每一步的输入、输出、决策理由全部落日志。第三个教训是成本。一次多Agent协作对话可能消耗几千个Token。业务上是否有必要一定要提前评估。我现在的倾向是能用单Agent加工具解决的绝不上多Agent多Agent只用于真正需要不同角色视角的复杂任务。6. AI工程的质量保障测试、评测与监控6.1 为什么AI应用测试这么难传统软件测试建立在一个前提上预期输出是可以精确判定的。AI应用打破了这一前提同一个输入模型今天和明天可能给出不同的回答而且两种回答可能都对。那怎么定义bug我的经验是把AI系统的质量问题分成三个层次来处理确定性错误格式错误、JSON解析失败、必填字段缺失、敏感信息泄漏。这些可以用传统代码检查全部拦截是性价比最高的防线。语义偏差答案与标准答案不一致、遗漏关键信息、引用不存在的内容幻觉。这类需要构建评测集用大模型打分或相似度计算来辅助评估。体验问题回答语气不友好、过于简短、不给用户台阶下。这类最难量化适合用规则加人工抽检控制。我还想特别强调一个工程原则用代码能拦截的错误绝不要指望模型自觉避免。比如要求模型输出JSON一定要在代码里加JSON解析和schema校验要求模型只输出指定枚举值一定要在代码里检查值合法性。模型是概率性的但系统边界必须是确定性的。6.2 评测集的构建从零到能支撑迭代评测集中最重要的思想是以增量方式沉淀。我第一次上线的评测集只有50条后来每次线上出问题就把问题样本修正好后补充进评测集现在规模已经超过500条。这个过程持续不断评测集就会越来越接近真实世界的复杂分布。评测集要覆盖三类样本典型样本高频场景、边界样本模糊表达、极端长度、多意图混淆、对抗样本攻击性输入、越狱尝试、自相矛盾的指令。边界样本尤其重要因为模型在边界上的表现往往最能反映系统的真实鲁棒性。评测方式我常用三种组合规则断言校验必填字段、格式、长度、引用来源是否存在。模型打分用更强的大模型按既定标准相关性、完整性、忠实度对回答打分。注意打分模型的Prompt里要附上明确标准最好隔一段时间抽样人工复核打分质量。人工抽检对于高风险场景定期抽检原始对话记录发现评测集覆盖不到的新问题。6.3 线上监控与回归保证改不坏AI功能上线之后真正的考验才开始。模型厂商更新版本、提示词优化、上下文结构变化任何一项改动都可能影响整体表现。我在线上至少会监控四类指标调用层面成功率、延迟、Token消耗、超时率、重试率。这些是系统健康度的第一信号。输出质量层面空输出率、格式错误率、低置信度率、触发兜底逻辑的频率。这些反映模型输出是否稳定。业务层面用户满意度、转人工率、任务完成率。这是最终价值的度量。成本层面单次调用平均成本、日均总消耗、预算使用率。AI项目的成本波动比传统服务大得多不设监控容易失控。回归测试是我现在每个AI项目必做的环节。做法不复杂把评测集固化为自动化测试用例任何代码改动、提示词改动、模型版本升级之前先跑一遍全套评测对比关键指标有没有回退。没有这套机制你根本不敢优化提示词——因为你不知道改完第3个prompt会不会把第1个场景弄坏。7. 个人学习路线总结与避坑清单7.1 我沉淀下来的学习路线图如果从头再走一遍我会把ai engineering from scratch的学习路径压缩成四个阶段阶段一工程基础与模型调用约2周。目标不是学理论而是熟练完成数据输入→模型调用→结果处理的闭环。做3个极简项目文本分类、信息抽取、格式转换。每做一个都强制自己加上输出校验和日志。这个阶段结束时你应该能独立完成一个无交互的单点AI功能。阶段二上下文与提示词工程约3周。系统学习上下文窗口的影响、结构化输出、少样本示例、提示词版本管理。核心产出是能针对一个真实业务场景写出带完整规则的提示词并设计出一套50条以上的评测集来衡量效果。这里的练习重点是可衡量。阶段三RAG与工作流约4周。做知识库问答项目理解切分、嵌入、检索、重排、生成整条链路然后把两三个单点能力串联成工作流每一环都加校验和错误处理。这个阶段结束时你应该具备把复杂任务拆分并工程化落地的能力。阶段四Agent与评估体系约4-6周。实现一个带工具调用的单Agent设计清晰的任务循环和终止条件上加完整的trace日志有条件再尝试多Agent协作。同时把评测、回归、监控体系完整搭建起来。至此你已经有能力独立交付一个中等复杂的AI系统。每个阶段的核心是重复假设-实验-测量-改进的循环而不是单纯堆知识。我的经验是AI工程技能的成长速度和你做实验的频率成正比和你刷教程的时长关系不大。7.2 给从零开始者的避坑清单最后整理一份我在实践中反复踩过的坑每条后面附一句自救建议希望你能少走弯路。坑1沉迷模型原理忽略工程落地。很多初学者把大量时间花在读论文、推导公式上但项目还是不会做。自救建议每天最多花20%时间学原理80%时间做项目用项目倒逼原理理解。坑2跳过评测直接调提示词。没有评测集的提示词优化基本都是自我感觉良好。改完prompt觉得看起来更好了一上线就原形毕露。自救建议任何改动都要有评测数据支撑哪怕只是20条用例的快速对比。坑3盲目追求Agent化和多Agent。简单任务非要用Agent复杂任务直接上多Agent结果成本和不确定性双双飙升。自救建议先工作流后Agent先单Agent后多Agent每一步都要有明确的必要性判断。坑4忽略日志和可观测性。AI系统的debug难度远高于传统系统没有完善的日志一次偶发错误足以让你排查一整天。自救建议从第一天就记录每次调用的完整输入输出、耗时、成本、版本号。坑5上下文塞得太满。总觉得历史信息越多模型越聪明结果Token爆掉、延迟飙升、模型注意力被稀释。自救建议建立上下文压缩和裁剪机制只保留当前决策真正需要的信息。坑6没有模型版本管理。厂商更新模型后你的AI应用效果悄悄变化用户开始投诉你却找不到原因。自救建议生产环境固定模型版本升级前务必先跑整套回归评测。我在实际项目中最大的体会是AI工程这条路没有捷径但确实有正确的绕行方式。把系统思维、工程纪律和模型理解结合起来哪怕起点再低迭代速度都会很快。如果你正站在入口处不知道该往哪走挑一个最不起眼的单点功能把它的评测、校验、监控做完整——这一个闭环走完你看到的就不再是模型能做什么而是系统该如何被构建。这个视角的转变就是from scratch最重要的收获。
语法分析器与DFA词法分析器)
