企业官网建设流程全解析

做AI工程四五年了，从最初只会套API写DEMO，到后来在真实业务里把大模型、向量库、Agent串成一条条稳定的流水线，我最大的感触是：市面上教“怎么调模型”的内容太多了，但教“怎么把AI这个系统工程化落地”的内容太少。所谓“AI engineering from scratch”，不是从零学会训练一个人工智能，而是从零搭起一整套能交付、能维护、能评估的AI应用工程体系。这篇内容没有花架子，全是我自己摸爬滚打后沉淀下来的一套打法，适合刚转岗的工程师、准备用AI改造业务流程的产品经理，以及想带着团队系统推进AI落地的技术负责人。

1. AI工程能力地图：先搞清“工程”的边界，再决定学什么

很多人开局就败在目标过于宏大。听到“AI工程”四个字，第一反应是去啃《深度学习》、学反向传播、从头撸一遍Transformer。这完全是研究员路径，工程岗如果照着学，大概率三个月后还在原地打转。

AI工程的核心交付物是“能用大模型能力解决实际问题的应用系统”，它需要的能力谱系其实是酱紫的：

看上表就明白了：它覆盖了传统后端、算法应用、产品设计甚至运营的交叉地带。我见过很成熟的研发负责人最不适应的点在于——传统开发是确定逻辑，AI工程是概率逻辑，所以工程的重心不再只是“写代码”，而是“设计约束、设置护栏、建立评估”。

再给零基础到能落地的学习顺序排个序，这是我给团队新人画过的路线，你按这个顺序基本不会走偏：

1. 用现成大模型API跑通几十个场景的Prompt，感受模型的能力边界和说话风格。
2. 做一个100行以内的Python/Node脚本，把Prompt封装成可重复调用的函数。
3. 引入LangChain或直接手写工具调用，做一个能联网搜索或能查数据库的Agent原型。
4. 学习Embedding和向量库，把你自己的文档丢进去，做一个RAG问答Bot。
5. 给上面的Bot做评估集和回归测试，再顺手接进Web/IM/内部系统。

这个顺序的精髓是：每一步都有看得见、摸得着的产出物，比一上来就啃论文要接地气得多。当你走完第5步，行业里说的“AI工程化”你基本就入门了。

1.1 为什么要强调“边界清晰”

工程和研究的最大区别在于“可交付性”。研究可以允许一个课题做两年、允许结果不可预期，工程不行。AI工程的目标函数非常固定：用可控的成本，把准确率提升到业务能接受的水平，并保证在极端输入下系统不会崩溃。

所以我在给内部技术评审把关的时候，有个习惯动作：先问团队，这个需求到底是“模型能力没到”，还是“工程封装没到位”。大量失败的AI项目，栽倒在后半句。比如模型答不准人名，其实不是换个更强的基座模型能解决的，而是应该在检索链路里加入别名映射；回答风格不一致，也不是靠调temperature能解决的，而是要在Prompt里把评分维度写清楚。

1.2 一个人怎么搭完整栈

你可能没那么多资源配齐正规军团队，但可以用“单人全栈”的思路把所有环节先跑通。我个人推荐的MVP配置是：一台带有16GB以上内存的笔记本作为本地模型实验环境，一个OpenAI兼容接口的国产模型服务用于生产，一条Python FastAPI小服务做后端聚合，再加一个最简单的Web前端。这个配置成本低，但覆盖了从模型到用户之间的所有关键环节，你亲手把每个环节走过去后，才有资格考虑团队的拆分。

2. 环境搭建和模型选型：本地部署、API预算与第一条测试链路

很多教程一上来就让你装LangChain，然后写个五行的demo，看起来很美，实则你连模型返回的结果在质量上是否达标都不知道。我的建议是先把底层能力“打服”，再上框架。

2.1 本地模型的快速起手式

本地部署大模型，不是跟风，而是有真实的工程价值：调试Prompt不产生API费用、数据不出内网、可以反复压测。目前最推荐新手的路径是Ollama：

# 安装后拉取一个中等体量的开源模型 ollama pull qwen2.5:7b ollama run qwen2.5:7b

拉取并跑起来之后，它就自动提供了一个OpenAI兼容的HTTP接口，地址是http://localhost:11434/v1。这意味着你后面写的任何调用代码，既能连云端API，也能连本地模型，只不过改一行base_url而已。

