从房源记录信息，走向销售成交决策系统

支持聊天记录 JSON、多份楼盘知识/词典表和 HomeSeek AI 用户笔记；当前统一读取 5 份 1.1 楼盘知识库、3,409 条有效楼栋与户型规则，并记录导入批次、源文件、工作表、开发商原值与时间。

统一项目别名、面积、户型、电话、时间、群聊和联系人格式；金额必须分类为发布总价、租金、单价、推算约价、首付、定金、佣金或其他费用，并保留原始文本与来源类型。

按统一结构维护开发商、标准项目名、别名、上级项目、分期、楼栋、房号、建筑类型、面积、户型、朝向、总高、梯户比、景观、备注和源文件。开发商读取 1.1 知识库“开发商”列，并同时保存原值与标准值；例如景业知识库中的“景业清水湾三号”按业务规则归一为开发商“景业”，不得把项目名称当作开发商。离线用于发布内容标准化、项目归属和安全字段补齐；在线与原文检索、向量/SQL 召回并行，未命中不得阻断查询。

一条消息可拆分多个房源候选；任何编号项强制开启新候选，分隔线与项目标题辅助切分。每个候选只能抽取本片段内的项目、房号、面积、户型、总价、单价、租金、佣金和联系人。

相同房源关联同一 listing_group_id；同一 wx_id 的重复消息归入同一 offer，不同 wx_id 分别保留为组内独立销售关系。

只向量化每个 offer_id 的最新规范记录，并支持更新、失效和重新生成。

首页以 HomeSeek 品牌标题和统一输入面板作为唯一核心入口；保留 8 个经典业务案例卡片及展开交互，用于覆盖求购、求租、字典事实核查、复杂硬条件和 HITL 补全等典型场景，但不再单独显示“常见场景”标题。案例点击后也必须按当前 active dataset 实时检索，不使用冻结 Showcase 快照。销售提交客户原话后才创建 Conversation 与 Turn，并按当前业务词典、用户笔记和当前版本 Prompt 实时执行意图判断、检索与生成；未发送时不得创建空对话。系统保留完整查询文本，并解析楼盘、产品俗称、销售姓名、手机号、用户标识、预算、面积、户型和交易类型等条件槽位。

房源详情展示楼盘、类型、楼层、面积、价格、房型、朝向、设施、地段和动态匹配度；同组下列出全部负责人、手机号、报价、佣金、税费、发布群、时间和完整历史原文。每条证据保留 message_id 与来源文件并支持命中字段高亮，wx_id 默认隐藏并支持点击“查看用户标识”。

首页案例与销售手动输入使用同一套实时生成机制；每次提交都基于当前 active dataset、完整查询条件、业务词典、用户笔记和本轮独立检索快照，由 Sonnet 4.6 重新生成回答、推荐顺序、风险和追问，不读取预生成答案或固定话术模板。模型必须遵循资深海南房产顾问的人物设定、专业语气和事实边界；词典高置信命中时自然解释术语，词典未命中时继续基于原文与房源证据回答。

每个结论展示来源、更新时间和可信等级；房源匹配度随当前查询条件动态计算，并可解释预算、面积、房型、结构、时效等得分因素。

销售可新建或编辑高置信房源笔记，维护楼盘、房源名称、销售姓名、联系电话、公开范围和 Markdown 正文；正文支持一级至三级标题、正文、有序列表、无序列表、斜体、加粗、删除线、分割线、引用及实时预览。粘贴单条房源信息时自动清理无业务意义的 Emoji 与特殊符号并回填字段；粘贴包含多套房源的长文时，系统按编号、分隔线、楼盘起始行和面积／户型／价格信号拆成独立候选，逐条显示完整度、需校对状态、原始片段与选择状态。整段只有一个手机号且位于末尾签名区域时，可作为公共联系人传播到本批房源；其他电话、价格、户型和正文不得跨条串联。每条拆分笔记必须拥有与单条编辑一致的完整能力：独立设置私人或共享、上传或替换封面、上传最多 9 张房源图片、从图片中设为封面、删除图片、图文实时预览，并在批量保存时随对应笔记持久化。编辑区显示账号已用空间、本次预计新增和剩余容量，底部操作栏不重复展示空间数字。旧笔记按 listing_id、标题、项目、面积与联系人关系回溯原始记录；卡片、查看弹窗、对话内笔记与编辑预览复用同一房源信息组件。

