企业官网建设流程全解析

做AI应用开发这几年，我最大的感受是：让模型跑通一个demo确实不难，难的是把一个 demo 变成稳定的、可交付的、真正能用的系统。很多团队在立项时最纠结“选哪个模型”，但真正上线后被反复折磨的，往往是数据格式、输出解析、评估标准、监控告警这些听着不太性感、做起来全是细节的工程问题。吴恩达近两年反复强调一个方向——AI工程技能驱动构建。他的意思很明确：大模型本身的差距在缩小，真正决定AI项目能走多远、能落地多实的，是团队的工程能力。

这篇文章我就围绕“AI工程技能驱动构建”这句话，把我在实际项目里用到的思路、方法和踩过的坑整理出来。内容不局限于某一种模型或框架，重点是讲清楚一件事：AI应用从原型到生产，到底需要哪些工程技能，每项技能在项目里解决什么问题，以及如何一步步把“模型能跑”变成“系统能用”。适合正在做AI产品、AI应用开发、或准备把大模型接入业务系统的工程师和产品经理，也适合想系统理解AI工程化路径的初学者。

1. 先认清一个事实：模型不是项目成败的唯一变量

很多人会本能地把AI项目的成败押在模型身上。模型强，项目就成了一半；模型弱，再好的工程也白搭。这个说法在demo阶段成立，但在生产环境里并不成立。我见过不少项目，明明用了当时最强的模型，上线后依然问题不断：答案时对时错、接口偶尔超时、同样的Prompt在不同时段输出格式不一致、用户反馈的问题无法回溯。这些问题没有一个是“换更强的模型”能解决的，它们全部落在工程侧。

吴恩达所说的“AI工程技能驱动构建”，本质上是在提醒行业回到工程本位。他多次强调的是从“以模型为中心”转向“以数据为中心”，以及在提示词、检索、Agent、评估这些环节里系统化投入。翻译成我自己的理解就是：模型是发动机，工程是底盘、悬挂、刹车和仪表盘。发动机再好，没有底盘和刹车，长途跑不了一百公里；发动机差一点，但底盘扎实、反馈及时、维护到位，反而能稳稳当当跑完整个运输流程。

1.1 算法能力之外的工程瓶颈

我拆过几个从原型到生产的AI项目，发现卡点几乎都集中在几个固定位置。

第一是数据。模型要的数据和业务系统给的数据，经常对不上。有的是字段缺失，有的是格式混乱，有的是编码问题。一个知识库问答系统，文档里有PDF、Word、Markdown，图片里嵌着表格，表格里还有嵌套表格，光是把这些内容洗干净、切好、存进向量库，就占掉了整个项目三分之一的时间。

第二是指标。线下测试时模型表现不错，一上线用户反馈却完全不是一回事。原因很简单，线下用的测试样本和线上真实流量分布不一致。没有一套能代表真实场景的评估集，你根本不知道改了一次Prompt之后，模型到底是变好了还是变差了。

第三是链路。AI应用很少是单次调用就能完成的，尤其是Agent类应用，要经过多轮工具调用、状态维护、结果校验。任何一环出现异常，整个交互就崩了。但很多团队在原型阶段根本不会考虑这些，等上线了才被各种异常打懵。

第四是迭代。传统软件有明确的版本管理和回归测试，AI应用的输出是概率性的，每次改动都可能引发不可预期的行为漂移。没有回归机制，就没有人敢动线上Prompt和模型版本，项目越往后越僵化。

1.2 从“以模型为中心”到“以数据为中心”

吴恩达提出的“以数据为中心”的AI理念，在工程实践里非常实用。核心思想是：与其反复换模型，不如系统化地改进数据质量。这个“数据”不只是训练数据，还包括评估数据、检索数据、用户反馈数据和Prompt示例数据。

具体到项目里，我通常会做三件事。第一，建立一份高质量评估集，覆盖业务里的典型问题、边界情况和容易出错的案例，所有模型和Prompt改动都在这份数据集上打分。第二，把线上收集到的badcase持续回流进评估集，保证评估集随业务变化而更新。第三，对输入数据做严格清洗和规范，确保模型在干净、一致的输入上工作，而不是被迫应对各种脏数据。

