企业官网建设流程全解析

这几年我帮不少团队做过AI项目方案评审和技术复盘，一个很明显的感受是：很多程序员基础功相当扎实，缓存、队列、分库分表、灰度发布、幂等设计这些传统后端技能都门儿清，但一旦面对AI系统设计，整套思路就卡住了。同样是画架构图，传统系统输入输出是确定的，数据库表结构、接口契约、消息格式都能提前定死；而AI系统要面对的是一堆不确定的东西——模型输出不可控、Token要花钱、上下文窗口有限、向量召回质量飘忽不定、幻觉概率无法清零。这些维度在传统系统设计里根本找不到对应物，所以不少人第一次做AI项目时会本能地用老方法去套，结果往往很惨。

这篇文章想做的，就是把程序员从传统后端到AI系统设计之间缺的那块拼图补上。我会讲讲AI系统设计和传统设计的本质差异，拆解模型接入、上下文工程、RAG检索、Agent编排这几个程序员最需要补的核心模块，再用一个完整的知识库问答系统设计案例，把参数估算、架构分层、选型对比讲透，最后整理一份高频问题排查速查表。无论你是准备转AI方向、要应对AI系统设计面试，还是想在自己负责的业务系统里接入AI能力，这份内容都能给你一个从0到1的完整参照系。

1. 传统系统设计经验，为什么在AI项目上失灵了

1.1 确定性假设：传统设计的根基在动摇

做传统后端的人，脑子里都有一套默认的“确定性假设”：接口契约定了就是定了，数据库一个事务要么提交要么回滚，消息队列保证不丢不重，幂等键挡住重复请求。我们衡量一个系统好不好，看的是QPS、延迟P99、可用性几个点，方法论也成熟，缓存穿透怎么办、热点key怎么办、分库分表怎么做，这些早就有标准答案。

这套东西在AI系统里依然重要，但不够了。AI系统引入了一个传统设计里几乎不存在的变量——模型行为的不确定性。同一个问题问大模型两次，措辞可能不一样，也可能一次答对了、一次一本正经地胡说八道。这不是bug，而是模型本身的概率采样机制决定的。你没法用传统的单元测试去锁定模型的行为，因为你连“预期输出”都很难定义。

但这不意味着AI系统设计就完全没有确定性可言。我自己的理解是：确定性的重心从代码层转移到了评估层。传统系统我们约束的是函数逻辑，AI系统我们要做的是用评测集、回归基线、幻觉检测规则把模型的行为边界框住。优秀的AI系统设计者，脑子里永远有两套东西并行：一套是传统的工程保障体系，另一套是针对模型不确定性的评估和兜底体系。

1.2 AI系统新增的两个硬约束：不确定性、成本

除了不确定性，AI系统设计还多了一个传统后端几乎不用操心的问题：Token成本。传统系统加一台服务器、加个缓存，成本是可预估的；AI系统每次调用都在烧钱，输入越长、输出越多、模型档位越高，单次成本就越高。而且这个成本不是线性的——一个设计不当的RAG链路，可能每次请求都把一大堆无关文档塞进上下文，费用翻好几倍，效果反而更差。

所以AI系统设计本质上是在三个维度之间做权衡：效果、成本、延迟。传统设计追求的是性能和可用性，AI设计还得盯着“每一块钱换来了多少分的效果”。这两个新维度——不确定性和成本，就是程序员补AI系统设计时首先要建立的思维模型。

还有一个维度容易被忽略：可观测性。AI系统的错误不像传统系统那样直接报异常，而是静默地给出一个错误答案。如果你的日志里只记录了响应状态码和耗时，不记录模型输出、检索结果、Token消耗、上下文内容，那出了问题你连排查的抓手都没有。所以AI系统的日志设计也比传统系统重得多，这一点后面在排查章节我还会展开。

2. AI系统设计的四个核心模块

2.1 模型接入层：别把模型调用当普通API封装

