企业官网建设流程全解析

开头：先聊清楚“AI工程”到底是什么再动手

这些年我在一线带过不少AI项目，发现一个特别普遍的现象：很多人一提到AI工程，第一反应就是“调Prompt”“接API”“让大模型跑通一个Demo”。等Demo真的跑通了，又开始头疼——生产环境一上，输出不稳、成本失控、回归问题一堆，最后项目不了了之。说白了，大家缺的不是模型能力，而是一整套从零开始把AI做成“工程”的方法论。

这个“ai-engineering-from-scratch”项目，其实就是我把自己过去几年踩坑的经验整理成的一套AI工程搭建链路。它不教你怎么训练模型，也不讲高深的数学推导，核心就一件事：当你只有一个业务诉求和一颗想要落地的决心时，怎么从零设计、搭建、评估、迭代一个AI系统。我给它起了个朴素的名字——“从零开始的AI工程”，对应的就是那条被无数人忽视的完整链路：数据准备、Prompt设计、评估体系、Agent工作流、系统集成、监控回归。

这篇文章是给谁看的？如果你是个正在做AI应用的产品经理、后端工程师、测试开发，或者刚带团队做AI项目的技术负责人，这篇内容应该能帮你少走大半年弯路。我尽量把那些文档里不会写出来的经验、决策时的“为什么”，以及具体到可以直接抄作业的步骤，都摊开来讲。核心关键词就三个：AI、engineering、from scratch。它解决的核心问题，就是让AI系统从“发明”变成“生产”。

1. 项目定位与整体思路拆解

1.1 先搞清楚“AI工程”和“调模型”的边界

很多人把AI工程等同于“调用大模型”，这个认知偏差是项目烂尾的第一原因。真正的AI工程，起点不是模型，而是“我要把一个不稳定的智能体，嵌入到一个需要稳定运行的业务系统里”。

这句话怎么理解？我举个例子。你做一个客服问答机器人，模型调用只是一个环节。你要考虑用户问法怎么归一化、知识库怎么切片、模型答错之后有没有兜底话术、回答延迟能不能接受、满足率怎么统计、模型升级后会不会把之前跑通的问题搞挂。这些全部加起来，才叫AI工程。

所以我做这个项目时，定的第一个原则就是：把模型当作系统中一个可替换的组件，而不是系统本身。这意味着所有围绕模型的输入输出，都要有标准化封装，都要有日志、评估、回滚机制。模型升级就像换发动机，底盘和外壳不能动。

1.2 从零搭建最适合的切入场景

从零开始做AI工程，最容易上手、也最能暴露全链路问题的场景是什么？我个人的答案是：文档智能问答。

理由有三条。第一，业务价值直观，老板能看懂，用户能感知；第二，数据获取容易，公司内部随便找几千份文档就能开工；第三，整个链路足够完整，涉及切分、召回、上下文组装、Prompt生成、答案评估，几乎覆盖了AI工程的七大核心环节。做完这个场景，你再迁移到客服、数据分析、流程自动化等任何方向，都是顺水推舟。

项目初期我就定了一个“最小可用闭环”的目标：不要贪多，先把一条链路彻底打通。具体来说，就是下面的流程：

文档上传 → 自动切分 → 向量化存储 → 检索召回 → 拼接上下文 → 模型生成 → 答案评估 → 日志回流

这里面没有任何一个环节是“高大上”的，但每一个环节都有坑。跑通这个闭环，才算摸到了AI工程的门槛。

1.3 四条铁律：SOP化、可评估、可回滚、成本可视

这个项目能走到今天，核心靠的不是哪个模型强，而是我一开始定的四条铁律。这些原则帮我在无数个“看似成功”的Demo面前保持了清醒。

第一条：一切流程SOP化。无论是数据清洗、Prompt撰写，还是评估集构建，全部要有标准操作流程。哪怕是“人工润色答案”这种听起来很主观的事情，我也要定义清楚：什么情况需要润色、润色到什么程度、润色完谁来复核。没有SOP，AI工程就是靠运气活着。

第二条：一切改动可评估。改Prompt、换模型、调参数，绝不能靠感觉。我在项目里坚持一个习惯——任何改动都必须在一套固定的评估集上跑一遍，得到量化指标后才能上线。评估集就是AI工程的“测试用例”，它是一切改动的裁判。

