很多人以为AI工程就是从零把一个大模型跑通或者把Prompt写得花里花哨再或者调一个开源模型让它输出稳定。但真正动手以后你会发现这些东西只是冰山一角。我做了十几年软件工程这两年All in AI工程方向最大的感受是会调API、会写Prompt和能交付一个稳定可用的AI系统中间隔着一条巨大的沟。这篇文章就想把这条沟到底怎么填从零开始到底该学什么、做什么、避哪些坑跟你聊透。先说清楚适用人群。如果你只是想拿AI做个玩具Demo这篇文章里的很多东西你用不上但如果你是真想把AI能力落到一个业务系统里让它给用户提供持续可靠的价值那这篇文章说的每一件事都值得你记下来反复对照。我会用我自己从零搭建AI Agent、做AI测试开发、把AI能力嵌入团队研发流程的经历把整个路径拆开来讲。1. 为什么“从零开始做AI工程”比搭个Demo难十倍1.1 会调API不等于会做AI工程我见过太多人踩同一个坑拿到一个大模型的API写个Prompt让它生成一段文字跑通了就觉得自己会AI工程了。然后放到真实业务里发现输出不稳定、格式偶尔错乱、有时候还会一本正经地胡说八道上线两周就被用户骂回来了。这里面的误解在于调API是单个接口的事AI工程是一整套系统的事。你调API只需要考虑输入输出做AI工程需要考虑输入从哪来、输出往哪去、中间失败怎么办、异常数据怎么兜底、用户怎么反馈、模型升级了会不会影响现有行为、成本怎么控制。任何一个环节出了岔子整个系统都会崩。我最早做一个内容生成工具时前三天就把模型调用跑通了。但我花了整整两周处理这堆事用户传进来的PDF里有一些扫描图片不是纯文本模型偶尔输出Markdown格式但用户要HTML请求超时后用户重复点击导致重复扣费还有模型给出的答案里混着过时信息没有来源。这些问题没有一个是“Prompt写得不够好”导致的但它们才是AI工程真正要解决的问题。1.2 AI工程的真实工作流输入噪音、上下文、评估闭环从零开始做AI工程我建议你先在脑子里建立一个工作流框架而不是急着写代码。这个框架长这样输入端数据从哪来格式是否统一有没有噪音需不需要清洗、切分、转换上下文管理模型需要哪些信息才能给出正确回答怎么把相关信息拼装进Prompt超出上下文窗口怎么办推理端选哪个模型用多少温度要不要带工具调用超时重试策略如何设置输出端怎么保证格式稳定怎么校验内容正确性怎么拦截幻觉评估闭环怎么知道现在的输出比上周好怎么用测试样例集做回归人机协作哪些场景要保留人工确认哪些决策可以自动执行这六个环节缺一不可。很多人只盯着中间那一段“推理端”觉得模型厉害就行。但真实系统里输入端和评估端往往才是决定成败的。举个例子你让AI从用户聊天记录里提取结构化信息如果聊天记录里有错别字、表情符号、长对话截断模型再强也白搭。1.3 我踩的第一个坑Prompt写对了系统还是崩了我印象最深的一次是我做了一个客服问答机器人。一开始我精心设计了一套系统提示词把角色、语气、回答边界、引用规范都写进去了单测时怎么问都很好。结果一到线上用户问了个“你们有没有那个什么套餐来着”模型答得驴唇不对马嘴。后来排查原因发现不是Prompt的问题是用户消息里那个“那个什么”根本没有对应的知识库内容模型在知识库里检索不到相关信息只能靠猜。这让我意识到Prompt只是AI工程里很小的一块拼图真正的功夫在Prompt之外——检索、上下文构造、兜底逻辑、提示用户补充信息这些才是让系统稳定运转的基石。所以如果你也想从零开始做AI工程不要一上来就钻进Prompt调优。先搭出完整的工作流骨架再回来打磨Prompt你会少走很多弯路。2. 我把AI工程拆成的四块核心能力数据、模型、提示词、工程化做AI工程需要的能力很杂。我自己的经验是把它拆成四块数据能力、模型能力、提示词能力、工程化能力。四块各管一段但又互相咬合。2.1 数据准备不只是清洗构造样本、标注规范和边界测试集很多教程告诉你第一步是把数据清洗干净。但做AI工程尤其是做基于大模型的应用数据准备的重点不是“清洗”而是“构造”。大模型不像传统机器学习模型那样需要几万条标注数据才能学会一个任务。它已经具备很强的理解能力你需要做的往往只是给它很少量的示例Few-shot甚至在Prompt里写清楚规则它就能照做。但前提是你得知道什么输入会让它做错然后把这类输入收集起来形成边界测试集。我目前的做法是每次在测试阶段发现模型输出不合格的case就把它记录到一个专门的目录里按“输入类型、期望输出、失败原因”分类。一个月下来这个边界测试集比任何评估指标都有用因为它全是你业务里真实出现的坑。数据层面还有一件事特别重要标注规范。如果你要做数据标注哪怕只有几千条也一定要先写标注规范文档。我之前带一个实习生做实体抽取两个人对“金额”到底包不包括“元”理解不一致导致标注数据前后矛盾。用这种数据做评估甚至微调结果都是灾难。2.2 模型选型绝不是越大越好延迟、成本、能力三角模型选型是AI工程里最容易被情绪化选择绑架的一环。很多人一听到“大模型”“GPT”“最强开源”就两眼放光直接上最大参数版本。但实际做工程要算三笔账延迟、成本、能力。我做一个实时客服场景时用最大参数模型效果最好但平均响应时间接近4秒用户根本等不了。后来换成小一号的模型配合更精确的检索和提示词效果几乎没差响应时间降到800毫秒成本降了七成。给你一个通用的选型对比思路考量维度优先大模型优先中小模型复杂推理效果好但慢容易出错响应速度可能不达标优势明显成本高低上下文长度通常更长受限多步骤任务更稳需要拆得更细私有化部署资源消耗大更现实我的建议是先拿一个标准测试集在不同模型上跑一遍不要只看单条回答质量要同时测延迟和成本然后按业务场景加权打分。别信所谓“最强模型”信你手上那个业务测试集测出来的结果。2.3 提示词工程从“碰运气”走向“版本控制”提示词工程现在炒得很热但它不是玄学。我把它当成一种代码来看待要写注释、要做版本管理、要能回滚、要有测试。具体来说我会把每个任务的系统提示词写成一个模板文件里面包含角色、任务目标、输入格式、输出格式、约束条件、示例、兜底策略。然后用类似Git的版本管理方式记录每次改动改动时附带一个说明改了什么、为什么改、用哪些测试case验证过。我自己踩过最痛的坑是某次为了提升一个任务的准确率我在提示词里加了一句“如果信息不足请明确告诉用户你不知道”。结果这个改动让另一个任务从文本里提取实体的输出多了一堆“我不知道”的开头把下游解析搞崩了。如果当时有回归测试这个问题能在十分钟内发现而不是上线三天后被用户投诉了才知道。所以提示词工程的核心不是“会不会写”而是“改了之后怎么保证不影响其他地方”。这就是为什么它必须纳入工程化管理。2.4 工程化缓存、重试、可观测性一个都不能少最后一块工程化能力是很多算法背景的人最容易忽略的。模型调用再聪明如果服务一崩就全崩那它就不叫AI工程叫AI实验。我在所有AI服务里都会做这几件事缓存相同或相似的请求直接返回缓存结果省钱又提速。但要设计好缓存键不能把用户上下文搞串。重试和降级模型调用超时先重试一次连续失败就降级到备用小模型或者直接返回预置话术。可观测性记录每一次调用的完整输入输出、模型类型、token消耗、耗时、错误码。没有这个你根本没法定位线上问题。隔离把AI服务拆成独立模块AI挂了不要拖着整个系统陪葬。我给你看一个最简单的重试逻辑示例用Python写import time from openai import OpenAI client OpenAI() def chat_with_retry(messages, max_retries3, timeout30): for attempt in range(max_retries): try: response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, timeouttimeout ) return response.choices[0].message.content except Exception as e: print(fattempt {attempt 1} failed: {e}) if attempt max_retries - 1: return 抱歉我现在处理不过来请稍后再试。 time.sleep(min(2 ** attempt, 5))这段代码很朴素但它解决了一个实际问题AI服务不能因为一次网络抖动就整个报错给用户。工程化的核心不是用多高深的技术而是把容错作为默认设计。3. 零基础搭建第一个AI Agent的完整流程与关键选型说完了基础能力聊聊现在最火的AI Agent。很多人想从零开始做Agent又被各种概念绕晕。我用一个实际项目的完整流程告诉你Agent到底是怎么搭起来的。3.1 先定场景为什么我推荐从“工具调用型Agent”入手Agent可以做得非常复杂比如自主规划、长期记忆、多智能体协作。但如果你是从零开始我强烈建议你先做一个“工具调用型Agent”它有一个明确的目标可以调用几个预定义工具查数据库、发邮件、查天气等根据工具返回结果决定下一步动作。这个方向最适合入门因为它的边界是可控的工具数量有限任务目标单一失败模式清晰。我做的第一个Agent是一个“客户工单处理助手”用户提交一个问题描述Agent判断这个问题属于哪类然后调用查询工单历史、查看库存、查物流状态这三个工具最后给用户一个完整答复。3.2 完整流程任务拆解、工具定义、记忆设计和执行循环一个工具调用型Agent核心流程有四步任务拆解把用户请求拆解成一个个可执行的子任务。工具选择根据子任务选择合适的工具。工具执行真正去调用API或数据库。结果整合把工具返回的结构化数据整合成自然语言答复。光看这四步很简单但每一步都有暗坑。比如任务拆解模型有时候会把一个简单请求拆成三步每步都调一次工具导致又慢又费钱。我后来给Agent定了一个规则如果能够直接通过一个工具回答不要拆分。效果立竿见影。工具定义这块我强烈建议你把每个工具的说明写得极其详细包括工具能做什么、不能做什么、参数格式、典型示例。这比在系统提示词里反复强调“你要仔细思考”有用得多。因为模型是通过工具描述来理解工具用途的描述越具体选错工具的概率越低。记忆设计同样关键。我的经验是短期记忆当前对话上下文放在Prompt里长期记忆用户偏好、历史工单放在外部存储按需检索注入。不要把全部历史都硬塞给模型那会让它在无关信息里迷失方向还会很快打爆上下文窗口。3.3 关键选型模型、编排框架、代码助手搭建Agent时会有三个选型问题绕不开。模型选型参考我前面说的三角账。我目前的经验是做Agent任务模型工具调用能力比纯文本生成能力更重要。有些模型写文章很漂亮但让它按照JSON格式返回工具调用参数时频频出错相反一些专门在工具调用上做过优化的模型虽然文笔普通却非常适合做Agent。编排框架我的建议是第一个项目别上来就上LangChain之类重框架。我最初用LangChain中间抽象层太多出了问题很难排查后来改用纯代码手写Agent循环逻辑一目了然。等你对流程完全熟悉了再决定要不要用框架也不迟。工具、API、提示词全部自己控制调试成本低很多。代码助手的选型我现在日常会用到CodeBuddy这样的AI编程工具。它在Agent开发里的作用不光是帮你写代码更重要的是能帮你生成测试用例、解释报错、重构代码。用AI写AI工程的代码本身就是一种很好的实践方式。但记住一点AI生成的代码只是初稿你要有足够的工程判断力去审查它尤其是涉及工具调用、系统边界的地方。3.4 从单轮到多轮让Agent不跑偏的4个约束手段把单一任务跑通以后很多人会急着让Agent支持多轮对话、自主决策。这时候最容易出现“跑偏”的问题聊着聊着Agent忘了最初的目标开始做无关动作甚至反复调用同一个工具不撒手。我用来约束Agent跑偏的手段有四个都很朴素限制工具调用总次数。超过阈值强制停止要求Agent总结当前进度并询问用户下一步。每一步都强制输出“当前目标”字段。让Agent在每次调用工具前用一句话说明这一步在为什么目标服务。如果目标对不上系统直接拦截。设定最大token预算。每次Agent循环消耗超过预算就中止防止失控烧钱。引入人工确认节点。对于“删数据”“发消息”这类高风险工具Agent只生成操作建议必须由人在界面上确认后才真正执行。这四个手段听起来特别简单但它们把Agent从“不可控的自主体”变成了“可控的协作体”。这是我认为做Agent工程最重要的一条体感。4. 用“测试开发”思路让AI输出稳定可交付AI工程里最容易被低估的是测试。传统软件测试可以写断言输入1加1断言等于2。但大模型的输出是概率性的同一个Prompt可能产生不同结果。那怎么测我把AI测试开发的一些经验给你拆开讲。4.1 LLM输出不稳定是常态不是bug首先要摆正心态LLM输出不稳定不是bug是它的固有属性。跟大模型打交道你要接受“Same input, different output”这件事。所以AI测试的目标不是保证每次输出完全一致而是保证每次输出都在可接受范围内。什么叫可接受范围我来定义一下一个客服回答不需要每次一字不差但它必须满足不侮辱用户、不编造不存在的政策、最终给出明确建议或下一步行动。这些就是你的验收条件。我在项目里做过一件事把同一个测试输入跑10次每次记录输出然后人工看这10个输出之间的差异。你会发现差异通常集中在措辞上但偶尔会有一次输出出现严重事实错误。测试的目的就是把这种偶发严重错误抓出来找到触发条件然后通过提示词或后置校验去拦截。4.2 构造断言集和回归测试像质检一样验收AI输出我给AI服务做测试的思路跟传统测试很像只是断言会更抽象。我会把断言分成四层格式层输出是否为合法JSON是否包含必需字段内容层是否包含期望的关键信息是否自相矛盾安全层是否包含暴力、色情、政治敏感或违规内容业务层是否答非所问是否做了超出权限的承诺前两层可以用代码来自动判断后两层通常需要借用更强的模型来做裁判或者用规则做初筛。真正的回归测试是把历史所有bad case重新跑一遍确保这次改动没有把原来修好的问题又带回来。我来写一个最简单的断言示例判断一个客服回答是不是“不合格”def is_qualified_answer(answer: str) - bool: if not answer or len(answer) 5: return False # 不能直接承认自己不知道而不给任何下一步建议 if 我不知道 in answer and 建议 not in answer and 您可以 not in answer: return False # 不能包含涉嫌违规的内容 banned_words [攻击, 辱骂, 赌, 毒] if any(w in answer for w in banned_words): return False return True这只是非常粗糙的示例但思路是有效的把业务规则翻译成可执行的校验函数。你不需要一上来就追求100%自动判定能拦截80%的明显问题就已经比纯靠眼睛看强太多了。4.3 评估指标准确率、格式合规率、幻觉率、成本除了断言AI项目还需要一套持续跟踪的评估指标。我每个项目都至少盯这四个数字准确率人工抽查或裁判模型判定回答正确且符合预期的比例。格式合规率输出能被下游解析器正确解析的比例。格式错了内容再好也没用。幻觉率回答中出现了知识库/工具结果里根本没有的信息。这是最危险的。单次调用成本平均一次完整请求花了多少token。这四个数字要放进可视化的看板里每次模型升级、Prompt修改、知识库更新之后跑一遍回归对比数字变化。没有这个对比你根本无法判断一个改动到底是变好了还是变差了。我见过很多团队凭感觉调Prompt调完觉得“看起来更好”但上线后一堆新的bad case冒出来。有了评估看板你会清楚地看到哦准确率确实从82%涨到了86%但幻觉率从3%涨到了7%这个改动值不值得落地就很清楚了。4.4 线上监控与灰度AI功能必须有一套“安全开关”最后是线上监控。AI功能上线绝对不能像传统功能那样直接全量发布。我的做法是灰度发布先让5%流量走新Prompt对比旧版本的评估指标再逐步扩量。实时拦截线上仍然跑着内容安全校验一旦命中高危关键词立即替换为兜底话术并记录日志。反馈回路在用户端加一个“答案是否有帮助”的按钮把低分反馈自动拉取出来每天review一次补充进测试集。安全开关是AI工程里特别重要又常被忽略的东西。你可以在代码里加一个总阀门如果模型连续多次输出不合格系统自动切成备用方案哪怕只是返回“收到你的问题了我们人工处理中”也比给用户一个胡编乱造的答案强得多。AI功能的“安全开关”不是为了业务优雅而是为了保命。我强烈建议你上线第一天就把它做出来。5. 从个人玩具到团队协作Harness Engineering与AI Native研发范式个人项目跑通以后很多人会进入下一个阶段把它推广到整个团队。这个阶段会撞上一堵特别厚的墙个人实验可以靠脑子控制一切但团队协作需要的是流程、规范和基础设施。这就引出了Harness Engineering这个概念以及AI Native研发范式。5.1 为什么个人项目跑通之后一上团队就翻车我自己就经历过这种“翻车”。个人项目里所有Prompt、数据、评估脚本都放在我本地模型API key也只有我一人有。当我把代码交接给团队时其他人根本不知道怎么改Prompt、怎么跑评估、怎么加新的bad case。最后变成整个AI功能的迭代只有我一个人能做别人想帮忙都无从下手。这不是人的问题是工程化缺失的问题。个人项目里你脑子里装着的隐性知识换成团队环境必须变成显性的代码、文档、流程。否则项目做得再成功也只是一个单点demo。5.2 Harness Engineering解决什么问题把AI能力“套上缰绳”Harness Engineering这个概念你可能听得不多但我理解它的核心就一句话给AI能力加缰绳让它可靠、可控、可观测地为人所用。它不是某个具体框架而是一整套工程实践集合。在团队协作里Harness Engineering落地要抓几件事统一的Prompt模板库所有Prompt集中管理不走个人文件。标准化的工具接入协议无论团队里谁新增一个工具都按同一套接口规范接入Agent才能正常调用。集中式的评估数据集bad case归所有人共同维护不允许散落在个人电脑上。权限与审计哪些操作允许AI自动执行哪些必须人工确认要有明确规则并落到代码里。我自己的团队实践是建立一个“AI服务目录”每个被Agent使用的能力都在目录里有详细描述包括用途、参数、限制、负责人。这个目录既是文档也是接入规范。Agent在调用一个工具前会先根据目录里的描述做选择而工程师维护好目录就是最有效的“给AI套缰绳”的动作。5.3 AI Native研发范式不是“加个AI功能”而是重构研发链路AI Native研发范式这个词最近越来越热。我的理解是它不只是“在现有系统里加个AI接口”而是从需求分析、代码编写、测试验证到发布监控整条研发链路都用AI重新做一遍。举个例子传统研发流程里一个需求下来先写设计文档然后写代码再写测试用例最后手工验证。在AI Native研发范式下这些环节的产出都可以由AI辅助生成但人要做的是定义边界、审核结果、把控质量。举个例子我用Agent来处理代码评审意见中的“是否真的解决了问题”。传统工具只能检查代码风格但现在AI能读懂代码逻辑对比改动前后的行为。但AI的评审结论不能直接作为最终结果它只能给出“疑似问题”和“建议”最后由人确认。这套流程跑通以后研发效率确实明显提升但前提是每一步都有明确的人在回路。AI Native研发范式的核心是把AI嵌进研发流程的每一个决策点而不是放在某一个孤立的对话框里。它要求研发团队具备两种能力一是能准确描述任务的边界二是能对AI产出做有效审查。这两个能力恰好也是AI工程的核心素养。5.4 CodeBuddy这类工具在团队里到底怎么用聊团队协作很多人会问AI编程助手比如CodeBuddy到底能不能在团队里直接用我的答案是能用但要用对方式。我见过两种完全不同的用法。一种是传统IDE插件用法让AI补全代码、写单元测试、解释报错。这种用法本身没问题但它只改变了“写代码”这一个环节整个研发流程还是老样子。另一种是把它当成团队的数字生产力设施CodeBuddy背后有一套工程上下文理解能力可以让它把整个项目结构、代码规范、历史修改记录都纳入考虑这样它生成的代码就能贴合团队实际工程环境而不仅仅是给一段孤立代码。在这个基础上团队可以建立自己的AI辅助研发规范哪些代码允许AI直接生成哪些必须人工手写AI生成的代码合并前必须走一遍完整的人工评审所有AI生成的Prompt和代码都要纳入版本管理。我在团队里还会用CodeBuddy做“AI助手训练”让它学习我们现有的代码评审意见总结出团队自己的代码风格偏好然后自动给新提交的代码打上风格检查标签。这样做下来人关注的内容可以聚焦在真正的逻辑正确性上琐碎的风格问题交给工具处理。我特别想提醒一点别把自己的工程判断力外包给AI。CodeBuddy再强它也是基于历史模式做预测它不知道你们业务的特殊约束也不知道线上出了什么紧急状况。用它的关键在于把它当成“超级实习生”产出初稿你来定夺。6. 踩坑实录从零到一过程中我最想告诉你的五件事最后这部分我把自己从零做AI工程踩过的最有价值的坑集中整理一下。这些教训很多都是拿真金白银和时间换来的希望你能直接绕过。6.1 把评估放到第一天不要放到最后一天我最早做AI应用时花了三周调Prompt觉得效果很不错才想起来要搭评估体系。结果一跑测试集发现不少问题之前根本没注意到——因为人工肉眼验证时总会不自觉地记住那些回答漂亮的case忽略偶尔翻车的case。正确做法是项目启动第一天就把一小组核心bad case和评估脚本搭起来。哪怕最开始只有20条测试样例也足够阻止你朝着错误方向狂奔。这跟传统开发里的“测试先行”是一个道理只是LLM让它的重要性放大了十倍。6.2 不要过度设计Agent先用手动流程跑出黄金路径第二个大坑是一上来就想做一个完全自主、全自动的Agent。我一度给Agent设计了很多工具和很复杂的规划逻辑结果它在一个简单任务上反复绕圈气得我把它砍掉重做了。后来我学乖了先完全手动走一遍业务流程把每一步操作、每个决策点都记录下来形成一条“黄金路径”。然后只在黄金路径上逐步加自动化加一步验证一步。等黄金路径全自动跑通了再考虑处理分支情况。这样既不会过度设计又能在每一步都保证可用性。6.3 系统提示词也要做版本管理和回归测试前面提过这个坑但我还是要单独强调一次提示词不是一段静态文本它是像代码一样会演进的资产。我见过有人把系统提示词直接写在Python文件的一个长字符串里每次改动直接改代码完全没有历史记录。我的经验是所有提示词建议放进单独的文件或配置表通过版本管理追踪每次改动至少跑一次回归测试哪怕只有几十个case也能拦住绝大多数意外影响。这个习惯一开始可能觉得繁琐但等你的提示词超过20个、相互之间开始有耦合的时候你会感谢这个决定。6.4 观察成本一次多模型调用可能比想象贵成本问题太容易被忽略了。在实验阶段你只跑几十个case看不出成本。但上线以后一个每天几十万次请求的AI服务token费用蹭蹭往上涨。尤其是Agent场景经常一次用户请求背后要调好几轮模型每一轮都要消耗大量上下文token实际成本可能是单次请求的三到五倍。我建议每个AI工程在立项时就建好成本模型预估单次请求token量、峰值QPS、模型单价算出日成本上限。上线后盯着每天的token消耗一旦发现异常飙升优先查是不是Agent陷入了重复调用循环。成本控制不是财务部门的事是AI工程师必须背的指标。6.5 保留人在回路AI工程不是无人驾驶最后一条也是我认为最重要的一条不管你的AI系统多聪明都不要彻底摘掉人工干预机制。尤其是在高风险场景比如医疗建议、法律建议、财务操作、内容发布AI只能做草稿和建议最终决策必须由人来做。我做一个自动化内容生成项目时把AI生成的初稿直接发布上线结果有一篇内容出现了事实性错误差点出问题。后来我加了一个强制人工审核流程AI负责生成和润色人负责事实核查和最终拍板。虽然这降低了“全自动化”的纯度但换来的安全和信任是无价的。做AI工程到后面你会发现真正的难点不在模型本身而在于你怎么在“发挥AI能力”和“守住安全边界”之间找到那个平衡点。这个平衡没有标准答案只能靠你的业务场景、风险评估和持续测试来慢慢校准。如果你也打算走一遍从零到一的AI工程之路我的建议很简单先动手做一个极小的工具型Agent把评估、缓存、重试、安全开关全部搭上跑通一轮真实业务数据然后回头再看这篇文章你会更有体感。AI工程没有那么多玄学本质上还是用工程方法驯服一个概率系统它需要的是耐心、严谨以及愿意一遍遍试错的那股劲。