企业官网建设流程全解析

你可能也见过这种场景：团队里有人用大模型API做了个Demo，效果惊艳，产品一看马上要求上线。结果一到真实业务环境就翻车——“回答不稳定”“换个问法就答非所问”“上下文一长就犯迷糊”“Token费用比自己写代码还贵”。问题不在模型，而在把Demo变成工程化系统的中间环节，也就是AI工程能力。

这篇文章想聊的，是我从零开始搭建这套能力时踩过的坑、沉淀下来的方法和可以直接照搬的操作路径。不管你是后端工程师、测试工程师、技术Leader，还是刚接触大模型的应用开发者，只要你想把AI能力真正落到业务里，而不是停留在“调API演示”，这篇内容应该能帮你少走不少弯路。我会重点拆解四条线：工程地基、提示词与Agent开发、评测与可观测、部署与迭代，最后用一个企业内部客服助手的完整案例串起整个流程。

1. AI工程到底在解决什么问题

1.1 从“会调接口”到“能交付系统”的差距

如果你只是写几行代码调用大模型接口，那叫“使用AI”，不叫“AI工程”。什么是AI工程？我自己的定义是：让一个基于大模型的应用，在真实业务场景里稳定、可控、可评估、可迭代地长期运行。

传统的软件工程里，输入输出是可预期的，你的代码写对了，结果基本就对。但大模型应用的本质是概率性的，同一个Prompt，模型两次返回的内容可能不同；同一条知识，换个问法就检索不到；你修好了一个Bad Case，很可能引发另外三个新问题。这意味着，AI工程的核心不是“把功能做出来”，而是“管理不确定性”。

我见过不少项目死在“Demo挺惊艳，一上生产就崩”这个阶段。原因几乎都一样：没有离线评测集，不知道改动是好是坏；没有结构化日志，线上出错没法复盘；没有提示词版本管理，早期好用的Prompt后来被随手改成了一团乱麻；没有护栏机制，模型偶尔“发挥失常”时系统直接裸奔。

所以，AI工程首先是补上这些工程化能力，然后才是模型能力本身。

1.2 AI工程的四个轮子：数据、评测、推理与工具链、迭代机制

我在实践中把AI工程拆成四个互相咬合的轮子：

这四个轮子互相依赖。没有数据，评测集无从谈起；没有评测，你根本不知道数据清洗得好不好；没有工具链，模型只能空想；没有迭代机制，一切又会倒退成一堆人工拍脑袋的临时修改。

这也能解释，为什么那些看起来“模型能力最强”的团队，最后未必是产品落地最顺利的团队。模型是引擎，工程是底盘、刹车、仪表盘和方向盘，缺了任何一样，你都开不了远路。

2. 从零搭建AI工程能力：一条可复用的路线图

2.1 第一层：工程地基，先把代码组织做对

很多AI项目的起点不是算法，而是一个干净的代码仓。别小看这一步，我接手过的项目里有不少连“配置文件和代码混在一起”“Prompt直接写在业务函数里”“跑完脚本不留日志”这类问题都没解决，后面每一步都步履维艰。

我的建议是，任何一个AI应用项目，从一开始就按这个结构组织：

project/ app/ agents/ # Agent定义与编排 chains/ # 固定流程链 rag/ # 检索增强相关 tools/ # 模型可调用的工具 prompts/ # 提示词模板，按场景分文件 data/ raw/ # 原始文档 processed/ # 切分清洗后的知识块 eval/ # 离线评测集 tests/ eval/ # 评测脚本和结果 configs/ # 模型配置、检索配置 logs/ # 运行日志

这个结构看着简单，但它逼迫你区分“提示词”和“代码”。提示词本质上是业务策略，它一定会频繁变动；代码是承载策略的骨架，应该相对稳定。把Prompts独立出来，既方便非技术角色参与调整，也方便做版本对比。

另外两件事别偷懒。第一是依赖管理和虚拟环境固定住，保证任何人拉下来都能运行；第二是从第一天就写测试，哪怕只测一个“输入Query返回结构正确”的壳子。你要的不是测试覆盖率数字，而是至少有一条回归路径，能在改动后快速确认“系统没碎”。

2.2 第二层：提示词工程与Agent工作流开发

地基打好后，才轮到模型应用本身。这个阶段先掌握两件事：提示词工程（Prompt Engineering）和Agent工作流。

提示词工程不是“写一句好话让模型听懂”，而是用结构化方式约束模型的输出空间。我在实际项目里总结了一个五要素模板：

• 角色：明确模型扮演什么角色，比如“你是电商客服助手”
• 任务：一句话说清要完成什么，比如“根据知识库内容回答用户问题”
• 约束：列出禁止事项，比如“不要编造知识库以外的信息”
• 输入：说明用户输入和上下文的格式
• 输出：指定输出结构，比如“先给结论，再列引用来源”

写成模板后，还要注意提示词的分寸感。给太多限制，模型会变得机械；给太少，它又自由发挥。一个比较稳妥的做法是用评测集对比两个版本的提示词，而不是凭感觉判断。

Agent工作流则是把一次“大模型生成”变成“大模型自主完成一系列步骤”。我建议初学者先从固定的“规划-执行-反思”三步走起：

