1. 先想明白AI工程和调参炼丹是两条完全不同的路这两年我陆陆续续被问过很多次同一个问题想做AI应用是不是先得学会训练模型每次我都得花十几分钟解释一件事——AI工程的核心工作根本不是把模型训出来而是把模型可靠地用到真实业务里。我见过太多团队第一周兴致勃勃接上大模型API觉得对话能跑通、能回答问题了项目就成了一大半。结果一到压测、灰度、上生产问题全冒出来了同样的提示词今天答得好明天答得烂检索回来的文档明明有答案模型却视而不见线上请求一多延迟和账单一起飙升。这时候大家才意识到模型只是一个零件而AI工程要解决的是整个系统的稳定性、可观测性、成本和迭代效率。所以这篇东西不教你怎么写Transformer也不贴论文公式。我想用一个真正从零搭过AI应用的人的口吻把AI工程这条路上最关键的几个环节——选型、上下文工程、微调决策、评估观测、上线迭代——掰开揉碎了讲清楚。适合正在做AI应用落地、或者准备从传统后端转型AI方向的人看哪怕你完全没有训练过模型也能照着这条路把第一版做出来。1.1 先给AI工程划一个范围如果非要用一句人话概括AI工程就是围绕大模型构建可靠软件系统的方法论。它和你熟悉的传统后端有个本质区别传统系统的行为是可预期的你写死了一个分支输入什么就输出什么大模型应用的行为是概率性的同样的输入温度调成0也得面对token级别的随机浮动。这个区别带来了一系列连锁反应。你的代码不能再假设模型一定按格式输出所以必须加结构化校验你的测试不能只写固定断言得用另一套评估逻辑判断回答是否达到预期你的监控不能只看接口报错率还得看上下文命中率、token消耗、回答质量的漂移。这些都是传统工程里不存在的课题。搞明白这一点之后再看市面上那些AI工程相关的岗位要求眼光就不一样了。你会发现真正值钱的能力不是谁更会写花哨的提示词而是谁能把模型放进一个可运行、可衡量、可演进的系统里。1.2 三条主线上下文、数据、闭环我做过的几个AI项目无论业务形态怎么变到最后都会收敛到三条主线上第一上下文工程。模型的聪明是预训练阶段决定的你改不了它的知识但你能决定它看到什么再回答。提示词怎么写、检索回来的材料怎么组织、怎么让它只依据给定材料作答、怎么保证输出格式合法——这些属于脚手架层面的功夫也是大多数项目前期投入最多的地方。第二数据工程。这里说的不是拿来训练模型的大规模语料而是针对你的业务场景建的小数据评测集、少样本示例、微调数据集、线上反馈样本。AI应用跑起来之后数据质量直接决定迭代速度。我常说模型能力是地板数据质量才是天花板。第三反馈闭环。模型上线不是终点你必须有机制知道它哪里答得不好把bad case沉淀下来再通过改提示词、补充检索材料、微调等方式让系统变好。没有闭环AI项目就是一个一次性的玩具。后面所有内容都是围绕这三条主线展开的。2. 从零搭第一套AI应用我现在的选型思路很多人一上来就纠结用哪个框架用哪个向量库其实这些都是末端问题。选型第一件事永远只有一个你的场景到底需要模型具备什么能力。2.1 模型选择先看参数以外的维度模型不是参数越大越好。我的判断维度按优先级排序大概是这样的任务复杂度纯粹做文本分类、实体抽取、格式转换中小模型完全够用便宜且快要做复杂的多步推理、长文档分析、代码生成才需要上旗舰模型。上下文长度如果你的业务要处理几十页的合同、整本书的问答长上下文模型能省掉一堆分块拼接的麻烦。函数调用/工具使用能力做Agent类应用时这一项比模型的知识量还重要。模型能不能按JSON Schema精确调用工具决定了你的Agent是靠谱的执行者还是失控的幻想家。结构化输出支持需要严格输出JSON的选原生支持约束解码的模型比提示词正则兜底稳一个量级。成本与延迟预算To C场景每增加100ms延迟转化率就跌一截To B场景每百万token的价格差在高峰流量下会变成巨大的成本鸿沟。我个人的习惯是首版不选贵的选最容易跑通的。先把端到端的链路走通再用评测集去对比不同模型的效果差异数据说话而不是靠发布会PPT说话。2.2 编排框架用还是不用取决于团队和时间市面上主流的AI编排框架核心价值其实是三件事管理多步调用链比如先检索再生成再校验、内置工具调用的循环逻辑、以及提供可观测的trace能力。我的建议很直白如果你只需要单次提示词一个工具调用别上框架直接写十几行代码调API最清晰。如果你的应用确实要处理Agent式循环模型可以多次调用工具再决定下一步那么值得用框架但一定要选团队里有人能读源码的框架。否则线上出问题时你根本不知道是框架的bug还是你的设计问题。框架的抽象层会掩盖细节所以无论用什么框架你都得对底层模型调用、prompt组装、结果解析这三层的实际行为有掌控。2.3 一套最小可用的技术栈长什么样我最近一个项目从零起手技术栈非常有代表性服务端用Python FastAPI模型调用统一封装在仓储层中间件只留了日志和鉴权检索组件自建用PostgreSQL的pgvector当向量库没有引入独立的向量数据库Agent循环自己写了个状态机没用重型编排框架观测直接接LangSmith后来换了自建方案。一句话总结选型哲学每个组件都必须回答它替我解决了什么不可替代的问题回答不上来的砍掉。3. 上下文工程实战提示词、RAG与结构化输出的门道上下文工程是AI应用开发里最软也最考验经验的部分。它不是念两句提示词口诀就完事的而是要系统性控制模型的输入。3.1 提示词工程的真面目提示词工程不是什么玄学它的本质是在模型的能力边界内用最少的token把任务定义清楚。我总结下来一套健壮的提示词包含这几块角色与目标一句话说明你是谁、要干什么。任务步骤把复杂的任务拆成有序的操作步骤模型在遵循步骤时出错率明显低于自由发挥。输入-输出格式约定包括输入内容的界限比如用XML标签包裹用户输入防止提示词注入、输出格式JSON结构、字段含义。边界与兜底明确不知道就直说不知道、只依据给定材料作答、禁止编造等规则。少样本示例给1到3个输入输出对比任何抽象描述都管用。这里最有价值的一条经验是**提示词也要做版本管理而且每个版本都要跑评测集。**我见过太多人改提示词完全靠感觉这次好像变好了这样根本没法回溯也不知道是哪句话起了作用。正确做法是把提示词当代码一样放进Git每次改动关联对应的评测结果。3.2 RAG的正确打开方式检索决定上限RAG检索增强生成被讲烂了但我观察到的真相是大部分项目的RAG效果差不是生成环节的问题而是检索环节根本没做好。我自己跑RAG的固定检查清单是这样的分块策略跟语义走不跟字符数走。按固定500字切分等于把完整的业务逻辑拦腰截断。我习惯按标题层级、段落边界、或者是语义完整的小节来切。块与块之间要有重叠或上下文粘合剂。有些信息在分块边界被切断检索会漏掉。实测下来加入父文档引用机制先命中小块再取所属大块整段送入上下文很有效。嵌入模型要和你的文档语言、领域匹配。通用嵌入模型处理垂直领域术语的效果通常不如专门在相似语料上微调过的模型。检索结果要排重、要按相关性筛选。一股脑把Top 20全部塞给模型看着是给了更多信息其实是干扰了模型注意力还烧了大量token。还有一个很多人忽略的点**RAG的G生成环节同样需要设计。**你不能简单地把检索结果拼在用户问题后面就算完而是要在提示词里明确告诉模型以下是参考资料如果资料中没有答案就直说不知道。否则模型会一本正经地脑补这是RAG应用最臭名昭著的幻觉来源。3.3 结构化输出这是AI应用的接口契约如果你做过任何一个需要把AI集成进业务流程的项目就会同意我的看法能不能稳定输出合法JSON比回答质量本身还重要。处理结构化输出我按三层递进来做第一层提示词约束明确JSON结构、字段类型、枚举值范围并要求只输出JSON不要任何解释文字。这层能解决80%的格式问题但挡不住偶尔的胡来。第二层解析校验写一个健壮的JSON提取器能容忍Markdown代码块包裹、前后多余文字、注释等常见异常。解析失败时要有明确的错误处理逻辑而不是让整条链路崩掉。第三层约束解码对于核心生产场景用模型服务商提供的结构化输出能力或本地的JSON模式约束生成。这层直接把生成合法JSON变成硬约束代价是略微增加耗时但换来的可靠性非常值。4. 微调到底做不做我的决策框架现在聊微调依然有一半人把它当成万能药。我的态度很明确**微调是最后手段不是首选手段。**绝大多数场景先优化提示词和检索效果能提升80%根本轮不到微调。4.1 区分知识缺失和能力不足微调解决的是能力不足解决不了知识缺失。这是很多团队栽跟头的地方。业务有私有资料库模型不知道——这是知识问题RAG就是干这个的加文档、调检索就行。模型不理解你的业务规则、输出风格、特定判断标准——这是能力问题才是微调的候选场景。模型推理逻辑不对、常识性错误——这是预训练阶段的根本能力问题小规模微调救不回来你应该换更强的基础模型或者干脆承认当前模型做不了这个任务。判断方法也很简单把同样的任务混入公开资料再问一遍。如果模型在公开资料上表现正常只在你的私有知识上胡说那一定是知识层问题微调治不了。4.2 真决定微调了数据集怎么建微调数据集的质量直接决定微调效果。我最怕看到的就是团队拿几百条我手写的问答对就开跑这在今天的大模型时代几乎是浪费时间。我的实战经验是数据量不是核心覆盖度才是。对一个垂直场景300条高质量且覆盖各类边界case的数据可能比3000条同质数据有用得多。从线上bad case里捞真实样本。把线上用户真实问过、但模型答错的case捞出来人工修正成标准答案这比你和同事脑补的问答对靠谱一百倍。混合构造用模型生成候选回复人工再修正。一个人的精力有限让生成模型当初稿写手你来当终审编辑效率能提升不少。训练集和评测集严格分离评测集里还得包含不该做什么的负例。4.3 微调后的回归测试微调最阴险的地方在于它可能在目标任务上变好却在别的能力上悄悄退化。所以微调完不能只看目标任务的评测分数还要跑一遍通用能力回归——我固定维护一个30条通用问题的冒烟集覆盖格式遵循、逻辑推理、拒绝回答、中文表达等维度。任何微调上线前目标任务分数要过线通用回归不得明显下降两个条件同时满足才会放行。5. 评估与观测没有这两样AI工程就是盲人摸象我觉得这是整篇里最重要的一节。**AI工程和传统工程最大的差异就是质量的定义不再那么容易量化。**你没法写一个单元测试说输出必须等于某个字符串。所以你必须建立一套适合AI应用的评估体系。5.1 评测集AI应用的地基不管是调提示词、调检索参数、换模型还是微调你都需要一把统一的尺子。这把尺子就是评测集。建评测集的几个建议首版不追求大追求有代表性。50到100条覆盖主流程、边缘case、易错case各三分之一就够你开始迭代了。答案标注要有参考答案评分标准。评分标准写清楚什么算对、什么算部分对、什么算错避免人评的时候凭感觉。版本化维护。每发现一个线上bad case修完就把它加入评测集。评测集是你的资产会随着项目一起成长。评测集要定期审查。当模型换大版本、或者业务规则调整后有些标注可能已经过时时不时抽验一下。5.2 LLM-as-judge的实战用法用大模型当裁判LLM-as-judge评估大模型这套路现在已经很成熟但很多人用不好。我踩过坑之后沉淀下来的规则是只让裁判做二选一或打分并给理由这类低阶任务不要让它做复杂的综合判断。裁判的提示词里必须包含业务标准不然它的审美和你的业务要求是两条线。一定要抽样人工复核裁判结果计算裁判和大V真人标注的一致率。一致率低于70%时你的裁判逻辑就得改。同一批回答固定用一个裁判模型对比不要今天用这个、明天换那个不然结果没有可比性。5.3 线上观测token、延迟、语义三件套线上观测真正常用到的指标不多但都很要命Token消耗与成本按用户、按功能、按天统计设置预算告警。AI应用上线的第一周成本失控是我见过最多的事故。延迟分位数不光看平均延迟要看P95和P99。大模型输出的流式特性让P99经常高得离谱。如果业务对延迟敏感就得做缓存、用小模型做初排、或者限制输出长度。语义质量漂移通过用户反馈按钮、自动判分器抽样、以及用户会不会复制你的回答再出去搜这类隐式信号持续判断回答质量有没有下降。模型服务商版本更新、你的提示词改动、检索库增删文档任何一个环节变动都可能让线上质量偏移。没有观测你就永远最后一个知道。6. 从0到1之后发布、迭代、团队协作的实操心得最后聊点偏工程管理和组织层面的东西。AI应用项目跑起来之后真正决定成败的往往是这些非模型因素。6.1 灰度发布与快速回退AI应用的发布比传统功能更需要灰度。原因是模型的输出是概率性的你本地评测集过得好好的线上遇到没见过的输入分布可能瞬间崩给你看。我的做法是新提示词或新模型版本先放10%流量同时挂着自动判分器分数对比基准版本。一旦分数下跌超过阈值自动回退无需人工介入。这个机制看起来简单但能救命——我有一次就是在放量到30%之前靠这套机制拦下了一个检索参数变更导致的大面积答非所问事故。6.2 迭代节奏Fast iteration beats perfectionAI项目的迭代节奏应该比其他软件项目更快、更碎。原因是最优解往往藏在评测数据和bad case里而不是一开始的蓝图里。我的固定节奏是**每周一个完整迭代循环——捞bad case、补评测集、改提示词或检索、跑回归、灰度上线。**这种节奏看起来琐碎但它是让系统质量稳步上升的最可靠方式。别搞憋大招三个月换个新架构这种玩法大模型技术演进太快三个月后你的方向很可能已经不是最优解了。6.3 给团队的一句话建议从传统后端转AI工程的人最大的优势是工程素养代码规范、监控告警、CI/CD、故障复盘这些在AI项目里一个都不能少甚至更重要。所以别觉得自己没做过AI就没有竞争力把模型当做一个行为不可控的第三方组件去管理你的工程能力恰恰是刚需。如果你正考虑带团队做第一个AI项目我的建议是让团队里每个人都亲自走一遍接API、写提示词、建评测、看trace的完整链路。只有亲手推过一遍才知道哪些环节疼哪些环节快。AI工程不是少数人的炫技它越来越像一门需要整个团队共同掌握的基础能力。我自己在这条路上最深的体会是**大部分所谓的模型效果不好拆到最后都是工程问题。**上下文没组织好、评测没建起来、数据没闭环这三件事干好了AI应用的成功率能翻一倍都不止。剩下的就交给时间和耐心一套一套把case磨干净系统自然会变好用。