企业官网建设流程全解析

很多做装修内容的朋友都深有体会：写攻略、拍视频、回答评论区问题，翻来覆去逃不开那几个高频提问——"半包全包怎么选""阳台要不要打通""卫生间防水刷多高"。这些问题单看都不难，但对业主来说，它们散落在几十个帖子、三五段视频、若干条客服语音里，真正想查的时候，搜到的全是碎片，问出来的全是各说各话。我做了一个家居装修AI智能咨询助手，把这件事从"大海捞针"变成了"一问即答"。这篇文章就聊聊这个项目从需求拆解、架构设计到落地踩坑的全过程，给想做垂直行业AI应用的开发者，或者想给自己业务装一个智能客服的装修从业者，一个可以参考的完整方案。

很多技术朋友看到"AI咨询助手"，第一反应是接个大模型API、写个Prompt、套个对话框就完事了。真做完你会发现，装修咨询这行当，信息量极大、矛盾点极多、安全红线极硬，纯粹的对话模型根本扛不住。真正值钱的部分，是怎么把散落的知识整理成可检索的体系，怎么让模型在"回答问题"和"承认不知道"之间拿捏好分寸，以及怎么让用户相信你说的是对的。这篇就把这些部分一层层拆开讲清楚。

1. 为什么装修咨询比想象中难，这正是AI能切入的地方

1.1 装修信息检索的两个真实痛点：碎片化和信任危机

装修咨询这个场景，和问"今天天气怎么样"完全是两个物种。天气是事实性、即时性的，装修是决策性、长周期、高金额的。业主面对的问题往往是"我预算20万，三线城市，120平，想要原木风，怎么分配各项花费"——这里面包含预算、地域、面积、风格四重约束，任何一个通用搜索引擎都没法用一个答案满足。

碎片化是最直观的痛点。同样一个问题，论坛老帖里的答案可能是2016年写的，短视频博主说的方案是针对大平层的，装修公司客服给的报价里暗含了各种增项，厂家导购的建议永远"他家产品最适合"。用户在一堆互相矛盾的信息里做判断题，结果往往是越查越焦虑，最后要么赌运气，要么被话术带跑。

信任危机是比碎片化更深一层的痛点。装修行业话语权严重不对等，业主天然怀疑每一个利益相关方给出的建议。这就导致一个有趣的现象：用户宁可去听一个陌生网友的装修日记，也不愿意信监理的现场结论。AI助手在这个语境下有个天然优势——它没有签单KPI，不推销任何品牌，用户对"中立角色"的信任起点比装修公司客服高得多。但也正是因为没有KPI，它更不能胡说，一旦被用户发现两次瞎编，整个产品信任就崩塌了。

1.2 大模型直答还是检索增强？选型前必须想清楚的逻辑

很多人问：现在大模型知识量那么大，直接把装修常识灌进模型里让它回答不就行了？

这个问题我在项目初期专门做过对比测试。拿一款通用对话模型的基座（不用联网搜索、不开插件）和加上检索增强（RAG）的方案做AB对比，问三组问题：常识性的"硅藻泥和乳胶漆区别"、中段难度的"回填式卫生间和降板式卫生间防水做法差异"，以及高风险的"承重墙能不能开横槽走水电"。

结果是：常识性问题两边都答得不错，模型甚至能说得更顺溜；中段难度的问题，纯模型开始暴露出信息混叠，把不同标准、不同年代的做法搅在一起；高风险问题，纯模型大概率会给出一个看似合理、实则可能闯祸的答案——因为你没法指望模型内部的知识边界恰好和当地建筑规范对齐。

核心原因就一条：装修答案不是一个固定文本，而是一棵依赖树。防水的做法取决于房屋结构，电路的方案取决于负荷需求，预算分配取决于区域市场价格。模型需要"检索到当前用户的具体语境，再根据这个语境组织答案"，而不是从静态参数里"背"一个答案出来。所以这个项目从第一天起就确定：RAG是地基，大模型是拿来理解问题和组织语言的，不是拿来背知识的。

1.3 产品定位：不做"算命大仙"，做"资料员加陪聊顾问"

动手之前，我先把产品的边界画清楚了。这个助手不替用户做任何最终决定——不说"你这个户型必须拆这堵墙"，不说"这个品牌一定好"，而是做三件事：把模糊问题翻译成具体问题，从知识库里检索有出处的参考答案，帮用户把决策需要考虑的因素列全。

