企业官网建设流程全解析

1. 先说清楚：AI工程到底在造什么

如果给"AI工程"下一个我自己的定义，我会说：它是一门把模型能力变成用户可感知、系统可维护、业务可交付的产品的工程学科。这不是算法工程师的理论推演，也不是研究员的paper代码，而是一套完整的方法论——从选模型、写Prompt、搭RAG、接Agent，到压测、评估、成本控制、灰度发布，每一步都是工程决策。

我在最开始做AI项目时踩过的最大坑，就是把"调通API"当成了"完成工程"。当时写了个调用大模型生成摘要的小工具，Demo跑通时信心满满，觉得AI应用也不过如此。但等到真正要上生产，问题就全冒出来了：模型输出不稳定，这次返回JSON、下次给你夹带一段Markdown；上下文窗口被撑爆，长文档处理直接崩溃；用户问题稍微换个说法，回答质量肉眼可见地崩塌。那时候我才意识到，AI工程的核心命题其实跟传统软件工程一样：如何在一个充满不确定性的系统里，构建可靠、可测、可迭代的产品。

这篇文章写给谁？两类人。一类是从传统后端、前端转来做AI应用的开发者，你们不缺工程素养，缺的是理解大模型的特殊脾气；另一类是已经在用LangChain、Dify这类工具拼应用的同学，你们需要从"会用工具"走向"理解原理"，知道每一步的取舍和代价。我会按自己从零搭一个AI工程项目的真实路径来讲，不堆概念，只讲实操。

2. 从零开始的技术选型，别一上来就堆全家桶

很多刚上手的朋友会问：AI工程是不是必须上LangChain？是不是直接找一套完整的智能体框架？我的建议是先忍住。

2.1 语言和框架怎么选

整个AI应用技术栈里，Python仍然是绝对主流，因为模型SDK、数据处理生态、评估工具全都是Python优先。但如果你做的是偏向端上的产品、实时性要求高、或者团队本来就是前端为主，TypeScript（Node.js）也完全可行——目前主流模型厂商的SDK对TS支持已经非常好了，再加上Vercel AI SDK这类工具，做Web应用落地效率极高。

框架层面我的真实体验是：第一版能不用框架就不用框架。直接调OpenAI/Anthropic/国产模型的SDK，或者用各家官方函数调用（Function Calling）接口，先把手上的业务逻辑跑通。理由很朴素：框架帮你封装了Prompt模板、记忆、工具调用这些环节，但封装的代价是你没法看清每个环节的输入输出，出了问题很难定位是模型的问题还是框架的锅。等业务验证了方向，再引入框架或自研编排层，那时候你的判断力完全不同。

2.2 模型选型的原则：按任务分而不是按名气分

模型选型是AI工程里性价比最高的决策项。我不认为存在一个"最好的模型"能通吃所有场景，更合理的策略是按任务分：

• 复杂推理、代码生成、长文本理解：选顶级闭源模型（比如各家的旗舰版），成本高点但稳定，这属于"买确定性"。
• 意图识别、分类、抽取、改写：中等尺寸的模型完全够用，成本能省下70%以上。
• 本地化、隐私敏感、离线部署：考虑开源权重模型，再用LoRA微调或量化压缩。

我见过一个团队为了追求"AI感"给所有任务都上最强的模型，结果成本翻了三倍，响应速度还慢了一半，用户体验反而更差。正确的思路是先做任务拆解，再给每个子任务配上合适的模型——就像你不会拿大型服务器去跑一个定时脚本一样。

提示：模型选型时别忘了看一个常被忽略的指标——输出Token上限和上下文窗口。有些模型擅长对话但输出上限太低，没法稳定生成结构化长文本；有些模型上下文窗口大，但中间位置的召回能力会衰减，长文档场景需要额外验证。

2.3 数据与向量数据库：别在第一版追求高性能检索

数据存储这块，我建议第一版直接从向量数据库里挑一个主流的（比如Milvus、Qdrant、pgvector），不要自己研究ANN算法，也不要在多个向量库里纠结。选型的判断标准是：团队熟悉哪个生态、是否支持混合检索（向量+关键字）、能否水平扩展。

有个常见的误区是"向量数据库越专业越好"。如果你的数据量在几万条量级，一个PostgreSQL加上pgvector扩展就够了，省掉一个中间件对运维成本是很大的减负。数据规模到百万级、千万级再引入独立向量库，那时候工程收益才明显。

3. 摸清大模型的能力边界，比学会调API更重要