选模型时注意一个原则：优先选跟你要解决问题的领域匹配的中小模型，而不是一味追求最大的参数。7B到14B的模型在写作辅助、结构化抽取、普通问答上，已经能和几十B的大模型掰手腕，而部署成本和推理延迟低出好几倍。一旦本地能够流畅推理，你再把同样的Prompt搬到云端大模型上做对比，就能非常客观地评估“不同模型在同一任务上的差异”。

2.2 API供给与成本护栏

生产环境不可能都靠本地算力，接入商业大模型API依然是最靠谱的兜底方案。但接口并发、动态限流、计费模式、数据隐私这些问题，必须在一开始就设计进去，而不是等上线被打了再补救。

我自己的做法是三层成本护栏：

• 模型分级：简单任务（如摘要、情感分类）默认走7B模型；复杂推理任务才升级到更强模型。
• 上下文裁剪：把输入内容做结构化截断，不重要的历史对话直接压缩成摘要，避免每轮请求都在烧token。
• 缓存层：基于Prompt指纹做结果缓存，同样的查询直接命中Redis，减少重复成本。

这条链路的验证也很关键，我会在写完代码后先做一个压力脚本，模拟50并发，记录每次请求的延迟和token消耗，确认模型不报错、价格可预期、响应在合理区间后，才进入后续开发。

2.3 不要一上来就上框架

你可能被LangChain的华丽抽象吸引，但我要先泼一盆冷水。框架的价值在于帮你编织复杂调用链，代价是引入大量黑盒抽象，遇到问题时你分不清是Prompt的问题还是框架调度的问题。我在早期就把一个简单Agent跑了整整两小时没查出来Bug，最后发现是框架某个版本的工具调用参数解析出了故障。

所以我的建议是：在项目初期，直接用原生HTTP请求构建一条最精简调用链，写一个call_llm(messages)函数，把所有远程调用封装在一小块代码里。等逻辑确实变复杂了，比如你需要规划多步工具调用、多分支状态流转，再去引入框架。

# 最精简的大模型调用封装，不依赖任何框架 import requests def call_llm(system_prompt, user_prompt, model="qwen2.5:7b", base_url="http://localhost:11434/v1"): payload = { "model": model, "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt} ], "temperature": 0.2 } response = requests.post(f"{base_url}/chat/completions", json=payload) response.raise_for_status() return response.json()["choices"][0]["message"]["content"]

这个函数看着简单，却是你验证模型能力、排查网络层错误的最小单元。往后所有高级操作，都是在这个“通信管道”基础上长出枝叶。

3. Prompt Engineering的核心手法：从会问到会设计

Prompt Engineering，说到底是“给模型写使用说明书”。它在AI工程里之所以被称为核心，是因为它直接决定了模型能力的释放率。一段糟糕的Prompt，让GPT-4输出的结果可能还不如精心设计后的GPT-3.5。

3.1 系统提示词的三大支柱：角色、目标、约束

我几乎每个生产级Prompt都会分三段来设计：

1. 角色定义：给模型一个明确的行为框架。例如“你是一名严谨的技术编辑，擅长从代码仓库中提取架构变更，并以结构化文档输出”。
2. 任务目标：说明这个角色这次要做什么、把输入怎么转换输出。
3. 约束条件：列出绝不能做的事和必须做到的事。例如“如果信息不足，只输出NOT_FOUND，不要猜测；回答控制在200字以内”。

这样设计的逻辑在于：模型生成时，是先按角色激活知识面，然后按目标聚焦注意力，最后按约束拉出边界线。你少写一段，模型就少一个锚点，输出质量就会跑偏。

3.2 借助思维链和示例提升推理质量

当你发现模型老是在多步骤问题上答错，不要急着换更强的大模型，先在提示里加入要求“分步骤思考并按思考过程输出”：

请按照以下步骤处理： 1. 提取问题中的关键实体和关系。 2. 根据关系推断可能的因果关系。 3. 给出结论，并注明你的判断依据。

这招最为有效的一个场景是数据抽取和规则判断。另一个杀手锏是Few-shot示例，在提示里给2到3个“输入-理想输出”的样例，模型能很快学会你的期望格式，比写一百句抽象规则都管用。

3.3 用评分卡来量化Prompt效果