管理员可合并或拆分房源组、处理同一 wx_id 内的误去重、修正销售身份和异常来源；房源归组不得删除任何销售关系。

记录销售采用、修改、联系和成交结果，用于优化排序、话术和置信度。

编辑中文字、元数据和附件自动保存，支持撤销、重做和草稿恢复。每个账号默认提供 10GB 笔记空间，实时显示已用量、剩余量、百分比和附件占用；超额时禁止继续上传并引导清理。

后台模型管理按“意图分析、文字、图像、视频”四类独立配置。意图分析模型必须真实负责“你好”“今天天气怎么样”等寒暄、非房源边界判断、模糊房源判断及对应轻量回复；严格整句寒暄也不得绕过前置模型。文字模型负责智能检索理解、客户专业回复和专业接待判断。管理员保存后，后续新请求从 PostgreSQL 的当前模型配置读取并立即生效，环境变量仅作为配置缺失时的兜底。每次调用必须在 PipeLLM 监控、Token 用量和历史轮次中记录实际模型，禁止后台只展示选择但运行链路仍使用固定环境变量。API Key 只保留在服务端。

查询结果必须先按同一销售相同房源去重，再将去重后的全部房源组、全部销售关系和命中词典数据交给模型，禁止 Top N、抽样或销售人员截断。AI 推荐只影响排序，不得删除未推荐房源；AI 接待页和房源页均需显示本次全部去重结果。重复发布原文和同一销售的重复证据不进入模型上下文，但必须保留在关系库中用于详情追溯。

提交查询后依次显示需求理解、词典、房源记录、语义理解、价格校验、用户笔记和去重归组进度。基础检索产生的候选列表不得直接展示；只有语义重排、价格清洗和去重归组全部完成后，才一次性呈现稳定房源，防止低价中间结果闪现后自动换序。稳定列表立即生成唯一 retrieval_snapshot_id 并持久化，销售顾问 AI 只能读取该冻结快照并异步生成回复。AI 运行期间“更新查询”保持可用，新查询必须取消上一轮请求并废弃旧快照。

查询理解 AI 输出 explicitTerms、inheritedTerms、implicitNeeds、dictionaryTerms、searchExpansions、preferFeatures 和 avoidFeatures。inheritedTerms 只能来自当前 Session 已完成历史，并由服务端反向校验原文依据；程序同时校验 dictionaryTerms 确实存在于真实词典。纯场景查询若没有楼盘、预算、面积、户型、交易类型、当前 Session 继承实体或词典关系等确定性锚点，不得仅凭 AI 假设扩大房源结果，只能用于专业追问。存在锚点时，AI 候选可以重排真实结果，但不得删除销售关系。

每个客户对话创建独立 Session，每次提交创建独立 Turn；同一 Session 最多向模型提供最近 8 个已完成 Turn，并支持“300万以内”“不要地下室”等连续补充。右上角提供“新对话”，点击后取消旧请求、关闭旧 Session、清空输入与结果并创建新 Session。服务端校验 session_id、turn_id 与 retrieval_snapshot_id 的归属，旧 Turn、旧快照或已关闭 Session 返回的结果不得更新当前页面。Session 仅作为运行时上下文，24 小时无活动可失效；原始对话由永久 conversation_id 独立持久化。

清洗程序将“景业清水湾三期”“智汇城云尚A区”“恒大·海上帝景”等原文别名映射到统一标准名称，并按项目、面积、户型、朝向、楼栋和房号逐级匹配字典规则。项目级名称命中后必须把标准名写入规范房源；只有详细规则唯一且不与发布显性字段冲突时才补齐具体分期或属性。存在冲突或多个候选时保留发布原名并记录候选，不得强制覆盖。模型读取 knowledgeReference 时必须区分标准产品知识与实时挂牌证据。