1. 规划：让模型分析用户请求，拆解为若干步骤或工具调用
2. 执行：调用搜索、查询数据库、操作API等工具，拿回结果
3. 反思：让模型检查结果是否满足需求，不满足则修正下一步

在实际落地时，不要一上来就上一套复杂的Agent框架。先用裸代码实现一个最简单的工作流，跑通后再引入框架。框架解决的是通用问题，但会带来额外的抽象和排障成本，你业务里的很多特殊逻辑还是要自己写。

2.3 第三层：评测与可观测性，给AI装上仪表盘

如果只能从这篇文章里选一个理念带走，我建议是这句：没有评测，就没有优化。

大模型应用的质量不是靠瞪大眼睛看出来的，是靠一套评测集和跑分脚本量出来的。我每次做项目，第一周就会逼团队建一个“最小可用评测集”，哪怕只有三五十条，也比没有强。评测集的标准结构大概是：

[ { "query": "订单超过多久未发货可以申请退款？", "documents": ["内部规则编号PR-101"], "expected": { "answer_contains": ["48小时", "退款"], "not_contains": ["免费"] } }, ... ]

针对不同场景，评测指标也不同。客服问答看答案是否包含关键信息；摘要场景看是否保留核心要素；分类场景看准确率；Agent场景就复杂得多，还要看工具调用是否合理、中途是否死循环、落库结果是否正确。

有离线评测还不够，线上必须有可观测性。我给每个AI请求写结构化日志，至少记录：用户原始输入、完整提示词版本号、检索到的文档ID、模型输出、耗时、Token消耗、用户是否有反馈动作（点赞、点踩、转人工）。这些日志是线上问题复盘的证据链，也是下一次优化评测集的来源。

2.4 第四层：部署与迭代，让系统能持续演进

AI系统的部署和普通服务有一个关键区别：你不仅要管理代码版本，还要管理Prompt版本和模型版本。一个在线的AI服务，线上运行的实际上是“代码+Prompt+模型参数”的联合体。

我的做法是给每个Prompt分配一个版本号，在调用日志里带上；模型层面则通过网关统一管理，不直接在各业务代码里写死模型名，这样才能平滑切换和灰度。部署策略上，先做好灰度：新旧版本各接一部分流量，用线上日志做对比。没有专门A/B平台的时候，一个简单的开关配置也能顶一段时间。

迭代方面，我强烈建议建立“线上反馈→评测集扩充→离线回归→灰度发布”的闭环。线上用户点“回答不满意”的Case，每周抽一批，把其中能复现、有明确答案的加进评测集。每两周做一次批量回归，看整体分数变化。这个过程听起来慢，但它才是AI应用质量持续提升的真正引擎。

3. 一个完整案例：企业内部客服助手从零到上线

3.1 先把需求边界说清楚

理论说多了容易飘，我拿一个真实做过的项目来串一遍。需求是给某企业做一个内部客服助手，员工可以问社保、报销、休假制度等问题，由助手基于内部制度文档回答；同时它还要能识别“我要转人工”“我要投诉”这类意图，自动转接给人工客服。

项目启动时，我们做的最重要的一件事就是划边界：第一期不做多轮复杂对话，不做实时数据库查询，不接第三方系统，只做“文档问答+意图识别+转人工”。原因很简单，第一期最重要的是跑通工程闭环，而不是追求功能多。先解决“回答得准不准”问题，再谈“能干多少事”。

这其实也是给很多AI项目提个醒：边界不清晰，评测集就没法构造，因为“什么算对”都说不清楚。

3.2 数据准备与评测集构造

这个项目的数据准备分三步走。

第一步，收集原始文档。把分散在各部门的人力制度、报销流程、Q&A清单全部收拢，转成统一的Markdown或文本格式。这里有个隐含的信息安全要求：所有文档必须先做敏感信息检查，这是上线前的硬门槛。

第二步，清洗和切分。删掉模板页眉页脚、表格里残缺的行，再按“章节标题+正文段落”切成知识块。切分长度要看实际内容来定，我一开始固定用500字符，后来发现制度文档里很多条目是一二三四条结构，就改成“按标题层级切块”。切块的目的是让检索命中更精准，切得太碎会丢失上下文，切得太长又容易检索不精准。

第三步，也是最容易被忽视的一步：构造评测集。我们从历史客服工单里挑出高频问题，整理成50条评测Query，每题标注了“答案必须包含的关键短语”和“禁止出现的短语”。比如：

Query: 年假在什么情况下会作废？ 必须包含: ["当年未休完", "未申请"] 禁止出现: ["强制清零"] # 政策原文并没有“作废”说法

这个评测集的构造花了大概两天，但它让后面所有优化都变成了可量化的游戏。没有它，你无法回答老板那句“改完是好是坏”。

3.3 RAG与Agent的逐步实现

评测集就位后，开始写主流程。我们第一版只做最简单的RAG（检索增强生成）：用户Query进来，向量检索知识库，取TopK文档块，拼进提示词，让模型生成回答。

代码并不复杂，核心就是这样一个函数：

