1. 装修咨询的“大海捞针”用户真正卡在哪里做这个项目之前我先在几个业主群里蹲了差不多一个月也翻了大量装修类社区里沉淀的问答帖子。一个很直观的感受装修咨询这件事用户的耐心极其有限但问题本身却极其发散。同样一句“瓷砖要不要做美缝”有人关心的是价格有人关心的是环保胶有人关心的是和地暖搭配会不会开裂还有人只是想知道自己找的施工队有没有在忽悠。同一个问题背后用户的真实诉求可能差出十万八千里。传统的信息获取路径基本就三条。第一是搜索引擎搜出来一堆广告和互相矛盾的文章第二是装修论坛、社交群去翻帖子信息太散质量参差不齐第三是直接问身边装修过的人但朋友的经验不一定适用你家的情况。这三条路本质上都是“大海捞针”——用户要的不是信息而是针对自己情况的判断。可装修是个低频、高客单、强依赖经验的领域普通人一辈子可能就经历一两次根本没有积累。更麻烦的是装修咨询链条特别长。从一开始的预算规划、风格选型到拆改、水电、瓦工木工油漆工再到主材辅材选购、家具家电尺寸预留最后是软装搭配和验收入住。每一个环节都有大量细节决策点而这些决策点之间又互相牵连。比如厨房电器没定好橱柜的电位、水电位就全定不下来卫生间地漏选错了防水做完之后想再换基本是拆重来。用户意识不到这种牵连问问题的时候只问“这个单品怎么选”但真正需要的是一套连带的决策链条。我在项目初期做的用户访谈里印象最深的一个案例有位业主问“墙面刷乳胶漆还是贴壁纸”我们当时的初版回答给了两种材料的价格、优缺点对比。结果用户下一句直接追问“那我如果选了乳胶漆是不是铲掉原来的壁纸还要加钱需要晾多久才能入住”——他不是一个孤立的问题而是带着施工条件和入住时间约束的。这让我意识到装修问答的难点从来不是“知识库不够大”而是“用户的问题永远带着自己的上下文”传统的关键词匹配式问答根本接不住这种需求。这个痛点映射到技术层面就是要解决三件事第一让助手能理解“用户没直接说出来的条件”比如预算是隐性的、城市的人工费是差异化的第二让答案不是百科式罗列而是带有施工链条的推演材料变了工艺、工期、费用、环保都会联动变化第三用户追问的时候能记住之前的上下文而不是每问一句都从零开始。所以这个项目的核心定位不是做一个“装修百科问答机器人”而是做一个“带装修施工常识的决策咨询助手”。知识库只是底座真正撑起体验的是咨询逻辑和上下文管理。2. 知识工程才是这类助手的天花板很多团队做行业问答上来就囤数据、调模型觉得模型能力强一切问题都解决了。我在项目里最深的体会训练一个庞大模型永远比建立一个准确的领域知识体系容易得多但前者只是“学会了说话”后者才是“真懂装修”。项目前期我们花了大量时间做知识工程大致分三层。第一层知识分类体系。我把装修咨询按照“空间—工程—材料—预算—验收”五个维度拆开。空间维度解决“每个房间有哪些决策点”工程维度解决“施工工序和工艺标准”材料维度解决“品类怎么选、怎么鉴别、怎么计价”预算维度解决“钱花在哪、哪里能省、哪里不能省”验收维度解决“怎么检查施工质量和材料真假”。一个用户问“厨房橱柜用什么板材好”它至少同时落在空间厨房、材料板材、预算不同价位三个维度里。知识只按单一维度组织后期检索一定出问题。第二层经验规则的显性化。论坛帖子、装修纪录片、施工师傅口头经验这些信息源里大量知识是以“如果…那么…”的形态存在的。比如“如果南方回南天严重墙面不要用普通乳胶漆要选防霉级别高的”“如果家里有宠物瓷砖光泽度选哑光的地面不容易打滑”“如果层高低于2.7米新风系统最好走地面送风顶送会压层高”。这些规则单独拿出来都是常识但零散在几百个帖子里用户根本不可能遇到问题的时候就刚好搜到。我们把这类经验规则统一拆成条件-建议-原因-例外四段式结构存进知识库。为什么一定要存“例外”因为装修是高度依赖条件变化的决策没有例外的建议是危险的。比如“乳胶漆比壁纸环保”这条很多帖子这么写但实际如果选了劣质乳胶漆反而比合格壁纸的污染更大不给例外等于给用户埋坑。第三层场景化问答模板。装修用户的实际提问方式极度口语化很多人问的不是“地漏有哪几种”而是“我家两个淋浴间地漏师傅说要买深水封的贵了一倍有没有必要”。这种问题没法靠关键词命中必须把知识组织成“识别场景→确认约束→给出建议链”的模板。我们项目里给几百个高频场景各做了至少三档不同回答深度一句话结论版、标准推荐版、详细推演版。用户赶时间就给他结论他愿意多往下问再一步步展开。做知识工程还有一个特别容易被低估的部分单位、地区、品牌的价格差异数据。装修咨询里只要提到“这个多少钱”就不可能绕开地区因素。同一个衣柜定制在一线城市和三四线城市的每平米计价能差出一倍多同一个品牌的乳胶漆不同渠道的价差也很大。我们做了大量归一化处理所有价格类知识统一标注基准城市、年份区间、上下浮动比例答案里明确告诉用户“这个价格以某类地区为基准你所在的城市具体会有多少浮动”而不是丢一个全国均价让用户自己对号入座。坦白讲这一阶段是最不性感但最决定生死的。我们把大量时间花在读帖子、拆案例、跟工长聊天做录音转写、整理验收规范条文上模型部分反而推进得很快。后来上线实测用户满意度最高的答案几乎全部来自这些显性化程度高、带条件判断的规则型知识而不是模型自由发挥生成的答案。3. 意图识别与上下文管理让追问不再“断片”装修咨询场景下用户对话有三个鲜明特点提问口语化碎片化“柜子歪了怎么搞”“这个能省吗”、每个问题都隐含着前文条件“我家二楼”“预算十万”“已经开工了”、经常在同一个话题里反复横跳“那瓷砖呢”指的可能还是上上文里的墙面。我们的对话链路设计了三层处理。第一层是意图分类区分用户到底在问“选型建议”“价格估价”“施工工艺”“验收标准”“避坑提醒”还是“确认性提问”。这个分类不做对后面检索知识库的方向就全偏了。第二层是实体提取从口语里抓房间、材料、施工阶段、预算约束、房屋条件这些关键槽位。第三层是上文状态维护用一个会话级记忆结构把用户在对话里提到的房屋类型、所在城市、施工进度、预算区间全部保存下来后面的回答默认带上这些前置条件。举一个我们实测中经常出现的例子。用户先说“我家是精装二手房准备局部改造厨房”系统会记录“精装房”“厨房”这两个关键限制。下一句用户问“台面用岩板还是石英石”如果我们直接甩一篇岩板和石英石的对比文章用户大概率会觉得这个助手不够聪明因为他关心的不是材料本身的差异而是“在精装房局改背景下拆旧与安装的成本和施工难度分别有多大”。我们让系统在知识库检索时自动带上“精装局改”这个隐性过滤条件回答里会先给结论再补充局改场景下独有的注意点。多轮追问还有一个坑用户问“环保”系统默认他在问甲醛但他其实问的是施工过程有没有粉尘噪音污染。我们一开始在意图识别里把“环保”统一归类成“材料环保性”结果上线后发现不少用户问环保其实关心的是对家里老人孩子的影响或者施工期间能不能继续住人。后来我们在意图分类里把“环保”拆成了“材料环保”“施工环保”“入住环保”三类靠上下文的施工阶段字段去消歧。施工还没开始默认理解成材料环保已经刷完漆在通风晾晒阶段就按入住环保去回答。上下文管理这块很多团队容易犯的错是想做得太重给每个会话都建一个庞大的结构化档案用户每说一句话就往里面塞字段。实际跑下来根本不是这回事用户大多数会话就三到五轮重结构带来的唯一结果是首轮响应变慢、字段稀疏没意义。我们后面改成轻量记忆只维护当前会话里跟决策最相关的六个槽位房屋类型、施工阶段、空间、预算倾向、所在城市、核心诉求超过六项就把最早的非关键项丢弃。这个取舍让上下文维护成本大幅下降同时用户感知不到记忆丢了——因为装修决策真正依赖的也就这些没那么复杂。4. 从“给答案”到“给决策链”答案结构设计这个项目的另一个核心设计决策答案不能是孤立的结论必须是带决策链的推演。原因很简单装修用户的追问深度往往超过预期一个答案如果只给结论用户下一句往往就是“为什么”“那我该怎么做”“有没有别的影响”。我们在初版测试时发现回答里带不带施工联动信息直接决定用户是否愿意继续对话。带联动信息的回答后续追问率高出将近一倍。典型的例子用户问“卫生间用集成吊顶还是石膏板吊顶”。普通问答会给出两者对比、优缺点然后收尾。我们的回答结构是这样组织的先给一个一句话结论比如“预算有限选集成吊顶追求整体质感和灯光效果选石膏板但如果卫生间没有做干湿分离石膏板要慎重回潮变形风险高”。再往下拆三层第一层讲价格差异集成吊顶材料加人工大概每平米多少钱石膏板加防潮漆加施工的价格区间第二层讲施工条件差异石膏板吊顶需要木工板基层找平、螺丝防锈处理对通风和工期有要求集成吊顶安装快对顶面管线有一定遮蔽作用但不如石膏板整体第三层讲联动影响如果装了风暖浴霸石膏板吊顶要在预设位置预留检修口集成吊顶则直接拆板维修很方便。为什么一定要这么设计因为装修里的很多问题是“决策前置”的。用户在问吊顶的时候很可能已经在做水电或者已经在装浴霸了他问的不只是材料本身而是“我现在这个阶段要怎么调整”。所以每条标准答案里我们都尽力带上施工阶段的标注这张对比表在“水电进场前看”和“木工进场后看”给出的重点完全不同。另一个重要结构是“预算优先级”。装修用户几乎都会被预算卡住但很少有人在提问时把预算准备好。我们让回答里对凡是涉及选型的知识都自动附带一个“预算压力测试”小模块如果预算紧哪些环节可以降配而不影响后期使用如果预算充足哪些升级是值得的。这不是为了推销或者制造焦虑而是装修决策的本质就是在给定约束下做最优取舍。没有预算维度的建议对用户来说可操作性会差很多。我一直觉得家居装修AI助手能不能打关键看它在多大程度上还原了“一个懂行工长和业主对话”的感觉。工长不会给你背材料参数他会问你的预算、装修进度、谁住这个房子然后直接告诉你怎么办。我们做答案结构设计时的目标就是把这种对话逻辑沉淀下来。5. 落地时踩过的坑幻觉问题与知识对抗所有做生成式问答的人都会遇到模型一本正经胡说八道的时刻。但装修场景里胡说八道的代价比一般闲聊域大得多——用户真可能因为你一句“防水做完不用做闭水试验”就在入住后吃了大亏。所以我在这块花了非常多精力给整个系统做了三层防幻觉机制。第一层检索增强前置。所有回答强制走知识库检索流程模型只能基于检索结果生成不允许自由发挥补充经验和数据。用户在测试里会故意问一些知识库里没有的冷门细节比如“地暖回填层的碎石粒径要求”如果检索不到系统不会编而是回答“这个问题我目前没有足够可靠的资料建议咨询你家的地暖厂家或持证工程师”同时主动给出和这个问题相关的三条附近知识。实证下来这个“坦白不知道但提供近似上下文”的模式反而比强答更能建立信任。第二层高风险知识点白名单。装修里有一批“红线级”操作比如拆承重墙、燃气管道改造、水电改造的验收标准、防水闭水试验时长。这些话题我们的规则引擎强制走固定回答模板模板里必须包含“必须由持证专业人员操作/验收”“涉及安全/法规的项目不能自己判断”这类警示句。模型在这些话题上不拥有自由度因为它再能写也不该在一句话里把结构安全和法规边界讲得模棱两可。用户对这一条的感知很强好几位在内测反馈里专门提过“问到拆墙的时候它的回答很稳重不像一般AI那么飘”。第三层矛盾检测。装修领域知识里有一个很常见的问题两个来源的建议互相冲突。比如A师傅说“防水涂料刷两遍就够了”B师傅说“墙面最好刷到一米八”。我们做法是让系统遇到冲突型问题时不站队把争议和各自适用条件都列出来并标注主流做法和保守做法。比如卫生间防水回答就会说“淋浴区墙面防水高度建议做到一米八非淋浴区墙面返高三十厘米即可如果预算允许、想做更保险全墙做一米八成本增加也不算大。两个做法都不算错取决于你家的防水等级需求。”这种回答在知识推演上不是最简短的但它在真实装修场景里是更合适的用户问冲突型问题的本质是想知道“哪个更稳妥”你给一个武断结论不如给一套判断框架。还有个大坑是材料品牌型号的时效性。装修材料市场更新迭代很快某个型号可能去年还在主流推荐列表里今年已经停产或者换配方了。我们在知识库里给所有带品牌型号的知识录都挂了“更新时间”字段和“保守/前沿”标记。上游系统每季度人工复审一次品牌化知识凡是标记超过两年的老型号条目在排序权重里降权避免给过气产品推荐。同时对回答里的带品牌信息我们在模板层面设计了一句缓冲语“具体到你在的城市实际售价和货源建议以本地建材市场为准品牌型号信息可能有更新。”这些机制单拎出来都不算新鲜但把它们组合在一起并且坚决执行就能明显降住生成内容的“虚”。项目后期我们又做了一次rén工抽检随机抽了三百条真实用户会话的助手回答编造率已经降到个位数。尤其是高危类和法规类话题零编造。对我来说这是衡量一个装修助手到底能不能用的底线指标。6. 上线后的真实效果与还值得深挖的方向项目上线一个多月我拿到几个还比较有意思的数据值得分享。整体咨询量里“选型对比”类问题占比最高超过四成其次是“预算估价”和“施工工艺确认”各占两成多“验收标准”类咨询反而最少只有不到一成。这个分布其实挺说明问题的用户在装修过程中最焦虑的不是“怎么验收”而是“选什么”“花多少钱”“这么干对不对”。我们后续把答案深度资源的配比往这三个方向倾斜减少了验收类内容的过度投入因为后者单条知识已经够用用户需要的是在关键节点给一个提炼过的提醒不是长篇大论的规范条文。用户满意度调研里有个细节让我印象很深对话轮次超过四轮的用户满意度评分明显高于只问一轮就走的用户。这印证了我们最初的设计假设咨询助手的价值不在首答有多漂亮而在追问接得住。首答漂亮但追问接不住的产品用户会拍照分享或者收藏但他不会真的把它当成装修路上的工具。只有追问体验足够稳用户才会在每一个决策点上都回来问一遍。从可持续演进的角度看我觉得这个项目最值得继续深挖的方向有三个。第一个是屋况档案与个性化推荐。如果用户在对话里逐步完善自己房屋的真实条件结构、面积、层高、采光、居住人口系统可以反推更精准的建议链条。比如知道家里有老人和幼儿那地面材质的推荐、柜子拉手的高度、卫生间扶手的预留建议就全部跟着调整。现在的方案是问答内记忆下一步要做的是跨会话的长期屋况档案。第二个是施工进度节点的主动提醒。装修咨询最大的痛点之一是“不知道下一步该干什么也不知道现在干的对不对”。如果助手能跟着用户的施工阶段在关键节点主动推一条“你正在做瓦工贴砖这个阶段有三件事千万别忘”类型的提醒那种陪伴感和实用价值会比被动问答强很多。这个功能我们已经在做试点用户接受度非常高。第三个是结合用户所在城市的人工费和材料价做一个更精准的本地估价闭包。目前我们对价格的回答已经做了城市系数修正但还是要用户自查希望后面能做到用户报小区名自动匹配同城同类户型的近期造价参考区间的水平。做一个装修咨询助手的最大感受是真正难的不是让它“会说”而是让它“懂行”。“懂行”意味着它知道你的真实处境、能顺着你的决策链给答案、在不确定的时候知道收敛而非展开。全靠模型自由发挥的问答迟早会在某个边界问题上坑用户。用知识库当底盘、用规则画线、再交给生成模型去表达这套组合到目前为止是我在这个场景里验证过最稳妥的路径。