第三条：一切版本可回滚。前面的评估集跑得再好，生产环境也可能出现没见过的Case。所以我给每个线上版本都做了完整备份，包括Prompt版本、参数配置、模型版本。一旦线上出问题，一键切回旧版本，而不是紧急修新版本。

第四条：一切成本可视。AI项目的成本不是买服务器，而是Token消耗。我见过太多项目上线后才发账单崩了。所以在链路设计之初，每个环节的Token消耗都要打点统计，按请求维度记录输入长度、输出长度、模型单价，做到“每一分钱都有出处”。

这四条铁律写起来很轻，执行起来全是功夫，但它们是整个项目的地基。

2. 核心细节解析与实操要点

2.1 数据准备：不是“喂得越多越好”，而是“切得越准越好”

文档问答场景里，数据准备的核心工作不是清洗脏数据——虽然那也很重要——而是文档切分。切分做不好，后面的检索和生成全是空中楼阁。

很多人上来就用固定字符数切文档，比如每500个字符切一段。这个做法在纯文本上勉强能用，但一到真实业务文档就翻车。排版复杂的PDF、带表格的Word、有章节层级的技术手册，固定长度切分会把语义完整的一段话拦腰截断，也可能把两段无关的内容硬拼在一起，检索召回的质量会直线下降。

我实践下来比较稳的策略是**“层级切分 + 语义回退”**。具体做法分三步：

1. 结构识别：优先按文档本身的层级切分，比如章节、标题、段落。现在很多解析工具能把PDF的目录结构抽出来，用结构去切，语义完整性最高。
2. 阈值控制：每个切分块控制在一个合适的大小。块太小，召回时上下文信息不够，模型答不透；块太大，Token成本高，且容易混入噪声。项目里我常用的是每块256到512个Token之间，具体数值取决于你下游生成时能拼多少上下文。
3. 重叠窗口：相邻块之间保留10%到20%的重叠内容，防止切分边界把关键信息卡掉。比如实体名称、承上启下的转折句，刚好被切开，重叠窗口能大幅降低这种概率。

贴一段我当时用的切分逻辑伪代码，核心思想就是“优先结构，补充长度，带重叠回退”：

def smart_split(document, max_tokens=512, overlap_ratio=0.15): blocks = [] # 第一优先：按文档结构切（标题/段落） structural_blocks = extract_by_structure(document) for block in structural_blocks: token_count = count_tokens(block) if token_count <= max_tokens: blocks.append(block) else: # 长度超限，按句子边界二次切分，并保留重叠 sub_blocks = split_by_sentence(block, max_tokens, overlap_ratio) blocks.extend(sub_blocks) return blocks

这套方案在项目里的实际效果，是检索命中率直接提升了20个百分点。所以说，在AI工程里，数据的“形状”比“数量”更重要。

2.2 Prompt工程：本质是接口设计，不是“咒语编写”

Prompt工程这几年被炒得很玄，我自己的体会是：别把它当“咒语”，要把它当“接口文档”来设计。一个生产级的Prompt，最核心的是稳定，不是花哨。

我在项目里把Prompt拆成五个组成部分，每一部分都有明确的职责：

• 角色指令：模型以什么身份、什么立场来处理输入。比如“你是一名资深技术支持工程师”。
• 任务描述：模型要完成什么任务，输出什么格式。要具体到“根据提供的文档片段，回答用户问题。如果文档中没有相关内容，请明确回答‘未找到相关信息’”。
• 约束条件：禁止什么、必须避免什么。比如“不要编造文档中不存在的事实”“回答不超过200字”。
• 输入数据：这里注意，不是把检索到的内容一股脑塞进去，而是要先做“上下文筛选”。我之前吃过教训——模型面对一堆不相关的内容时，容易被带偏。
• 输出格式：结构化输出一定要用JSON Schema约束，方便下游解析。不要靠“请以JSON格式输出”这种软性指令，直接给Schema最稳。

另外一个非常关键的技巧是**“思维链与落地诉求的平衡”**。思维链能显著提升复杂推理任务的准确性，但会拖慢响应、增加Token成本。我的经验是：只有任务本身需要多步推理时（比如代码修复、复杂数据分析），才开启思维链；简单问答不要开，浪费钱还延迟高。按任务类型区分Prompt模板，是这个项目里性价比最高的优化之一。

