企业官网建设流程全解析

1. “AI 工程”究竟在工程什么：一个从业者的重新定义

1.1 先放下一个执念：AI 工程不等于训练模型

很多人一听到“AI 工程”，第一反应是机器学习、深度学习、炼丹调参。这个印象在五年前是对的，在今天已经严重过时。自从基础大模型把“从零训练一个能理解语言的模型”这件事变成了一件普通开发者不需要再碰的事之后，AI 工程的重心已经从“造模型”转移到了“用模型造产品”。

我自己就是从零开始走这条路的。最开始我以为要先把 Transformer 结构吃透、把反向传播手写一遍才能动手，结果花了两周看理论，代码一行没写。后来调整策略：先学会调 API、先做出一个能跑的聊天机器人，再回头补原理。实践一上手，很多理论名词突然就通了。所以我建议所有从零起步的人，别把理论学习放在动手之前，两者要并行，但动手永远优先。

那 AI 工程到底在做什么？我现在的理解是：把一个大模型（或者多个大模型）接入真实的业务场景，让它在约束条件下稳定、可控、可评估地完成特定任务。这里面涉及提示词设计、上下文组织、工具调用、数据回流、效果评测、成本优化、错误兜底，是一整套系统工程，而不仅仅是“发个请求拿个结果”。

这也是我想写这篇文章的原因。市面上的教程要么太偏理论，上来就是注意力机制；要么太偏工具，教你怎么装框架却不说为什么。我想用自己从零到一的完整经历，把 AI 工程这个命题拆开，讲清楚到底该学什么、怎么练、坑在哪。这篇文章适合那些已经决定投身 AI 应用开发，但不清楚第一步该往哪迈的人。

1.2 从零起步需要的能力地图

我把 AI 工程需要的能力拆成了六块，按重要程度和上手顺序排列：

这六块不是并列的，而是层层递进。前三块是地基，第四块是多数文档类应用的核心，第五块是当前最有想象力的方向，第六块则是决定你能不能长期维护一个 AI 产品的关键。我见过太多人花大力气做了一个 Agent，却完全答不上来“它比上一个版本好在哪里”，这就是没做评测的后果。

对零基础的人，我的建议是不要一上来就追 Agent、追多智能体协作。先把地基打牢，把一次 API 调用做到极致，再谈编排。后面我会详细讲我自己的练手路径，每一步都附上我踩过的坑和验证过有效的做法，你可以直接照着走。

2. 我的从零练手路径：从第一个 API 调用到能上线的产品雏形

2.1 起步动作：先把一个接口用熟、用透

我给自己定的第一个目标非常朴素：只用一个模型接口，做出五个不同的小应用。这一阶段我完全不碰框架，不用任何大模型应用层封装，就用最原始的 HTTP 调用写。原因很简单，封装库帮你省掉的代码，恰恰是理解原理的最佳教材。

从最简单的开始，先是一个聊天补全接口。我建议你做这几件事来练手感：

1. 写一个脚本，连续发十条不同风格的请求，观察 temperature、max_tokens 这些参数对输出的影响；
2. 把流式输出改成非流式，对比响应时间和体感差异；
3. 在 system prompt 里放一段很长的背景说明，测试模型对指令的遵循程度；
4. 给自己建一个“变量控制清单”，每次只改一个参数，记录输出变化。

这一步看起来幼稚，但价值非常大。很多人在这一步之前就急着上 Agent、上 RAG，结果遇到输出不稳定、幻觉百出，根本不知道是提示词的问题、参数的问题还是上下文的问题。变量控制的能力，是 AI 工程调试的基础功。

另外我要推荐一个很实用的习惯：从第一天起就用“结构化输出”。让模型返回 JSON，而不是自由文本。你可以在 system prompt 里直接声明输出格式，再用代码做一层校验，解析失败就重试或降级。这会让你的应用稳定性上一个台阶。很多新手直接拿自由文本去解析，一个标点符号差异就崩了，这都是可以提前避开的。

2.2 五个由易到难的练手项目，我全部做过一遍

我建议的练手项目顺序是这样的，每一个都有明确的目的，做完之后能力是叠加的：

第一个，做一个人设固定的聊天助手。目的就是练提示词和参数控制。我给助手设计了角色、语气规则、知识边界，然后反复测试它会不会“出戏”。这个项目让我真正理解了 system prompt 的约束力。测试过程中我发现，光说“你是客服”是不够的，必须把“遇到无法回答的问题时如何回应”也写清楚，否则模型会硬答。

