企业官网建设流程全解析

1. 从零搭建AI工程能力：为什么我劝你别一上来就啃论文

这两年“AI工程”这个词被炒得火热，招聘JD上动不动就要求“具备大模型落地经验”“熟悉RAG架构”“能独立完成Agent开发”。很多做后端、做前端甚至做数据分析的朋友跑来问我：到底怎么才能从零把AI工程这套东西学明白？我的回答通常很直接——别一上来就抱着Transformer原论文死磕，也别急着去调参微调，先把“工程”两个字吃透。

ai-engineering-from-scratch这个项目标题，核心讲的其实就是一件事：从工程视角而非学术视角，把AI应用从想法到上线的完整链路跑通一遍。它解决的不是“模型为什么能预测下一个token”这种理论问题，而是“我手上有个业务需求，怎么用现成的模型能力把它做成一个稳定、可维护、能扛住真实流量的服务”。适合谁来参考？我认为有三类人最该看：一是传统软件工程师想转型AI方向，二是产品/运营想自己动手验证AI想法，三是学生或刚入行的开发者想补齐工程化这块短板。

我自己的背景是后端开发转AI应用，踩过的坑不比谁少。最开始我也走过弯路，花两个月啃深度学习理论，结果真到要做项目时，连一个带上下文记忆的对话服务都搭不利索。后来我调整了思路，把AI工程拆成“数据接入—模型调用—业务编排—服务部署—监控迭代”这几个环节，逐个击破，才慢慢摸到门道。这篇内容我就按这个思路，把从零搭建AI工程能力的完整路径拆开讲，包含方案选型逻辑、关键参数计算、实操步骤和避坑经验，尽量让不同基础的人都能照着复现。

2. 整体设计与思路拆解：AI工程到底在工程什么

2.1 先搞清楚AI工程和算法研究的边界

很多人把AI工程和算法研究混为一谈，这是第一个要纠正的认知。算法研究关心的是模型结构、损失函数、训练策略，目标是提升指标；AI工程关心的是如何把模型能力稳定、高效、低成本地交付给业务，目标是让功能可用、好用、用得起。举个具体例子：算法同学会研究怎么把准确率从92%提到94%，而AI工程同学要解决的是“这个模型响应延迟800毫秒，用户等不了，怎么优化到200毫秒以内”。

这个边界划清楚之后，学习路径就完全不同了。你不需要自己训练一个大模型，但你必须懂推理服务的部署方式、上下文窗口的限制、token计费规则、并发请求的处理策略。这些才是AI工程师日常打交道的东西。我见过太多人卡在“要不要自己微调”这个问题上，其实对绝大多数业务场景来说，用好提示词工程加检索增强，效果已经足够，成本还低得多。

2.2 技术选型的三个核心决策点

从零搭建AI工程能力，绕不开三个选型决策，我把它总结成一张表，方便你对照自己的情况做判断。

为什么起步阶段强烈建议用闭源API？因为自部署一个可用的开源模型，光是环境配置、显存规划、推理加速这几件事，就能耗掉你两周时间，而且效果未必比API好。工程学习的核心是快速拿到反馈闭环，不是炫技。等你把整条链路跑通了，再根据成本或合规要求考虑替换模型来源，这时候切换成本也低，因为你的业务代码和模型调用层是解耦的。

2.3 分层架构：让每一层都能独立替换

我在实际项目里总结出一个分层思路，把AI应用拆成四层：接入层、编排层、能力层、数据层。接入层负责请求接收和鉴权，编排层负责流程控制和提示词组装，能力层封装模型调用和工具调用，数据层管理向量库和业务数据库。这样分层的好处是，任何一层想换实现，其他层几乎不用动。

比如你一开始用某家API，后来想换成另一家，只需要改能力层的适配代码，编排层和接入层完全无感。再比如你一开始用内存向量存储，后来数据涨到百万级要换专用向量库，也只动数据层。这种解耦设计是AI工程能长期维护的关键，很多demo项目之所以没法变成产品，就是因为所有逻辑揉在一个文件里，改一处崩三处。

3. 核心细节解析与实操要点：把每个环节拆到能上手

3.1 环境准备与依赖管理

环境这块我踩过的最大坑是依赖版本冲突。AI相关的Python包更新极快，今天装的版本明天可能就不兼容了。我的做法是：用虚拟环境隔离，并且把关键依赖的版本号锁死。具体操作上，我习惯用venv加requirements.txt，而不是直接全局安装。

python -m venv ai-env source ai-env/bin/activate # Windows下用 ai-env\Scripts\activate pip install openai python-dotenv fastapi uvicorn pip freeze > requirements.txt

