家居装修这个行业，信息差一直大得离谱。你自己上网搜“卫生间干湿分离怎么做”，能翻出几百篇互相打架的文章，有的说尺寸要90公分，有的说60就够，看完更不知道听谁的。而身边真懂装修的人又少，就算认识一两个搞设计的朋友，你也不好意思天天追着问。这就是我做“家居装修 AI 智能咨询助手”这个项目的出发点：把散落各处的装修知识、常见案例、材料参数、验收标准全部收进一个知识库，再让大模型基于这些资料直接回答用户问题，把“大海捞针”变成“一问即答”。这篇文章就聊聊这个 AI 助手从想法到落地，我踩过的坑、试过的方案，以及你完全可以照着复现的实操过程。
这个项目听起来高大上，但本质上就是三件事：建一个高质量的装修知识库、接一个大模型接口、写一套能把用户问题接住并精准回答的对话逻辑。适合谁看？想给自家装修做个智能答疑工具的业主、做装修行业 SaaS 的开发者、刚入门 RAG（检索增强生成）想练手的同学，都能从里面拿到一点能直接用的东西。
1. 项目整体设计与思路拆解
1.1 装修咨询的真实痛点，到底痛在哪
先换个角度想问题。装修咨询这个场景，有一个非常反直觉的特征：答案就在那里，但你很难找到那个“正确的答案”。比如用户问“墙面开裂了怎么处理”，其实网上有大量关于裂缝分类（温度裂缝、沉降裂缝、腻子层裂缝）和处理方法的资料，但用户不知道自己的情况属于哪一种，所以搜出来的内容对不上号，问来问去还是不知道怎么办。
另外，装修问题的答案往往不是单一的。同样是“铺地板还是铺瓷砖”，南方回南天严重的城市和北方干燥地区，建议完全不同；一楼潮湿的户型和高层采光好的户型，结论也相反。这就导致传统的“百度式”搜索很难给出个性化答案，用户必须自己消化一堆条件，然后自己做判断。很多装修 App 里的问答社区也解决不了这个问题——回复慢，质量参差不齐，还夹杂着各种建材商家的软广。
所以我判断，这个场景的核心需求不是“提供信息”，而是“提供经过筛选、匹配用户具体情境的建议”。大模型擅长这个，但裸用大模型不行——它没有装修领域的深度知识，容易把通用经验当成标准答案，甚至一本正经地胡说。这就是这个项目最根本的设计逻辑：用知识库约束大模型的回答边界，用检索保证答案忠于行业经验。
1.2 为什么选“大模型 + 知识库”而不是其他方案
我在做之前，其实对比过几条技术路线，简单说一下取舍过程。
第一种方案是纯人工咨询，也就是做个表单，用户提交问题后人工回复。这个方案效果可控，但人力成本太高，也没法 7×24 小时响应，用户等半小时才收到回复，体验基本就崩了。
第二种方案是关键词搜索 + 推荐知识库文章，类似给网站加个站内搜索。这个能做，但用户得自己从文章里提炼答案，本质上还是把筛选压力丢回给了用户，没有解决“一问一答”的核心诉求。
第三种方案是裸用大模型，比如直接用通用对话接口。这个方案省事，但实测下来问题很大：模型会把“装修建议”和“行业规范”混为一谈，回答风格过于“通用”，比如你问“厨房台面高度多少合适”，它先给你讲人体工程学原理，就是不告诉你一个具体的参考值。而且你追问“我家身高 165 的做饭人适合多少”，它又会泛泛而谈，给不出基于装修行业经验数据的答案。
第四种方案才是我最终采用的：RAG（检索增强生成）架构。简单说就是先把装修知识库里的内容切成小块、做向量化，用户提问时先从知识库里检索最相关的几段内容，把它们和大模型接口一起打包发给大模型，让大模型“看着资料回答问题”。这样既保留了大模型理解自然语言、多轮对话的能力，又让回答有据可依，不会跑出知识范围。你把这个架构想象成一个新来的咨询顾问，他桌上放着一大摞公司内部资料和案例库，你问他问题的时候，他先快速翻资料，再结合资料给你答复——检索是翻资料，生成是开口说话。
1.3 系统整体架构，画在脑子里的一张图
这个项目的架构不复杂，分四个模块：
- 知识库构建模块：负责收集装修领域的资料，做清洗、分段、向量化，存到向量数据库里。这是整个项目的地基。
- 对话意图理解模块：负责解析用户问题，识别装修相关的实体（比如“卫生间”“瓷砖”“防水”）、判断问题类型（是问材料、问工艺、问价格还是问验收），必要时抽取出用户提到的房屋条件（楼层、面积、地区）。
- 检索模块：根据解析后的查询条件，从向量数据库里召回最相关的知识片段。
- 生成模块：把检索到的片段、用户对话历史、系统提示词拼装成带上下文的请求，发给大模型接口，返回最终答案。
整个链路看起来普通，但每个环节都有不少细节坑。下面我就把从零搭建过程中的关键技术细节和踩坑经验拆开讲。
2. 核心细节解析与实操要点
2.1 知识库不是随便堆文档，切片策略决定回答质量
这是整个项目里最容易被低估的一步。我一开始想得很简单，从网上扒了几百篇装修文章，整个丢给向量化接口，结果一测试就翻车——问“卫生间防水做多高合适”，模型答非所问。
问题出在切片方式上。很多现成工具默认按固定长度切文本，比如每 500 个字切一块。装修文章里经常出现这种情况：前面一大段在讲卫生间防水的施工步骤，后面突然开始讲厨房防水的区别。如果固定长度切，一块切片里可能混着两个完全不相关的主题，检索的时候匹配度就被稀释了。
我的调整方案是：按标题层级 + 段落语义来切。具体做法是把装修资料统一转成 Markdown 格式，根据标题（##、###）把文章切成多个语义完整的区块，每个区块再按 300~500 字切小，相邻切片之间保留 50 字左右的重叠。这样做的好处是：检索时命中的切片，内容主题高度聚焦，大模型拿到的上下文干净，回答自然就准了。
注意：切片重叠这个细节很容易被忽略，但实际影响很大。如果没有重叠，一个知识点刚好被切断在上一片结尾和下一片开头之间时，检索只能命中其中一半，回答就会缺信息。
另外，知识库必须做去重和矛盾处理。不同来源的资料对同一个问题可能有不同建议，比如墙面腻子到底刮几遍，有的说两遍，有的说三遍。这种矛盾如果同时进知识库，大模型就会左右摇摆。我的处理方式是以国家施工规范、知名装修公司内部工艺标准为优先，其他来源打上“经验参考”的标签，在提示词里要求模型优先采信规范类资料，如果资料之间存在差异，明确告诉用户这种差异存在并说明原因。
2.2 提示词设计：把大模型“约束”成装修行家
很多第一次做 AI 应用的人，以为提示词就是写几句“你是一位装修专家”，效果好不好全看模型心情。其实提示词在这类 RAG 应用里承担着三个作用：框定角色、规定回答结构、设定知识边界。
我最终版的提示词大概是这样的结构：
你是一位拥有 15 年家装设计和施工管理经验的资深专家。请根据提供的参考资料回答用户问题，严格遵循以下要求： 1. 如果参考资料中包含明确答案，优先引用资料中的数据和建议，并在回答中标注信息来源类型（施工规范/行业经验/产品说明）。 2. 如果参考资料中没有相关内容，直接回复“这个问题我这边资料库还没覆盖到，建议咨询线下设计师或施工方”，禁止编造。 3. 回答要做到：先给结论，再解释原因，最后给出可执行的建议步骤。 4. 如果用户问题涉及房屋具体情况（楼层、面积、地区、家庭人口等），先确认这些信息是否齐全，不齐全时主动追问。 5. 涉及价格、工期时，给参考区间而不是绝对数字。 6. 禁止使用模糊词汇，如“可能”“大概”这类词最多出现一次，每个建议都应落到具体参数或动作上。这里面最有价值的是第 2 条和第 6 条。第 2 条解决大模型“爱编”的老毛病，实测下来，加了这条之后回答的“幻觉率”明显下降。第 6 条则是用规则强制模型输出可执行的答案，而不是正确的废话。比如问“砌墙要注意什么”，如果没有这条约束，模型会给你一段“要用砖、要抹灰”的废话；加了之后，模型会直接告诉你“红砖要提前一天浇水湿润，新老墙交界处每隔 50 公分要植筋，顶部要用斜砌砖”。
提示词还有一些动态拼接的部分。我会把用户对话历史、检索引擎召回的原文片段、用户画像信息（如果有）一并写进请求里。整体的请求结构是：
系统提示词（固定不变的部分） + 知识库检索到的参考内容（每个片段前面标注来源） + 最近两轮对话历史 + 当前用户问题这个拼接顺序不是随意定的。把参考内容放在对话历史之前，是为了让模型在生成回答时，注意力能集中到资料上；把用户问题放最后，是很多大模型 API 的习惯——越靠近末尾的内容，模型往往会越重视。
2.3 多轮对话状态管理：让助手记住你说过什么
装修咨询天然是多轮对话场景。用户第一句可能只问“厨房怎么设计”，你回答了之后，他才会补充“我家厨房只有 4 平米，而且光线不好”。如果助手不记得第一轮聊了什么，第二轮回答就成了空中楼阁。
做多轮对话，市面上有现成的框架，但我说说我是怎么自己控制的。我维护了一个会话记忆队列，最多保留 6 条最近的对话记录。每轮生成请求时，把队列内容拼进提示词。超过 6 条时，按时间顺序丢弃最老的记录。
有个容易被忽略的细节：要存的是“原文”，不是“模型提炼过的摘要”。我之前试过，用大模型把每轮对话先总结成摘要再存，这样做虽然省 token，但会丢失很多关键实体。比如用户说“我家的墙是轻质砖，能不能挂电视”，如果你把摘要总结成“用户询问挂电视条件”，那“轻质砖”这个关键信息就丢了。直接存原文，虽然每次请求多花一点点 token，但信息保全度高得多。
注意：多轮记忆不是越多越好。对话超过 6 轮之后，模型经常会“迷失在上下文中”，反而把早几轮的过时信息当成当前条件。6 条是最适合我这套系统的长度，你可以根据自己的场景调整，但别超过 10 条。
2.4 意图识别与实体抽取：让检索更精准
用户的问题五花八门，有些问题根本没法直接拿去检索。比如用户问“开放式厨房能不能装燃气热水器”，这个问题里检索关键词如果是“开放式厨房”和“燃气热水器”，召回的结果往往不够精准，因为最核心的知识点可能是“厨房通风条件对燃气设备排烟的要求”。
所以我在检索之前加了一个轻量的查询改写层：先把用户问题交给大模型，让它提取关键实体和查询条件。大概是用这样一个小提示词：
你是一个查询解析器。请从用户问题中提取以下信息： 1. 空间位置：厨房/卫生间/卧室/客厅/阳台/玄关/全屋 2. 涉及的装修项目：水电/防水/瓦工/木工/油漆/收纳/建材/家电 3. 关键限制条件：层高/面积/楼层/地区/家庭成员/预算档位 4. 提取用于检索的核心关键词，重写为一段简洁的描述 只输出 JSON 格式，不要多余解释。输出大概是：
{ "space": "厨房", "project": "燃气设备安装", "constraints": {"通风": "开放式厨房"}, "query": "开放式厨房 燃气热水器 排烟 通风 安装条件" }这个改写过后的 query 拿去做向量检索，命中率明显比原句更高。为什么？因为大模型把“开放式厨房能不能装”这个模糊问法，拆解成了“排烟”“通风”“安装条件”这几个在知识库文章里真正出现过的关键词和概念。这一步是整个系统里性价比最高的一笔投入。
3. 实操过程与核心环节实现
3.1 技术选型：这是一套花钱少、上手快的组合
说下我用到的具体工具，都是个人开发友好的选择：
- 知识库来源：国家建筑装饰装修工程质量验收规范公开摘要、《住宅设计规范》公开资料、几家装修公司公开的工艺标准文档、知乎/贴吧等平台的高赞问答（清洗后使用）。
- 向量化模型：用的是开源的中文向量模型，本地跑，不花 API 费用。如果你的机器配置一般，可以用现成的向量化接口，费用很低。
- 向量数据库：用开源向量数据库，支持本地部署。短期数据量在几万条以内完全够用。
- 大模型接口：用的是国内某大厂的通用对话接口，为了控制成本，选择中档型号，问题不大。
- 后端框架：Python 的 FastAPI，轻量、文档自动生成、异步性能好，适合快速搭建。
- 前端界面：第一版只做了简单的 Web 聊天界面，原生 HTML + JavaScript，没有引入任何前端框架，避免过度工程化。
整套系统的成本，如果不算人力的话，主要是大模型接口调用费。日常测试和少量并发使用，一个月几十块人民币。生产成本取决于用户量，按调用次数计费，每轮回答大约消耗 1000~1500 个 token。
3.2 知识库预处理：从一堆杂文到干净的切片
这一步是整个项目里最脏最累但最关键的。我做了几件事：
清洗。网上扒来的文章自带一堆广告和无关内容，我写了一个清洗脚本，规则包括：去掉所有链接、去掉图片引用、去掉“关注公众号”等营销段落、把全角符号转半角、统一数字格式。
规范化。把 HTML 转成 Markdown，然后按标题结构重组。我的做法是把常见标题词（“一、”“二、”“1.”“1）”“第一”）全部统一成 Markdown 的##或###格式，方便后续按标题切片。
切片。我最终的切片逻辑是：
import re from typing import List def split_markdown_by_heading(text: str, max_chunk_size: int = 500, overlap: int = 50) -> List[str]: """按 Markdown 标题层级切块，超过最大长度时按段落继续切，带重叠。""" # 按标题分割 sections = re.split(r'(?m)^(#{2,3})\s+', text) chunks = [] for i in range(1, len(sections), 2): level = len(sections[i]) content = sections[i + 1].strip() if not content: continue # 如果内容太长，按段落再切 if len(content) > max_chunk_size: paragraphs = re.split(r'\n\s*\n', content) current = "" for para in paragraphs: if len(current) + len(para) > max_chunk_size and current: chunks.append(current.strip()) current = current[-overlap:] + "\n\n" + para else: current += "\n\n" + para if current: chunks.append(current.strip()) else: chunks.append(content) return chunks这个脚本是核心，但它解决的问题深度有限。真正要命的不是切，而是切出来的块要“接得住上下文”。比如一篇讲“卫生间防水”的文章，标题是“施工步骤”，下面的内容可能包含“涂刷第一遍防水涂料后要等 12 小时”，这个“12 小时”如果没有前文“第一遍”，单独检索出来，模型不知道说的是什么。所以我切完片之后，在每块开头加了它所属的一级标题作为前缀，比如“【卫生间防水·施工步骤】”。实测下来，这一个小改动让回答准确性提高了不少，因为大模型拿到切片时，一眼就知道这段在讲什么，不会误读。
3.3 向量化与检索：建立“语义索引”
切片完成后，需要把每段文字转成向量。这个过程要特别注意向量化模型和检索时用的模型必须一致。我有一次换了向量化接口，但忘了更新检索端的模型，结果检索出来的内容驴唇不对马嘴，折腾了半天才排查出来。
入库时每一条记录包含这几个字段：
id：唯一标识content：切片文本source_type：来源类型（规范/经验/产品说明）source_name：来源名称title：所属一级标题vector：向量化结果
查询时做两步：先向量检索出 top 20 相关切片，再用关键词做一次 BM25 检索（这个用开源检索库就可以），最后把两路结果做加权融合，取最终 top 5 作为大模型的参考上下文。为什么要做混合检索？因为向量检索擅长找“意思相近”的内容，但个别装修术语还是要精确匹配才靠谱。比如用户问“踢脚线”的时候，向量检索可能召回一些关于“地脚线”“墙角保护”的内容，而 BM25 能稳稳地把包含“踢脚线”字眼的文章捞出来。两路并行走，互补效果很明显。
3.4 对话接口：把知识库和大模型串起来
这是核心逻辑代码，我用 FastAPI 写了一个接口：
from fastapi import FastAPI, HTTPException from pydantic import BaseModel import openai app = FastAPI() class ChatRequest(BaseModel): session_id: str message: str class ChatResponse(BaseModel): answer: str sources: list # 伪代码逻辑，实际使用时需替换为你的 API 配置 def build_messages(session_id: str, user_message: str) -> list: query = parse_query(user_message) # 查询解析 chunks = hybrid_search(query["query"]) # 混合检索 history = get_history(session_id) # 获取多轮上下文 system_prompt = load_system_prompt() # 加载系统提示词 context_text = "\n\n".join( f"[来源:{c['source_type']}|{c['source_name']}]\n{c['content']}" for c in chunks ) messages = [{"role": "system", "content": system_prompt + "\n\n参考资料如下：\n" + context_text}] for h in history: messages.append({"role": h["role"], "content": h["content"]}) messages.append({"role": "user", "content": user_message}) return messages def generate_answer(messages: list) -> str: resp = openai.ChatCompletion.create( model="your-model-id", messages=messages, temperature=0.3, top_p=0.9, ) return resp.choices[0].message.content @app.post("/api/chat", response_model=ChatResponse) async def chat(req: ChatRequest): try: messages = build_messages(req.session_id, req.message) answer = generate_answer(messages) save_history(req.session_id, req.message, answer) return ChatResponse(answer=answer, sources=extract_sources(messages)) except Exception as e: raise HTTPException(status_code=500, detail=str(e))这段代码里面有两个细节值得展开。
第一个是 temperature 参数。我最终设的是 0.3。这个参数控制生成的随机性：越高回答越有创造性，越低越保守。装修咨询是典型的需要“确定性”的场景，温度太高模型容易发挥，给出一些花里胡哨但不实用的建议。0.3 是我测试下来既保留一定表达自然度、又不会跑偏的甜点值。
第二个是 sources 的返回。用户问完问题之后，界面下方会显示这次回答引用了哪些资料，标着“来源：施工规范”“来源：装修公司工艺标准”。这个设计一开始只是为了内部调试方便，上线后意外发现用户对它的信任度明显提升——看到答案有出处，用户更愿意按建议去执行。这也说明，AI 助手不是越像真人越好，让人感觉到后面有专业资料库在支撑，反而更可信。
3.5 前端界面：不炫技，但要把关键信息说清楚
前端我没怎么做花活，一个居中的对话窗口，左侧是聊天记录，右侧是“常见问题快捷入口”。这个快捷入口是上线后根据用户高频问题总结出来的，比如“卫生间防水做多高”“瓷砖通铺注意事项”“全屋定制柜子按投影面积还是展开面积算”，一键点进去就能问，降低用户输入门槛。
消息气泡里，答案下面是折叠的参考来源列表，点开能看到具体的引用标题和原文片段。输入框旁边加了一个免责声明小字：“建筑做法受地区、房屋结构、材料品牌影响，建议结合线下专业意见使用。”这个声明不只是合规需要，也能有效降低系统被当“医嘱”用导致的误导风险。
部署我用了最简单的方案：后端 FastAPI + Uvicorn，前端静态文件直接由后端托管，单机部署，用反向代理加一层 HTTPS。没上 Docker，也没搞 K8s，对于一个个人项目来说，越简单越容易维护。
4. 常见问题与排查技巧实录
4.1 检索结果不相关，是大模型还是知识库的锅
这是调试中出现频率最高的问题。一开始我老觉得是大模型回答得不好，后来证明 80% 的根因在检索环节。
典型现象：问“瓷砖要不要做美缝”，回答时引用的资料却是“瓷砖选购注意事项”。排查思路是：去向量数据库里看检索出来的 top 5 切片到底是什么内容，如果切片本身就不对，那问题出在向量化和检索，不在生成。
这类问题通常有三个原因：
- 切片太碎或太杂，知识内容被切得七零八落。解决方法是调整切片策略，按语义块切，而不是纯按字数切。
- 向量化模型不适合中文长文本。有些开源模型对中文长句理解弱，换个模型测试一圈，往往能找到明显更好的。
- 用户问题本身有歧义。如果“开放”和“封闭”这种词同时出现在备选切片里，检索结果容易跑偏。这时需要优化查询解析层的改写逻辑，让改写后的 query 更聚焦。
排查这类问题有一个笨但有效的方法：把检索到的切片都打印出来，人工判断是不是应该被召回。坚持做几天，你会发现系统哪儿有毛病，心里清清楚楚。
4.2 模型“一本正经地胡说八道”，怎么摁住
大模型隔三差五还是会编出来一些看似合理、实际上没处查证的内容。比如有一次用户问“墙面返潮能不能贴壁纸”，系统回答里居然有“可以使用防潮壁纸，市场常见品牌包括……”——知识库里根本没提过任何品牌。
这种幻觉问题，我控制手段有这么几层，按优先级排：
- 强约束提示词：在系统提示词里明确写“禁止编造参考材料中不存在的信息”，这属于底线，能用但不够。
- 回答要求标注来源：当模型被要求“引用资料时标明出处，不引用时直接承认不知道”，它会有意识地减少自由发挥。
- 结构化输出约束：让模型输出 JSON 格式的答案结构，包含
answer、confidence（置信度）、source三个字段。模型发现要输出source但知识库里确实没有对应资料时，它宁可降低confidence也不太会硬编。 - 后置校验：这是最后一道防线。对模型输出的答案做一次“事实性验证”，把答案里的关键数字和实体抽出来，再回知识库里查一遍有没有对应内容。我刚开始做这个功能，目前只对数字类信息做校验，效果还不错。
4.3 用户问到“系统外问题”，是答还是不答
装修咨询系统免不了遇到边界问题，比如“推荐一款油烟机”“你们能帮忙找施工队吗”这类涉及产品推荐、服务对接的问题。一开始我让系统直接回答，结果知识库里没有品牌库，回答的推荐完全是凭空捏造，我自己看了都觉得不靠谱。
后来我在意图识别层加了一个兜底分类器：把问题分成“装修知识类”“产品咨询类”“服务需求类”三大类。装修知识类正常走 RAG 流程；产品咨询类回复“系统不提供具体品牌推荐，建议到线下门店实测”；服务需求类回复“系统暂不提供施工队推荐，这里整理了一份找施工方的 5 个考察要点”。这个设计既守住了边界，又没让用户带着问题白跑一趟。
4.4 对话时间长了就“犯糊涂”，记忆该存多少
多轮对话还有一个典型问题：聊了十几轮之后，模型开始前后矛盾。比如用户最开始说“预算 10 万”，聊到后面问“全屋中央空调值得装吗”，模型给的回答完全没考虑预算限制。
我排查后发现，问题还不是出在记忆条数上，而是出在记忆的“注意力权重”上。对话历史越长，初始条件（预算、面积、楼层）被淹没在后面的闲聊里，模型自动忽略了。
我的解决方案是：做一个关键信息提取器，每轮对话结束后，把用户的房屋条件和关键约束提取出来，单独存成一个“用户画像”字段，下一轮拼接时放在对话历史之前，并且用特殊标记强调。比如：
用户已知条件： - 房屋面积：89平米 - 户型：两室一厅 - 装修预算：10万元 - 所在地区：南方沿海城市，湿度较高 请注意：以上条件对回答所有问题均有效，回答后续问题时须自动带入这些条件。这样改完之后，哪怕聊了二十轮，系统依然记得用户一开始说的预算和房屋情况。这个细节，说实话比很多商业的 AI 客服做得都好，但实现成本很低，值得做。
4.5 效果评估：怎么知道系统在变好
很多人做 AI 应用，做完就完了，从来不量化效果。我做了一套简单的评估流程，现在分享给你。
评估集：我从真实用户咨询里整理了 100 个高频问题，覆盖空间（厨房、卫生间、卧室等）、项目（水电、防水、木工等）、场景（新房装修、旧房改造、局部翻新）。每个问题都从知识库里找到标准答案，并标记了难度（直接问答 / 需要多条件推理 / 需要结合地区季节等上下文）。
打分维度：针对每个回答，我人工打三个分：相关性（有没有答到点子上）、准确性（关键参数和工艺是否符合行业规范）、可执行性（用户看完能不能照着做）。每项 1~5 分。
回归测试：每次修改知识库或提示词后，用同一套评估集跑一遍，对比分数变化。这个方法能帮你发现“修好一个问题，打崩另一个问题”的回归情况。
我至今还留着最初几版系统的测试结果，相关性从 3.1 分一路涨到 4.5 分，准确性从 3.5 涨到 4.3 分。每次看到数字往上走，就知道这个项目是在真正向前推进的。
5. 部署上线后的运行经验与内容运营
系统上线后，我并没有“撒手不管”，知识库运营反而成了日常最重要的工作。
持续追踪真实提问。我每周会导出用户提问记录，把答不上来的问题、用户追问超过两轮的问题批量整理，入库补充资料。第一周知识库只有 300 多篇文档，三个月后涨到了 800 多篇，其中至少 200 多篇是来自真实问题的驱动补充。
按季节调整知识库重点。夏天回南天地区用户问除湿防潮相关问题明显增多，冬天北方用户问暖气改地暖的增多。我会在季节转换前主动搜集相关优质资料入库，让助手“应季”变得更能帮上忙。
回答质量抽检。每周抽 30 条真实问答，一条一条看，发现问题就回到知识库和提示词层面去修。我把这个环节当成 AI 应用运营的“人工反馈闭环”，这比任何自动化评估工具都管用。
我个人在实际搭建过程中的体会是：这个项目真正难的不是代码，而是知识库的组织和对用户问题的理解。代码那套东西，大模型和向量数据库的文档都写得明明白白，你照着做就行；但知识库怎么切、提示词怎么约束、多轮对话怎么管理，这些全靠一遍一遍测试摸索出来的手感。如果你也想动手做一个，别追求一步到位的完美版，先搭个简单原型跑起来，拿真实用户问题去打磨，两到三周就能看到明显的效果。
最后再分享一个小技巧：做这类垂直领域 AI 助手，别一开始就往里面塞一堆“通用知识”，比如“装修风格分类大全”这种资料，看起来全面，但用户问得最多的问题其实就集中在几十个具体场景里。先把你手上最优质的、针对高频问题的资料放进去，跑起来再慢慢扩。知识库宁精勿滥，这是我做这个项目最深刻的教训，也是给准备入坑的同学最诚恳的建议。