这里有个容易被忽视的点：模型参数量再大，也扛不住系统性地给它喂垃圾输入。你把一份排版混乱、内容矛盾的材料丢给它，再强的模型也会给出混乱的答案。数据质量决定了模型能力的上限，这句话放在AI工程里丝毫不夸张。

1.3 AI工程技能包含什么

结合实际项目来看，AI工程技能至少由五块组成：

• 数据工程：数据采集、清洗、转换、分块、向量化、质量管理，是AI应用的原料车间。
• 提示词工程：任务描述、上下文编排、输出约束、示例设计，是让模型稳定输出预期结果的关键。
• 评估工程：评估集构建、评估指标设计、回归测试、badcase回收，是AI应用的质量防线。
• Agent工程：工具调用、任务规划、状态管理、容错恢复，是复杂AI应用的骨架。
• 平台工程：服务封装、部署、监控、告警、版本管理和成本控制，是AI应用长期稳定运行的底座。

这五块不是独立的，而是层层递进的关系。数据工程做不好，提示词再精妙也白搭；评估工程缺位，提示词工程就变成玄学；Agent工程不完善，功能越丰富系统越脆弱；平台工程缺失，前面所有的工作都无法在线上持续运行。吴恩达强调“AI工程技能驱动构建”，我的理解正是要把这五块能力当成和模型选择同等重要的系统工作来投入。

2. AI工程体系的核心拆解：从提示词到Agent

工程技能听起来抽象，落到项目里其实是几个非常具体的模块。下面我把实践中反复用到的几个核心环节逐一拆开讲，重点说清楚每个环节解决什么问题、有哪些关键点、怎么做才靠谱。

2.1 Prompt工程为什么只是起点

很多刚接触大模型的人以为，Prompt就是“把需求用大白话问出来”。真做工程化之后你会发现，Prompt是一套结构化的任务描述，目的不是“让模型听懂”，而是“让模型稳定、可预期地完成任务”。

我在项目里通常会按四个层次来设计Prompt。第一层是角色与目标，明确模型在这个任务里扮演什么角色、要完成什么目标，比如“你是售后客服助手，你的任务是基于客户手册回答售后问题”。第二层是任务规则，把约束条件写清楚，比如“只基于提供的资料回答，不编造信息”“如果资料中没有答案，直接回复‘资料未覆盖’”。第三层是输出格式，用JSON Schema或示例明确要求输出结构，方便程序解析。第四层是few-shot示例，给2到3个输入输出对，帮助模型理解预期风格和粒度。

实际项目里最常见的Prompt问题是“规则太多，模型记不住”。模型对提示词中不同位置的指令遵从度不一样，一般来说开头和结尾的指令效果最强，中间大段规则容易被稀释。所以我通常把最关键的限制条件放在开头和结尾，中间部分放补充说明和示例。

做一个稳定可用的AI应用，Prompt工程是起点，但它也只是起点。真正决定系统上限的，是围绕Prompt构建起来的评估和兜底机制。

2.2 检索增强生成（RAG）的工程化要点

RAG是目前落地最广的AI应用模式，流程看着简单：文档切块、向量化、检索、拼Prompt、生成答案。但每个环节都有不少坑，我把实践中踩过的关键点列出来。

文档切分是第一个坑。很多人按固定字符数切块，比如每500字一块，结果语义被切得七零八落。我现在的做法是优先按文档结构切分，一个章节、一个标题块、一个完整表格作为基本单位；如果结构不清晰，再结合段落语义切分。切完之后还要保留标题、章节路径、来源页码等元信息，后续检索时可以用元信息做过滤和引用溯源。

向量检索是第二个坑。只依赖向量相似度召回，经常出现“字面不匹配但语义相关”或者“语义相关但业务上不该出现”的情况。我的做法是混合检索：关键词匹配和向量检索并行，再用重排模型对候选结果重新打分。关键词保证精确匹配的硬召回，向量保证语义泛化的软召回，重排保证最终进入Prompt的是最相关的内容。

上下文组装是第三个坑。同样一段资料，直接拼接进Prompt和经过摘要压缩后拼进Prompt，效果差别很大。模型很难从大段无关文字里精准提取目标信息，所以我会在组装前做一步过滤，只保留与用户问题最相关的段落，并给每个段落附上来源标记，让模型在回答时引用对应来源。