2.3 评估体系：LLM-as-judge的落地姿势

AI工程被骂“不靠谱”，最大的原因就是没有评估体系。传统软件有单元测试、回归测试，AI系统呢？输出是开放的，不能简单断言。这时候就要用上“模型判官”的思路——用一个强模型去评估另一个模型的输出质量。

LLM-as-judge这个做法网上讨论很多，我落地之后发现几个容易忽视的细节：

第一，评估维度要分开打分，不要笼统评分。我常用四个维度：相关性、准确性、完整性、可读性。每个维度单独打分（1到5分），最后再算加权总分。混在一起打分，模型判官很容易“和稀泥”，区分度低。

第二，评估Prompt要带参考答案和评判标准。光让模型打分，它不知道“好”的标准是什么。我每次评估都会把原始文档片段、标准答案、模型输出一起喂给判官，同时附上明确的评分锚点（比如“出现与文档矛盾的信息，准确性直接判1分”）。这样打分的一致性能大幅提升。

第三，样本集要持续回流。评估集不是建一次就完事。每次线上用户反馈“答得不好”，我都把真实Case回收，人工标注后加入评估集。这样评估集会越来越贴近真实分布，模型的迭代方向才不会跑偏。项目里我大概每两周扩充一次评估集，这比任何花哨的监测指标都实在。

2.4 Agent工作流：从“单次问答”进化为“多步任务”

文档问答跑通之后，我开始把能力扩展到真正的Agent场景——让系统自主完成多步任务，比如“查一下上月销售数据，分析异常原因，生成一份报告草稿”。

这里要做的核心改造有三块：

• 工具调用规范：模型不能直接操作数据库或调用任意函数，而是通过一套预先注册的工具集来做。每个工具必须有明确的“功能描述”“参数Schema”“返回格式”。模型只负责“选择工具+填参数”，剩下的事交给调度器。
• 记忆管理：多轮任务必须有记忆。短期记忆可以放上下文，长期记忆则要入库。项目里我用的是“近期对话摘要+关键实体持久化”的结构，既控制Token消耗，又保留多轮对话能力。
• 护栏机制：这是最容易忽略的一块。模型在Agent模式下自由度大，很容易“跑飞”。我设置了三道护栏：一是工具白名单，模型只能调用注册过的工具；二是最大步数限制，超过设定步数强制终止并转人工；三是合规输出检查，涉及敏感内容或不符合业务规范的输出，直接拦截。

Agent工程的核心不是让模型“更聪明”，而是让系统的确定性边界足够清晰。模型可以在边界内自由发挥，但边界本身由工程人员牢牢守住。

3. 实操过程与核心环节实现

3.1 第一步：搭起最小可用的工程骨架

前面讲了那么多理念，这里开始上实操。我按项目推进的真实过程，给你拆一遍“从零到一”的关键步骤。

项目启动时我选的技术栈是这样的：Python + FastAPI做应用层，Milvus做向量库，LangChain做流程编排，底层模型用的当时稳定性和性价比都比较均衡的一款商用大模型。后来的经验是，技术栈不是重点，重点是每一层职责要清晰：应用层管交互，编排层管流程，模型层管生成，向量库管记忆。

搭骨架的核心动作是定义“数据流接口”。项目里所有环节之间都传递标准结构，我把它定义为：

{ "query": "用户原始问题", "documents": ["检索到的文档块"], "prompt_template": "使用的模板ID", "llm_config": {"model": "模型名称", "temperature": 0.2}, "response": "模型生成结果", "meta": {"latency_ms": 850, "tokens_used": 1200} }

所有环节只认这个结构，不认别的。这样做的好处是，后面调Prompt、换模型、加工具，都只是改某个环节内部实现，接口一律不动。这个设计让迭代成本低了一个数量级。

3.2 第二步：写Prompt模板与完成第一版线上对话

骨架搭好后，我最先做的事不是调优，而是把一套“能用的Prompt模板”固化下来。为什么强调“能用”？因为初版永远不完美，但必须有基线版本。没有基线，后面所有“优化”都无从对比。

我给文档问答场景设计的第一版Prompt模板大概是这样的：

