购房是典型的重决策场景：客单价高、决策周期长、信息不完全、答错代价大。用户想问的往往是一句结果（“300 万能在西湖区买多大”），但这句话背后是一连串必须澄清的依赖项。
站在购房用户视角，本作品梳理出三类核心痛点：
痛点一 · 需求高度个性化，难以直接转化为可执行条件 用户只会用大白话描述模糊意向（“预算 100 万、想买西湖区”），但背后的依赖项——预算、名下套数、区域、可行性——必须逐项澄清，否则无法给出有效方案。
痛点二 · 高客单重决策下，用户缺乏一套清晰的购房决策框架 买房涉及预算、套数、区域、可行性、取舍等多维约束，用户往往凭感觉或零散信息推进，容易漏掉关键依赖（如名下套数影响首付与契税、预算与区域存在冲突）。
痛点三 · 购房依赖大量当地政策与流程类背景知识，且高频变动 限购、首付比例、学区划片等口径随时调整，用户自身难以掌握。
这三类痛点，正是本作品以“自然语言转译 + 九态机 + RAG”组合应对的对象，通过可控的智能对话，引导线索转化。
1、 用户说大白话（如“预算100万能买西湖区吗”），系统能听懂并转成结构化需求，回复说人话不堆术语——大模型只负责“听懂、抽槽位、生成”，不做硬决策。详见后文 3. 产品架构图 / 6.2 章节。
2、九态机约束对话方向，对话方向可控、高效引导用户留资：对话被锁定在“需求收集→首套认定→可行性→方案→留资”的必走路径上，不跑偏、不绕过关键环节；走到 S8 终态时按情形分流四类出口（留资 / 转人工 / 交付资料 / 明确拒绝）。详见后文 4. 九态机逻辑流程 / 6.1 章节。
3、RAG 政策库约束，降低合规与客诉风险：政策类回答强制引用到具体条款号与生效日期（如 [HZ-XG-010]），说什么、依据什么可追溯，不凭模型记忆发挥。详见后文 5.1 / 5.2 / 6.3 章节。
4、三道护栏兜底信任与安全：输入闸门（模型只拿到代码算出的事实）、输出校验（回复发出前程序拦截承诺词 / 禁区 / 数字矛盾）、行为兜底（关键决策一律代码拍板）——越权率、误承诺率实测为 0。详见后文 6.2 / 7. 章节。
1 推进逻辑：用确定性状态机，而非大模型自由编排
问题：购房决策链路长、容错低，若让大模型自由决定下一步，易跳步或绕过关键校验。 选择：对话推进（状态转移、中断返回、责任判定）由 Python 状态机代码保证可控、可测、可观测；知识问答交给 Dify 检索，两层接口解耦、可独立替换或降级。
原因：把「流程对不对」从概率性变成确定性，可单测、可回归。
2 行权与兜底：大模型不直行权，硬决策与三道护栏都由同进程代码控制
问题：购房场景容错极低——既怕模型擅自拍板行权（承诺、留号），也怕模型「说错话」引越权、误承诺。 选择：首套认定、可行性、留资等硬决策一律由代码裁决；同时在 Harness 同进程内置三道护栏——输入闸门（模型只拿代码算出的事实）、输出校验（拦截承诺词 / 禁区 / 数字矛盾）、行为兜底（关键动作一律代码拍板）。大模型只负责听懂、抽槽位、生成话术。
原因：把「判得准不准」与「说没说错话」都变成可程序核验的事，越权率、误承诺率实测为 0。
3 知识供给：RAG 只承载 L1/L2，实时状态走代码 / Skill
问题：把实时、精确的事实（房源 / 成交价 / 学位占用）塞进向量库，会产出「相似但错误」。 选择：政策语义类（L1/L2）走 Dify RAG 并强制条款级引用 + 版本戳；L3 实时状态走精确查询 / Skill，不进向量库。
原因：从根上消除实时类幻觉，引用可追溯。
评论