企业官网建设流程全解析

1. 九个月能改变什么：一个二线城市AI应用团队的转折点

九个月能做什么？如果放在两年前，我的答案可能是“够把一个项目从立项拖到验收”。但去年，我在一个中部城市跟着一支不到十人的创业团队，亲眼看着他们把一个只会在Jupyter Notebook里跑通的RAG问答Demo，做成了能稳定服务企业客户的完整系统，还因此被海外技术社区的同行邀请去做分享。很多人把这段经历称为“奇迹”，但我更愿意把它拆成三个90天——每段时间里只解决一类问题，逼着自己不掉队。

这篇文章想写给谁？写给那些和我一样，不在头部大厂、不在核心城市，但想蹭上大模型应用这波浪潮的开发者。如果你正处在“会调API但不知道怎么工程化”“Demo能做但一上线就崩”“什么都想学但不知道先学什么”的阶段，那么这九个月的方法论应该能给你一些可落地的参考。我不会讲太多理论，也不会给你画大饼，只讲一个普通团队如何靠务实的技术取舍，一步步从“能跑”走到“能交付”。

也是因为这段经历，我越来越反感“奇迹”这个词。真正的跃迁从来不靠某一天的灵感爆发，而是靠每个阶段把该踩的坑踩完、该补的课补上。下面我把这条九个月的路线按时间轴拆开，连同当时的取舍逻辑和事后复盘，一起写给你看。

2. 第一个90天：从“调接口跑Demo”到“交付一套知识问答系统”

2.1 起点的真相：团队对“做大模型”的误解有多深

团队最初的状态很有代表性。几个人都是做传统软件出身的，会写Java、Python，也做过一些算法外包，但对大模型的认知基本停留在“训练一个大模型”的层面。当时全组讨论的第一个方案，居然是想找几台机器，拿开源模型自己预训练一个行业基座模型。好在大家冷静算了一笔账：训练数据的清洗、算力成本、调参周期、以及后续维护的人力，都不是十人团队能扛的。

后来我们把目标从“做一个模型”改成“做一个应用”。这个转向是第一个90天里最重要的一次决策。我们决定站在现有大模型能力的肩膀上，用检索增强生成（RAG）来构建一个面向企业内部的知识问答系统。为什么选RAG？因为它的逻辑最贴合真实业务：企业有大量内部文档、制度、技术手册，需要让员工能像问搜索引擎一样快速得到答案。相比微调一个模型去记住所有文档内容，RAG不需要频繁重训，更新知识只需要换库里的文档，成本低、响应快，出了问题也容易溯源。

那段时间我们几乎每个晚上都在讨论一个核心问题：如果只做“大模型API + 向量检索”，我们的壁垒到底是什么？结论是，壁垒不在模型本身，而在把文档处理好、把检索调准、把交互做稳的工程能力。想通了这一点，组里的氛围反而轻松了——因为每个人都知道自己该干什么了。

2.2 RAG链路里最容易被低估的环节：文档处理

很多人想象中的RAG很简单：把文档喂进去，切片，向量化，然后查询。但真正落地时，第一步“文档处理”就把我们折腾了一个月。我们的客户发来的文档里，有PDF、Word、PPT，甚至有扫描版的合同和带水印的图片。PDF里还有大量表格、页眉页脚和分栏排版，直接用通用解析库拉出来的文本经常是乱的。

我们当时做了几件事，每一步都踩过坑：

• 表格内容单独提取。把识别出的表格转成结构化数据（比如JSON或Markdown表格）之后再参与切片；直接按纯文本切，检索时几乎必然丢失行列关系。
• 扫描件先走OCR再进流程。这一步不能省，否则文档里全是空壳文字。
• 样式噪声清洗。页眉页脚、页码、目录、重复的免责声明，全部要在分块前剔除，否则向量空间会被大量无效文本污染。

切片策略也是个反复实验的过程。一开始我们用固定窗口（比如512个字符）无脑切，结果一个问题涉及多个段落时，答案总是残缺不全。后来改成“按文档标题层级优先切块，块过大再二次切分”的策略，每个切片尽量保留相对完整语义。同时块与块之间留了少量重叠，避免检索时把一句话从中间切断。

2.3 检索不是“查到了就行”：重排与混合检索的实战价值

第一个版本上线后，我们最大的挫败不是模型答错，而是模型“自信地答错”——检索结果里明明有正确答案，但排名前三的片段不包含关键信息，模型只能根据上下文里那些不相关的边角料强行生成。这个问题的根源是embedding相似度和“真正符合问题意图”之间，并不总是画等号。

