企业官网建设流程全解析

最近半年，我面试了不少简历上写满大模型项目经验的候选人，也在内部分享评审时看过大量AI应用Demo，一个反复出现的画面让我很不踏实：理论说得头头是道，现场却交付不出一个能验收的应用。你问“RAG流程怎么设计”，他能从文本切分讲到向量检索再讲到重排序；你问“系统上线后首响延迟多少、召回率怎么标的、检索失败怎么兜底”，他支支吾吾。这不是某个人的问题，而是这个行业正在批量制造的一种八股文——背了很多理论，却没有把理论变成可验收系统的能力。这篇文章我想认真聊聊这个问题，聊聊为什么“背一百个理论，不如交付一个能验收的应用”。

大家先别急着反驳，我并不是说理论不重要。没有Transformer就没有今天的大模型，没有Attention机制就没有RAG的合理性。我想说的是，理论是地图，交付是走路。地图画得再漂亮，腿脚不动，到不了目的地。在AI应用开发、AI Agent、模型部署这些具体场景里，真正卡住团队的往往不是概念不懂，而是交付能力跟不上。这篇主要写给正在做AI应用开发的产品经理、研发工程师，以及想入行AI编程的新人，希望能帮大家把注意力从“背概念”拉回到“做交付”上。

1. AI 八股文的病根：理论正确不等于交付正确

1.1 “术语复读机”制造了虚假熟悉感

AI这行最近一年冒出了一套新八股：简历上写“精通大模型提示词工程”“熟悉RAG检索增强生成”“主导过Agent系统开发”，答辩时术语一个接一个往外蹦，从“幻觉”到“上下文窗口”再到“多智能体协作”，听起来非常专业。可只要追问一句“你负责的Agent系统，Tool调用失败时的重试策略是什么？评测集有多少条？核心指标是多少？”——会议室经常瞬间安静。

这不是个别案例。我过去半年参与了50多个AI项目的评审和面试，简历里提到“RAG”“Agent”“微调”等热词的比例超过八成，但能明确说出自己应用验收指标（比如回答准确率、首响延迟、召回率、兜底策略）的，不足两成。大量项目停留在“教程跑通”阶段：照着LangChain的官方案例改一改，用Streamlit套个界面，就算“完成”了。这种虚假熟悉感非常害人，因为它让从业者误以为自己掌握了AI工程能力，实际上连最基本的工程约束都没碰过。

1.2 理论正确与工程正确是两套逻辑

为什么会出现这种八股文？我自己的体会是，理论语境和工程语境之间存在严重错位。理论告诉你“RAG可以缓解幻觉”，但它不会告诉你：知识库源文件可能是扫描版PDF，解析出来是一堆乱码；理论告诉你“向量检索能找相似内容”，但它不会告诉你：用户提问的表述和文档原文差异很大时，Top5召回可能一条都用不上；理论告诉你“大模型有强大推理能力”，但它不会告诉你：在业务系统里，模型输出并不稳定，你需要设计校验、回退和人工兜底。

理论回答的是“能不能”，工程回答的是“稳不稳、准不准、贵不贵、可不可维护”。很多技术讨论都停在第一层，反复争论不同模型的Benchmark分数、不同框架的抽象设计，却很少聊数据清洗怎么处理、评测集怎么构建、效果回归怎么做、延迟和成本怎么平衡。后面这几个问题，才是决定一个AI应用能不能真正落地的关键，也是“能验收”这三个字的真正含义。

2. 能验收的应用，才是检验AI能力的硬标准

2.1 “Demo能跑”和“应用能验收”之间存在巨大鸿沟

我相信不少人都见过这样的场景：开发同学花两周做了一个AI应用Demo，演示时效果惊艳，完美回答了几个精心挑选的问题，领导当场点头。结果一放开真实流量，用户问法稍有变化，系统就答非所问，甚至直接报错。Demo和应用之间，差的不是一个措辞，而是一整套工程保障。

我习惯用一个简单的标准来判断一个AI应用是否“可验收”：它有没有明确的输入边界、输出形式、质量指标和运行环境。比如一个制度问答助手，输入是员工的自然语言问题，输出是带引用来源的回答，质量指标是Top5召回率不低于85%、回答准确率不低于90%、首响延迟不超过3秒，运行环境是内部服务器或云环境，还要具备日志追踪、失败兜底、人工反馈通道。只要有一条说不清或做不到，这个应用就没有真正交付。

2.2 从“我知道”到“我交付过”需要跨过四个台阶

结合这两年做AI应用、带团队、评审项目的经验，我把AI工程能力分成四个台阶，大家可以对照自测一下：

绝大多数“八股文型选手”停在第一台阶，少数团队勉强够到第二台阶，而AI Agent、AI编程这类热词真正产生价值的地方在第三和第四台阶。我见过不少团队用很复杂的Agent框架搭了一个华丽的系统，最后被运维环节击穿——API Key过期没人管、模型调用成本暴涨没人预警、用户反馈没有收集入口。所以我在内部常说一句话：先别管Agent还是Workflow，先把一个应用的“验收底线”立住，再谈更高级的架构。