第二个，做一个文档问答工具。把几本书切成片段，做向量检索，把命中片段塞进上下文，让模型基于片段回答。这个项目练的是 RAG 的完整链路，切分策略、检索质量、答案组织都会暴露出来。做完之后你会对“上下文才是关键”有切身体会——模型表现得聪明还是笨，很大程度上取决于你塞给它的材料质量。

第三个，做一个信息抽取管线。给模型一堆非结构化的邮件或聊天记录，让它输出结构化的字段，比如客户名称、诉求类型、紧急程度。这个项目练的是结构化输出和错误处理，你会开始认真设计 JSON schema 和校验逻辑，也会发现少样本示例对输出质量的影响有多大。

第四个，做一个带工具调用的 Agent。让模型能查天气、能算数学、能查数据库，核心是把“模型决策调哪个工具”这件事做对。这个项目练的是函数调用和循环控制，难度上一个台阶，但做完之后对 Agent 的理解会完全不同。

第五个，给自己前面做的某个应用写一套评测脚本。定义一组测试用例，每次改完代码自动跑一遍，对比输出质量。这个项目练的是评估思维，是 AI 工程里最值钱也最少人愿意做的事。

我做完这五个项目大概花了两个月，每天晚上两三个小时。进度不算快，但每一步都有实打实的产出。关键是每个项目都要留文档，记录你改了什么、效果如何、为什么这样改，这份记录后来成了我自己的“经验库”。

2.3 从第一天起就建评测集，这是很多人漏掉的关键

我在做完第一个聊天助手的时候就发现一个问题：每次改完提示词，感觉输出“好像更好了一些”，但过两天又觉得不对劲，说不清哪里退步了。后来我才意识到，没有评测集的改进全是幻觉。

评测集的建设其实不复杂：拿 30 到 50 个有代表性的输入，为每个输入写好期望的输出标准，然后每次改动之后跑一遍，人工打分。打分维度可以很简单，比如准确性、完整性、格式符合度，每项 1 到 5 分。不需要什么高级工具，一个表格就够。

等你有了一批真实用户输入之后，评测集要持续扩充，把线上出过问题的样本都加进去。这就是回归测试的思路，和传统软件开发里的单元测试是一个道理。我后来把所有线上翻车案例都沉淀成了评测条目，每次新版本上线前先跑评测集，低于某个分数就不允许发布。这个机制帮我避免了很多次灾难性上线。

3. 核心技能拆开看：提示词、Agent 与 RAG 的真实用法

3.1 提示词工程：本质是结构化沟通，不是咒语

网上关于提示词的文章很多，但大部分把这件事讲玄了。我的理解非常朴素：提示词工程就是把你对任务的全部要求，用模型最容易遵循的方式表达出来。它像跟一个极其聪明但容易误解你意图的新同事沟通，关键是消除歧义。

我自己的提示词结构一般是这样：先定义角色和任务目标，再给出约束条件和输出格式，接着给少量高质量示例，最后说明边界情况怎么处理。这套结构几乎适用于所有任务。示例的作用往往被低估，同一段指令配不配示例，效果能差出一大截。

还有一个容易被忽略的点：提示词也要版本化。我见过很多团队，提示词直接写在代码里，每次改动都靠复制粘贴保存，根本说不清线上跑的是哪一版。我的习惯是把提示词当作独立的版本化资产，和代码一起提交，每次改动都带着变更说明。这样当线上效果波动时，你能快速定位是代码问题还是提示词问题。

我强烈建议你把提示词当代码来管理。写一段好的提示词有时比写一段代码更费力，它的调试过程也更依赖“实验和观察”。没有版本控制，你就是在用感觉做工程。

3.2 Agent 设计：把大模型装进决策循环

Agent 是当前 AI 工程最热的方向，但也是最容易被过度包装的概念。剥掉所有花哨的说法，Agent 的本质就是一个循环：模型根据当前状态决定下一步动作，执行动作，观察结果，再决定下一步，直到任务完成或者达到某个终止条件。

我做的第一个 Agent 特别简单，只挂了两个工具：一个查询接口，一个计算函数。模型每轮输出两个东西，一是思考过程，二是要调用的工具和参数。我拿到之后执行工具，把结果拼回对话历史，继续下一轮。这个循环看起来简单，但真正写起来全是细节：工具返回结果太长怎么办、模型连续调用同一个工具怎么办、某一步调用失败要不要重试、最多跑多少轮就强制停止。