AI工程里面大部分"翻车"，根源不是Prompt写不好，而是设计者对模型的边界缺乏感知。我在团队里常说一句话：先把大模型当成一个高智商但极度不稳的实习生，再看你该怎么安排它的工作。

3.1 模型不是数据库，也不是规则引擎

有大模型之后，很多新手的自然反应是：把产品逻辑都塞给大模型去理解执行。比如做一个请假审批系统，让模型直接根据员工请假理由判断是否批准——这种做法非常危险。大模型不具备执行规则的一致性，同一段话换个语气可能得到完全不同的判断结果，这在实际工程里属于致命缺陷。

正确的姿势是把模型用在"语义理解"和"内容生成"这两个它的绝对优势区，把判断、计算、权限校验这些确定性逻辑留在代码里：

• 用户输入了一段话，让模型抽取其中的日期、人员、事由（结构化输出）；
• 再用代码去校验日期格式、权限范围、剩余假期；
• 最后让模型生成一段审批意见回复用户。

这样分工，模型的不确定性被限制在"理解"和"表达"层，业务正确性由代码保证。这个原则几乎可以套用到所有AI应用里。

3.2 函数调用（Function Calling）是工程化的地基

现在主流模型都支持函数调用能力，它在工程里的地位怎么强调都不为过。你可以把它理解成给模型一只手，让模型自己决定"为了完成这个任务，我需要调用哪个工具，传入什么参数"。

实践中我建议把函数调用当成结构化接口来设计：每个函数的参数必须有清晰的JSON Schema定义，函数描述要写清楚"什么时候该调用这个函数"和"参数的含义"。举例，你做一个天气查询助手，函数描述如果只写"查询天气"，模型很可能在用户问"明天出门要不要带伞"时不调用任何函数直接回答。但如果你把函数描述写成"当用户询问天气状况、穿衣建议、出行安排等需要气象数据支撑的问题时调用此函数，参数location为城市名，date格式为YYYY-MM-DD"，调用成功率会提升很多。

注意：函数调用也会出错，模型可能传入不存在的参数名、或者在不该调用的时候调用。工程上必须做好参数校验和失败兜底，比如调用失败后给模型返回一个可读的错误信息，让它重新规划。

3.3 上下文窗口：能用的窗口和真实的有效窗口

各家模型都在比拼上下文窗口长度，128K、256K甚至更夸张。但工程上的真相是：窗口够不够长是一回事，长距离信息能不能被"看"到是另一回事。模型本质上对中间位置的注意力会衰减，塞入大量无关内容反而会稀释重点。

所以做长文档问答时，正确思路不是把全文塞进去，而是先检索再拼装。用户的问题进来，先找到最相关的几个片段，把片段拼成Prompt再交给模型。这也自然引出后面要讲的RAG（检索增强生成）。

4. Prompt Engineering的三个层次：从写词到编排

很多人以为Prompt Engineering就是"给模型写一段提示词"，实际上它可以拆成三个层次：提示词层、上下文工程层、系统编排层。越往下走越接近系统工程。

4.1 提示词层：先说清角色、任务、输入、输出

最基础的提示词设计，核心是"说人话、边界清"。一个合格的系统Prompt至少包含四要素：角色定义、任务描述、输入说明、输出格式。我常用的写法是：

你是一个<角色>。 你的任务是<任务描述>。 你将收到这样的输入：<输入格式说明>。 你必须输出以下格式：<输出格式/示例>。 约束：<任何不可违反的规则，比如"只基于给定内容回答，不要编造">

这套模板看着简单，但实际效果比很多人随手写的"帮我分析一下这段话"要好得多。原因是它把模型的工作范围和输出标准一次性界定清楚了，模型不需要去猜你要什么。

进阶技巧是给模型提供几个基本一致的示例（Few-shot）。注意是"基本一致"而不是"最好"，因为如果示例里有一个特殊的表达方式，模型会不自觉地模仿你的示例风格。被它带偏还不如不给示例。

4.2 上下文工程层：模型记忆和知识的管理

提示词层解决的是"怎么问"，上下文工程层解决的是"给它看什么"。这里有个很有用的概念叫上下文预算——你能在多大程度上控制进入Prompt的信息。

一个真实的例子：我们的文档问答应用，最初把所有相关片段不分主次全拼进去，结果模型答问题答得含含糊糊。后来改动策略，第一步先用大模型对小片段做一次相关性排序，挑出最相关的3-5个片段，再把它压缩改写成一个尽量简洁的背景段落喂给模型。同一个模型、同一个Prompt，回答准确率提升了接近20个百分点。

