企业官网建设流程全解析

做AI工程这件事，我前后折腾了大半年。项目就叫 ai-engineering-from-scratch，翻译过来就是“从零开始构建AI工程能力”。它不是一个具体产品，而是一套我自己给自己定下的训练路线：不依赖任何现成的AI应用模板，从模型调用、提示词编写、Agent搭建、数据微调，到测试评估，整条链路全部亲手过一遍。这篇笔记就是把这条链路里踩过的坑、验证过有效的做法、以及最终沉淀下来的方法论，按顺序整理出来。如果你正准备入坑AI应用开发、想系统补齐工程化能力，或者已经在写Prompt但总觉得不稳定，这篇文章应该能给你一条比“到处看碎片教程”高效得多的路径。

1. 先搞清楚：AI工程到底在“工程”什么

1.1 我给“从零开始”下的定义

很多人一听“从零开始”，第一反应是“从零训练一个大模型”。说实话，除非你有几十张显卡和几个月时间，否则这条路对绝大多数人不成立。我项目里的“from scratch”指的是：不直接套用现成的AI产品（比如开箱即用的聊天机器人、自动总结工具），而是从调用一个裸模型API开始，自己设计提示词、自己搭Agent框架、自己处理数据做微调、自己写评估脚本。换句话说，模型可以是大厂的、开源的，但工程能力必须是自己一层层搭起来的。

这个定义有个好处：它把“AI工程”从玄学变成了可拆解的能力项。模型选型是一层，提示词是一层，上下文管理是一层，Agent控制流是一层，测试评估是一层。每一层都可以独立练习、独立验证，出问题也知道去哪儿排查。我见过太多人一上来就甩给模型一大段Prompt，效果不好就换模型，换完还不好就骂AI不行，本质上是把多层问题混成了一团，根本没定位到瓶颈在哪儿。

1.2 能力分层：四层递进

我实际操作中把AI工程能力分成四层，每一层都有明确的“合格标准”：

第一层是调用层：能稳定地把模型的API跑起来，处理超时、重试、限流、Token超长这些基础问题。这一层不过关，后面全建立在沙地上。

第二层是指令层：能用提示词把模型的输出行为约束到业务需要的范围内。这一层考验的是你对“模型是怎么生成概率分布”这件事的理解，而不是语文能力。

第三层是系统层：能把多个模型调用、工具调用、检索、规则判断编排成一个闭环系统。这一层就是Agent和RAG的主战场。

第四层是质量层：能建立评估集、自动化跑回归、量化指标来保证系统改了不会变差。

这四层我开头两个月基本全在第一层和第二层打转，后来才发现这是最正常的过程。AI工程和传统软件工程最大的区别是：传统工程的对象是确定性的代码，而AI工程的对象是不确定性的模型输出。你没法用“跑一遍看报不报错”来验收，必须建立一套专门应对不确定性的方法论。

2. 基础底座：模型选型与API工程化

2.1 如何挑选合适的基础模型

选模型是我见过最容易被低估的环节。很多教程默认你该用某个大厂的旗舰模型，但真实项目里模型选型要综合考虑四个维度：推理能力、上下文长度、价格与限流、以及数据合规要求。

我在项目里维护了一张自己的模型选型表，核心原则是“按任务难度分级路由”：

这里有一个关键经验：不要盲目追求“最强模型”。我做过一个实体抽取任务，用旗舰模型每万次调用要花几十块钱，换成中等模型后加了两个Few-shot示例，准确率只掉了0.3%，成本直接降到原来的四分之一。先想清楚任务的上限要求，再倒推选模型，而不是反过来。

2.2 上下文管理与Token估算

上下文管理是API工程化里最容易被忽略、炸得最狠的坑。模型能接收的Token总量是固定的，但你的业务数据是无限的。我见过太多人写代码时直接把整份PDF塞进Prompt，然后报错Token超长，一脸懵。

实操层面我总结了三个方法。第一是估算：中文场景下，一个字大约占1.5到2个Token，英文一个词约1.3个Token，标点和格式也要算进去。做聊天机器人时，我通常预留30%的Token额度给输出和函数调用参数，输入部分只占70%。

