从调Prompt到构建系统：AI应用开发工程化实战指南

这几年我带过不少新人也面试过不少人。一个特别典型的画面是候选人能一口气说出十几种提示词技巧能现场做出一个玩具机器人但你把一份真实的需求文档放到他面前告诉他“这个功能要上线、要稳定、要考虑成本”他就开始眼神发飘。我自己也经历过那个阶段。最初学 AI 应用开发满脑子都是“把 prompt 写好调通接口能跑就完事”。后来项目做多了才明白用 AI 写一个 demo 和把一个 AI 能力嵌进真实业务里中间差着整整一个“工程化”的鸿沟。吴恩达那条“AI 工程技能图”系列里第五张图正好卡在这个位置从实现需求到参与整个构建过程。我觉得这是整个系列里最值得反复读的一张因为它不再教你“怎么用模型”而是教你“怎么把模型用在真实项目里”。这篇内容适合谁两类人。一类是已经能用大模型 API 做点东西、但一面对真实业务就不知道从哪下手的开发者另一类是刚进入 AI 应用团队、想从“接需求写 prompt”升级成“参与完整构建”的准工程师。我会把这阶段的核心能力拆开讲再用一个完整的实操案例带你从头到尾走一遍真实的构建过程。1. 先搞清楚这一阶段在整个技能图里的位置1.1 前几张图是“会用工具”这张图开始“建系统”吴恩达这套 AI 工程技能图我个人理解是一层一层爬楼梯最开始是理解大模型的基本能力然后学提示词、学调参再往后是学 RAG、学 agent、学如何把多个模型能力组合起来。前面那些阶段的核心目标是让 AI 完成“单个任务”。你告诉它“总结这段会议纪要”它给出一个不错的结果任务就结束了。但到了第五张图“实现需求”这件事的标准变了。给一个 prompt模型输出一段文字这只能叫“实现了需求”吗在真实工程里显然不是。真正的实现需求要考虑数据从哪来、结果怎么校验、出错怎么办、用户怎么访问、延迟和成本能不能接受甚至还要考虑这个功能上线后会不会被滥用。这一阶段的训练目标不再是把“任务做好”而是把“构建过程走通”。所以这个系列越往后越不像是“AI 应用课程”反而更像是“软件工程课程”。只不过传统软件工程的操作对象是函数、模块、数据库而这里的对象变成了大模型、向量库、提示词和 agent。1.2 “实现需求的人”和“参与构建的人”差在哪有一个很直观的对比我在面试里经常用维度只会实现需求的人参与整个构建过程的人面对需求拿到直接写代码、写 prompt先问背景、用户、边界、验收标准技术选型用什么顺手用什么按成本、延迟、隐私、效果综合取舍异常处理报错就改改完就算提前设计超时、降级、重试、兜底逻辑质量判断跑几个例子看着不错建评估集用指标说话上线意识本地能跑 完成部署、监控、灰度、回滚都要管协作方式被动接需求主动和产品、测试、运维对齐你会发现差别不在于“会不会调模型”而在于有没有“工程闭环”的意识。第五张技能图训练的就是这个闭环从需求分析到方案设计到技术选型到实现到测试再到上线维护。我自己带团队时有个习惯新人来了先不给核心任务让他跟着一个完整项目走一遍。目的不是让他多干活而是让他亲眼看到一个 AI 功能是怎么从一个模糊的想法变成一个稳定运行的系统。这个“看到全局”的过程比写十段漂亮代码都值钱。2. 这个阶段真正要练的四个核心能力2.1 需求理解与拆解把模糊想法翻译成工程任务大多数真实需求天然是模糊的。业务方跑过来跟你说“帮我们搞一个智能客服能回答产品问题就行。”这句话如果直接拿去开干必踩坑。“能回答”是什么标准回答错了算谁的产品问题是哪个产品知识库有没有资料用户问的是售前问题还是售后问题单轮还是多轮上线后人工怎么介入这一阶段最该练的第一个能力就是“追问”。在动手之前至少要搞清楚五件事用户是谁内部员工还是外部客户技术人员还是普通用户。核心使用场景是什么多少用户、多高频、什么时间用。成功怎么定义是回答准确率达到 90%还是人工客服转接率降低 30%。失败怎么处理答错之后有没有兜底用户能不能一键转人工。数据从哪来有没有现成的文档、FAQ、历史工单格式是什么。我见过太多项目死在需求不明确上做着做着才发现业务方想要的功能和最初描述的完全是两码事。所以每次需求会我都会拿着问题清单逐条确认宁可多问一句显得“不懂业务”也不要做到一半推倒重来。2.2 方案设计与技术选型没有最好的技术只有最合适的需求清楚了紧接着就是选型。很多人一上来就想着“我用哪个大模型”其实模型只是整个方案的一部分。一个完整的 AI 应用方案至少要回答这几个问题用闭源 API 还是开源本地部署这关系到成本、数据隐私和可控性。要不要做 RAG知识是静态文档还是动态数据需不需要联网检索要不要微调模型能力是否真的不够还是提示词可以解决要不要引入 agent流程是否需要多步骤推理、调工具、查数据库架构上怎么组织哪些逻辑走 AI哪些逻辑走传统代码拿真实场景说。前段时间一个项目要做行业问答助手客户一开始坚持要本地部署大模型理由是“数据不能出内网”。我给他算了一笔账本地部署一个中等规模的开源模型需要高性能 GPU 服务器一次性硬件投入几十万还要配运维如果用主流的 API核心数据做脱敏只把查询语句发出去一年成本可能只有几万块。最后客户接受了 API 方案但加了一条敏感数据本地做关键词过滤绝不出网。这就是选型的真实逻辑不是哪个技术听起来高端选哪个而是对成本、延迟、隐私、效果做综合权衡。这一阶段练的核心能力就是能在多种方案里为具体场景找到最合适的组合。2.3 工程化交付把原型变成可靠系统原型和系统的最大区别就是系统要考虑“异常情况下还能不能扛住”。我有个很朴素的判断标准如果一段代码只在 happy path 上能跑通那它只能叫脚本不叫产品。AI 应用的工程化有四个地方最容易暴露问题上下文工程。RAG 检索回来的内容怎么拼装、怎么截断、怎么去重直接影响输出质量。工具调用。agent 调用外部工具时工具的输入输出格式、错误返回、超时处理都要设计好。版本管理。提示词版本、模型版本、评估集版本全部要纳入版本控制不然哪天效果变了你根本不知道是哪个改动引起的。可观测性。每次请求的输入输出、token 消耗、延迟、命中哪几条知识都要有日志否则线上出了问题完全没法排查。其中提示词版本管理最容易被忽略。我见过很多团队prompt 直接写在代码里改一版覆盖一版最后谁也不知道线上跑的是哪一版。后来我们强制要求所有 prompt 走配置文件加版本号每次修改都记录 diff效果波动时能随时回滚这才算把“提示词”当成正经代码来管。2.4 质量保障与迭代AI 系统的测试不能靠“感觉”传统软件有单元测试、集成测试、回归测试AI 应用一样要有而且要更早做。为什么因为大模型是概率系统这次输出“很好”下次可能输出“很差”。如果只靠肉眼抽查几个例子你根本不知道整体质量是上升还是下降了。我强烈建议从项目第一天就建评估集。什么是评估集就是一批“标准问题 期望答案要点”的样本集数量不用太多一开始 50100 条就够。每次改动提示词、换模型、调检索逻辑都拿这批数据跑一遍用指标看效果变化。评估方式有两种一种是人评准确但慢另一种是用 LLM 自动打分快但需要设计好评分标准。两年前我们全人工一次评估要半天后来发现让一个强模型当“裁判”把评估标准写清楚效果和人工接近但时间缩短到十几分钟。这个阶段建议两条腿走路常规迭代用 LLM 自动评估重要版本发布前加一轮人工抽检。3. 实操过程从一条模糊需求到一个可运行的 AI 应用3.1 需求阶段先跟“甲方”聊透再动手为了让你看得更具体我用一个真实做过的项目来讲完整流程需求一句话“做一个内部资料问答助手。”这个需求刚拿到手时跟“做个智能客服”一样模糊。我们坐下来聊了一个小时把几个关键问题敲定用户是公司内部运营团队约 80 人日常需要查询产品文档、运营手册、活动规则。使用场景是上班时间高频查询每次查询两三句话以内要快速给答案。成功标准是首答能够解决 70% 的问题未解决的能给出相关文档链接。失败兜底是在回答末尾固定提供“转人工群”入口避免用户卡住。数据来源是三个内部知识库产品文档、运营手册、历史 FAQ绝大部分是 Word 和 PDF。聊完之后我们开了个一句话需求文档发给业务方确认。这一步看似浪费时间实际上省了一堆返工。后来业务方看文档时补了很重要的一条很多查询是“最近有没有什么新活动”这意味着知识库里必须有时效性内容不能只靠静态文档。3.2 选型阶段为什么先用 RAG而不是微调或纯提示词拿到需求接下来选型。当时我们的判断是这样的不需要微调。因为模型本身的通用能力已经很强问题在于模型不知道我们内部的知识而这是知识注入问题不是风格或能力迁移问题。做 RAG 是性价比最高的路径。把知识库文档切片、向量化查询时先检索再让模型基于检索结果回答。模型选择上用闭源 API因为内部数据做了脱敏且上线时间紧自建部署来不及。向量库选了开源的数据量不大单机部署完全够用。技术选型最常见的误区是“为了用某种技术而用”。如果知识库只有 20 个文件用户提问模式也很固定那纯提示词加全文搜索可能就够了如果 90% 的问题都要推理用户意图、多轮对话那 RAG 也不够可能真要上 agent。选型永远跟着需求走。成本方面我们也做了粗略估算假设日均 1000 次查询每次消耗 3000 token用主流 API 的中等模型一天的成本大概在几十块钱量级业务方完全可以接受。这个数字拿出来选型会就没有争议了。3.3 实现阶段提示词工程 检索 agent 编排实现阶段是整个过程中代码量最大、也最容易翻车的地方。我们的核心链路是用户提问 → 检索知识库 → 组装上下文 → 调用模型生成回答 → 返回结果并记录日志。核心提示词我简化一下大概是这样的你是一名内部知识助手。请严格基于提供的资料回答用户问题。 规则 1. 如果资料中有明确答案用简洁的语言回答并标注来源文档名称。 2. 如果资料中没有答案明确说“资料库中未找到相关信息”并引导用户咨询运营支持。 3. 不要编造资料中不存在的信息。 4. 如果用户问的是多轮问题结合历史对话上下文理解意图。 资料 {retrieved_chunks} 历史对话 {chat_history} 用户问题 {user_query}这段提示词里藏了几个关键设计。第一明确“不要编造”这是缓解幻觉最直接的手段第二强制标注来源文档用户能溯源第三给出“不知道”时的标准话术避免机器人答非所问。这几条看起来简单但缺一条线上效果都会明显打折扣。检索部分我们用的是“先关键词粗筛 再向量精排”的组合。纯向量检索有时候会漏掉精确匹配比如产品型号搜出来是另一个相近型号加上关键词粗筛先把候选范围缩到 100 条再做向量排序准确率高很多。当时我们还没上复杂 agent只在两个地方做了工具调用一个是查知识库一个是调内部活动排期接口。当用户问“最近有什么新活动”时系统先调排期接口拿最新数据再和知识库内容一起组装成上下文。这就已经是一个最简 agent 雏形了有决策路由、有工具调用、有上下文组装。如果你想练 agent从这个规模入手比一上来就搞一堆工具编排靠谱得多。3.4 评估与上线先建评估集再谈发布会这功能开发只用了三天但上线前我们花了两天做评估。第一天从真实运营群里收集了 100 个历史问题覆盖产品、运营、活动三大类逐条写好期望答案要点这就是第一批评估集。然后跑了三版候选配置各跑一遍用 LLM 自动打分加人工抽检 20 条。评估结果记录大概是这样的配置版本检索方式模型评分备注v1纯向量claude-haiku6.8精确型号查询有遗漏有编造成分v2关键词向量claude-haiku8.1检索改善但活动类回答仍有时效性问题v3关键词向量排期接口claude-sonnet8.9效果达标成本略高可接受最终选择 v3 上线。上线当天我们做了三步先内部小范围试用再放到 10% 用户灰度最后全量放开。同时每天跑一次评估集监控评分波动日志里专门加了一个字段记录用户有没有点击“转人工”入口一旦转人工率上升立刻回滚上一版。我印象很深的是灰度第三天评分突然从 8.9 掉到 7.6。排查下来是知识库更新了一批新文档但切片程序没跑导致检索结果还是旧数据。从那以后我们给知识库更新加了自动触发重建索引的定时任务这类问题再没出现过。4. 常见问题与排查技巧实录4.1 四个高频坑几乎是所有 AI 工程新人都会踩的第一个坑是“重检索、轻评估”。好多人把大量时间花在调 prompt 上却懒得建评估集。结果改一版觉得“好像好一点”再改一版又觉得“好像差一点”全凭感觉做事。没有评估集你连自己改坏了都不知道。第二个坑是“上下文塞太满”。RAG 检索回 10 个片段一股脑全塞进提示词结果模型抓不住重点回答又长又偏。一定要根据问题类型动态控制检索数量。我们实测下来普通问答场景下检索 35 个高质量片段效果往往优于塞 10 个片段。上下文不是越多越好越精准越好。第三个坑是“低估幻觉”。就算提示词写了“不要编造”模型依然可能一本正经说瞎话。缓解幻觉必须在系统层面做检索不到了就强制接口返回“未找到”而不是让模型自由发挥对于时效性数据优先走工具调用而不是文档检索关键数字类回答强制模型给出参考文献位置方便人核验。第四个坑是“上线就松手”。AI 应用上线不是终点知识库会变、用户提问方式会变、模型平台也可能调整。我养成的习惯是每周固定看一次评估集得分、转人工率、平均延迟三个指标任何一项异常都立即追查。没有监控的 AI 系统就像没装仪表的汽车开着开着就出事了。4.2 问题排查思路速查表现象可能原因排查步骤回答准确率突然下降知识库更新但索引未重建上游文档格式变化检查索引更新时间抽查最近入库文档回答很好但延迟很高检索返回太多模型上下文过长网络慢看日志里耗时分布逐段优化同一个问题每次答案不一样模型采样温度过高检索结果不稳定降低 temperature检查检索排序是否波动频繁答非所问用户问题表述与知识库脱节缺少关键词检索扩充同义词映射加关键词粗筛层成本飙高上下文越长越贵无效检索太多压缩上下文限制单轮检索片段数本该调工具却没调路由判断条件太严格prompt 没说明工具使用场景检查路由逻辑补充触发示例4.3 三个我用了很久的独家避坑技巧第一个技巧所有 prompt 改动都要做 A/B 对比。不要今天加一句“请用简洁的语言回答”明天又删掉完全不看数据。每次只改一个变量在评估集上跑完对比再决定去留。第二个技巧在日志里记录每个回答的“检索来源”。这样用户反馈正确答案时你能立刻看到是检索到了对的资料还是模型自己猜的。我靠这个发现过好几次数据源问题。第三个技巧给 agent 的每个工具调用都设计“失败返回值”。工具超时了要返回什么、查不到要返回什么都必须明确。很多 agent 效果不稳不是模型不行是工具异常后模型只能瞎编。写在最后的体会这个项目做完回看最大的转折点不是我把代码写得多漂亮而是我终于意识到AI 应用开发的核心矛盾不是“模型不够聪明”而是“工程不够扎实”。模型的能力边界就摆在那里能不能把它的能力稳定、可控、低成本地输出给用户完全取决于构建过程的质量。吴恩达那张技能图本质上是在提醒我们AI 不是一个“调包”的活是一个正儿八经的工程领域。从实现需求到参与整个构建过程跨越的不仅仅是技术栈更是思维方式。以前拿到需求我想的是“怎么实现”现在我先想“怎么定义成功、怎么兜底、怎么评估、怎么运维”。如果你正卡在这个阶段我的建议很直接别再只看教程了找一个真实的小需求哪怕只是给团队做一个问答机器人从头到尾走一遍完整流程。需求、选型、实现、评估、上线、监控每一步都踩一遍踩完你就真正入门了。