开头先聊清楚“AI工程”到底是什么再动手这些年我在一线带过不少AI项目发现一个特别普遍的现象很多人一提到AI工程第一反应就是“调Prompt”“接API”“让大模型跑通一个Demo”。等Demo真的跑通了又开始头疼——生产环境一上输出不稳、成本失控、回归问题一堆最后项目不了了之。说白了大家缺的不是模型能力而是一整套从零开始把AI做成“工程”的方法论。这个“ai-engineering-from-scratch”项目其实就是我把自己过去几年踩坑的经验整理成的一套AI工程搭建链路。它不教你怎么训练模型也不讲高深的数学推导核心就一件事当你只有一个业务诉求和一颗想要落地的决心时怎么从零设计、搭建、评估、迭代一个AI系统。我给它起了个朴素的名字——“从零开始的AI工程”对应的就是那条被无数人忽视的完整链路数据准备、Prompt设计、评估体系、Agent工作流、系统集成、监控回归。这篇文章是给谁看的如果你是个正在做AI应用的产品经理、后端工程师、测试开发或者刚带团队做AI项目的技术负责人这篇内容应该能帮你少走大半年弯路。我尽量把那些文档里不会写出来的经验、决策时的“为什么”以及具体到可以直接抄作业的步骤都摊开来讲。核心关键词就三个AI、engineering、from scratch。它解决的核心问题就是让AI系统从“发明”变成“生产”。1. 项目定位与整体思路拆解1.1 先搞清楚“AI工程”和“调模型”的边界很多人把AI工程等同于“调用大模型”这个认知偏差是项目烂尾的第一原因。真正的AI工程起点不是模型而是“我要把一个不稳定的智能体嵌入到一个需要稳定运行的业务系统里”。这句话怎么理解我举个例子。你做一个客服问答机器人模型调用只是一个环节。你要考虑用户问法怎么归一化、知识库怎么切片、模型答错之后有没有兜底话术、回答延迟能不能接受、满足率怎么统计、模型升级后会不会把之前跑通的问题搞挂。这些全部加起来才叫AI工程。所以我做这个项目时定的第一个原则就是把模型当作系统中一个可替换的组件而不是系统本身。这意味着所有围绕模型的输入输出都要有标准化封装都要有日志、评估、回滚机制。模型升级就像换发动机底盘和外壳不能动。1.2 从零搭建最适合的切入场景从零开始做AI工程最容易上手、也最能暴露全链路问题的场景是什么我个人的答案是文档智能问答。理由有三条。第一业务价值直观老板能看懂用户能感知第二数据获取容易公司内部随便找几千份文档就能开工第三整个链路足够完整涉及切分、召回、上下文组装、Prompt生成、答案评估几乎覆盖了AI工程的七大核心环节。做完这个场景你再迁移到客服、数据分析、流程自动化等任何方向都是顺水推舟。项目初期我就定了一个“最小可用闭环”的目标不要贪多先把一条链路彻底打通。具体来说就是下面的流程文档上传 → 自动切分 → 向量化存储 → 检索召回 → 拼接上下文 → 模型生成 → 答案评估 → 日志回流这里面没有任何一个环节是“高大上”的但每一个环节都有坑。跑通这个闭环才算摸到了AI工程的门槛。1.3 四条铁律SOP化、可评估、可回滚、成本可视这个项目能走到今天核心靠的不是哪个模型强而是我一开始定的四条铁律。这些原则帮我在无数个“看似成功”的Demo面前保持了清醒。第一条一切流程SOP化。无论是数据清洗、Prompt撰写还是评估集构建全部要有标准操作流程。哪怕是“人工润色答案”这种听起来很主观的事情我也要定义清楚什么情况需要润色、润色到什么程度、润色完谁来复核。没有SOPAI工程就是靠运气活着。第二条一切改动可评估。改Prompt、换模型、调参数绝不能靠感觉。我在项目里坚持一个习惯——任何改动都必须在一套固定的评估集上跑一遍得到量化指标后才能上线。评估集就是AI工程的“测试用例”它是一切改动的裁判。第三条一切版本可回滚。前面的评估集跑得再好生产环境也可能出现没见过的Case。所以我给每个线上版本都做了完整备份包括Prompt版本、参数配置、模型版本。一旦线上出问题一键切回旧版本而不是紧急修新版本。第四条一切成本可视。AI项目的成本不是买服务器而是Token消耗。我见过太多项目上线后才发账单崩了。所以在链路设计之初每个环节的Token消耗都要打点统计按请求维度记录输入长度、输出长度、模型单价做到“每一分钱都有出处”。这四条铁律写起来很轻执行起来全是功夫但它们是整个项目的地基。2. 核心细节解析与实操要点2.1 数据准备不是“喂得越多越好”而是“切得越准越好”文档问答场景里数据准备的核心工作不是清洗脏数据——虽然那也很重要——而是文档切分。切分做不好后面的检索和生成全是空中楼阁。很多人上来就用固定字符数切文档比如每500个字符切一段。这个做法在纯文本上勉强能用但一到真实业务文档就翻车。排版复杂的PDF、带表格的Word、有章节层级的技术手册固定长度切分会把语义完整的一段话拦腰截断也可能把两段无关的内容硬拼在一起检索召回的质量会直线下降。我实践下来比较稳的策略是**“层级切分 语义回退”**。具体做法分三步结构识别优先按文档本身的层级切分比如章节、标题、段落。现在很多解析工具能把PDF的目录结构抽出来用结构去切语义完整性最高。阈值控制每个切分块控制在一个合适的大小。块太小召回时上下文信息不够模型答不透块太大Token成本高且容易混入噪声。项目里我常用的是每块256到512个Token之间具体数值取决于你下游生成时能拼多少上下文。重叠窗口相邻块之间保留10%到20%的重叠内容防止切分边界把关键信息卡掉。比如实体名称、承上启下的转折句刚好被切开重叠窗口能大幅降低这种概率。贴一段我当时用的切分逻辑伪代码核心思想就是“优先结构补充长度带重叠回退”def smart_split(document, max_tokens512, overlap_ratio0.15): blocks [] # 第一优先按文档结构切标题/段落 structural_blocks extract_by_structure(document) for block in structural_blocks: token_count count_tokens(block) if token_count max_tokens: blocks.append(block) else: # 长度超限按句子边界二次切分并保留重叠 sub_blocks split_by_sentence(block, max_tokens, overlap_ratio) blocks.extend(sub_blocks) return blocks这套方案在项目里的实际效果是检索命中率直接提升了20个百分点。所以说在AI工程里数据的“形状”比“数量”更重要。2.2 Prompt工程本质是接口设计不是“咒语编写”Prompt工程这几年被炒得很玄我自己的体会是别把它当“咒语”要把它当“接口文档”来设计。一个生产级的Prompt最核心的是稳定不是花哨。我在项目里把Prompt拆成五个组成部分每一部分都有明确的职责角色指令模型以什么身份、什么立场来处理输入。比如“你是一名资深技术支持工程师”。任务描述模型要完成什么任务输出什么格式。要具体到“根据提供的文档片段回答用户问题。如果文档中没有相关内容请明确回答‘未找到相关信息’”。约束条件禁止什么、必须避免什么。比如“不要编造文档中不存在的事实”“回答不超过200字”。输入数据这里注意不是把检索到的内容一股脑塞进去而是要先做“上下文筛选”。我之前吃过教训——模型面对一堆不相关的内容时容易被带偏。输出格式结构化输出一定要用JSON Schema约束方便下游解析。不要靠“请以JSON格式输出”这种软性指令直接给Schema最稳。另外一个非常关键的技巧是**“思维链与落地诉求的平衡”**。思维链能显著提升复杂推理任务的准确性但会拖慢响应、增加Token成本。我的经验是只有任务本身需要多步推理时比如代码修复、复杂数据分析才开启思维链简单问答不要开浪费钱还延迟高。按任务类型区分Prompt模板是这个项目里性价比最高的优化之一。2.3 评估体系LLM-as-judge的落地姿势AI工程被骂“不靠谱”最大的原因就是没有评估体系。传统软件有单元测试、回归测试AI系统呢输出是开放的不能简单断言。这时候就要用上“模型判官”的思路——用一个强模型去评估另一个模型的输出质量。LLM-as-judge这个做法网上讨论很多我落地之后发现几个容易忽视的细节第一评估维度要分开打分不要笼统评分。我常用四个维度相关性、准确性、完整性、可读性。每个维度单独打分1到5分最后再算加权总分。混在一起打分模型判官很容易“和稀泥”区分度低。第二评估Prompt要带参考答案和评判标准。光让模型打分它不知道“好”的标准是什么。我每次评估都会把原始文档片段、标准答案、模型输出一起喂给判官同时附上明确的评分锚点比如“出现与文档矛盾的信息准确性直接判1分”。这样打分的一致性能大幅提升。第三样本集要持续回流。评估集不是建一次就完事。每次线上用户反馈“答得不好”我都把真实Case回收人工标注后加入评估集。这样评估集会越来越贴近真实分布模型的迭代方向才不会跑偏。项目里我大概每两周扩充一次评估集这比任何花哨的监测指标都实在。2.4 Agent工作流从“单次问答”进化为“多步任务”文档问答跑通之后我开始把能力扩展到真正的Agent场景——让系统自主完成多步任务比如“查一下上月销售数据分析异常原因生成一份报告草稿”。这里要做的核心改造有三块工具调用规范模型不能直接操作数据库或调用任意函数而是通过一套预先注册的工具集来做。每个工具必须有明确的“功能描述”“参数Schema”“返回格式”。模型只负责“选择工具填参数”剩下的事交给调度器。记忆管理多轮任务必须有记忆。短期记忆可以放上下文长期记忆则要入库。项目里我用的是“近期对话摘要关键实体持久化”的结构既控制Token消耗又保留多轮对话能力。护栏机制这是最容易忽略的一块。模型在Agent模式下自由度大很容易“跑飞”。我设置了三道护栏一是工具白名单模型只能调用注册过的工具二是最大步数限制超过设定步数强制终止并转人工三是合规输出检查涉及敏感内容或不符合业务规范的输出直接拦截。Agent工程的核心不是让模型“更聪明”而是让系统的确定性边界足够清晰。模型可以在边界内自由发挥但边界本身由工程人员牢牢守住。3. 实操过程与核心环节实现3.1 第一步搭起最小可用的工程骨架前面讲了那么多理念这里开始上实操。我按项目推进的真实过程给你拆一遍“从零到一”的关键步骤。项目启动时我选的技术栈是这样的Python FastAPI做应用层Milvus做向量库LangChain做流程编排底层模型用的当时稳定性和性价比都比较均衡的一款商用大模型。后来的经验是技术栈不是重点重点是每一层职责要清晰应用层管交互编排层管流程模型层管生成向量库管记忆。搭骨架的核心动作是定义“数据流接口”。项目里所有环节之间都传递标准结构我把它定义为{ query: 用户原始问题, documents: [检索到的文档块], prompt_template: 使用的模板ID, llm_config: {model: 模型名称, temperature: 0.2}, response: 模型生成结果, meta: {latency_ms: 850, tokens_used: 1200} }所有环节只认这个结构不认别的。这样做的好处是后面调Prompt、换模型、加工具都只是改某个环节内部实现接口一律不动。这个设计让迭代成本低了一个数量级。3.2 第二步写Prompt模板与完成第一版线上对话骨架搭好后我最先做的事不是调优而是把一套“能用的Prompt模板”固化下来。为什么强调“能用”因为初版永远不完美但必须有基线版本。没有基线后面所有“优化”都无从对比。我给文档问答场景设计的第一版Prompt模板大概是这样的你是公司内部的技术支持助手请根据下面的参考资料回答用户问题。 参考资料{context} 用户问题{query} 要求 1. 只依据参考资料回答禁止编造 2. 如果参考资料中没有答案回复“未找到相关信息” 3. 回答控制在200字以内使用简洁的技术风格。这个版本很朴素但它是整个项目的第一个基线。上线后我收集了三天的真实对话日志发现三个问题一是回答经常包含“根据提供的资料”这种废话前缀二是某些问题回答太长三是有小概率模型无视资料开始自由发挥。于是第二版Prompt立刻迭代你是公司内部的技术支持助手。 参考资料{context} 用户问题{query} 规则 1. 直接给出答案不要解释你如何找到答案 2. 严格基于参考资料严禁引入外部知识 3. 若参考资料没有明确答案仅回复“未找到相关信息” 4. 回答不超过150字关键信息靠前。对比两版改动不算大但都提炼自真实日志。这就是我想强调的Prompt是养出来的不是写出来的。每一版Prompt都要由线上反馈驱动迭代。3.3 第三步建立评估集并用模型判官打分基线Prompt稳定后我立刻做了一件很多团队会拖延的事——建评估集。我知道这活儿枯燥但它是AI工程里最值得投入的部分。评估集的来源构成我建议这样分配来源占比说明真实用户问题脱敏后60%从线上日志抽样覆盖最高频场景人工构造的边缘Case25%故意刁难模型覆盖相似问题、否定表达、超长问题业务专家提供的典型问题15%让真正懂业务的人出题保证专业深度第一版我建了120道题每一道都配了标准答案。评估方式用我前面说的LLM-as-judge四个维度打分。这一跑基线分数就出来了相关性4.1准确性3.8完整性3.5可读性4.2。这个分数列表就是我后续所有迭代的“方向盘”。这里有个心得要分享不要追求所有指标都高要结合业务定优先级。比如我这套文档问答业务上“准确性”是第一位的回到整体评估时权重就设为0.5其他三项各0.17左右。后续迭代优先冲准确性不为相关性或可读性的小波动分心。关键是每次改动Prompt或者换模型都在同一套120题上跑分对比。分数涨了才上线没涨就回滚。这个流程坚持下来模型的输出质量是稳定向上的而不是上下乱跳。3.4 第四步日志、监控与迭代节奏最后一步也是很多“从零开始”项目最容易漏掉的一步可观测性建设。AI系统的日志和普通接口日志不一样除了记录请求、响应、耗时必须额外记录这几个字段检索结果、Prompt版本、模型版本、Token消耗、模型判官评分。为什么要记这些因为AI系统的“问题复现”逻辑和传统软件不同——同一个问题换个Prompt版本可能答案就变了同一个Prompt版本模型悄悄升级了行为也会漂移。没有这些日志字段你根本没法事后排查。项目里我用了一套简单但好用的打点方案每次请求结束异步写一条JSON日志到本地文件系统再由定时任务汇总进数据库。日志样式大概是{ time: 2025-06-11T10:00:00Z, query: 续费流程怎么操作, retrieved_docs: [doc_1032, doc_1088], prompt_version: v2.3, llm: gpt-4o-mini, temperature: 0.2, tokens: 850, latency_ms: 780, judge_score: {relevance: 4.5, accuracy: 4.2, completeness: 4.0, readability: 4.4} }迭代节奏方面我在项目里磨合出一套“三周一小迭代两月一大迭代”的节奏。前两周收集线上日志和用户反馈扩充评估集第三周集中调Prompt、调参数、换模型候选跑评估集打分做一次小发布大迭代则用来做架构级改动比如引入Agent工作流、更新知识库切分策略、升级向量模型。这套节奏不强求“日日上新”但保证每一次改动都有数据支撑。AI工程不怕慢怕的是乱改一通然后退回原地。4. 常见问题与排查技巧实录4.1 问题一模型“一本正经地胡说八道”这类问题在AI工程里叫幻觉是上线后遭遇最频繁的投诉来源。排查思路其实不难先判断是“检索到的资料里根本没有相关信息”还是“有相关信息但模型没遵循”。我用一个笨但有效的办法鉴别把模型输出中的每个关键事实点回原文比对。如果原文里完全找不到对应内容那就是检索失败了如果原文有但模型答错了那就是Prompt指令不够强。对应两个方向的解法也不一样。检索失败要调切分策略和召回阈值模型没遵循就在Prompt里强化“仅依据资料回答”这类限制必要时结合规则拦截做后置校验。我在项目里还加了一道轻量的“引用溯源”——模型回答时强制要求附上引用的文档编号用户能一键跳转原文验证。这一招不仅降低幻觉感知还显著提高了用户对系统的信任度。4.2 问题二上下文太长答案被“淹没”文档多、检索块多、历史对话长几个因素叠加很容易出现“上下文塞满了模型反而找不到重点”的问题。这不是模型变笨了而是注意力被稀释了。排查时我习惯从Token消耗下手。打开日志看输入Token数如果动辄几千上万那就要做减法。我试过的有效做法有三种检索结果只取Top-K不要把“相关”的结果全塞进去控制在3到5块相关性不够宁可不要历史对话做摘要压缩多轮对话时把早期轮次压缩成一句话摘要只保留最近两轮完整对话上下文重排。强调相关字段放前面模型对开头和结尾的内容记忆更牢把最相关的信息放最前。4.3 问题三成本失控单次请求Token爆炸有段时间我的单次问答平均Token消耗从1200涨到了3500排查后发现了“隐形消耗”——检索返回的文档块里大量冗余内容也被拼进了上下文。修复方式很直接引入一个“上下文裁剪器”按检索得分裁剪到固定长度先把超长块过滤掉再做二次精排。另外一个容易被忽略的成本大坑是Agent模式。多步任务会反复调用模型每一步都在烧Token。我的做法是给Agent任务设置单轮预算全局超出预算就自动切到降级模式比如改用更小的模型或直接转人工。还有一招很实用给生成结果加缓存。相似问题在指定时间窗口内直接命中缓存不重复调模型。这笔账算下来能省20%到30%的Token费用。4.4 问题四模型升级后旧功能的回答质量反而下降这其实就是“行为漂移”我在实际项目里踩过不止一次。有一次模型供应商发布了新版本官网说明是“智能提升对话更自然”结果我们的评估集分数全面下跌——模型变得“太自然了”开始天马行空不再严格遵循“只依据资料回答”的约束。这件事给我的教训很深商用模型的版本升级绝不能无脑跟随。我把所有模型请求都显式绑定版本号绝不使用“最新版”这种动态指针。任何新模型版本上线前都要在完整评估集上跑一遍对比测试过了才切换。同时在代码层面预留“模型路由开关”一旦新版本行为异常一键切回旧版本。经验是一刀一刀切出来的。我后面还专门在监控里加了一项“质量漂移预警”每天统计评估指标的周环比跌幅超过阈值就自动告警。有了这个机制模型行为漂移不再是“事后发现”而是能提前干预。从一段经验到一套方法这个“ai-engineering-from-scratch”项目做到现在我最大的体会是AI工程的“难”不在于哪个环节有多高深而在于把所有环节连成一个可稳定运转的系统。单点上有无数现成的工具和教程但从零到一打通整条链路并且让它在真实业务里持续产出价值需要的是一套纪律——SOP化、可评估、可回滚、成本可视。如果你也正准备从零搭一个AI项目我给你的建议是不要从“最酷的功能”入手而是从“最小的闭环”入手。先用最笨的方式把整条链路跑通哪怕效果普通也没关系。然后建立评估基线让数据告诉你下一步该往哪走。最后记得给你的系统装上日志和护栏让它在无人盯守时也能按规矩办事。我个人操作中还有一个压箱底的小技巧每个迭代周期结束时花半小时把决策过程写下来——改了什么、为什么改、评估结果如何、有什么副作用。这个习惯让我的项目在半年后回头看时每个决策依然有迹可循。对于AI这种“随机性”很强的系统这种“确定性”的记录是整个工程最值钱的部分。