举一个实际案例。我之前做过一个运维知识库问答系统，原始材料是几百页的故障处理手册。第一版直接按500字固定切块，用户问“服务器CPU飙升怎么办”，系统召回的内容经常横跨多个无关章节，答案五花八门。改成按故障类型分类、每个故障单独成块并保留“适用场景”元数据之后，召回准确率明显提升，答案也稳定多了。这个优化不涉及任何模型调整，纯粹是工程侧的数据处理和检索策略改出来的效果。

2.3 Agent化应用：链路、工具与状态管理

Agent类应用是现在AI工程里最热的方向，也是难度跳跃最大的领域。一个Agent系统里包含规划、工具调用、记忆、反思、多轮交互等模块，任何一个模块设计不当，整个系统就会表现出“不稳定”“失控”或“死循环”。

我搭建Agent应用时，会先把链路画清楚：用户输入进来，Agent判断要不要调用工具，工具返回结果，Agent综合判断是继续执行还是输出最终回答。这个链路里最关键的是工具调用协议。工具描述要写清楚参数、返回值和边界条件；工具调用的输出要结构化，Agent才能稳定判断下一步动作；最关键的是对工具结果做校验，不能模型说“调用成功”就当成功，要以工具实际返回为准。

状态管理是Agent应用的另一个大坑。多轮对话里，Agent要记住用户的目标、已经执行过哪些操作、哪些信息还不确定。我的做法是把状态分为两类：短期状态放上下文里，长期状态存到外部存储。每次工具调用结束后，把关键状态更新到上下文或存储里，避免Agent在长链路中“失忆”。

容错设计也不能少。我习惯给Agent设置最大步数限制，比如最多调用5次工具；每次工具调用加超时和重试；一旦检测到Agent连续重复调用同一个工具，就触发人工接管或向用户说明“当前无法完成该操作”。这些措施单看都很朴素，但组合在一起，能拦住Agent大量失控场景。

2.4 评估集与回归测试：让AI输出可度量

没有评估，就没有AI工程可言。传统软件开发有单元测试、集成测试、回归测试，AI应用开发同样需要一套系统化的测试机制，而它的基础就是评估集。

评估集不是随便找几十条问题就完事。我会按业务维度去建：正常问题、边界问题、模糊问题、包含敏感内容的问题、资料覆盖不到的问题，每一类都要有足够样本。每条样本除了输入，还包含预期输出、关键要素、可接受的回答范围。比如知识库问答场景，一条样本的预期输出不应该是固定文本，而应该是“答案必须包含某某型号的故障原因，且不能出现某某操作方式”，这样模型改版后才有比较依据。

评估打分我通常从五个维度进行：答案准确率、信息完整率、格式合规率、幻觉率、拒绝准确率。准确率看回答对不对，完整率看该给的要素给没给全，格式合规看程序能不能解析，幻觉率看有没有编造信息，拒绝准确率看“该说不知道的时候有没有老实说不知道”。

这套评估集要纳入回归流程。每次改Prompt、换模型、调检索策略，都跑一遍全量评估集，对比分数。我见过太多项目“调好一个问题，带崩一片功能”，就是因为只看个例不看全局。有了回归测试，至少能在发布前发现问题，把“感觉变好了”变成“数据证明变好了”。

3. 一个可落地的AI应用工程闭环：实操拆解

讲完核心模块，我再用一个虚构但高度贴近真实的项目——企业内部售后知识助手，完整走一遍AI应用的工程闭环。这个项目规模不大，但涵盖了需求定义、方案选型、服务封装、上线监控、持续迭代等所有关键环节，可以直接套用到多数AI应用场景。

3.1 需求定义与方案选型

项目启动第一件事不是选模型，而是把需求定义清楚。我在需求阶段会用“用户故事+验收标准”的方式写描述，而不是“我们要接入大模型”。比如：“客服小张在回复用户问题时，可以快速检索售后手册，并生成带来源引用的回复草稿；系统应在一分钟内给出答案，且引用来源必须真实存在于手册中。”这样一来，“接入大模型”这个模糊目标就变成了几个可验证的具体要求。

