企业官网建设流程全解析

装修咨询这件事，我做了大半年，最大的感受就是：信息越搜越乱，越问越慌。一个普通的首次装修业主，想弄明白"90平米两居室半包大概多少钱"这种基础问题，往往要在论坛、装修公司报价单、短视频评论区里来回折腾好几个星期，得到的答案还是互相打架的。所以我做了个家居装修AI智能咨询助手，目标很简单——把"大海捞针"式的装修咨询，变成"一问即答"。这篇东西不是产品文档，是我从零搭这个系统的完整记录，包括为什么选这条技术路线、知识库怎么建、意图识别怎么调、线上踩过哪些坑，适合也想做垂直领域问答助手的开发者和产品同学参考。

1. 装修咨询这件事，为什么越搜越焦虑

1.1 三个信息源，各有各的坑

在动手写第一行代码之前，我先花了一周时间，把自己伪装成一位即将装修的业主，把所有普通人会用的咨询渠道都走了一遍。结论很清晰：传统渠道的问题不是没有信息，而是信息结构太差。

第一个坑是论坛和搜索。装修论坛里确实有大量真实案例，但帖子是碎片化的，一位业主在某城市分享的半包报价，可能来自三年前的行情，而且和他家房屋结构、施工复杂度、材料档次强相关。你搜"防水怎么做"，能搜出十几种工艺细节，但没人告诉你哪些适用于你家卫生间、哪些适用于阳台。信息不是知识，散落的经验更不是。

第二个坑是装修公司的免费咨询。销售导向决定了他们给的信息一定有选择性，常见话术是"我们套餐价199一平全包"，等你签了合同，增项清单才一项项浮出来。不是说装修公司都不靠谱，而是这种咨询模式天然带着立场，用户没法直接信任。

第三个坑是通用大模型。它们语言通顺、态度好，但装修知识时效性强，材料价格、工艺标准、地区差异都很敏感，通用模型要么给出过时信息，要么在具体参数上"一本正经胡说八道"。我拿"防水闭水试验做多久"问过主流模型，答案从24小时到72小时都有，但没有一个能告诉我标准做法是什么、依据来自哪里。

1.2 什么样的用户最需要"一问即答"

做产品之前必须先定义用户，不然非常容易做成一个"什么都能聊"但其实什么都没用的聊天机器人。

我这边锁定的核心用户是首次装修、房屋面积在80到120平米之间的刚需业主。这类人普遍有一个特征：预算有限、时间有限、没有装修经验，而且特别怕被装修公司牵着走。他们真正需要的不是海量信息，而是一套稳定可靠的"知识底座"——先让我知道装修大概分几步、每个节点要盯什么、什么价格区间是正常的，再带着这些底牌去跟设计师、工长、装修公司沟通。

辅助用户还有一类，是已经开工的业主。他们问的问题会更具体，比如"水电改造完要不要拍照存档""瓷砖空鼓率多少算合格"。这类问题在传统渠道更难快速找到答案，因为太细、太实际，而"一问即答"恰好能解决。

1.3 项目范围：哪些不做，哪些重点做

想做和该做的边界，我是在测试阶段才真正想明白的。最开始产品同事提了很多需求：生成整屋设计方案、自动报价、推荐装修公司……我全部砍掉了，原因很简单，这些功能对数据质量和责任边界的要求远高于咨询助手能承受的范围。

这个项目的边界最终定成四件事：

• 装修流程知识问答：从量房到竣工验收的每个节点该干什么、带什么、验收标准是什么。
• 预算参考与避坑指引：基于城市、面积、装修方式给出价格区间，而不是精确报价。
• 材料与工艺科普：地砖、乳胶漆、防水、木地板这些常用材料的选购要点和施工工艺。
• 合同与维权注意事项：付款比例、增项条款、工期约定这类高发纠纷点的提醒。

不做的事同样重要：不做整屋设计、不做自动报价单、不承诺任何材料具体品牌优劣，更不推荐具体装修公司。划清边界之后，系统反而好做了，因为每一个回答都能控制在"知识科普"这个安全范围内。

2. 系统骨架与选型逻辑：RAG才是这个场景的正解

2.1 先对比三种技术路线再动手

