企业官网建设流程全解析

1. 装修咨询这件事，为什么值得用AI重做一遍

干过装修的人都有一个共同感受：信息太碎了。你问一个“80平米老房翻新大概多少钱”，能收到二十个版本的答案，有人说八万，有人说十五万，还有人甩给你一张报价单让你自己悟。这不是谁在故意藏着掖着，而是装修行业的报价本身就高度依赖变量——城市、房龄、拆改量、材料档次、施工季节、工人档期，任何一个参数变了，总价就能差出一倍。

我做这个AI智能咨询助手的出发点特别朴素：把装修咨询从“大海捞针”变成“一问即答”。你不需要先成为半个专家才能问出好问题，你只需要用大白话说清楚你家的情况，助手就能给你一个结构化的、可追问的、带解释的参考答复。

这个项目适合谁看？三类人。第一类是想自己动手做一个垂直领域问答工具的技术爱好者，装修只是切入点，换成法律、医疗、育儿都一样。第二类是装修公司的客服或运营，想用AI把重复咨询接住，把人力释放到真正需要跟进的客户身上。第三类就是普通业主，你至少能看懂一个靠谱的装修咨询助手应该长什么样，以后遇到类似工具能判断它靠不靠谱。

核心关键词我先摆出来：装修咨询、智能问答、知识库构建、意图识别、多轮对话、报价估算、材料推荐、施工流程。这些词后面会反复出现，因为它们就是这个系统的骨架。

2. 整体设计思路：为什么不做“万能聊天”，而做“带知识库的垂直助手”

2.1 通用大模型的三个致命短板

一开始我也想过，直接拿一个通用大模型套个装修的提示词不就行了？实测下来，三个问题绕不过去。

第一个是报价幻觉。你问“100平米毛坯房简装多少钱”，通用模型会给你一个看起来很像那么回事的数字，比如“8到12万”。但这个数字没有考虑任何本地化变量，你拿去跟装修公司谈，对方一句“我们这儿人工费比这个高30%”就把你堵回来了。更麻烦的是，它不会告诉你这个数字是怎么来的，你没法追问“如果我只做厨卫改造呢”。

第二个是材料推荐不落地。通用模型推荐瓷砖会说“建议选择耐磨、防滑的”，这话没错但没用。业主需要的是“800×800的抛釉砖，本地建材市场大概什么价位区间，什么品牌在这个价位段口碑比较稳”。通用模型给不了这种颗粒度，因为它没有结构化的本地化材料库。

第三个是多轮对话容易跑偏。装修咨询天然是多轮的：你先问预算，再问拆改，再问水电，再问工期。通用模型聊到第三轮就开始遗忘前面的约束条件，你明明说了“不改格局”，它后面又给你推荐拆墙方案。

2.2 我的方案：知识库+意图路由+参数化估算

所以这个助手的架构不是“一个大模型包打天下”，而是三层结构。

最底层是装修知识库，用结构化的方式存三类东西：工艺知识（比如防水怎么做、水电走顶还是走地）、材料知识（品牌、规格、价位区间、适用场景）、报价知识（分项单价、地区系数、面积计算规则）。这些知识不是从网上随便爬的，而是从公开的行业资料、建材市场调研、施工规范里整理出来的，每一条都带来源和适用范围。

中间层是意图识别与路由。用户说一句话，系统先判断他到底在问什么：是问预算、问材料、问工艺、问工期，还是问某个具体问题的解决方案（比如“墙面开裂怎么办”）。不同意图走不同的处理链路。问预算的走参数化估算模块，问材料的走材料库检索，问工艺的走知识库问答。

最上层才是对话生成。大模型在这里的角色是“把结构化结果翻译成人话”，而不是“凭空编答案”。它拿到的是估算模块算出来的数字、材料库检索出来的条目、知识库匹配到的工艺说明，然后组织成一段自然语言回复。这样既保留了对话的流畅性，又保证了信息的可靠性。

提示：这个“知识库+路由+生成”的三层结构，是垂直领域问答工具能不能落地的关键。通用模型直接套提示词，做demo可以，做产品一定翻车。

2.3 为什么参数化估算比“让模型猜”靠谱

报价估算这块我单独拎出来说，因为它是装修咨询里最高频、也最容易出问题的环节。

我的做法是把报价拆成可计算的参数模型。举个例子，墙面乳胶漆这一项，公式大概是：

墙面涂刷总价 = 涂刷面积 × 单价 × 地区系数 × 材料档次系数 涂刷面积 = 建筑面积 × 墙面展开系数（通常2.5到3.0） 单价 = 基础人工 + 材料费（按档次分档）

地区系数和材料档次系数是查表得到的，不是模型猜的。用户输入“建筑面积100平米，二线城市，中档材料”，系统就能算出一个区间，并且把计算过程展示出来。用户追问“如果换成高档材料呢”，系统只需要改一个系数重新算，不需要重新理解整个问题。