很多程序员第一次接大模型接口时，习惯性地把它当成普通HTTP API：封装一个Client，定义好入参出参，超时设成3秒，重试两次，完事。这个思路在大模型场景下会踩很多坑。

大模型接口有几个和普通API非常不一样的特征。一是延迟波动极大，简单问题可能一两秒返回，复杂推理可能几十秒，而且同一个问题不同时间的耗时也不稳定，这和普通接口那种稳定的毫秒级延迟完全是两码事。二是流式和非流式的输出策略会直接影响用户体验——你要等整个回答生成完才展示，还是首字出来就边生成边打字？对终端用户来说，等待首字的时间和打字机效果带来的体感差异非常巨大。三是重试机制要格外小心，普通接口重试一次顶多多打一次数据库，大模型接口重试一次就是双倍Token费用，如果网络抖动导致请求实际上已经到达服务端，重试还会产生重复扣费。所以重试一定要配合幂等机制和超时策略，不能无脑retry。

我在实际评审中见过一个真实案例：某个AI问答功能上线后，运维报告模型服务调用量是业务请求量的三倍多，查下来就是重试策略没做精细化控制，加上冷启动阶段多个模块各自重试、重复调用，费用直接失控。后来统一收敛到模型网关层，做多模型路由、熔断、重试、语义缓存，同一份能力收口到一条链路，费用和稳定性才恢复正常。这个教训说明一个道理：模型接入层不能散落在各个业务代码里，必须做成一个独立的网关服务，就像传统架构里数据库访问要收口到DAO层一样。

2.2 上下文工程：Token才是真正的数据库

传统系统设计里，数据放在数据库，查询靠SQL，存储靠磁盘，这是根深蒂固的思路。AI系统的存储逻辑完全不同——模型的“数据库”是上下文窗口，你要让模型“知道”什么，就得把对应的文本放进上下文里。没有索引，没有外键，只有Token的数量限制和计费规则。

所以AI系统设计的一个核心基本功就是上下文工程：在有限的上下文窗口里，以最小成本装下对回答最有帮助的信息。这听起来简单，做起来全是细节。系统提示词负责角色、规则、输出格式，相当于服务端的全局配置；动态插入的检索结果、对话历史、用户输入，才是每次请求真正要组织的数据流。上下文不是越长越好，有些模型对中间位置的注意力会衰减，塞太多无关内容反而会稀释关键信息，导致效果下降。

上下文工程里有一个特别典型的坑：多轮对话场景中的上下文漂移。对话进行到第十轮，如果每轮都把完整历史塞进去，Token消耗呈线性增长，而且越往后模型越容易被早期信息干扰，回答质量波动很厉害。解法一般有滑动窗口、历史摘要压缩、关键信息抽取这么几条路。我的经验是，对话历史保留要分层：最近几轮对话完整保留，更早的内容先做摘要压缩，与当前问题无关的早期细节直接丢弃。这比设计任何花里胡哨的功能都更影响实际体验。

2.3 RAG检索增强：让模型学会查资料

RAG是目前AI应用里绕不开的一个模块，核心思想很朴素：模型不知道的知识，你先把资料查出来，再当成上下文喂给它。它解决的是大模型私有知识缺失和知识更新不及时的问题，比微调成本低、见效快，也是绝大多数企业内部AI应用的标配能力。

但很多首次做RAG的程序员会把它简化成“三步走”——文档切碎、存向量库、查询时召回，然后拼进提示词。这个流程看起来简单，真正落地到处是细节。首先是切分策略：切得太碎，单块内容缺少上下文语义；切得太整，召回精度下降，浪费Token。我见过一份企业内部文档，目录结构清晰、分章节明确，有人直接用固定字符长度切块，把完整的章节切断，结果就是检索时经常只召回半截内容，模型读着读着就断档了。正确做法是先按文档结构和语义段落切，再设定重叠区域，保证上下文连贯。