解决办法分两层。第一层是混合检索，把关键词匹配和向量检索结合起来。很多人以为有了向量就不用管关键词了，但实际效果恰恰相反：对一些专有名词、编号、精确型号，BM25这类关键词检索往往比向量更可靠。把两路结果按分数加权融合后，召回率明显提升。第二层是重排，用重排模型对候选片段做精排。检索阶段用轻量模型快速召回100条，重排阶段再精挑5条作为上下文。这一步增加了一点延迟，但答案质量的提升是肉眼可见的。

我还记得当时自己做的一个小实验：问“上一季度的退款率是多少”，单纯向量检索死活找不到对应表格，而混合检索+重排之后，系统准确命中了那张只有几行的汇总表。道理说起来很简单，但很多教程里不会告诉你——检索质量决定生成质量，而检索质量是由文档处理、索引策略、重排策略三者共同决定的。你无法靠一个万能参数把它们全解决。

2.4 没有评测体系就上线，是最蠢的决定

这个阶段我们犯过一个特别蠢的错误：凭感觉调优。调了重排参数，看了几个案例觉得效果不错，就以为可以交付了。结果客户在验收时找测试人员随便问了20个问题，就有6个答案明显是“编的”。当时我整个人都懵了，因为这几个问题在开发环境里明明跑得好好的。

后来我们花了整整一周时间，做了一套最朴素的评测集——也叫Golden Set。我们从客户的真实文档里整理出150个问答对，覆盖制度类、技术类、数据类、流程类四种场景，每类问题再标注难度等级。每次调整链路后，全量跑一遍，记录检索命中率、答案准确率、答案忠实度（即生成内容是否严格基于给定上下文）。有了这个评测集，优化从“拍脑袋”变成了“看分数”，效率完全不一样了。

第一个90天结束时，系统在评测集上的准确率从62%提升到86%，总算跨过了“可演示”和“可试用”之间的那根线。但这只是开始，紧接着客户抛来了更多的需求，也把我们逼进了第二个阶段。

3. 第二个90天：从“答得对”到“答得专业、干得成事”

3.1 为什么RAG搞不定“固定格式输出”

第二阶段我们接到的需求非常现实：客户要求所有回答必须按照某个固定格式输出——先给结论，再给依据，最后附上原文链接或文档编号；涉及对比时，必须输出表格；涉及数字时，必须带上时间和单位。刚开始我们天真地以为，在提示词里写清楚“请按照以下格式输出”就够了。实测却发现，大模型在执行复杂指令时经常顾此失彼：给了格式就忘了引用来源，给了字数要求就丢了关键数字。

这让我重新思考了一个问题：RAG、微调和提示词设计，各自在什么场景下才是最优解。我后来给团队画了一张分工表，也帮你一起理一理：

其实没有哪个是“银弹”，关键在于组合。我们的做法是：用提示词做轻量约束，用RAG保证内容准确，用微调去解决“无论怎么提示都做不到”的问题——也就是强制格式化输出。

3.2 用LoRA做微调，数据量没有你想的那么大

做微调之前，团队里又有人提议“用几千条数据全量微调”。我劝住了。全量微调一来显存开销大，二来容易破坏模型在开放对话上的通用能力。我们最终选了低秩适配（LoRA）这类参数高效微调方法，只训练一小部分额外参数，把原模型冻结住。效果上，训练速度快得多，最关键的是，模型原来会的知识基本不受影响。

数据准备是个手艺活。我们没有刻意追求海量数据，而是把重点放在质量上。整理客户历史对话、让运营同事标注好回答，最终凑了大约1200条高质量样本。每条样本都是一个完整的指令和标准输出：指令里包含用户问题和必要的上下文片段，输出则严格按客户要求的格式写。为了让模型学会“什么场景输出表格，什么场景输出纯文本”，我们还特意把样本设计成不同格式的混合体。

训练参数这边，我们用了很保守的设定：学习率设置在1e-4量级，训练2到3个epoch就停。当时也有同事觉得“多训几轮效果更好”，但我们在第5个epoch时明显看到评测集上出现了过拟合——格式对了，但内容开始重复、机械化。所以做微调一定要留一部分验证集，不能只看训练损失下降。如果模型只学会了“形”而丢掉了“神”，那这个微调就是失败的。

3.3 把问答系统升级成能干活的Agent

第二个90天的后半程，客户提了一个更“野”的需求：不要只回答问题，能不能帮我们直接完成一些操作？比如查一下某个项目的最新进度、按条件筛选一批合同、生成一份日报草稿。这意味着系统必须从“问答机器人”升级成“能干活的数字员工”。