上下文工程里还有个被低估的细节：信息的位置。有些模型对Prompt开头和结尾的注意力明显强于中间。所以关键指令放在开头（角色和任务），关键数据放在结尾（用户问题新加入的内容），中间放背景材料。虽然听起来很玄学，但实测真的有效。

4.3 系统编排层：把多步任务分解成流水线

复杂任务不要指望一次Prompt搞定，你需要的是一条Pipeline。比如做一个"行业调研报告生成器"，直接让模型一次输出完整报告，结果通常是泛泛而谈。拆成多步之后效果完全不同：

1. 第一步：模型生成报告大纲（结构化输出）；
2. 第二步：针对每个小节，让模型列出需要的数据或事实；
3. 第三步：检索相关材料并填充内容；
4. 第四步：汇总初稿，再用一个"润色/纠错"Prompt做终审。

每一步的输出都交给下一轮Prompt作为输入，中间环节可以被记录、被干预、被替换。这其实就是Agent工作流的雏形——你不需要一步就让模型成为全知全能的天才，你要做的是把它当作流水线上的协作节点。

5. RAG落地：搜索质量决定应用的天花板

RAG（Retrieval-Augmented Generation）几乎是现在做知识库类AI应用的必选项。但我观察到一个现象：很多人把RAG想得太简单，以为就是"Embedding入库+向量检索+拼接Prompt"三段式。真跑到生产环境，会发现一堆粒度问题、召回问题和解析问题。

5.1 Embedding模型选型：别迷信"越大越好"

Embedding是整个RAG的地基。选Embedding模型时关注三点：语义匹配效果、向量维度（影响存储和检索成本）、多语言/领域适配度。不要盲目追求维度高，维度越高存储越大、检索越慢，收益却很有限。对中文场景，优先考察在中文语义相似度评测集上的表现，很多英文优秀的Embedding模型在中文本土语义上表现平平。

如果有条件，可以拿自己业务里真实的问题和文档片段做一个小评测集，对比两三个候选Embedding模型，看哪个召回的Top-K里真正包含正确答案。这个小动作能帮你绕开很多玄学争论。

5.2 分块策略：粒度决定检索精度

分块是RAG里最"手工作坊"但影响最大的环节。分太大，一块内容里混了多个主题，检索命中后噪声多；分太小，语义不完整，检索到的片段缺乏上下文。

我的经验是分块策略跟内容格式强相关，没有万能参数：

• 一般文本：按段落分块，每块控制在300-500字；
• 代码/技术文档：按语义块（类、函数、章节）分块，同时保留结构化标题信息；
• 表格数据：一行一条记录 + 表头重复拼接，否则模型读不懂列含义。

分块时保留上下文元数据很关键。比如你可以给每块附上章节路径、文档ID、标题层级，这些元数据在后续检索和引用溯源时非常有用。

5.3 检索优化的三个层次，从快到精

基础向量检索只是起点，工程上通常按下面顺序逐步加码：

第一层：混合检索。向量检索擅长语义匹配，但精确的关键字/ID匹配是它的弱项。把BM25或SQL关键字检索与向量检索结果做加权融合（RRF是个简单好用的融合算法），能显著提升精确类问题的召回。

第二层：重排（Rerank）。初检召回Top-50的候选段落，用一个专门的Rerank模型（比如bge-reranker系列）做细粒度相关性打分，取Top-5。这个操作的成本比直接让大模型排序低得多，效果却接近大模型精排。重排是RAG质量提升里性价比最高的一步，强烈建议加。

第三层：引用与溯源。最终答案里要求模型标注每一句话对应的来源段落ID，一方面方便用户核查，另一方面你可以在产品后台分析哪些来源片段被频繁引用，反向优化你的知识库内容和分块策略。

提示：别忽略一个"愚蠢但救命"的兜底逻辑——当检索结果的相似度分数低于阈值时，宁可告诉用户"知识库里暂时没有找到相关信息"，也不要硬凑答案。一个一本正经胡说八道的助手比一个"我暂时不知道"的助手可怕得多。

5.4 文档解析是魔鬼所在

文字版PDF、Word处理起来没太大问题，但扫描件、非标准排版、表格嵌套、双栏文档，每一个都能让你怀疑人生。工程上比较靠谱的做法是：先做OCR（比如PaddleOCR为主力），再用"解析+清洗+分层"的思路，把文档变成结构化数据后再分块。

这块我只有一个忠告：永远要留一个人工抽检环节。全自动解析的准确率不可能100%，但在知识库上线初期，抽取几个关键文档人工过目一遍，可以帮你及时发现解析问题，避免错误信息被用户看到后才暴露。