在定技术方案之前，我列了三种候选路线，拿同一个测试问题去跑对比。

第一种是纯规则匹配。把高频问题做成意图库，用户命中关键词就返回预设答案。这套方案的好处是简单、可控、不依赖模型，坏处是装修问题的表达方式太多样了。"卫生间漏水要怎么办"和"厕所有点渗水咋整"指的是同一个问题，但关键词完全不同。规则库要保养到能覆盖这些表达，维护成本是灾难级的。

第二种是纯大模型生成，也就是不挂任何知识库，直接让模型回答。优点是通用能力强，缺点是装修知识的时效性和地域性完全解决不了。我问模型的逻辑是：城市、工艺、价格这些信息，模型训练数据里没有的，它就会靠"猜"来补。猜对了是运气，猜错了就是事故。

第三种是检索增强生成，也就是RAG路线：先把装修知识全部结构化后存入知识库，用户提问时先从库里检索出相关片段，再交给大模型组织成通顺的答案。最终我选的就是这条路线，核心原因有三个。第一，答案可以有出处，用户能看到我每句话来自哪条资料；第二，知识更新只需要维护知识库，不用重新训练模型；第三，检索结果可以被拦截和过滤，安全性比纯生成高很多。

2.2 模块划分与一次完整查询的旅程

整个系统的骨架分两层：内容层和引擎层。内容层负责知识的生产、清洗、分块、打标签和存储；引擎层负责用户问题进来之后的全部处理。一条典型查询的旅程大致是：

1. 用户输入问题，先进入敏感词过滤模块，这一步不通过就直接拦截。
2. 通过后进入意图识别模块，判断问题属于预算、流程、材料、工艺、合同中的哪一类。
3. 实体抽取模块把问题里的面积、城市、装修方式、户型风格等信息拉出来，拼装成检索条件。
4. 检索器带着问题的文本向量和实体过滤条件，去知识库里找出最相关的一批知识片段。
5. 生成器把检索到的片段和原始问题组装进提示词，交给大模型输出最终答案。

这里最关键的一步在第4步：检索不是纯靠向量相似度，而是先拿实体过滤条件把知识库范围缩小，再做向量召回。举个例子，用户问"成都90平半包多少钱"，如果直接做全文相似度检索，很可能召回一堆"北京130平全包案例"，因为语言结构相似度确实高。但先按城市、面积、装修方式过滤一轮，再算相似度，命中率就稳得多。

2.3 嵌入模型、检索库、服务化怎么取舍

选型这事我花了不少时间试错，分享几个落地的标准。

嵌入模型选的是中文领域表现比较好的开源向量模型，选型依据不是榜单分数，而是三个实测指标：能否正确区分"马桶"和"浴室柜"这种同域不同物的近邻语义、长文本（超过512字）检索是否衰减、在装修专业名词上的召回稳定性。测试集我特意放了一批容易被混的装修问题，比如"全屋定制"和"成品家具"的区别，模型如果在这类问题上频繁检索错乱，直接淘汰。

向量存储我用的是开源向量数据库，看重的是可以直接按标签做过滤，不用把所有知识都拉出来重新排序。这个功能在初期不起眼，等知识条目到几千条之后，性能差别就非常明显了。

服务化部署那句经验也想说：别一上来就上大模型API。先用一个较轻量的生成模型跑通全流程，把知识库质量和检索逻辑调好，再换更强的生成模型做优化。否则很容易出现"模型很强、检索很烂、答案还是乱七八糟"的假象，让人误判瓶颈到底在哪。

3. 装修知识库：决定效果上限的"隐形工程"

3.1 语料清洗：把"营销文"和"干货"分开

知识库的质量决定了整个系统的上限，这句话怎么强调都不过分。一开始我天真地以为，多抓一些装修文章就能成为知识库，结果跑出来的答案充斥着"xxx品牌精选套餐，限时优惠"之类的广告腔，用户体验非常糟糕。

清洗流程我分了三步。

第一步是去广告和营销痕迹。凡是出现"点击咨询""免费报价""限时特惠"这些词的段落，直接整段丢弃。这个规则看着粗暴，但非常有效，因为装修领域的广告文大多有明显话术结构。