纯靠感觉调Prompt是有问题的，要把它当作可以回归测试的代码来看待。我给每个核心Prompt配一张评分卡，至少包含以下维度：

然后在修改Prompt后，把同样的测试集跑一遍，对比评分数值，而不是靠“感觉这版好了不少”。我就靠这套方式，把某个实体抽取任务的准确率从78%推到了90%以上，整个迭代过程两周内完成。

3.4 我在这块的几个深刻教训

在实际落地中，我发现几个高频错觉：

• 加更多的规则就会更准：其实规则过多会相互冲突，把模型的注意力稀释掉。要克制，只保留最关键的约束。
• 指令越详细输出越稳定：对强模型而言，臃肿的指令反而增加理解漂移，必要时给它几条核心指令，让模型发挥自身的对齐能力。
• 中文表达“自然”就完事了：不要轻视结构化符号。在Prompt里用清晰的标记符号，比如<user_input>、<output_schema>，能显著降低模型解析的歧义。

4. AI Agent设计：从单次调用升级到多步任务自动化

AI Agent是热搜里当之无愧的大热门，它的工程含量比单纯用Prompt做问答高一个量级。我理解的Agent核心，是一个拥有“规划-执行-反思”闭环的模型程序，而不是一个简单的函数调用器。

4.1 Agent基本骨架

一个能稳定工作的Agent，至少包含这五个模块：

• 编排器（Planner）：让模型分析用户意图，拆解成子任务列表。
• 工具集（Tools）：能执行具体动作的函数集合，比如搜索、查库、发消息、调用后端API。
• 记忆（Memory）：短期记忆存当前任务的上下文，长期记忆存历史偏好和状态。
• 执行反馈（Feedback loop）：执行完工具调用后，把结果回传给模型，模型判断下一步。
• 兜底策略（Safe mode）：当模型反复陷入死循环、调用失败、输出异常时，主动终止并回到人类接管。

这个骨架说起来容易，真正写代码的时候，最容易翻车的地方是“工具调用的参数解析”。模型端到端地生成“我想查北京的天气”，你是否能可靠地把“北京”和“天气”这两个参数从自然语言中抽出来，并映射到你定义的函数接口上？必须做严格的输入校验，而不是直接信model的输出。

4.2 用最少的代码实现一个可用的ReAct Agent

不要一开始就把Agent设计成十几个工具的庞然大物。我从零做过一个内部知识问答Agent，初期就只挂了两个工具：一个查知识库，一个读企业API。它工作的核心路径是这样的：

def agent_loop(user_query, max_steps=5): messages = [ {"role": "system", "content": AGENT_SYSTEM_PROMPT}, {"role": "user", "content": user_query} ] for step in range(max_steps): response = call_llm(system_prompt="", user_prompt=str(messages), model=MODEL_NAME) decision = parse_decision(response) # 模型输出JSON，解析它要调的工具 if decision["action"] == "final_answer": return decision["answer"] tool_result = execute_tool(decision["tool"], decision["tool_input"]) messages.append({"role": "user", "content": f"工具返回结果：{tool_result}"}) return "已达到最大步数，需要人工介入"

你发现没有，这个循环没有用到任何Agent框架，它的“智能”完全来自Prompt里规定的决策格式。系统提示里我会告诉模型：你必须输出一个JSON，格式为{"action":"search_kb","tool_input":"...","reason":"..."}，如果已经得到答案，就输出{"action":"final_answer","answer":"..."}。

这个简版Agent在十几个场景都能稳定跑通。它在设计上有意识地限制了步数，防止模型陷入死循环烧钱。

4.3 Agent的反思机制

很多人做完上述循环就以为Agent开发结束，大错特错。真实业务里，模型第一步很可能就选错了工具。所以进阶一定要加入“反思”环节：在模型执行完动作后，给它一个机会评判自己，比如“你刚才查到的信息和用户问题直接相关吗？如果不相关，请调整关键词重新查一次”。

我在一个数据整理Agent里实测过：加入反思后，任务完成率从61%提升到了83%。反思的Prompt也不复杂，就是让模型基于反馈重新审视计划，不需要额外训练模型。

4.4 Agent工程化的可观测性

最后强调一点：Agent不像普通API，你没法通过一次日志就完全判断问题在哪。所以从第一行代码开始，就要给Agent加完整轨迹记录——每一步决策的输入输出、工具名、耗时、消耗token数、走到的节点。这些数据既是排障依据，也是后续优化Prompt的素材库。我一般会把轨迹存成JSON文件或写入日志系统，然后单独写一个回放页面，用来复盘Agent哪一步开始跑偏。