接着是召回策略。关键词搜索能精确匹配词面，但撞不上语义近义；向量检索能处理语义相关，但偶尔会召回表面相似实际无关的内容。所以成熟一点的方案都用混合检索：BM25关键词召回和向量召回并行，再用重排模型对合并结果做精排。这里有一个关键参数很容易被忽略——TopK和相似度阈值。TopK太大，无关内容混进来稀释干扰；TopK太小，正确答案漏掉。相似度阈值设太高会把相关内容全部过滤掉，设太低又会把垃圾内容全放进来。很多人调RAG效果不好，本质是在这几个参数之间没有找到平衡，而不是模型不行。

2.4 Agent编排：从单次调用到闭环任务

当AI系统从“一问一答”走向“完成任务”，就要引入Agent的编排能力。Agent的本质是让模型能够调用外部工具、拆解任务、验证结果，并在一个循环里推进多步操作。对程序员来说，理解Agent最好的切入点，是把它类比成一个异步任务编排引擎——只不过每个任务节点的执行者不是确定的代码，而是带推理能力的模型。

Agent编排最常见的一个坑是缺少明确的终止条件。传统系统的流程有明确的状态机，而Agent如果设计成“模型想做什么就做什么”，很容易陷入反复调用工具、反复试错的死循环。我见过一个自动化报告生成Agent，模型在某个数据源查询失败之后，会换个参数重试多次、再尝试另一个工具获取数据，来回折腾十几轮才放弃，一次任务的Token成本比正常路径贵了十倍。这个问题的解法是给Agent加执行预算：最大轮数限制、单轮成本上限、步骤超时、失败兜底路径，必须一开始就在编排层写死。

Agent还有个安全边界问题要重视。哪些操作允许模型自动执行，哪些必须人工确认，这不能靠模型自觉。传统后台系统的权限控制挂在用户角色上，Agent系统还要多一层“工具权限”——模型只能调用预先授权且动作受限的工具，涉及删除、修改、发送等副作用较强的操作，必须走人工审批队列。这不是保守，而是对系统稳定性的基本负责。

3. 手把手设计一个知识库问答系统

3.1 需求分析与系统边界

理论讲完，落到实操。这里我给出一个通用的设计案例，你可以直接当成一个练习模板：某公司要把内部约50GB的文档资料做成一个智能问答助手，供1000名员工日常查询使用，包含制度文档、技术文档、项目资料。预期高峰并发是20个用户同时提问，对答案的要求是必须给出引用来源，不允许凭空编造。

第一步永远是划边界。这个项目不做模型训练、不做全局搜索，只做文档语义问答；多轮对话要支持，但只保留最近几轮上下文；权限控制要接公司现有账号体系，文档访问权限需要遵循原有目录权限。边界划清楚之后，后面每个模块的设计目标就有了依据：哪些地方要重投入，哪些地方能简配，都清晰了。

这个需求里最核心的难点是答案可溯源。用户问“请假的审批流程是什么”，系统不仅得回答流程步骤，还必须告诉用户这个答案来自《员工手册》第几章第几节。这实际上把RAG链路和传统系统的审计要求结合在了一起，很多AI项目就是倒在这个要求上——因为检索链路任何一个环节出问题，来源就跟着错。

3.2 架构分层与核心链路

针对这个需求，我的设计思路是按六层划分：接入层、会话层、检索层、模型层、存储层、可观测层。接入层负责Web端和IM入口对接，统一鉴权；会话层管理对话状态与上下文压缩；检索层是重头戏，内部再细分为关键词召回、向量召回、重排三步；模型层承载主问答模型、摘要压缩模型、重排模型三类能力；存储层放文档元数据、向量索引、对话缓存和审计日志；可观测层独立出来，专门记录每次请求的Token用量、链路各阶段耗时和模型输出快照。