这里有个细节：pip freeze会把所有间接依赖也写进去，版本锁得很死，好处是可复现，坏处是升级麻烦。我的折中方案是，主依赖手动指定版本范围，间接依赖让它自动解析。另外，API密钥这类敏感信息绝对不要写进代码，用.env文件管理，并且把.env加进.gitignore。我见过有人把密钥提交到公开仓库，结果被人跑了几百块账单，这种低级错误一定要避免。

注意：虚拟环境目录不要提交到版本控制，团队协作时每个人本地创建自己的环境，靠requirements.txt保证一致性。

3.2 模型调用层的封装要点

直接调API谁都会，但工程化的调用层要考虑的东西多得多。我封装调用层时必做四件事：超时控制、重试机制、错误分类、用量记录。超时控制是防止请求卡死拖垮整个服务，一般设30秒；重试机制针对网络抖动，但要注意只对可重试的错误重试，比如限流错误可以退避重试，参数错误重试多少次都没用。

错误分类这块我吃过亏。最开始我把所有异常都当成一种处理，结果限流错误和认证错误混在一起，排查了半天。后来我按HTTP状态码分类：401是密钥问题，429是限流，500是服务端问题，分别对应不同的处理策略。用量记录则是为了成本控制，每次调用记录token消耗，月底一算账心里有数。

import time from openai import OpenAI, APIError, RateLimitError client = OpenAI(timeout=30.0) def call_model(prompt, max_retries=3): for attempt in range(max_retries): try: resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}] ) return resp.choices[0].message.content except RateLimitError: wait = 2 ** attempt time.sleep(wait) except APIError as e: if e.status_code == 401: raise # 密钥问题，重试无意义 time.sleep(1) raise Exception("重试次数耗尽")

这段代码里，退避重试用的是指数退避，第一次等1秒，第二次2秒，第三次4秒。为什么用指数而不是固定间隔？因为限流往往是短时间高频触发，固定间隔容易继续撞墙，指数退避给服务端喘息时间，成功率更高。

3.3 提示词工程的工程化落地

提示词工程不是随便写几句话，工程化落地要解决可维护、可测试、可版本管理三个问题。我的做法是把提示词从代码里抽出来，单独放在模板文件里，用占位符注入变量。这样改提示词不用动代码，也方便做A/B测试。

提示词模板我一般分三部分：角色设定、任务描述、输出格式约束。角色设定让模型知道自己是干什么的，任务描述说清楚要做什么，输出格式约束保证结果可解析。比如做信息抽取，我会明确要求“以JSON格式输出，字段包括name、date、amount”，这样后续代码直接解析就行，不用再做自然语言处理。

提示：输出格式约束里，给一个具体的示例比单纯描述更有效。模型看到示例后，格式遵循率能提升一大截。

3.4 检索增强的完整链路

检索增强是AI工程里最实用的技术之一，它让模型能基于你的私有数据回答问题。完整链路包括：文档切分、向量化、存储、检索、重排、拼接提示词。每一步都有讲究。

文档切分不是随便按字数切，要考虑语义完整性。我一般按段落切，如果段落太长再按句子切，切分块大小控制在300到500字。为什么是这个范围？太小了上下文不完整，太大了检索精度下降还浪费token。向量化就是把文本转成向量，用现成的embedding模型即可，不用自己训练。存储用向量库，检索时算余弦相似度找最接近的几块。

重排这一步很多人会忽略，但它对效果影响很大。初步检索出来的结果按相似度排序，但相似度高不代表真的相关。重排用一个更精细的模型对候选结果重新打分，能显著提升最终质量。我实测下来，加了重排之后，回答准确率能提升15%左右。

4. 实操过程与核心环节实现：从零跑通一个完整服务

4.1 需求定义：做一个能查内部文档的问答服务

为了把前面讲的东西串起来，我拿一个真实场景来演示：做一个能查询内部技术文档的问答服务。需求很明确——用户输入问题，系统从文档库里找到相关内容，让模型基于这些内容生成回答。这个场景覆盖了AI工程的大部分核心环节，又不至于太复杂。

先明确技术指标：响应时间控制在3秒以内，单次回答成本控制在0.01元以内，支持每天1000次调用。这些指标决定了后面的选型。3秒响应意味着不能用太大的模型，成本限制意味着要控制token用量，1000次调用意味着并发不高，单机部署足够。

4.2 文档处理与向量化实操

文档处理是第一步。我准备了一批Markdown格式的技术文档，先用脚本把它们切分成块。