这个定位是想清楚之后才定的，不是妥协。装修行业太容易出纠纷，AI说错一句话，业主照着做了出了事，责任落到谁头上很难扯清楚。把自己定位成"资料员和陪聊顾问"，有四个字可以概括：安全、有用。安全是底线，有用是追求。用户问"瓷砖选亮光还是哑光"，助手给他的是两种砖在采光、防滑、耐污、风格适配上的对比维度，再反问一句"你家客厅采光怎么样、有没有老人小孩"，这就有用且安全。如果它直接来一句"选哑光的"，那这产品迟早出事。

2. 整体架构与核心模块拆解：一个可用级助手的长相

2.1 三个核心模块：知识库、推理引擎、对话编排

整个系统拆出来就三个模块，每个模块各司其职，边界非常清晰。

知识库是"记性"。装修相关的规范、攻略、问答、报价模板，全部清洗、分块、向量化之后存进带标签的索引里。它解决的是"模型说什么"的问题。

推理引擎是"脑子"。它的任务是基于检索出来的片段，结合对话历史，组织出一段通顺、结构清晰、有引用标注的回答。它解决的是"怎么说"的问题。

对话编排是"嘴和耳朵"。负责识别用户意图、管理多轮上下文、在信息不够时主动追问、对敏感问题启动兜底话术。它解决的是"什么时候说、说什么"的问题。

我见过很多翻车的AI助手项目，就是没把这三个模块分开，所有逻辑都塞进一个大Prompt里，最后改一版需求就要把所有Prompt重写一遍。模块化之后，知识库不准就补数据，模型态度不对就调提示词，意图识别错了就改编排逻辑，互不牵连。这是这个项目能在比较短时间跑通的关键。

2.2 对话流向设计：从"问什么"到"追什么"

装修咨询的对话，不是简单的一问一答，而是一个逐步收敛的过程。用户初始问题往往是"装修多少钱"这种大炮仗，你要是直接答"全包1200一平到3000一平都有"，等于没说。编排层要做的是把大问题拆小、把缺的信息问出来。

以"装修多少钱"为例，对话流向是这样的：先判断意图是预算类，然后提取已有的槽位（面积、城市、方式），发现缺面积和城市，就追问"您房子多大面积、在哪个城市"；用户回答"89平，成都"，再追问关键决策变量"半包还是全包，有没有大概的心理预期"；拿到这些之后再去检索，给出一个带区间的参考值，并且说明这个区间受主材档次影响很大。

这套追问逻辑不靠大模型自由发挥，而是写成结构化的追问树。每个意图对应一个追问模板，槽位没齐就继续问，槽位齐了才去查资料。别小看这一步，自由发挥的追问经常会把用户带沟里——比如用户问防水问题，模型追问起"你家风格是日式还是现代"，那就是灾难。

2.3 落地载体怎么选：小程序、公众号、网页还是企业微信

载体选择直接决定交互习惯和开发工作量。我见过几个团队一上来就做App，结果用户量小还维护成本高。实际做下来，装修咨询助手最合适的载体是微信生态，原因很简单：目标用户（业主）都在微信里，传播也依赖业主群和朋友圈。

具体到微信内，小程序适合做独立工具，交互灵活，可以放图文卡片、报价单、成本计算器；公众号适合做内容沉淀，可以在文章里内嵌问答入口；企业微信适合装修公司内部用——销售或客服在跟客户沟通时，随时把助手拉进群，让它对客户提问做辅助回答。

我们的做法是先把核心逻辑做成一套API，在这个API之上先接一个最简单的Web对话页做验证，确认回答质量和追问逻辑都过关之后，再把同一套API接到小程序和公众号。前期节约了不少返工成本。前端界面可以随时换，后端这套"知识库+检索+编排"才是最需要花时间的部分。

3. 知识库构建：AI助手"懂不懂行"全看这一步

3.1 语料从哪来：国家标准、平台攻略、问答帖、报价单、施工记录

知识库的语料质量直接决定检索质量，这个环节花的时间占了整个项目的四成以上。

第一梯队是工程类标准与规范资料。公开的建筑装饰装修工程质量验收标准、住宅装饰装修工程施工规范、各种材料的产品标准，这些是技术底线，回答"防水刷多高""瓷砖留缝多大""电路分几路"这类硬核问题必须优先引用它们。标准化语料格式干净、表达严谨，非常适合做RAG。