你是公司内部的技术支持助手，请根据下面的参考资料回答用户问题。 参考资料：{context} 用户问题：{query} 要求： 1. 只依据参考资料回答，禁止编造； 2. 如果参考资料中没有答案，回复“未找到相关信息”； 3. 回答控制在200字以内，使用简洁的技术风格。

这个版本很朴素，但它是整个项目的第一个基线。上线后我收集了三天的真实对话日志，发现三个问题：一是回答经常包含“根据提供的资料”这种废话前缀；二是某些问题回答太长；三是有小概率模型无视资料开始自由发挥。于是第二版Prompt立刻迭代：

你是公司内部的技术支持助手。 参考资料：{context} 用户问题：{query} 规则： 1. 直接给出答案，不要解释你如何找到答案； 2. 严格基于参考资料，严禁引入外部知识； 3. 若参考资料没有明确答案，仅回复“未找到相关信息”； 4. 回答不超过150字，关键信息靠前。

对比两版，改动不算大，但都提炼自真实日志。这就是我想强调的：Prompt是养出来的，不是写出来的。每一版Prompt都要由线上反馈驱动迭代。

3.3 第三步：建立评估集并用模型判官打分

基线Prompt稳定后，我立刻做了一件很多团队会拖延的事——建评估集。我知道这活儿枯燥，但它是AI工程里最值得投入的部分。

评估集的来源构成我建议这样分配：

第一版我建了120道题，每一道都配了标准答案。评估方式用我前面说的LLM-as-judge，四个维度打分。这一跑，基线分数就出来了：相关性4.1，准确性3.8，完整性3.5，可读性4.2。这个分数列表就是我后续所有迭代的“方向盘”。

这里有个心得要分享：不要追求所有指标都高，要结合业务定优先级。比如我这套文档问答，业务上“准确性”是第一位的，回到整体评估时权重就设为0.5，其他三项各0.17左右。后续迭代优先冲准确性，不为相关性或可读性的小波动分心。

关键是，每次改动Prompt或者换模型，都在同一套120题上跑分对比。分数涨了才上线，没涨就回滚。这个流程坚持下来，模型的输出质量是稳定向上的，而不是上下乱跳。

3.4 第四步：日志、监控与迭代节奏

最后一步，也是很多“从零开始”项目最容易漏掉的一步：可观测性建设。

AI系统的日志和普通接口日志不一样，除了记录请求、响应、耗时，必须额外记录这几个字段：检索结果、Prompt版本、模型版本、Token消耗、模型判官评分。为什么要记这些？因为AI系统的“问题复现”逻辑和传统软件不同——同一个问题，换个Prompt版本可能答案就变了；同一个Prompt版本，模型悄悄升级了，行为也会漂移。没有这些日志字段，你根本没法事后排查。

项目里我用了一套简单但好用的打点方案：每次请求结束，异步写一条JSON日志到本地文件系统，再由定时任务汇总进数据库。日志样式大概是：

{ "time": "2025-06-11T10:00:00Z", "query": "续费流程怎么操作？", "retrieved_docs": ["doc_1032", "doc_1088"], "prompt_version": "v2.3", "llm": "gpt-4o-mini", "temperature": 0.2, "tokens": 850, "latency_ms": 780, "judge_score": {"relevance": 4.5, "accuracy": 4.2, "completeness": 4.0, "readability": 4.4} }

迭代节奏方面，我在项目里磨合出一套“三周一小迭代，两月一大迭代”的节奏。

• 前两周：收集线上日志和用户反馈，扩充评估集；
• 第三周：集中调Prompt、调参数、换模型候选，跑评估集打分，做一次小发布；
• 大迭代则用来做架构级改动，比如引入Agent工作流、更新知识库切分策略、升级向量模型。

这套节奏不强求“日日上新”，但保证每一次改动都有数据支撑。AI工程不怕慢，怕的是乱改一通然后退回原地。

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

4.1 问题一：模型“一本正经地胡说八道”

这类问题在AI工程里叫幻觉，是上线后遭遇最频繁的投诉来源。排查思路其实不难：先判断是“检索到的资料里根本没有相关信息”还是“有相关信息但模型没遵循”。

