企业官网建设流程全解析

这些年我见过太多做AI项目的翻车现场：模型选型没问题，提示词写得也溜，结果一上线就崩——要么回答质量不稳定，要么成本直接失控，要么响应慢到用户骂人。

问题出在哪？出在很多人只会“用模型”，不会“做工程”。

所以我整理了这套ai-engineering-from-scratch的学习路线。它的目标很明确：让一个只写过增删改查的后端工程师，或者刚毕业的学生，在没有AI基础的情况下，一步步建立起完整的AI工程化能力。不是教你调一个API，而是教你如何把一个模型能力变成稳定、可控、可评估、可维护的产品功能。

这套路径我自己走了一遍，里面既有技术选型的思考，也有大量从实际项目里踩出来的坑。今天把整个思路和实操过程拆开讲清楚，希望能给正在转型或者准备入坑的朋友一条更顺的路。

1. 项目到底是什么：AI工程化不是“调库”，而是一整套系统能力

1.1 从“跑通模型”到“交付系统”

很多人对AI工程有误解，以为会用Python调一下OpenAI的接口、能把返回结果打印出来，就算入门了。但实际上，从“跑通一个demo”到“交付一个系统”，中间隔着的距离不比从零学到跑通demo短。

ai-engineering-from-scratch想解决的，就是这段距离。

这里有个很关键的认知转变：传统软件开发中，代码行为是可预期的——输入相同，输出几乎确定。但AI应用天然带有不确定性，同样的输入，今天返回的结果和明天可能不一样，甚至同一个请求重复两次结果都不一样。这种不确定性会让所有传统软件工程的方法论失效。你不能用普通单元测试去验证一个LLM的输出对不对，也不能用传统的监控指标去判断线上质量是否下降。

所以AI工程化的本质，是把“不确定性”包进一层工程化的壳里——通过上下文管理、检索增强、输出约束、评估体系、灰度机制，把不可控的模型行为变成可控的产品行为。

这套路线的标题里有两个关键词：ai-engineering和from-scratch。前者代表方向，是AI工程；后者代表路径，是从零开始不打折扣地建立地基。它不是一份“三天精通大模型”的速成课，而是一张按依赖关系排好的学习地图。

1.2 为什么这个能力现在值得投入

我判断一个技术方向值不值得学，就一个标准：它能不能帮你解决“真实世界中持续存在、且愿意付费”的问题。

AI工程恰好满足。现在企业落地AI的主要瓶颈已经不再是模型能力不够，而是没人能把模型能力稳定地接到业务流程里。你可以观察到，招聘市场上“AI应用工程师”“LLM应用工程师”这类岗位越来越多，薪资也高于同级别后端。但真正能胜任的人很少，因为大多数候选人只会写提示词，没有工程化的基本功。

另外，从技术演进角度看，工具链越来越成熟：LangChain、LlamaIndex、向量数据库、Agent框架层出不穷。但框架越成熟，越需要人理解底层原理。框架解决的是“通用的80%”，剩下那20%的定制需求，永远需要你从原理层去处理。没有from-scratch的底子，遇到框架解决不了的问题，就只能干瞪眼。

1.3 谁适合走这条路

我的结论比较明确，这套路线最适合两类人：

• 一类是有后端开发经验、想转型AI应用方向的工程师。你懂API、懂数据库、懂系统设计，只需要补齐大模型原理、检索和评估层面的知识，就能快速上手。
• 另一类是计算机相关专业的学生，趁在校期间从零系统化地建立知识体系，毕业时直接具备AI工程岗位的实战能力。

老实说，它不适合那种想“零基础从文科转码”的读者。我坚持认为，写提示词可以不写代码，但做AI工程必须会写代码。如果连JSON都处理不明白、连HTTP异步请求都没理解，工程化这条路会走得非常痛苦。所以前置条件只有一个：至少能熟练使用Python，理解基本的数据结构。