第二步是识别时效性。装修行业的价格、工艺标准、环保等级变化很快，我会在每条知识上记录内容的适用年份。比如2022年的报价数据，绝不会被检索到2025年的对话里去回应"现在多少钱"。

第三步是建立"内容可信度分级"。官方发布的施工规范、行业协会公开的技术指引、一线工人发布的一手经验，属于高可信度；装修博主的体验分享属于中可信度；评论区里的零散吐槽，基本不进入知识库。这一步做完了，知识库的"杂质"才算被真正滤掉。

3.2 分块策略：一篇文章该切成多大

这是我在这个项目里试错最多的地方。刚开始我按固定长度切文本，每512个字切一块，结果出现了很尴尬的情况：一篇讲"卫生间防水施工全流程"的文章，被从中间切断，"防水材料选择"在上半块，"闭水试验步骤"在下半块。用户问"闭水试验要多久"，系统只能召回后半块，答案里完全没有前面的原理，生成模型不得不靠自己的知识去补，幻觉风险直线上升。

后来我改成了层级语义分块。先按文章的段落结构和标题层级拆，每篇文章尽量保留完整的语义模块；模块超过一定长度，再按句子边界切。同时把标题作为该分块的元信息保存下来，检索时标题也能参与匹配。这样改完之后，"闭水试验"这类问题召回的片段，通常开头就是"闭水试验"这个标题，生成质量明显提升。

关于分块的大小，我建议按主题而不是按字数来定。一个完整的问答对通常在200到500字之间，分块往这个区间靠即可，不必强求整齐划一。

3.3 给知识打标签：城市、户型、预算都写上

纯文本的知识片段对生成模型来说是"哑巴"，必须给它结构化的属性，检索才能做到精准过滤。

我给每条知识都打上了三类标签：适用城市（无限制、一线、新一线、二线及其他）、适用面积段（80平米以下、80到100、100到120、120以上）、适用装修方式（全包、半包、清包、无限制）。有些知识还会额外打上风格标签，比如"北欧风收纳技巧"只适用于风格类的提问。

同时每条知识还配了一个"兜底答案"。一旦这条知识被检索到，但生成模型判断它不足以直接回答用户问题，兜底答案就会被作为参考，让模型输出"根据现有资料，您的情况建议重点检查xxx，具体价格需要结合施工量现场评估"这类话，而不是硬答。

下面是知识库条目结构的示意，方便你理解这个"带壳"的设计：

{ "id": "KB-2024-00723", "title": "卫生间防水闭水试验时长与做法", "content": "闭水试验应在防水涂层完成并干燥后进行的……规范要求蓄水深度不低于20毫米，蓄水时间不少于48小时……", "tags": { "city": "无限制", "area": "无限制", "decoration_mode": "无限制" }, "source": "公共建筑装饰工程施工与验收相关标准", "validity_year": 2024, "fallback": "防水闭水试验的规范时长是48小时，但具体项目需以防水材料要求为准。" }

每一条知识都可以独立溯源，这为后面的安全控制和回答可解释性打下了基础。

4. 让AI听懂"装修人话"：意图识别与追问设计

4.1 七类高频意图与对应策略

装修咨询的问题表达极其口语化，同一个意图能有十几种问法。我整理了一段时间内的真实用户问题，最终把高频意图收敛成了七类，并给每类设计了不同的应答策略。

意图识别的实现，初期用了一套规则加少量标注数据的方案：先靠关键词粗分，再用一个轻量文本分类模型做精分。分类模型的训练数据不多，胜在每一类都标得足够准确。这个阶段不建议追求大而全的模型，把高频意图打准，系统的可用性已经能超过大多数通用助手。

4.2 实体抽取与归一化

意图决定了"怎么答"，实体决定了"答得准不准"。我这边重点抽四类实体：面积、城市、装修方式、预算范围。

实体抽取的难点不在抽取本身，而在归一化。用户说"九十平""90平米""89.8平"，都该归一为同一档面积段；说"魔都""成都"都该归一到城市规格。装修行业的报价逻辑通常是按城市线级、面积档位和施工内容来锚定区间的，实体归一化做不好，检索过滤就会失调。

