1. 为什么我从零开始做AI工程

过去几年，我见过太多团队在AI项目上从"惊艳demo"跌进"生产事故"的泥潭。模型在笔记本上跑得好好的，一上生产就崩；提示词换几个字，输出结果天差地别；模型更新一个版本，线上效果反而倒退。这些问题的根源，都不是"模型不够强"，而是缺少一套能把AI能力稳稳托住的工程体系。所以两年前我做了一个决定，把所有AI相关项目全部推倒，从零开始搭建一套属于自己的AI工程方法论，也就是今天标题里这个"ai-engineering-from-scratch"。

这套体系解决的不仅是"怎么把模型跑起来"的问题，更是"怎么让AI能力稳定、可控、可测、可迭代"的问题。它覆盖了数据准备、模型选型、提示词工程、Agent工作流、测试评估、部署运维这一整条链路。适合谁看？如果你只会调用现成的API，想往工程方向走；或者你在团队里负责AI应用落地，但总觉得哪里都不够扎实——这篇文章应该能帮你在脑子里树起一张完整的地图。

我先说一个真实的对比案例。之前有个项目组用开源模型做一个文档问答机器人，最初两周就做出了demo，演示效果非常好。但进入生产后，问题接踵而至：用户问一句超过上下文长度的话，系统直接报错；模型偶尔输出一段和文档无关的内容，没人发现；某天模型换了新版本，API参数变了，代码直接挂掉。整个团队连续加班三周才勉强稳定。而我的团队在另一个相似项目上，因为一开始就走"工程化"路线，整个过程几乎没有慌乱。差距不在模型调参的技术高低，而在是否提前把工程的关键环节想清楚了。

1.1 从"会调接口"到"懂工程"的差距

很多人觉得AI开发门槛低，因为现在的模型API确实"开箱即用"。调一个接口，传一段prompt，拿回一段输出，这跟调用普通HTTP服务没什么区别。但一旦你要求这个能力稳定服务于真实业务，问题就来了：怎么评估输出质量？怎么控制成本？怎么处理模型幻觉？怎么保证上线后可观测？怎么应对输入变化？这些问题是API文档里找不到答案的，也是"调接口"和"懂工程"的最大分水岭。

调接口的思维是"输入-输出"的线性视角：你给它什么，它给你什么，中间是黑盒。工程思维的视角则是"系统-环境-反馈"的三维视角：这个AI能力被嵌入在什么业务流程里？它的上游输入从哪来、质量如何？它的下游输出给谁用、出错了会有什么后果？它的运行环境是GPU服务器还是边缘设备？它上线后靠什么反馈机制持续改进？把这些问题想清楚，才算入门的AI工程。

我经常用一个比方：会调接口像是会踩油门，懂工程像是会开车。踩油门谁都会，但开车要懂路况、看后视镜、打方向盘、处理突发事故。AI工程要处理的"突发事故"，就是模型输出漂移、数据分布变化、反馈回路失效这类问题。

1.2 判断一个AI项目"工程化"程度的五个指标

在面试和内部评审时，我常用五个指标快速判断一个AI项目的成熟度，你也可以拿来评估自己正在做的项目。

第一是确定性。同样的输入，跑十次，输出分布是否稳定？自然语言模型的输出天然有随机性，工程化的目标不是消灭随机性，而是把可接受的变化范围定义清楚，超出范围必须有拦截机制。第二是可观测性。请求进来了、模型推理了、结果返回了，每一步有没有日志和监控指标？模型输出的核心指标（如置信度、偏好标签）有没有记录？出问题时能不能快速回溯？第三是可测试性。有没有一套离线评测集？每次改prompt、换模型、调参数，能不能在离线环境快速跑一遍回归测试？第四是可回滚性。模型升级后效果不好，能不能一键切回旧版本？提示词改动出了问题，有没有快捷恢复手段？第五是可维护性。代码和配置是否分离？换模型供应商时，代码改动量是改一行还是一百行？

如果你的项目在这五个指标上都有明确方案，工程化程度就算合格；如果只有一个demo跑通，那离"工程"还有很大距离。后面所有章节，我都围绕这五个维度展开。

2. 从零构建AI工程的三条主线

