企业官网建设流程全解析

"ai-engineering-from-scratch"，翻译过来就是"从零开始做 AI 工程"。这个项目名字看着像一门课程，实际上代表了过去一年我反复验证的一条完整路径：从拿到一个大模型，到把它变成真正能落地、能扛住真实业务流量的应用系统。很多朋友刚接触时都会问同一个问题：大模型这么强，直接调用 API 不就行了？为什么还需要专门的"工程"？答案是：模型能给你一段高质量文字，但给不了你一个稳定、可控、可维护的产品。这中间的差距，就是 AI 工程要补的课。

这篇文章我结合自己的实操经历，把从零搭建 AI 应用的核心环节完整拆一遍：提示词工程怎么做、RAG 检索增强怎么落地、Agent 智能体怎么编排、测试和评测体系怎么搭，以及最常踩的坑怎么排。适合三类人看：想转行做 AI 应用开发的工程师、正在带团队做 AI 项目的负责人，以及想独立用 AI 做产品的开发者。读完你至少能搭出一条"数据准备 → 检索 → 生成 → 评测 → 迭代"的完整链路，而不是只停留在"调用一下模型 API"的玩具阶段。

1. 项目概述与整体思路解构

1.1 "从零"到底零在哪里

先说清楚一个概念：AI 工程里的"从零"，不等于自己训练大模型，也不是从线性代数开始补课。你不需要自己从零实现 Transformer，也不需要去优化损失函数，这些工作由模型训练团队和开源社区完成了。这里的"零"，指的是你手上除了一个大模型的 API 或开源模型权重之外，什么都没有：没有现成的业务流程、没有数据管线、没有评测集、没有可复用的工程骨架。你要做的，是在这个"零"的基础上，把模型能力变成产品能力。

这个定位非常重要，因为它决定了你整个学习路径的重心。我刚带团队时，很多成员的第一反应是去读论文、复现模型结构，结果一个月过去，连一个能跑的 demo 都没有。后来我强制大家把时间放到下游任务上：设计提示词、清理数据、搭检索链路、做效果评测。一周之后，每个人的手里都有了一个可以演示的版本。方向对了，进度就快；方向错了，努力全是沉没成本。

从零到一的路线图，我建议按顺序走五步：第一，掌握提示词工程，这是最基础也是最容易立竿见影的能力；第二，学会用框架和工具编排模型调用，把单次问答变成可复用服务；第三，引入外挂知识库，也就是 RAG，这是目前 AI 应用落地最主流的形态；第四，升级到 Agent 智能体，让模型具备规划任务和调用工具的能力；第五，搭建评测与监控体系，让系统可度量、可回归、可持续迭代。这五步覆盖了当前几乎所有 AI 应用的核心骨架。

1.2 先搞工程，还是先搞算法

这是几乎所有新人都会纠结的问题，我的答案非常明确：先搞工程。80% 的业务场景，根本不需要你动模型参数；你需要解决的是数据怎么进来、结果怎么出去、质量怎么保证、成本怎么控制。这些全是工程问题。只有当你发现现成模型在特定任务上怎么调都达不到效果时，才需要考虑微调或蒸馏，而那已经是第二个阶段的事了。

工程思维和算法思维有一个本质区别：算法思维追求"理论上更优"，工程思维追求"系统上可行"。举个例子，我在做文档问答时，算法同事建议用更复杂的语义切分模型来切分长文档，说理论上能提升召回率。但我评估了一下，那个模型的推理耗时会让整个接口的响应时间增加三倍，而且个别长文档的切分边界并不稳定。最后我用的是"固定大小 + 重叠窗口 + 标题层级拼接"的工程方案，效果接近，成本低了一个数量级。这就是工程和算法的分野：你要的不是最好的模型，而是最合适的系统。

当然，完全不碰算法也不行。我所说的"先搞工程"，是让你把工程基线先跑通，然后再在关键节点上补充算法知识，比如嵌入模型是什么、向量相似度怎么算、重排（Rerank）为什么能提升精度。这些知识不用深到推导公式，但必须理解原理，否则出了问题你连排查方向都没有。

1.3 不同背景的人怎么切入

AI 工程有个特点：它不像传统后端那样要求统一的语言和技术栈，所以不同背景的人切入路径差别很大。

有 Web 后端经验的工程师，最容易上手。你的优势在于服务架构、接口设计、数据库、部署运维这些基本功可以直接迁移。你要补的只有两块：一是理解模型的输入输出方式和能力边界，二是学会写提示词和设计检索链路。我通常建议这类人直接把项目做成一个带 API 的服务，用 FastAPI 包一层，前端或业务系统来调用，这样最能发挥你的优势。