第二是截断策略：超出上下文的文本不能硬切，按章节标题切、按段落切、按语义边界切，否则会把一句话从中间劈开，模型读到一半的句意，输出质量断崖式下降。第三个方法是压缩和摘要：对于历史对话，每轮结束后做一次摘要存进上下文，而不是把原始轮次全带进去。这招对长会话场景几乎是必须的，我自己实现过一版“滚动摘要”，效果拔群。

2.3 调用稳定性：重试、超时与结构化输出

模型API是网络服务，不是本地函数，不稳定才是常态。我从项目第一天起就养成了一个习惯：所有模型调用全部包一层封装，统一处理四个问题。

第一是超时：默认超时设置成30秒，但根据任务复杂度动态调整，推理型任务给到60秒以上，因为思维链长的时候模型真的会“想很久”。第二是重试：遇到限流（429）或服务端错误（5xx），用指数退避策略重试——第一次等1秒，第二次等2秒，第三次等4秒，最多重试5次，避免把对方服务打爆。

第三是结构化输出：不要指望模型返回纯JSON就一定合法。我踩过的坑是模型偶尔会在JSON前后加说明文字，或者把布尔值True写成小写true导致解析失败。现在的做法是优先用模型的函数调用能力（Function Calling）让模型走结构化出口，拿不到就用正则和容错解析器兜底，再不行就引入一个轻量二次校验。

第四是缓存：对完全相同的请求做本地KV缓存，尤其是文档摘要、代码解释这类重复率高的场景，能省下可观的成本和延迟。实测下来，在知识库场景里加了缓存后，API费用下降了大概25%。

3. Prompt Engineering：核心技能拆解

3.1 提示工程的底层逻辑

很多人把写Prompt当成“跟AI说人话”，这其实是最大的误区。提示词不是写给“人”看的，而是写给“概率分布”看的。模型在做的事情是：根据你给的Token序列，预测下一个最可能的Token。提示词的作用是把这个概率分布朝着你期望的区域压缩。

理解了这一点，你就明白为什么“请你帮我写个方案”这种宽泛提示词不好用——它留下的概率空间太大了，模型只能靠自己的平均偏好去填空。而好的提示词本质上是在不断收窄概率空间：约束角色，收窄了语言风格；约束步骤，收窄了推理路径；约束输出格式，收窄了答案结构。每一条约束都是在帮模型减少“自由度”，自由度少了，稳定性和质量自然就上去了。

3.2 一套可复用的提示词框架

项目跑了大半年，我沉淀下来一套六段式提示词框架，适用面非常广。不是每段都必须有，但遇到复杂任务时我会逐段补齐：

• 角色定义：告诉模型它应该以什么身份和视角处理问题。注意不是让模型“扮演”，而是提供风格和目标锚点。
• 任务目标：一句话说清楚要做什么，我通常会加一句“目标是某某，不是某某”，把边界划出来。
• 约束条件：列清楚不能做的事，比如“不得编造数据”、“不确定时明确说不知道”。
• 输入数据：把要处理的内容完整放进来，注意格式清洗，乱糟糟的输入一定带来乱糟糟的输出。
• 推理过程提示：让模型先展示思考过程再给结论，对应思维链。
• 输出格式：给出结果的结构化模板，复杂任务甚至给一个填好示例的JSON骨架。

这套框架看起来简单，但真去逐字写的时候你会发现，最费时间的是“约束条件”和“输出格式”。约束条件写少了，模型容易自由发挥；输出格式不写清楚，解析代码就得到处打补丁。

3.3 思维链与Few-shot的正确用法

思维链（Chain-of-Thought）是提示工程里性价比最高的技巧。原理很简单：引导模型在给出最终答案前，先生成中间的推理步骤。为什么有效？因为模型的注意力是逐Token展开的，先写推理过程等于给后续生成铺设了一串“锚点”，每一步都受前一步约束，最后结论的连贯性和正确率都会提升。实测在数学推理和逻辑分析类任务上，加一句“请一步步思考，再给出结论”，准确率能提升10到15个百分点，零成本。