第二梯队是平台型攻略和问答。装修论坛的高赞帖、问答平台的优质回答、短视频文案的逐字稿。这些语料胜在"说人话"，能把专业术语翻译成业主听得懂的表达，比如"墙固地固""薄贴法""阴阳角找直"这些词，就是靠这些语料喂给模型，模型才学会用通俗语言解释的。

第三梯队是本地化数据。包括本地装修公司的公开报价单模板、建材市场的行情帖、同城市业主的装修日记。这部分语料直接支撑"在XX城市，这个预算能做到什么程度"这类地域性极强的问题。哪怕同一个品牌，一线城市和三线城市的安装费能差出一倍，没有本地语料，答案永远是"正确的废话"。

语料注意要采集公开可用的内容，涉及个人隐私和明确标注禁止转载的坚决不用。宁可资料少一点，也不能给自己埋合规的雷。

3.2 清洗与分块：只有干净的块才值得被检索

语料拿回来不是直接切了就丢进向量库，随随便便的清洗会导致检索时噪音极大。我在清洗环节主要做三件事：去广告，去掉"加微信领报价"这类营销内容；去时效性噪音，把语料里明确提到的年份提出来打上标签，比如"2021年市场价格"；去重复，不同来源里同样的内容只保留表述最清晰的一份。

分块参数我试过很多组，最后固定在一套比较稳的组合：按文档的语义边界（小标题、段落）切分，每个块控制在300到500字，相邻块之间重叠50字左右。为什么是这个参数？块太大，检索命中一个块之后里面包含太多不相关内容，模型会被噪音带偏；块太小，语义不完整，检索到的片段往往掐头去尾，模型没法理解上下文。50字的重叠是为了避免一个完整的知识点恰好被切在边界上，保证语义的连续性。

3.3 向量化与索引：用语义检索抓住"同一个意思"

一开始我犯过一个错误，试图全靠关键词匹配来做检索，结果用户问"家里有老人，卫生间要不要装扶手"，知识库里明明有大量关于适老改造的内容，关键词却是"老年人""无障碍""安全抓杆"，一个都匹配不上。后来换成语义向量检索，这类问题才被正确召回。

向量化用的是一套中文通用Embedding模型，输出768维向量。批量处理的时候按每批32条来跑，速度适中且不容易触发服务端的限流。索引方面我选的是一套支持元数据过滤的开源向量数据库，因为装修查询必须支持标签过滤——用户说在南方城市，就直接把北方独有的地暖、供暖分集水器相关语料过滤掉，只搜和南方气候相关的防潮、防霉内容，检索精度提升非常明显。

标签体系是我在设计阶段就坚持做的，每一条语料入库时必须带四类标签：来源类型（规范/攻略/问答/报价）、更新日期、适用地域（全国/华东/华南……）、适用房型（新房/老房/毛坯/精装）。这四类标签在做过滤检索时非常有用，比如"老房翻新能不能不砸地砖直接铺地板"这个问题，只需要检索同时满足"老房"和"地面工程"两个标签的语料，又快又准。

3.4 知识标注：给每块语料安上"户籍"

很多RAG项目把数据塞进向量库就完事了，不做标注，结果检索回来一堆来源不明的内容，模型引用的时候根本不知道这段话出自哪里、哪一年的、针对什么情况说的。

我的做法是给每个语料块加一个头注，类似给它安一个"户籍"。头注严格按固定格式写在每个块的开头，内容包括来源类型、年份、地域、适用场景。这个头注在用户提问匹配时不会参与语义对比，但在生成的回答提示词里会作为"引用来源说明"之一，模型在组织答案时能清楚地知道"我引用的这段话来自2023年的某平台攻略，对应的是南方地区"，在引用标注时信息就是完整的。

这一步还有一个额外的好处：后续如果用户对某条答案的来源有疑问，可以直接展开看到完整的头注，知道这条信息的"出身"，信任感提升很直观。

4. 核心实现：检索增强（RAG）的工程化落地

4.1 混合检索策略：向量做主、关键词兜底

纯向量检索有个天然缺陷：对专有名词和缩写不敏感。装修领域满屏都是"环氧彩砂""美缝剂""PET门板""岩板台面"这种术语，Embedding模型并不总能把这些词投影到语义空间里的准确位置。反过来，传统的关键词检索（BM25）在专有名词上反而很准，因为它是字面匹配。