def answer_question(query: str) -> str: rel_docs = vector_store.search(query, top_k=4) prompt = build_prompt( role="内部客服助手", task="根据提供的制度文档回答员工问题", context="\n---\n".join(rel_docs), query=query, ) response = llm.chat(prompt) return response

跑了两周评测后，我们发现两个典型问题：一是用户问“报销多久到账”，制度里写的是“收到发票后10个工作日”，但回答经常漏掉“工作日”三个字；二是提问里带口语化词，比如“买车要啥手续”，检索不到“车辆购置”。针对第一个问题，我们在提示词里强调“金额、时间、办理条件必须引用原文，不要改写数字和单位”；针对第二个问题，加了一个查询改写层，先把“买车要啥手续”改写成“车辆购置手续流程”，再去做检索。

接着我们上了Agent流程。之所以上Agent，是因为有些问题不是简单检索能解决的。比如“我刚入职，帮我列出下个月我需要办的事”，制度文档分散在多篇里，需要连续检索三次再汇总。我们设计了一个稍复杂的Agent：

1. 意图识别：判断是“问答”“多步查询”还是“转人工”
2. 问答分支走RAG；多步查询分支走“规划+多次检索+汇总”；转人工分支直接输出转人工卡片
3. 最后统一经过“回答自检”：检测回答中是否存在知识库未覆盖的信息

这么一套流程跑下来，评测正确率从第一版的68%涨到82%。最值钱的不是这个数字，而是我们每次改动都能精确说清提升来自哪里。

3.4 评测、上线和后续迭代

上线前我们做了两轮人工抽检，主要看评测集覆盖不到的开放问题。然后又加了一层“答案引用来源”展示，让员工点开能看到原文位置。这一步对抑制幻觉非常有帮助，因为当答案必须带出处时，模型编造的冲动会明显下降。

部署上，我们把它包装成一个内部Web服务，模型调用走统一网关，日志全量结构化落盘。上线后第一周，我们专门盯三类指标：回答被点赞/被踩的比例、转人工率、平均响应时间。转人工率异常升高，往往意味着模型对某些新话题完全不会答，这些Query会被抽回离线评测集补充进去。

一个比较明显的收益是：第二个月碰到一个政策调整，所有知识文档需要替换。因为我们有清晰的文档切分和提示词版本管理，只花了一个下午就完成知识库更新和全量回归，这在没有任何工程化能力的项目里是不可想象的。

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

4.1 高频问题速查表

做AI工程这一年多，我遇到过的问题里，有一半以上集中在下面这张表：

4.2 三个排查技巧，提升定位效率

第一个技巧是复现最小样例。线上日志里发现一个Bad Case，不要直接在完整链路里猜，而是把用户原始Query、当时命中的文档、使用的Prompt版本、模型输出四样东西单独抽出来，放到一个脚本里跑。这样能快速区分问题出在哪一环。我见过很多人排查半天，最后发现是某个文档更新把旧内容覆盖了，根本不是模型问题。

第二个技巧是给检索结果留痕。RAG类系统出了问题，有一半概率是“检索不对”而不是“生成不对”。所以日志里一定要记录返回了哪些文档ID和相似度分数。这样当回答质量下降时，你能立刻判断是向量检索漂了，还是模型本身没法正确利用检索结果。

第三个技巧是坚持回归评测。你发现一个Bad Case，修好了，这只是开始。真正的问题是你这个修改有没有影响其他Case。所以每次修改Prompt或检索策略后，把所有历史Case回归一遍，看总分变化。宁可使用一个笨重的离线脚本，也不要“改完就上线”。

4.3 别急着上Agent、上框架

我踩过最大的坑，就是过早地把系统设计得过于复杂。新手做AI应用，特别容易被“Agent”“多Agent协作”“AutoGPT”这类概念吸引，一上来就引入复杂框架，结果是代码抽象了三四层，出了问题根本不知道在哪一层丢的信息。

我的原则是先做减法。能用单次Prompt解决的，不建Chain；能用一步检索解决的，不上多步Agent；能用简单工具函数实现的，不引框架。只有当线上数据证明“简单方案确实不够”时，才逐步升级。很多问题，数据清洗干净、提示词写清楚、评测集跟得上，就已经能解决80%，剩下20%再交给更复杂的编排。

5. 我对AI工程落地的一点个人体会

做了几个AI项目之后，我一直把一句话挂在嘴边：不要把AI工程当作魔法，它是传统软件工程在大模型时代的自然延伸。你过去学过的版本管理、测试、日志、监控、灰度发布，没有一样是白学的，只不过现在多了一个“概率性组件”需要你特殊对待。

我自己最大的转变，是从“追求模型输出惊艳”变成“追求系统行为可预期”。后者听起来无聊，但正是这些无聊的工作——构造评测集、写结构化日志、做Prompt版本管理、建反馈闭环——决定了项目能不能活过三个月。如果你也准备从零开始做AI工程化，我建议你今天就可以做三件事：找一个真实业务场景，建一个几十条的评测集，然后让模型在这个场景下跑出第一条基线。剩下的所有优化，都会自然地从这条基线出发，一步步变成你真正可用的AI系统。