2. 知识体系设计：一张按依赖关系排好的学习地图

2.1 第一层地基：Python工程能力与数据结构

很多学习路线一上来就讲Transformer，我认为这是错的。跳过了地基直接上模型，后面会频繁返工。

我在这套路线里，第一层安排的是Python工程化基本功。不是语法教程，而是“用Python组织一个真实项目的能力”：虚拟环境管理、类型注解、异常处理、日志规范、配置文件管理、单元测试。这些内容在普通Python教程里不会成体系地出现，但它们是所有后续内容的载体。

这里多说一句，数据结构的优先级被我刻意调低了。AI工程日常面对的主要是列表、字典和JSON嵌套结构，最复杂的也就是一个对象数组的筛选排序。真正影响开发效率的不是数据结构算法题刷得多深，而是你是否能清晰地把嵌套的JSON结构转化为业务实体。所以这一层的重点，我用一句话概：代码写出来能让人看懂，能保持改动三个月不出问题。

2.2 第二层地基：模型原理与调用心智模型

第二层进入大模型基础。这里我的建议是：不要一上来读Attention Is All You Need的原始论文，也不要一上来研究微调。先建立“调用者视角”的心智模型。

你要理解这几个问题的答案：

• Token是什么？为什么上下文长度按Token算？
• 温度（temperature）和top-p分别控制什么？调高调低有什么区别？
• 模型为什么会产生“幻觉”？它的本质是概率生成还是事实检索？
• 为什么同样的提示词，模型表现会时好时坏？

这几个问题理解透了，使用模型时的很多困惑就自然解开了。比如你知道了温度影响的是采样分布的随机性，就能明白为什么客服场景要把温度调低甚至调为0，而创意写作场景则需要更高温度。

在技术实现上，我会要求大家手写一个最基本的调用封装：包含超时控制、重试逻辑、日志记录。用代码库也好，直接requests调用也罢，重点不是“会调”，而是“稳定地调”。很多人第一次做AI项目遇到的问题——线上偶发超时导致整个流程失败、重试导致重复计费——就是在这一层没学好。

2.3 第三层核心：上下文工程、RAG与向量检索

这是整套路线中工程含量最高的一部分，也是ai-engineering-from-scratch的精华所在。

先说上下文工程。上下文是模型回答质量的决定性因素。你需要学会：如何在有限的上下文窗口内放入最有价值的参考信息；如何设计system prompt来固定模型的行为边界；如何利用few-shot examples来引导输出格式。这里有一个我反复强调的原则：不要把模型当作数据库，要把模型当作推理器。知识应该存在你的业务系统里，模型只负责根据给定知识做推理。

然后是RAG（检索增强生成）。RAG是目前落地最广泛的AI应用模式，它解决了大模型“知识陈旧”和“领域不相关”的核心问题。你需要理解它的完整链路：

1. 文档加载与切分——切分粒度直接决定检索质量；
2. Embedding向量化——选择什么模型、维度多少、如何批量处理；
3. 向量存储与检索——Milvus、Qdrant还是传统库pgvector；
4. 重排序（rerank）——向量相似度检索的结果往往不够精确，需要重排序模型二次过滤；
5. 送入大模型生成——如何把检索结果组织成模型友好的上下文格式。

很多人不重视切分这一步，认为就是按字符切分而已。实际上切分策略决定了检索的上限。你按固定长度硬切，很容易把一个完整的语义单元截成两段。我一般建议优先按文档结构切分：Markdown标题、段落、代码块、表格，尽可能保持语义完整性，再结合重叠窗口避免切分断点处的信息丢失。

2.4 第四层进阶：Agent、工具调用与复杂任务编排

Agent是目前AI工程里最热也最容易被神话的概念。我一向的观点是：先学会不用Agent解决问题，再考虑用Agent。