在做"ai-engineering-from-scratch"时，我发现很多资料都在讲某个具体工具或技术，但真正重要的是把工程体系拆成三条主线来思考：数据线、模型线、应用线。这三条线环环相扣，缺一不可。

2.1 数据线：从原始数据到评测集

数据是AI工程的地基，但也是最容易被低估的一环。我刚起步时犯过一个错误：拿到一批业务文档直接丢给模型做问答，以为模型"聪明"，会自动理解内容。结果模型答得驴唇不对马嘴——原因不是模型不行，而是文档格式混乱、关键信息被无关段落淹没、还有大量扫描件依赖OCR，数据完全没法用。

数据线的核心工作可以分成三层：第一是采集和清洗。明确数据来源，做格式统一、噪声过滤、敏感信息脱敏。第二是结构化整理。对非结构化文本做切分、标注、索引，这一步直接决定后续检索和问答的质量。第三是最容易被忽视的——评测集的构建。你需要从真实业务场景中抽取一批有代表性的输入-期望输出对，作为未来所有改动的回归测试基准。没有这套评测集，你后面每一步优化都是盲人摸象。

评测集怎么建？我推荐一个"三七原则"：30%来自真实线上日志中的典型问题，70%来自人工构造的边界情况。边界情况包括：超长输入、歧义问题、意图倒置、对抗性表述等。只有这种"真实+边界"的配比，才既能保住主线效果，又能暴露隐患。

2.2 模型线：选型、推理、迭代

模型线的核心不是训练一个大模型，而是根据业务场景做出正确的选型决策，并把模型的推理性能优化到可用水平。选型的核心考量包括效果、成本、延迟、可控性四维。

效果很好理解，就是实测指标。成本包括token费用和硬件成本。延迟直接决定用户体验。可控性则是数据隐私和模型权重的归属问题。实践中最常见的错误是"人人都在选最大模型"。我见过一个内部工具，处理的是标准结构化信息抽取任务，完全可以用7B的小模型加好的prompt搞定，但团队一开始选了70B大模型，推理成本高不说，延迟还大，后来换成小模型微调版本，效果没降、成本省了70%。

推理优化这块，量化是最立竿见影的手段。将模型从FP16量化到INT8，显存占用接近减半，推理速度通常能提升30%到80%，而效果损失在大多数任务里可以控制在1%到3%以内。具体怎么做，我会在后面的部署实战部分详细展开。

2.3 应用线：Prompt、Agent与业务集成

应用线是用户直接感知的部分，也是"ai-engineering-from-scratch"中最需要打磨的一层。它包含三个层级：最基础的是Prompt工程，核心是让模型稳定输出你想要的格式和内容；进阶是Agent工作流，让模型能调用工具、检索知识、自主决策；顶层是业务集成层，包括与现有系统的对接、权限控制、异常兜底等。

这三层的关系像是"输入法-助手-办公流程"：Prompt工程解决"怎么把想法变成准确指令"，Agent解决"怎么让系统帮我完成一系列动作"，业务集成解决"怎么把事情嵌入真实工作流"。很多项目死在第一层就以为自己在做Agent，这是认知上的错位。

三条主线里，如果你只能先做一条，我建议从数据线起步。因为后续的选型、Prompt优化、Agent设计，全都依赖高质量数据和评测集来驱动。没有数据线，其他两条线就是空中楼阁。

3. 提示词工程的工程化实践

提示词（Prompt）是这个时代被误解最深的技术之一。很多人把它当成"跟AI聊天的技巧"，但在我眼里，Prompt工程是一套严格遵循输入输出规范的工程实践。好的提示词，本质上是一段经过精心设计、版本管理、回归测试过的"模型端代码"。

3.1 提示词不是"聊天技巧"，而是"模型端代码"

把提示词当代码看，一切就清晰了。代码需要版本管理，提示词也需要。代码需要测试，提示词更需要。代码有注释，提示词也该有变更说明。我见过无数团队在共享文档里散落十几个版本的prompt，最后没人分得清线上跑的是哪个。而我自己的做法是，每个prompt模板都是独立文件，放在Git仓库里，和代码一起走评审、测试、发布流程。