我用的方案是"基于词表的规则抽取为主，大模型抽取兜底"。词表覆盖城市名、风格名、常见面积表述，规则能稳定命中大部分需求；遇到规则覆盖不了的长尾表达，就丢给生成模型解析成标准化字段再落库。测试下来，这套组合的实体抽取准确率足够支撑上面的七类意图。

4.3 多轮对话里的追问与澄清

单轮问答很快会遇到瓶颈。用户问"防水怎么做"，这个问题的解空间太大——是卫生间还是阳台？是涂料防水还是卷材防水？是自己施工还是找工人做？如果不追问，答案只能泛泛而谈。我给系统设计了"缺什么补什么"的澄清机制。

当某个必要实体缺失时，系统不是直接给一个笼统答案，而是先给出一个基于最常见情形的回答，再附带一句追问："以上是卫生间的常规做法。如果您问的是阳台或厨房，防水工艺和蓄水要求会有所不同，可以再告诉我具体位置。"这样既没有故意卡住用户，又把对话往精准的方向推进。

实现上，每个意图配置一个"必要实体槽位表"。预算意图必须要有城市和面积，缺了就追问；流程意图只要有面积和装修方式就能得很好的答案，城市缺省影响不大。这本质上是让系统在"知道多少"和"答得多准"之间做一个动态平衡。

5. 回答安全与幻觉控制：线上翻车的高发区

5.1 内容安全过滤清单

问答助手一旦对外发布，内容安全就是底线。我在系统前面加了一道独立的敏感词过滤层，不经过它，任何问题都不会进入问答引擎。这里的过滤词表是装修领域专用的，覆盖几类高风险表达：

• 涉及财产建议的：报价、具体价格承诺、投资回报，不允许给绝对化数字。
• 涉及施工安全的：承重墙、燃气管道、高空作业、电气改造，必须带安全提示。
• 涉及环保承诺的："零甲醛""绝对环保"这类绝对化表述，回答里直接禁止出现。
• 涉及用户隐私的：让用户输入手机号、地址、身份信息的引导，全部拦截。

除了前置过滤，生成阶段还挂了一道后置检查：如果生成模型输出的文本里包含"保证、绝对、一定、百分之百"这类词，该回答会被打回重写或者退回兜底话术。这在初期误伤了一些正常表达，但整体上把系统拉到了安全区。

5.2 施工安全类问题的边界

装修里最危险的不是材料选错，而是结构安全被当成了普通常识来回答。我拿"承重墙能敲掉吗"这个问题做了专门的规则处理。

系统对这类问题的回答，固定走一条安全链路：先给绝对结论——承重墙不得擅自拆改；再说明理由——它承担着整栋楼的结构荷载；最后给出正确路径——如需改动，应委托有资质的设计单位出具方案，报物业和相关部门审批。整个过程不允许出现任何"如果条件允许、有些人会这么做"之类的试探性表达。燃气管道改造同理，回答只讲"需要具有相应资质的机构施工"这个标准口径，不讨论任何具体操作。

这块的经验是：安全类内容不要依赖大模型临场发挥，要当成独立的知识条目写死，并且永远排在知识库检索的最前面。

5.3 引用来源与"不确定就说不确定"

幻觉是RAG系统绕不开的敌人，我用两个手段压制。

第一个手段是强制引用。生成模型的任务描述里明确了：所有关键结论必须提到知识库中的来源编号，用户如果追问"你凭什么这么说"，系统可以展示来源名称。这一点对建立信任很有帮助——装修用户本来就充满戒备，看到一句没有来由的"建议你选实木复合地板"，和看到一句"根据某行业协会的材料对比报告"，体验完全不一样。

第二个手段是置信度阈值。每次检索结果都会算出一个相似度分数，低于阈值的片段不允许被拼进回答。这时候系统走另一套话术："关于您问的问题，我目前掌握的资料还不够具体。建议您补充一下房屋所在城市、面积或装修方式，我可以给您更准确的信息。"别看这句话简单，它把大量"硬答"挡在了门外面。实测下来，低频长尾问题的回答满意度反而比高频问题更高，就是因为低频问题大多走了这个诚实路径。

6. 实测复盘：从翻车到稳定的三个阶段

6.1 测试集怎么建才不算自嗨

这类项目最怕的是拿着自己写的问题测自己，结果当然全是好评。我从真实场景里拉了300条咨询记录作为测试集。这些记录来自用户在前端咨询框里的真实提问，有实体地址、有口语表达、有错别字，质量参差不齐，但这才是真实的生态。