服务端必须以版本化角色配置维护“首席房产销售顾问”身份、性格、五步接待法、自然销售表达和事实边界。客户回复必须像资深中介在即时沟通中真实接待：简单问题简洁，复杂家庭场景要细致说明初选判断、替代方向、关键取舍与执行步骤；每项建议按“已知事实—对选择的影响—下一步动作”自然展开。专业主张可以是联系、核验和看房顺序，不得为了果断强行宣布唯一答案。只允许清除内部术语等底线内容，禁止使用机械短语替换或整句删除破坏语感；禁止检索摘要、客服问卷、固定模板和无证据营销判断。

从提交查询到最终回复完成，页面不得出现无法判断是否卡死的空白或静态等待文本。客户原话只保留在可编辑输入框中，不在侧栏重复以大标题展示。查询理解采用一次有界调用，默认最多等待9秒，超时立即使用确定性与本地语义规则继续，不得连续重试拖延首段回复。需求理解、房源整理和快照确认使用紧凑行内旋转器；收到首个 Markdown 增量后立即切换为分批平滑文本流，避免逐字重绘造成卡顿。客户回复完成后输入框立即停止转圈，内部专业判断继续按顺序加载。房源结果始终独立可用，模型失败不得阻断检索或暴露技术错误。

价格语义、正则边界、编号切分、项目别名、词典冲突和推算字段均作为版本化清洗规则维护。价格提取必须排除“总建面22.7万㎡”“占地面积”“总建筑面积”等项目规模数字，只能把售价、总价、挂牌价或面积乘明确单价作为总价。每次变更必须从源文件重建完整索引，并自动验证定金/首付/佣金排除、项目面积排除、小数单价边界、编号长消息、项目归属、关键楼盘召回和销售关系完整性；任一用例失败不得发布新索引。

每次新客户对话在生成前创建唯一 conversation_id，与运行时 session_id 分离。持久保存对话标题、创建/更新时间、每轮客户原话、客户回复、内部判断、推荐 ID 和房源呈现快照。历史记录以响应式短卡片网格展示，默认不显示选择框和“详情”按钮；点击卡片直接恢复当时完整产品结果，包括房源解读、全部房源、楼盘资料、用户笔记、销售关系、比价、专业判断和追问。历史对话的“对话”模式必须在最后一轮下方提供持续可见的输入框；发送后复用当前持久对话 ID 和隔离会话，立即追加新一轮客户原话，并在原页面渐进显示需求理解、房源整理和流式客户回复。生成期间锁定重复提交；完成后重新读取服务端完整对话，刷新页面不得丢失新增轮次。只有用户主动进入“批量管理”时才显示卡片选择状态和批量删除操作。

后台分为“校验概览”“字典列表”“待处理项目”三个工作区。字典列表必须按上传 Excel 的逐行粒度展示开发商、小区名称、建筑类型、楼栋、房号、别墅房型名称、建筑面积、户型结构、朝向、总高、梯户比、景观面、楼栋样式和备注 14 个字段；使用固定表头、冻结开发商与小区名称两列、横向滚动和每页 50 条，不能再用纵向长卡片或 JSON 编辑器。支持关键词以及开发商、楼盘、建筑类型三级筛选，行内编辑、保存、取消和恢复导入值。服务端通过 GET /api/dictionary/admin 返回聚合词条与逐行规则，通过 PUT /api/dictionary/rules/:ruleId 保存修订；原始 Excel 行永久只读保留，修订值单独持久化并标明修改状态、修改人和时间。完整索引仍必须输出 matched、ambiguous、unmatched 三态统计与全部未收录楼盘清单。

销售顾问 AI 必须根据客户已经表达的信息，动态判断这次找房希望完成的生活、家庭或资产安排，而不是固定套用需求问卷。客户只给楼盘、预算、面积或户型时，从触发事件、期望进展、阻力与焦虑、决策情境中选择最能改变排序的一项自然深挖；客户已经明确养老、度假、换房、投资等场景时，围绕该场景给条件式建议，不得重复询问用途。客户回复结尾最多提出一个场景深挖问题，再加一个会改变排序的硬条件问题，并说明答案将如何影响房源或看房顺序。方法论名称仅供内部 Prompt 使用，客户侧不得出现“JTBD、Job To Be Done、任务理论、需求框架”等术语；由场景推导的动机只能作为待验证假设，不得写成客户事实。