这一层要掌握的核心技术是工具调用（function calling / tool use）。它本质上不是让模型自由发挥，而是给模型一套明确的“工具箱”，让它学会在合适的时机选择工具并填入参数。这个过程中，模型的角色从“直接生成答案”变成“编排计划并调工具”。工程上你需要维护好：

• 工具的描述信息（模型依赖描述来选工具）；
• 参数Schema的准确性（模型按Schema生成JSON参数，Schema错了，后续全部崩掉）；
• 工具执行结果的返回格式（模型需要看到结构化结果才能继续决策）；
• 循环调用的终止条件（避免死循环烧钱）。

你可以自己从零实现一个极简的Agent循环，这比直接用现成框架更能理解本质。等理解了循环机制，再上LangChain、CrewAI、MetaGPT这些框架，你就能读懂它们的源码，也才能根据业务场景改造它们。

3. 从零到一：手写一个AI知识助手全流程

3.1 项目选题与需求拆解

理论说再多都不如做一个完整项目。我在路线里安排了一个压轴实战：从零搭建一个私域知识问答助手。假设你是一家服务商，手里有几百份产品文档、售后FAQ和工单记录，需要做一个人人可用的智能客服。

先说需求拆解。做这个项目前，先把“能做什么”定义清楚：

• 用户输入一个问题，返回准确的答案；
• 答案需要给出参考来源，方便运营人员复核；
• 针对“不知道”的问题，明确回复不知道，而不是硬编；
• 支持多轮追问（先问“你们支持哪些退款方式”，再追问“哪个到账最快”）。

这四个需求看似简单，但每个都对应一个工程决策。引用来源需要检索层返回document id并映射到原文；拒绝硬编需要阈值判断和提示词约束；多轮追问需要会话记忆管理。

3.2 技术选型与架构设计

我的选型原则很简单：先用最朴素的组件把链路跑通，再替换复杂组件。很多人一上来就上全套分布式、微服务、Kafka，这种架构用在几十个QPS的场景上就是灾难。我从不用技术复杂度作为简历亮点，我只用“恰到好处的工程复杂度”。

这个项目的初始版本，我会选择：

• 后端：Python FastAPI，异步支持好，写起来直观；
• 向量库：先上pgvector。为什么不用Milvus？因为项目初期数据量在十万级以内，PostgreSQL自带的pgvector够用了，还能少维护一个中间件。等数据量上来了，再平滑迁移到专门的向量库；
• Embedding模型：选择一个本地部署的国产开源模型（比如BGE系列），避免每次调用外部API的延迟和成本；
• LLM：走通用大模型API，第一版快速验证。
• 切分：使用基于结构的PDF/HTML解析，先按标题层级切块，再补充段落边界。

整体架构是一个简单的三层结构：数据预处理层（离线）、查询服务层（在线）、评估监控层。这个架构没有花哨之处，但每一层都清晰可扩展。

3.3 核心实现步骤与代码要点

我挑三个阶段的关键实现细节来讲。

第一阶段是离线索引构建。核心代码如下：

# 文档结构切分示例 def split_document_by_structure(doc_elements): chunks = [] current_section_title = None current_buffer = [] for element in doc_elements: if element['type'] == 'heading': # 遇到新的标题，把buffer中积累的内容作为一个chunk输出 if current_buffer: chunks.append({ 'content': '\n'.join(current_buffer), 'meta': {'section': current_section_title} }) current_buffer = [] current_section_title = element['text'] else: current_buffer.append(element['text']) # 处理最后的buffer if current_buffer: chunks.append({ 'content': '\n'.join(current_buffer), 'meta': {'section': current_section_title} }) return chunks

这里最关键的是meta信息保留。很多教程只存content，不存标题和路径，导致检索到结果后用户只看到一段文字，却不知道来自哪个文档。我习惯在每个chunk里保留“文档名+章节路径+原文ID”，方便后续引用溯源。

第二阶段是查询链路。流程是：query改写 → 向量检索（top 20） → 重排序（top 5） → 携带上下文调用LLM → 解析输出并返回引用。