具体操作上，我推荐两个细节。第一，提示词模板必须带变量占位符，例如用{{context}}和{{query}}标识动态内容，不要把用户输入直接拼进一大段固定文案里。第二，每个模板要有"预期输出规范"的说明，例如规定返回JSON格式并给出一个示例。这样模型输出更容易稳定，后续的解析和处理也不会因为格式飘忽而崩溃。

3.2 五个能直接套用的高复用提示词模式

这几年我沉淀了一套自己的提示词模式库，这里分享五个在工作里发生频率最高、直接能用的。

第一个是角色锚定模式。开头明确"你是一位资深的XX专家"，并给出一到两句该角色的职责边界。角色设定不是玄学，它能约束模型的语言风格和知识范围。第二个是步骤拆解模式。当任务复杂时，要求模型"先输出你的解题思路，再给出最终答案"。这个模式在数学推理、方案设计这类任务里特别有效，能让模型把思维链外显出来。第三个是格式约束模式。明确要求"只输出JSON格式，字段包括xxx，其中yyy字段取值只能是A或B"。注意，给出一个真实示例往往比描述规则更有用。第四个是少样本示例模式。给模型一两组"输入-理想输出"的示例，它能快速模仿出你想要的处理模式。实测下来，两个高质量示例的效果往往胜过一大段规则描述。第五个是自我校验模式。在prompt末尾要求模型"生成完成后，检查你的答案是否符合上述所有约束，如有违反请修正后重新输出"。这个模式能让模型的格式违规率降低一半以上。

3.3 提示词的评测与迭代闭环

提示词的优化最忌讳"凭感觉"。你改了几个字觉得输出顺眼了，就上线了——这跟赌博没区别。正确的迭代闭环是：先从评测集里随机抽50到100条，跑一次旧版本prompt，记录输出；然后修改prompt，再跑一遍同样数据；最后对比两版输出质量，决定是否切换。

对比的标准可以用人工，也可以用另一个强模型当裁判。但我建议至少在初期保留人工评审，因为模型裁判也有倾向性，可能和你的业务目标不一致。等你的评测标准完全固定下来，再考虑用模型自动化评审跑大样本。

我自己的团队每周固定做一次提示词回归测试，节假日还会额外抽查线上日志中的真实案例。这不是形式主义——AI模型的接口、上游数据、下游需求都在变，提示词如果不跟着迭代，效果只会慢慢钝化，而你可能毫无察觉。

注意：提示词不是一次写对就完事的工作，它是需要长期养护的"活代码"。线上模型升级后，第一时间跑一遍你的评测集，你往往会发现意料之外的输出变化。

4. 模型选型与本地部署实战

选模型和部署模型，是AI工程从"想法"走向"可用"的两个关键节点。这里分享我的实战做法和踩坑总结。

4.1 选型决策：先算账，再跑分，最后拍板

选型最忌讳拍脑袋。我总结了一套四步决策法。第一步，明确硬约束：隐私要求（数据能不能出域）、延迟预算（比如首字延迟低于500ms还是1s）、成本上限（单次调用的预算化到几分钱）。第二步，缩小候选池：按参数量级列出两到三个候选模型，不要超过三个，太多只会让评测成本失控。第三步，跑真实评测：用你的评测集，而不是公开benchmark，去实测候选模型的输出质量。这一步一般要预留两天时间，别指望半天搞定。第四步，综合打分：效果占50%，成本占20%，延迟占15%，可控性占15%，按自己的业务比重调整权重。

举个例子，我之前做一个客服工单分类产品。候选模型有闭源API和几个开源模型。闭源API的效果确实最好，但仔细一算，我们每天要处理几十万条工单，token成本一个月下来是个不小的数字；工单内容又包含大量客户隐私，走第三方API需要额外合规审批。权衡之下，我们选了一个支持私有化部署的中型开源模型，配合少样本prompt，效果拉回到闭源模型的95%，成本却降了一个数量级。

4.2 部署一条龙：量化、推理加速与服务化