专业接待判断必须由模型基于本轮真实字典命中、房源级校验、楼盘资料、字段冲突和查询理解结果，独立生成“字典与资料作用”。内容分别说明资料参与了名称归一、产品解释、检索扩展、结构化字段补齐或需求验证中的哪些环节；哪些校验通过且唯一一致的内容可作为准确参考；哪些存在多个候选、资料未收录、字段冲突或多个可能值只能作为候选；以及资料帮助发现了哪些原文未直接写出的标准项目、产品结构、参考户型、建筑类型或总楼层数据。隐性需求必须注明来自客户原话与查询理解，楼盘资料只能验证、补充或否定，不能冒充客户动机来源。销售用户可见内容禁止展示英文状态、系统字段、内部房源 ID、null 或代码名，必须转换成自然中文。该判断供销售内部使用，不写入可直接发送给客户的回复。“相关楼盘解释”区域只展示对用户有价值的名称与产品解释，不重复展示“用于名称归一、户型解释和房源字段补齐”“不代表实时挂牌状态”等内部用途或边界说明；这些规则仍在数据与模型层保留。

查询理解必须区分客户点名楼盘是硬限制还是初选方案。出现“只看、仅限、不要其他”等明确限制时采用严格范围，只召回点名楼盘；出现“初步设定、可以更改、需要建议、您更专业、不好决定、还有其他建议”等授权顾问判断的表达时，在保留客户点名房源的同时，按地域、租售、预算、户型、入住时间等硬条件从完整真实索引补充候选。销售顾问 AI 必须先评价客户初选，再推荐 1–3 个真实替代方向，结合家庭成员、租期、楼层、电梯、房屋结构、价格与入住条件说明加入比较的原因和代价；不得虚构楼盘、跨区域或把语义偏好误当硬过滤。客户点名基础项目名时，标准分期名称仍归为客户点名范围。

客户并列说出多个开发商、楼盘、产品或联系人时，确定性解析必须生成完整目标数组，不得只保留第一个或最长实体。同一维度的并列目标执行 OR 召回，不同维度的租售、预算、面积、户型等条件执行 AND 过滤；例如“求购碧桂园，求购雅居乐，求购绿城”必须同时保留三个品牌并统一限定为售房。意图分析与 HyDE/语义扩展在直接召回之后并行补充别名、项目关系和隐性需求，不得删除、改写或替代客户明确点名的目标。多目标结果按目标生成子Tab，每个目标默认展示15套并独立加载；词典没有标准词条的目标仍按发布原文和房源索引返回。

索引载入时根据 message_id 将每条销售证据关联到完整原始记录，不在详情组件临时遍历全量消息。正常查询、原文回退召回和历史对话恢复必须使用同一证据结构；详情展开后完整展示原文及审计元数据，并对当前查询与房源字段进行安全高亮。任一房源或销售关系缺少原始证据都视为发布阻断问题。

顶部导航提供独立定价页，会员方案命名统一为基础版、专业版和团队版。会员状态、积分余额、购买记录与积分流水必须和平台用户 UUID 唯一绑定并由服务端持久化，禁止仅保存在浏览器。购买请求必须使用幂等标识，重复提交不得重复生成订单或发放积分；专业版 450 初始积分每个账号只发放一次。基础版计划提供每日 3 次 AI 房源解读、每次最多 10 组结果与 2GB 笔记空间；专业版以 99 元/月早鸟价提供完整结果、20GB 笔记空间、房源追踪、比价走势、AI 笔记与积分包折扣；团队版提供团队积分池、共享笔记、成员权限与团队追踪，具体额度由商务方案确定。当前测试阶段套餐按钮完成站内登记但不发起真实扣款，也暂不执行次数、空间和功能拦截；原始证据回溯是可信度基础，三档均可使用且不得设置为付费限制。接入真实支付后，会员生效与积分入账必须以服务端支付成功回调为准。

