企业官网建设流程全解析

“ai-engineering-from-scratch”如果按字面理解，就是“从零开始做 AI 工程”。过去两年我面试、带过不少人，发现大多数准备进入这个方向的人，第一反应都是先买一本深度学习教材，或者把某个大模型的论文啃一遍。而真实业务里，AI 工程背负的是另一套命题：如何把一个不确定、会犯错、有时还一本正经胡说八道的大模型，变成一条稳定、可观测、成本可控的生产链路。

这篇文章相当于我这几年把“从零开始”重新定义之后的笔记。如果你刚接触 AI 应用开发，或者已经写了一些 demo 但总觉得落不了地，我建议你按“系统思维”而不是“模型原理”来读。我会讲清楚四个核心板块、一个可复现的内部知识库问答项目、四个常见大坑，以及一条务实的学习路径。

1. 先别急着写代码：AI 工程从零开始到底是“从哪开始”

1.1 为什么“AI 工程师”这个头衔让很多人困惑

我遇到过不少候选人，简历上写着“AI 工程师”，但每个人对这个词的理解都不一样。有人以为是算法工程师，有人以为是调 prompt 的，有人以为是训练模型的。这种混乱很正常，因为这个方向的确横跨了好几层：模型研究、应用开发、数据工程、MLOps、产品设计。

在工业环境里，绝大多数“AI 工程师”干的并不是研究新模型，而是用现成模型解决问题。这意味着你的日常工作更多是：写调用逻辑、处理输入输出、设计评估、建立反馈闭环、控制成本、排查偶然故障。我最早也陷入过“从零开始”的误区，觉得自己不把 Transformer 拆明白就不配动代码。后来才发现，那是研究者的路，不是工程者的路。工程者的“从零”是从“用户问题”开始的，不是从“反向传播”开始的。

1.2 第一个认知升级：你在构建系统，不是在操作魔法

如果你把大模型当成一个“输入一句话、输出一句话”的黑盒，那确实只能停留在 demo 水平。真正系统化的 AI 工程，是把模型当作一个能力组件，然后用数据、工作流、评估和部署把它包起来。模型负责“智能”的部分，工程负责“稳定”的部分。

举个例子：假设你要做一个文档问答机器人。模型可以帮你理解问题、生成答案，但“文档从哪来、怎么切片、怎么召回、怎么判断答案对错、用户点踩之后怎么回流改进”，这些都是模型之外的事。它们才是 AI 工程的主体。

这就像开餐厅。你不需要自己种菜，但需要挑菜、洗菜、配菜、控制火候、尝味道。而大模型这个食材，脾气还不稳定——今天咸了明天淡了。AI 工程的核心，就是把这份“不稳定”管理到你晚上能安心睡觉的程度。

2. 拆解 AI 工程的地基：模型、数据、编排、发布

2.1 模型能力层：不读论文也能用得好的底层理解

第一层是模型层。你至少需要对模型的基本接口有直觉：文本生成、向量嵌入、函数调用/工具调用、多模态输入。不需要懂完整数学，但需要知道它们各自适合什么场景。

• 文本生成：对话、总结、改写、推理。
• 向量嵌入：把一段文本变成一组数字，用来做相似度检索。
• 函数调用：让模型生成结构化的调用指令，把外部工具接进来。

还要理解 token 是什么。很多新手第一波成本超支，就是因为没搞懂 token 是如何换算的。一个汉字大约占 1~2 个 token，一段 2000 字的文档塞进上下文，可能一下子就耗掉几千 token。你面向用户做的问答系统，如果每次请求都把所有相关文档塞进去，费用会迅速膨胀。

模型选型上，最稳妥的原则是：先拿最强模型验证可行性，再往下换更便宜的模型。很多人一上来就用小参数模型，结果提示词怎么调都不对劲，误以为方案不行。先用最强的模型跑通效果，再逐步替换并做评估，这是更高效的路径。

2.2 数据与评估层：没有评估就没有“工程”

这一层是我认为的“从零开始”第一站，但也是最容易被跳过的。多数入门教程会教你调用 API，但几乎不会教你“怎么判断调用得好不好”。结果就是，你的系统像一团摸不清状态的迷雾。

一个工程化的 AI 应用，必须有一份属于自己的测试集。做法很朴素：把你（或真实用户）常问的问题收集起来，找出 30~50 个代表性的，人工写好期望答案，或者至少标注“哪些文档能回答这个问题”。每次改完提示词、更换模型、调整切片参数，都在这份测试集上跑一遍。