# 检索增强生成的核心链路 async def answer_question(query: str, history: list[dict], session_id: str): # 1. 改写问题：将带指代的多轮问题转成独立问题 rewritten_query = await rewrite_with_history(query, history) # 2. 向量检索，取 top 20 query_embedding = embed_model.encode(rewritten_query) candidates = vector_store.search(query_embedding, top_k=20) # 3. 重排序，取 top 5 reranked = rerank_model.rerank(rewritten_query, candidates, top_k=5) # 4. 组装上下文并调用 LLM context = build_context(reranked) prompt = build_prompt(context, query, history) llm_response = await llm_client.call(prompt) # 5. 引用来源映射 sources = [format_quote(r) for r in reranked] return {"answer": llm_response, "sources": sources}

第三阶段是会话管理。这里我踩过一个坑：把完整的聊天历史全部塞进上下文，导致Token消耗爆炸式增长。正确做法是维护一个滑动窗口，只保留最近4-6轮对话，并对每轮历史做摘要压缩，保证既不丢失关键信息，也不撑爆上下文。

3.4 上线前的评估与迭代机制

工程做得再好，没有评估体系就是盲飞。我强烈建议每个AI项目上线前，准备至少100条覆盖主要场景的评测集，并人工标注“标准答案”或“期望答案要点”。

评测集按难度分层：

• 简单题：答案就在原文中，直接命中；
• 中难题：需要跨段落拼接信息，或者需要结合多个文档；
• 对抗题：提问方式模糊，或故意用错误说法引导，期望模型拒绝回答。

评测指标不是只看一个，而是组合看：

• 检索命中率：前5个结果是否包含正确答案所在片段；
• 生成相关性：模型回答和问题的相关度；
• 引用准确率：模型引用的来源是否真的支撑其答案；
• 拒绝率：对抗题中正确拒绝的比例。

有了这套评测体系，每次改动Prompt、调整切分参数、更换Embedding模型，都能用一套固定的测试集对比分数。改动的效果不再靠“感觉还行”，而是通过数字判断。

4. 实操中最容易踩的坑与排障思路

4.1 检索质量差：切分和Embedding的锅各占一半

做RAG最常见的抱怨是“检索结果不对”。大部分情况下，问题根源不在向量检索本身，而在上游的两件事：切分策略和Embedding模型选择。

我做过一个很直观的对比实验：同一批文档，用固定长度500字符切分，检索精确率只有56%；改用结构切分（先按标题再按段落），精确率提升到81%。原因很简单，固定长度切分会把一个完整的逻辑单元劈成两截，向量化后两段各自的语义都残缺不全。多做这一步改造，成本几乎为零，但效果却天差地别。

Embedding模型同样重要。通用Embedding模型在专业领域效果会明显下降。解决方式是在专业数据上微调Embedding模型，或者至少做一个领域词汇表的扩充。如果数据量不够微调，退而求其次，用更好的商用Embedding API也能显著提升。

4.2 模型“一本正经胡说八道”：阈值与证据约束

幻觉是LLM的固有属性，你无法彻底消灭它，但可以工程化地压制它。我在项目里做了三道防线：

第一道是检索侧的相似度阈值过滤。当用户提问和所有检索结果的相似度都低于某个阈值（比如0.35），直接判定为“知识库覆盖不到”，返回兜底话术，不进入LLM生成环节。这道防线挡住大量“明知不知道还硬答”的情况。

第二道是Prompt约束，明确要求模型只能基于提供的参考材料回答，当材料不充分时明确回复“根据现有文档无法回答”。加上这句话，比不加这句话，能显著减少编造的情况。

第三道是输出后校验，用一个小模型或规则模型检查回答中是否包含关键实体与参考资料的一致性。比如用户问“退款到账时间”，如果模型回答里没有出现任何与到账时间相关的数字或日期，就标记为低置信度，让审核人工介入。这道防线成本高一些，适合高价值场景。