历史记录中的任一对话均可建立房源追踪计划。用户从该对话最新一轮的完整房源结果中选择一个或多个楼盘，并设置每小时、每 6 小时、每 12 小时、每天、每 3 天或每周的更新周期。定时检查只比对选中楼盘的报价、销售关系和发布动态；更改楼盘范围时重建基线，不将范围变化误报为房源下架。历史卡片和对话详情必须显示追踪楼盘、更新周期、下次更新时间和未读动态，并支持暂停、继续、立即更新和停止追踪。

从历史卡片进入对话后，页面固定按“对话—详情—房源—追踪”顺序组织，默认打开对话模式并完整展示历史轮次；详情模式恢复当时的房源解读、楼盘资料、用户笔记、比价、专业判断和追问；房源模式展示完整房源、销售关系与原始内容。桌面端详情模式占满导航以下的剩余视口，左侧楼盘资料与右侧房源结果分别独立滚动，任一侧滚动不得带动另一侧；移动端保持自然纵向浏览。仅已追踪对话显示追踪模式。每次追踪检查必须保存真实报价的更新前价格、更新后价格、变动金额、变动比例和时间；追踪模式使用 ECharts 展示单套房源价格走势、每次更新的整体平均波动、基线与最新房源总数对比、上调/下调次数和平均变动。追踪页提供“价格／百分比”切换并默认进入价格模式。价格模式的房源只展示当前参考价，详情只并列展示区间起点与当前参考价，不在卡片、徽标和汇总数据中直接铺开计算价差；价差与涨跌幅应在鼠标悬停曲线节点时按需呈现。整体走势必须使用连续曲线：价格模式绘制同一计价单位房源的平均参考价，百分比模式绘制相对起点的平均涨跌幅；禁止把售价、月租和年租混算。左侧房源按完整卡片分页加载，任何视口与缩放比例下都不得从半张卡片处截断或因右栏高度产生空白占位。没有新的真实报价差异时，服务端应基于已有发布轨迹或最新报价生成稳定、可复现的模拟趋势，并在标题、统计、图表和 AI 分析中持续标明“模拟趋势”；模拟值不得计入真实价格变化记录，也不得表述为真实调价、成交价或市场事实。Sonnet 只能基于对应数据口径生成销售分析，禁止编造房东动机、市场背景、心理底价、成交概率或谈判时机，出现越界表达时必须自动重写或回退为确定性数据分析。

销售顾问生成任务以 retrieval_snapshot_id 唯一标识并在服务端后台运行，SSE 连接只是订阅者。页面离开、网络短暂断开、刷新或浏览器关闭不得取消已经开始的模型任务；服务端必须缓存该任务已经产生的 Delta、阶段事件和最终结果。用户重新进入同一 conversation_id 后，客户端打开新的 Session，使用原 Turn 和快照重新订阅：先重放已有增量，再实时接收后续事件；最终结果仍写入原 Turn，不创建重复轮次。若只有 Pending Turn、尚未产生快照，则使用原 Turn ID 继续检索；若 Turn 已完成，则直接返回持久化结果。开发环境可使用进程内任务表，生产多实例必须使用 Redis 或持久任务队列保存任务状态、事件游标、租约和幂等键，确保进程重启后仍能恢复。

客户长句必须拆成四类原子条件：楼盘、产品、联系人等召回锚点；租售类型、明确户型、明确预算等强约束；楼层、边户、朝向、装修等偏好排序；租期、起租时间、是否可预定等逐套核验条件。程序先按召回锚点建立候选集，再计算强约束交集并按偏好重排，核验条件不得因房源字段未写明而删除候选。完全匹配为空时不得只显示空状态：第一层保留同项目、同租售类型但其他条件需要放宽的真实房源；第二层保留同项目、同户型或关键物理特征但租售类型不同的负责人线索，只用于询问其是否掌握对应库存。页面和模型必须明确展示已符合、存在差异、联系时确认三组信息；售房线索绝不能写成出租房，出租线索也不能写成在售房，其报价不得换算为客户目标交易类型的参考价。所有分层结果继续遵守同一销售去重、跨销售关系保留和原文证据回溯规则。