需求明确之后才是方案选型。我通常会做一张对比表，把模型部署方式、数据敏感性、延迟要求、成本预算、团队维护能力都列出来逐个打分。

这张表没有标准答案，完全取决于业务场景。对多数企业内部知识助手类项目，我倾向先用闭源API快速跑通，验证需求真实性和价值；等流量和效果稳定了，再评估是否把高频模块切到本地部署来降本。

3.2 模型与环境选择

选模型时我会按任务复杂度分层，而不是所有需求都用同一个最强模型。简单分类和抽取任务，用轻量模型就能完成；复杂推理和长文档问答，才需要上强模型。这样既能控制成本，也能降低延迟。

这里我的经验是建立一个“模型路由”机制：请求进来先做意图判断，简单问题走轻量模型，复杂问题走强模型。比如售后助手场景，“这个产品支持七天无理由退货吗”是简单规则问题，“根据故障现象判断可能的原因并给出排查步骤”是复杂推理问题，两者走的模型可以完全不同。

如果选择开源模型本地部署，有几个参数要特别注意。显存大小决定能跑多大参数量的模型；吞吐量决定并发能力；量化精度影响推理速度和效果。一般我会从7B到14B参数量的模型起步，配合4bit量化，单张消费级显卡也能有可用的推理速度，但生产环境还是建议用至少两张专业卡做冗余，避免单点故障导致服务中断。

如果用API方式接入，要重点确认限流策略、版本兼容和故障响应机制。API服务偶尔抖动是正常现象，工程上必须提前做好重试、降级和告警，不能把第三方服务的稳定性当作自己系统的稳定性。

3.3 构建解耦的AI服务模块

AI应用要长期维护，架构上必须把AI能力和业务逻辑解耦。我的惯用结构是五层：数据接入层负责对接各种数据源并清洗；预处理层负责切块、向量化、构建索引；推理服务层负责调用模型或API生成结果；后处理层负责输出格式化、结果校验和兜底规则；业务集成层负责对接客服系统、工单系统等业务平台。

这个结构的好处是每一层都能独立替换。换了向量库，推理层不用动；换了模型，数据层不用动；加了新的数据源，也只是在接入层增加适配器。

推理服务层我习惯用一个统一的接口封装，这样上层业务不关心底层用的什么模型。核心思路是定义同一个方法签名，然后为不同模型写各自的实现。

class CompletionClient: def generate(self, prompt: str, **kwargs) -> str: raise NotImplementedError class OpenAIClient(CompletionClient): def generate(self, prompt: str, **kwargs) -> str: # 调用OpenAI兼容接口 return response_text class LocalModelClient(CompletionClient): def generate(self, prompt: str, **kwargs) -> str: # 调用本地推理服务 return response_text

业务层拿到的是同一个CompletionClient接口，切换模型时只要替换初始化逻辑，其他代码不用动。这个小技巧能极大降低模型升级和替换的改造成本。

输入输出Schema校验也是容易被忽略的点。AI模型的输出是概率性的，偶尔会打出残缺的JSON、多出多余字段、或者格式完全走样。我在后处理层会做严格的Schema解析和校验，解析失败就自动重试一次，重试仍失败就走兜底文案。这么做能拦截掉大量用户可见的报错，让模型输出的“小毛病”在系统内部消化掉。

3.4 上线后的质量监测与迭代

AI系统上线不是终点，而是评估迭代的起点。我上线后第一件事是配置监控大盘，重点盯四类数据：调用延迟的分位数（p50、p95、p99）、token消耗量、错误码分布、以及用户反馈信号（点踩、举报、转人工等）。

这里我想特别强调badcase回收机制。我会上线第一天就在评估集管理后台开一个“线上badcase回收列表”，每天把用户点踩的对话、转人工的记录、格式解析失败的请求全部捞出来，人工标注后加入评估集。这其实是很多团队不做、但价值极高的事情。线下评估集是静态的，线上badcase是动态的，只有不断把动态问题纳入静态评估，系统质量才能真正滚动提升。

迭代节奏我也建议走“小步快跑+灰度发布”。每次改动只动一个变量——要么只改Prompt，要么只换模型版本，要么只调检索参数，不要同时改多个东西，否则出了问题根本不知道是哪个改动造成的。修改后先跑评估集回归，再放到5%到10%的流量上观察，确认指标没有恶化再逐步放量。