6. 评估驱动开发：没有评估闭环，一切都是玄学

AI工程跟传统工程最大的区别是：没有明确的"对错"标准。同一个Prompt，用户换一个问法结果就可能漂移。所以AI工程必须有自己的一套质量保障方法，我把这套方法的核心叫作"评估驱动开发"。

6.1 先建评估集，再写代码

很多团队的节奏是：先做功能、后补测试。但在AI工程里我强烈建议反过来，先花时间攒一个评估集。收集真实用户问题100条，整理标准答案；或者退而求其次，把用户问题归类到预期的答案要点里。评估集将成为你所有迭代判断的"裁判"。

这个评估集的来源可以是历史客服记录、你自己反复提的问题、朋友试用时提的问题，甚至可以先让模型模拟出一批典型问题，再人工校准。关键是真实、代表性强、覆盖边界情况。我见过不少项目卡在"改一个Prompt怕影响其他场景"的死结里，其实就是因为没有评估集，每一次改动都只能靠感觉去赌。

6.2 评估方法：从规则到AI裁判

有了评估集之后，怎么评估模型输出好不好？分三个层次：

• 精确性评估：适合抽取、分类、JSON生成这类任务，直接用代码比对模型输出和标准答案，统计准确率即可。这里面有个细节：模型输出的JSON经常不规范，所以解析要容错，必要时让模型先输出再校验，错了给错误信息让它重试。
• 多要点打分：适合问答、摘要类任务。把标准答案拆成多个要点，每个要点让AI裁判（用强模型）判断是否在模型输出中被覆盖，最后算要点覆盖率。这比整体打分可靠，因为整体打分经常会因为措辞不同而误伤。
• AI裁判注意事项：AI裁判也有偏差。用强模型评弱模型时会系统性偏向文笔流畅、篇幅较长的答案。所以评估Prompt要明确要求"忽略长度差异，按内容要点覆盖率打分"，最好固定几个回答的顺序避免位置偏差。

6.3 回归测试：每次改动都要跑一遍

从你建好评估集那天起，每次修改Prompt、换模型、调检索策略，都必须跑一遍同一套评估集，对比分数变化。这是AI工程版的"回归测试"，它能让你改性的时候心里有底。

我们团队现在把评估集跑分集成到CI流程里，每次提交代码自动跑一次，指标下降超过阈值就阻断合并。这个机制看起来增加了一点开发成本，但相比模型行为漂移后线上爆雷的代价，这点成本完全可以忽略。

7. AI Agent实战：从工具调用到自主任务编排

Agent是现在最热的话题，但也是被误解最多的概念。很多人以为Agent就是"你问一句，它自己把活儿全干了"。真实工程里的Agent远没有那么神奇，它的本质是：一个由模型做决策、由代码做执行、按照循环机制运转的任务编排系统。

7.1 先Workflow，再Agent

我的建议是从Workflow做起，再在关键节点上逐步引入Agent的自主决策能力。Workflow是把业务流程固定成DAG，每个节点做什么清清楚楚，稳定可控；Agent则是在某些节点上由模型自己决定"下一步该做什么、是否要调用工具、调用哪个工具"。

一个落地案例：我们的智能客服系统走的是混合路线——主流程是Workflow：先意图识别，再按工单类型走不同的处理路径；但其中"用户问题比较复杂，需要查多个文档才能回答"的场景，会切入一个Agent子流程，让模型自己决定查几个库、拼几次答案。这样既保证了90%常规问题的高效稳定，又让剩下10%的疑难杂症有兜底解法。

纯Agent方案的诱惑在于看起来自适应能力强，但代价是行为不可预测、难以回归测试、出问题很难复现。如果你的场景业务规则清晰且稳定，优先Workflow；如果确实需要动态决策，再考虑Agent，并一定给它限制"活动范围"。

7.2 记忆与状态管理：Agent最容易翻车的环节

多轮对话里的Agent有个阴暗角落：上下文状态。模型自己维护的记忆是不可靠的，它经常会在对话过程中遗忘或混淆信息。工程上正确的做法是：模型只做一次性的"信息抽取"和"决策输出"，真正的状态交给外部存储。

我就犯过这个错误：早期做一个Agent应用，让模型自己在对话里记住用户选过的偏好（比如"我不吃辣"），结果对话到第5轮，模型在回答完全不相关的问题时还把"不吃辣"扯进来。后来改造：每轮对话先用一个抽取Prompt把用户偏好结构化出来，写入独立的字段；回答时再把结构化偏好作为上下文注入。从那以后，状态一致性再也没出过问题。