但这里有个细节很多人没意识到：把思维链提示改成“OpenAI o1格式”那种过度描述（比如“请用scratchpad思考”）并没有额外加成，关键还是给模型留出生成中间步骤的Token空间。有些任务需要把max_tokens调大，否则模型推理到一半就被截断了。

Few-shot示例也很有讲究。我项目里有一个原则：示例的质量和相似度远重要于数量。我曾做过一个任务，给模型看了20个示例，准确率反而比只看5个时低了。原因是20个示例里混进了一个标签不干净、边界模糊的样本，模型直接学到了噪声。现在的做法是：先准备3个高质量示例确保基本格式正确，跑一轮测试后只针对错误样本追加1到2个针对性示例，而不是无限堆量。

3.4 提示词评估与迭代

提示词迭代最大的敌人是“凭感觉”。我见过太多人改Prompt靠拍脑袋，这次效果不错就上线，下个任务效果差就全盘重写，毫无沉淀。我的做法是：每一条重要提示词都必须绑定一个评估集。

评估集不用很大，但要有代表性。比如一个分类任务，我准备30到50条覆盖不同子类、不同难度、不同边界情况的输入。每次改动提示词，跑一遍评估集，记录准确率、格式合规率、拒绝率这些指标。只有当指标变好或至少不掉，改动才算通过。这套流程跑起来后，提示词迭代变成了一件可积累的事：你手里的评估集就是最重要的资产，以后换模型也好、加功能也好，都能快速验证。

还有一个容易被忽略的点：同一个提示词在不同模型上的表现差异很大。A模型上效果炸裂的措辞，放到B模型上可能完全无感。所以升级模型或切换供应商时，别只看跑通没跑通，务必用评估集重新跑一遍基线，我在这上面吃过两次亏，都是“看着能用，实际指标掉了5个点”。

4. 从Prompt到Agent：推理能力与工具调用

4.1 Agent的架构：计划、执行、观察的循环

提示词只是静态指令，Agent才是动态系统。我做Agent的起点是一个极简的三段式循环：计划（Plan）、执行（Execute）、观察（Observe）。模型根据用户需求制定步骤，把每一步转成具体的工具调用，拿到工具返回结果后再决定下一步做什么，直到满足结束条件。

从零实现第一版Agent时，我建议别一上来就接外部框架。自己写一个几十行的循环，你就真正理解了状态是怎么流转的、错误是怎么传递的、上下文是怎么累积的。我当时用Python写了一个最简版：一个主循环、一个工具注册表、一个消息历史列表。主循环里把当前消息发给模型，模型决定是调用工具还是给出最终回复；如果调用工具，代码执行函数后把结果追加进消息历史，继续下一轮。

4.2 Function Calling的工程实现

Function Calling是Agent能真正“干活”的关键机制。它的思路是：你预先定义一组工具的JSON Schema，告诉模型有哪些工具可用、参数怎么填；模型收到用户问题后，如果判断需要调用工具，就生成一个结构化的“调用请求”，而不是普通文本回复。

我实际实现过程中，发现工程重点不在“调通”，而在“边界处理”。第一是参数校验：模型生成的参数偶尔会多一个字段、少一个字段，或者把整数传成字符串，必须在执行前用JSON Schema校验一次，不合法就返回错误信息让模型重新生成。第二是工具结果截断：工具返回的内容可能非常长，直接把完整结果塞回模型会撑爆上下文，我通常会对结果做截断或摘要，只保留最关键的信息。第三是循环保护：设置最大迭代次数（比如8轮），防止Agent在一个问题上反复调用工具死循环。这层保护是必须有的，我自己就遇到过模型把一个API连续调了十几遍的情况。

4.3 多Agent协作的探索

单个Agent能力有限，多Agent协作是我后期重点探索的方向。最稳妥的模式是“主管-执行者”：一个主管Agent负责拆解任务、分发指令、汇总结果，多个执行Agent各自专注于一个子领域。执行Agent的输出再回传给主管，由主管判断是否达标、是否需要补充。

