企业官网建设流程全解析

室内设计这个行业，表面看是创意驱动，实际上大量时间耗在重复沟通、方案比稿、材料询价和施工交底上。一个中型设计公司，设计师平均每天要花三到四成时间处理"这个材料还有没有货""上次那个户型图放哪了""客户问的报价含不含软装"这类问题。我接触过几家设计工作室，他们最朴素的诉求就是：能不能让AI把那些翻聊天记录、翻网盘、翻Excel的活儿接过去。这个项目要做的，就是给一家室内设计公司搭一套AI智能体系统，包含5个业务Agent和一个RAG知识库。整套需求清单和预算已经列好，我把它拆开揉碎，从业务逻辑、技术选型、成本构成到落地踩坑，完整讲一遍。

1. 先搞清楚设计公司到底需要AI接什么活

1.1 五个Agent不是拍脑袋定的，是从业务流里长出来的

很多人一上来就问"我要做几个Agent"，这个问题本身是错的。正确的问法是：公司里哪些岗位每天在做重复性信息处理？我把室内设计公司的典型业务流拆成五段，每段对应一个Agent，这样划分的依据是"信息输入输出边界清晰、可独立验证"。

第一段是客户咨询与需求初筛。客户在微信、电话、表单里丢过来的信息往往是碎的："我家120平，三室两厅，喜欢奶油风，预算30万左右，什么时候能出图？"这些信息需要被结构化：面积、户型、风格偏好、预算区间、时间预期、特殊需求（比如有老人要无障碍、有宠物要防抓材料）。这个Agent的输出是一张标准需求卡，直接进CRM。

第二段是方案素材检索与匹配。设计师拿到需求卡后，需要快速找到相似户型、相似风格的历史案例、效果图、材料清单。这个Agent连接RAG知识库，把公司过去几年的项目资料变成可检索的资产。

第三段是材料与报价辅助。这是最耗时的环节。客户问"这个岩板多少钱一平"，设计师要翻供应商报价表、算损耗、加人工、加管理费。这个Agent要能根据材料名称、规格、用量，给出参考报价区间，并标注数据来源和更新时间。

第四段是施工交底与进度问答。施工队在现场问"这个节点收口怎么做"，项目经理要翻图纸、翻规范。这个Agent把施工规范、节点大样图、历史交底记录做成问答库。

第五段是客户跟进与话术生成。设计师要定期跟进客户，但每次写跟进话术很费神。这个Agent根据客户当前阶段（初次接触、已出方案、已报价、待签约、已签约），生成合适的跟进内容和提醒。

这五个Agent的划分逻辑是：每个Agent对应一个明确的岗位角色，有独立的输入输出，可以单独上线、单独评估效果。不是按技术模块分，而是按业务动作分。这一点很关键，因为设计公司老板不关心你用什么模型，他只关心"我的设计师能不能少加两小时班"。

1.2 RAG知识库不是"把文件丢进去"那么简单

RAG（检索增强生成）这个词现在被用烂了，很多人以为就是把公司网盘挂上去。实际做过就知道，设计公司的资料有几个特点：格式杂（PDF、PPT、Excel、图片、CAD图纸、微信聊天记录截图）、版本多（同一个方案改了八版）、非结构化严重（大量信息在图片和聊天记录里）。

所以这个项目的RAG知识库需要做三层处理。第一层是原始资料清洗与分类：把资料按"项目案例""材料库""施工规范""报价模板""客户沟通记录"五类归档，每类有独立的元数据字段。第二层是多模态解析：PDF和PPT提取文字，Excel提取表格结构，图片用OCR提取文字并用视觉模型生成描述，CAD图纸提取图层信息和标注文字。第三层是切片与索引：不是简单按字数切，而是按"语义单元"切——一个材料条目是一个切片，一个施工节点是一个切片，一个客户需求卡是一个切片。

这里有个经验：切片粒度直接决定检索质量。切太碎，检索出来的片段没有上下文；切太大，噪声太多。我的做法是让每个切片自带"标题+正文+来源+时间+项目编号"五个字段，检索时先按元数据过滤，再做向量匹配。这样即使向量模型不够强，也能靠元数据把范围收窄。

1.3 预算的构成逻辑：钱花在哪，为什么这么花

需求清单里列了预算，但很多人看不懂钱为什么这么分。我把预算拆成四块：模型调用费、向量数据库与存储、开发与集成、运维与迭代。