数据分析师或测试工程师转型，也别慌。你对数据质量的敏感度是很大的优势，因为 AI 应用的质量问题本质上都是数据问题。你可以先往"AI 测试开发"方向走：帮团队搭建评测集、设计回归测试、分析 bad case。这个岗位在当前市场非常稀缺，很多团队不缺写代码的人，缺的是能说清楚"模型效果到底好不好、哪里不好、为什么不好"的人。

完全零基础的朋友，我给的建议是不要先啃编程，先白嫖各种 AI 产品建立直觉。去用各种大模型产品，观察它们在什么场景下好用、什么场景下胡说八道，然后尝试用自然语言写提示词控制它们的输出。有了直觉之后，再从 Python 语法开始，学 Flask、学爬取数据、学调用 API。你不需要成为一个资深程序员，但你需要成为那个最会"指挥 AI 干活"的人。

2. 核心技术栈与工具选型解析

2.1 AI 应用的最小技术栈

我一直反对一上来就堆技术栈。很多教程张口就是 LangChain、LangGraph、Dify、FastGPT，把架构图画得天花乱坠，结果新手全在学框架，学完还是不会自己解决实际问题。我的做法是：先用最朴素的代码打通一条最小链路，再根据痛点引入框架。

一条 AI 应用的最小链路长这样：用户请求进来，你的服务把请求拼接成提示词或调用 Agent 框架，发送给大模型（云端 API 或本地部署模型），拿到输出后再经过解析、校验、后处理，返回给用户。如果涉及知识库问答，中间再加一条"向量化 → 检索 → 重排"的路径。所有技术栈都是在为这条链路服务。

具体到选型，我分成四层说。模型层：云端闭源 API 适合追求效果和上线速度的场景，国内可用的大模型服务很多，开源模型则可以用 Ollama 一键本地跑起来，或者用 vLLM 做高性能部署。框架层：我的建议是新手先别用 LangChain，先手写两次调用逻辑，理解提示词拼接和函数调用的本质，然后再拿框架简化重复劳动。数据层：小项目用 Chroma 或 FAISS 就够了，数据量大、并发高再上 Milvus 或 pgvector。服务层：首选 FastAPI，自带异步支持和接口文档，写起来快。

2.2 Prompt Engineering 提示工程的价值与边界

提示词工程是所有人都绕不开的第一课，但它也是最容易被误解的一课。它不是简单的"把话说清楚"，而是利用模型的训练特征来约束它的行为空间。我觉得有一个类比特别准确：提示词不是咒语，而是给一个什么都懂一点但有点爱自由发挥的实习生写的任务说明书。说明书越清晰，实习生的发挥越可控。

一份高质量的提示词，至少要包含五个要素：角色设定、任务描述、约束条件、示例输出、输出格式。角色设定告诉模型"你是谁、站在什么立场"，任务描述告诉它"你要干什么"，约束条件告诉它"什么不能干"，示例输出给它一个参考模板，输出格式则方便你做程序解析。我自己的模板通常长这样：开头定义角色和背景，中间列任务清单并编号，然后用"注意：不要..."写约束，最后给一个 JSON 格式的输出样例。

提示词也有边界。它约束的是模型的输出风格和内容倾向，无法改变模型内部的知识边界。你让模型回答一个它从没见过的产品参数，它唯一能做的就是编一个看起来合理的答案。所以遇到这类需求，不要死磕提示词，而是要给它外挂资料，也就是下一步要说的 RAG。提示词工程管行为，知识外挂管内容，两者配合才是完整方案。

2.3 从单模型调用到 Agent 智能体

Agent 是这两年 AI 工程里最火也最容易做虚的概念。我把 Agent 的本质讲穿：它就是一个"能自己做决定调用什么工具"的大模型循环。传统开发里，流程是你写死的：用户说 A，程序就执行 A。Agent 不一样，模型分析用户的指令，自己决定先调哪个工具、根据工具返回结果再决定下一步做什么。这个能力在业务自动化、多步骤任务处理上价值很大。