本地部署开源模型，最常用的路径是这样的。以当前主流的7B到14B参数模型为例，用单张消费级显卡（如24G显存）就能跑起来。第一步是量化。用llama.cpp或AutoGPTQ这类工具，把模型从FP16量化到INT8或INT4精度。量化后模型文件变小，显存占用变低，推理速度提升。我在实际项目里，INT8量化在大多数业务场景下几乎没有可感知的质量损失。第二步是配置推理引擎。llama.cpp适合快速实验和CPU部署，vLLM则适合需要高并发吞吐的生产场景。你需要设置好上下文长度，同时把最大生成token数控制在一个合理范围，避免模型无限生成下去。第三步是封装成服务。用FastAPI包一层HTTP接口，把模型的输入输出规范化为JSON格式，便于上游业务调用。

部署中有个特别容易踩的坑：并发控制。很多人以为显存够大就能随便并发，结果某天流量稍大，模型直接OOM。稳妥的做法是在推理服务层设置一个信号量或队列，控制同时推理的请求数。我见过最简单的方案是在FastAPI里加一个asyncio.Semaphore(2)，仅此一行，就避免了大半OOM事故。

4.3 从单机到服务化的架构演进

单机部署跑通后，下一步就是服务化。这里要注意的不仅是性能，还有故障隔离和优雅降级。我的推荐架构是三段式：接入层（负责鉴权、限流、参数校验）、业务编排层（负责prompt组装、工具调用、结果后处理）、模型推理层（一个或多个模型服务实例）。三段式的好处是每一层都可以独立扩缩容、独立发布、独立降级。

举个例子，当模型服务出现异常时，接入层可以快速把流量切到备用模型或者直接返回预设兜底文案，而不是让整个链路崩溃。这些都是纯本地脚本完全不具备的工程能力。

5. AI Agent工作流落地

Agent是这两年最火热的概念之一，但真正把它落地到工程里，你会发现难点根本不在"能不能调用工具"，而在"怎么让多步行为可控、可观测、可兜底"。

5.1 从链式调用到Agent循环

很多人理解的Agent就是"模型调工具"，这其实只是第一步。真正的Agent是一个循环：模型理解用户目标，规划步骤，调用工具，观察执行结果，再根据结果决定下一步动作，直到完成目标或触发终止条件。这个循环可以用伪代码表示：

while not task_done: plan = model.generate_plan(goal, observation) action = model.select_action(plan) result = execute_action(action) observation = result if should_stop(observation): break

这个循环看起来简单，工程化的难点在于四个环节：规划的质量、动作的约束、结果的解析、终止的判断。规划阶段容易产生天马行空的步骤，所以你需要限定模型只能在预定义的工具集合里选择，不能自定义调用。动作执行阶段要记录完整日志，尤其是模型决策的依据。结果解析阶段可能会遇到工具返回错误或格式不符合预期，需要异常处理逻辑。终止判断是重中之重——没有设定好最大循环次数，Agent会陷入死循环，白白烧钱。

5.2 最小可用Agent的落地示范

我做一个最小可用的"文档数据分析Agent"来说明整体结构。它的任务是：用户提一个数据问题，Agent自动从数据库查询、做简单分析、给出答案。工具集合就两个：一个SQL查询工具，一个代码执行工具。整体逻辑是这样的：先由模型判断问题是否能拆解成可查询的SQL；如果可以，调SQL工具，拿到结果；如果SQL执行报错，模型根据错误信息修复SQL重试，最多重试两次；拿到数据后，如果还需要计算或可视化，就调用代码执行工具；最后汇总成自然语言答案返回。

这里面几个工程细节很关键。一是工具的输入输出完全schema化。SQL工具只接收字符串查询、返回表格格式结果，代码执行工具只接收Python代码、返回stdout。这样模型生成的动作才能被稳定解析。二是所有重试逻辑都在外围代码里限制死，而不是让模型"自由发挥"到满意为止。三是每一步都记录一条结构化日志，包含步骤序号、动作名、输入摘要、输出摘要，为后续调试留足依据。

5.3 多Agent协作的组织方式

多Agent协作听起来很酷，但工程上要先把单Agent跑稳，再考虑协同。常见的协作组织方式有三种：主管-下属模式、流水线模式、辩论模式。

