1. 别急着调Prompt先搞清楚AI工程到底在工程什么这几年AI圈最魔幻的场景莫过于人人都是Prompt工程师。GitHub上随便一个项目挂个AI前缀就能拿星社交媒体上充斥着三句话让大模型替你写周报的教程。但真到了生产环境你会发现Prompt写得再漂亮也顶不住业务逻辑的复杂性和系统稳定性要求——这就是我为什么一直强调AI工程和写Prompt完全是两码事。如果你正打算从零上手AI工程或者已经在用API做小Demo但总觉得差点意思这篇文章就是写给你的。它不是那种五分钟搭建聊天机器人的快餐教程而是一套我在多个真实项目里反复验证过的工程化思路从需求拆解、技术选型、Prompt设计、Agent编排到评测体系和上线运维。先说一个容易被忽视的事实从零开始做AI工程最大的优势恰恰是你没有历史包袱。很多传统软件团队转型时会把旧架构里的每一个坏习惯都搬进AI项目里——比如把大模型当成数据库、把所有逻辑都塞进一个函数、完全不考虑Token成本。而你是从零起步意味着可以从第一天就按照AI应用的规律来设计系统。我见过太多人把AI工程理解为调用大模型API这是天大的误解。一个真正可交付的AI应用至少包含四层模型层怎么选模型、上下文层怎么组织数据、逻辑层怎么编排流程、交互层怎么对接用户和业务。Prompt只是上下文层的一小块而大多数人恰恰只在最窄的地方死磕。另外一个常见的误区是工具崇拜。看到LangChain火了就无脑上LangChain看到AutoGPT火了就想搞全自动Agent。我个人的建议是前三个月尽量手写核心链路再决定要不要上框架。因为只有当你亲手处理过Token拼接、上下文窗口溢出、工具返回格式错误这些问题你才真正理解框架帮你解决了什么——这是AI工程的基本功绕不过去。2. 需求拆解与技术选型先写需求文档再谈大模型2.1 需求四问输入、输出、约束、兜底从零开始做AI工程第一件事不是选模型不是搭环境而是把需求写清楚。我习惯用四问法来拆解任何一个AI需求输入是什么用户是上传文档、输入文本、还是语音输入格式是否统一数据量级多大输出是什么是生成文本、提取结构化字段、还是做分类判断输出格式是否有硬性要求约束是什么延迟要控制在多少秒内成本上限是多少需要支持并发多少兜底是什么当模型答不上来或答错时系统怎么办有没有降级方案举个例子。之前有个项目业务方上来就说我们要做一个智能客服。听起来很简单对吧但四问之后发现输入是用户语音转写的文本错别字一堆输出要求先分类再回答客户要的是结构化工单延迟不能超过3秒如果模型判断不了必须转人工而不是硬答。这些问题不问清楚后面全是要返工的坑。AI应用最怕的就是需求模糊——模型瞎猜——效果不满——反复调Prompt——还是不满的恶性循环。需求四问的目的是把模糊的商业诉求翻译成工程参数这样你选模型、设计Prompt、搭架构的时候才有据可依。2.2 模型选型不是越大越好参数和场景要匹配选模型是个老生常谈的话题但真正动手的时候很多人还是会犯一个毛病无脑选最强的模型。强模型确实聪明但Token价格高、延迟大而且对于简单任务来说属于大材小用。我的选型逻辑分三步任务复杂度评估如果任务是从合同里提取甲方乙方、金额、日期这是一个信息抽取任务中等模型完全够用如果任务是读完50页年报后对比三家供应商的报价策略这才需要强模型的推理能力。计算Token成本用中文环境下一个请求的Token消耗约为英文字符的0.7到1.5倍取决于分词方式不要只看单次价格要按实际业务量估算月开销。验证兜底能力你一定要知道模型的能力边界在哪里。我建议在选型阶段就准备一套20条左右的冒烟测试题覆盖正常情况、边界情况和明显不该回答的情况让候选模型挨个过一遍。实际项目中我经常采用的组合策略是大小模型分层简单任务走小模型速度快、成本低复杂任务升级到大模型实在搞不定的才动用最强的旗舰模型。这套策略在客服分类、文档解析这类场景里能省下60%以上的Token费用。2.3 框架选择LangChain不是唯二的答案现在聊框架我的态度已经从推荐用变成了慎用。LangChain当然是个好项目它把大量常见操作封装成了标准组件但问题也出在这里封装越多你对底层数据的控制力越弱出了问题越难排查。如果你从零开始做AI工程我建议按这个顺序来第一阶段原生API 代码手写。直接用大模型厂商提供的SDK自己写Prompt拼接、上下文管理、输出解析。这是基本功也是你理解AI应用运行原理最快的方式。第二阶段核心组件抽象。当你发现我每天都在写同样的工具调用代码时再自己抽一层轻量封装比如统一的消息构建器、统一的工具注册表。第三阶段按需引入框架。到这一步你已经有足够经验判断框架的取舍了这时候再看LangChain、LlamaIndex这些工具你会迅速明白它们哪些设计值得借鉴、哪些抽象会坑你。这套路径走下来你可能比直接上手框架的人慢一两周但后续调试和二次开发的速度会快一个量级。因为你对每一行数据流都有完全的控制权出了问题不需要猜框架在背后做了什么。3. Prompt工程落地把提示词当接口协议来设计3.1 System Prompt的结构化写法很多人写System Prompt像在写作文想到哪儿写到哪儿。我见过一个团队的系统提示词有2000多字但模型还是频繁出错——因为关键信息全被埋没了。我推荐的写法是结构化分区用清晰的标记把不同类型的指令分开你是[角色定义]负责[任务描述]。 ## 核心规则 1. [规则一必须做什么] 2. [规则二不能做什么] 3. [规则三边界条件] ## 输出格式 必须严格遵循以下JSON结构 { intent: 分类结果, reply: 给用户的回答, confidence: 置信度 } ## 特殊情况处理 - 如果信息不足confidence设为0reply必须包含需要人工介入 - 如果用户问题涉及敏感话题一律拒绝回答不要小看这个格式。大模型对结构化指令的遵循度远比长篇描述高原因是分区明确的提示词降低了模型理解指令的难度它不需要在2000字的散文里自己找重点。另外System Prompt里不要堆砌形容词比如你是一个乐于助人的助手这种话对任务型系统毫无帮助。把每一个字的Token都花在刀刃上。好的System Prompt应该让模型清楚地知道三件事我是谁、我的任务是什么、什么情况下我必须怎么做。3.2 Few-shot示例的选取与数量控制很多教程告诉你给几个示例模型就会学得更准但没人告诉你示例选不好还不如不给。我踩过一个很实在的坑做文本分类时我在Prompt里放了一个疑似投诉的示例结果模型把正常的催发货消息也判成了投诉——因为示例里恰好包含货怎么还没到这句模型学到的是字面匹配而不是我想要的意图理解。选示例的核心原则是覆盖边界而非代表主类。你不想让示例强化模型对主流情况的判断它本来就会而是通过示例教会它模糊地带怎么处理。比如上面的分类任务你应该放的是一个看起来像投诉但其实是咨询的消息 - 标注为咨询一个语气平静但明确要求赔偿的消息 - 标注为投诉一个完全不相关的消息 - 标注为其他数量上我的经验是3-6个高质量边界示例远胜于20个随意挑选的示例。20个示例会占用大量Token直接抬高成本而且模型在长上下文里很容易被中间位置的示例带偏这个在实践里反复验证过。3.3 RAG场景下Prompt位置容易被忽略的问题如果你做的是知识库问答RAGPrompt设计比普通对话复杂一个数量级——因为你不仅要告诉模型怎么回答还要教会它怎么使用检索到的资料。我最常提醒团队的一句话是检索增强的本质不是把资料塞给模型而是给模型一个可信任的证据链。所以在RAG的Prompt里必须包含检索资料的上限说明以下资料可能包含你需要的信息也可能完全不相关引用规则引用事实时必须标注来源编号拒绝规则如果资料与问题完全无关不要强行回答其中最关键的是资料可能不相关这句。少了这句话模型会把你检索出来的任何内容都当作事实依据来编造答案。加了这句话之后模型才敢说抱歉我在提供的资料中没有找到相关信息。RAG项目的Prompt调试还有一个容易忽略的维度——检索结果顺序。同一个问题检索出来的前三条资料如果顺序不同回答质量会差很多。你需要在Prompt里告诉模型靠前的资料优先级更高还是所有资料一视同仁这取决于你的知识库质量。实测下来知识库质量高时用一视同仁效果更稳质量不高时必须加权排序否则一条低质的强相关片段会把答案带偏。4. Agent不是聊天框工具调用与状态流转才是核心4.1 Function Calling的设计原则工具要像APIAgent之所以区别于普通聊天机器人核心在于它能调用工具。但很多人在设计工具时随便把内部函数暴露给模型结果模型根本不知道该怎么调用。好的工具定义应该是为模型设计的API而不是为程序员设计的函数。我总结过一套工具描述的三要素做什么用一句话说明这个工具的完整功能不要写细节实现什么时候用明确使用场景和触发条件减少模型误用参数说明每个参数要写清楚类型、取值范围、默认值尤其是边界情况比如空字符串代表什么实际编码中我建议工具参数的命名和描述尽量与模型训练语料中的常见表达对齐。比如一个查询订单的工具参数应该叫order_id而不是oid因为模型更理解前者。这听起来像玄学但在实测中确实能提高工具调用的准确率因为模型是在用概率做匹配你越符合它的语言习惯它越容易选对。工具不是越多越好。模型每多一个可调用工具出现幻觉调用的概率就高一分。我强烈建议每次迭代只新增一个工具并在评测集上验证它对整体效果的正向影响而不是一口气塞十个工具进去。4.2 状态管理从无状态走向有状态如果你用大模型的聊天补全API做过对话你会发现一个问题API默认是无状态的所有上下文都要靠你在每次请求时重新拼接。这在单轮问答里没问题但到了Agent场景就变得复杂了。比如一个帮我查快递的Agent用户的真实意图可能是查快递 - 发现签收人不是我 - 要求改地址 - 通知发货方。这四步是一个完整的状态流转每一步都依赖上一步的结果。如果你只是简单地把所有历史记录一股脑塞给模型Agent很容易在第二步就忘了最初的目的。我的做法是引入显式的状态变量而不是完全依赖上下文定义一个对话状态的JSON结构包含当前意图、关键实体订单号、收件人、待确认信息地址手机号每次Agent调用工具之后都会更新这个状态结构系统Prompt里明确告诉模型以下是当前会话的关键状态优先依据这些信息决策而不是依赖全部历史对话这套设计显著提升了多轮任务型Agent的稳定性。它把记忆从模型的概率世界中拉回到了工程的可控范围内——这恰恰是AI工程和调Prompt之间最本质的区别。4.3 边界与安全Agent必须知道的不能做什么我接手过一个Agent项目最初版本什么工具都能调结果有一天模型把删除用户这个危险动作给执行了。虽然事后发现是因为工具权限控制没做好但这个事故给我留下一个深刻教训Agent越强越需要清晰的边界。边界设计分两层工具权限层每个工具都要有权限标记只读/写入/高危在代码层面做硬校验而不是指望模型自己判断。例如查询订单可以随时调用但修改订单必须额外提供操作人ID而且要经过二次确认。Prompt护栏层System Prompt里必须有明确的禁区清单。例如当用户要求删除数据、修改他人信息、绕过审核时一律拒绝并说明原因。还有一个容易忽略的细节工具返回值也需要消毒。我之前一个项目里工具返回了一串含HTML标签的字符串模型直接把它原样输出给了用户导致页面被渲染成了奇怪的样子。从那以后所有工具返回值都会经过统一清洗。5. 评测先行从看着还行到可量化的质量体系5.1 构建评测集的迭代思路AI工程和传统软件开发最大的不同在于你没法用unit test断言模型的输出正确。但这不代表你不能测试。从第一天起你就需要构建自己的评测集Eval Set。我构建评测集的方法是三层扩展法第一层核心冒烟集。10-20条覆盖系统的基础能力比如能回答问题能拒绝不当请求能调用正确工具。每次改动代码必须全过一遍。第二层边界回归集。30-50条来自真实的边界情况——用户手滑打错字、问题包含多个意图、信息特别长、语气特别差等。每次改Prompt要跑一遍。第三层业务演化集。持续从线上日志中抓取用户实际提问中模型表现不好的案例人工标注答案后加入评测集。这个集合每周更新一次。这个方法坚持三个月后你的评测集会变成最有价值的团队资产——它比任何一个团队成员的记忆都可靠任何改动都能快速判断是好是坏。5.2 评测维度的取舍准确率之外的三个指标准确率当然重要但AI应用不能只看准确率。我日常盯的是四个维度的指标指标含义衡量方式准确率输出是否符合预期人工标注/自动比对拒答率不该回答的问题是否拒绝统计拒绝次数稳定性同一问题多次提问结果一致性重复提问N次计算相似度延迟首Token返回时间技术监控稳定性是我特别想强调的。试想一下用户A问这个产品多少钱第一次得到199元第二次得到219元——哪怕第二次更准确用户对系统的信任也已经崩塌了。AI系统的稳定性往往比绝对准确性更重要因为用户无法判断模型对不对但一定能感知到系统忽好忽坏。如果稳定性指标过差优先检查三个地方Prompt里有没有歧义、模型温度参数是否太高建议任务型系统设0.1到0.3、召回的资料是不是每次都不同。5.3 回归测试每次调Prompt都要跑一遍调个Prompt怎么还给调坏了——这是我听过最多的抱怨。原因特别简单你在单独测试时发现某个Prompt让模型表现得更好但放回完整链路里它可能影响了模型的整体行为风格导致其他能力退化。回归测试的意义就在于此。我建议把评测集做成一个脚本每次修改完Prompt或者Agent逻辑全量跑一遍评测集对比改动前后的得分矩阵。不要嫌麻烦一次回归五到十分钟这时间花得值。我还习惯在每次回归测试后记录一个改动日志格式很简单改了什么Prompt第几段、工具描述、温度参数……为什么改遇到了什么bad case预期效果是什么希望提升哪个维度实际效果是什么哪些指标上升、哪些指标下降结论保留/回滚/继续调整这个日志坚持做一年你会拥有一本完整的AI应用调优手册每个改动都有据可查不再依赖我记得好像改过这种模糊记忆。6. 生产环境的最后一公里部署、观测、成本与迭代6.1 流式输出与异步架构从Demo到生产第一个会撞上的墙就是慢。大模型生成一把完整的回答可能要10秒而用户在前端已经不耐烦了。解决方案是流式输出Streaming也就是建模边生成边把Token推给前端。流式输出实现难度并不高调用API时设置streamTrue然后持续把增量内容转发给前端。但有几个坑需要注意中转服务要支持SSEServer-Sent Events不要自己用WebSocket实现SSE简单且够用。流式输出时工具的调用顺序会受影响。Agent场景下模型往往先想再做中间可能有好几轮工具调用这些轮次不适合流式输出需要等Agent决策完成后再开始流式推送最终答案。中断与重连。用户关闭页面的场景很常见你要确保服务端能处理断开连接避免浪费资源继续生成。异步架构也是老生常谈但我要强调一个具体问题不要把大模型请求放在用户请求链路的同步路径上。哪怕是生成一个摘要这样的轻量任务在高峰期也可能因为模型排队把整个服务拖垮。正确的做法是任务队列化异步处理用户侧通过轮询或WebSocket接收结果。6.2 可观测性追踪一次请求的完整链路线上出bug最痛苦的不是修复而是定位。AI应用的调用链路比传统应用长得多用户请求 - 业务逻辑 - Prompt组装 - 模型调用 - 工具调用可能多次- 结果解析 - 返回用户。任何一环出问题症状可能都差不多——用户说答案不对。我建议从第一天就给你的AI系统构建完整的追踪体系至少覆盖每次请求的完整日志输入消息、完整Prompt含System和Context、模型返回的原始结果、最终返回给用户的内容Token消耗统计每次请求的输入Token数、输出Token数、对应成本工具调用记录每一步调了哪个工具、传了什么参数、返回了什么结果错误分类超时错误、模型限额错误、解析错误、工具异常有人会问把完整Prompt存进日志隐私怎么办这个问题问得好。我的做法是分两级开发环境保存全量Prompt生产环境只保存哈希值和关键片段数据脱敏后入库。观测和隐私不是非此即彼的关系关键是设计好脱敏策略。6.3 成本治理Token预算和缓存策略模型API是按Token收费的成本不是线性增长而是随业务量暴涨。我在一个客服项目中最深有体会上线三个月Token账单从每月几百涨到上万——不是用户量涨了十倍而是我们往Prompt里塞了太多内容。成本治理三板斧Token预算控制在代码里给每个接口设置Token上限。比如最大上下文是8000Token实际使用限制在5000Token超了就出发检索压缩或摘要而不是无脑硬塞。缓存策略完全相同的输入针对分类、抽取这类任务可以在Redis里缓存结果Key用输入文本的哈希。实测相似场景缓存命中率能达到20%到30%成本立刻降下来。模型分级这个前面提到过简单任务用便宜的小模型复杂任务才用旗舰模型。比例控制好综合成本能降一半以上。还有一个小技巧定期检查线上日志里Token消耗最高的Top 100请求。你会发现大部分高消耗请求来自异常场景——某用户反复提交超长文本、某个工具返回了大量无用内容被拼进上下文。针对这些异常做治理比盲目优化Prompt更有效。6.4 数据飞轮让系统越用越准最后想聊聊迭代这个环节。传统软件的迭代是修bug发版本AI应用的迭代是收集数据 - 发现问题 - 优化Prompt或工具 - 评测 - 上线 - 再收集数据这是一个闭环。闭环的第一步是挖掘真实用户的bad case。光靠评测集是不够的评测集只是你的记忆而线上每天都会产生你的未知。建议每周固定时间从日志里随机抽100条用户交互人工标注其中模型表现不佳的部分。不用全部保留挑出那些模型给了错误答案模型答非所问模型没调用该调用的工具模型调用了不该调用的工具每条bad case都要写清楚期望行为是什么然后才会进入优化池。这样你的系统不需要重新训练模型只是通过调整Prompt、工具描述、上下文拼接方式就在不断变好。我见过太多团队上线之后就躺平了——模型跑通就算完效果好不好全看运气。这其实是巨大的浪费。模型本身的智力是买来的但工程上能不能把这份智力用好靠的是你的数据飞轮转得快不快。写在最后从零开始做AI工程说难也难说简单也简单。难在你要同时理解模型能力、系统工程、用户体验三件事任何一个短板都会在某个环节卡住你简单在于它的路径极其清晰——需求拆解、技术选型、Prompt设计、Agent编排、评测验证、上线迭代每一步都有章可循。我个人实践中最深的体会是不要迷信任何单一环节的银弹。最强的模型也扛不住混乱的上下文最完美的Prompt也救不了糟糕的检索工具再多也替代不了清晰的状态管理。AI工程是个木桶每一块板都不能太短。如果你正在或即将踏上这条路我的建议是先手写一个最小的完整链路哪怕是30行代码跑通之后再考虑优化。这个最小闭环会让你对AI应用的真实运行机制产生直觉这种直觉会在之后的每一个决策里保护你。项目从零开始成长也是从零开始。写得不好没关系跑起来再去打磨这条路本身就已经值回票价了。