这里就引入了Agent（智能体）的概念。最朴素也最实用的Agent，本质上是一个循环：模型根据用户问题，决定调用哪个工具；工具返回结果后，模型再根据结果决定下一步做什么，直到任务完成。为了落地，我们自己做了一套极简的工具调用协议：为每个工具定义一个JSON Schema，注明名称、参数、返回值格式；模型输出的内容里夹带结构化调用指令，系统拦截到后再真正执行函数。

那段代码有点简陋，但思路很清晰，类似这样：

tools = [ { "name": "query_project_progress", "description": "查询指定项目的当前进度", "parameters": { "type": "object", "properties": { "project_id": {"type": "string", "description": "项目编号"} }, "required": ["project_id"] } } ] # 模型在回答中生成结构化调用意图 # 系统解析意图 -> 执行函数 -> 将结果返回给模型 -> 模型生成最终答复

实操中我们遇到过不少问题。最典型的是循环失控：模型为了查一个数据，反复调用同一个工具，或者把参数猜来猜去，最多的一次跑了十几轮才停下来。后来我们加了两个硬性限制，一是单次任务最大轮数不超过5轮，二是当工具连续返回相同结果时强制终止。另一个坑是模型会凭空捏造工具名，这通常是因为工具描述写得不够清楚，我们后来在描述里加了“该工具用于什么场景、什么时候不要用”，误调用率立刻降了不少。

3.4 复杂Agent vs 固定流水线：别为了“智能”而智能

那段时间我研究了很多所谓的“Agent框架”，也尝试过让模型自主规划、自我反思。效果不能说没有，但成本和不确定性都明显增加。比如让模型自己决定“先查A再查B”，一次任务里可能出现的路径组合太多了，我们根本没办法做回归测试。

后来我们做了一个明确取舍：凡是流程相对固定的任务，直接用代码写死成“固定流水线”，只有流程不确定、需要模型临场判断的任务，才交给Agent动态决策。举个例子，生成日报草稿是固定流程——先查项目进度、再查财务数据、最后汇总成文，这种用瀑布式调用就够了；而“帮我想想这个合同有什么风险”这种开放问题，才适合交给Agent多步检索和推理。

这个取舍让系统的稳定性和可测试性提升了一大截。在真实的业务场景里，“会做减法”比“会做加法”更能体现工程水平。客户不会因为你用了多复杂的架构就给你加分，他们只关心任务能不能稳定完成。

4. 第三个90天：模型部署、推理成本与规模化运营

4.1 功能稳定后，真正的麻烦才开始

前两个阶段结束时，系统的功能已经很完整了：能回答、能格式化、能调用工具。但我们很快发现，客户对系统的评价维度突然变了——没人再关心“你用了什么技术”，而是关心“响应为什么这么慢”“高峰期会不会宕”“这个费用能不能降”。第三个90天，我们基本都被按在部署和成本优化上。

最初我们用的是云端API按量付费，好处是省事，但企业客户对数据出域非常敏感，而且业务量上来后账单吓人。后来我们评估了私有化部署的方案，模型选的是7B量级的开源底座。这里给一个显存估算的方法：7B模型按FP16精度算，光权重就需要约14GB显存，加上KV Cache、激活值和推理框架开销，单卡加载至少需要20GB以上。如果想并发服务多个请求，还得额外预留显存，或者用张量并行把模型拆分到多卡上。

我们最终的选择是先私有化单机部署，再通过排队和限流保护后端。很多团队在演示环境里跑得好好的，一上生产就崩，大多不是因为模型不行，而是因为根本没考虑过并发和限流。

4.2 推理优化的三板斧：量化、缓存、请求合并

部署上线后，我们做了三件很实在的优化。第一是量化。INT8量化在我们的场景里几乎没有精度损失，显存占用却降了接近一半；INT4量化速度更快，但有几个固定格式任务的输出会偶尔丢标点符号，所以我们只在非关键链路上用。“量化一定掉精度”是个刻板印象，实际上要看任务复杂度和量化方法。自己动手测一遍比道听途说靠谱得多。

第二是语义缓存。用户的真实问题有大量重复或近似，比如“退款流程是什么”和“怎么申请退款”在业务上几乎等价。我们用embedding相似度做了语义缓存，命中直接返回历史回答，不再重复调用模型。高峰期实测缓存命中率能到30%以上，大幅降低了有效请求量。

第三是请求合并。对于非实时场景（比如批量生成摘要），我们把多个请求打包成一次推理，减少上下文重复加载的开销。别小看这个细节，当调用量到了一定规模，批处理带来的吞吐提升非常可观。

4.3 上线之后，可观测性和质量抽检不能停