测试集的维护也是动态的。每收集一批新问题，就用当前系统跑一遍，把跑不好的挑出来，分析是检索问题、知识缺失还是生成问题，然后针对性修。这300条问题就是系统的"体检单"。

评测指标我盯三个：完整覆盖率（能给出有效回答的比例）、答案准确率（由行业伙伴人工复核）、违规率（出现安全隐患或绝对化承诺的比例）。这三个指标能很好地反映一个问答助手是否真正可用。

6.2 三个典型失败案例的修复过程

第一个案例是预算类问题。有用户问"五六线城市90平全包十万块够不够"，当时系统直接按新一线城市的报价数据回答，区间差了一倍多。复盘发现是实体抽取把"五六线"错误归一化成了"无限制"，导致检索没有按城市规格过滤。修复方案是在归一化词表里增加"城市线级"的单独字段，用户明确说了城市规格，就绝不退回默认城市库。

第二个案例是"厨房能不能移到阳台"。系统第一次的回答只讲了阳台承重、防水、上下水改造这些技术点，漏了最关键的信息——这类改动通常需要物业审批。用户会不会问、怎么问，不代表风险的边界。我把这类涉及公共部位和结构安全的提示词做成强制附加规则，只要识别到"移、改、拆、扩"搭配空间词，就必须追加审批提醒。

第三个案例是"装修公司跑路怎么维权"。这个问题的知识库里有完整法律术语，但生成模型输出得太干硬，用户根本看不懂，比如"提起诉讼"这类建议没有交代取证步骤和时效性。后来我调整了这类维权问题的回答模板：先讲操作步骤（留证据、发函、投诉、诉讼），再讲每步的关键点，让用户能直接照着做。

6.3 最终指标与线上表现

通过上面这一轮轮迭代，我在测试集上的数字稳定到了这个水平：完整覆盖率92.5%，人工复核准确率接近90%，违规率压到了1%以内。作为对照，初期版本的完整覆盖率只有67%，违规率在7%左右。

线上表现给我留下的一个深刻印象是：用户不会因为你答错一次就离开，但会因为你答得空洞而下一次不再信任。前两周的对话记录里，凡是带"不太清楚""建议咨询"字样的回答，下一轮流失确实高。这反向验证了知识库建设阶段投入的价值——真正的口碑，是靠一段段具体、有出处、可操作的回答堆出来的。

7. 上线之后的持续优化：这活儿没做完

7.1 用户问题回流和再标注

问答助手上线那一刻，才是知识库建设工作最重的开始。我建立了"问题月报"机制：每月把系统没能命中、或者触发低评分的用户问题导出来，人工跑一遍，看看是知识库缺内容、检索分块不对，还是生成模型措辞有问题。

有一个很典型的例子：多位用户连续问"榻榻米垫子怎么选"和"地台床值不值得做"。这两类问题在初始知识库里几乎没内容，因为我认为"榻榻米"是低频需求，但实际咨询量一直很稳。问题回流只用了两周，就让这类问题的覆盖率从不到40%提到了90%。知识库永远不可能一步到位，问题是干出来的，不是想出来的。

7.2 最值得盯的两个运营指标

最后说两个我认为最值得每天盯着的线上指标。

第一个是首轮好答案率。用户问一个问题，系统第一轮就能给出带有效信息的回答，这个比例建议保持在80%以上。低于这个线，说明知识库覆盖、检索精度或实体追问机制至少有一环在漏题。

第二个是负反馈率。我在答案底下放了一组"有帮助/没帮助"的评价按钮，用户点"没帮助"的情况就是最精确的优化信号。不要只看整体满意度，要按知识条目看——某几条知识被频繁点"没帮助"，基本就是那条知识的写法和实际用户需求有偏差，要么改，要么换。

我自己的体会是：做这类垂直领域的AI咨询助手，真正的护城河从来不是模型，而是围绕领域知识做的清洗、结构化、边界控制和持续运营。模型是放大器，知识库才是信号源。信号本身是脏的，放大器越强，噪音越大。把这套"知识工程"的底子打扎实，用户那边自然会给出答案。