import os from pathlib import Path def split_document(text, chunk_size=400, overlap=50): paragraphs = text.split("\n\n") chunks = [] current = "" for para in paragraphs: if len(current) + len(para) > chunk_size and current: chunks.append(current.strip()) current = current[-overlap:] + para else: current += "\n\n" + para if current.strip(): chunks.append(current.strip()) return chunks docs = [] for md_file in Path("docs").glob("*.md"): content = md_file.read_text(encoding="utf-8") for i, chunk in enumerate(split_document(content)): docs.append({"source": md_file.name, "index": i, "text": chunk})

这里overlap参数是重叠字数，设50是为了避免正好在切分点丢失上下文。比如一句话被切成两半，重叠部分能让两块都包含完整语义。切分块大小400字是我反复测试后的经验值，太小检索不准，太大浪费token。

切分完就是向量化。我用的是现成的embedding接口，把每块文本转成向量存起来。这里要注意，向量化是有成本的，文档多的时候要批量处理，别一条一条调，那样又慢又贵。

4.3 检索与回答生成的串联

检索环节，用户问题先向量化，然后和库里所有向量算相似度，取Top 5。为什么取5块而不是1块？因为单块可能不完整，多取几块让模型有更全的上下文。但也不能太多，太多会超出上下文窗口还增加成本。5块是我实测下来效果和成本的平衡点。

import numpy as np def retrieve(query_vec, doc_vecs, top_k=5): scores = np.dot(doc_vecs, query_vec) / ( np.linalg.norm(doc_vecs, axis=1) * np.linalg.norm(query_vec) ) top_idx = np.argsort(scores)[-top_k:][::-1] return top_idx, scores[top_idx]

拿到Top 5的文本块后，拼进提示词里让模型生成回答。提示词里我会明确要求“只基于提供的资料回答，资料里没有的信息不要编造”。这句话很关键，能大幅降低模型胡说的概率。

4.4 服务化与接口设计

最后把整个流程包成一个HTTP接口，用FastAPI实现。接口设计上，我留了question和top_k两个参数，top_k默认5，允许调用方调整。返回结果里除了回答，还带上引用的文档来源，方便用户核实。

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class Query(BaseModel): question: str top_k: int = 5 @app.post("/ask") def ask(q: Query): q_vec = embed(q.question) idx, scores = retrieve(q_vec, doc_vecs, q.top_k) context = "\n\n".join(docs[i]["text"] for i in idx) answer = call_model(build_prompt(q.question, context)) return { "answer": answer, "sources": [docs[i]["source"] for i in idx] }

部署用uvicorn起服务，前面挂个Nginx做反向代理。单机跑1000次调用绰绰有余，等量上来了再考虑加机器或上容器编排。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 模型返回格式不稳定怎么办

这是最高频的问题。你要求输出JSON，模型有时候给你包一层Markdown代码块，有时候字段名拼错，有时候干脆输出一段解释文字。我的应对策略分三层：第一层在提示词里给明确示例，第二层在代码里做容错解析，第三层加校验重试。

容错解析就是先用正则把可能的JSON部分抠出来，再尝试解析。解析失败就触发重试，重试时在提示词里强调“只输出JSON，不要任何其他文字”。实测下来，加了重试之后，格式问题基本能解决。如果某个场景反复出问题，那就要考虑换更强的模型，或者把任务拆得更细。

5.2 检索结果不相关怎么调

检索不准通常有三个原因：切分不合理、embedding模型不适合、相似度算法问题。排查顺序我建议从切分开始，把检索出来的块打印出来看，如果块本身语义不完整，那问题就在切分。如果块没问题但检索不到，那可能是embedding模型对领域词汇不敏感，考虑换一个在相关领域表现更好的模型。

还有一个容易被忽略的点是查询改写。用户的问题往往口语化，直接拿去检索效果差。我一般先用模型把用户问题改写成几个关键词或标准问法，再拿去检索，命中率能提升不少。这一步多花一次模型调用，但值得。

5.3 成本失控怎么控制

成本失控一般发生在两个地方：上下文太长和调用太频繁。上下文太长是因为检索回来的块太多或太大，解决办法是控制Top K和块大小，并且定期清理低质量的块。调用太频繁可能是代码里有循环调用或者缓存没做好。

我强烈建议加一层缓存。相同或相似的问题直接返回缓存结果，不用每次都调模型。缓存用问题文本的哈希做key，简单有效。另外，用量记录一定要做，每天看一次消耗，发现异常及时排查。我见过有人因为一个死循环，一晚上跑掉几百块，有监控就能避免。

