1. 先看清AI工程的真实版图它和调个API完全是两回事1.1 传统软件工程的三层假设正在失效我见过太多团队拿着大模型API文档就想从零开始做AI结果第一个月写出来的东西和聊天玩具没什么区别。问题不在于他们不会调用模型而在于脑子里还挂着传统软件工程的三层旧假设。第一层假设是输入是确定的输出是可验证的。传统代码给一个输入必然产生一个可断言的输出单元测试模型建立在确定性之上。而大模型是概率系统同样的提示词同一个参数两次调用可能给出两种答案其中一种还是错的但看起来像真的。你没法用assert response expected这种思维去验收AI功能。第二层假设是逻辑在代码里数据在存储里。传统开发把业务规则写死在代码分支中AI工程则把大量规则溶解在提示词、系统提示词和上下文里。于是代码库中出现了第一类新的维护对象——提示词版本、评估集版本、上下文拼接策略它们既不完全是代码也不完全是配置更像是带逻辑的数据。第三层假设是系统边界是清晰的。传统后端最多处理外部API异常、超时和限流而AI应用的核心风险来自模型胡编——它可能一本正经地引用不存在的论文、计算错误的订单金额或者在你没有约束时跑偏话题。这些已经不是可捕获的异常而是需要一整套护栏体系来兜底。这三层假设失效之后AI工程就不再是给软件加个AI接口而是一套完整的、从零搭建的新学科。它同时涉及模型能力边界、数据组织、运行时控制、质量评估和生产稳定性每一块都得单独学。1.2 从零起步需要的四块基石如果让我把从零开始学AI工程需要掌握的东西压缩成四块我会这样划分提示词与上下文工程这是最基础也最容易被低估的一层。提示词不是聊天话术是写给模型的指令协议背后涉及结构化输出、few-shot示例的组织、上下文窗口的预算分配。Agent与任务编排让模型不只会回答问题而是能拆解任务、调用工具、按计划执行。这块引入了工具调用Tool Calling、ReAct循环、Agent状态管理等一系列新概念。评估与测试体系因为你无法用传统断言验证AI输出必须建立评估集 评判标准 回归机制三位一体的质量保障体系。这是AI工程和传统工程最本质的区别之一。生产化与稳定性治理包括成本控制、延迟优化、模型降级策略、数据回流、灰度发布等等。模型只是AI应用中最廉价和最容易替换的部分真正决定产品价值的是围绕它的整个工程系统。这四块不是四门独立的课它们是一条链路提示词决定单次输出的上限Agent决定复杂任务的完成度评估体系决定质量能否被度量生产化治理决定系统能否活过上线第一天。这篇文章就按这条链路往下走每一部分我都会给出可以立刻照着做的落地方法而不是停留在概念解释上。2. 提示词的工程化改造从会聊天到可复用、可测试、可评估2.1 提示词的本质是程序中的一段运行时代码很多初学者把提示词当作写得更好听的话这是一个根本性误解。提示词在AI应用里的地位等同于传统程序里的函数体——它接收输入变量执行一段规则产生结构化输出。你写提示词本质上是在编程只不过这个执行引擎是大模型。这个定位一旦确立很多设计原则就自动出来了。比如函数必须处理异常输入提示词就必须声明如果用户输入不包含日期明确要求补充。函数必须有明确的返回类型提示词就必须定义输出JSON Schema并且给出一到两个符合标准格式的示例。函数不能有歧义提示词里的指令就必须使用祈使句、限定范围而不是描述性的委婉语。我实测下来提示词工程化改造前后同样的模型在同一批测试样本上的准确率可以相差20个点以上。差距主要来自三个方面角色设定是否限定了知识边界、输出格式是否被严格约束、是否提供了可靠的few-shot示例。角色设定不只是你是资深律师这种泛泛话术而是要明确你只基于提供的材料回答材料中没有的信息一律答复资料不足。输出格式不只是说以JSON返回而是要给出完整Schema并附上示例。这样模型才不会自由发挥。2.2 结构化提示词的五大组件我在团队内部强制推行了一种五段式提示词模板用了一年多在多个业务场景上都稳定地提升了输出质量。这里直接分享给你角色与边界定义模型的身份、知识范围和回答禁区。例如你是一名智能客服质检员只分析对话记录中客服人员的表现不评价用户言行。任务目标用一两句话说清要做什么必须具体到可执行。例如从对话记录中抽取客服的违规话术按严重程度分为A/B/C三级。输入与输出规范声明接收什么字段、输出什么格式。输出必须给出Schema示例必要时使用XML标签或JSON包裹。约束与例外处理写明不做什么以及遇到边界情况怎么办。例如如果对话内容与客服无关输出空数组如果信息不足不要推测直接标注unknown。few-shot示例给一到三组输入输出对。示例的作用是让模型看到而不是猜到你期望的格式和推理路径。这五个组件不是让你每次都写满而是要求你时刻清楚自己的提示词里缺了哪一块。我在审查别人写的提示词时最常见的问题就是只有任务目标没有边界和约束导致模型在开放领域里自由发挥。2.3 上下文工程决定输出质量的第一变量提示词本身能给的指令终究有限真正决定模型知道什么的是你塞给它的上下文。这就是上下文工程的核心逻辑模型就像一个只有短期记忆的专家你喂什么材料它就依据什么材料作答。这个环节在RAG检索增强生成架构里尤其关键。我习惯把上下文工程拆成三件事选什么进上下文、怎么组织、怎么分配预算。选什么进上下文本质上是检索质量的问题。很多人直接做了个embedding相似度检索就往里塞效果很差。我建议至少做到先做意图路由再做窄域检索。先判断用户问题属于哪个业务域再只在对应域的文档库里检索能显著减少语义干扰。怎么组织上下文指的是检索到的碎片不能直接拼接。更好的做法是给每段文本加上元信息头比如来源产品手册V3.2第4节退款规则模型在引用时就能更准确地追溯来源。你还可以把相关的FAQ、表格、流程说明打包成一个信息块让模型整体消费而不是读一堆碎片。怎么分配预算指的是上下文窗口是有限的资源要把引导指令 参考材料 历史记录 最新用户问题按优先级切分历史记录可以截断或摘要参考材料要控制总量。比较好的经验是给参考材料留一半以上的空间给最新的对话留足位置因为模型对离结尾越近的内容注意力越强。3. Agent与Harness让模型从回答问题进化到完成任务3.1 Agent的四层基础架构如果你的应用只是进一个问题、出一个答案那还停留在API调用层。一旦需要让AI去查数据库、调内部接口、连续多步推理就必须引入Agent架构。我把它拆成四层来看决策层Brain负责理解目标任务、拆解子任务、决定调用哪个工具。这一层通常由大模型承担核心是规划能力。工具层Tools模型可以调用的外部能力包括搜索、数据库查询、代码执行、HTTP请求和内部业务接口。工具必须先做说明书——用清晰的描述告诉模型这个工具是干嘛的、什么时候用、参数是什么。记忆层Memory管理短期对话历史、长期用户画像和任务中间状态。没有记忆层Agent就是一个每次重新开始的健忘症患者。执行层Execution Loop把上面的决策、工具调用和结果观察串起来反复循环直到任务完成或触发终止条件。经典范式是ReAct——推理一步、执行一步、观察结果、再推理。这个四层架构不需要一上来就全做但你必须知道自己的Agent缺了哪一层缺了会出什么问题。3.2 Harness Engineering边界、护栏与纠错机制Harness Engineering这个词在业内讨论里逐渐热起来本质上是在讲怎么给Agent设计一套笼头让它在自由发挥的同时不跑偏、不越界、不造成破坏。我把Harness拆成三个层面来落地。第一层是工具访问边界。Agent能调用的工具必须最小化授权。比如聊天机器人原则上不需要权限去删除数据库记录即便它规划出这个动作也不应该真的能执行。实现上可以用工具白名单 参数校验 操作审计三层卡控工具层只暴露必要的接口参数里不允许传入未经验证的外部数据所有工具调用记录都要留痕。第二层是行为护栏。通过系统提示词和运行时的规则检查限制Agent的行为范围。例如规定遇到超出权限的请求不得尝试绕过必须明确拒绝规定任何涉及金额的操作必须经过用户二次确认才能执行。运行时还可以检测模型输出的工具调用是否触发了敏感操作一旦命中预设规则就中止执行。第三层是自动纠错机制。Agent在执行过程中会产生错误中间结果Harness应该能够识别并让它重试。最常见的纠错触发条件有三种工具调用返回了异常或空结果、模型连续两次生成完全相同的错误输出、单次任务总步骤超过上限。我一般会建议在Agent执行循环里加入最大重试次数和降级策略——重试超过两次就放弃当前路径返回用户可读的说明而不是让用户面对一个进程挂死的黑洞。这里我要特别强调一点Harness不是限制模型发挥而是划定安全区。没有边界的Agent在POC阶段看起来很强一上线就会暴露成破坏力巨大的不可控组件。我见过一个团队在演示时让Agent自由调用内部接口结果Agent在测试环境里连续创建了上百个重复订单整个演示直接翻车。这种事故只要事前设计好工具边界完全可以避免。3.3 任务编排单个Agent的局限与多Agent协作很多人一上来就想搭建多Agent协作网络我的建议是先把单个Agent的任务编排做扎实。单个Agent最常见的失败不是不会做而是不知道什么时候该停。我给任务编排总结过一个简单的分层策略顶层线性、底层并行。顶层的任务阶段收集信息 → 分析 → 生成结果 → 校验按线性顺序执行每个阶段内部可以并行调用多个工具或检索多个资料源。这种结构比自由规划更可控也更容易审计。什么时候需要多Agent只有当你发现一个Agent既要做深度分析、又要做事实核查、还要跟用户情感沟通导致提示词互相冲突、语气四不像的时候才应该拆分角色。多Agent协作的落地方式不要做得太花哨一个Worker Agent 一个Reviewer Agent的组合就足够解决大部分质量问题。Worker负责生成结果Reviewer负责对照原始材料做事实核查发现不一致就打回重写。我在多个内容生成项目里用这个模式把事实性错误率压低了大概一半。4. 质量保障体系AI应用测试的三种关键手段4.1 从断言到评判为什么传统单测会失灵AI应用上线之前最头疼的问题是我怎么知道它行不行传统软件有单元测试、集成测试断言函数是等值判定。但AI应用没有固定答案同一句话换个说法正确答案的表达形式可能完全不同。这就是从断言到评判的转变你不能再期望程序自动判断对错而是要用一个评判者Judge来评估输出质量。评判者可以是三种角色之一规则加正则的模式匹配、一个专门的评估模型、或者人工标注抽样。我推荐的做法是分层评估而不是只用一种评判手段。第一层用规则做硬校验比如JSON格式是否合法、必填字段是否缺失、输出长度是否超限这些事规则就能搞定。第二层用模型做语义评判针对回答是否忠实于原文关键信息点是否齐全有没有明显跑题这些维度打分类别或打分。第三层是人工抽检按一定比例随机抽取线上样本让人来复核防止模型评判者自身产生偏差。4.2 评估集Eval Set的建设方法评估集是AI工程质量体系的基准线。没有评估集你就无法量化一次提示词修改是变好还是变坏。很多团队觉得我们也有测试用例啊但仔细一看只有二十几条手工写的样例覆盖不了真实流量的分布这叫过拟合测试集。我建议评估集至少包含三种样本标准样本、边界样本和失败回流样本。标准样本覆盖业务的常见类型每个类型至少十条以上边界样本包含异常输入、极长文本、模糊指令、恶意输入专门用来测试护栏是否有效失败回流样本来自线上真实用户的问题尤其是那些曾经让模型出错的案例每发现一个新bug就把它固化进评估集防止回归。数量上一个中等复杂度的业务场景评估集至少应该积累到两百条以上才有统计意义。每次修改提示词或调整Agent流程都跑一遍完整评估集对比关键指标的升降再决定是否发布。这个过程看起来很笨但它就是AI应用迭代的自动化测试。4.3 线上巡检与回归的落地评估集在发布前验证质量但线上环境还有一类问题你以为修好的问题换一种表达又冒出来了。所以我还会建议搭建一个轻量的线上巡检体系。核心做法是把线上用户的真实输入做脱敏采样每晚批量跑一遍最新版本的系统自动用评判模型打分把分数异常偏低的案例自动归类并进入待人工审核队列。早上上班打开面板就能看到昨晚哪些场景质量下滑了原因是什么。这个机制的成本不高一个小型任务队列加一个评判模型的调用就够但产出的价值非常大它把用户投诉了才知道质量崩了变成了第二天早上就知道哪里出了问题。这里涉及到的AI测试开发本质就是为上述这套评估体系写工具、写自动化流程、写数据回流管道。它不是给AI写传统测试用例而是开发测试AI的系统。5. 从原型到生产最难的不是写代码是处理不确定5.1 非确定性工程重试、采样与温度控制把AI应用从Demo推向生产第一个撞上的墙就是非确定性。模型同一个输入可能给出两个不同答案这在Demo阶段没什么在生产环境里就是事故。处理非确定性有几个成熟手段我按实用程度排序温度参数调低生产环境我通常调到0.1~0.3让输出趋近稳定关键路径重试对结果做校验不合格就重新生成最多重试两到三次取校验通过的那次批量采样投票对关键决策类任务可以同时生成三到五个候选结果用规则或评判模型选最优代价是成本和延迟上升只在真正关键的场景用。此外还有一个容易忽略的点把模型的版本号、温度、提示词版本统统记录在日志里。没有这些元信息你事后根本没法排查为什么这条数据输出变了。5.2 上下文爆炸与成本失控的防御策略AI应用到了生产环境成本往往比预想涨得快得多。我见过一个惨痛案例一个RAG应用每次请求都把用户的历史对话全量塞进上下文上线一周后单日token消耗翻了几十倍账单直接失控。防御策略有三个层次。第一层是上下文裁剪设置对话轮数上限超出部分做摘要压缩只保留摘要加最近几轮完整对话。第二层是缓存复用对于相似度很高的重复问题直接命中缓存返回上一轮的答案可以省掉大量重复计算。第三层是模型分级简单问题用便宜的小模型处理只有复杂任务才路由到最强模型这个策略能省下50%以上的成本。这里我提醒一点成本监控必须是实时的。我给团队定的规则是每笔请求记录模型名、输入输出token数、本次调用的总成本按小时聚合上报。看到异常上涨的趋势立刻查是哪个场景、哪个用户、哪类输入导致的而不是等到月底账单出来才知道超支了。5.3 幻觉治理的工程三板斧幻觉是AI应用没法彻底消灭的问题但可以治理到业务可接受的程度。我总结出最有效的三板斧第一板斧约束知识来源。强制模型只基于提供的上下文回答上下文没有的内容必须明说资料中未提及。配合提示词的硬约束和引用来源编号的输出格式能大幅降低无中生有的概率。第二板斧事实核查回路。让模型先生成答案再让另一个核查角色把答案中的事实性陈述逐条与原始材料对照不一致的标记出来打回。多花一次模型调用换取可信度的显著提升这个交换非常划算。第三板斧设计人机边界。对于那些出错代价高的场景不要指望模型全自动输出最终结论而是让模型生成建议稿由人工做最后确认。比如医疗建议、财务数据、法律文书模型的角色永远应该是辅助起草而不是最终拍板。把这条原则写进产品设计文档比任何提示词都管用。6. 我踩过的坑与给新手的起步建议6.1 三个最典型的失败模式我从零做AI工程这一年多见过自己也见过同行反复踩坑最典型的失败模式有三个。第一个是跳过评估体系直接上线。功能在Demo环境里完美运行一上真实流量就崩因为没有评估集任何修改都没有回归依据整个项目陷入改了坏、坏了改的循环最后质量始终提不上去。这个教训我说过很多次评估体系应该和功能代码同时开发甚至更早。第二个是上下文塞太多导致注意力稀释。早期我总怕模型不知道所以把能检索到的文档全塞进去结果模型反而被大量无关信息干扰关键答案的质量明显下降。后来强制做检索结果的排序和截断只保留最相关的Top K段效果立刻改善。这里可以做一个类比上下文窗口就像一个人的工作台东西堆得太满反而找不到最需要的那份文件。第三个是把Agent当全知全能的员工。以为给了模型工具和权限它就能自己搞定一切结果它在错误的路径上反复重试消耗了大量token还产生了错误数据。后来我给Agent设计了明确的任务终止条件和人工介入点才把这个坑填平。6.2 从零开始的两条学习路线如果你是从零开始学AI工程我给两条不同的学习路线按你的背景选一条就可以。路线A先做窄再做宽。选定一个非常具体的场景比如给客服对话做质检打标把这一条链路完整走通设计提示词、做几十条评估样例、搭一个最简单的RAG检索、再上一个极小规模的线上巡检。一个场景走完整条AI工程链路的核心痛点你都亲身体验过了再横向扩展到其他场景就顺理成章。路线B先搭框架再填细节。如果你更喜欢系统性学习可以先建立一个AI工程的知识框架——提示词、上下文、Agent、评估、治理这五块各是什么、各解决什么问题、彼此怎么衔接。然后针对你实际工作里最薄弱的那一块重点深入。框架的价值在于你不会把某个技巧当成全部而是知道它在一整条链路里的位置。我个人更推荐路线A因为AI工程里大量经验是做了才知道的不把一套RAG跑上线你永远理解不了检索质量对最终答案的影响有多大不做一个Agent到生产环境你永远体会不了Harness设计的必要性。动手做一个小而完整的项目胜过读十篇架构文章。最后再说一句掏心窝的话AI工程从零到一最难的其实是心态转变。在这个领域没有银弹没有一次写对只有建立评估 → 快速试错 → 持续回流这个循环。接受不确定性把它纳入工程管理你就已经比大多数停留在提示词技巧层面的人往前走了一大步了。