面向开发者的AI工程实践指南

本文旨在为有经验的软件工程师提供AI工程化实践指南。作者拥有15年后端开发经验，发现LLM引入生产环境后，传统规则不再适用：系统默认非确定性、输入为自然语言、单元测试无法评估输出质量。

AI工程概述

基础模型是新一代抽象：经过大规模混合语料预训练，可通过API调用适配多种任务，无需重新训练。例如，Gemini 3.1 Pro既能撰写营销邮件，也能分类客服工单、生成SQL、总结百万token代码库、调用工具。工程师的角色转变为构建围绕模型的系统，而非模型本身。

基础模型适用于代码、写作、图像视频、教育、对话、信息聚合、数据组织、工作流自动化等场景，但不适用于精确算术、实时事实（无接地）、以及任何不能容忍轻微错误的场景。

AI工程 vs ML工程 vs全栈工程

ML工程关注模型训练：数据管道、特征工程、超参数调优。AI工程关注利用预训练模型构建应用：提示、检索、评估、智能体、推理服务、可观测性。AI工程师是后端工程师，额外承担系统接地、持续评估、以及控制成本与延迟的责任。

三层技术栈

• 应用层：提示、RAG、智能体、UI、业务逻辑。
• 模型开发层：微调、模型合并、蒸馏、数据集工程（可选）。
• 基础设施层：GPU、推理服务器、向量数据库、网关、可观测性。

大多数团队驻留应用层，仅在必要时下沉。提示工程和RAG达到瓶颈时考虑微调；成本、数据驻留或硬件限制迫使自建推理基础设施时考虑基础设施层。

适配LLM的方法

按成本递增：提示工程（最便宜、最快）、RAG（运行时注入上下文）、微调（改变权重）。默认顺序：提示→RAG→微调。不要跳过步骤。

选择LLM

2026年模型类别：封闭前沿（最高质量、高成本）、封闭中端、封闭廉价（批量任务首选）、开源权重（自建GPU）、专用模型（嵌入、重排序等）。选择依据：任务适配、成本、延迟、上下文窗口、输出结构、运行位置。多数团队应使用多个模型，将低成本请求路由到廉价模型。

规划AI应用

AI功能规划不同于传统功能，因为输出质量非二进制。规划需包含明确的质量检查点：用例评估（真实问题？概率输出容忍度？错误成本？）、设定预期（开发时间至少为常规功能的2倍，主要用于评估和边缘情况）、里程碑规划（快速达到“勉强能用”→评估→生产加固）、持续维护（模型漂移、提示退化、数据变化）。

“勉强能用”里程碑至关重要：尽快交付真实用户，观察问题并修复，而非在隔离环境中追求完美。

挑战

• 开发：提示无法进行确定性单元测试，需提前构建评估数据集。
• 部署：推理慢、昂贵、突发性强，需缓存、批处理和路由。
• 维护：模型版本迭代、分词器变化（如Opus 4.7新分词器可能增加35% token）、幻觉演变，需监控和红队测试。

行业用例与ROI

高回报场景：客服分流、内部文档RAG搜索、代码辅助、文档自动化。低回报或负回报场景：面向用户的错误答案导致品牌危机、尝试替换确定性API、无人维护的演示项目。

理解基础模型

训练数据决定模型能力。多语言模型在主要语言上表现良好，但长尾语言薄弱。领域专用模型在特定领域有小幅提升，但大多数情况下，通用模型配合RAG在质量和操作简便性上胜出。

模型架构与规模

主流是仅解码器Transformer，部分采用混合专家模型。模型规模仍重要，但精心调优的70B模型可击败欠调优的400B模型。推理模型（如Gemini 3.1 Pro思考模式、Claude扩展思考）将关注点从参数数量转向测试时计算量。

小语言模型、多模态、领域专用与推理模型

• 小语言模型：可在单GPU运行，适用于分类、路由、简单摘要等低成本任务。
• 多模态：图像、视频、音频已成为一等输入，需决定是否预处理以控制成本。
• 推理模型：内部长思维链后响应，适合数学、代码、规划，但更慢更贵。