5.4 并发上来后服务不稳定

单机测试没问题，一上并发就崩，这是很多demo项目的通病。原因通常是同步阻塞调用把线程占满了。模型API调用是网络IO，应该用异步方式。把requests换成httpx的异步客户端，FastAPI的接口改成async def，并发能力能提升一个数量级。

另外，模型API本身有速率限制，并发太高会触发限流。我的做法是在调用层加一个信号量控制并发数，超过就排队等待。这样虽然单个请求可能慢一点，但整体服务稳定，不会雪崩。

6. 能力进阶与持续迭代：从能跑到好用

6.1 建立评估体系让优化有依据

项目能跑起来只是第一步，怎么知道改得好不好？必须有评估体系。我一般准备一批测试问题，每个问题有标准答案或参考答案，每次改动后跑一遍，看准确率变化。没有评估体系，优化就是盲人摸象，改了半天可能还退步了。

评估指标我关注三个：准确率、响应时间、单次成本。准确率靠人工标注的测试集，响应时间和成本靠代码自动统计。这三个指标要一起看，不能为了准确率无限堆模型和上下文，那样成本受不了。

6.2 从单轮到多轮的演进

单轮问答跑通后，自然会想支持多轮对话。多轮的核心是上下文管理，要把历史对话带上。但历史不能无限带，会超窗口还费钱。我的策略是保留最近N轮，更早的做摘要压缩。摘要用模型生成，把长对话压成几句话，既保留关键信息又控制长度。

多轮还有个坑是指代消解。用户说“它怎么样”，这个“它”指什么，模型不一定知道。解决办法是在提示词里把历史对话结构化，明确标出每轮的问答，让模型自己推断指代关系。实测下来，结构化之后指代准确率明显提升。

6.3 工具调用扩展能力边界

模型本身能力有限，但可以通过工具调用扩展。比如查实时数据、做计算、调外部接口，都可以封装成工具让模型调用。工具调用的关键是工具描述要清晰，模型靠描述判断什么时候调哪个工具。描述里要写清楚工具做什么、参数是什么、什么时候用。

我封装工具时遵循一个原则：一个工具只做一件事。不要做一个万能工具，参数一大堆，模型根本不知道怎么填。拆成多个小工具，每个职责单一，模型调用准确率高得多。工具调用的结果也要做容错，外部接口可能失败，失败时要给模型一个明确的错误信息，让它决定是重试还是换方案。

6.4 监控与日志：上线只是开始

服务上线后，监控和日志是生命线。我必看的几个指标：请求量、成功率、平均延迟、token消耗、错误分布。这些指标用简单的日志加统计就能实现，不用上复杂的监控系统。关键是每天看，发现异常及时处理。

日志里我会记录每次请求的问题、检索到的文档、模型返回、耗时和token数。出问题时能完整复现整个链路，排查效率高很多。日志要注意脱敏，用户隐私信息不能明文记录。保留周期一般设30天，太久了占空间，太短了不够排查。

7. 我在这条路上踩过的几个真实坑

最后分享几个我实际踩过的坑，都是文档里不会写但特别容易中招的。第一个坑是过度设计。刚开始做的时候，我总想着一步到位，上微服务、上消息队列、上向量数据库集群，结果光搭环境就花了两周，业务逻辑一行没写。后来全部推倒重来，用最简单的单机方案，两天就跑通了。先跑通再优化，这个顺序不能反。

第二个坑是忽视提示词的版本管理。我改提示词改得很随意，今天改一版明天改一版，结果效果时好时坏，还不知道是哪版导致的。后来我把提示词纳入版本控制，每次改动记录原因和效果，才理清楚。提示词就是代码，必须同等对待。

第三个坑是不做降级方案。有次模型API出故障，整个服务直接不可用。后来我加了降级逻辑，模型调不通时返回预设的兜底话术，至少服务不崩。任何依赖外部服务的系统，都要考虑依赖不可用时的表现。

第四个坑是忽略token计费的细节。不同模型的计费方式不一样，有的按输入输出分开算，有的有缓存折扣。我一开始没注意，预算算错了。后来我把每次调用的输入输出token都记下来，按实际计费规则算成本，才做到心里有数。

这些经验归结起来就一句话：AI工程的重点在工程，不在AI。模型能力是现成的，把它稳定、高效、低成本地交付出去，才是工程师的价值所在。从零搭建这套能力，不需要你懂反向传播，但需要你有扎实的工程思维和持续迭代的耐心。把上面这些环节一个个跑通，你就已经超过大部分只会调API的人了。