评估维度不一定是“正确率”，也可以拆成更适合业务的形式：

刚开始不用做得很重，哪怕 30 条问题的测试集都行。但一定要有。它存在的意义是让你知道，一次修改到底是“变好了”还是“感觉变好了”。

2.3 工作流与 Agent 编排层：用确定性代码包住不确定性模型

模型本身是不可预测的。同样的输入，温度调高一点，回答就不一样。所以在系统设计上，有一个原则我特别推荐：能写死的逻辑用代码写死，把模型留给真正需要“智能”的部分。

比如一个客服工单分类系统，“先查用户是不是 VIP”这种条件判断，用 if/else 就好，不需要让模型来猜。而“用户这句话是什么情绪”这种模糊判断，才适合交给模型。

这一层已经从简单的一次调用，演进到流程编排：连续多次调用、条件分支、循环、工具调用。你可以理解为：

• 普通 API 调用：模型回答一个问题。
• Prompt 链：前一个模型的输出作为后一个模型的输入。
• Agent：模型自己决定下一步调哪个工具，循环直到任务完成。

我见过很多人一上来就搭 Agent，热情很高，却没有把底层的数据和评估做好。结果模型在循环里自我发挥，一会儿调用工具，一会儿又绕回去，跑得热热闹闹，最后输出还是不靠谱。先做单轮、简单流程，等你对模型的行为模式有感觉了，再上复杂的 Agent。

2.4 部署与运营层：用最低成本把系统推向真实用户

AI 项目最怕的是永远停留在 notebook 里。部署层不是让你一开始就上 K8s 和复杂微服务，而是至少能把自己写的东西变成一个接口，让真实用户能用上。

一个很顺手的组合是 FastAPI + 云函数/轻量服务器。把模型服务包成一个函数，挂上 HTTP 接口，前面配个简单的前端页面或企业微信机器人，就足够第一轮内测了。

运营才是重点。我给自己定的最低标准是：每次请求都要有日志。记录请求时间、用户问题、上下文切片、模型输出、用户反馈。没有日志的系统，出问题只能靠猜，靠猜的工程是走不远的。

还要关注两个运营指标：延迟和成本。模型调用是有延迟的，用户等 3 秒还凑合，等 10 秒就会流失。成本更是要实时盯着，尤其是用了 Agent 循环的项目，一次多轮调用可能烧掉平时十倍的 token。

3. 从零开始的第一炮：搭一个内部知识库问答助手

3.1 为什么第一次实战选“内部工具”最稳

如果你想练手，不要一上来就做面向全网用户的 AI 产品。第一个项目的复杂度控制很重要，我强烈建议从“内部知识库问答”这类工具切入：

• 用户量小，即使体验不完美，也不会被大规模投诉。
• 数据范围可控，不需要处理开放互联网上乱七八糟的内容。
• 答案错误的影响相对可控，可以在迭代中修复。
• 反馈链路短，同事直接告诉你哪里不对。

我当时的选择是：把部门里的技术文档、会议纪要、常见问题整理出来，做一个内部问答机器人。这个项目麻雀虽小，五脏俱全，几乎覆盖了数据清洗、检索、生成、评估、部署的全过程，非常划算。

3.2 系统模块拆解与最小代码骨架

这个项目的完整模块大致是：文档接入、文本切片、向量化与检索、上下文组装、模型生成、后处理、反馈收集。我用一个极简的 Python 伪代码骨架来说明：

def answer(question: str, namespace: str = "team_docs") -> dict: # 1. 召回相关片段 chunks = retrieve(question, namespace=namespace, top_k=5) # 2. 组装上下文 context = "\n\n".join( f"[{c.doc_title}#{c.chunk_id}] {c.text}" for c in chunks ) # 3. 调用模型生成回答 prompt = build_qa_prompt(question, context) answer_text = call_llm(prompt) # 4. 后处理：提取引用、格式校验 cleaned = post_process(answer_text) # 5. 打日志 save_log(question=question, chunks=chunks, answer=cleaned) return {"answer": cleaned, "sources": [c.doc_title for c in chunks]}

这个骨架简单，但已经有工程味道了。你会发现，绝大部分代码不是“写提示词”，而是数据整理、检索、日志、异常处理。这也验证了前面说的：AI 工程不只是模型调用。

3.3 检索、切片与生成参数：这些细节决定成败

