企业官网建设流程全解析

“ai-engineering-from-scratch”这个话题，我琢磨了很久才敢动笔。半年前我开始带着团队做AI应用落地，最大的感触不是模型能力不够，而是身边大多数人连“AI工程”这三个字到底意味着什么都没想清楚。很多人以为AI工程就是会调接口、会写Prompt，可真把一个AI功能做成能上线、能维护、能兜底的产品系统，中间隔着的是提示词协议设计、上下文管理、工具调用链路、评估体系、资源成本控制这一整套工程方法。这篇东西就是我从零开始搭建AI工程能力的一份实践总结，不聊玄乎的架构，只讲我真实踩过的坑、验证过的方法，以及可以直接抄走的路径。

1. 为什么我会把“从零开始”当成AI工程的第一课

1.1 会用AI和能交付AI系统，是两种完全不同的能力

我面试过不少候选人，简历上写着“熟练使用ChatGPT、熟悉Prompt Engineering”，可一聊到实际落地就露馅了。你问他：如果模型返回的JSON字段偶尔缺失，你的下游逻辑怎么处理？如果同一套Prompt在用户换了一种说法之后就答非所问，你的系统靠什么兜底？大多数人的反应是愣住——因为他们只把AI当成一个“问答工具”在用，没把它当成一个“有概率输出的运行时组件”来设计。

这恰恰是我想说的第一件事：会用AI，和能交付AI系统，是两种完全不同的能力。前者是消费者视角，后者是工程视角。工程视角的核心，就是默认模型会犯错、会不稳定、会超时、会胡说八道，然后围绕这些不确定性设计一套可控的流程。举个例子，我让AI从一段客服对话里提取用户意图和情绪标签，如果只是调API把结果打印出来，那是Demo；但我会把输出强制约束成JSON Schema，加一层解析失败兜底，再对关键字段做枚举校验，命不中就走人工复核队列——这才叫交付。从零开始学AI工程，第一步不是学某个框架，而是先扭转这个认知。

1.2 工程化的本质，是让不确定性变得可管理

我经常用一个比喻：写传统代码，你在和确定性的逻辑打交道；做AI工程，你在和一群“能力很强但偶尔抽风”的实习生协作。你怎么管理一个能力很强的实习生？不能只丢给他一句话任务，要给他标准作业流程，他交上来的活你要复核，重要的环节你要留出人工确认位，他一旦跑偏你要能随时叫停。Prompt Engineering、结构化输出、模型评估、人工审核回流——本质上都是这套管理手段。

工程化的目标从来不是让AI永远不犯错，这不现实。目标是：让AI犯错的方式可控、可发现、可修复。我在设计AI功能时通常会问自己三个问题：这个环节如果AI答错了，会造成多大损失？有没有办法在AI输出之后、影响用户之前拦截错误？模型能力不够的时候，我能不能靠流程设计来补位？只要这三个问题有答案，哪怕模型本身不是最顶级的，系统整体依然是可靠的。反之，就算把模型换成最新的旗舰版，没有工程封装，照样会在线上出事故。

2. 从零起步的三块核心拼图：提示词、上下文、工具调用

2.1 Prompt不是写话术，是在定义输入协议

很多人把Prompt Engineering理解为“把话问得更清楚一些”，这是被各种网文带偏了。我在实际工作中最深的体会是：Prompt不是聊天话术，它是你定义给模型的“输入协议”和“输出契约”。一份合格的生产级Prompt，至少要包含角色边界、任务目标、输入变量说明、约束条件、输出格式、失败时的兜底指令，还要配一两个示例（few-shot）让模型理解你的期望粒度。

我写Prompt有一个习惯：先写“输出格式”再写“任务描述”。因为对模型来说，输出格式就是最强的约束指令。比如我做客服工单分类，Prompt里会这样写：

system_prompt = """ 你是一个工单分类引擎。你的任务是判断用户诉求属于哪个类别。 可选的类别（严格限定在本列表内）： - refund: 退款/费用异议 - shipping: 物流/配送问题 - product: 商品质量/使用问题 - account: 账号/权限问题 - other: 无法归入以上类别 输出要求： - 只输出一个JSON对象，不要输出任何解释文字。 - 字段格式：{"category": "<类别英文名>", "confidence": 0.0-1.0, "reason": "<不超过20字的原因>"} 规则： - 如果信息不足，category填"other"，confidence不得超过0.6。 - reason必须来自用户原话，不允许发挥。 """

这个格式你可以直接拿去改成自己的场景。它的核心价值是：把模型输出变成了可程序校验的数据。confidence低的情况走人工，字段不在枚举内的情况直接告警，reason必须来自原话防止模型“脑补”。我见过太多线上翻车案例，根因全是Prompt里没写输出契约，下游程序拿到的是一堆自由文本，解析逻辑天天崩。