3. 一个反八股样本：制度问答助手的验收式开发

为了把上面的观点说得更具体，我拆解一个我们实际做过的项目：企业内部制度问答助手。它的目标是让员工用自然语言提问，比如“年假可以分几次休完”“差旅费报销需要什么发票”，系统基于制度文档库给出准确回答，并且每条回答都附带引用来源。这个项目不算前沿，但足够典型，它几乎涵盖了AI应用开发里所有关键环节。

3.1 先用验收标准倒推需求，而不是先选模型

这个项目启动时，我们做的第一件事不是选大模型，而是写验收标准。产品、研发、业务方一起开了一上午会，把“什么叫做好用”拆成了四个可量化指标：

• 召回率：在预置的200条测试问题上，系统正确召回目标文档的比例不低于85%。
• 回答准确率：回答内容与制度原文一致且无编造，由业务专家抽评，准确率不低于90%。
• 首响延迟：接口从收到请求到返回完整回答，P95不超过5秒。
• 引用可追溯：所有回答必须给出文档标题和原文段落链接，引用缺失视为不合格。

这四条一出来，很多方向性讨论立刻有了结论。比如为什么不做多轮复杂对话？因为验收指标里没有这一条，初期做了反而分散精力；为什么先不用复杂的Agent框架？因为固定流程足够满足当前指标，Agent带来的不确定性在验收阶段是负担。

3.2 技术选型的克制：向量库加固定RAG流程就够了

这个项目的技术栈后来收敛到：一个开源的Embedding模型做文本向量化，一个内部部署的向量数据库做检索，一个大模型做生成，中间用固定的RAG流程串起来。最前面加了一个查询改写模块，用于处理“年假有啥规定”和“我今年还能休几天年假”这类不同粒度的问题。这个选型在很多人看来可能太朴素了，但我的经验是，在AI应用里，“够用且可控”远比“酷炫且不可控”重要。

先说为什么需要查询改写。制度文档里的原文往往是“职工累计工作已满1年不满10年的，年休假5天”，而员工的实际问法是“我工作3年了有几天年假”，两者的语义距离很远，直接做向量检索会漏召回。我们在前面加了一层轻量改写：先用大模型把口语化问题改写成标准查询，同时提取关键实体（工龄、假期类型），再做检索。这个模块不复杂，但把召回率从72%提升到了84%。

再说不使用复杂Agent框架的原因。市面上很多Agent框架把编排、工具调用、记忆、多轮规划都打包好，学习成本和排错成本都很高。在我们的场景里，核心链路是“改写—检索—重排—生成”，这条链路用几百行代码就能串起来，出问题时也容易定位。等到场景复杂度真正上来了，比如需要多工具协同、动态规划、用户多轮澄清时，再引入Agent能力不迟。而且那时候你有评测集和监控日志在手上，改造起来有据可依。

3.3 理论没告诉你的三个落地坑

这个项目做下来，有三个坑我在绝大多数AI理论文章里都没见过，但每一个都差点让项目延期。

第一个坑是源文档解析。制度文档里有大量PDF，其中一部分是扫描件，还有大量表格和页眉页脚。直接解析后拿去切分，会得到一堆乱码和残缺表格。我们最后用OCR加版面分析工具先把PDF转成带结构信息的内容，再做清洗和分段。光这一项，就花了两周。这个工作听起来没有一点技术含量，但它决定了整个检索效果的上限。

第二个坑是评测集的构建。很多团队先写功能，后补评测，这是完全反的。我们的做法是先整理200条真实问题，覆盖高频场景和易错场景，然后逐条标注对应的标准答案和来源文档。整个过程很费人力，但评测集是整个项目的锚点：后面无论换模型、调切分参数、改Prompt，都跑一遍这200条，用数据说话。没有评测集的时候，优化完全是玄学；有了评测集，优化就从经验驱动变成数据驱动。

第三个坑是幻觉控制的工程化手段。验收标准里“回答必须引用原文”这一条，靠Prompt提示是做不到100%的。我们加了两个机制：一是生成时把检索到的原文片段一起传给大模型，并要求输出引用编号；二是后置校验——如果回答里的关键信息在召回文档里找不到对应文本，就把答案降级为“抱歉，我没有在制度库中找到相关内容”。这个兜底机制，比任何Prompt技巧都管用。

3.4 验收不是一次性的，它是一套持续动作

项目交付当天，我们给业务方做了一次现场验收：现场提出20个新问题，系统实时回答，由业务专家判断对错。结果19个回答正确，1个回答因为检索到相似但过时的制度版本而出现了偏差。当场我们就把这个问题记入评测集，并在检索环节增加了版本过滤条件。这件事体现了“能验收”的真正含义：验收不是一个终点动作，而是一套持续的质量保障机制。

