前阵子有个老同事找我，说想入门AI，但又不知道从哪下手。我问他手里有什么实际问题要解决，他说“暂时没有，就想先把 ai-engineering-from-scratch 这套东西搞明白”。这句话其实特别典型：想做AI工程的人，十有八九不是缺教程，而是缺一个“从零到一的工程化起点”。我后面陪他完整走了一遍，从需求定义、Prompt设计、Agent编排，到部署和测试，花了大概三周时间，跑通了一个真实的小项目。今天这篇就把这条路径完整拆开，讲讲哪些环节能省、哪些环节坚决不能省、哪些坑我踩完以后最想提前告诉你。
这篇内容不是算法科普，更不是让你先啃三个月数学再动手。它解决的核心问题是：当你想把一个AI能力真正放进自己的产品、脚本或工作流里，该怎么从一个模糊想法变成稳定可用的服务。适合三种人看：刚接触AI、想从零搭建第一个应用的开发者；团队里负责把大模型能力落地的工程师；以及那些被“AI什么都行”搞得无从下手、想做点实际东西的产品和项目负责人。
1. 先想清楚：从零做AI工程到底在做什么
1.1 先分清“炼丹”和“做工程”
市面上很多AI内容讲的是“炼丹”：训练模型、调参、看loss曲线。但绝大多数业务场景根本轮不到你训练模型，你面对的是已经能用的通用大模型，真正要解决的是怎么把它接入业务、控制输出、稳定运行。我把这个叫做“做工程”，它和炼丹是两种完全不同的技能树。
你可以这样理解：炼丹的目标是发现“火药”的配方，而工程的目标是把火药做成能稳定发射的“弹匣”，还要算清楚每次扣扳机消耗多少成本、卡壳了怎么恢复。AI工程的重点不是模型本身，而是模型周围那一圈东西：输入输出契约、数据管道、缓存、重试、校验、监控、权限控制。这些听着不性感，但恰恰是决定项目能不能落地的关键。
我见过太多人一上来就追求“我要做一个全自动Agent”，结果连“从一段文本里稳定抽出5个字段”这种基础任务都没做扎实。AI工程的第一步不是写Agent，是先把小任务做成标准化接口。你先能用高概率拿到正确输出，再谈自动化。
1.2 从零到一，我建议的六个步骤
如果让我给一个新人画路线图，我不会直接推荐框架，而是让TA按照这六个步骤走一遍：
- 定义输入输出：你的功能解决什么问题？输入是什么格式，输出是什么格式？比如“从项目描述里提取风险点”，输出就是风险列表。
- 收集最小样本：找20到50条真实数据，不要用自己编的假数据。这一步会被很多人跳过，但它是后面评估的地基。
- 用Prompt搭基线：不写工程代码，直接在对话界面里试，看模型大概能不能做到。
- 建立验证集：把20到50条样本分成开发集和测试集，用来判断改动是变好还是变坏。
- 工程化封装：把上面的流程写成服务，加上参数校验、缓存、日志和错误处理。
- 部署与监控：上线后持续收集真实请求，定期回放错误案例。
这个顺序需要严格遵守，尤其不要跳过第2步。你可能会问：为什么不让模型直接读用户真实请求，上线以后再慢慢优化？因为真实流量不可控，等发现质量问题时，你已经没有干净的样本来复现和修复了。先拿小样本跑通，成本低、迭代快，后面再扩大。
1.3 为什么“从零开始”最容易翻车
翻车原因通常集中在三个方面。第一是需求定义得太宽，比如“做一个智能问答助手”，到底回答什么领域的问题？覆盖哪些格式？不回答什么？全都没说清。第二是数据格式不统一，你让模型从合同里抽取甲方名称，结果有的合同是扫描PDF、有的是表格、有的缩写，模型再强也架不住输入乱。第三是效果评估缺失，全靠人肉眼感觉“好像行”，说不清哪里不行。
我自己踩得最重的坑，是对Agent期望过高。早期我以为只要把任务描述给模型，再给它几个工具，它就能自动完成复杂工作流。实际跑起来发现：模型会在不该调用工具的时候调用，会在循环里反复试错，会把中间错误当成最终结果。工程化之后我才明白，AI工程的核心不是“让模型更聪明”，而是“让系统的确定性更高”。你要把不确定性圈在一个可控范围内，让模型在边界内发挥，而不是让它自由发挥。
2. 核心工程环节：从Prompt到Agent的开发细节
2.1 Prompt Engineering不是写作文，是设计接口契约
很多人把Prompt工程理解成“把话说得更清楚”，没错，但工程化的Prompt不止是清楚，它是一份接口契约。所谓接口契约，就是模型输入输出的格式、约束、边界都必须明确，像函数签名一样可维护。
我常用的Prompt结构包含四部分：System设定角色和全局规则，User提供待处理内容和上下文，Few-shot给出输入输出示例，最后的Output Schema规定输出格式。举个例子，做一个简历字段抽取功能，System里写清楚“你是一个信息抽取助手，只输出JSON”，User里放简历文本和“请抽取姓名、工作年限、技能列表”，Few-shot放一组“看着像但和你业务相关”的示例，最后在代码里用JSON Schema校验输出。
这里有一个实操细节：如果业务允许，尽量把温度参数调低，我一般用0到0.3。温度越高，输出越随机，但结构化抽取任务完全不希望随机。只有在写文案、起名字这类创意任务里，我才会把温度调到0.7以上。另外，不要在同一轮Prompt里既让模型做抽取又让它做推理，比如“抽取字段，并判断风险等级”，功能越单一，越稳定。你把复杂任务拆成多个小Prompt，每个只干一件事，效果会好得多。
2.2 AI Agent：先别让它自主，先用状态机控制
Agent这个词现在很火，但工程化的Agent不是“模型自己随便跑”，而是一个受控循环：模型根据用户目标，决定调用哪个工具，工具返回结果，模型继续判断，直到得到最终答案。这个范式没错，错的是很多人在没有约束的情况下直接让循环裸奔。
我的建议是，第一版Agent不要做完全自主，改成状态机。把流程拆成固定节点：接收需求、调用检索工具、生成答案、校验答案、结束或重试。每一步都由代码控制，模型只负责节点内的决策，不负责跳转。你可以用简单的Python状态机实现，也可以用LangGraph这类编排框架，但核心思路一样：让模型在状态机内部行动，而不是让它控制全局流程。
代码层面，我习惯给每个工具做一个签名描述，包括参数名、类型、含义。比如给Agent一个“查询项目风险”的工具，就需要定义参数project_id、risk_type，还要告诉模型什么时候用、什么时候不用。同时加两个保险：最大调用步数，例如20步；超时时间，例如30秒。这样即使模型发疯，系统也能在指定步数内强制结束，不至于烧钱烧到天亮。
2.3 Harness Engineering：给模型套上“执行骨架”
Harness这个词在Agent圈里越来越常见，你可以把它理解成“执行骨架”。它的作用不是替代模型，而是在模型外面包一层系统性能力：工具注册、参数校验、错误捕获、结果缓存、权限控制。为什么需要它？因为大模型输出天然不稳定，模型会生成一个看似合理但格式错误的工具调用，或者把不存在的结果说得像真的一样。如果这些输出直接进入业务系统，轻则报错，重则产生错误账单。
我做的Harness一般包含这几个模块：工具注册表、参数校验器、执行器、结果校验器、重试器。工具注册表声明有哪些工具可用，每个工具对应一段真实执行的函数；参数校验器按JSON Schema检查模型生成的参数，不合格就直接拒绝并让模型重试；执行器真正调用工具；结果校验器检查返回是否符合预期类型；重试器控制次数和退避策略。
这里有一个容易忽略的安全点：工具权限一定要收敛。只给模型最小权限，比如检索类工具可以开放，写数据库、发消息、调支付这类操作，必须加“人工确认”节点。我看到过不止一次，模型被提示词注入后执行了不该执行的工具。Harness里加上权限白名单，比事后补救安全得多。
3. 工具链选型与AI工作流搭建
3.1 从零搭AI工程，先用最笨的工具跑通
很多新手在选型上耗费大量时间，今天看这个框架文档，明天看那个Agent平台，来回切换，项目却迟迟没进展。我的经验是：先别引入任何重框架，直接用Python脚本加模型API把主流程跑通。流程真的复杂了，再考虑LangChain、LangGraph、Dify这类工具。最笨的工具不代表最终方案，它只代表你用来验证“这条路是否可行”的最小成本路径。
我举一个实际场景：给客服工单做自动分类。我先用Python列表存了50条历史工单，每条标注好类别，然后把“用模型分类”的代码写成普通函数，循环跑一遍，打印错误案例。整个过程不涉及数据库、不涉及队列，只有输入输出和判断。两天后我确认准确率可以接受，才开始加存储、加接口、加前端页面。这样做最大的好处是，出问题时你能快速定位是模型问题还是工程问题，而不是被框架日志淹没。
3.2 多AI协作：把任务拆给不同角色
有些任务用一个大型Prompt就能完成，但会把上下文塞得太长，输出不稳定。这种情况下，我倾向于把任务拆成多个角色，让不同模型或同一个模型的不同会话分别负责，再把结果串联起来。多AI协作不是让一堆Agent自由聊天，而是像流水线一样，每个节点有明确输入输出，节点之间传数据不传废话。
举个例子，我做过一个“生成项目周报摘要”的工作流：第一个模型只负责从材料里提取关键事项，输出JSON；第二个模型拿到JSON后，只负责生成段落文字；第三个模型做审核，检查事实是否与原始材料一致。每个模型的任务都很窄，上下文也不会无限膨胀。接口就是JSON，谁都可以替换。这个思路叫“角色拆分”，它比塞一个超长Prompt更可控，也更省钱。
3.3 让AI配合工作流，而不是反过来
我见过最多的失败案例，是把AI当成流程的替代品，直接让模型做整个流程的“大脑”。实际上，成熟的做法是把AI嵌进现有工作流里，做一个增强组件。比如客服工单处理，先让规则引擎把简单问题自动回复，再让AI处理复杂情况，最后人工复核。AI只负责生成草稿，不负责最终决策。
你应该先把业务流程图拿笔写出来，标出哪些步骤适合AI，哪些步骤必须人工。适合AI的通常是重复性高、容错率相对高的环节；必须人工的是责任重、错误代价高的环节。我个人的实践法则是“AI做初稿，人做终审”。这样既保证了效率，也留住了兜底。如果你发现流程本身还是一团乱麻，别指望上AI能解决，先梳理流程，再谈智能化。
4. 模型部署、测试与上线避坑
4.1 模型部署的三个方案：API优先、自部署补充
从工程角度看，部署模型有三种主流方案：直接使用云厂商的模型API；自部署开源模型；二者混合。决策依据通常是成本、延迟、数据私密性和维护成本。
API方案适合快速验证和中小流量，不需要管GPU，按量付费，但单次调用成本会随着流量线性增长。自部署方案适合对数据私密性要求高、调用量大到API成本超过硬件成本、或需要定制模型能力的场景，但要处理显存、并发、模型权重、升级等问题。我通常建议先用API把产品跑通，等有稳定流量和成本模型后再考虑自部署。混合方案则是把高敏数据走私有模型，普通内容走API。
给你一个显存估算的经验：一个7B参数的中等模型，FP16精度下光权重就需要约14GB显存，再加上KV Cache和运行时开销，实际至少需要24GB的显卡才舒服；量化到INT4可以让权重降到约4GB，但你有额外部署和精度损失问题。具体选型要量力而行，不要一上来就搞70B，7B模型在很多任务上已经够用。
4.2 AI测试开发：把模型输出当被测对象
AI测试和传统测试最大的区别是：模型输出不是确定性的，你不能用“等于预期值”来断言。但这不代表没法测。我通常会给模型输出建立一套“质量基线”，然后用自动化手段回归。
具体做法是准备一组验证集，每条数据标注标准答案。跑完模型后，用规则校验输出格式，看JSON schema是否合法、必填字段是否缺失、枚举值是否越界。再把文本字段和标准答案做相似度或关键子串匹配。结构化的任务可以算准确率和字段级F1，生成类任务可以抽样让人工评分。我还会用“模型判官”方式：让一个更强的模型对输出按标准打分，但每隔一段时间抽样人工复核，防止判官模型自己跑偏。
这里要重点提醒：测试数据一定要来自真实场景，用真实工单、真实简历、真实对话，不要用你自己编造的整齐数据。模型在干干净净的输入上表现良好是假象，一到真实噪声数据就崩。把脏数据、错别字、缺失字段塞进测试集，才叫有效测试。
4.3 上线后的监控、灰度与负反馈闭环
上线并不是终点。模型升级、Prompt调整、用户输入变化都会影响效果，所以必须有监控和迭代机制。我会在日志里记录每次请求的输入、模型版本、Prompt版本、输出结果、耗时和Token消耗。这样出问题时可以回放，不用对着屏幕猜原因。
灰度尤其重要。模型提供商更新一个版本，哪怕宣称“能力增强”，都可能改变你的输出格式。不要看邮件公告就自动切流，先在测试集上跑一遍，再按5%、20%、100%的比例放量。上线后建立负反馈闭环：每周抽一部分badcase，分析是输入脏、规则缺失还是模型问题，修复后再跑回归。
这里给一个上线检查清单：是否记录Prompt版本？是否设置单次调用超时？是否对模型输出做了格式校验？是否有失败重试和降级方案？Token消耗是否设置了阈值告警？如果这些全是“否”，先别上线。
5. 常见问题与排查技巧实录
5.1 输出格式漂移、字段缺失怎么办
很多人在用模型抽取信息时遇到这种怪事：上周还好好的，这周突然缺字段，或者JSON后面多出一段解释。我先检查三件事：温度是不是被改高了；System Prompt里是否明确写了“只输出JSON，不要任何解释”；模型是否升级了。第一个问题最常见，很多人为了“让回答更自然”把温度调高，结果格式全乱。第二个问题是因为模型认为你需要解释，你要在Prompt里反复声明输出格式，最好的方式是开启模型的结构化输出或JSON Mode功能。
字段缺失还有一个常见原因：Few-shot示例太少或太特殊。我给模型提供的示例最好覆盖边界情况，比如空值、超长值、多值字段。如果模型仍然不稳定，就在代码里做兜底：解析JSON失败时自动重新请求一次，并带上错误信息。本质上是把“格式错误”当成一种预期内的异常，而不是偶然事件。
5.2 Token超限、上下文爆炸、成本失控
上下文超限是Agent项目里最常遇到的硬问题。根本原因是把历史对话、参考资料不停往Prompt里塞，Token只增不减。解法是给上下文瘦身：只保留最近N轮对话，更早的内容做摘要；参考资料用RAG检索后截取相关片段，不要全文塞入；设置最大输出Token数，防止模型长篇大论。
成本失控也是这些项目的高发问题。我习惯在每次调用前估算Token：假设系统Prompt和示例占1000Token，用户输入平均500Token，输出平均300Token，那么一次调用就是1800Token。如果一天一万次调用，就是1800万Token。价格乘以单价，数字很直观。所以我对每个接口做了每日Token预算告警，某类任务一旦超预算，立刻排查是不是出现了Agent死循环或用户恶意灌长文。
5.3 幻觉与事实错误：兜底而不是根治
大模型的幻觉不可能靠一句话根治，工程上要做的是兜底和减害。做知识类应用时，我一定用检索增强：先检索知识库中的相关片段，再把片段附在Prompt里，并要求模型在回答中标明依据来源。如果模型说“根据文档”，而文档里根本没有这句话，就用规则或二次模型校验来判断一致性，不一致就拒绝输出。
另一个技巧是允许模型“不知道”。在Prompt里明确写“如果没有足够信息，直接回答‘无法从现有资料中确定’，不要推测”。很多人觉得这样不智能，但实际业务里，一个诚实的“不知道”远比一本正经的错误答案安全。关键流程还要加人工复核节点，让模型生成的最终结论只能作为参考，而不是自动生效。你要接受一个事实：AI工程的目标不是消灭错误，而是把错误控制在可观测、可回滚、可拦截的范围内。
我个人跑完这套从零到一的项目后，最深的体会是：不要一开始追求全自动，先做一个有人参与、但效率明显提升的半自动流程，稳定以后再慢慢扩大自动化范围。每隔一段时间，我都会回去重看自己的老项目，最满意的不是用了多新的模型，而是把那些细碎的错误一点点收进了框架里。最后分享一个小技巧：给每一个Prompt都加上版本号和变更记录，比如v1.2修正输出字段，v1.3增加空值处理。这样模型升级后行为变化时，你能迅速定位是Prompt的问题还是模型的问题，而不是在混乱中反复重试。