实现多Agent协作时，最难的不是每个子Agent的能力，而是它们之间的“消息协议”。我吃过一次亏：让主管收集所有执行Agent的结果去写总结，结果各个Agent用不同的格式返回数据，主管根本没法程序化处理。后来我把所有Agent之间的通信统一成一种结构化格式：每条消息带任务ID、状态、结果、补充说明字段，主管和执行的对接全部走协议，人话只在最外层出入口出现。

多Agent协作还有一个好处是可以用不同模型分别扮演不同角色：花钱少的子任务用成本低的小模型，负责最终决策的主管用推理能力更强的旗舰模型。我实测过一个三Agent协作场景：一个文档解析Agent用中等模型，一个代码生成Agent用代码专项模型，一个审阅Agent用旗舰模型，整体效果比单一旗舰模型单干好，总成本反而降了两成。

4.4 记忆与状态管理

Agent的“记忆”是个大坑。模型本身是无状态的，每次请求都要带上对话历史，但对话历史不可能无限增长。我在项目里给Agent设计了三级记忆：第一级是当前会话窗口内的原始消息，用于最近的推理；第二级是会话摘要，每当上下文接近上限，就把前面的对话压缩成摘要放进后续请求；第三级是长期记忆库，用向量数据库存重要的事实和结论，需要时检索出来注入上下文。

这套三级记忆跑通之后，Agent才算真正有了“连续做事情”的能力。否则每次对话都是失忆的，用户上一句说过的偏好，下一句就忘了。但也要提醒一句：记忆不是越多越好。每次塞进上下文的记忆都会占用Token、增加噪声，关键是设计好“哪些值得记、哪些需要忘”，这跟人脑的记忆筛选机制是一个道理。

5. 从零构建推理模型的实践经验

5.1 为什么我要自己碰模型训练

自己训练一个推理模型（Reasoning Model）听起来门槛很高，但在开源模型生态成熟的今天，它已经不是遥不可及的事。我做这块的动机很直接：通用大模型在我的特定业务数据上表现不稳定，我想验证“用领域数据做继续训练能不能解决”。项目名里有“from scratch”，如果只停在调API层面，就名不副实了。

但我要老实说：真正从零做预训练——准备几万亿Token、搭分布式训练集群——不是个人项目该碰的东西。我的路线是“从开源基座起步”：下载一个质量可靠的开源模型，用自己构造的领域推理数据进行监督微调（SFT），再用偏好优化（DPO）调一轮对齐，最后量化压缩到单卡或本机能跑的尺寸。这条路线保留了“自己动手改模型权重”的核心体验，又避开了绝大多数人无法跨越的算力门槛。

5.2 推理数据怎么构造

微调阶段最耗时、最决定成败的不是训练代码，而是数据。模型在下游任务上的能力几乎完全由数据决定，训练代码只是把数据“刻”进权重。

我在项目里自己构造推理数据集，格式非常简单：每条数据是一组多轮对话，每轮包含用户输入和模型回复。关键在构造推理过程：模型回复里除了最终答案，必须包含完整的思考步骤，即“先分析问题，再逐步推理，最后给出结论”。我从两个途径凑数据：一是把日常工作中的真实问题整理成标准化问答，二是让大模型生成候选推理路径，再人工筛选和修正。

这里有一条重要心得：数据的多样性比数量重要。同样一千条全是数学推理的数据，模型就只能学会数学；但如果覆盖代码、逻辑分析、格式转换、多步规划等不同任务，模型的推理能力会明显更通用。我第一批数据只有八百条，但分了六个任务类别，微调后的模型在通用场景上比基座提升了明显一截。

5.3 微调、对齐与量化落地

训练流程我用的是社区成熟的开源训练框架。SFT阶段的超参我用过一轮比较稳的组合：训练轮数3轮，学习率2e-5，批次大小按显存尽量往大调，最大序列长度4096，只训练模型的LoRA适配器而不是全量参数。全量微调在个人单卡上根本跑不动，LoRA可以只训练不到百分之二的参数，效果在大多数场景下和全量微调差距很小。

DPO对齐我放在SFT之后，作用是把“模型觉得应该这样回答”和“人类觉得应该这样回答”之间的距离拉近。具体做法还是准备偏好数据：同一个问题，给一个优质回复和一个普通回复，让模型学会偏向优质回复。这一步跑完之后，模型输出的“说教感”和“废话感”会明显下降，更贴合我期望的风格。