系统一旦上线，最怕的是“坏了没人知道”。我们搭了一套完整的链路日志：每个问题从进入、检索、调用模型、生成回答到返回，每一步的耗时和Token消耗都记录下来。客户投诉时，我们能直接查链路，定位是检索问题还是模型问题，而不是和客户一起“猜”。

Token消耗记录还有一个隐藏价值——它是成本治理的基础。有了它，我们才发现某些客户的高频问题平均要消耗2000多个Token，但答案其实只需要300字。于是我们专门优化了这些高频场景的提示词和检索策略，把上下文压缩到原来的三分之一，成本立刻就降下来了。

另外，我们还建立了一个每天随机抽检100条回答的机制，由运营同事给回答打“是否忠实原文”“是否答非所问”两个标签。抽检比评测集更能反映线上真实分布，因为客户的问题千奇百怪，评测集覆盖不了所有长尾场景。

4.4 那些容易被忽略的安全与权限细节

这部分内容虽然不性感，但我必须提醒每一个准备做B端AI应用的团队：权限隔离和审计日志是底线。企业内部系统面临的第一个问题是越权，比如普通员工理论上不该看到某个财务数据，但如果检索系统把包含数据的文档当成上下文传给了模型，模型就可能“无意间”泄露信息。

我们的做法是给每个文档和知识库打上权限标签，在检索阶段直接按用户角色过滤结果，而不是等模型生成答案后再审查。顺序很重要：先过滤、再生成，不能先生成、后拦截。另外，所有对话和工具调用都要有审计日志，保证出了任何问题都能追溯到“谁在什么时间问了什么、系统调用了什么资料”。这在企业客户那边几乎是硬性要求，但很多技术团队直到被质疑了才想起来补。

5. 复盘九个月：拉开差距的从来不是技术，而是判断力

5.1 三个90天里的“转折点决策”回顾

九个月走下来，我越来越相信一句话：技术团队之间的差距，往往不是谁更能写代码，而是谁在关键时间点作出了更务实的决策。我们把转折点列了一下，发现每个阶段都有一个“差点走偏”的时刻。

第一个90天，差点去做预训练大模型，这是方向性错误。第二个90天，差点为了“Agent而Agent”，把简单的任务复杂化，这是架构上的诱惑。第三个90天，差点把所有精力都花在调模型效果上，忽略了成本、稳定性和数据安全，这是工程化的失衡。每一个转折点，我们最终都是用“客户真正需要什么”来校准的，而不是用“我们觉得什么技术更酷”来驱动的。

当然，这个过程也离不开对市场和客户的持续调研。我们是靠一个个真实需求来验证方向的：客户说“检索不准”，我们就优化检索和评测；客户说“格式不一致”，我们就上微调；客户说“能不能直接干活”，我们就做工具调用和Agent。方向不是坐在办公室里拍脑袋拍出来的，而是从客户的抱怨和反馈里过滤出来的。

5.2 团队分工：算法、工程、产品的黄金比例

这九个月里，团队分工也一直在调整。一开始所有人都扑在“模型效果”上，导致中间层工程一塌糊涂——没有评测脚本、没有部署文档、没有监控告警，就靠大家手动跑。后来我们强制把人员结构调整为：算法（提示词、微调、检索策略）、工程（服务化、部署、可观测性）、产品（需求梳理、客户沟通、样例标注）各占三分之一。

这个结构调整初期有些人不适应，觉得写算法的去干工程是“降级”。但实事证明，只有算法而没有工程，你的模型永远只是模型；只有工程而没有产品，你甚至不知道应该优化什么。尤其是“产品”这条线，在B端AI项目里太重要了：谁来转化客户的模糊需求为具体功能？谁来从历史对话里挑训练样本？谁来设计评测集？这些事看起来不起眼，但都直接决定系统的最终体验。

5.3 客户预期管理：Demo和正式环境的差距

我们吃过一次特别大的亏。有一次给客户做演示，我用的是精心准备的数据集，问题自然个个“完美命中”。客户当场非常满意，合同也签了。结果到了验收阶段，客户拿他们日常真实的数据来测试，效果远不如Demo，气氛一度非常尴尬。

后来我们总结出一条规矩：Demo里用真实数据进行“盲测”，而不是用精挑细选的样例如演示。不只是把最好的case给客户看，也要把最差的case拿出来，坦诚地说明边界在哪里。这反而让客户更加信任我们，因为他们知道你了解自己的系统，知道什么时候该用、什么时候不该硬用。