这些都是我在实际写代码时反复调整过的控制点。举个例子，工具返回结果我一开始全量塞回上下文，一次数据库查询返回几百行记录，模型直接蒙了，决策质量急剧下降。后来我改成只返回前十条加一个总数字段，效果立刻稳定。Agent 的工程含量就在这里——不是模型有多聪明，而是你为模型设计的环境有多清晰。

还有一个原则：永远设最大轮数。没有轮数上限的 Agent 就是一颗定时炸弹，账单和延迟都会失控。我建议所有做 Agent 的人，先把“最大轮数、超时、重试策略、异常兜底”这四个参数想清楚，再谈智能不智能。

3.3 RAG 的适用边界与落地细节

RAG 是让大模型基于私有知识回答问题的标准方案，但很多人对它有不切实际的期待。RAG 不是万能的，它解决的是“模型不知道的信息怎么让它知道”的问题，而且效果上限取决于检索质量，不是模型能力。

切分策略是第一个坑。PDF 按固定字数硬切，经常把一句话从中间劈开，检索召回质量直线下降。我后来改用按标题层级和段落边界切分，每个片段尽量保持语义完整，重叠区间控制在少量字符，效果立刻改善。第二个坑是检索只做向量相似度。向量检索对同义改写很友好，但对精确关键词匹配反而敏感度不足，最好的做法是向量检索和关键词检索做混合召回，再用重排模型把结果重新排序。

还有一点我必须强调：RAG 的答案必须可溯源。在输出里附上引用的原文片段，让用户能自己核对。这不仅是产品体验问题，也是信任问题。我做文档问答工具时强制要求每句话都能对应到来源，否则视为不合格。这一步让我避开了很多幻觉投诉。

适用边界方面，如果知识库更新频率很高、内容很短、或者问题对时效性极其敏感，RAG 可能要配合其他机制。RAG 适合的是“静态知识为主、答案需要依据”的场景。别指望它解决一切问题。

4. 从零到一踩过的五个大坑，每一个都让我返过工

4.1 坑一：把模型当成数据库用

我最早的文档问答工具，为了实现快，直接把用户的问题抛给模型，指望它凭“记忆”回答。结果模型一本正经地给出了好几段看起来毫无破绽、实际全是编造的内容。那一刻我意识到，模型是概率性的文本生成器，不是数据库。数据库里没有的记录会明确说不存在，模型没有的记录会帮你编一个。

这个坑的解法就是引入 RAG，并且强制答案溯源。同时我学到一个经验：永远不要让模型回答它没有足够上下文支撑的问题。当检索结果为空或者相关性太低时，直接告诉用户“没有找到相关资料”，而不是让模型硬答。

这个经验后来扩展成了我所有项目的通用原则：不确定就承认不确定。这比让模型硬编一个答案体面得多，也安全得多。

4.2 坑二：技术栈先堆满，需求还没想清楚

这是我早期最蠢的一次返工。我当时想做一个通用问答平台，还没想清楚用户是谁、要解决什么问题，就先把向量数据库、容器化部署、监控告警全部上了。结果光环境搭建就花了两周，核心功能一个字没写。

后来我复盘，问题出在把技术选型当成了项目进度。正确顺序应该是：先用最笨的方式把核心流程跑通，验证需求真实存在，再逐步替换掉不合适的组件。一个只有几十个用户的产品，根本不需要一开始就上分布式向量库。轻量级方案完全够用。

从那以后我给自己定了一条规矩：任何组件要在“没有它已经跑不动了”的时候才引入。这条规矩让我少做了大量无用功。

4.3 坑三：没有评测就上线，改来改去全凭感觉

这个坑我前面提过，但值得单独再说一次。没有评测集的迭代，本质上是随机游走。你今天把提示词改了一版，觉得输出变好了，发布上线；三天后用户反馈变差了，你又改回去，来回折腾，浪费的不仅是时间，还有用户的耐心。

我现在对任何 AI 功能的改动都坚持三条铁律：先写评测用例，再改代码或提示词，最后跑评测集对比分数。分数没有提升就回滚。这套流程让我从“感觉主义”变成了“证据主义”，迭代质量和速度反而都上去了。

可能有人觉得 30 到 50 条评测用例太少，代表性不够。但起步阶段，哪怕只有十条用例，也比零条强得多。评测集的价值在于“可对比”，不在于“完备”。你先有一个基线，再逐步扩充，这比追求一步到位实际得多。

4.4 坑四：上下文管理与成本控制双双失控

AI 应用的账单是随着上下文膨胀线性增长的。我做过一个多轮对话产品，早期为了保留完整对话历史，每一轮都把从头到当前的全部消息发给模型。对话超过二十轮时，单次请求的 token 数已经翻了好几倍，响应延迟和成本一起飙升。