量化部署我用的是4bit量化，模型体积直接缩到原来的四分之一以内，单张消费级显卡就能跑起来。量化的代价是推理速度可能变慢一点点，但换来的是部署门槛大幅下降。如果你有一批敏感数据不能出内网，这个路线几乎是必选项。

这里必须提醒一句：训练模型的失败率远高于调API。数据里混入格式错误、标签错位、推理过程跳步，最后都会在推理阶段放大成质量事故。我的做法是先在小数据集（一百条左右）上跑通全流程，验证数据格式没问题，再扩到完整数据集，避免浪费大量训练时间。

6. RAG与工作流：让AI真正落地

6.1 RAG的完整链路拆解

RAG（检索增强生成）是解决“模型不知道你的私有数据”的主流方案。它本质上是给模型加了一个外部知识库：先根据用户问题检索出相关内容，再把这些内容拼进提示词让模型基于它们回答。我在项目里把它应用在个人知识库问答上，效果非常显著。

一个完整的RAG链路分成五段：加载、分块、嵌入、检索、生成。加载就是从PDF、网页、数据库里把文本抽出来；分块是把长文本切成适合检索的小段；嵌入是把每段文本变成向量；检索是用用户的查询向量去向量数据库里找最相近的若干段；生成是让模型基于检索结果回答问题。

这几步里最容易出问题的就是分块。我最初用固定长度分块，比如每块五百字，发现很多块把语义完整的段落从中间切断，检索质量很差。后来改成按文档结构切：优先按Markdown标题、按章节、按段落边界切，每块五百到一千字，块与块之间再重叠五十到一百个字，保证边界信息不丢失。就这么一改，检索命中率明显上来了。

6.2 检索质量的重排序环节

很多人做完嵌入和检索就觉得完事了，实际上这是RAG最大的认知陷阱。向量检索找的是“语义上接近”的结果，但“接近”不等于“能回答问题”。有些文本在向量空间里和问题高度相似，实际内容却完全答非所问。

我的解决方案是加一层重排序：向量检索先粗筛出几十条候选，再用一个专门的排序模型把候选按“相关性”重新打分，最后只取最相关的前几条进Prompt。重排序模型不算大，跑一遍速度也可控，但检索质量提升非常明显。总体上，加了这层之后，知识库问答的“答非所问”比例至少降了一半。

6.3 工作流编排：把多步操作串成闭环

RAG和Agent解决的是“单点智能化”，真正到业务里还需要把智能和多步骤封装进一个可复用的工作流。我在项目里搭过一个内容生成工作流：先是需求解析Agent判断用户要什么类型的内容，然后检索Agent从知识库里捞素材，接着写稿Agent生成初稿，再让审阅Agent检查事实性和格式，最后一层规则检查保证输出符合业务约束。

这个工作流里最核心的设计不是每个Agent多强大，而是“失败分支”怎么处理。写稿Agent生成的内容不合格时，是退回重写还是走人工？检索Agent没找到足够素材时，是降级成通用模型回答还是直接报错？我在每个关键节点都定义了明确的失败策略，而不是任由它一路错下去。另外一个原则是：高风险的决策动作（比如对外发布内容、删除数据、转账支付）绝不交给Agent自动完成，必须在流程里卡一个人工确认环节。这是我做AI工程最坚持的底线。

7. AI工程的测试与质量保障

7.1 评估集建设：从口口相传到可量化

AI应用上线之后，用户反馈“感觉变笨了”“输出不对”，最怕的就是只能靠抽样和感觉去猜。要解决这个问题，必须建立评估集。

我的评估集建设方法是：从真实历史请求里分层抽样，覆盖正常场景、边界场景、错误场景三类。正常场景是典型任务，边界场景是超长输入、复杂格式、多步骤指令，错误场景是缺信息、歧义问题、超出能力范围。每条样例都要人工标注标准答案或评价标准。我自己的经验是：评估集不求大，两三百条就已经能发现绝大部分质量问题，但标注质量必须严格把关，因为整个评估体系的地基就是这些标注。

