ai-engineering 这个词最近两年几乎成了招聘网站上的万能标签但我见的更多的是被这个标签吸引、却不知道从哪下手的人。我自己当初也是从零开始不会训练模型没读过完整的 transformer 论文甚至没搞懂 attention 机制能怎么落地。真正把我拉进这条路的不是补了多少数学基础而是把一个又一个 LLM 能力做成能被真实用户使用、能被测试、能回滚、能监控的系统。这篇文章想写给所有想认真踏入 ai-engineering 的人尤其是那些没有算法背景、但想靠工程能力吃饭的朋友。先泼一盆冷水从零开始不等于从线性代数开始更不等于先啃三个月论文再动手。你的第一个目标应该是“让一个最小但完整的 LLM 功能跑起来”然后用工程视角把它推翻重来。1. 先厘清边界AI 工程究竟解决什么问题1.1 “AI 工程师”不是“机器学习研究员”很多人一听到 AI 工程第一反应是“我要不要回去学 Python、学 PyTorch、把几大经典模型复现一遍”。这个想法不能说错但它混淆了两个完全不同的岗位。研究员的核心目标是探索模型能力边界工作成果通常是论文、新架构、训练方法AI 工程师的核心目标是利用现有模型搭建产品工作成果是稳定运行的系统、可控的成本、可评估的效果。两者当然有交叉但一个从零开始的人如果非要把研究路线当成入门路径大概率在第三个月就放弃因为你发现自己既缺数学基础又缺分布式训练资源还看不到任何产出。我后来给自己的定位很简单把大模型当成一个能力很强但脾气很怪的外部组件我的工作就是设计好它周围的输入、输出、流程、兜底和监控。就像请了一位顶级大厨到后厨研究这道菜为什么好吃是食品科学家的事我要负责的是菜单设计、食材供应链、出餐节奏和客人投诉处理。1.2 常见误解有 API Key 不等于会做 AI 工程圈子里还有另一个极端觉得“调一下 API 谁不会Prompt 复制粘贴就行”。这种心态会让项目死得更快。API Key 只是给了你进入厨房的钥匙你能不能稳定出餐完全是另一回事。一个典型的翻车场景你写了个 Prompt让模型从合同里抽取关键条款自己试了几份文档觉得效果不错于是直接上线。结果用户传进来一份 80 页的 PDF里面有扫描件夹杂表格模型直接漏掉最关键的一条“违约责任”。你怎么办你要不要重新定义输入格式要不要加 OCR 预处理要不要做条款分类要不要设计二次校验这些都是 AI 工程要解决的事情而它们没有一件是靠换 Prompt 能解决的。1.3 一句话理解 AI 工程用一句话总结就是把模型能力封装成稳定、可信、可交付的软件功能同时处理掉模型带来的不确定性。它更像传统软件工程的一次延伸而不是一门全新的玄学。所以我后面讲的每一个章节都不会让你去卷训练而是围绕工程链路展开选型、调用、检索、控制、评估、监控、上线。2. 从零开始的选型原则先求稳再追新2.1 编程语言Python 是路径依赖但不是唯一答案绝大多数教程和框架都默认你会 Python所以如果你完全零基础Python 是最省事的选择。它语法简单生态全LangChain、LlamaIndex、FastAPI 全是它的天下遇到问题搜索引擎一搜一大把。但如果你本来就是个前端或后端工程师只有 JavaScript/TypeScript 底子我不建议你强行转 Python。现在几个主流模型厂商都提供了 Node.js SDKLangChain.js 也在快速追赶。你完全可以用 TypeScript 写出同样高质量的 AI 应用关键是你要会处理异步流、处理 JSON 解析、处理接口超时这些对你来说不是难事。我的建议是别为了学语言而学语言你的工程经验比语言本身值钱得多。如果一定要给个标准团队代码库用什么你就用什么没有团队约束就选 Python。2.2 模型选型API 优先开源要等场景明确后再碰从零开始阶段我最推荐直接使用大模型厂商提供的 API而不是自己部署开源模型。原因有三个第一API 的模型质量通常高于你能自己跑起来的中小开源模型尤其在指令跟随、长文本理解、多轮对话这些工程场景上差距明显第二API 没有硬件门槛你不用为了一张显卡焦虑也不用操心 CUDA 版本冲突第三API 有清晰的计费逻辑你能训练自己的成本敏感度这对 AI 工程非常重要。开源模型什么时候值得碰等你明确知道自己的场景对性价比极其敏感、且数据隐私不允许出内网时再考虑部署私有模型。到那时候你已经有工程经验了踩坑成本会低很多。2.3 框架选型先裸写三遍再引入框架我很建议新手用一种反直觉的做法头三个小功能不用 LangChain 这类框架直接用你选的编程语言调模型接口。例如 Python 里就写一个httpx.post()拼一个 OpenAI 格式的请求体拿到响应再解析 JSON。这三遍裸写会让你把最关键的概念刻进脑子里messages数组、system/user/assistant三种角色、temperature含义、token 数量限制、JSON 输出格式怎么约束。有了这个基础你再去看 LangChain 或 LlamaIndex就明白它们只是把上面这些步骤封装成好用的对象和链条。此时你再决定用不用才不会被神秘抽象劝退。框架的价值是提升熟练者的效率而不是帮新手逃避细节。我见过太多人用 LangChain 写出来一个自己完全看不懂的问题链路出了问题只能靠重装重启解决。2.4 记住这张基础选型表选型项从零开始阶段建议理由语言Python或已有经验的 TS生态全、资料多模型主流厂商的托管 API质量高、无硬件门槛编排框架先不引入裸写 2-3 个功能后再选避免过早抽象化服务框架FastAPIPython或 Express/NestTS生态成熟、部署方便存储PostgreSQL pgvector你更需要服务端数据存储向量只是其中一个字段向量检索先用 PG 自带的向量索引避免给项目硬加一个分布式向量库很多人一上来就部署 Milvus、Weaviate 这种专业向量数据库结果全项目就几千条数据白交运维成本。pgvector 在数据量百万以下完全够用等规模大了再迁移也不迟。3. 从一条 API 请求到可控业务系统3.1 先把最基础的一次调用写得明明白白不管是哪个厂商你都会发现这套调用逻辑大同小异。我把一个最简单的调用拆开看import httpx import os api_key os.environ[LLM_API_KEY] url https://api.openai-like.example.com/v1/chat/completions payload { model: your-model-name, messages: [ {role: system, content: 你是合同审查助手只输出 JSON。}, {role: user, content: 请抽取下面合同中的违约责任条款并判断责任是否明确\n contract_text} ], temperature: 0.2, max_tokens: 1000, }这段代码里真正值得关注的不是 URL而是三个核心设计点把系统提示词system prompt和用户输入分开因为系统提示词是你要反复维护和版本管理的用户输入则是不可控的让模型输出 JSON并且在 Prompt 里明确要求这是为了后续程序化解析哪怕有些厂商有 structured output 特性你也要在 Prompt 里写清设一个偏小的temperature因为业务场景里我们要的是稳定抽取不是让模型自由发挥。从零开始的人往往忽略max_tokens结果模型输出一半就被掐断返回一个截断的 JSON程序直接报错。所以你还要在代码里对响应做完整性校验解析失败就重试或者告诉用户“结果超长请分段提交”。3.2 把 Prompt 当成代码来写很多人把 Prompt 当成“跟 AI 说话的话术”但在工程视角里Prompt 是稳定接口的一部分。我会把 Prompt 模板单独放进配置文件或版本控制仓库而不是散落在业务代码里。理由很简单上线后你不可避免地要调 Prompt调 Prompt 就必须能对比历史版本不然你根本不知道哪个改动让效果变差了。我自己常用的一种模板结构是【任务角色】你是…… 【任务目标】你的任务是…… 【输入格式】用户会给你…… 【输出格式】你必须输出 JSON字段为…… 【约束条件】如果不确定不要编造请返回 unavailable这四段式的价值是模型对结构化的约束响应更稳定比你在自然语言里揉杂所有要求好得多。注意不要用“如果你不确定就千万不要编造”这种绕弯的否定句式模型更容易服从“返回 unavailable”这类明确的正向指令。3.3 RAG 不是搭积木切分、嵌入、检索都要有自己的逻辑当你想让模型回答“基于某一份内部文档”的问题时RAG检索增强生成几乎是标准答案。但网上把 RAG 说得太简单了好像装一个文档加载器、连一个向量库、调一个 embedding 接口就完了。真实问题是用户文档千差万别检索链条才是决定“AI 有没有用”的关键。切分文本时不要机械按固定长度截断。一份合同里有“定义条款”“履行条款”“违约责任”如果按 500 字硬切一个条款可能被切得七零八落。好的做法是尽量按文档结构切Markdown 按标题HTML 按标签PDF 按页和段落。然后再给每个分块加一个重叠区域让跨块的语义不要断裂。我在项目里常用的策略是标题级块 段落级块 语句级小块做多层次索引这样不同粒度的检索都能命中。检索也不能只靠向量。向量对语义相近的词有效但对精确匹配的词反而会失灵。比如你要搜“违约金 10%”向量检索可能找到一堆“赔偿金”“扣除”相关段落就是漏了那个写着一模一样数字的条款。工程上我建议用混合检索先做关键词检索BM25和向量检索再把两路结果用 RRFReciprocal Rank Fusion合并最后交给重排模型挑更相关的 Top-K。这套组合虽然听起来复杂但每一步都有清晰目的你可以从“向量检索优先”逐步加组件。3.4 智能体Agent循环能力越大越要框住边界对话式智能体是 ai-engineering 里最热的部分但我必须提醒你Agent 的本质是个循环模型不断判断要不要调用工具、要不要继续执行而这个循环本身就是出错的高发区。从零开始做一个 Agent最稳妥的路径不是先跑“自动规划”而是先做一个极其受限的工具调用器。你给模型提供一份工具清单每个工具包含名字、功能描述、输入参数 JSON Schema模型按照约定返回一个工具调用指令你的代码去执行工具再把结果塞回对话。这个循环里大多数不稳定因素来自模型“自作主张”——它可能调用了没有权限的工具也可能在拿到错误结果后强行圆一个答案。所以你要做三件事在系统 Prompt 里明确“你的输入输出只能遵循 JSON Schema”在代码里为每次工具调用设置超时和重试上限在最外层加一道人工可打断的确认机制尤其当工具涉及高权限操作时。记住一个原则Agent 的自主性应该和业务风险成反比。业务影响越小你可以给它越多自由业务影响越大请老老实实引入审批流。4. 没有评估就没有发布建立可量化的检验体系4.1 脱离评估谈模型效果都是讲故事我做项目最怕听到的一句话是“我试了一下效果挺好的。”这句话在演示现场没问题但一旦要交付就必须换成另一句话“在 200 条测试样本上正确率 85%失败集中在表格识别和长文本漏检两类问题。”AI 工程和传统开发最大的差别在于传统开发的输入输出是确定性的你能断言代码对错LLM 应用本质是概率性的你只能通过一组测试样本来估算它的质量分布。所以一个不含评估集的项目是不完整的。从零开始建立项目时请先花时间和业务方一起整理一份 golden set也就是“一批覆盖典型场景、包含正确答案的测试问题”。这份测试集不要求一开始就很大50 到 100 条就够。但必须包含三类样本正常样本、边界样本超长文本、缺字段、错误格式、明显的坑样本模糊问题、多意图问题。以后只要你改了 Prompt、换了模型、调整了 RAG 切分策略就在这份集子上跑一遍比较效果是上升还是下降。没有这个过程你的项目每一步都像在走钢丝。4.2 LLM 当裁判可以但要给自己留后路当你的测试集答案需要判断“答得对不对”时人工逐一评估成本很高所以很多人引入 LLM-as-judge也就是让一个大模型为你的模型输出打分。这个方法可以用但有明显缺陷不同模型对同一输出的打分风格不同而且它往往给“看起来流畅”的答案更高分而不是给“信息准确”的答案更高分。我的折中方案是用 LLM 打分做初筛把明显高分和明显低分直接标记中间地带全部转给人来审。同时每次用 LLM 打分时要求它输出判定理由并收集它的误判案例。你会发现几个星期之后你能总结出一套针对自己业务的打分标准这时候才是真的把评估体系建立起来了。4.3 可观测性你能回答这些运营问题吗上线阶段有一个问题必须能回答线上一次完整请求模型调用了几次花了多少钱平均耗时多少每次调用的 input 是什么output 是什么哪一步最容易失败这些问题的答案全部来自可观测性建设。你至少要做两件事。一件事是结构化日志。每次模型调用的前后把 token 数、纠错重试次数、耗时、返回状态、上下文里命中哪些文档片段都记录到日志系统里。这是你日后定位所有线上问题的第一手资料。另一件事是 tracing 追踪。一个复杂的 RAG 或 Agent 流程可能涉及十几个步骤每一步都可能成为瓶颈。你要在代码里给这些步骤打上链路标识把它们串成一个完整 trace。成熟的工具会用 OpenTelemetry 这类标准但从零开始哪怕你用个简单脚本把 trace ID 串进日志也比没有强。5. 三阶段动手路线从玩具到能上线5.1 第一阶段复制一个最小产品不求完整但求闭环第一个项目不要挑战“公司级智能客服”“全自动合同审查系统”那些目标会把你逼疯。我建议第一周做一个自己会用的命令行小工具。比如输入一段会议记录让它输出待办事项列表和负责人输入一段营销文案让它按你的语气风格重写。为什么从命令行开始因为你能省掉做前端的时间把精力全部集中在调用模型、解析输出、本地保存这些核心环节上。你只需要 Python 脚本 API 文件存储就能完成第一次“输入—处理—输出”的闭环。跑完这个你会对 token 成本、响应时间、解析失败概率有一个直观感受这些感受比任何教程都宝贵。5.2 第二阶段做一个带 RAG 的知识库问答系统第二个项目建议做一个“本地文档答疑助手”题材可以选你最熟悉的领域比如你自己的技术笔记、公司产品手册、或者一份开源项目的文档。这个阶段要把第 3 章的内容实践一遍文档切块、向量化、混合检索、重排、带引用的回答。做一个评估集要求它每个回答都自带引用来源比如“根据 /docs/2024/guide.pdf 第 3 页”。然后故意塞几篇格式混乱的文档进去观察系统如何出错。第二阶段的目标不是做出完美产品而是让你亲手体会到 RAG 在每个环节的坑为什么切得太大检索会失焦为什么两篇相似文档会让模型串答案这些体会才是你后续所有架构决策的依据。5.3 第三阶段把前面所有成果变成可上线的服务第三个项目请把第二个项目包装成真正的服务用 FastAPI 包一层 HTTP 接口加上鉴权、限流、超时控制把日志和评估集都接进来让每次调用都能留痕最后部署到云平台或一台自己的服务器上持续跑两周。两周后你会发现真正的问题不在模型效果而在“今天返回 503 了”“某个用户上传的 PDF 解析超时了”“某次请求因为重试逻辑而重复调用账单超出预期”。这些线上事故才是 AI 工程师必须处理的主战场。当你通过这三步走下来你简历上就能写清一个完整的项目故事从文档处理到检索增强从 API 封装到监控告警全链路自己搭建。6. 从零最容易踩进的坑数据、上下文和“看起来很好”6.1 数据质量永远优于模型参数新手常常沉迷研究哪种 Prompt 更神奇、哪个模型更强却忽略了喂给系统的文档本身质量。如果你把一份扫描得歪歪扭扭的合同、一份全是术语缩写的内部手册、一份排版混乱的 Markdown 丢进 RAG模型再强也无法输出靠谱答案。我在实际项目里处理的最耗时环节永远是数据清洗。扫描件要过 OCR缩写要补齐词典重复文档要做去重表格要转成适合检索的格式。这些工作不在模型调优里但对最终效果的影响通常在模型调优之上。记住一句话垃圾进垃圾出这个老规律在 AI 时代依然成立。6.2 上下文窗口变大了但“长文本幻觉”反而更危险现在很多模型支持超长上下文但越长反而越容易忽略中间内容。你可以把模型想象成一个注意力有限的人你把 100 页材料一次性丢给它它大概率只“认真看”了开头和结尾。所以长上下文不是 RAG 的解药RAG 的意义恰恰是裁剪信息只把最相关的三五个片段交给模型让它聚焦在真正重要的内容上。在实际评估里我发现采用 RAG 前后模型在事实准确率上的差异可能大到 30 到 40 个百分点。不是长上下文模型不好而是它不擅长在你的 100 页文档里精准找出第 57 页那个关键条款。工程上我们宁可多做一道检索也不要赌模型的“毅力”。6.3 看起来很好的 Demo上线三天就翻车这种坑经历过一次就忘不掉。开发时你精心挑了几条顺眼的新数据测试模型答得漂亮领导和客户都很满意。上线后真实用户提问五花八门系统准确率肉眼可见地往下掉。原因很简单你的测试集严重偏向“你所期待的输入”没有覆盖真实世界里的脏数据、歧义、口语化措辞和刁钻业务问题。对策其实前面已经说过尽早建立包含边界样本的评估集收集线上真实失败案例定期把它们补回测试集里。你要让系统越变越好而不是只让汇报越来越好。从零开始的人花在“让失败案例暴露出来”上的时间永远比花在“调优高光案例”上的时间更值。6.4 别让模型自己宣称“我很确信”最后这个坑很隐蔽你问模型对回答有多少把握它会非常自信地给你一个分数这几乎不可信。模型的置信度表达和事实正确率之间存在很大的偏差尤其在你不给它足够上下文时它依然会“礼貌而自信地”编造一个答案。工程上的兜底办法是设计输出规范要求模型在“没有足够依据”时明确返回insufficient_context而不是硬答。再用一个简单规则发现这种返回就触发“请提供更多信息”的引导话术。你看这又回到了系统设计和规则控制而不是指望模型突然变得诚实。7. 复盘如果让我重新走一遍从零开始的 ai-engineering如果时间能倒流我会给自己三条最实在的建议第一条不要从工具开始要从任务开始。先找一个你真正不想手动做的重复性工作比如整理周报、梳理会议纪要、检索自己收藏的笔记然后让模型帮你完成。工具会随着任务自然涌现而不是反过来绑架你。第二条把失败当成进步指标。当我开始把自己的失败案例整理成测试集时我的水平才真正开始飙升。每一个答错的问题都是系统改进的方向一个从零开始的项目第一个月的目标就是“收集足够多失败的样本”而不是“零失败”。第三条尽早做完端到端闭环。哪怕最初版本很粗糙也要让它具备生产三要素输入、输出、日志。因为日志会告诉你用户真正问了什么、系统哪里最痛这些信息比一百遍手推 Demo 都要真实。ai-engineering 这条路走到最后你会发现它并不是什么神秘魔法而是把“概率模型”变成“可靠系统”的一门手艺。模型本身一年比一年强但围绕它构建的工程能力——数据、评估、监控、控制、应急——才是你真正积累下来的资产。希望这些从零开始的经验能帮你少走一点我当年走过的弯路。