模型调用费是大头，但也是最容易被低估的。一个设计公司如果有20个设计师，每人每天触发50次Agent调用，每次调用平均消耗2000 token（输入+输出），按当前主流API价格，一个月大概在几百到一千多块。但如果RAG检索返回的上下文很长，token消耗会翻倍。所以预算里必须留出"上下文压缩"的优化空间。

向量数据库与存储这块，如果资料量在十万级切片以内，用轻量方案就够，不需要上重型集群。开发与集成是一次性投入，但要注意：集成到现有工作流（微信、企业微信、设计软件）的成本往往比开发Agent本身还高。运维与迭代是长期费用，包括资料更新、效果评估、提示词调优。

提示：预算表里一定要单独列一项"资料整理人力成本"。很多项目失败不是因为技术不行，是因为没人愿意把历史资料整理成机器能用的格式。这部分工作量往往被严重低估。

2. 五个Agent的技术实现路径与选型理由

2.1 需求初筛Agent：为什么用"规则+小模型"而不是直接上大模型

需求初筛Agent的任务是把非结构化对话转成结构化需求卡。最直接的做法是丢给大模型做信息抽取，但实测下来有两个问题：一是成本高，每次对话都调大模型不划算；二是稳定性差，同一个客户说"三室两厅"和"3房2厅"，大模型有时抽取得不一致。

我的方案是两层处理：第一层用规则引擎做关键词匹配和正则抽取，覆盖80%的常见表达（面积、户型、预算数字、风格词库）；第二层用一个小参数量的模型做兜底，处理规则没覆盖到的长尾表达。这样成本降下来，稳定性也上去了。

具体实现上，规则层维护一个"同义词表"，比如"奶油风/法式奶油/轻法式"归到同一风格标签，"半包/全包/整装"归到同一服务类型。小模型只负责判断"这句话里有没有规则没识别到的需求信息"，如果有，再触发大模型做精细抽取。这个设计的关键是：不要让大模型做它不擅长的事，规则能搞定的绝不调模型。

2.2 素材检索Agent：RAG的检索策略比模型选择更重要

素材检索Agent的核心是RAG。很多人把精力花在选哪个向量模型上，但实际效果差异最大的地方是检索策略。

我采用的是混合检索：向量检索负责语义相似，关键词检索负责精确匹配（比如项目编号、材料品牌、户型代号）。两路结果合并后做重排序。重排序用一个轻量交叉编码器，对Top 20结果重新打分，取Top 5送给生成模型。

这里有个细节：设计公司的素材检索往往带有强过滤条件，比如"只要最近两年的""只要这个小区同户型的""只要现代简约风格的"。所以检索接口必须支持元数据过滤，而且过滤要在向量检索之前做，不是之后。先过滤再检索，速度和准确率都更好。

另外，图片素材的检索要单独处理。效果图不能只靠文字描述检索，要用视觉模型生成结构化描述（空间类型、风格、主色调、主要材质、家具布局），把这些描述存进向量库。设计师搜"客厅 原木色 无主灯"，能直接命中对应效果图。

2.3 报价辅助Agent：为什么必须做"数据溯源"

报价辅助Agent最怕的是"胡说八道"。客户问一个岩板价格，Agent给了一个数，设计师拿去报价，结果实际采购价差一倍，这个责任谁负？所以这个Agent的设计原则是：只做检索和计算，不做生成式报价。

具体做法是：材料价格全部来自结构化的供应商报价表，Agent只负责根据材料名称和规格去查表，然后按公式计算（材料单价×用量×损耗系数+人工费+管理费）。所有输出必须附带"数据来源"和"最后更新时间"。如果查不到，Agent明确说"未找到该材料报价，请人工确认"，而不是编一个数。

这个设计牺牲了一些"智能感"，但换来了可信度。在设计公司场景里，可信度比智能感重要得多。设计师可以接受Agent说"我不知道"，但不能接受Agent给错数。

2.4 施工交底Agent：知识库的"时效性"是最大挑战

施工交底Agent连接的是施工规范和节点大样库。这个Agent的特殊之处在于：规范会更新，工艺会迭代，不同项目可能有特殊做法。

所以这个Agent的RAG知识库需要加一个"时效性权重"。检索时，越新的资料权重越高，但历史经典做法也不能完全丢弃。我的做法是给每个切片打两个标签：生效时间和适用项目范围。检索时先按项目范围过滤，再按时间衰减排序。