每轮房源需求保存常规检索、智能检索和最终判断三套结果。常规检索由程序完成规范化、分词、明确条件识别、词典定位和硬条件门禁；智能检索只有在开关开启时才由 Sonnet 拆分复合意图、隐性偏好、同义表达和 HyDE 候选。当前实现中，模型先读取常规检索冻结的完整候选快照，再对候选做语义理解与排序；不会自行新增快照外房源。若未来要让扩写词触发候选扩展，必须由程序用扩写词二次查询真实索引、重新执行硬条件门禁并重新冻结快照，模型不能直接扩大事实集合。智能检索关闭不影响专业接待判断。两套检索结果不得互相冒充、交叉补齐或共享分页；最终判断按房源 ID 去重并保留全部销售关系，重新校验楼盘、地域、租售、户型、面积、预算、建筑类型和地下空间等硬条件，共同命中优先，其次保留通过门禁的常规独立命中和智能补充，未通过硬条件的房源只能标记为关联建议。房源区域使用“最终建议—常规检索—智能检索”导航，默认展示最终建议，另两项用于核对。客户回复和专业接待判断都只读取最终判断；专业接待判断无论智能检索是否开启都必须生成，并记录实际使用的房源、字典和客户回复证据。智能检索失败时，最终判断可沿用常规结果但必须记录降级原因。

客户未明确表达建筑类型时，确定性检索、原文回退和条件放宽均默认按高层住宅处理，不得混入别墅结果。只有客户明确提到别墅、克拉墅、合院、独栋、联排、双拼、叠拼、排屋、低密、纯地上两层或带地下室等产品信号时，才进入别墅结果；明确说不要或不考虑别墅时继续限定高层。客户同时明确接受高层和别墅时允许两类并行。联系人查询用于核对该人员完整发布历史，不应用默认高层过滤。该边界必须在常规检索和智能检索中保持一致，AI 不得把未表达的别墅偏好写回客户意图。

房源解读中的具体挂牌事实与楼盘资料解释必须可在原句后直接核验。模型使用当前冻结快照中的真实房源 ID 与词典标准词条声明来源，前端按正文首次出现顺序，把普通数字 1、2、3 放入统一角标容器；禁止模型自行编号或引用快照之外的来源。同一段相同来源只标一次，默认最多 10 个。角标桌面端可视尺寸不得小于 20×20px，字号不得小于 13px，常态必须有浅色底与边框，悬停或聚焦时使用黑底白字，禁止退化为难以识别的小号脚注。鼠标悬停或键盘聚焦角标时，房源来源展示楼盘、报价、面积、户型、租售类型与最近发布时间，并提供进入该房源销售关系和原始内容的操作；楼盘资料来源展示词条与解释，不显示导入文件名称；“房源”和“楼盘资料”两类引用都必须保留明确的类型标识。新回复存在模型声明时不得再自动补标；历史回复完全没有来源声明时，前端可按楼盘名、面积和词典词条做确定性兼容补标。流式输出未闭合的内部标记不得短暂显示，复制客户回复时必须自动去掉内部来源标记，只保留干净话术。

顶部导航提供独立“接口监控”页面。除 HomeSeek 业务接口的调用数、成功率和响应时间外，必须将 PipeLLM 作为独立上游服务强监控，分别记录客户回复文本流、需求理解 Tool Use、专业销售判断 Tool Use 和追踪价格分析四条调用链。每条链路展示真实上游请求数、HTTP 状态、报错数、成功率、平均与最近耗时、自动重试、重试恢复、连续失败和流式中断；必须覆盖 400、401/403、429、5xx、超时、HTTP/2 或网络中断，并保留 HomeSeek 请求 ID 与 PipeLLM 上游请求 ID 以便对账。对话界面必须按本轮独立展示“常规检索、智能检索、最终建议、专业回复、专业接待判断”五段耗时：运行中实时走时，完成后固定为服务端实测数值，并在 JSON 结构化日志中进一步拆出索引读取、数据规范化、条件匹配、语义理解、智能召回与最终裁决。错误事件使用 JSON 结构化日志，最近 100 条事件和链路统计持久化，服务重启后仍可查看。页面每 10 秒更新并支持手动刷新，错误使用醒目但可理解的处理判断。监控数据严禁记录 Prompt、房源正文、联系人、授权令牌、API Key 和本地敏感路径；监控采集不得影响主请求成功与响应时间。