但 Agent 最怕的就是失控。模型在一个多步骤任务里可能会反复调用同一个工具停不下来，也可能会在工具返回的结果不理想时自作聪明地编一个结果。所以工程上必须给 Agent 加约束，这就是我常说的"Harness Engineering"，直译过来是缰绳工程——像给马套缰绳一样，给 Agent 划定活动范围和行动边界。具体做法包括：限制工具列表的数量和精度，给每个工具写清楚描述和参数规范；设置最大迭代步数，超了就强制结束；关键节点要求模型输出中间推理过程，方便回溯；对工具返回结果做校验，异常时直接中断而不是让模型硬编。没有这层约束，Agent 只能在 demo 里炫技，上不了线。

多 Agent 协作是另一个容易翻车的地方。我的经验是：能用一个 Agent 解决的，绝对不要拆成两个。Agent 之间互相传递信息时，格式不统一、上下文丢失、决策冲突都是高频问题。如果确实要拆，那就明确分工：一个主控 Agent 负责理解任务、拆解步骤、汇总结果，若干子 Agent 负责具体执行。消息格式统一用结构化 JSON，每个 Agent 只读它需要的字段，尽量避免"所有 Agent 共享全部上下文"这种设计。

2.4 AI 测试开发：没有评测体系就别谈迭代

我觉得整个 AI 工程里最被低估的环节，就是测试和评测。传统软件测试测的是"输出是否符合预期"，而 AI 应用的输出是概率性的，同一个问题问两次，答案可能字面上完全不同。这就意味着你无法用简单的断言来验证功能，你必须建立一套基于数据集和指标的评测体系。

我管这套工作叫"AI 测试开发"，它包含三个层面。第一层是构建评测集，也就是一批有标准答案或答案判据的问题，来源可以是历史真实用户问题、业务专家标注、模型生成后人工修正；第二层是定义评测方式，可以用规则匹配关键信息、可以用语义相似度打分、也可以让另一个模型当裁判（LLM-as-judge）；第三层是把评测跑在 CI 里，每次修改提示词或调整检索参数，都自动跑一遍全量回归，用分数对比来判断改动是变好了还是变差了。

评测体系最忌讳的是自嗨。我见过很多团队，自己写了 20 条测试题，每次改完代码跑一遍，分数涨了就觉得效果变好了。但实际上，那 20 条题跟真实用户问的问题根本不是一回事。正确的做法是：从真实用户日志里抽样，覆盖高频问题和困难问题，让业务方参与标注"满意 / 不满意 / 错误"，然后每个月基于线上 bad case 滚动扩充评测集。评测集就是 AI 应用的地基，地基歪了，楼越高越危险。

3. 实操记录：从零搭一个企业知识库问答系统

3.1 场景定义：为什么第一个项目选 RAG

前两部分讲的都是概念，接下来的实操部分，我用一个最经典的场景来串联：企业内部文档问答系统。为什么第一个项目选这个？因为它完整覆盖了 AI 工程的各个核心环节，且业务价值非常清晰。文档散落在各个地方，Word、PDF、企业Wiki，员工查一个政策要翻半天，而大模型天生擅长把零散信息组织成通顺的答案，只是不知道你公司内部的内容，所以我们必须给它外挂一个"资料库"，这就是 RAG 的本质。

RAG 的全称是检索增强生成（Retrieval-Augmented Generation），思路就三步：先把你的文档切块、向量化，存进向量数据库；用户提问时，把问题也向量化，去库里找最相似的若干文本块；把这些文本块和问题一起塞给模型，让它基于这些资料作答。这套方案最大的好处是：不用训练模型，知识可以随时增删改，答案可溯源。它是目前 AI 应用落地最成熟的技术路线，没有之一。

在开始之前，我建议你先问自己一个问题：我要做的这个系统，核心 KPI 是什么？对知识库问答来说，KPI 通常不是"回答得多通顺"，而是"能不能找到正确的那份文档、能不能基于它给出准确答案"。这个判断会影响你之后所有的设计决策。

3.2 数据准备：文档清洗与切分策略

很多人把 RAG 的重心放在模型和检索上，但实际跑下来你会发现，数据准备才是决定效果上限的那一步。脏数据进，脏数据出，模型再强也救不回来。

我拿一个真实项目举例：客户发来几百份企业制度文档，格式极其混乱，有扫描 PDF、有表格嵌套的 Word、有带页眉页脚的网页导出件。我的处理流程是分四步：先用工具把 PDF 转为文本或 Markdown，检查乱码；然后做清洗，把页眉页脚、重复的目录、无意义的换行符全部去掉；接着按文档原有的标题层级切分，保留章节目录信息作为元数据；最后把文本切成一个个信息块，每块控制在 300 到 500 个 token 左右，块与块之间留 50 到 100 个 token 的重叠。重叠的目的是防止一个完整语义被从中间切断。