在这个项目里，我踩得最久的是“切片参数”。一开始我把整篇文档直接塞给模型，指望模型自己找答案，结果回答冗长、不准、还经常串内容。后来改成切片后，效果立刻提升了。

我常用的几个初始化参数，可以照着起步：

检索端还有个容易忽略的点：一定要保存切片的“来源信息”。我习惯在每条切片前面加[文档标题#片段编号]，模型回答时要求引用这些标识，最后代码把标识解析出来展示给用户。这样用户能点开原文核对，信任度会高很多。

3.4 30 条黄金问题与回归评估

这个项目上线前，我花了整整一个下午去收集真实问题。注意，是“真实问题”。我和同事说的很清楚：不要只问“你的系统能做啥”，你们平时怎么搜文档就怎么问。最终整理了 40 条问题，包括“如何申请远程权限”“上个月的实验结论是什么”“提交预算的流程”等。

然后我写了一个简单脚本，把所有问题跑一遍，输出答案。针对每条答案做三个判断：

1. 是否有明确答案，还是模棱两可。
2. 答案是否与检索到的文档一致。
3. 引用来源是否指向正确文档。

每次改完切片大小、提示词或换了模型，就跑一遍这 40 条，看差异。这个过程叫回归，不复杂，但它让我心里特别有底。很多改动在个例上看是好的，一跑回归就露馅了。比如“更口语化的提示词”可能让 3 条问题变得更好，却让另外 5 条问题开始乱发挥。

如果精力允许，还可以让另一个同事“盲评”两次输出的结果，避免我自己对自己写的提示词有偏爱。

3.5 上线后的三块仪表盘：成本、延迟、恶劣答案

系统上线后，我在后台一直盯着三类信息：

• 成本：每天 token 消耗、平均单次请求成本。
• 延迟：P50/P95 响应时间。P95 一旦超过 8 秒，就该看看是检索慢还是生成慢。
• 恶劣答案率：用户点踩的比例，以及每一条点踩记录对应的日志。

记得把每一条点踩都捞回来。我有个习惯，每周五下午挑几条被点踩的问题，手工重跑一遍，分析是哪一步出了问题——检索没召回、模型理解错、还是知识库本来就缺这个答案。绝大多数“AI 效果不好”的问题，排查到最后都不是模型的问题，而是数据或流程的问题。

4. 实战中我踩过的四个典型坑

4.1 提示词“看起来更准了”，离线分数却更低

有一段时间我非常沉迷优化提示词。改了措辞、加了限制条件、规定了输出格式，单看几个案例，感觉特别好。但当我跑完整版测试集时，分数反而下降了。后来我才明白两个原因：

第一，我那几个“看起来更好”的案例恰好是提示词里新规则的强相关场景。第二，新规则对其他问题造成了副作用。比如我加了一句“如果信息不足，直接回答不知道”，结果模型开始过度拒答，明明文档里有答案也不肯给出。

从那以后，我给自己立了规矩：提示词改动必须搭配一次完整回归，至少跑完所有黄金问题。没有整个测试集的对比，所谓的“感觉更准了”只是错觉。

4.2 上下文越长，回答反而越“水”

早期我以为把越多相关文档都塞进上下文，答案就会越全面。于是我把 top_k 调到 10，切片大小调到 800，结果回答开始泛泛而谈：“根据资料，这个流程大概包括多个步骤……” 没有任何细节。

后来看了很多模型行为分析的资料才发现一个现象：模型对长上下文的注意力并不是均匀分布的，它会高估前后内容、忽略中间的细节。也就是说，你塞了 10 篇文档进去，模型可能只重点看了第一段和最后一段。

解决办法不是继续加材料，而是做减法：只保留与问题最相关的 3~5 个切片；重排模块把相关性差的切片丢出去；在上下文里用醒目的分隔符标明每个切片的来源；必要时先让模型做一轮“哪些片段能回答问题”的筛序，再针对筛出的片段生成最终答案。

4.3 Agent 循环失控，一次隐形的高昂账单

另一个让我印象深刻的坑发生在做自动化数据分析 Agent 时。我设计了“写 SQL → 执行 → 发现出错 → 反思 → 重写 SQL”的循环。单看逻辑没问题，问题在于我没有设定步数上限。某个 SQL 语法错误反复触发反思，循环跑了 6 轮才退出，我以为是系统在研究策略，结果发现是 loop bug，费用已经烧了不小一笔。

从此以后，凡是涉及 Agent 循环，我都会提前做好这些护栏：

• max_iterations=5，超过直接终止并返回当前结论。
• 每一步消耗的 token 写入内存，累计超过预算就主动退出。
• 循环里必须有明确的“成功信号”，只要目标达成，立刻 break，不要让它兜圈子。
• 对敏感操作加人工审批，例如删除数据、发送消息等。

这个思路不仅是成本控制，也影响产品质量。无界循环的模型会生成大量冗余输出，反而浪费用户时间。

4.4 模型升个版本，系统突然“像换了个人”

我原以为模型升级只会变强，不会变差。结果有一次把某个模型的版本从旧版切到新版，评测分数确实高了，可生产环境出事了：新版模型不再按照固定结构输出引用标记，前端解析直接崩溃。

这提醒我一个关键点：模型升级不是纯收益，要当作一次风险管理事件。我在升级时会先做这几件事：

• 看一眼官方 release notes，重点关注“行为变化”和“弃用参数”。
• 在小流量（比如 5%）上灰度运行，对比旧版本的输出格式、错误率、延迟。
• 跑一遍完整回归测试集，不能只看总体分数，还要看高风险用例。

从那以后，我所有项目都会把“模型名称 + 版本号”写进配置文件的必填项，并在日志里记录。将来任何人看到这批日志，都能复现当时是哪个模型做出的这个回答。

5. 接着怎么走：一条更能落地的时间线

5.1 按阶段投入时间：先把“评估意识”练出来

如果让我重新给自己排学习计划，我会把时间切成三段：

• 第 1~2 周：练熟调用一个主流模型的 API。文本生成、向量嵌入、函数调用各写一遍，能跑通一个小工具。
• 第 3~6 周：做自己的评估集。哪怕只是 20 个问题，也要把“改代码 → 跑评估 → 看差异”的循环跑熟。
• 第 7~12 周：做一个内部小项目，覆盖从数据到部署的完整链路。

很多人的问题在于第 3~6 周跳过了。没有评估习惯，后面学什么都是空中楼阁，因为你根本不知道自己做得好不好。

5.2 从单 Agent 到多 Agent 协作，别贪早

多 Agent 协作是最近很火的概念，但我建议新手不要第一个项目就做。多 Agent 意味着更多的模型调用、更多的不确定性、更复杂的调试。就像一个只有两个人的小团队，本来沟通顺畅，你一上来就扩成十个部门，光扯皮就耗死了。

单 Agent 或简单的“主从式”结构（主管模型分配任务、工兵模型执行任务）就已经满足大部分需求。等技术成熟了，再把任务拆分、结果合并、冲突仲裁这些东西逐步加进去。核心判断标准是：拆分后是否比单 Agent 更稳定、更便宜、更好排查。如果三个答案都是否，就别拆。

5.3 工程可维护性：代码、配置、提示词、数据分开管理

这是容易被轻视但长期价值很高的习惯。我见过很多项目，提示词散落在不同文件里，有的在数据库里，有的写死在请求里，上线后改一次提示词要全局搜索三次。

我的做法很简单：

• 代码库只放代码。
• 提示词放在独立目录，每条提示词一个文件，有版本备注。
• 配置里记录模型名称、版本、温度参数。
• 测试集和黄金答案放在单独目录，与代码分离。

这样做的理由是，AI 项目的迭代速度很快，建模的人和改代码的人往往不是同一个。如果数据和提示词不能被“像代码一样提交、评审、回滚”，项目很快就会陷入混乱。

5.4 信息源与“热搜抗性”：怎么学习才不被带偏

行业里每天都有新工具、新框架、新热词，被热搜牵着走的话，半年下来你会发现学了一堆“名词”但没解决问题。

我有一套不变的信息输入策略：

• 官方文档和 release notes 永远第一优先，信息准确且具体。
• 每看到一个热词，第一反应不是收藏，而是问：它解决什么问题？我需要吗？可以用什么最小实验验证？
• 每周留一个固定时间做“技术雷达”，把这一周的新信息写进自己的笔记，每条至少写一句“和我当前项目的关系”。

这套方法帮我过滤掉大量噪音。真正重要的新东西，会在你解决问题时自然浮出来，主动权始终在自己手里。

回头看，“from scratch”这四个字差点把我骗进理论研究的深水区。好在后来我及时醒悟：AI 工程的从零开始，是从数据、评估和系统稳定性开始的。对刚入门的你，我只有一个建议：别跟模型较劲，先去定义“什么算答得好”。哪怕是一张纸上手写的 30 条问题，也比一个精心打磨但毫无尺度的提示词更值钱。