每个标准项目必须同时维护项目总览和 project_building_type 建筑类型子词条。高层、洋房、公寓、独栋、双拼、联排、叠拼与合院分别保存离散标准建面、标准户型、产品名、总高和结构说明；禁止跨建筑类型计算项目全局最小／最大面积，禁止展示“91–210㎡”一类混合区间。读取 Excel 时必须还原合并单元格表达的项目与建筑类型，仅在连续有效规则行内继承，空白分隔行不得继承。房源知识补齐必须同时满足标准项目、唯一建筑类型以及面积／户型／楼栋等证据；仍可能对应多个建筑类型时只保留项目命中，不补写任何一类产品属性。客户明确查询建筑类型时只进入对应子词条和房源分支；未明确类型时继续遵循默认高层边界。建筑类型子词条不得反向充当项目标准名，不得制造项目归一歧义。

客户可见回复和销售内部专业判断必须使用独立完成状态。客户回复流结束后，服务端必须先把完整 Markdown 写入原 Conversation Turn，并将状态标记为 reply_complete，随后才能发送 customer_done 和继续等待内部判断。两阶段分别执行带退避的自动重试；重新进入未完成对话时复用原 Conversation 与 Turn，从当前阶段自动续跑，不要求用户重新发送，也不得创建重复轮次。已有客户回复时只重试内部判断，不再发送客户回复 Delta，成功后把同一 Turn 升级为 complete。任何房源快照刷新都不得把 reply_complete 降级为 retrieved；页面不得再显示“可以重新发送”类提示。

意图分析必须把请求分成非房源、模糊房源和明确房源三条路径。非房源进入 HomeSeek AI 边界回复；明确房源进入常规检索；模糊房源必须先进入可恢复的“等待补充”状态，不得提前查询房源、楼盘资料或用户笔记，也不得创建检索快照。客户没有说清求租或求购时，“找房方式”必须作为必填项，以等宽按钮直接选择；缺少楼盘或区域、户型、预算、入住时间、租期、楼层要求或产品类型时，页面按字段名称提供选择或输入，必填与选填清楚区分，选择求租后才显示入住时间和租期。界面只使用“先确认找房方向”“还差这几项”等普通用户语言，不展示 HITL、结构字段、意图路由等技术词。服务端持久保存原始客户表达、已经识别的条件、缺少字段和补充状态；刷新页面、进入历史记录或重新打开 Conversation URL 后，最新待补充卡片仍可继续操作。用户点击“补充完成，开始找房”后，系统把原话与人工补充合并成同一 Conversation 的新 Turn，经安全校验后进入完整检索；已补充的旧轮次只保留追溯文本，不得再次显示可操作卡片。补全协议只接受服务端定义的字段、合法选项和长度，不能成为绕过非房源拦截或提示词保护的入口。

retrieval_snapshot_id 是某一轮回答实际使用的房源证据留档，不是可被下一次查询直接复用的缓存。每份快照必须保存数据版本、全局时间范围、检索规则版本、创建时间、完整房源顺序和销售关系；历史回复、引用卡片与专业判断始终读取其原快照，已完成 Turn 不得覆盖、降级或重新写入。当前数据版本或检索规则版本变化后，历史页面必须将旧快照标记为“历史检索结果／需要重新检索”，明确其不能代表当前结果，并提供“按当前规则重新检索”。重新检索必须创建新的 turn_id 和新的 retrieval_snapshot_id，完整执行当前意图校验、当前有效数据、常规检索、可选智能检索与最终判断；旧快照即使存在错误也保留用于审计，但不得静默冒充当前房源。未完成 Turn 恢复时，若其快照已过期，允许在继续生成前重新核对当前数据并换用新快照；完整 Turn 永远只能通过新增一轮纠错。