2.2 RAG和上下文管理，别一上来就堆向量库

上下文管理是AI工程里最容易被低估的模块。我见过有团队一上来就搞向量库、搞RAG，结果效果还不如直接把知识库全文拼在Prompt里丢给模型。为什么？因为他们的问答场景文档量就几万字，塞进上下文完全没问题，做了RAG反而因为切片检索不准把关键信息弄丢了。

我的经验是：先搞清楚你的上下文到底有多大，再决定要不要上RAG。上下文管理有一个基本优先级：

• 文档总量小于上下文窗口的50%，直接全文注入，最简单也最稳定；
• 文档量中等，先做“分层摘要+关键段落动态拼装”，用规则或小模型做初筛；
• 文档量很大或需要跨文档推理，才轮到向量检索，而且必须配合rerank（重排）和召回评估。

即便真要做RAG，也不要迷信“切块越细越精确”。我在项目里吃过亏，按固定512字符切块，把一段完整的技术说明拦腰切断，语义丢失，检索出来的片段全是残句。后来改成按标题、段落边界做结构切分，再给每个片段生成摘要并存metadata，召回质量明显提升。这里分享一个实用思路：检索召回之后，一定要加一步“相关性判断”——把召回的片段连同用户问题一起交给模型，先让模型判断“这段内容是否真的能回答这个问题”，不相关就丢弃。很多人只做召回不做判断，结果检索系统把完全无关的内容拼进Prompt，模型一本正经地胡编，反而比不带上下文更差。

2.3 工具调用是Agent的“手脚”，也是最大的不可控源

所谓AI Agent，我理解并不神秘：就是让模型在对话循环中拥有“工具调用”的能力——它分析用户意图后，决定去调用哪个函数、传什么参数，拿到工具返回结果后再组织回答。这里有一个工程上的坑：工具调用给了模型“行动力”，也给了它“闯祸空间”。一个只有对话能力的模型，说错话顶多被吐槽；一个有工具调用能力的模型，一旦解析参数错误、调用顺序混乱、循环不终止，可能真的会去给用户发消息、下单、改数据库。

所以我的建议是：新手做Agent，一定要先把“工具权限”做小。工具函数的设计原则是：宁可增加一个确认步骤，也不给模型一杆子捅到底的权限。比如模型想调用“发送邮件”工具，那就先走一个“生成邮件草稿并返回给用户确认”的工具，用户点了确认才真正触发发送。这个中间层只有几行代码，但能把事故率降一个数量级。工具调用的入参也一定要做Schema校验，模型给的参数哪怕有一丁点不符合类型、超出枚举范围，都不要直接塞给函数。我在内部的Agent框架里规定：模型调用工具返回的参数，先过一遍Pydantic校验，不过就重新要求模型修正，最多重试两次，还不行就放弃本次调用并转人工。

3. 一条可复制的AI工程实操路径

3.1 第一步：在不动架构的前提下跑通最小验证

很多团队做AI项目，上来就画架构图：向量数据库、Agent编排、消息队列、微服务……画得天花乱坠，结果连“用户的核心问题模型能不能答好”都没验证过。我的习惯是反着来：先用最土的方式把一个最小闭环跑通。所谓最小闭环，就是拿一个简单的Python脚本，读一条用户问题，拼一个写死的Prompt，调一次模型，打印出结果，人工看一眼对不对。这一步的价值不是演示，是快速回答一个致命问题：当前模型在真实输入上的基线表现，到底能不能打。

我会把这一步当成一次正式的测评来做：准备20到30条覆盖典型场景的用户输入，用最朴素的Prompt跑一遍，记录每一条的输出质量，分三档——可以直接用、需要后处理才能用、完全不能用。如果“完全不能用”的比例超过30%，别急着调Prompt，大概率是任务本身超出了模型当前能力，要么换更强的模型，要么把任务拆小。如果大部分结果“需要后处理才能用”，恭喜你，这恰恰是工程可以发挥作用的空间：设计解析规则、补全逻辑、格式修正，把可用率从60%拉到95%，这就是AI工程师真正的价值。

3.2 第二步：用Schema把输出变成可校验的数据

当我确认模型在自由文本输出上“基本能用”之后，下一个动作永远是加上结构化约束。现在的模型API基本都支持response_format或者工具调用式结构输出，我强烈建议生产环境全部启用。

我之前做一个文档信息抽取功能，第一版让模型自由输出，结果同一份合同，模型有时候输出“甲方：XXX公司”，有时候输出“甲方是XXX公司”，解析脚本写了一个星期，天天被字段格式变化折磨。后来切换到类似structured_output的方式，直接定义好数据模型，让模型返回JSON，再配合Pydantic做运行时校验，问题直接消失。你不需要在意用的是什么SDK，核心思路是一致的：