7.3 平台还是代码框架

如果你不想从零造轮子，Dify、Coze这类平台确实能快速搭出原型；代码层面LangChain、LlamaIndex、Semantic Kernel这类框架各有一批拥趸。我的经验是：原型阶段用平台/全套框架，生产阶段必须能下探到一层。也就是说，你要搞清楚平台内部帮你做了什么——Prompt是怎么拼的、工具调用的错误怎么处理的、多步执行失败时有没有回滚机制。否则上了线你会发现，平台给的自由度和可观测性根本不够。

我们现在用的方式：底层工具调用直接写原生代码，只把Agent编排逻辑用框架的抽象层来组织，同时给每个环节加日志。遇到问题能定位到是哪一步、哪个工具的调用出了问题，这在生产环境里是必须的。

8. 工程化的另一半：测试、可观测性和成本

一个AI工程能稳定跑在生产环境，靠的不是"模型选得好"，而是四周的工程配套够扎实。最后这部分聊几个容易被忽略但决定成败的点。

8.1 测试：不只有提示词测试，还有全链路测试

AI应用的测试金字塔和传统应用长得很相似：

• 底层：对工具函数、数据解析、业务逻辑做单元测试（这部分是确定性代码，100%要有）；
• 中间层：单次模型调用做输入输出快照测试——固定一组输入，比较模型输出是否在合理范围内；
• 上层：做端到端测试，模拟一个完整的用户流程图，确认最终结果满足业务目标。

其中快照测试是我强烈推荐的：在线把真实用户问题和当时的模型输出存下来，定期对比当前模型输出和历史的差异。模型行为发生变化时快照测试能让你第一时间感知，而不是等用户投诉上门。

8.2 可观测性：把模型当网络服务来监控

调用大模型本质上是在调用一个由别人掌控的外部服务，传统监控手段全都用得上：调用量、错误率、P95/P99延迟、Token消耗量、费用估算。除此之外，AI应用还需要监控"语义健康度"——比如注入攻击触发率、输出空内容/非法格式的比例、拒答率、甚至输出内容的敏感词命中率。

日志方面，每个外部调用都要把Prompt和回复记录下来。这里提醒一下隐私问题：如果用户数据不允许出域，就要考虑私有化部署模型或至少做脱敏处理，这个一定要在产品设计阶段就想清楚，而不是上线前才补。

8.3 成本控制：Cache、模型分层和蒸馏

大模型的成本不像服务器有固定的账单，它跟你的Prompt设计直接相关。省成本的三个杠杆：

• 语义缓存：把用户问题和生成结果缓存下来，相似问题命中缓存就不重新调用模型。用Embedding相似度做缓存命中判定，实际能砍掉30%-50%的重复调用。
• 模型分层：开头说的任务拆解在这里就兑现了——能用小模型解决的绝不用大模型。在意图识别、摘要、改写这类任务上，中小模型的表现已经足够好，大规模上线能省下一大笔钱。
• 蒸馏（Distillation）：如果某个子任务的高质量输出模式比较固定，考虑用强模型产出一批高质量数据，微调小模型复刻这种能力。这样做一次性的训练成本，换来长期的推理成本下降，流量大的场景很划算。

注意：成本优化一定不能牺牲核心体验。定价的时候想清楚哪些交互必须走最强模型不可替代，哪些允许"低配版"回答。优先级永远是核心场景质量 > 成本，否则你省下的钱会以用户流失的形式加倍还回去。

8.4 灰度发布与模型切换：AI系统也需要平滑上线

传统系统升级发布要灰度，AI工程的模型切换、Prompt改动同样要灰度。我见过不止一次团队在生产环境直接换了新模型，结果某个暗处的边角场景表现崩了，用户截图投诉才发现。

稳妥的做法是：新旧模型（或新旧Prompt）并行运行，线上流量按比例切（比如先5%），用前文提到的评估集+用户反馈数据对比两者表现，再逐步放开。新模型也好、新Prompt也好，在没有评估证据之前，"感觉好用"是不可靠的。

我自己在项目里长期保留一个"对比面板"：同一个用户问题，让新旧两套方案同时回答，人工或AI裁判对比优劣。这比任何翻来覆去的讨论都有说服力。

从零做一个AI工程，要学的技术点确实不少，但真正决定项目生死的往往不是某个算法多高深，而是一整套工程习惯：把不确定性限制在可控范围、每个环节都有评估依据、每次变更都经得起回归。把这些基础打牢，你会发现大模型应用开发和传统软件开发在心态上没什么两样，只是多了一门理解"新同事"（模型）脾气的功课。