这样做的好处是可解释、可追问、可校准。装修公司的报价员看了这个计算逻辑，能直接指出哪个系数不对，我们改系数就行。如果让模型直接猜数字，报价员根本没法校准，只能推翻重来。

3. 核心细节解析：知识库怎么建、意图怎么分、对话怎么管

3.1 装修知识库的结构化设计

知识库是这个项目的地基，地基没打好，上面盖什么都是歪的。我把它分成三个独立的库，每个库的结构不一样。

工艺知识库用“问题-方案-注意事项”的三段式结构。比如：

材料知识库用“品类-规格-价位区间-适用场景-口碑标签”的结构。价位区间按城市等级分档，不写死具体数字，而是写区间和影响因素。

报价知识库用“分项-计算公式-系数表”的结构。每个分项独立成条，系数表按地区和档次两个维度组织。

这三个库不是孤立的，通过标签关联。比如用户问“卫生间防水加贴砖多少钱”，系统会同时命中工艺库的防水条目和报价库的贴砖条目，然后合并计算。

3.2 意图识别的分类与路由逻辑

意图识别我一开始想用大模型直接做，后来发现不行，因为大模型分类不稳定，同一个问题换个说法就分到不同类里去了。后来改成关键词规则+小模型分类的混合方案。

先定义意图类别：

• 预算估算类：包含“多少钱”“预算”“报价”“贵不贵”等信号词
• 材料选择类：包含“什么牌子”“哪种好”“选什么”“推荐”等信号词
• 工艺咨询类：包含“怎么做”“流程”“步骤”“注意什么”等信号词
• 问题排查类：包含“开裂”“漏水”“空鼓”“怎么办”等信号词
• 工期咨询类：包含“多久”“几天”“什么时候”等信号词

关键词规则负责快速命中明显意图，命中不了的走小模型分类。小模型是用标注数据微调的，准确率比通用大模型高不少，而且响应快。

路由逻辑是这样的：预算类走估算模块，材料类走材料库检索，工艺类走知识库问答，问题排查类走“症状-原因-方案”匹配，工期类走工期估算表。如果一句话里包含多个意图，比如“卫生间防水加贴砖多少钱”，系统会拆成两个子意图分别处理，然后合并结果。

3.3 多轮对话的状态管理

装修咨询的多轮对话有个特点：约束条件是逐步累积的。用户第一轮说“我想翻新老房”，第二轮说“80平米”，第三轮说“预算有限”，第四轮问“那墙面怎么弄”。到第四轮的时候，系统必须记得前面三轮的所有约束：老房、80平米、预算有限。

我的做法是维护一个对话状态对象，每轮对话结束后更新这个对象。状态对象里存的是结构化字段：

{ "房屋类型": "老房", "建筑面积": 80, "预算档位": "经济型", "已讨论分项": ["墙面", "水电"], "待确认分项": ["厨卫", "地面"] }

每轮生成回复之前，先把状态对象注入到提示词里，让模型知道当前的所有约束。这样就不会出现“用户说了不改格局，模型还推荐拆墙”的情况。

注意：状态对象里的字段要设计得足够细，但也不能太细。太细了维护成本高，太粗了约束不住。我的经验是，围绕“预算估算需要哪些参数”来设计字段，基本够用。

4. 实操过程：从零搭一个能用的装修咨询助手

4.1 环境准备与技术选型

这个项目不需要特别重的技术栈，我用的是一套比较轻的组合。

• 后端：Python + FastAPI，负责接口和业务逻辑
• 知识库存储：SQLite起步，数据量大了换PostgreSQL
• 向量检索：用于知识库的语义匹配，选一个开源的轻量向量库即可
• 大模型：调用公开的通用大模型API，负责最终回复生成
• 前端：先用简单的网页对话界面，后面可以接微信或APP

选SQLite起步是因为装修知识库的数据量其实不大，工艺条目几百条，材料条目几千条，报价公式几十条，SQLite完全扛得住。等你要做多用户、多租户的时候再换，不用一开始就上重型数据库。

4.2 知识库的录入与校验流程

知识库录入我走的是“整理-录入-校验-上线”四步。

整理阶段，我从公开的施工规范、建材市场公开报价、行业公开资料里提取条目。每条都要标注来源和适用范围，来源不明的直接扔掉。

录入阶段，用脚本批量导入，每条数据都要过一遍格式校验，字段缺失的退回整理阶段。

校验阶段，找有装修经验的人抽样检查，重点看报价公式的系数是否合理、工艺描述是否准确。这一步不能省，我见过太多知识库因为一条错误公式导致整个估算模块不可信。

上线阶段，先小范围试用，收集用户追问和纠错反馈，持续迭代。