from pydantic import BaseModel from enum import Enum class PartyRole(str, Enum): party_a = "甲方" party_b = "乙方" guarantor = "担保方" class ContractEntity(BaseModel): role: PartyRole company_name: str unified_social_code: str | None = None sign_date: str | None = None # 模型输出先校验，校验失败就重新抽取一次 result = ContractEntity.model_validate(json.loads(raw_output))

这样做的另一个好处是：结构化字段天然形成了后续业务的接入点。你可以直接拿字段去做匹配、入库、触发流程，而不是再写一堆正则去猜模型在讲什么。

3.3 第三步：用工作流把多个AI步骤串成闭环

单个模型调用稳定之后，就要考虑组合多个AI步骤，甚至让Agent在步骤之间做决策。我做的很多业务其实不是“一个大Prompt解决所有问题”，而是拆成几个小步骤，每个步骤由一个专门的模型调用完成，每一步的输出校验通过后才进入下一步。

举个实际例子，我做一个“智能售后处理流”：第一步，检测用户情绪等级，如果情绪分高于阈值，先走安抚话术再进入正式处理；第二步，从对话里抽取订单号、问题类型；第三步，查库存和售后政策，把结果组装进答复模板；第四步，让模型根据模板生成个性化答复。这四个步骤如果用一个大Prompt做，一方面上下文互相干扰，另一方面单点出错很难定位。拆开之后，每一步都能单独评估、单独降级。比如第二步抽取失败，就直接转人工，而不是硬着头皮生成答复。

工作流编排上有两个我踩过的坑，提醒大家注意。第一，步骤之间传递数据要“显式传参、显式校验”，不要指望模型在上文里记住；第二，不是每一步都必须用大模型，能用代码规则完成的步骤，比如查库存、拼模板，就用代码写死，大模型只做它擅长的语义理解和生成。这样既省钱又稳定。

3.4 第四步：按真实场景建评估集，持续迭代

AI工程和传统软件工程最大的区别之一，就是它没有一个“编译通过就完成任务”的验收线。模型换了版本、Prompt改了几个字、用户的说话方式变了一种，线上表现都可能波动。所以从项目第一天起，就应该维护一份评估集。

我的评估集分三层：第一层是“回归集”，选50到100条典型输入，每次改Prompt或换模型都要全量跑一遍，确保质量不倒退；第二层是“边界集”，收录那些容易让模型翻车的输入，比如用户故意分叉话题的专业表达、之前线上出过错的问题；第三层是“线上回流集”，定期从真实日志里采一些新问题加进去，持续补充覆盖度。

跑评估集的时候，光看“答没答对”不够，还要按场景分维度打分。我常用的维度包括：信息完整度、格式合规率、幻觉率（模型答了原文里没有的信息）、拒绝率（模型什么都不答的比例）。这些分数是驱动迭代的，没有数据就没有方向。我见过太多团队调整Prompt全凭感觉，今天加一句话觉得好，明天反过来又删了，折腾一个月原地踏步。有评估集之后，哪怕效果暂时变差，也能立刻知道问题出现在哪个维度、哪一批case上。

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

4.1 判断是否需要本地部署的三个问题

“本地部署AI”是一个听起来很酷但经常被误解的需求。我先泼一盆冷水：如果你只是觉得本地部署“安全、可控、免费”，建议先冷静三分钟。本地部署真实要付出的代价包括显卡采购、显存规划、推理性能调优、模型更新维护，以及最容易被忽略的——同级别效果的开源模型和商业API之间，存在肉眼可见的效果差距。

我在决定要不要本地部署时，只问三个问题。第一，数据是不是真的不能在网络环境下处理？比如企业内部合同、隐私性的医疗数据，这类场景没得选，必须本地。第二，稳定性要求是不是高到不能依赖外部服务？比如产线控制、离线环境。第三，成本模型是否划算？如果日请求量不大，买一张昂贵显卡的摊销成本远超按次数付费的API账单。三个问题都是否，那本地部署就是给自己找麻烦。

只要有一个答案是肯定的，再考虑本地。选型上我的建议也简单直接：先从同级别开源模型里选经过社区验证的中等规模版本，不要一上来就追最大参数量。对大多数业务场景，推理速度和部署成本比那一点质量提升重要得多。

4.2 资源估算、量化方式与并发调优

本地部署最核心的数学题是显存。我之前被问得最多的问题就是“我这台机器能跑多大的模型”，学生党以为8G显存能跑70B模型，这是不可能的。你至少得知道一个估算公式：模型显存占用，粗略按参数量乘以每参数字节数算。FP16精度下，每个参数占2字节，所以7B模型大约需要14GB显存，再加上KV Cache和推理中间态开销，实际要预留20GB以上。想用8G显存跑则只能走4-bit量化，一个7B模型量化后大约4GB上下，勉强能塞进去，但生成质量和速度都会有损失。