另外，管理客户预期还体现在“版本计划”上。我们不再承诺“一次交付完美系统”，而是和客户约定好“词条级迭代”的节奏：每两周发布一个小版本，每次解决一类最痛的问题。这样客户能持续看到进展，我们也不至于为了憋大招而把自己逼上绝路。

5.4 什么才是真正的“奇迹”

回头看这段经历，我给“奇迹”重新下了一个定义：它不是在九个月里做完了别人三年的事，而是在每个阶段都没有走偏，每次都把当时最重要的问题解决掉，然后顺理成章地进入下一阶段。

就像爬一座山，你在每个海拔看到的风光不同，要解决的问题也不同——山脚是方向问题，山腰是体力问题，山顶是装备问题。如果一开始就朝着错误的方向爬，或者在该补充体力的阶段非要换装备，再快的速度也白搭。我觉得每个团队都应该定期停下来问自己：“我们在哪个海拔？”“我们现在面对的到底是方向问题、能力问题，还是资源问题？”

6. 如果你也想走这条路：可复制的路线图和避坑清单

6.1 一份可以直接照抄的九个月计划表

经常有人问我，想从传统开发转到大模型应用，第一周该干什么，第一个月该达到什么水平。我根据那次经验，整理了一个比较通用的计划表，你可以按自己的业务场景调整：

身边的朋友问我，我就推荐他们照着这个节奏来。每个阶段结束时都做一个明确“验证点”：能不能给真实用户用？有没有量化数据支撑？如果答案是否，就停下来补课，不要急着进入下一阶段。

6.2 我在九个月里踩过的最值得说的十个坑

这些坑每一个都是真金白银换来的。我按踩坑频率从高到低列一下：

1. 不建评测集就开始调优，等于蒙着眼睛开车。
2. 文档解析不做清洗，向量库里塞满垃圾，检索永远不准。
3. 只做向量检索，不做混合检索，专有名词疯狂召回失败。
4. 提示词写得无比复杂，却不知道模型根本记不住超过两页的指令。
5. 微调后不做回归评测，模型学会了新格式，却忘了旧能力。
6. Agent工具没有轮数限制，线上跑出不可控的死循环。
7. 不记录Token消耗，连成本去哪了都不知道。
8. 私有化部署不考虑并发和限流，一上线就宕机。
9. 忽略权限隔离，系统成了泄露敏感数据的管道。
10. 拿精心挑选的样例做Demo演示，拉高了客户预期。

6.3 “最小业务闭环”核验法：如何判断技术选型对不对

最后分享一个我个人非常受用的方法，我叫它“最小业务闭环核验法”。每次我们想引入一个新方案（比如换一个更强的模型、上马一套Agent框架），先不要急着搭架构，而是问自己一个问题：我只用最小的代价，能不能在一个真实的业务场景里跑通一个闭环？

举个例子，当时团队有人主张用一个更复杂的Agent框架来替代我们的极简工具调用协议。我没有直接反对，而是拿了一个真实任务做对比：同样一个“查询项目进度并生成日报”的需求，用老方案写死流程只要一天，用新框架要配记忆、规划、反思模块，至少一周。而且老方案的可控性更好。于是这个提案就被否决了。

同样的方法，我们也用在了“要不要换基座模型”“要不要自建向量库”这类决策上。凡是能在小闭环里验证就尽量先验证，不要为一个“听起来更先进”的方案支付过高的试错成本。这个方法不一定能帮你选到最优方案，但能帮你在最短时间内排除最不该选的方案。

6.4 给二线城市技术团队的一碗实在话

如果让我给同样身处非核心城市、非大厂团队的朋友几句实在话，我想说：地理距离不是做不成AI应用的理由。现在的基础设施和大模型生态已经把门槛拉得很低了，很多能力只需要学习和实践就能获得。

但我也必须诚实地说，二线城市团队有一个天然劣势——缺少同频交流的环境。这需要我们更主动地在网络上输出、分享和参与开源社区。我们当时正是因为在社区里写了几篇RAG实战踩坑记录，才被海外团队注意到的。所以，不要闷头做事，把你的实验、你的失败、你的经验写出来，它会以你意想不到的方式回报你。

另外，第一性原理的思考方式一定要刻意训练。遇到问题多问一句“这个问题的本质是什么”，而不是直接跳到“我要用什么技术方案”。九个月的经历告诉我，正确答案往往出现在你把问题定义清楚之后，而不是在技术方案清单里。

最后再说一句：如果你正在犹豫要不要开始，我的建议是现在就找一个真实的业务场景，哪怕是帮你自己整理一个个人知识库，用一周时间把它做成一个能跑的东西。开始的姿态难看没关系，关键是别停在原地。九个月后回头看，你会感谢今天迈出的这一步。