切分这个环节，很多人直接用固定长度硬切，效果一塌糊涂。更好的做法是"语义优先、长度兜底"：优先按 Markdown 标题、段落、列表来切，切出来的块如果太长，再按句号或换行符二次切分。每块文本记得附上来源文档、页码或章节路径等元数据，这样以后才能做答案溯源。这块没有银弹，需要根据你文档的实际情况反复调。

3.3 嵌入模型与向量检索选型

文本切好之后，下一步是把它们变成向量。这里要先解释一下什么叫"嵌入"：简单说，就是把一段文字变成一串固定长度的数字，让语义相近的文字在数字空间里距离更近。比如"公司年假政策"和"工作满一年可以休几天"这两句话，字面上完全不像，但嵌入向量会很靠近，这样你用后者去检索，就能召回前者。

嵌入模型的选择直接影响检索质量。我现在的经验是：中文场景优先用国产开源嵌入模型，比如 BGE 系列，效果在中文语义上表现很好，本地部署免费且没有数据外泄风险；英文或混合场景，可以选 OpenAI 的 text-embedding-3 系列。向量维度不是越大越好，很多场景 768 维已经够用，维度太高会带来存储和检索成本的上升。选嵌入模型时注意固定版本，因为换模型等于整个向量库重建，代价很大。

向量数据库这块，我的选型逻辑是分阶段。第一个版本我用 FAISS，因为它只是一个库，嵌入在服务进程里，部署简单，项目只有几万条数据时完全够用。数据量到了百万级、需要多人同时检索、需要持久化和权限管理时，再迁移到 Milvus 或 pgvector。不要一开始就追求分布式架构，当前阶段能用够用比高大上重要。

3.4 检索与生成链路：从裸召回到底装进提示词

向量检索是最常用的召回方式，但实际项目里，纯向量检索会在两个地方出问题：一是专有名词和精确代码，比如"报销流程编号 FY-2024-03"，语义上很难找到相近表述，向量召回效果差；二是用户问题太口语化，跟文档里书面语风格差距大。解决办法是引入混合检索：同时跑向量相似度和 BM25 关键词匹配，然后把两路结果合并排序。BM25 是传统搜索引擎的核心算法，擅长精确匹配，与向量检索互补性很强。

召回之后再上一个重排模型（Rerank）是见效最快的提升手段。原理不复杂：向量检索先粗召回 50 条候选，重排模型再对这 50 条逐一精读，评估它们跟用户问题的相关性，只保留 Top 3 到 Top 5 传给大模型。这个环节会让最终答案质量上一个台阶，因为它把"接近"的问题变成了"精确"的上下文。代价是多了几十毫秒延迟，但值得。

然后是组提示词。RAG 的提示词跟普通问答不太一样，必须明确告诉模型：下面这些资料来自企业内部文档，只基于这些资料回答，资料里没有的就直接说不知道，不要编造；每条答案最后标注资料来源，格式是"[来源：文档名-章节]"。这一步很关键，它既减少幻觉，又让答案变得可信。拼装时我会把多段资料用 XML 标签包起来，方便模型区分不同来源，也方便后续解析。

3.5 从脚本到服务：完整工程代码示例

理论讲完，上实战代码。下面是我常用的一个最小可运行版本，用 Python 实现，依赖只用了 FastAPI、OpenAI SDK 和一个本地向量库。这里我故意不用重量级框架，目的是让你看清每一步在干什么。

import os from fastapi import FastAPI from pydantic import BaseModel import chromadb from openai import OpenAI app = FastAPI() # 初始化向量库（本地持久化） client = chromadb.PersistentClient(path="./kb_store") collection = client.get_or_create_collection("docs") # 初始化大模型客户端 llm = OpenAI( base_url=os.getenv("LLM_BASE_URL", "http://localhost:8000/v1"), api_key=os.getenv("LLM_API_KEY", "local"), ) class AskRequest(BaseModel): question: str def retrieve(question: str, top_k: int = 5): """向量检索 + 关键词检索合并，这里简化用向量检索""" results = collection.query( query_texts=[question], n_results=top_k, include=["documents", "metadatas"], ) return results["documents"][0], results["metadatas"][0] def build_prompt(question: str, docs: list, metas: list): context = "\n\n".join( f"<doc>\n{doc}\n来源：{meta.get('source', '未知')}\n</doc>" for doc, meta in zip(docs, metas) ) return f"""你是一位企业内部知识库助手。请只基于下面提供的资料回答问题。 资料中不存在的信息，请明确回答"资料中未找到相关内容"，严禁编造。 资料： {context} 用户问题：{question} 要求： 1. 答案准确、简洁、条理清晰。 2. 回答末尾列出引用来源，格式为：[来源文件名-章节]。 """ @app.post("/ask") def ask(req: AskRequest): docs, metas = retrieve(req.question) prompt = build_prompt(req.question, docs, metas) resp = llm.chat.completions.create( model=os.getenv("LLM_MODEL", "qwen"), messages=[{"role": "user", "content": prompt}], temperature=0.1, ) return {"answer": resp.choices[0].message.content, "sources": metas}