主管-下属模式适合任务可以垂直拆分的场景，比如一个主管Agent负责任务拆解，把子任务交给专门的分析Agent和写作Agent。流水线模式适合处理固定流程，比如"检索->摘要->写作->校对"，每个节点由一个专职Agent完成。辩论模式适合需要多角度审视的决策场景，让两个Agent从不同立场输出观点，再由第三个Agent做裁决。

实践建议是：能用流水线就不用辩论，能用单Agent就不用多Agent。每多一个Agent，系统的不可控性就会指数增长。你要为每个Agent都配置独立的超时、重试、降级策略，否则任何一个Agent卡死都会拖垮全链路。

6. AI工程的测试、评估与运维

最后这部分，是最不性感但最救命的环节。AI工程能不能长期稳定运行，不看模型强不强，看的是测试、评估、运维做得到不到位。

6.1 离线评测集怎么建

评测集是AI项目最重要的资产之一。我的建议是，从项目第一天就开始积累，不要等上线了再回头补。评测集里的每条case应该包含四部分：输入、期望输出、评估要点、备注来源。评估要点可以是"答案必须包含A品牌名，且不出现B品牌名"这种可判定规则，也可以是"流畅度1-5分"这样的主观维度。

关于评测集规模，我建议梯度建设：起步50条，功能回归200条，全面评估500条以上。50条的时候可能只需要一个下午就能人工标完，但已经能拦住大部分明显退化。不追求一步到位，先跑起来最重要。

6.2 线上观测与回归机制

上线后的观测，我建议至少记录三类指标：业务指标（任务完成率、用户满意度）、系统指标（延迟、吞吐、成本）、模型指标（输出长度分布、拒绝率、格式合规率）。模型指标往往最容易被忽略，但它能最早暴露出模型行为漂移的征兆。

回归机制也很重要。我要求任何模型升级、prompt改动、工具逻辑调整，都必须先跑一遍离线评测集，再跑到一个单独的线上"影子环境"观察一段时间，最后才全量切换。这套流程在传统软件工程里叫"灰度发布"，在AI工程里同样适用。另外，每次改动都要留档，包括改了哪几个字、评测集得分是多少、线上效果如何。没有这些记录，你无法回答"为什么这个版本在线上的表现跌了"。

6.3 典型问题排查实录

分享几个我实际遇到的高频问题。

第一个是"模型突然开始重复输出同一句话"。排查思路：先看是不是推理参数里的temperature设太高或top_p设成了1，再看上下文是否过长、旧对话是否不断累积导致模型陷入重复循环。解决方案通常是给生成加了最大长度限制，并在对话打包时截断过旧的消息。第二个是"同一套prompt，线上效果比评测集差很多"。这多半是评测集和线上数据分布不一致。我那次排查发现，评测集里问题描述都很工整，而线上真实用户输入有大量口语、错别字和夹杂英文。后来我把评测集补上了杂乱输入，差距立刻缩小。第三个是"Agent调用工具时反复重试同一个错误动作"。这是典型的缺少错误反馈设计。后来我在工具结果回传时增加了结构化错误信息，并明确告诉模型"刚才那个动作因XX原因失败，请换一种方式"，问题就解决了。

7. 最后分享几个我常回看的细节

走过一遍"ai-engineering-from-scratch"之后，我越来越觉得，AI工程和传统软件工程的底层逻辑是相通的，只是多了一层"模型输出不确定性"的变量。应对这种不确定性，靠的不是玄学调参，而是扎实的评测、严格的可观测、完善的回滚机制。

我个人的经验是，不要急着追求复杂架构。先把一条最简单但完整的数据链路跑起来——一只好的样例数据文件、一段干净的prompt模板、一个能复现结果的推理脚本，就是一个扎实的起点。有了这个起点，后面所有优化都能在评测集和线上观测的指导下稳步推进。如果看到哪段链路不通，先问自己：是数据的问题、是模型的问题，还是工程链路的问题？绝大多数情况下，答案都不是"换一个更大模型"那么粗暴。

最后再分享一个我至今沿用的习惯：每周抽一个小时做一次全链路的"混沌检查"。随机挑几条线上真实日志，手动跑一遍完整链路，查看每一步日志和输出，确认没有异常。这比看任何监控面板都更能暴露真实问题。希望这篇内容能帮你在自己的AI工程路上，少走几个我走过的弯路。