4.3 报价估算模块的参数计算过程

拿一个具体例子走一遍。用户输入：“二线城市，100平米老房，想翻新厨卫，中档材料，大概多少钱？”

系统处理流程：

第一步，意图识别命中“预算估算类”，提取参数：城市等级=二线，面积=100，房屋类型=老房，改造范围=厨卫，材料档次=中档。

第二步，调用报价库，匹配“厨卫翻新”分项。这个分项包含拆改、防水、贴砖、吊顶、水电改造、洁具安装等子项。

第三步，逐项计算。以防水为例：

防水面积 = 厨卫地面面积 + 墙面防水面积 厨卫地面面积 ≈ 建筑面积 × 厨卫占比（通常10%到15%）= 100 × 0.12 = 12平米 墙面防水面积 = 周长 × 高度 = 约20平米 防水总面积 ≈ 32平米 防水总价 = 32 × 单价（中档）× 二线系数

第四步，汇总所有子项，给出总价区间，并列出各项占比。

第五步，生成回复时，把计算过程用通俗语言解释一遍，并提示“如果拆改量大或水电全改，总价会往上浮”。

实操心得：报价估算一定要给区间而不是单点数字。装修行业本身就没有精确报价，给单点数字反而显得不专业。区间上下浮动控制在15%以内比较合理。

4.4 对话生成的质量控制

对话生成这块，我加了三个约束。

约束一：不编数字。所有数字必须来自估算模块或知识库，模型不能自己生成数字。实现方式是在提示词里明确要求“如果上下文中没有数字，就说需要更多信息，不要猜测”。

约束二：不超范围。如果用户问的问题知识库里没有，模型要明确说“这个问题我暂时没有可靠信息”，而不是硬答。硬答一次，用户信任就崩了。

约束三：带追问引导。每次回复结尾，根据当前对话状态，引导用户补充下一个关键参数。比如估算了厨卫之后，追问“地面和墙面要不要一起翻新”。

这三个约束看起来简单，但实际调优花了不少时间。尤其是约束一，模型天生喜欢编数字，要在提示词和输出后处理两层都做拦截。

5. 常见问题与排查技巧实录

5.1 意图识别不准怎么办

最常见的表现是用户问“墙面怎么弄”，系统分到了材料类而不是工艺类。排查思路：

先看关键词规则有没有覆盖“怎么弄”这个说法，没有就补进去。再看小模型分类的置信度，如果置信度低于阈值，走兜底策略——直接问用户“您是想了解施工工艺还是材料选择”。兜底策略虽然多一轮交互，但比答错强。

5.2 报价估算偏差大怎么校准

偏差大通常来自三个地方：系数表不准、面积计算规则不对、分项遗漏。

校准方法是找真实报价单做回归测试。拿十份真实报价单，把参数输入系统，看估算结果和实际报价的偏差。偏差超过20%的，逐项拆开看是哪个子项的问题。系数表可以按地区逐步细化，面积计算规则可以按房屋类型调整。

5.3 多轮对话丢失约束怎么排查

如果用户说了“不改格局”，后面系统又推荐拆墙，说明状态对象没更新或者没注入。排查步骤：

先看状态对象在每轮结束后有没有正确更新，再看生成回复时有没有把状态对象注入提示词。这两个环节任何一个断了，约束就会丢。我建议在开发阶段把状态对象打印出来，每轮都看一眼，确认字段正确。

5.4 常见问题速查表

避坑技巧：知识库条目宁可少而精，不要多而杂。一条错误条目带来的信任损失，十条正确条目都补不回来。

6. 这个助手后续还能怎么扩展

我现在这个版本跑通了“问答+估算”的核心链路，但装修咨询还有很多可以做的。

一个是图片识别。用户拍一张墙面开裂的照片，系统识别裂缝类型，给出对应的处理方案和参考报价。这个需要接图像识别模型，但知识库和报价模块可以直接复用。

另一个是方案对比。用户输入两个装修方案，系统从预算、工期、耐用性三个维度做对比，给出建议。这个本质上是把估算模块跑两遍然后做差异分析，实现难度不大。

还有一个是施工进度跟踪。用户输入开工日期和房屋类型，系统生成一个施工进度表，每个节点提醒用户该验收什么、该付哪笔款。这个需要把工期知识库做得更细，但价值很高，因为装修超期是业主最大的痛点之一。

我个人在实际操作中的体会是，垂直领域问答工具的核心竞争力不在模型，而在知识库的颗粒度和准确性。模型可以换，知识库换不了。你把知识库做扎实了，换什么模型都能跑出靠谱的结果。反过来，知识库稀烂，用再强的模型也是胡说八道。所以如果你也想做类似的东西，先把知识库的整理和校验流程跑通，再考虑模型和交互的事。