我用一个笨但有效的办法鉴别：把模型输出中的每个关键事实点，回原文比对。如果原文里完全找不到对应内容，那就是检索失败了；如果原文有，但模型答错了，那就是Prompt指令不够强。

对应两个方向的解法也不一样。检索失败，要调切分策略和召回阈值；模型没遵循，就在Prompt里强化“仅依据资料回答”这类限制，必要时结合规则拦截做后置校验。我在项目里还加了一道轻量的“引用溯源”——模型回答时强制要求附上引用的文档编号，用户能一键跳转原文验证。这一招不仅降低幻觉感知，还显著提高了用户对系统的信任度。

4.2 问题二：上下文太长，答案被“淹没”

文档多、检索块多、历史对话长，几个因素叠加，很容易出现“上下文塞满了，模型反而找不到重点”的问题。这不是模型变笨了，而是注意力被稀释了。

排查时我习惯从Token消耗下手。打开日志看输入Token数，如果动辄几千上万，那就要做减法。我试过的有效做法有三种：

1. 检索结果只取Top-K：不要把“相关”的结果全塞进去，控制在3到5块，相关性不够宁可不要；
2. 历史对话做摘要压缩：多轮对话时，把早期轮次压缩成一句话摘要，只保留最近两轮完整对话；
3. 上下文重排。强调相关字段放前面，模型对开头和结尾的内容记忆更牢，把最相关的信息放最前。

4.3 问题三：成本失控，单次请求Token爆炸

有段时间我的单次问答平均Token消耗从1200涨到了3500，排查后发现了“隐形消耗”——检索返回的文档块里大量冗余内容也被拼进了上下文。修复方式很直接，引入一个“上下文裁剪器”，按检索得分裁剪到固定长度，先把超长块过滤掉再做二次精排。

另外一个容易被忽略的成本大坑是Agent模式。多步任务会反复调用模型，每一步都在烧Token。我的做法是给Agent任务设置单轮预算，全局超出预算就自动切到降级模式（比如改用更小的模型或直接转人工）。还有一招很实用：给生成结果加缓存。相似问题在指定时间窗口内直接命中缓存，不重复调模型。这笔账算下来，能省20%到30%的Token费用。

4.4 问题四：模型升级后，旧功能的回答质量反而下降

这其实就是“行为漂移”，我在实际项目里踩过不止一次。有一次模型供应商发布了新版本，官网说明是“智能提升，对话更自然”，结果我们的评估集分数全面下跌——模型变得“太自然了”，开始天马行空，不再严格遵循“只依据资料回答”的约束。

这件事给我的教训很深：商用模型的版本升级，绝不能无脑跟随。我把所有模型请求都显式绑定版本号，绝不使用“最新版”这种动态指针。任何新模型版本上线前，都要在完整评估集上跑一遍对比测试，过了才切换。同时在代码层面预留“模型路由开关”，一旦新版本行为异常，一键切回旧版本。

经验是一刀一刀切出来的。我后面还专门在监控里加了一项“质量漂移预警”：每天统计评估指标的周环比，跌幅超过阈值就自动告警。有了这个机制，模型行为漂移不再是“事后发现”，而是能提前干预。

从一段经验到一套方法

这个“ai-engineering-from-scratch”项目做到现在，我最大的体会是：AI工程的“难”，不在于哪个环节有多高深，而在于把所有环节连成一个可稳定运转的系统。单点上有无数现成的工具和教程，但从零到一打通整条链路，并且让它在真实业务里持续产出价值，需要的是一套纪律——SOP化、可评估、可回滚、成本可视。

如果你也正准备从零搭一个AI项目，我给你的建议是：不要从“最酷的功能”入手，而是从“最小的闭环”入手。先用最笨的方式把整条链路跑通，哪怕效果普通也没关系。然后建立评估基线，让数据告诉你下一步该往哪走。最后，记得给你的系统装上日志和护栏，让它在无人盯守时也能按规矩办事。

我个人操作中还有一个压箱底的小技巧：每个迭代周期结束时，花半小时把决策过程写下来——改了什么、为什么改、评估结果如何、有什么副作用。这个习惯让我的项目在半年后回头看时，每个决策依然有迹可循。对于AI这种“随机性”很强的系统，这种“确定性”的记录，是整个工程最值钱的部分。