另外，施工交底场景下，图片和图纸的检索比文字更重要。施工队问"这个收口怎么做"，最好的回答是一张节点大样图加一段说明。所以这个Agent的输出要支持图文混排，而且图片要能定位到具体图集页码。

2.5 客户跟进Agent：话术生成要"像人"但不能"太像人"

客户跟进Agent根据客户阶段生成跟进话术。这个Agent的难点是：话术要自然、有温度，但不能过度承诺、不能涉及敏感信息。

我的做法是模板+变量填充+风格微调。先定义每个阶段的话术模板，模板里留变量位（客户称呼、项目名称、上次沟通要点、本次跟进目的）。然后用模型做风格微调，让话术不那么生硬。但模型只做"润色"，不做"内容生成"，所有关键信息（价格、工期、承诺）都来自模板变量，不经过模型自由发挥。

这样既保证了话术的自然度，又避免了模型乱承诺的风险。实测下来，设计师对这类"半自动"话术的接受度反而比"全自动生成"更高，因为他们能控制关键信息。

3. RAG知识库的搭建细节与数据治理

3.1 资料清洗：最脏最累但最不能省的一步

设计公司的历史资料，我见过的典型状态是：网盘里几百个文件夹，命名混乱（"最终版""最终版2""真的最终版"），PPT和PDF混在一起，Excel报价表有几十个版本，微信聊天记录里散落着大量客户需求和确认信息。

清洗的第一步是去重。不是按文件名去重，而是按内容哈希去重。很多"最终版2"其实和"最终版"内容一样。第二步是版本归并，同一个项目的多个版本，保留最新版，但旧版的变更点要提取出来作为"变更记录"存入知识库。第三步是格式统一，所有文档转成纯文本+结构化元数据，图片单独走视觉解析流程。

这一步的工作量，以一家有五年历史、积累了几百个项目的设计公司为例，大概需要一到两个人全职整理两到三周。这个时间必须算进项目周期，不能指望"边用边整理"。

3.2 切片策略：按"业务语义单元"切，不按字数切

切片是RAG质量的分水岭。我见过太多项目用"每500字切一片"的粗暴做法，结果检索出来的片段要么断章取义，要么包含大量无关内容。

正确的做法是按业务语义单元切。具体来说：

• 项目案例：一个项目一个切片，包含项目基本信息、风格、面积、主要材料、设计说明。
• 材料条目：一个材料一个切片，包含名称、规格、品牌、参考价、供应商、更新时间。
• 施工节点：一个节点一个切片，包含节点名称、适用部位、做法说明、大样图引用。
• 客户沟通记录：一次沟通一个切片，包含时间、参与人、沟通要点、待办事项。
• 报价模板：一个模板一个切片，包含模板名称、适用场景、费用构成、计算规则。

每个切片控制在200到800字之间，太短的合并，太长的拆分。关键是每个切片必须能独立回答一类问题。

3.3 元数据设计：让检索"先过滤再匹配"

元数据是RAG的隐形骨架。我的元数据字段设计如下：

检索时，先用"来源类型+项目编号+风格标签+空间类型"做过滤，再在过滤结果里做向量匹配。这样即使向量模型一般，也能靠元数据把准确率拉上来。

3.4 更新机制：知识库不是建完就完了

很多公司做完知识库就不管了，结果半年后检索出来的还是旧报价、旧规范。所以必须设计更新机制。

我的方案是双通道更新：一是定期批量更新，每月把新增的项目资料、材料报价、规范变更批量导入；二是实时增量更新，设计师在用的过程中发现知识库有误或缺失，可以通过一个简单表单提交修正，经审核后即时更新。

这里有个经验：更新流程要尽量短。如果更新一个材料价格需要走五步审批，没人会去更新。我的做法是材料价格由采购岗直接维护，项目资料由项目助理维护，规范由技术负责人维护，各管各的，系统只做格式校验和版本记录。

4. 预算拆解与成本控制实战

4.1 模型调用费：怎么算，怎么省

模型调用费的计算公式是：日均调用次数 × 平均token消耗 × 单价 × 30天。以一个20人设计团队为例：

• 需求初筛Agent：每天约100次调用，每次约1500 token。
• 素材检索Agent：每天约200次调用，每次约3000 token（含检索上下文）。
• 报价辅助Agent：每天约80次调用，每次约1000 token。
• 施工交底Agent：每天约60次调用，每次约2500 token。
• 客户跟进Agent：每天约120次调用，每次约800 token。