核心请求链路是这样的：用户提问进来，会话层做历史摘要压缩，把最近三轮完整对话加上早期摘要拼成会话上下文；同时检索层接收用户问题，做查询改写和混合检索，从知识库召回候选文档段落；重排模型对候选段落精排后，取TopK结果拼入系统提示词；模型层根据“只能基于给定材料回答并标注来源”的约束生成最终答案；回答返回给用户的同时，把引用来源、检索结果、Token消耗写入审计日志。

3.3 关键参数估算过程

系统设计不能只画图，还得算账。这个案例里几个关键数字我实际推演一遍，大家以后做类似项目可以直接套这套估算思路。

第一个是Token吞吐估算。假设每个问答平均输入约1500 Token（包含系统提示词、检索上下文、对话历史），输出约500 Token，那么单次请求吞掉2000 Token。高峰20并发时，每秒消耗4万Token。按一个工作日8小时、平均请求间隔拉长到每用户每小时3次来算，日均请求量约24000次，日均消耗约4800万Token。这个数字直接决定模型费用的量级，也是做预算和配额设计的起点。

第二个是向量存储量估算。50GB文档按中文平均每个汉字约1.5 Token折算，文本Token量约5000万到1亿。切块大小设置为512 Token、重叠64 Token，大约能产生20万到25万个向量块；每个向量按768维、FP32存储占用约3KB，向量库总存储量约1GB以内，加上索引和副本也不会超过几个GB。这个量级用单机完全可以扛住，根本不需要上分布式。

第三个是缓存命中率收益估算。内部知识库问答的重复提问比例相当高，员工问的问题集中度也高。加入语义缓存后，我们可以对用户问题做向量化匹配，命中历史问题时直接复用缓存答案，假设缓存命中率按30%算，就能砍掉近三分之一的高峰Token消耗。这就是我说的“AI系统也要讲缓存设计”，只不过缓存key从业务ID换成了问题向量。

3.4 选型对比与取舍

选型这块我给一个通用的决策框架，不绑定具体商业产品。第一层是架构模式选型：自研RAG链路还是用现成的Agent框架？我的建议是，如果核心场景就是标准的知识库问答，自研可控性远高于套框架，因为框架抽象会绑架你的上下文结构，出了问题很难定位；如果要做复杂多工具编排，可以先用框架快速验证，再逐步替换关键模块。

第二层是模型选型：商用大模型API和开源模型自部署各有利弊。知识库问答场景对中文理解、长文本归纳、指令跟随要求较高，商用API效果有保障但单位成本高；开源模型自部署初期成本大但边际成本低，适合对数据安全要求高、调用量大的场景。这个案例因为数据量中等、并要求审计溯源，我倾向于商用API为主、离线任务走开源模型，两类模型分层使用。

第三层是向量检索存储选型：专用向量数据库和关系数据库向量插件怎么选？员工规模不大、向量量级在百万以内时，关系数据库自带的向量能力完全够用，架构简单，运维成本低；数据量到千万级以上、有高并发低延迟要求时，再考虑独立向量数据库。不要一上来就为了AI项目引入重组件，能用简单方案顶住的阶段，简单就是最大的优势。

4. AI系统设计高频问题排查实录

4.1 模型幻觉：答案看着权威，其实是编的

幻觉是AI系统设计里绕不开的坎。从工程角度说，幻觉问题无法彻底消除，只能通过系统和流程设计把它控制到可接受范围。最实用的三招是：一是限定知识来源，系统提示词里明确要求模型“只能基于提供的参考材料回答，材料中没有的内容明确回答不知道”；二是要求逐句标注引用来源，答案里每个关键论断后面都要挂对应的文档来源，这就给了用户和审计人员一个核查抓手；三是在模型和用户之间加一道规则校验层，用关键词抽取和规则匹配检查答案是否真的引用了检索结果，没引用的回答打回重答。