5. 把AI大模型接进业务系统：RAG、向量库与产品化路径

跑通Agent后，你离交付还有一段距离。真实业务里，用户不接受你只回答通用知识，他要的是基于他的私有数据、台账、手册得到答案。这就是RAG（检索增强生成）的价值。

5.1 RAG到底解决什么问题

核心是抑制幻觉，让模型在回答你问题时，先到外部知识库里找到可引用的证据，再基于证据生成答案。工程上拆成两阶段：索引阶段（把文档切块、向量化、存入向量库）和查询阶段（把问题向量化、检索TopK相关块、把块塞进Prompt让模型作答）。

5.2 文档切分的参数选择

这是RAG里最微妙也最容易被忽略的一环。切得太粗，带入大量无关内容，模型易被噪声带偏；切得太细，又可能截断语义，丢失完整上下文。我常用的起始参数是：

• 切片大小：400到600字符。
• 块重叠：80到120字符。
• 过滤规则：跳过表头、页脚、重复段落。

不过这些参数别死记，一定要结合你文档的类型调整。我处理过一份分布式系统故障排查手册，多级章节之间因果链很强，单纯按字符切会把“前置条件”和“故障现象”切到两个块里。后来我改成先用Markdown标题定位章节，再按语义段落切分，查准率立刻上升了一截。

5.3 向量库选型与检索策略

向量库选型上，项目早期千万别搞分布式重型架构。先用轻量方案，比如pgedvector、Chroma，甚至直接用文件形式的内存向量库。等数据量确实过了百万条，再评估Milvus这类专业向量库。

检索策略也有一个技巧：不要只做向量相似度召回。可以把“关键词匹配+向量召回”混成双通道，能显著提升包含精确ID、型号、人名这类查询的效果。然后在Prompt里让模型必须输出它引用的文档来源，这样出了错能准确定位是哪份材料误导了模型。

5.4 产品化的最小闭环

所谓产品化，我把它定义为：把零散的模型调用装进一个有界、可交互、有反馈的产品外壳里。工程落地时，我尽量让产品闭环具备这些能力：

• 用户提问后实时流式输出，减少等待焦虑。
• 底部展示“参考来源”，增加回答可信度。
• 加一个“回答有没有帮助”的点赞点踩按钮，把反馈回流到评估集里。
• 敏感词过滤和内容安全拦截作为必经管道，在模型输出前做一道检查。

这里特别说一下流式输出。很多后端工程师初期容易忽略，结果系统响应slow到让用户离开。流式Socket传输不复杂，大体上在FastAPI里用SSE（Server-Sent Events）或WebSocket把模型返回的token逐片推给前端。虽然会增加一点后端复杂度，但对用户体感的提升是决定性的。

5.5 微调不是万能钥匙

聊到最后，我必须给微调泼一盆冷水。很多人一遇到“模型效果不好”就想到微调，对于绝大多数应用场景，瓶颈根本不在基础模型的通用能力，而在于Prompt设计、数据检索质量、工程约束。微调唯一真正必要的场景是：模型需要固定学习一套新的输出风格或高度领域化的术语。

没有足够的优质标注数据就强行微调，结果通常是灾难性的：短期在训练集表现不错，一到开放域就大幅退化，还附赠高昂的训练成本。我现在的决策准则是：先尝试用Prompt+示例+RAG解决80%问题，再做评估看残差，只有当残差明确指向“知识或风格固化问题”时，才考虑构建微调数据。

6. 从零搭建AI工程能力时的典型隐患和修正方案

聊点能直接帮你省时间的实战避坑经验。这个行业太新，试错代价高，很多坑踩一次就足以击垮一个小团队的信心。

6.1 忽视评估体系，一切精准都是错觉

我见过最普遍的错误是“拿几个例子测一下，感觉挺好就上线”。AI系统的概率特性决定了它的失败模式千奇百怪。你给客户演示十个问题全答对了，可能第十一个就崩了。所以一定要建评估集，初期哪怕只有30条历史问题，也要能覆盖正常查询、边界查询、恶意输入三大类。然后每次改动Prompt或链路，就跑一遍完整评估集，用评分卡衡量是变好还是变坏。