这段代码有三个值得注意的细节。第一，temperature=0.1，知识库问答是确定性问题场景，温度必须设低，减少模型自由发挥；第二，提示词里要求模型在资料缺失时说明，这是对抗幻觉的关键设计；第三，检索结果的元数据直接返回给前端，前端可以展示引用来源，用户能点进去核对原文，信任感完全不一样。

上线之前，还有三件事必须做：一是加接口鉴权和限流，防止被别人白嫖算力；二是记录每次提问和回答的日志，这是后续分析和优化的数据基础；三是加基础监控，比如响应时间、检索失败率、空答率，空答率突然升高往往意味着检索链路出了问题。

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

4.1 答案质量不达标，先调什么？

这是出场率最高的问题。答案是质量很差，是调提示词、换模型，还是加数据？我的排查顺序是固定套路，按优先级来：

第一先查检索。拿用户的原始问题去跑检索，看召回回来的 Top 5 到底是不是相关内容。如果召回的前几条根本不相关，那模型答得再差也怪不到它头上——巧妇难为无米之炊。检索质量排查方向包括：问题是不是太口语化导致向量偏了；是不是专有名词没召回；候选数是否太少；重排模型有没有误杀。

第二再查数据。看召回的文本块本身内容是否完整，是否被切断了上下文，有没有关键信息在下一块里。比如合同条款经常跨页，切分时按页切，那模型永远看不到完整条款。这种问题调提示词是无效的，必须回头改切分策略。

第三查提示词。确认约束条件是否写清楚了，资料缺失时是否要求模型承认不知道，输出格式是否会被模型随意改变。第四才轮到换模型。说实话，我用过的大小模型不少，在同等条件下，GPT-4o 系列、Claude 系列和国内几个头部模型在知识问答任务上的差距远没有想象中大。先把前三步走完，效果基本都能拉到及格线以上。

4.2 上下文太长、成本失控怎么办？

AI 应用的成本大头基本都在模型 token 消耗上，而且很多人以为只有输出才花钱，其实输入 token 才是花钱大户。一个典型知识问答请求，检索回来的资料可能就有两千 token，加上系统提示词、历史对话、候选资料去重重排后塞进去，单次请求消耗轻松上万 token。访问量一起来，账单立刻爆炸。

我的成本控制三板斧：第一板斧是瘦身，系统提示词精炼到 500 token 以内；历史对话只保留最近两轮，更早的做摘要；检索回来的资料只保留与问题最相关的 Top 3，不是 Top 5，让重排模型把最精的筛出来。第二板斧是缓存，对高频问题做语义相似度匹配，命中缓存直接返回历史答案，省掉模型调用费用。第三板斧是限额，给每个用户每天设置调用次数上限，并对超长输入做截断保护，防止被恶意刷量。

还有一个容易被忽略的技巧：把知识库内容的结构化摘要存一份。比如用户问报销流程，你不必把整个 1000 页制度手册都检索进来，可以先把"流程标题 + 摘要 + 原文位置"作为一个检索入口，命中后再按需加载细节。这种"先摘要后详情"的设计，能把单次请求的 token 消耗降低 50% 以上。

4.3 检索不到相关内容怎么办？

这个问题比答案质量差更隐蔽，因为用户看到的不是"答错了"，而是"模型在硬编"——资料库里根本没有的流程，模型也能绘声绘色地描述出来。排查时首先要做的是确认资料库的覆盖面：用户问的事务，文档里到底有没有写？很多项目上线后才发现，核心业务流程根本没有发文，资料库本身就是不完整的。遇到这种情况，不是调技术，是去推动业务部门补资料。