合计每天约560次调用，平均每次约2000 token，一天约112万token。按主流模型价格，一个月大概在几百到一千多块。这个成本对设计公司来说完全可以接受，但前提是做好上下文压缩。

省钱的三个手段：一是规则前置，能规则搞定的不调模型；二是检索结果重排序后只取Top 3，减少上下文长度；三是缓存高频问题的答案，比如"半包和全包的区别"这种问题，第一次调模型，之后直接走缓存。

4.2 向量数据库选型：轻量方案够用就别上重型

向量数据库的选择取决于数据规模。十万级切片以内，用轻量方案完全够用，部署简单，成本低。百万级以上才需要考虑分布式方案。

我的建议是：先估算切片数量，再选方案。一家中型设计公司，五年积累的项目资料，切片数量大概在五万到十万之间。这个量级用轻量方案，检索延迟在毫秒级，完全满足需求。

存储成本方面，向量数据本身不大，十万条768维向量大概几百MB。真正占空间的是原始文件和解析后的文本。如果原始文件量大，可以考虑冷热分离：热数据（最近两年）放高速存储，冷数据放低成本存储，检索时按需加载。

4.3 开发与集成：最大的隐性成本在"对接"

开发Agent本身的工作量，如果需求明确、资料就绪，一个熟练的团队大概四到六周能出第一版。但集成到现有工作流往往要花同样甚至更多时间。

设计公司常用的工具是微信、企业微信、设计软件（CAD、SketchUp、酷家乐等）、网盘、Excel。Agent要能用起来，必须嵌入这些工具。比如需求初筛Agent要能读微信群消息，报价辅助Agent要能在Excel里调用，素材检索Agent要能在设计软件里弹出结果。

我的经验是：先做最小可用集成，再逐步扩展。第一版只做企业微信机器人，设计师在群里@机器人就能用。跑通后再做设计软件插件、Excel插件。不要一上来就追求全平台覆盖，那样周期太长，还没上线需求就变了。

4.4 运维与迭代：留出15%到20%的预算

运维与迭代包括：资料更新、效果评估、提示词调优、模型版本升级、bug修复。这部分预算建议占总预算的15%到20%。

效果评估要建立量化指标：需求初筛的字段抽取准确率、素材检索的Top 5命中率、报价辅助的数据准确率、施工交底的回答满意度、客户跟进的话术采纳率。每月评估一次，低于阈值的Agent要调优。

提示词调优是个持续工作。同一个Agent，不同公司的表达习惯不同，提示词要跟着调。我的做法是维护一个"提示词版本库"，每次调优都记录变更原因和效果对比，避免越调越乱。

5. 落地过程中最容易踩的五个坑

5.1 坑一：资料没整理就上RAG，检索出来全是垃圾

这是最常见的坑。很多公司觉得"先把系统搭起来，资料慢慢整理"，结果RAG检索出来的东西驴唇不对马嘴，设计师用两次就再也不用了。

正确做法：先整理资料，再搭系统。至少要把核心资料（最近两年的项目案例、当前有效的材料报价、现行施工规范）整理到位，再上线RAG。整理资料的过程也是梳理业务的过程，一举两得。

5.2 坑二：Agent权限没设计好，敏感信息泄露

设计公司的报价、客户信息、供应商信息都是敏感数据。如果Agent权限没设计好，一个普通设计师能查到所有项目的报价，或者客户信息被无关人员看到，就是事故。

正确做法：Agent的检索范围要跟用户角色绑定。设计师只能查自己参与的项目，采购只能查材料库，项目经理只能查施工相关。权限控制要在检索层做，不是在展示层做。

5.3 坑三：过度依赖模型生成，输出不可控

有些Agent设计成"什么都让模型生成"，结果模型偶尔会编造材料价格、承诺工期、生成不合规的话术。在设计行业，这种错误可能导致实际经济损失。

正确做法：关键信息（价格、工期、承诺、规范）必须来自结构化数据，模型只做检索、计算和润色。生成式输出要有边界，不能自由发挥。

5.4 坑四：没有反馈机制，用着用着就废了

Agent上线后，如果设计师发现回答不对，但没有方便的反馈渠道，他们就会直接放弃使用。没有反馈，系统就无法迭代，慢慢就废了。

正确做法：每个Agent的输出都带"有用/没用"按钮，点"没用"可以填写原因。这些反馈数据定期分析，作为调优依据。同时要有一个简单的"知识库纠错"入口，让一线人员能直接提交修正。

5.5 坑五：预算只算开发，不算运营