7.2 自动评估：LLM-as-Judge与断言检查

评估集建好后，不能靠人工一条条看，要用自动化脚本跑。具体做法是：写一个评测脚本，把评估集的每条输入依次发给被测AI系统，然后把系统的输出和标注答案交给评判方打分。评判方可以是规则（比如判断输出里是否包含关键字段、是否符合格式）、代码断言，也可以是另一个强模型。

用模型评判模型（LLM-as-Judge）是现在的主流做法，但要注意裁判本身的偏差：给裁判的评判标准写得不明确，裁判可能被候选回答的长度、语气带偏。我通常会在裁判Prompt里要求它先逐条核对事实，再打分数，并且提供具体的扣分原因。测试跑完后输出一个表格：每条用例的分数、判定结果、失败原因，一眼就能看到系统在哪里崩了。

7.3 回归测试与可观测性

评估集最大的价值在于做回归测试。我每次改提示词、换模型、动Agent逻辑，都会跑一遍完整评估集，对比改动前后的指标。指标没跌，改动才允许合并；指标跌了，哪怕是直觉觉得“新版更好”，我也以数据为准。这套流程看起来繁琐，但它是系统能持续演化的前提——否则每改一次都在赌。

可观测性方面，我做AI工程的习惯是把每次模型请求的关键信息全部记下来：输入和输出的Token数、延迟、重试次数、模型版本、Prompt版本、命中缓存与否。一旦线上出了问题，能按时间线把当时模型到底收到了什么、输出了什么完整复盘出来。没有这个，排查问题基本靠猜，效率极低。

8. 常见问题与排查技巧实录

8.1 我踩过的高频问题速查表

项目跑了大半年，踩过的坑攒了一大堆，整理成下面这张速查表，都是我实际遇到过并验证过解法的：

8.2 关于幻觉的排查经验

幻觉是AI工程里最让人头疼的问题之一。我排查幻觉问题时，先做定位：是检索到的知识本身就没有答案，还是模型没有忠实参考检索结果。区分这两类情况的方法很简单——把检索到的上下文原样拿给一个更强的模型，看它能不能从上下文里得出正确答案。如果强模型也答不出来，说明是检索侧缺信息；如果强模型能答出来，说明是生成侧没遵循上下文。

针对生成侧幻觉，我的对策是在Prompt里加一条强制约束：“你的答案只能基于以上提供的参考内容，不要引入参考之外的任何事实”。针对检索侧缺信息，对策是提高检索召回数量和质量，并设计一个“低置信度拒绝”机制：当检索结果的相关性分数低于阈值时，让模型直接回答“没有找到相关资料”，而不是硬编一个答案。这套组合拳下来，幻觉比例控制到了一般项目可接受的范围。

8.3 性能与成本的平衡技巧

最后聊一下性能和成本的平衡。AI工程项目很容易陷入两种极端：要么什么都用旗舰模型，账单爆炸；要么为了省钱用太小的模型，效果崩盘。我的策略是三级路由：简单任务（意图识别、实体抽取、格式转换）走小模型，中等任务（摘要、改写、单轮问答）走中档模型，复杂任务（多步推理、代码生成、长文档深度分析）才走旗舰模型。

路由判断本身也是AI做的：先让一个轻量模型对任务复杂度打分，再根据分数转发到不同的模型。这套机制上线后，我的整体API成本下降了差不多四成，而端到端质量几乎没有下降。同时配合2.3节说的缓存机制和批量处理，进一步把单位成本压了下来。

我个人的体会是：AI工程绝不是“调一个模型”那么简单，它是一整套围绕着不确定性构建的工程体系。从模型选型到提示词设计，从Agent编排到检索增强，从微调到测试评估，每一环都值得认真对待。项目叫“from scratch”，其实最宝贵的地方就在这里——你亲手把每个环节都趟过一遍之后，才真正拥有了判断问题出在哪里、以及如何修复它的能力。最后一个建议：从第一天起就保存你的失败案例，每踩一个坑就记录下来。过半年回头看，那份记录会比任何一个AI教程都有价值。