这几年AI领域最明显的变化，就是“会调API”和“能做AI工程”之间的鸿沟被迅速拉大了。尤其当大模型本身变得唾手可得之后，真正的瓶颈已经不是模型能力，而是围绕模型构建系统的那套工程方法——这正是“ai-engineering-from-scratch”这个主题的价值所在。
我见过太多人从零开始接触AI工程时，一头扎进某个框架或者某个热门模型的调用代码里，结果遇到问题就卡住。根本原因在于，AI工程不是单纯的软件开发，也不是纯粹的算法研究，它是横跨系统设计、数据管理、模型行为理解和软件工程实践的交叉领域。这篇文章我就想从零开始，把AI工程这条路上的关键节点、核心方法以及那些课本上不会写清楚的坑，一次讲透。
如果你是一名正准备转行AI方向的开发者，或者已经入行但感觉自己在“调包”而不是“做工程”，这篇文章应该能帮你把整个知识框架理顺。
1. 先搞清楚“AI工程”到底是什么
1.1 AI工程不是“调API”，也不是“写算法”
很多人对AI工程的第一印象是调用大模型的接口，把用户输入转发给模型，再把结果返回前端。如果你只做这件事，那严格来说只是“API集成工程师”，离工程化还有相当距离。另一种极端是认为AI工程就是研究Transformer架构、自己训练模型，这其实是算法研究员或者机器学习科学家的工作范畴。
AI工程真正的位置是在这两者之间：你要用工程手段把AI能力稳定、可控、可维护地集成到真实业务系统中。这意味着你需要处理模型输出的不确定性、成本波动、延迟瓶颈、数据回流、效果评测、安全边界等等问题。
我个人的定义是：AI工程是一门“驯服不确定性”的工程学。传统软件开发面对的是确定性逻辑（同样的输入必然得到同样的输出），但AI应用面对的是概率性输出。同一句提示词，模型可能给出风格不同、内容略有差异的回复，这种特性会渗透到系统的每一个设计决策里——要不要缓存、要不要人工审核、要不要多模型投票，这些问题都是传统工程里不存在的。
1.2 AI工程的核心能力矩阵
如果给AI工程师画一张能力地图，大致会分成五个维度：
第一，编程与系统工程能力，也就是扎实的软件工程基本功，包括代码组织、接口设计、测试、部署、监控，这部分与普通后端开发高度重合。
第二，模型与提示词工程能力，要理解模型的行为特征、上下文窗口的影响、温度与采样参数的意义，并能写出稳定的高质量提示词来引导模型输出。
第三，数据工程能力，包括数据清洗、向量化、检索系统的设计、评测集的构建与维护，这部分是AI应用效果的上限所在。
第四，Agent与工作流设计能力，当AI从单点问答走向多步骤任务执行时，需要掌握任务拆解、工具调用、循环执行与终止条件的设计方法。
第五，成本与安全治理能力，要能估算模型调用成本、设置预算上限、设计输出过滤与权限控制机制。
这五个维度不是平行的，而是层层递进的关系。最底层是编码能力，往上依次是模型使用能力、数据管理能力、系统设计能力，最顶层是治理能力。绝大多数从零开始的人，问题不是某一层缺失，而是只停留在某一层，没有形成完整的能力栈。
2. 从零起步：地基怎么打
2.1 编程与工具链：先把Python玩熟
AI工程的生态位基本被Python统治，这不是偏见，而是生态决定的。主流AI框架的SDK、数据处理库、模型推理工具链，Python的支持永远是最先、最全的。所以从零起步的第一件事，就是熟练掌握Python，至少做到三层水平。
第一层是语法层面，变量、循环、函数、类、异常处理、列表推导式，这些基础就不必多说了。第二层是工程层面，要求能写出结构清晰、可维护的代码，会用类型注解、dataclass、抽象基类，能组织合理的模块结构而不是把所有逻辑都塞进一个脚本文件。第三层是生态层面，需要熟悉虚拟环境管理（venv或poetry）、依赖管理、常用的数据处理库（pandas、numpy的基本操作），以及至少一个Web框架的基本使用（FastAPI或Flask）。
我见过不少算法背景很强的朋友，写出来的代码一个文件几千行、没有类型注解、错误处理靠print，这种代码放到生产环境里就是灾难。从工程角度出发，我强烈建议在开始AI项目之前，先完成一个小型Web服务的开发——比如做一个带数据库的待办事项API，不需要多复杂，但要把路由、请求校验、异常处理、单元测试这些环节走一遍。
关于环境配置，有一点经验值得提：不要把依赖装在系统Python里，务必用虚拟环境隔离项目。我早期吃过亏，两个项目分别依赖不同版本的pydantic，结果系统环境里互相冲突，排查花了整整一个下午。后来统一用poetry管理，问题再也没有出现过。
2.2 模型基础理论：别怕数学，知道怎么用比会推导重要
很多从零开始的人被AI工程吓住，是因为觉得需要深厚的数学基础。坦率说，如果你要做的是工程落地而非算法创新，数学要求没有想象中高。但如果完全不懂原理，构建系统时会像盲人摸象——不知道为什么上下文长度会限制性能，不知道温度参数调高为什么会让回答变得更“发散”。
我建议的最低限度理论储备包括三块内容。一是Transformer的基本结构：自注意力机制（Self-Attention）的大致原理、位置编码的作用、为什么上下文窗口是有限的。二是一点概率论基础：理解概率分布、采样、温度（Temperature）参数如何影响生成结果的随机性。三是Embedding的基本概念：词向量/句向量是什么、向量之间的相似度如何计算（余弦相似度）、为什么语义相近的内容在向量空间中距离更近。
这里不需要你会手动推导反向传播公式，也不需要你会实现多头注意力机制。你只需要能用自己的话解释清楚“模型是怎么把文本变成数字的”以及“为什么生成是逐token进行的”，这足以支撑后续工程实践。
一个常见的误区是花大量时间啃深度学习理论书籍，结果几个月过去还没摸到模型API。我的建议恰恰相反，先跑通一个完整的AI应用，比如写一个调用大模型做文本摘要的小工具，然后再回头补充理论基础。工程实践在先、理论补课在后，学习效率会高得多。
3. Prompt Engineering：每天都要用的基本功
3.1 结构化提示词的骨架
如果说AI工程有什么技能是每天都在用的，那一定是提示词工程（Prompt Engineering）。很多人觉得写提示词就是“用自然语言告诉模型你要什么”，这话对了一半。真正稳定、可靠的提示词，不是一段随意的自然语言，而是一个结构化的模板。
我常用的提示词模板包含五个组成部分：角色设定（Role）、任务描述（Task）、输入数据（Context）、输出格式（Format）、约束边界（Constraints）。
角色设定的作用是激活模型在对应领域的知识分布，让模型以特定专业视角处理任务。任务描述要足够具体，比如“将以下客户反馈分类为产品问题、配送问题、客服问题或其他”，就比“分析这段客户反馈”好得多。输出格式可以约束为JSON对象并给出示例，这样系统层可以直接解析，省去从自由文本里提取结构化信息的痛苦。约束边界写清楚不能做什么，比如“不要推测用户未明确表达的意图”、“不确定时输出unknown，不要编造”。
一个细节值得注意：提示词的排版方式会影响效果。模型对文本结构的敏感度远超想象，使用分隔线、编号列表、缩进等方式明确区分各部分，比把所有信息堆在一段话里效果好得多。实测下来，同样的任务，结构化提示词与普通提示词的成功率差距可能有百分之二十以上。
我之前做过一个客服工单分类系统，初期用自然语言提示词，分类准确率只有78%左右。后来花了两个晚上把提示词完全结构化，明确角色、任务、格式，并在几个容易混淆的类别上给出了示例，准确率提升到了89%。这个例子说明提示词本身是值得投入时间打磨的工程资产。
3.2 提示词调试的实操方法
提示词调试跟代码调试不一样，不会有报错信息告诉你哪里出了问题，你只能通过输出结果反推哪里需要调整。在实践中我总结了一套有效的调试流程，跟读者分享一下。
第一步，固定变量。每次只调整一个提示词要素，其他保持不变。如果你同时修改了角色设定和输出格式，出了问题很难判断是哪一处的锅。
第二步，建立评估样例集。挑选20到30个有代表性的输入案例，覆盖不同的难度和类型，每次修改提示词之后，在这个样例集上跑一遍，统计成功率。不需要自动化，手动跑也行，但样例集必须稳定，不能今天一批明天换一批。
第三步，针对失败案例做深度分析。分类错误的案例不要只看正确答案，要看模型输出“错在哪里”。是理解偏差？是指令没遵守？还是信息缺失？不同的失败模式对应的调整策略完全不同。
第四步，善用“思维链”（Chain of Thought）技巧。在任务涉及推理或判断时，提示模型先逐步分析再给出结论。比如处理多步骤判断任务时，可以在提示词中加入“请先列出你考虑的关键因素，再给出最终结论”，这通常能显著提升复杂任务的准确率。
调试提示词最耗时的不是写，而是测。所以建议把评测和提示词版本绑定管理，用代码仓库记录每次修改，配合commit信息写明改动原因。我见过一个团队因为提示词版本没有管理，线上效果异常时无法回滚，最后只能人工一条条对照聊天记录找原因，颇为狼狈。
4. 接住大模型：从API到RAG
4.1 API接入的工程细节：温度、Token与重试机制
提示词调好之后，接下来就是工程化接入。调用大模型API这件事看似简单，但里面藏着不少工程细节，处理不好生产环境就会出各种幺蛾子。
先说关键参数。温度（temperature）是最常调的参数，它控制的是生成结果的随机性。温度越低，输出越确定、保守，适合分类、抽取、格式化输出等任务；温度越高，输出越发散、有创造性，适合文案生成、头脑风暴等场景。实际项目中我通常把温度设置在0.1到0.4之间，极少超过0.7。
还有Max Tokens参数，它限制生成结果的最大长度。不少人忽略这个参数，导致模型输出被截断，系统拿到半截文本就往下游处理。设置时要注意估算业务所需的最大长度，同时考虑提示词长度，两者之和不能超过模型的上下文窗口。
重试机制是大模型API调用中极其重要的一环。模型服务经常会出现瞬时抖动、限流、超时等问题，如果代码不做重试，用户会直接看到报错。我在生产代码里通常用指数退避策略，首次失败等待1秒后重试，再失败等待2秒，然后是4秒、8秒，最多重试4到5次。同时要处理Token速率限制（Rate Limit）：遇到限流错误时，不仅要退避重试，还要考虑降低并发请求数量。
超时设置也容易被忽略。默认的请求超时时间通常较长，但实际生产中你应该根据自己的业务容忍度设置更短的超时，比如10秒或15秒，超时之后走降级逻辑（返回缓存结果或提示用户稍后再试）。不要盲目地把超时设成180秒，然后让用户傻等三分钟。
4.2 RAG落地：检索增强生成的关键环节
RAG（Retrieval-Augmented Generation，检索增强生成）是目前AI应用中最主流的知识库方案。核心思路是：先把文档切块、向量化存入向量数据库，查询时检索最相关的文本片段，拼接到提示词中作为上下文，让模型基于这些材料回答问题。
RAG看起来简单，实际落地时有几个关键决策直接决定了效果上限。
切块策略首当其冲。切块过大，向量化之后的内容主题模糊，检索精度下降；切块过小，单块信息不完整，模型无法理解上下文。我一般会结合文档类型来定：段落结构清晰的用段落切块，长文手册类按固定字符数切块（通常500到800字），并设置重叠区域（例如与上一块重叠100字），避免关键信息恰好被从中间截断。
向量模型的选择同样关键。不同的Embedding模型在语义理解能力、语言适应性和维度大小上差别很大。维度越高通常表达越精细但计算成本越高，中文场景还需要考虑模型对中文的支持程度。这里没有绝对最优，建议在自己的知识库上分别测试几个候选模型，再做权衡。
检索策略方面，单纯靠向量相似度召回往往不够。大多数生产级RAG系统会采用“混合检索”：向量检索负责语义召回，关键词检索负责精确匹配（比如产品型号、人名、专有名词），然后通过倒数排名融合（RRF）算法合并结果。我实测过一次，在包含大量专业代码和术语的文档库中，混合检索比纯向量检索的准确率高出十几个百分点，这个提升非常可观。
还有召回数量的设置，不要贪多。很多人以为检索出的片段越多越好，实际上过多无关片段会干扰模型判断。通常3到5个有效片段已经足够，关键是保证这几个片段与问题高度相关。我之前调试一个售后知识库问答系统，把召回数量从5降到3之后，回答准确率反而提高了8%，因为模型不再被弱相关片段误导。
5. Agent工程：AI从回答问题到完成任务
5.1 Agentic Pattern：从“问答”到“行动”的跃迁
如果说RAG让AI具备了知识，那么Agent让AI具备了行动能力。核心区别在于：问答系统的终点是产生文本回复，而Agent系统需要完成一系列具体任务——查数据、调接口、做计算、执行工具，再基于执行结果继续推进。
从工程视角看，Agent不同于单个模型调用，它是一个循环控制系统：模型在这个循环中扮演“决策者”角色，每轮迭代观察当前状态，决定下一步动作（调用哪个工具、是否完成任务），执行动作后观察结果，再做下一步决策。直到任务完成或达到终止条件。这就是当前业界常说的Agent Loop，也叫Loop Engineering。
设计这个循环最需要注意的，是不要让模型在任何一步“自由发挥”到失控。Agent循环的框架代码相对简单，难点在边界条件的控制上：失败重试不能无限死循环，动作次数要设置上限，预算要限制，工具调用结果要校验。
我强烈建议从零开始自己实现一遍Agent循环，而不是直接上框架。你只需要一个模型调用接口和几个Python函数，就能写一个最小可用的Agent。自己实现一遍的好处是你会真正理解工具的注册机制、函数调用的参数解析、循环终止条件是如何运作的。框架给你封装好了便利，但也把关键逻辑变得黑盒化了。
5.2 Harness Engineering：为Agent建好“缰绳”
Harness Engineering是近期Agent开发中逐渐被关注的概念，字面直译是“挽具工程”，其实就是Agent控制系统中的约束与安全带设计。它的核心理念是：Agent的能力越强，越需要完善的控制机制来确保其行为与预期相符。
具体到工程实现，Harness包含几个层次的约束。第一层是工具准入控制：Agent能调用哪些工具、不能调用哪些工具，必须是显式声明的，而不是让模型自由发现。第二层参数校验：模型生成的对函数调用的参数必须经过严格校验，防止模型编造不存在的参数值，这一步通常借助Pydantic或JSON Schema做类型和范围校验。第三层是权限控制：Agent使用的API密钥应遵循最小权限原则，比如一个只需要读取文档的Agent，不应该持有写数据库的权限。
还有一层常被忽视的是“阶段性护栏”：在Agent执行高风险动作（如发送邮件、删除数据、修改线上配置）之前，设立审批流。轻量做法是让系统拦截，输出确认请求交给人工决策；自动化做法是设置规则，比如金额超过阈值或操作对象是生产环境时自动暂停。
这些看起来像“限制了AI”，但实际是为了让Agent能放心干活。没有Harness约束的Agent在演示环境里看起来很酷，到了生产环境就是事故高发区。我在一个自动化测试项目中见过Agent因为模型幻觉，把测试数据库误当成生产库连接，如果不是连接配置恰好没有写权限，后果不堪设想。
6. 工程化落地：评测、监控与成本控制
6.1 评测体系：AI工程的重中之重
传统软件工程有单元测试、集成测试，AI工程同样需要评测体系。但AI的评测不是简单比对输出值，而是需要一套更灵活的评估方法。
离线评测集是最基本的一层。你至少要维护100条以上的评测用例，覆盖主要业务场景、边界情况与典型疑难场景。每条用例包含输入、预期行为和判断标准。判断标准不一定是精确答案，可以是“是否包含关键要素”或“格式是否符合要求”。利用大模型作为评测员（LLM-as-a-Judge）是当前最常用的自动化评测方式，让一个强模型充当裁判，对系统输出打分。这种方式效率高、成本低，但要注意裁判模型自身的偏差——建议定期人工抽检裁判结果的合理性。
在线评测则要关注真实用户的使用反馈，包括用户点赞、点踩、举报等显式数据，也包括“用户提问后是否重复追问”、“是否放弃当前会话”等行为信号。
评测的最终目的不是得到一个分数，而是创造一个可以持续迭代的闭环：发现问题、定位原因、修改提示词或检索策略、重新评测、再上线。没有评测体系，所有改动都靠“感觉”，这是AI工程里的巨大隐患。
6.2 监控、成本与安全底线
AI应用上线之后，监控体系要覆盖准确率与运行时状态两个维度。准确率层面，要建立一个抽样审计流程，每天随机抽取一定比例的用户会话，人工判断回复质量。成本层面，要密切跟踪Token消耗量。很多人上线AI应用后收到巨额账单，就是因为没有监控Token消耗。
Token成本要提前预估和设置预算上限。我通常会在代码里加一道“成本检查”逻辑：每次请求完成时，把该请求消耗的Token数和累计消耗写入日志或指标系统，达到阈值时触发告警甚至熔断。还有一个实用建议是启用缓存：相同或相似的请求可以直接复用缓存结果。对于高频的客服咨询、FAQ类场景，缓存可以把成本降低一半以上。
安全方面有几条必须守住的底线：输入侧的提示词注入防护（用户可能在输入中夹带“忽略之前的指令”来诱导模型输出敏感内容）、输出侧的内容安全过滤（禁止模型生成违规内容）、系统侧的权限隔离（Agent工具凭证与主系统凭证分离）。我见过一个小团队上线AI客服，忽略了提示词注入防护，被用户套出了内部数据库结构，幸运的是没有造成实际损失，但这给了团队一个深刻的教训。
从零开始做AI工程，最忌讳的是想一口吃成胖子。我见过太多人一头扎进Agent框架，还没搞清楚Prompt和RAG的基本功，就去追最新的多Agent编排，结果做了一个星期连最小可用版本都拿不出来。我的建议是把时间花在基本功上：把Python工程能力打扎实，把提示词调出稳定的效果，把RAG的检索质量做到可用，再考虑Agent。地基打牢之后，上层的一切都是水到渠成。