所以实际检索我用了混合策略：两路并行，向量召回和BM25召回各出结果，然后按加权分数合并重排。权重分配上，向量分数占六成、BM25占四成。这个比例不是拍脑袋拍出来的，是在测试集上对比了十几组权重后选出来的结果——向量权重太高，术语类问题召回率掉得厉害；BM25权重太高，语义改写类问题（比如"有小孩要怎么防撞"）又召回不全。

4.2 重排与上下文扩展：粗召回之后还有两步精加工

混合检索的定位是"粗召回"，先把候选范围扩大，比如取前50条。这么多条不可能全塞给大模型，硬塞进去又贵又容易让模型迷失重点。所以要再做一次精排。

精排我用了一个开源的中文Rerank模型，把用户问题逐个和这50条候选做相关性打分，取分数最高的前5到8条作为最终上下文。Rerank模型虽然小，但在"精准排序"这个任务上比大模型Embedding要靠谱得多，尤其在装修这种术语密集的场景里，效果差异非常明显。

还有个容易踩的坑：知识库里一个完整知识点可能被切成了好几个相邻块，比如一个讲"水电改造验收"的段落，前半部分在块A，后半部分在块B，检索命中了A却丢了B，生成的答案就会缺少后半段验收标准。解决办法是扩展窗口——命中某个块之后，把跟它在同一文档中位置相邻的前后各一个块也一起拉出来，作为补充上下文。这一步能让答案连贯性明显提升，代价只是略微增加一点Token消耗，非常划算。

4.3 提示词工程设计：让模型知道什么该说、什么不该说

提示词是RAG项目里投入产出比最高的环节，一套好的提示词工程能让模型少犯一半的错。

我最终固定下来的系统提示词包含五个部分：角色定义、回答原则、不确定性处理、引用规范、红线兜底。

角色定义部分写明：你是一个家居装修智能咨询助手，只根据提供的检索资料回答用户问题。这里"只根据"三个字是重中之重，它可以最大限度压制模型的自由发挥。

回答原则部分特别强调了几条：答案要分点、给出结论先行；尽量使用口语化的专业表述，专有名词后给出通俗解释；如果在检索资料中存在相互矛盾的观点，要如实说明"不同来源说法不一"，并把各自适用条件列出来。

不确定性处理部分，要求模型在检索资料不足以支撑回答时，明确说"这个问题的信息还不够，我需要了解以下信息再帮您判断"，同时给出建议追问的方向。这一步是为了堵住模型硬编答案的毛病。

引用规范部分要求模型在回答末尾对每个关键结论标注出处编号，编号对应检索片段，前端可以用来生成引用列表。

红线兜底部分写的是：凡涉及结构拆改、燃气、水电、消防安全、法律法规的问题，第一条回答必须强调"请以图纸、物业规定和相关主管部门要求为准，必要时应咨询有资质的专业人士"，然后再进入正常答疑。

4.4 引用溯源：解决"你凭什么这么说"

装修咨询和普通闲聊最大的区别是，用户真的会照着你的答案去花钱、去安排施工，所以"说服力"本身就是产品功能。如果AI助手回答完问题用户还是半信半疑，那产品就失败了。

引用溯源的实现不复杂：模型生成答案时，在关键结论后面插入引用标记，比如"《住宅装饰装修工程施工规范》"；前端把标记渲染成可点击的小卡片，点开就能看到对应知识库片段的原文和来源信息。实测这个功能对用户信任度提升非常大，很多用户首次看到引用来源时的反馈是"原来你是有依据的，不是瞎搜的"。

但同时要说明，引用并不等于绝对正确。知识库语料本身也可能过时或有误，所以引用卡片上我会同时展示"已有XX人觉得这条回答有帮助"这类产品层面的反馈信息，作为补充的信任增强手段。

5. 实操过程：从0到1把Demo跑起来的记录

5.1 技术栈选择与理由：能外包的绝不自建

这个项目的技术选型原则很简单：凡是成熟的东西，直接拿现成的；只有在知识库和对话编排这些关系到核心体验的地方才自己动手。

后端我用的是Python和FastAPI，拆成三个服务：检索服务、编排服务和网关。检索服务负责查向量库和BM25索引，编排服务负责调大模型API、解析回复、组装引用，网关负责对话接口、历史记录和限流。