6.2 上下文窗口被塞爆，却浑然不知

模型有上下文长度上限，但真实使用中接近上限时，回答质量和延迟都会明显恶化。我在开发中遇到过一个奇怪现象：同样的Prompt，上午返回正常，下午开始频繁丢信息。排查后才发现是用户多轮对话累积的历史消息越来越多，把上下文快撑爆了，模型开始随机忽略早期内容。修正方案很简单：给历史对话做滑动窗口，只保留最近N轮，超出部分压缩成摘要；同时在调用前检查token数量，超出阈值就主动裁剪。

6.3 工具的鲁棒性不足，导致Agent频繁翻车

很多Agent失败的根因不是模型不够聪明，而是工具接口太脆弱。我在真实业务里见过，Agent调数据库查询接口，传入了一个日期格式错误，数据库直接抛异常，反馈给模型的信息是一串看不懂的堆栈，于是模型开始“臆想”错误原因。你要学会把工具层当API来设计：参数校验在前、异常捕获在后、返回错误信息要结构化，让模型真正看懂失败原因，才能修正下一步动作。

6.4 成本失控，是项目隐藏的灭顶之灾

一个看似很酷的功能，如果每次请求要消耗上万token，用户量一大就是天文数字。我一个朋友的产品，在早期没有做成本监控，上线一周后收到账单才发现烧掉的钱远超预期。后来整个团队花了两周做模型分级、缓存和上下文裁剪。我自己的习惯是每个接口都记录“每次请求的token数”，并设月度预算预警线，成本异常增长时第一时间告警。这份功夫越早做越值钱。

6.5 只追求“更聪明”，忽视了“更可控”

做AI工程久了你会意识到，企业真正买单的东西，永远不是“看起来聪明”，而是“是否可控、是否稳定、是否出了事能追溯”。我宁可要一个在95%场景下表现稳定、剩下5%明确说“我不确定”的系统，也不要一个偶尔惊艳但经常失控的系统。所以我会在Prompt的约束里写明“如果信息不足，必须如实告知，不要编造”，同时给系统配置内容安全过滤和低置信度拒答策略。

针对这一点，最后再分享一个具体打法：在项目一开始就把几条核心非功能指标定义清楚——准确率阈值、端到端响应延迟、单次调用成本上限、异常率上限，然后所有开发决策都围绕这些指标做取舍。你会发现，这个框架会逼着你做很多“不酷但正确”的决定，而这些决定才是项目能活过三个月的根本原因。

7. 一条务实的学习与落地路径

如果你现在正站在从零开始的起点，下面是我给你的行动清单，照着做，三个月内做出一个让自己满意的完整项目问题不大。

1. 第一周：用Ollama跑起本地模型，通过与模型聊天，写下你能想到的20个业务问题，逐一测试它回答的优缺点，找到它的短板和你自己的兴趣点。
2. 第二周：用最简单的方式封装一次模型调用，做一个命令行小工具，能够读取Excel、批量生成摘要或打标，感受数据在业务里流转的原始快感。
3. 第三到四周：选择合适的开源框架，或自己实现一个Agent循环，为这个小工具挂上检索知识库、读写文件和调用互联网搜索的能力。
4. 第五到六周：收集100条真实业务问题，人工标注答案，搭建第一版评估集，建立评分卡，开始对Prompt做系统性的回归测试。
5. 第七到八周：将整套链路封装成一个Web或IM机器人应用，加上鉴权和日志，让它被身边的小圈子实际使用，并根据反馈迭代。
6. 第九周之后：复盘整个过程的成本和效果，选一个你投入最多的模块做深挖。如果知识检索相关，就深入向量库和重排序；如果自动化相关，就深入Agent规划、工具编排与稳定的并发调度。

你不必等到能力全满才动手。AI工程这个领域有一个特质：它迭代极快，公共知识三天一变，但核心方法论是稳定复利的。你早一天建立自己的工程闭环，早一天把“模型能力”变成“业务结果”，后面所有的生态工具、新技术模型，对你来说都只是换上更好的发动机而已。

我个人在整个从零到一的过程里，最大的体会是：这条路上杀不死你的，从来不是模型不够聪明，而是工程素养的缺失——缺测试、缺评估、缺成本意识、缺兜底策略。把这几个字刻进骨子里，你的AI工程之路会越走越宽。