每轮房源检索必须记录按客户点名楼盘、区域和交易类型锁定的去重候选套数，以及经过户型、预算、边户、建筑类型等全部明确条件核验后的最终套数，同时保存被排除套数、候选销售关系数和最终销售关系数。客户回复开头直接使用服务端统计说明“先锁定多少套、最终多少套”，不得让模型根据代表性房源明细估算。智能检索开启时，常规与智能候选先按房源 ID 去重，再计算统一候选数和最终数。

服务端必须对当前有效数据范围内的全部候选执行去重、硬条件复核、客户优先级排序和事实核查，全部最终房源及销售关系写入本轮快照；15条仅为页面首批返回与每次加载数量，不得参与截断总数、最终判断或专业回复的统计。进入独立“房源信息”界面后按每次15套持续加载至完整总数。模型输入不得固定截取页面前15套，应在全量排序后使用紧凑字段提供最多120套逐套分析明细，并始终携带完整结果统计；超过模型上下文窗口的部分仍保留在产品完整列表中，模型不得声称其不存在。

模糊房源需求进入补全时，除找房方式和缺少条件外，必须询问客户首要考虑价格、面积、朝向、楼层、最新发布或其他条件。优先项作为结构化条件写入新 Turn；硬条件门禁始终高于偏好，同为明确房源时先按客户选择排序，再比较匹配度与发布时间。选择“其他条件”时展开文字说明。房源列表另提供按客户优先级、价格升降、面积接近、面积升降、朝向和最新发布的即时排序；手动排序只改变展示顺序，不修改快照事实和明确房源边界。

楼盘字典用于核查挂牌事实，不得覆盖原始发布内容。具体产品存在标准建面时，发布面积与任一标准建面差值不超过2㎡或标准面积2%才视为一致；超过阈值即保留发布值并标记“信息存疑”，展示发布信息、字典标准、判断原因和核查标准，要求联系前核对产权证建筑面积、实测口径、楼栋与具体期数。客户目标面积不在标准产品范围内时，系统可以召回相近房源，但必须明确该目标不是已收录标准户型。存疑房源可继续作为真实发布线索，不得未经核实改写为字典面积，也不得作为已确认产品事实向客户承诺。

对话和详情必须使用同一份结构化“事实追查项”，展示客户目标、当前具体项目的字典标准、相关证据、核对结论、核对标准以及等待确认／需要核实／已确认状态。当客户点名具体期数、组团或产品，而面积、户型或建筑类型不属于该实体已收录标准，但字典明确的同一产品集合中存在支持目标特征的兄弟项目时，系统必须在检索前进入人工确认，提供“只查当前范围”和“同时查相关项目”两个选择；用户确认前不得扩大检索、不得创建扩大后的快照。兄弟关系只能来自字典的产品集合关系，相同开发商、相同父级社区或名称相似不能作为扩展依据。确认结果写入新的 Turn 与检索快照，常规检索和智能检索使用相同边界；若没有相关兄弟项目，只保留事实存疑与核实标准，不触发范围扩展。

寒暄、天气等非房源内容仍由前置意图模型完成路由和安全判断，但路由层不得向客户界面预先输出身份前缀、固定文案或半句回复。寒暄回复和业务边界说明均由轻量回复模型一次性组织成完整自然表达，经身份、职责与泄露校验后，通过同一条 SSE 连续输出并持久化；前端不得把固定开场与模型正文拆成两次回答。模型不可用或回复校验失败时，才允许使用完整兜底文案。

“明确房源”和“优先联系”都属于房源判断，统一展示在项目／建面主信息区域；“优先联系”紧跟匹配度，仅在该房源确实进入推荐房源 ID 集合时显示。明确结果不再重复展示“符合当前明确条件”等解释句，销售关系列只展示负责人数量与最近发布时间，不在列表中铺开“先联系某人”或备选联系人；具体推荐联系人及证据进入房源详情查看。