上线后我们还接入了日志和反馈渠道，每个回答下方有“有帮助/没帮助”按钮，每周汇总一次失败Case并补充进评测集。第二个月，我们的测试问题集从200条扩展到350条，回答准确率和召回率都在这个过程中持续提升。这个闭环，恰恰是很多理论博客不会写、但AI真实场景里最值钱的部分。

4. 摆脱八股文，真正值得投入的四个实践方向

4.1 先写评测集，再写功能

如果你正在做一个AI应用，我给的最实在的一条建议就是：动手写第一行功能代码之前，先花时间写评测集。哪怕一开始只有几十条，也好过没有。评测集就是AI开发的单元测试，它让你每次改动都有了一个客观的反馈信号。我在制度问答项目里吃过这个亏，后来所有项目都先建评测集，这个习惯帮我避开了无数“感觉效果好了，实际效果却飘忽不定”的困境。

评测集不用一开始就很完美，关键是真实。可以从三类问题入手：一是最高频的问题，二是最容易答错的边界问题（比如“请假超过三天需要谁审批”），三是历史上真实出现的Bad Case。每次模型升级、框架变更、Prompt调整，都全量跑一遍，人工抽评变化点。长期来看，这是投入产出比最高的AI工程投资。

4.2 从固定流程到Agent，走一条渐进路线

AI Agent是今年最热的概念之一，但我的看法可能跟很多人不同：绝大多数业务场景，起步阶段都应该用固定流程，而不是Agent。固定流程的每一步都是确定性的，改了哪个环节、影响哪条路径，一目了然。当固定流程跑到瓶颈，且瓶颈确实来自流程死板、缺乏决策弹性时，才值得把特定环节替换成Agent化设计。

具体来说，可以先固定“改写—检索—重排—生成”这条主链路，把每个环节做成独立模块，并给每个模块配置日志和评测。然后观察哪一步最不灵活，比如查询改写对长尾问题处理不好，就可以把改写模块从“固定Prompt”升级成“带少量工具选择的Agent”，让它自己决定改写还是直接检索。这种渐进式的Agent化，既拥抱了热词背后的技术价值，又不会被复杂框架绑架。

4.3 把AI基础设施和可观测性当一等公民

“AI infra”“模型部署”这两个方向最近热度很高，这其实说明行业正在成熟。再强大的模型、再聪明的Agent，跑在不可观测的基础设施上，都无法长期稳定服务。我见过不少团队在演示时效果一流，可对首响时间、Token成本、API失败率、上下文长度膨胀这些问题完全没有感知，直到线上出故障才发现日志都没接。

我的建议是，AI应用从第一天就要有：结构化日志，记录每次请求的输入、检索结果、生成结果、延迟、Token用量；性能监控，重点关注P95延迟和成本趋势；失败告警，调用失败、空检索、连续降级等场景都要有告警；反馈闭环，用户侧的有用和无用反馈能回流到评测集。这套东西跟业务代码一样重要。很多博客爱讲“提示词工程有多精妙”，却很少讲这些基础设施，但恰恰是它们决定了AI应用能不能活得久。

4.4 让AI编程回归“交付”本质

今年“AI编程”也是个大热词，各种提示词模板满天飞，教你怎么让AI帮你写代码。我的观点是：AI编程的本质不是背提示词，而是利用AI加速从需求到可交付应用的路径。真正高效的AI编程，是你已经清楚知道自己要交付什么、验收标准是什么，然后用AI把重复性、机械性的编码工作快速完成。

举个例子，在制度问答项目中，我们用AI辅助生成了大量数据清洗脚本和接口测试用例，足足节省了将近一周的时间。但前提是，我们自己很清楚清洗规则和测试预期是什么。如果对需求本身一知半解，把希望完全寄托在AI生成上，结果就是在不确定的地基上盖楼。所以AI编程和“能验收的应用”是互相成就的：交付目标越清晰，AI辅助效果越好；AI辅助越快，交付速度越快。

5. 收尾：把“能验收”变成肌肉记忆

5.1 评审AI项目时，我只认验收单

最后再分享一点我在实际带项目过程中的体会。我现在评审一个AI项目，基本不看PPT和架构图，就要一张验收单，上面写清楚三件事：输入是什么，输出是什么，达到什么标准算通过。凡是能当场拿出这份单子并且数据齐全的团队，项目大概率不会差；凡是讲了半小时概念还说不清验收标准的，哪怕名词用得多漂亮，我都要打个问号。

5.2 放下理论焦虑，做一个小而真的应用

这篇文章是“反对AI八股文”系列的第一篇，核心就一条：背一百个理论，不如交付一个能验收的应用。这个系列后面我还会接着写，聊一聊具体怎么拆解需求、怎么设计评测集、怎么在成本和效果之间做取舍。如果你正被海量AI概念和框架弄得焦虑，我的建议很简单——放下那些论文和框架文档，找一个具体而真实的小场景，定一个可量化的验收指标，把它交付出来。做完一个这样的应用，比背一百个理论都管用。