我做过一个很深刻的复盘：有一版Prompt改动在某一次个例测试里表现特别好，但全量回归跑下来，准确率反而跌了两个点。原因就是这个改动让模型在“资料覆盖不到”的边界情况下更容易强行作答。如果没有回归测试，这个版本大概率会带着问题直接发布。

4. AI工程实战中的高频坑与排查技巧

不管前期设计多完善，AI应用上线后总会遇到各种奇奇怪怪的问题。我把这几年踩过的高频坑整理成一份速查手册，每个问题都附上排查思路和处理方法，希望对你有实际帮助。

4.1 上下文工程与上下文爆炸

现象：模型的回答越来越跑偏，或者完全丢失了最开始提到的指令；token消耗异常增长，响应越来越慢。

原因：给模型塞了过多内容。很多系统的Prompt由系统指令、检索资料、历史对话、业务数据四部分组成，每一部分单独看都不多，叠加起来却可能远超几万token。模型需要在大量信息中挑重点，自然容易“迷失”。

排查思路：先看每条请求的Prompt实际包含多少token，哪个部分占大头；再逐段做消融测试，去掉某一段后观察输出质量变化，定位拖累效果的内容来源。

处理方法：第一，精简指令，删掉长期不生效的冗余规则；第二，对历史对话做摘要压缩，而不是全量拼接；第三，检索资料的召回数量宁少勿多，只保留最相关的3到5段内容；第四，在Prompt里明确告诉模型“只基于最新指令和指定资料回答”。

我现在的习惯是给每条请求量一个“token预算”，比如总上下文不超过8000 token，其中历史对话最多3000，检索资料最多4000，指令固定1000。超出预算就压缩或截断，从根本上遏制上下文爆炸。

4.2 幻觉与应用层兜底

现象：模型一本正经地给出了资料里不存在的信息，用户按照这个信息操作出了问题，后果很严重。

原因：大模型天生倾向给用户一个“完整答案”，当检索到的资料不足以回答问题时，它会自动脑补。这是概率模型的固有问题，目前没有任何模型能完全杜绝。

排查思路：对模型的输出做来源验证——回答里声称的事实，能不能在检索资料里找到对应依据？找不到依据的段落就是高风险幻觉区。

处理方法：工程上我做四层兜底。第一层是在系统提示里明确写“当资料不足时，必须回答‘资料未覆盖，请转人工’”。第二层是设置检索置信度阈值，召回的相似度低于阈值时不进入Prompt，直接走无法回答流程。第三层是生成后校验，让模型对每个回答段落标注来源引用，程序中校验引用是否真实存在。第四层是对高风险场景（如医疗、法务、设备操作）强制加“需人工确认”提示，不能把AI回答当作最终决策结果直接呈现给用户。

一个很实用的技巧是“允许模型说不知道”。很多团队把“模型回答覆盖率”当成核心指标，逼着模型硬答，结果幻觉率飙升。后来我放弃了覆盖率执念，反而把“拒绝准确率”也纳入评估指标，允许模型在资料不足时拒绝回答，整体用户体验反而更好了。

4.3 Agent链路不稳定

现象：Agent在复杂任务中表现飘忽，有时候正确走完整条链路，有时候中途就断掉；工具调用偶发返回格式异常，Agent直接“懵住”或者反复重试。

原因：Agent链路涉及多步调用，任何一步的非预期输出都可能让整个流程失控。而大模型的输出天然带有随机性，工具返回的格式也可能不完全符合预期。

排查思路：第一步看日志，把Agent每一步的输入输出都记录下来，找到第一个偏离预期的节点；第二步做固定样例回归，用同一批复杂任务反复跑，统计每一步的成功率，定位最薄弱的环节；第三步检查工具返回格式，看是不是解析层对异常格式过于敏感。

处理方法：工具调用输出强制用JSON Schema校验，解析失败就要求Agent重新生成一次；给每个Agent任务设置最大执行步数（我一般设为5步），超过就终止并转人工；对工具调用做超时控制，超时后返回一个固定占位结果，避免链路卡死；关键动作（如下单、删除、修改配置）的Agent输出不能直接执行，必须通过额外的确认接口由用户或管理员二次确认。