4.3 成本失控：Token预算要精细到每轮对话

很多项目第一版上线，惊喜地发现效果不错，然后下个月账单来了，傻眼了。成本失控的罪魁祸首往往是上下文填充太猛——把大段历史、大段知识一股脑塞进去，每轮调用都消耗大量Token，而其中大多数都是冗余内容。

我用的成本控制手段有：

• 检索结果严格控制数量，经过重排序后只保留最相关的3-5个片段，每个片段不超过800字；
• 历史会话采用摘要化压缩，每隔几轮把前面的内容总结成50字的要点，而不是保留原文；
• 区分“复杂推理”和“简单查询”两种路径。简单查询用成本低的小模型，只有复杂推理才走大模型；
• 设置每日Token消耗告警，超过预算阈值自动降级到只返回检索原文。

有一条经验可以分享：Cost per useful answer（每次有效回答的成本），比单次调用成本更适合作为优化指标。优化时你不是要压单次成本，而是要提高回答准确率——准确率高，用户不用反复追问，总成本反而下降。

4.4 接口稳定性：超时、限流与降级策略

最后一个坑来自接口层。大模型API的延迟不稳定是常态，高峰期可能从500ms飙到5秒。如果线上不做超时控制和降级策略，一次偶发超时就能让用户感受“系统不行”。

我的工程处理方式是：所有LLM调用统一走一个异步封装，设置合理的超时时间（通常读3秒、写5秒）。超时后自动降级：优先返回检索到的原文列表让用户自己找答案，不让用户干等。重试机制要加上“指数退避+抖动”，避免服务恢复瞬间所有请求同时涌进来。注意一个细节：重试时如果请求已进入模型计算，LLM调用无法保证幂等，重试可能导致重复计费。因此重试标志和日志必须配套，区分“网络层失败可重试”和“业务层已抵达不可重试”。

5. 学习建议与路线图的补充分享

5.1 实操优先级：先做完整闭环，再优化细节

我的核心建议就一句：在学的第一周，先把一个最简单的“读文档 → 检索 → 回答”闭环跑通。不用上重排序，不用做复杂的切分，甚至Embedding都可以先用通用模型。跑通的这个闭环给你一个完整的地图，之后所有优化都是在给地图打补丁。

很多人学AI工程失败的原因，是一头扎进去研究Prompt技巧、研究各种框架API，学了两个月还在“看完最后一个教程才开始动手”。AI工程和其他工程一样，动手前你只能理解20%的知识，剩下的80%是在解决问题中学会的。从第一个星期就开始做项目，从第一个月起就维护一个自己的评测集，这样你会比那些一路看书的人快得多。

5.2 建立自己的最小复盘机制

我在整个from-scratch路线的最后，加了一个容易被忽视的环节：建立自己的复盘模板。每做完一个功能或修完一个Bug，回答三个问题——根因是什么？下次怎么提前发现？这个经验能否沉淀成脚本或配置？

这三个问题看着简单，但持续执行下来，你会发现自己的成长速度远超身边人。因为大多数人的经验是零散的，而工程能力恰恰来自把零散经验组织成可复用的方法论。我从2019年开始带团队，带过几十名工程师，凡是成长快的，无一例外都愿意做这种“额外”的总结工作。

5.3 最后说一个心态上的建议

如果你真的想把AI工程这条路走通，请接受一件事：你永远有学不完的新东西。模型在变、框架在变、最佳实践在变。这套ai-engineering-from-scratch提供的不是一份一劳永逸的答案，而是一种应对变化的底层能力——理解原理、快速验证、持续复盘。有了这三板斧，再复杂的新技术出来，你也能在短时间内把它工程化落地。

先把第一个闭环跑起来吧，哪怕它非常简陋。跑起来之后，你会发现接下来的每一条学习路径都有明确的方向了。