解法是分层管理上下文：最近的对话完整保留，较早的对话做摘要压缩，摘要再超长就继续摘要。还有一个经验是给每个请求设置 token 上限，超了就自动触发压缩策略。成本控制不是上线后才考虑的，而是一开始就要设计进架构里。

我见过很多团队在产品上线后才发现成本失控，然后急急忙忙加缓存、加压缩，改得手忙脚乱。其实这些在设计阶段花半天就能规划好。上下文管理不是优化项，是必选项。

4.5 坑五：一个人闷头造轮子

从零学 AI 工程，最大的风险不是技术难，而是闭门造车。我有很长一段时间自己闷头搭框架，写了大量没人用过的封装。后来我把代码给一个做后端的朋友看，他一眼就指出我的错误处理设计有问题——模型输出校验失败时，我的代码会崩溃而不是优雅降级。

从那以后我养成了一个习惯：每完成一个模块，就找至少一个人做代码评审或者产品体验。AI 工程里很多问题，比如延迟体感、输出质量、边界情况，自己测一百遍也发现不了，别人用一次就能暴露。找到愿意当“小白鼠”的朋友，比任何教程都重要。

如果你身边没有懂技术的朋友，那就去社区、去论坛。把你的项目丢出去，让陌生人用。他们的反馈可能很糙，但每一条都是真实的。这些真实反馈比你自己脑补的完美体验有价值得多。

5. 给同样从零开始的你：三个月到半年的路线图参考

5.1 第一个月：练 API 手感，打磨提示词基本功

第一个月的目标只有一个：把一次模型调用做到自己能掌控的程度。这阶段不要碰 Agent，不要碰复杂框架。找一个大模型 API，写脚本，跑通非流式和流式两种模式，掌握参数含义，然后完成一个带人设的聊天助手。

同时开始积累提示词模板，什么场景用什么结构，整理成自己的文档。第一月底的验收标准是：你能在三个不同任务上，稳定地让模型输出符合格式要求的结果，并且说得清每个参数为什么这样设置。

这个月最容易犯的错误是贪多。看到别人做 Agent 很酷，就想跳过基本功直接上。我劝你忍一忍，地基不牢，后面的每一层都会晃。

5.2 第二到三个月：做带状态的应用，开始碰 Agent

第二个月做文档问答工具，完整走一遍 RAG 的链路。这一步你会把切分、检索、重排、答案组织、溯源全部过一遍，对“上下文决定上限”有深刻理解。第三个月做带工具调用的 Agent，重点不是功能多，而是把循环、轮数限制、错误恢复这些控制逻辑写好。

这两个月你会不停地遇到“为什么输出不稳定”的问题。我的建议是：把所有不稳定案例记下来，归因到提示词、检索、参数或代码，形成自己的排查清单。这份清单的价值会随着你的项目越来越多而指数级上升。

做文档问答工具时，别急着换各种花哨的向量数据库。先把切分和检索调明白，你会发现大部分效果问题根本不在数据库层面，而在数据准备层面。这个认知能帮你省下一大笔迁移成本。

5.3 第四个月起：找一个真实场景，做给真人用

三个月之后，你的基本功基本够了，这时候最该做的不是继续学新技术，而是找一个真实的小场景，做一个有真人用户的产品。哪怕是给朋友做一个会议纪要工具，给团队做一个知识库问答，都行。真实用户会带给你教程里永远学不到的东西：真实的数据分布、真实的边界情况、真实的反馈循环。

从零开始做这个产品时，记得用上前面说的所有经验：先建评测集，再写代码；先跑通核心流程，再考虑扩展；每次改动都做对比评测。我认为 AI 工程从来不缺技术，缺的是把一个 AI 功能做成一个可靠产品的判断力，而这种判断力只能从真实项目里长出来。

6. 最后几句实在话

写到这里，我回头看自己从零到一走过的这段路，最大的体会是：AI 工程的门槛不在数学，不在框架，而在“愿不愿意用工程的纪律去对待一个本身就不稳定的技术”。

我在实际踩坑中形成的几个习惯，最后再分享一次：永远让模型返还结构化输出；永远给生成结果留一个校验层；永远先写好评测用例再动手改；永远对上下文长度和成本保持敏感；永远在发布前找一个人做体验评审。这五条没有一条是高级技巧，但每一条都让我少走了很多弯路。

如果你也是从零开始，别怕慢，也别贪多。把一个简单的功能做到可靠，比把十个花哨的功能做到半吊子有价值得多。这条路没有捷径，但每一步都是实打实的积累。