4.4 成本与延迟的平衡

现象：用户量一大，token成本快速上涨；用户反馈响应变慢了，尤其在高峰时段。

原因：AI应用的成本和延迟与每次请求消耗的token数、调用的模型规格、以及是否频繁触发高成本能力直接相关。Prompt越长、模型越强、工具调用越多，成本和延迟必然越高。

排查思路：用监控大盘分析token消耗分布，看哪些请求消耗了最多token，哪些场景触发了最强模型，哪些Agent任务进行了大量无效工具调用。

处理方法：我把成本优化总结成三板斧。第一，能轻则轻——简单任务走轻量模型，不走最强的；第二，能省则省——Prompt里的固定系统说明、长文本资料如果重复使用，考虑加缓存层；第三，能批量则批量——用户可接受非实时的场景（如日报生成、周报总结），走异步队列用低成本模型批量处理。

还有一个容易被忽略的点是“召回多了，成本翻倍”。系统提示词里的资料段落越多，每次请求的基础token消耗就越高。把召回数量从10段减到3段，效果通常不会有明显下降，但token成本能降一半以上。

我整理了一张常见问题速查表，方便你现在就用起来：

5. AI工程能力怎么练：方法、顺序与实践

聊了这么多具体技术，最后说说更底层的东西——AI工程能力到底怎么练出来。我给团队带新人时反复强调两句话：先建立评估，再谈优化；从项目中沉淀方法论，而不是停留在调参技巧。

先说“先建立评估，再谈优化”。这句话是整套AI工程方法论的基石。没有度量，就没有优化——你改了一个Prompt，如果无法判断它是变好还是变差，这次改动就是一次赌博；你有十个优化想法，如果无法验证优先级，团队就会陷入无休止的试错。我所有项目的启动顺序都是固定的：先建评估集，再搭评估流程，然后才开始动Prompt和模型。哪怕时间再紧，这一步我也不会省。因为缺了评估系统，后面每一分钟的调优都是在泥潭里打转。

在实践中，我会让每个项目的评估集至少覆盖四类场景：正常业务场景的样本（占60%左右）、边界和模糊场景（占20%）、敏感和异常场景（占10%）、历史上真实出错的badcase（占10%）。评估结果不只看一个总分，还要分维度看，方便定位具体是哪类问题在拖后腿。

再说“从项目中沉淀方法论”。每做完一个AI项目，我都会组织一次复盘，问三个问题：这个项目最后的效果提升，究竟来自模型升级还是工程优化？过程中哪个环节花了最多时间，这个环节能不能通过工具或流程改进来提效？哪些问题和教训是可以复用到下一个项目的？复盘完，把结论沉淀成团队的Checklist和模板库。

我这里有一个长期维护的“AI工程工具箱”清单，分享给你参考：

• 评估集管理：用表格或专门的标注工具维护评估集样本，每条样本带预期输出和可接受范围。
• 回归脚本：一键跑全量评估集，自动生成各维度得分对比报告。
• Prompt模板库：把常用任务的Prompt做成模板，按任务类型归档，标注适用场景和注意事项。
• badcase回收列表：线上问题人工标注后统一入库，进入下一轮评估集。
• 部署检查清单：每次上线前逐项检查模型版本、数据源状态、监控告警、回滚方案是否就绪。
• 成本报表：按业务模块统计token消耗趋势，定期分析成本异常波动。

这套东西看起来不复杂，但长期坚持下来，项目质量和迭代效率都会明显高于那些“每次从零开始、完全凭感觉调Prompt”的团队。

这三四年做AI项目下来，我最大的体会是：模型的能力边界会不断变化，今年觉得复杂的任务，明年可能轻松完成；工程的底层逻辑却相对稳定——清晰的目标、可靠的数据、可度量的评估、可控的链路、可持续的迭代，这些在任何一代模型上都适用。吴恩达强调“AI工程技能驱动构建”，我的理解是，模型让AI的上限变高，工程决定你到底能触碰到多高的上限。如果你正在做AI应用，建议把更多注意力从“选哪个模型”转移到“怎么构建一套可靠的AI系统”上来，这个转变带来的回报，会比想象中更大。