技术侧的排查方向有三个。一是检查问题 rewrite 是否缺失。用户问"去年年底发的那个关于加班补贴的通知"，直接拿这句话去检索，大概率召回失败。正确做法是先用一个轻量模型把问题改写为标准查询："加班补贴通知"，甚至拆成多个关键词组合，再分别检索合并结果。二是检查嵌入模型对专业术语的识别。有些场景需要自定义一个同义词词典，把简称、缩写、俗称都映射到标准术语上，检索前做一层替换。三是检查检索结果排序。如果相关内容能召回但排在第 20 位，那需要提高候选数并强化重排，而不是简单加大 top_k，否则噪声也会同时进来。

4.4 评测怎么做才不算自嗨

我在前面强调过评测的重要性，这里给出一套具体可执行的方案，你直接照着搭就行。

第一步，从用户真实日志里抽 100 条问题，覆盖高频问题、疑难问题各半。第二步，给每道题标注"满意答案要点"，可以是关键词集合，也可以是一段参考答案。日常维护时，如果答案命中了要点就是通过。第三步，三档打分：好、及格、差。好是关键信息全对且引用正确；及格是信息部分缺失但不致命；差是答非所问或关键信息错误。第四步，每轮迭代后跑一次全量评测，对比好和差的比例变化。我把这个指标简称为"好评率"，每次改动必须让好评率不降才会合入。

还有两个进阶技巧值得用。一是模型打分（LLM-as-judge）：让一个更强的模型当裁判，把问题和回答发给它，让它按你定的标准打分。用下来标准要写细：相关性、完整性、引用准确度、语言通顺度，每一项单独打分，否则裁判模型只会给出一句模糊的"整体不错"。二是建立 bad case 复盘机制：每次发现一个典型错误，立即把它加入评测集并修正答案要点，保证同样的错误不会第二次蒙混过关。这样你的评测集会越来越难，系统也会越来越稳。

4.5 多 Agent 协作时的互踩与防呆

如果你已经开始尝试多 Agent 架构，一定会遇到两个作用互相打架的经典场景：主控 Agent A 让资料 Agent B 搜索数据，B 返回一个表格，主控 Agent 没看懂表格，自作主张改写了一段，然后业务 Agent C 又基于改写后的内容做了错误判断。最后用户收到一个逻辑断裂的回答，而你根本不知道是哪一环出了问题。

我处理这类问题的经验是四件事同时做。第一，每个 Agent 只给它必要的上下文，禁止共享全部历史，避免信息污染。第二，Agent 之间的消息全部走结构化 JSON，定义好固定字段，例如{"task": "search_docs", "query": "...", "max_results": 5}，主控 Agent 拿到这个结构后直接解析，而不是靠自然语言理解。第三，给每个 Agent 设置权限边界和最大执行步数，工具失败或超时就直接返回错误，不要允许 Agent 自己编造工具结果。第四，整条链路打完整日志，每个 Agent 的输入、输出、耗时全部记录，排查问题时按时间线回放。做到这四条，多 Agent 协作才具备可维护性，否则就是一场大型赌局。

还有一个小技巧：设计 Agent 时，先把它的"工具清单 + 触发条件"写成一个表，比如某个 Agent 专门负责文档检索，只有当问题里出现"制度、流程、规定"这类词时才触发。这个表既是给模型的系统提示词，也是给你的架构文档，一举两得。

5. 从零到一最后想说的话

整套流程走下来，我最深的体会是：AI 工程从零到一，真正的瓶颈从来不是模型能力，而是你能不能把"模型"装进一个靠谱的"产品容器"里。提示词工程管行为，RAG 管知识，Agent 管流程，评测管质量，四件事环环相扣，缺一个都会在线上暴露问题。

如果让我给刚开始的人一个建议，我会说：先别追求架构上的大全，也不要急着上多 Agent，就从一条最简洁的 RAG 链路开始，用你自己的业务数据，跑通，然后疯狂问问题，把暴露出来的 case 一个个修掉。等你修到 50 个问题时，你对 AI 工程的理解会比读十本教程都深。这不算什么魔法，它就是朴素的工程实践——每次踩坑都记录下来，把它变成评测集里的一道题，让系统在这个坑上永远不再跌倒。

最后再分享一个小技巧：给知识库问答系统加一个"这个回答有帮助吗"的反馈按钮，用户的一次点击，胜过你离线猜测一万次。把用户反馈和实际回答一起存下来，每周抽一次 bad case 分析，你的系统就会以肉眼可见的速度变好。这个投入产出比，是我做 AI 工程以来遇到过最高的。