另外我要特意强调：显存够不够，不仅看模型权重，还要看并发。如果同时有4个用户请求，每个请求的上下文都很长，KV Cache会成倍吃掉显存。我的实测经验是，长上下文场景下，KV Cache比模型权重还吃显存，这是大家最容易算漏的一项。建议先用单路请求做基准测试，测出显存占用，再按“总显存预留30%”的余量倒推并发上限。推理引擎方面，目前主流选择已经比较成熟，优先用带优化和量化支持的推理服务框架，业务还没到瓶颈前，我不建议在自研推理引擎上浪费时间。

4.3 多模型混合编排与降级兜底

本地部署真正发挥威力，是在“多模型混合编排”的架构里。我喜欢的做法是：把不同难度、不同敏感度的任务分到不同模型上。比如简单的意图分类和内容提炼，用本地小模型处理，响应快且不需要把数据传到外部；需要高质量生成的最终答复，再调用更大的模型；敏感任务永远走本地链路。

这个混合架构必须配一套降级策略。我在生产线上是这样设计的：本地模型请求超过2秒没返回，自动切换外部API；外部API连续出错三次，熔断并切回本地；两边都不行的时候，返回一个编辑好的兜底文案，然后进人工队列。这层逻辑用代码写也就几十行，但有没有这层逻辑，决定了你的AI服务是“偶尔不可用的Demo”还是“可以长期值守的生产系统”。所有依赖大模型的功能都应该默认假设它会故障，没有降级方案的AI功能，上线就是埋雷。

5. AI工程线上问题排查与经验沉淀

5.1 输出质量波动，先查这几处

线上AI系统最常见的问题是“昨天还好好的，今天突然变笨了”。这种事别慌，跟着清单查就行。我的排查顺序是：先看模型版本有没有被平台悄悄更新；再看网络链路和重试逻辑，超时重试导致的语言模型重复输出经常被误判为质量问题；然后查Prompt里的动态部分，很多Prompt会拼当前时间、用户输入原文，这些变量一旦带了脏数据，输出质量立刻下滑；最后才是评估集跑分，确认是普遍退化还是个别case。

我对团队的硬性要求是：每个线上请求都要全链路留日志——原始Prompt、模型原始输出、后处理结果、用户反馈链路，缺一不可。没有日志，质量波动就只能靠猜。我见过最典型的案例：一次线上效果大跌，排查半天，最后发现是某个上游系统把用户昵称拼接进了Prompt，昵称里包含一段恶意文本把模型带偏了。这种问题，不抓日志根本无从查起。

5.2 Agent工具调用失控，排查思路和应急开关

Agent系统因为引入工具调用，故障模式比纯对话系统多一截，我把常见的失控情况整理成了一张速查表：

最重要的不是事后排查，而是事前给你的Agent装一个“急停开关”。我的做法是：所有工具在执行实际副作用（发消息、改数据、扣款）之前，必须经过一个统一的审批接口。这个接口在联调阶段直接模拟放行，上线初期则切到人工确认，等积累了足够多的可信样本再逐步放开。这个思路虽说保守，但能省掉无数次事故善后工作。

5.3 成本、延迟和安全边界，上线前必须设置护栏

很多从零开始做AI工程的人，第一步就栽在成本上。大模型调用是按Token计费的，Token单价看着不高，但乘上反复重试、长上下文、并发增长，月底账单会非常吓人。我见过一个团队做内部知识问答，每条用户问题都要把整本手册塞进Prompt，单次成本高得离谱。后来加了缓存层，把用户问题做语义相似度匹配，命中就直接返回历史答案，成本直接降到原来的十分之一。

除了成本护栏，还有两个边界必须设置。一个是输入侧的内容边界，你的系统接的是什么形态的输入、允许处理什么类别的信息、不允许碰什么，都要在入口就拦截，而不是等模型生成之后再补救。另一个是输出侧的行为边界，哪些话不能说、哪些操作不能触发，要在Prompt和工具权限两层同时约束。安全这件事在AI系统里不是附加项，是架构的一部分。毕竟模型不是你团队的人，它没有“常识”，你不给它焊死护栏，它就能在各种边界上来回试探。

我个人在实际操作中的体会是：做AI工程，最大的倚仗往往不是最新最强的模型，而是一整套关于输入、输出、工具、评估的纪律。模型能力可以靠换版本快速提升，但工程纪律只能靠在真实场景里一次次踩坑来积累。从零开始不是指你得先弄懂所有底层原理，而是指你要愿意从一个最小闭环出发，不断给系统加约束、加校验、加兜底。这套方法虽然不性感，却是我见过能真正把AI用稳、用久、用出价值的唯一路径。如果你现在正要启动一个AI项目，别急着画大架构，先拿一条真实数据跑通最小闭环，再用工程手段把它焊成铁桶——这条路我替你走过，确实走得通。