大模型选的是市面主流的商用大模型API，没有自己部署开源模型。原因很现实：对话生成对指令跟随能力要求高，开源小模型在这个场景下控制不好格式，编造率也偏高。商用API虽然按Token收费，但省去了显卡成本和运维精力，前期跑Demo阶段这笔账是划算的。Embedding模型同样走的API，降低成本同时保证效果。

向量数据库选的是一套开源方案，本地部署，支持元数据过滤和混合索引。之所以选开源而不是云托管，是因为数据量目前只有几十万条，本地部署完全扛得住，还能省下云端的固定开销。

5.2 数据入库流程：从原始语料到可检索知识

数据入库这条流水线，我大概分成七个步骤，每一步都有产出物：

1. 采集：从公开渠道收集规范、攻略、问答、报价模板原文，产出原始文档目录；
2. 解析：把PDF、网页、公众号文章转成纯文本，统一编码，产出干净的TXT文件；
3. 清洗：去广告、去转码乱码、去重复段，产出清洗后的语料文件；
4. 分块：按标题段落切块，控制在300到500字，做50字重叠，产出语料块清单；
5. 标注：给每个块打上来源、年份、地域、适用场景标签，产出带元数据的语料库；
6. 向量化：批量调用Embedding API，把每个块转成向量，产出向量文件；
7. 入库：把向量、原文、元数据一起写入向量数据库，建立索引，产出可查询的知识库。

第七步之后还差一道质检：拿一批测试问题跑一遍检索，人工检查返回的Top5片段和问题是否相关。这一步不能省，漏到后面模型全靠这些片段回答，出了问题再回头查是哪一步脏了就很费劲。

5.3 接口层实现要点：对话接口远不止"把问题转发给模型"

对外暴露的对话接口，看起来只是一个POST请求，收到用户问题、返回回答，但内部要做的事情比想象中多。

请求进来之后，第一步不是直接发模型，而是先做预处理：拼接用户问题和多轮历史，提取槽位信息，做一次敏感词过滤。然后才是查检索服务，拿到Top候选片段后组装提示词。组装完成才调大模型API，拿到回复文本之后还要做一轮后处理：把引用标记解析成结构化数据，把回答里的"我"改成"助手"，对包含风险词的回复触发兜底话术改写。

接口层还要做好三个保护措施：超时控制（大模型API偶尔会慢，不能让用户无限等待）、限流（防止有人恶意刷接口掏空预算）、日志记录（每轮问答的原始问题、检索结果、生成答案全量落日志，方便后续做数据回流和分析）。这些保护措施一开始觉得多余，后来在试运行阶段帮忙定位了好几个问题，属于做了不亏的投入。

5.4 对话调试与提示词迭代：从"答得出来"到"答得漂亮"

调试过程是最能体现"有没有做过项目"经验的地方。我遇到最典型的一个问题：用户问"墙皮要不要铲掉重新做"，模型直接答"要铲"，但现实里答案完全取决于原墙是耐水腻子还是普通腻子、墙面有没有空鼓开裂。

后来我在系统提示词的回答原则里加了一条硬性要求：如果用户问题涉及的决策强依赖尚未提供的关键信息，必须先指出这个信息缺口，再给出两种情况的方案，引导用户补充信息。加了这一条之后，模型的回答从"武断下结论"变成了"先问清楚再给建议"，专业感完全不一样了。

另一个迭代是回答结构的统一。最初模型的回答风格飘忽不定，有时候一大段文字糊过来，有时候又只有一句话。我在提示词里规定了一个回答模板：先说结论或者先说明需要补充什么信息，然后列出要点，每个要点不超过三行，最后给参考依据。模板化之后，前端甚至可以根据回答结构做卡片化渲染，交互体验直接上升。

6. 上线后的常见问题与排查实录

6.1 回答质量差：十有八九出在检索这一环

试运行阶段收到最多的反馈是"答案不对"和"答案感觉是在硬凑"。第一反应可能是提示词写得不行，但排查了半天，绝大多数问题最后都定位在检索侧。

排查方法很简单：把用户的问题单独丢进检索服务看返回的Top5片段。如果Top5里根本没有和问题高度相关的内容，那答案怎么组织都是错。这时候要检查三个地方：语料分块是否太粗或太碎、向量化模型是否选对了领域（通用模型偶尔对装修术语编码不准）、标签过滤条件是否太严格把正确内容过滤掉了。