实操中我发现一个容易忽略的细节：系统提示词里的限定写得再严格，如果检索结果本身质量差，模型还是会按照“被污染的上下文”来生成答案。所以与其花大力气在提示词上压制幻觉，不如先把检索质量做到位。没有好材料，再强的约束也白搭。

4.2 检索质量差：答非所问时先查链路

检索质量差是RAG系统最常被吐槽的点，表现就是用户问东、系统答西。遇到这种情况，很多人第一反应是调模型，换更大的模型、改提示词，实际上大多数问题出在检索链路。我的排查顺序固定是：先看TopK召回结果里有没有正确答案，如果正确答案就没有被召回，那是切分和向量召回的问题；如果答案在召回结果里但最终输出没用上，那是重排或者提示词组织的问题；如果答案在召回结果里，模型也引用了，但引用的是无关段落，那是重排排序和上下文裁剪的问题。

切分层面的调整方向通常是：块大小与文档结构是否匹配、是否有语义断句、重叠区域是否过大导致冗余。召回层面的调整方向是：TopK是否过小、相似度阈值是否过严、查询改写是否必要——很多时候用户的提问口语化严重，直接拿去向量检索效果很差，先用一个小模型把口语问题改写成规范查询语句，召回质量能提升一截。这个技巧投入产出比很高，值得优先尝试。

4.3 延迟和成本失控：两个最容易被忽视的隐形杀手

AI系统的延迟和成本问题，往往是设计阶段埋下的。延迟方面最常见的问题是设计同步调用链：检索、重排、模型生成依次同步执行，端到端延迟被累加。如果模型输出还要非流式等全部生成完才返回，用户感知的等待时间会非常长。优化手段除了流式输出，还可以让检索和重排更早并行，把检索引擎做成高吞吐低延迟服务，主模型调用等待期间提前把检索结果准备到位。

成本失控的典型原因，一个是日志和调试信息把完整上下文和模型输出全量落盘，日志存储成本惊人；另一个是上下文膨胀——每次请求塞入过多历史对话和冗余检索内容，Token消耗翻倍但效果没有提升。我建议每个AI系统都要做Token预算管理：给单次请求设定Token上限，超出则触发裁剪或简化；同时按天监控每用户Token消耗和缓存命中率，设置费用告警阈值。很多团队是在月底看到账单才知道控制成本，这显然太晚了。

4.4 高频问题速查表

5. 程序员补AI系统设计的一条最短路径

如果你时间有限，只想抓一条主线，我的建议是：先学会画Token流向图。不是架构图，是“从用户提问到最终返回，每一步哪些文本流进模型、哪些文本被丢弃、哪些文本进了日志和审计”的数据流图。AI系统设计的绝大部分问题，都能在这张图里提前暴露出来。上下文膨胀、重复检索、缓存命中、成本失控、审计缺口，全部藏在这张图里。

画Token流向图的时候，有几个具体的检查点你可以对着过一遍：每次请求的输入由哪些部分组成，总Token量是多少；哪些部分被重复拼入多轮对话但实际没什么用；历史对话压缩策略是不是真的生效；检索结果有没有做去重和裁剪；日志和审计里存了哪些敏感信息，存储成本是否可接受；缓存系统在哪些环节能拦下重复请求。我自己的习惯是在方案阶段就把这张图画出来，把每个节点的Token量标上去，算一次总账，很多设计问题当场就浮出水面了。

最后再说一个我在实战里反复强调的点：AI系统设计能力不是靠读几篇文档就能建立的，它要求你同时具备传统系统的工程严谨性和对模型行为边界的感觉。后者的建立，只能靠多参与真实项目、多复盘失败案例。我的建议是从一个小范围的知识库问答工具开始，把全文链路走一遍，再逐步加权限、加多轮、加Agent编排。等你能独立把一个百人规模的内部AI工具做到稳定、可用、成本可控，你对AI系统设计的理解，就已经超过大多数只会调接口的人了。