很多项目预算只算了开发和模型调用费，没算资料整理、集成对接、运维迭代的成本。结果项目做到一半发现钱不够，要么砍功能，要么追加预算，都很被动。

正确做法：预算分四块——开发与集成、模型与存储、资料整理、运维迭代。每块都要留余量，尤其是资料整理和集成对接，往往超支。

6. 上线后的效果评估与持续优化

6.1 怎么判断这套系统到底有没有用

评估不能只看"设计师用不用"，要看量化指标。我建议跟踪五个核心指标：

• 需求初筛准确率：抽取的字段与人工核对的一致率，目标90%以上。
• 素材检索命中率：Top 5结果中包含设计师所需素材的比例，目标80%以上。
• 报价查询效率：从提问到获得参考报价的平均时间，目标从原来的几分钟降到30秒以内。
• 施工交底满意度：施工队对回答的满意比例，目标75%以上。
• 客户跟进采纳率：生成的话术被设计师直接采用或稍改后采用的比例，目标60%以上。

这些指标每月统计一次，低于目标的Agent要分析原因并调优。

6.2 优化优先级：先修准确率，再提速度

优化要有优先级。准确率永远优先于速度。一个回答慢但准确的Agent，设计师愿意等；一个回答快但经常错的Agent，设计师用两次就弃了。

准确率优化主要靠三件事：资料质量、检索策略、提示词。资料质量是基础，检索策略是核心，提示词是微调。速度优化主要靠缓存、异步处理和模型降级（简单问题用小模型）。

6.3 从"能用"到"好用"：三个进阶方向

第一版系统跑通后，可以向三个方向进阶。一是主动推荐：Agent不只被动回答，还能根据设计师当前工作内容主动推送相关素材和提醒。二是跨Agent协同：需求初筛Agent识别出客户预算后，自动触发报价辅助Agent准备参考报价。三是个性化：每个设计师的使用习惯不同，Agent可以根据个人偏好调整输出风格和详细程度。

这三个方向都需要在基础版本稳定运行、数据积累到一定量之后再考虑。不要一上来就做，容易贪多嚼不烂。

注意：进阶功能的前提是基础功能的数据准确率和用户信任度已经建立。如果基础版本还有明显错误，先修基础，别急着加功能。

7. 给同类设计公司的落地建议

7.1 先做减法：五个Agent不用同时上线

需求清单里列了五个Agent，但落地时不要同时上。我的建议是分两批：第一批上需求初筛和素材检索，这两个Agent见效最快、风险最低；第二批上报价辅助、施工交底和客户跟进，这三个涉及敏感数据和复杂逻辑，需要更多调试。

每批上线后跑一到两个月，收集反馈、调优稳定后，再上下一批。这样团队有适应过程，技术团队也有迭代空间。

7.2 找对人：项目负责人要懂业务，不只是懂技术

这个项目的负责人最好是有设计行业背景的人，或者至少要在设计公司待过一段时间。因为很多需求细节、业务规则、敏感边界，只有懂业务的人才能判断。

技术团队负责实现，业务负责人负责定义"什么是对的"。两者缺一不可。如果只有技术团队，做出来的东西可能技术上没问题，但业务上不好用。

7.3 小步快跑：第一版不要追求完美

第一版的目标是"跑通流程、验证价值"，不是"功能齐全、体验完美"。先让设计师用起来，收集真实反馈，再迭代。很多项目失败是因为第一版做了半年，上线时需求已经变了，或者团队已经失去耐心。

我的经验是：第一版控制在四到六周，功能砍到最核心，先让一个小组试用。试用过程中发现的问题，比闭门造车想出来的问题有价值得多。

7.4 算好账：ROI要能说清楚

最后，这套系统要给老板算清楚ROI。投入包括开发、模型调用、资料整理、运维；收益包括设计师节省的时间、报价准确率提升减少的损失、客户响应速度提升带来的转化率提升。

以一个20人设计团队为例，如果每个设计师每天节省1小时，一个月就是400多小时，按人力成本算，几个月就能覆盖投入。这个账要算给老板看，也要算给设计师看，让他们知道这套系统是在帮他们，不是在监控他们。

这套系统的本质，是把设计公司里那些"翻资料、查价格、写话术"的重复劳动交给机器，让设计师把时间花在真正需要创造力的地方。技术不难，难的是把业务逻辑理清楚、把资料整理到位、把使用习惯培养起来。这三件事做好了，系统自然就转起来了。