有一类典型问题是"答案通顺但引用来源对不上"。这种情况通常是重排阶段出了问题，某段来源正确的语料排名靠后了，模型只好从次优的片段里找论据。解决方法是调整重排模型分数权重，或者把初筛的候选数量从50条放大到80条，给重排更多选择空间。

6.2 多轮对话跑偏：问题出在上下文管理

用户连续问三个问题之后，模型开始"记忆混乱"，把前面对话里提到的面积、城市张冠李戴，甚至开始重复前几轮的内容。排查后发现是把全部历史消息都塞进了提示词，旧信息和噪音太多，模型分不清哪个才是当前有效的约束。

优化方案是三层处理：历史只保留最近两轮（太久的对话信息对当前语义帮助有限，反而制造噪音）；每次追问提取出的结构化槽位（面积、城市、房型、预算）单独注入提示词，代替原始聊天文本；对话主题切换时做意图检测，如果新问题意图变了，主动清空历史上下文。这三层加完，多轮对话的稳定性好了很多。

6.3 Token费用失控：检索内容太长悄悄吃掉预算

RAG项目里Token消耗的大头不在模型生成，而在重复把检索片段一遍遍送进提示词。初期我每次回答给模型塞了8条片段，加上系统提示词和对话历史，单次请求经常超过6000个Token，一个月下来费用相当可观。

后来做了三件事：片段从8条减到5条，重排打分前5名优先，这5条在拼接成提示词之前，先用模型做一个提取压缩，只保留和问题最相关的句子；对高频问题做答案缓存，同样的问法直接命中缓存不重新调模型；非高峰时段批量处理离线知识问答，把结果存下来供有相同问题的用户即时获取。三招下来，单次对话平均成本降到原来的三分之一。

6.4 安全兜底：装修回答必须"留一手"

装修咨询不是纯聊天，说错一句话可能让人家花冤枉钱，更严重的可能涉及安全问题。所以系统里专门做了一层安全兜底。

兜底逻辑写在两个层面。第一层是触发词匹配，用户问题里出现承重墙、燃气管道、消防通道、电箱改造这类词时，系统强制在回答最前面插入一句安全提示：请以图纸、物业规定和相关主管部门要求为准，涉及结构安全务必咨询有资质专业人士。这句提示在提示词和代码两层都做了强制，防止模型漏掉。

第二层是回答内容控制。涉及拆改、负荷、防水这类关键问题时，模型被要求不能给绝对的指令式回答，而是给"检查方法和决策依据"。比如用户问"阳台隔墙能不能敲"，回答会包含如何判断是否承重墙的方法、物业报备流程、以及"未经专业确认前不建议施工"的明确提示。这套兜底上线以来，没有出现过一次越过安全线的不良回答。

7. 从实战里提炼的几条心得

最后说几条这个项目做完之后我个人最深的体会。

第一，垂直行业的AI助手，核心不是AI而是行业知识。模型能力各家都差不多，差距在知识库的质量和组织方式。我在知识库上花的四成时间，最后证明是性价比最高的投资。

第二，产品定位决定技术方案的复杂程度。如果我只想做"聊天玩具"，那纯大模型就够了；但要做"可用的咨询工具"，就必须接受RAG带来的工程复杂度。这个取舍要在大规模开发前想清楚，不然后期返工成本极高。

第三，引用溯源不是锦上添花，而是刚需功能。没有出处的AI装修建议，用户不敢信，自然也不会用。加了引用之后，用户的使用深度和问题复杂度明显提升，这是个真实的信号。

第四，安全兜底不能只写在提示词里。提示词可以被模型"遗忘"，所以关键安全逻辑必须在代码层强制执行。这个原则适用于任何涉及人身财产安全的AI应用场景。

如果你也想做类似的东西，我的建议是别一开始就铺得太大。先选定一个细分的场景做深做透，比如就做"老房卫生间翻新答疑"，把这一个场景的知识库做到极致，比做一个什么都懂一点的泛装修助手有意义得多。场景收窄之后，知识库规模变小、检索精度变高、回答质量显著提升，用户的付费意愿和口碑传播也会跟着来。

这个项目后续可以扩展的方向很多，比如接入装修公司的报价系统做AI报价解读、根据用户户型和预算生成方案清单、把施工过程中的验收节点做成AI巡检问答。核心的检索增强架构不用动，往知识库里加新的语料类型，就能盖出新的功能楼。这套路子，不只适用于装修，任何一个信息密度高、决策链条长、用户信任成本高的行业，都值得用同样的方式重新做一遍。