1. 现在学AI工程到底在学什么前阵子有个朋友问我你会调API会写提示词是不是就是AI工程师了我当时不知道怎么回答因为这个问题我一年前也问过自己。那时候我正做一个内部知识库问答项目模型用的是市面上不错的通用大模型提示词写得也很标准——角色设定、任务描述、输出格式全都齐了。Demo跑通的那一刻我一度觉得AI工程不过如此。可一上真实数据就露馅了用户问上月报销政策在哪模型一本正经地编了个文号问十次同样的问题答案能给你变出三个版本稍微改一下问法整个回答结构就散了。那段时间我很沮丧总觉得是模型不够聪明换了更强的模型还是不稳定。后来我才反应过来问题出在我压根没把AI当成一个需要工程化治理的系统来对待。我调的是模型不是系统。模型的不确定性只是其中一个变量真正的系统还包括数据怎么进、上下文怎么管、输出怎么校验、失败怎么兜底、效果怎么度量。这些加起来才是AI工程。所以这篇东西我想从零把AI工程这件事拆开讲一遍把我自己从会调API走到能交付稳定AI系统这段路上的认知、踩坑、方法论都整理出来。如果你正在做AI应用开发或者准备入行但被各种概念绕晕了这篇文章应该能帮你把骨架搭起来。先说清楚我讲的from scratch不是让你从Transformer论文开始读也不是让你从反向传播手写神经网络。工程视角的from scratch指的是当你面对一个真实业务问题、要在生产环境里交付一个稳定的AI系统时你该具备的最小知识集和完整工作流——从选模型、写提示词、搭Agent到做评测、控成本、管风险。这套东西才是AI工程的真正内核。1.1 AI工程和传统软件工程到底哪里不一样软件工程里你写一行代码它的行为是确定的。输入合法输出就可预期。AI工程最大的区别就是你写的代码只是系统的一部分另一部分是一个你没法完全控制行为的外部模型。我常用一个比喻传统软件工程是在造一台精密机床每个齿轮都咬合得很精确AI工程是在训一只聪明但偶尔闹脾气的狗。你能做的是给它清晰指令、规范奖励、划定边界但你没法保证它在极端情况下不给你整点新花样。这个区别引出三个AI工程独有的核心矛盾不确定性管理模型输出在概率空间里分布同一个提示词可能产生不同结果。工程上需要确定性外壳比如结果校验、重试策略、规则兜底。质量评价困难传统功能对不对用断言就能测AI回答的质量没有单一正确答案。你需要建立针对性的评测体系。成本非线性增长输入越长、步骤越多token消耗翻倍增长一个Agent跑完可能消耗你想象不到的额度。这三个矛盾几乎贯穿了AI工程的所有细节。后面每一章本质都是在跟这三件事周旋。1.2 你需要掌握的最小知识集如果让我给一个AI工程师画一张技能地图大概是这样的层面核心内容入门门槛基础层Python、HTTP调用、JSON数据处理、Git低交互层Prompt设计、上下文管理、输出解析与校验中增强层RAG检索增强、工具调用、记忆管理中高系统层Agent编排、评测体系、成本控制、可观测性高注意这张表的顺序。很多人一上来就冲Agent框架结果提示词都写不利索上下文被塞爆了还不知道为什么。我给的建议是先把交互层做实再谈上系统层。地基没打稳楼盖得越高塌得越快。2. 从零搭建AI工程工作台环境、模型与工具链很多教程上来就让你装框架、配环境我反而想先聊一个大家普遍忽视的问题AI工程的开发环境本质上是为了快速试错而存在的。你的环境布局应该围绕改提示词—跑测试—看结果这个循环设计而不是一上来就搭一个媲美生产环境的K8s集群。我见过不少初学者把时间浪费在配置复杂的分布式环境上结果一个简单的Prompt变更要等半天才能看到效果。在AI工程里迭代速度就是你最大的生产力。你的工作台首先要保证改完能立刻跑。2.1 Python环境与依赖管理的实操建议Python是AI工程的事实标准语言但Python的环境管理对新手来说就是个坑。我早期项目就栽在依赖冲突上项目A需要openai1.0项目B还在用0.28两个项目装在一个环境里互相把对方的库给搞坏了。我的建议是从第一天就用uv或conda做隔离。如果你在macOS或者Linux上直接上uv它比pip快一个数量级而且虚拟环境管理做得非常顺手# 创建一个Python 3.11的虚拟环境 uv venv .venv --python 3.11 # 激活环境 source .venv/bin/activate # 安装依赖 uv pip install openai langchain httpx python-dotenv为什么强调Python 3.11因为很多AI库比如pydantic、lancedb对新版本Python支持更快3.11以上的版本在性能上也有优化。别一上来用最新版Python 3.13有些底层库还没跟上你会遇到莫名其妙的编译错误。另外我强烈建议你把requirements.txt或者pyproject.toml管理成锁定版本状态。AI领域依赖更新极快今天能跑的代码明天升级了transformer库就可能跑不动。锁版本是保证可复现性的最低成本手段。2.2 模型选型别只盯着最强选模型是AI工程的第一步决策但多数人的决策方式是错误的——他们只看基准分数谁排在前面选谁。真实工程里模型选择要综合评估四个维度任务匹配度结构化抽取、分类、代码生成、长文本总结不同任务对模型能力的要求差异很大。一个轻量模型在简单的分类任务上效果可能和一个超大杯模型差不多但成本只有后者的几十分之一。上下文窗口超长上下文不是免费的。窗口越长成本和延迟都越高还容易出现中间迷失模型对长文本中间部分的信息处理不佳问题。延迟敏感度面向用户的交互场景模型响应速度直接影响体验。有些场景必须选推理速度快的模型哪怕效果略差。数据合规要求你的业务数据能不能进第三方模型API是不是必须私有化部署这个问题在项目初期不定清楚后面返工成本极高。我自己常用的一个技巧是建一个任务-模型映射表。把系统里每个AI调用点列出来标注它的任务类型、延迟要求、数据敏感级别再给每个调用点分配不同的模型。一个系统里用多个模型组合是完全正常的别指望一个通吃。2.3 API密钥管理与安全边界AI工程的开发流程里密钥管理看似小事翻车起来是大事故。我见过有同事把sk-开头的密钥直接写死在代码里然后提交到GitHub公开仓库几分钟内就被爬虫抓走账单刷了好几千。我现在的标准做法是所有密钥放在.env文件里并确保.gitignore里忽略了它用python-dotenv或系统环境变量加载对密钥设置用量上限在服务商后台配置月度预算警报生产环境的密钥与开发环境完全隔离通过密钥管理服务如Vault注入这块细节直接关系到钱和声誉从第一天就养成好习惯后面能省掉很多麻烦。3. 上下文工程Prompt不是聊天技巧是最核心的接口Prompt Engineering被一些评论者贬低为文科生活儿我觉得这个观点害人不浅。他们显然没做过复杂的生产级AI系统。事实是在一个典型的AI应用里模型能力的天花板由模型决定但地板由Prompt决定。你再强的模型给它一个模糊的任务描述、混乱的上下文它就能给你输出垃圾。我更喜欢用上下文工程这个名字来代替提示词工程。因为它真正研究的问题不是怎么跟AI聊天而是怎么把信息有效地组织成模型能充分利用的形式。3.1 系统提示词的结构化设计很多人在系统提示词里写一大段自然语言描述想到哪写到哪。模型确实能读懂但很不稳定很容易遗漏关键约束。我推荐的结构化做法是把系统提示词当成配置文件来写。用清晰的段落分区和明确标记# 角色设定 你是一名企业IT支持助手负责解答员工关于内部系统的使用问题。 # 知识边界 - 只能回答与内部系统相关的问题 - 如果不确定明确告知我不确定不要编造 - 涉及安全敏感信息如密码、权限申请引导联系IT服务台 # 回答规范 - 使用简体中文 - 步骤式回答每步不超过3行 - 引用内部文档时注明来源 # 输出格式 返回JSON对象字段包括answer, sources, confidence这样做的核心价值是降低模型的自由发挥空间。你把不确定性压缩到了定义好的结构里后续程序解析和校验就会方便得多。同时我强烈建议在Prompt里加入拒绝规则。比如客服场景里用户问你能帮我写一封辞职信吗模型要是正经回答了体验就很怪。提前写清楚只回答工作相关问题其他问题礼貌拒绝远比事后靠模型自觉来得靠谱。3.2 上下文管理窗口是资金别浪费大模型API按token计费上下文越长、每次调用成本越高。更重要的是超过一定长度后模型对早期信息的注意力会衰减甚至完全忽略。懂行的人会说这是Lost in the Middle现象——模型对长上下文的开头和结尾记得最清楚中间内容容易丢。所以上下文管理的基本法则是只把当前任务真正需要的信息塞进去其他一律不放。具体实操上我用三种手段控制上下文膨胀对话历史的滑动窗口只保留最近N轮对话作为短期记忆更早的内容摘要化后存起来需要时再注入。检索增强RAG不把所有文档塞给模型而是按用户问题先用向量检索找最相关的片段只注入Top-K个片段。指令压缩系统提示词里的固定内容尽量精炼删除所有正确的废话。这里我想特别强调一下RAG。RAG不是简单地把检索出来的文本拼到Prompt末尾就完事。你需要处理检索片段的排序、去重、融合还要在Prompt里明确告知模型你只能依赖下面这些资料回答。我见过太多RAG项目效果差不是向量库的问题而是没把检索结果如何呈现给模型这件事想清楚。3.3 从意图识别到功能调用Prompt提升的实例一个完整的AI功能往往不止一次模型调用。举个例子我的一个项目里有个请假助手功能。用户可能说我明天下午请半天假也可能说下周三我有个手术想休两周。这两句话对应的参数完全不一样。我的做法是先做意图与抽取再做回复生成。第一步用模型抽取出结构化意图和参数用户输入: 我明天下午请半天假 返回JSON: { intent: create_leave_request, params: { start_time: 2025-01-15 13:00:00, duration_hours: 4, type: personal } }拿到这个结构后程序先校验参数是否合法下午是否还有半天请假时长是否超过余额再决定让模型生成最终回复。这样做的好处是关键逻辑时间解析、余额判断由程序保证确定性模型只负责它擅长的自然语言转换。这也是AI工程和纯粹Chatbot玩法的分水岭——模型输出被当作程序逻辑的一块拼图而不是最终答案。4. Agent开发从一次问答到多步任务聊完了单次调用我们来碰真正复杂的东西——Agent。这也是目前AI工程里最热、也最容易被误解的方向。我理解的Agent不是一个能聊天的机器人而是一个能自主规划步骤、调用工具、根据中间结果动态调整路径的执行系统。它解决的问题是用户给一个复杂目标系统把它拆解成若干子任务逐个执行最终拼出结果。4.1 Agent的核心组件拆解一个完整的Agent系统我习惯拆成四个部分大脑LLM负责理解目标、生成规划、判断下一步动作。工具Tools模型可以调用的外部能力比如搜索引擎、代码解释器、数据库查询、内部API。记忆Memory短期记忆当前任务的对话上下文和长期记忆跨会话的用户偏好、历史事实。行动策略Policy决定现在该执行工具还是该回答用户以及对工具结果的解读方式。四者缺一不可。有个常见的误区是给模型接十几个工具就觉得它能干活了。实际上工具越多模型决策就越混乱还有可能接入恶意或错误的工具返回结果。工具接入前一定要做梳理和约束。4.2 工具调用的工程实现函数即工具在OpenAI的新版API和大多数框架里工具调用是通过函数定义来描述给模型的。模型不直接执行代码而是输出我准备调用这个函数、参数是这些由你的程序去实际执行。这里有个关键工程点工具函数的设计直接影响模型的使用效果。我给工具函数命名和写描述时都会站在模型的角度想一想——描述是否清晰参数命名是否直观这个工具和另一个工具的边界是否模糊一个典型的设计实践是{ type: function, function: { name: search_employee_leave_balance, description: 查询员工在某时间段内的请假余额。用于审批请假申请时校验剩余可用天数。, parameters: { type: object, properties: { employee_id: { type: string, description: 员工工号必填 } }, required: [employee_id] } } }注意描述里我写了用于审批请假申请时校验剩余可用天数。这种场景提示能帮助模型在合适的上下文中决定调用它而不是在其他话题里乱调用。工具调用的另一个坑是工具返回的错误处理。真实环境里工具可能查不到数据、超时或返回异常格式。模型看到报错信息可能会一头雾水。我习惯在工具返回里做一层包装错误时返回用户友好提示同时附加一个诊断代码方便模型判断下一步。4.3 多Agent编排的复杂度控制当一个任务需要多个角色协作时比如写一篇市场分析报告需要检索员、分析师、写手三个角色你就进入多Agent编排领域了。这块我踩过的坑比较多目前觉得最有用的经验是先单Agent后多Agent。能用一个大模型加几个工具解决的事就不要拆成三个Agent。多Agent之间的通信损耗和出错概率是呈指数级上升的。明确Agent间传什么。Agent之间传的不该是自然语言散文而应该是结构化数据JSON。散文信息密度低且容易在传递中丢失细节。设置全局监督。多Agent系统一定要有一个编排者角色负责检查每步产出是否符合预期而不是让Agent们自由发挥然后拼结果。我做过一个多Agent项目三个Agent协作处理工单看起来很美实际跑起来经常出现A生成的半成品被B当最终结果用了B又基于错误假设继续操作。后来我改成一个主控Agent若干工具的架构效果反而更稳定。很多场景里Agent数量越少越好。5. 评测体系没有衡量标准就没有交付资格我见过太多AI项目死在这道坎上功能Demo做得很酷一问效果怎么样答不上来。再问如果上线后模型回答变差了怎么办沉默。传统软件工程的QA逻辑无法直接套用在AI系统上。你没法写一个assert说这段回答必须以X开头。AI的答案是开放的、语义等价的、多样化的。所以AI工程必须建立一套自己的评测体系。5.1 评测维度的分层设计我给自己的每个AI功能都建立了一个评测矩阵至少覆盖以下维度准确性回答的事实是否正确是否忠实于给定资料有无编造。完整性问题包含的多个子问题是否都覆盖到了。相关性回答是否切题有没有答非所问、扯无关内容。风格合规语气、格式、长度是否符合产品要求。安全性有没有输出不当内容、有没有泄露系统提示词。其中准确性和安全性是硬指标缺陷即发布阻断完整性和风格合规是软指标属于打磨范畴。5.2 评测集怎么造从10条到1000条构建评测集是AI工程质量工作里最耗精力但回报率最高的事。步骤很简单但做扎实不容易从真实日志里挖把你系统跑过的真实用户输入都存下来这是最宝贵的评测素材。按场景分类把输入归类到不同意图、不同难度、不同边界案例下。人工标注黄金答案针对每个测试用例由人写出理想输出标准。持续追加每发现一个模型答错的case立刻加进评测集防止回归。我在项目里常设一个bad case库。线上模型答错了就把这个case收进去然后优化Prompt或加规则跑通后再上线。这就是AI版的单元回归测试。5.3 自动化评测与人工评测的结合评测怎么执行我的经验是分层跑第一层机器评测。用规则关键词、JSON schema校验和另一个模型来打分。现在各种Judge模型已经能对答案质量给出不错的评估可以作为第一道筛子。第二层人工抽检。机器评测漏网的靠人在关键变更上线前抽检。人工看变化前后的答案对比。第三层灰度观测。上线后收集真实用户反馈和隐式信号如用户是否追问、是否复制答案。机器评测和人工评测各有分工。机器快但可能误判语义人准但慢。AI工程团队每周应该固定排一次评测走查把所有新增bad case过一遍逐个定位是模型问题、提示词问题还是数据问题。这个环节别跳过我所有稳定交付的项目都靠这个循环撑起来的。6. 成本、安全与系统韧性AI工程落地的三座大山最后这章聊的是那些不性感但是决定生死的工程话题钱、安全和稳定性。很多AI项目在Demo阶段惊艳全场一上生产就扑街问题通常不在模型能力而在这三座大山没搬动。6.1 Token成本的估算与优化别等账单出来才后悔我之前做过一个文档问答系统最初版把用户问题加上检索出的15条文档片段全塞进上下文平均每次问答消耗8000个token。高峰期每天几千次调用一个月账单出来我差点没坐稳。后来我做了三个优化成本直接降到原来的三分之一裁剪检索片段从Top-15瘦身到Top-5并且对每个片段做去重和压缩只保留和问题相关的段落。缩短系统提示词把系统提示词里那些你很聪明、你很棒类的无效话术全删掉只保留必要的规则。模型分级简单问题走轻量模型复杂问题才调用强大模型。系统先做一个低成本意图分类把请求路由到不同的模型上。成本优化的核心思维就一句话别让系统的每一步都吃最贵的模型、最长的上下文。能用规则解决的问题绝不用模型能用小模型解决的问题绝不用大模型。6.2 内容安全与数据合规必须提前设计的防线内容安全这个话题在AI工程里不是可选项而是必修课。这意味着你的系统必须具备输入侧的审核与输出侧的过滤能力。我的标准实践是输入侧对用户提交的内容先做合规检测命中敏感词或疑似有害内容直接拒绝进入模型。输出侧模型生成的内容经过二次审核设置禁用词库和分类器拦截异常输出。审计留存保留请求和响应的日志便于出现问题后追溯。另外数据隐私上要注意你的业务数据发到第三方模型API就意味着数据离开了你的网络边界。如果业务场景里包含用户隐私、商业机密或内部敏感信息在架构选型时就得提前考虑私有化部署或使用支持私有化部署的模型服务。这个问题等项目上线后再想往往已经晚了属于架构级返工。6.3 可观测性给AI系统装上仪表盘传统微服务有日志、链路追踪和监控指标AI系统同样需要而且需要得更细致。我搭建AI系统的可观测性时会关注几个关键指标延迟分布P50和P95延迟那两个数字能毒打你。Agent系统多步调用会累加延迟几十秒不返回会让用户疯掉。Token消耗量按功能模块统计哪个功能烧钱最多一目了然。失败率与重试率调用失败、超时的比例以及用户实际看到加载中的时间。反馈回路用户的点赞、点踩、追问比例这是产品层面最真实的质量信号。没有这套仪表盘你就等于在全盲状态下驾驶。更具体的操作是把每一次模型调用的输入提示词、输出结果、耗时、token数都记录到结构化日志里。无论后续排查还是评测回归这些数据都是最原始的素材。特别是当模型升级后效果下降你翻出旧日志对比分析能快速定位是不是某些输出格式变化导致的兼容性问题。韧性设计上我还会主动为模型调用加上三件套超时控制、重试退避、降级开关。模型服务总会有抖动的别说不可能我见过知名厂商的API连续抖动两小时的事情。你的系统必须有Plan B要么用备选模型要么降级为固定规则回复最少不能让用户看到一个转圈转个没完的界面。最后聊两句写了这么多其实都是从我的血泪经验里萃出来的。如果只留一句话那就是AI工程不是调参和写提示词而是围绕不确定内核构建高确定性系统的过程。模型会不断更新工具会推陈出新但工程方法论的内核——评估、隔离、兜底、观测、迭代——是相对稳定、可以穿越周期的。如果你正准备开始自己的AI工程项目我建议先用一个最小闭环跑通一个Prompt加一次模型调用加一层输出校验加一条日志记录再配两个测试case。别想着一上来就搭建完美的Agent森林。从小处着手把这个闭环打磨顺了再逐步往外扩展这条路我走下来觉得最扎实也最不容易翻车。