不是检索工具
结果必须包含专业判断、客户回复、推荐顺序、风险提示和下一步追问,不能只展示匹配记录。
HomeSeek AI 不是一个“搜到几条聊天记录”的检索工具,而是面向专业房产销售的接待 Copilot:理解客户原话、判断真实需求、召回可信发布线索、定位发布人和发布场景,并给出比普通销售更完整的回复与下一步成交策略。
建立统一的数据事实层和销售决策层。页面首次打开默认用“我要克拉墅的房子”展示完整接待结果、房源列表和词典解释。该默认结果由 Sonnet 4.6 基于真实房源上下文提前生成并作为产品演示缓存,页面打开时直接呈现,不重复调用模型。销售改写输入框后,系统依次呈现需求理解、业务词典、房源记录、语义理解、用户笔记和去重归组状态,稳定房源组按批次逐步出现;查询理解 AI 只生成隐性需求与检索候选,程序负责查询真实词典和房源索引。检索全部完成后冻结完整房源快照,再由销售顾问 AI 生成专业接待建议。
结果必须包含专业判断、客户回复、推荐顺序、风险提示和下一步追问,不能只展示匹配记录。
每个价格、户型、销售和更新时间都能回到原始发布记录、知识库或用户维护笔记。
相同房源聚合为一个房源组;组内每个 wx_id 仍是独立销售关系,分别展示联系方式、报价、群聊和时间。
“克拉墅”是首屏默认示例查询,用于让销售进入页面后立即看到完整产品能力和已有数据;它不是检索引擎的固定条件。销售提交新内容后,默认示例立即被新查询替换,名称、预算、面积、户型和交易类型等当前条件共同决定结果。
同一对话内的补充条件与连续追问可以继承当前客户上下文;点击右上角“新对话”后必须创建全新 Session,并立即清空上一客户的需求、房源快照、推荐结果和 AI 历史。页面不展示技术 Session ID,不同 Session 之间禁止连接上下文。
Session ID 只负责当前运行期间的上下文隔离;产品在首次调用模型前创建独立 conversation_id,并持久保存每轮客户原话、客户回复、专业判断和房源快照标识。销售可从“历史记录”按 ID 查看、复制、恢复并继续原对话;服务重启不得丢失。
同一个 wx_id 会在多个群反复发布近似内容;这些重复消息会挤占召回,但不同发布人的相似信息本身是有价值的联系入口。
一线销售需要的是“该怎么回、先推哪套、为什么、还要问什么”,而不是几十条群聊原文。
房源有效期、价格波动和扩建信息必须标注来源与置信度;模拟数据只能用于演示,不能伪装成真实证据。
| 来源 | 主要内容 | 在产品中的作用 | 默认可信等级 |
|---|---|---|---|
| HomeSeek AI 房源笔记 | 人工维护的房源、销售姓名、联系电话、富文本、图片、录音、提醒与更新时间 | 优先用于销售推荐和联系人确认 | 高 |
| 楼盘知识库 / 业务词典 | 碧桂园珊瑚宫殿、景业清水湾三号、雅居乐清水湾、云尚智汇城和恒大海上帝景等知识库中的标准名、别名、分期、楼栋、房号、面积、户型、朝向与产品规则 | 清洗阶段统一项目名称并辅助字段补齐;在线与原文和语义检索并行,解释本次命中的业务术语和项目关系。字典属性不等于实时挂牌事实 | 高 |
| 聊天记录 | 挂牌价、当前房况、佣金、销售、电话、发布时间与群聊 | 形成市场动态、房源线索和销售关系 | 中高,需核验时效 |
| 模拟趋势数据 | 没有足够真实历史时的界面演示数据 | 仅用于原型演示,必须明确标注 | 不可作为业务证据 |
输入客户原话,在数秒内获得可以直接发送给客户的专业回复、推荐房源和跟进策略。
检查推荐是否专业、证据是否可信、销售是否覆盖,并沉淀团队统一的话术与判断标准。
管理导入、别名、同一发布人内部去重、销售身份、笔记和异常数据,持续提高召回质量。
系统同时管理房源展示组和独立销售关系:同样的房源只出现一个顶层结果,全部发布销售作为组内明细,不把销售账号互相合并。
当前聊天记录导出文件天然提供 wx_id、发送人、群聊、时间和原文。HomeSeek AI 生成 listing_group_id 用于顶层房源归组,生成 offer_id 表示组内某个发布人的独立销售关系。
覆盖 2026-05-31 至 2026-07-07 的连续导出目录。
全部递归读取,失败文件为 0。
按时间、wx_id / 发送人、群聊、类型和原文生成稳定 message_id。
优先以 wx_id 建立身份,缺失时以发送人进入异常身份空间。
编号清单与多房源长消息独立分段后形成的结构化抽取候选。
同一发布人的重复内容被压缩为 offer,历史消息继续保留。
高置信同房线索归组;无法确认同一套时保持分离。
不同 wx_id 的联系人、报价和来源均独立保留。
用于标准名称、别名、项目关系与产品知识校验。
统一读取 5 份楼盘词典,覆盖项目、分期、楼栋、房号、户型和产品规则。
群名精确为“HomeSeek AI”的内部沟通记录不进入业务索引。
2026.07.18-source-alignment-v14。该版本在金额语义、编号切分、字典校验与短别名保护基础上,新增房源片段边界、需求消息排除、查询回退同规则切分和逐组原文对齐;已从 9,773 个源 JSON 文件与 5 份业务词典完整重建。
追踪计划由后台按周期执行,持久保存基线、最新快照、价格变化、模拟曲线和 AI 分析。分析缓存使用追踪范围与房源事实指纹校验;数据未变化时直接复用,数据变化后后台自动重建。追踪页面每 15 秒只读取一次最新存储记录,有更新时自动刷新,不重复触发房源检索或模型生成。
每条唯一聊天消息都进入原始记录索引。即使某条消息暂时无法抽出项目、面积或价格,仍可通过原文、销售姓名、手机号、用户标识和群聊直接回退召回,不会因为结构化失败而从产品中消失。
导入、消息去重、候选切分、词典标准化、同人去重、跨销售归组、索引生成和前台验证由同一条可重复执行的数据流水线完成;更新聊天记录导出或知识库后可重新生成,不依赖页面手工补数据。
term_id业务术语唯一标识将“克拉墅”、组团别名和产品名称映射为可解释、可扩展的标准词条。
message_id原始消息唯一标识每一条聊天消息一条记录。无论后续如何去重,原文都永久保留。
wx_id发布人唯一标识标识发布账号或销售人员。一个销售可以发布很多套房。
listing_group_id房源展示组标识将相同或高度一致的房源信息聚合为一个顶层房源结果,便于用户先看房源、再选销售。
offer_id组内销售关系标识表示某个房源组下一个 wx_id 的规范发布线索。同一人的重复消息关联到同一 offer,不同发布人分别保留。
listing_group_id 与 offer_id若以 wx_id 作为房源唯一键,同一销售发布的映月湾81㎡、映月湾89㎡和朗月湾102㎡会被错误合并。
相同房源共用 listing_group_id,但每位销售分别拥有 offer_id + wx_id。界面只展示一个房源卡片,展开后完整列出所有销售。
dictionary_terms (
term_id PRIMARY KEY,
canonical_name,
entity_type,
aliases,
definition,
scope_json,
source_ref,
version,
updated_at
)
dictionary_links (
term_id,
related_entity_type,
related_entity_id,
relation_type,
PRIMARY KEY (term_id, related_entity_type, related_entity_id)
)
dictionary_sources (
source_id PRIMARY KEY,
file_name, sheet_name,
source_version, imported_at,
row_count, checksum
)
dictionary_rules (
rule_id PRIMARY KEY,
source_id,
term_id,
standard_project, parent_project,
building, room_no, building_type,
area, layout, orientation,
total_floors, household_ratio,
view_type, building_style, note,
FOREIGN KEY (source_id) REFERENCES dictionary_sources(source_id),
FOREIGN KEY (term_id) REFERENCES dictionary_terms(term_id)
)
dictionary_conflicts (
conflict_id PRIMARY KEY,
message_id,
rule_id,
field_name,
message_value,
dictionary_value,
resolution_status,
created_at
)
publishers (
wx_id PRIMARY KEY,
display_name,
phones,
identity_status
)
listing_groups (
listing_group_id PRIMARY KEY,
project, phase, listing_type,
floor, area, layout, orientation,
facilities, location, structure_features,
group_fingerprint,
group_confidence
)
offers (
offer_id PRIMARY KEY,
listing_group_id,
wx_id,
latest_message_id,
project, phase, area, layout, orientation,
latest_price,
commission,
tax_terms,
latest_published_at,
latest_room,
publish_count
)
offer_messages (
offer_id,
message_id,
PRIMARY KEY (offer_id, message_id)
)
messages (
message_id PRIMARY KEY,
wx_id,
room, content, published_at,
normalized_hash
)
| 层级 | 条件 | 系统处理 | 界面表达 |
|---|---|---|---|
| 同人明确重复 | 同一 wx_id,文本及核心字段高度一致 | 关联同一 offer_id,保留最新规范记录 | “该发布人发布 20 次,可展开全部来源” |
| 同人疑似更新 | 同一 wx_id,主体相同,仅价格、佣金或状态变化 | 保守关联同一 offer,并保留字段版本历史 | “当前报价+历史发布” |
| 同房不同发布人 | 核心房源特征相同,但 wx_id 不同 | 关联同一 listing_group_id,分别生成独立 offer_id | 一个房源组,下面列出多位销售 |
| 来源异常 | wx_id 与发送人同时缺失,或群聊、时间、原文无法定位 | 进入异常队列;仅缺房号、电话或部分房源字段不排除召回 | “来源身份不完整” |
相同房源可以跨发布人归入同一展示组,但销售关系绝不互相合并。真正的重复压缩只发生在同一个 wx_id 内部,原始发布永久保留。
保存导出批次、群聊、时间、发送人、wx_id、消息类型和原文。
统一空格、标点、表情、电话、面积和日期;价格同时区分总价、租金、单价、首付、定金、佣金与其他费用。
每个房源候选必须生成 matched、ambiguous 或 unmatched 状态;命中时将标准楼盘名写入规范记录,歧义或未收录时保留原名并进入审计清单。
编号项、分隔线和项目标题先形成独立房源块,再识别项目、面积、户型、楼栋 / 房号(如有)、总价、单价、租金、佣金和联系人。
先按房源核心特征生成 listing_group_id,再只在同一 wx_id 内生成或更新 offer_id。
更新房源组、销售关系、发布群、发布时间、历史消息和向量索引。
源文件只读,记录导出批次与文件路径。
同人重复压缩,跨销售关系保留。
结构化未命中时回退原文,不丢记录。
名称、买租、面积、户型、预算、销售与联系方式共同生效。
每条关系都能回到消息证据。
人工修正进入下一轮索引与排序。
同一 wx_id 发布相同或高度相似内容时,共用一个 offer_id。规范记录保留最新版本,原始消息全部保留。
不同 wx_id 可以关联同一 listing_group_id,但必须分别生成独立 offer。界面共用一个房源组,销售姓名、电话、报价和来源逐行保留。
同一 wx_id 下若面积、户型、项目或主体描述明显冲突,则保守拆为不同 offer,避免误把两条线索合并。
房号、图片和稳定特征可提高房源归组置信度,但无论归组置信度多高,都不能删除或覆盖任何一个 wx_id 的销售关系。
同一 offer 的新消息更新当前状态,旧消息作为历史版本存在,可查看每次发布的时间、群聊和原文。
房号是高置信归组证据,不是进入索引的前置条件。只要能定位发布人、群聊、时间和原文,记录就继续进入召回;无法确认同一套时保持多个房源组,不强行归一。
只有挂牌、售价、总价、报价、一口价、到手价等明确总价,或在房源语境中无冲突的独立金额,才可进入售房总价字段。首付、定金、佣金、税费、装修款、保证金、原购价、评估价和单价不得冒充当前总价。
“1.”“2、”“①”等编号一律开始新的候选块,即使该行只有项目名或户型名、价格在下一行,也不得继承上一编号项的项目、户型或价格。
项目匹配优先使用最长、最具体的标准名与别名。“恒大”这类开发商品牌词不能把“恒大外滩”等其他项目强制归为“恒大海上帝景”;无法安全标准化时保留原项目名。
原文只有单价且存在可信面积时,可计算参考总价,但必须保存 derived_unit_price 来源并在页面显示“约”;不得写入真实挂牌总价历史或伪装成发布人原始报价。
价格或项目无法可靠抽取时,将对应结构化字段置空并进入清洗队列,原始消息仍进入完整记录索引,可通过原文、发布人、电话、群聊和时间召回。
每次修改正则、词典别名、分段或字段优先级,都要升级清洗规则版本并重建全量索引;固定异常样本和关键业务查询必须自动回归,禁止只在前端隐藏错误结果。
任何进入结构化房源索引的记录都必须具有 dictionaryValidation。已命中项目使用字典标准名称;一个原名对应多个标准项时标记 ambiguous,不自动选择;无对应词条时标记 unmatched 并进入“字典校验”Tab。三种状态数量之和必须等于全部房源组,否则全量构建失败。
编号、明确的房源起点、独立完整房源行和分隔线都可以开始新片段。楼盘、租售、价格、面积和房型只有位于同一片段内才允许共同组成一条房源,禁止跨编号、跨房源行拼接。
长消息可以在同一项目小节内继承项目名称,但一旦出现新的明确项目名、编号边界或分隔线,上一项目上下文立即失效,不得把上一套的面积、户型或报价带入下一套。
在线查询从完整原文索引回退召回时,必须复用离线构建的房源切分、金额语义和字段边界规则;不能直接对整条长消息再次宽松抽取,否则会把已经修复的跨房源组合重新带回页面。
“求购、求租、客户要、谁有房源、麻烦推荐”等需求表达默认排除;只有同一片段同时明确发布出售或出租的具体房源时,才允许将对应发布片段作为供应线索。
sourceEvidence 必须保存实际抽取片段、message_id、wx_id、发布人、群聊、发布时间、原始价格和字段来源。页面展示和审计均回到片段,不只回到可能包含多套房源的整条消息。
允许将“云海帆哥”安全归一为“云海帆歌”、将明确语境中的“碧桂园”归入“碧桂园珊瑚宫殿”;但“果岭公园”等配套或景观词不得被误识别为项目。无法唯一确认时保留原名,不强制归一。
字典只负责名称规范、关系解释和无冲突的知识增强,不能覆盖发布原文中的实时面积、房型和报价。任何清洗结果若不能由 sourceEvidence 或唯一一致的词典规则支持,必须从确定事实中撤回。
正则只负责找到候选数字,不能直接决定业务字段。金额必须结合数字前后的业务词、租售语境、面积和同一句其他金额完成分类,再写入 price_value、price_basis、unit_price、price_raw 等字段。
| 原文类型 | 识别与优先级 | 存储 / 展示 | 禁止行为 |
|---|---|---|---|
| 明确发布总价 “仅售440万”“挂牌268万”“一口价73万” | “仅售、售价、总价、挂牌、报价、一口价、到手价、房东价”等标签后的金额优先级最高。 | price_basis=observed_total;进入预算筛选和真实历史价格。 | 被同句中的定金、佣金或原购价覆盖。 |
| 非总价金额 “首付22万”“20万定金”“含10万佣金” | 首付、定金、订金、佣金、中介费、服务费、装修费、税费、保证金、认筹金、原购价、买入价和评估价进入排除词表。 | 按需要写入独立费用字段;没有发布总价时,总价保持空值。 | 参与“300万以内”等总价过滤、排序或模型判断。 |
| 万元单价 “169平,单价1.32万” | 识别为万元/㎡;只有面积可信时才允许计算 面积 × 单价。 | 保存单价;推算总价为“约223.08万”,price_basis=derived_unit_price。 | 从小数中截取“32万”,或把推算值标成真实发布总价。 |
| 元单价 “97平,单价6392元” | 识别为元/㎡;参考总价为 面积 × 单价 ÷ 10000。 | 与万元单价使用同一推算标记和约价展示。 | 把6392元当月租或把数字直接写入万元总价。 |
| 租金 “5000元/月”“年租8万” | 月租、每月、年租、/月、/年等单位优先判为租房;月租可统一换算成年租用于比较。 | listing_type=租房,价格单位显示“万/年”。 | 与售房总价共用同一数值字段且不记录单位。 |
| 一句多个金额 “20万定金,仅售440万,含10万佣金” | 先排除定金和佣金,再选择带明确售价标签的440万;不能简单取第一个或最小数字。 | 总价440万;定金20万、佣金10万可独立保留。 | 依赖金额出现顺序决定总价。 |
| 小数边界 “单价1.47万” | 金额正则前边界必须同时排除数字和小数点,例如使用与 (?<![\d.]) 等价的边界保护。 | 完整读取1.47万/㎡,按面积推算。 | 从“1.47万”内部二次命中“47万”。 |
| 场景 | 处理规则 | 原因 |
|---|---|---|
| 编号清单 | 任何编号项都先结束上一候选,再创建新候选;后续无编号的面积、朝向、价格行只附着到当前编号项。 | 避免“第17套649万”与“第18套880万”串成同一房源。 |
| 分隔线与项目标题 | 连续横线、项目标题和明显房源标题可作为边界;标题后的属性行只在未出现新编号时继承标题项目。 | 允许处理“项目名一行、面积价格在后续行”的发布习惯。 |
| 同段多个项目名 | 按项目出现位置继续细分,并保证每个片段只使用片段内的面积、户型和金额。 | 整段存在一个已知项目名,不代表后续所有房源都属于该项目。 |
| 项目不在词典 | 从清晰编号项中保留原始项目名,例如“海岸一号”“万绿园壹号”;品牌未知时显示“-”。 | 完整索引优先于强行映射,词典缺失不能造成数据消失或错误归属。 |
| 开发商品牌短词 | 短词只在独立、无歧义的表达中使用;当短词是另一个项目名称的一部分时,不触发目标项目映射。 | 防止“恒大外滩”因包含“恒大”被归到“恒大海上帝景”。 |
只要能够定位发布人、群聊、时间和原文,就保留在完整索引。缺项目、总价、房号、电话或朝向时对应字段显示“-”,不自动舍弃。
面积与单价同时存在时允许生成约价;必须保留公式、原始单价和推算标记,不能覆盖发布总价。
多个金额无法判定、编号边界破损、项目别名冲突、发布字段与词典冲突或同一 wx_id 核心字段矛盾时进入人工队列;修正结果记录操作者、时间、旧值和新值。
只有明确属于系统 XML / 非正文元数据、已配置排除的内部业务群、完全无法定位来源的损坏记录,才允许不进入业务房源候选。即使不进入结构化候选,源文件仍保留用于审计;不得以“抽取困难”作为删除发布原文的理由。
为每个 offer_id 维护一条当前规范记录,将该发布人最新且信息最完整的版本用于向量索引,避免同一销售几十条重复内容占满召回结果。
用户查看详情时,先按 listing_group_id 拉取全部 offer,再按每个 offer_id 展开对应发布人的重复发布、群聊、时间和原文。
listing_group_fingerprint = normalize(
project + phase + area_bucket + layout +
orientation + floor_structure +
decoration_features + image_signature
)
offer_fingerprint = hash(
listing_group_id + wx_id + normalized_text_signature
)
same listing fingerprint + different wx_id:
same listing_group_id, different offer_id
same listing fingerprint + same wx_id + near duplicate:
same offer_id, append message history
项目别名、期数、组团、产品名、户型编号。
产权面积、宣传面积、拓展面积、房厅卫数量。
租售类型、发布总价、价格来源、单价、推算约价、租金、底价、首付、定金、佣金、税费、满五唯一。
wx_id、负责人、电话、群聊、地段、设施、首次/最近发布和在售确认时间。
原文匹配解决显性命中,词典定位补全概念与隐形关系,向量理解模糊表达,SQL 保证硬条件和销售关系准确。检索、去重和房源列表是独立业务能力,完成后立即呈现全部结果;AI 仅在其后读取同一批完整证据生成销售回答,不能决定是否返回房源。
将销售当前输入的完整查询文本与解析出的条件槽位同时送入发布原文、业务词典、向量/SQL 和用户笔记通道。词典是增强通道,不是前置闸门;词典查询失败、超时或缺少词条时,其余召回必须继续执行。
页面按“需求理解 → 业务词典 → 房源记录 → 语义理解 → 用户笔记 → 去重归组 → 专业回复 Loading → 最终结果”推进。基础程序检索先执行;查询理解 AI 在其后补充隐性需求,程序使用候选重新查询真实词典并重排或扩展有确定性锚点的房源。只有去重归组完成后才能生成 retrieval_snapshot_id;最终客户回复、推荐顺序、销售建议和 5 个追问必须基于同一快照一次性回填。
匹配完整查询中的显性名称、联系人和原文关键词,该通道不依赖词典。
对输入中能命中的业务术语逐一查询词典,返回标准定义、别名、适用组团和产品属性;未命中项不阻断其他检索。
查询理解 AI 输出原子化候选词;程序校验真实词典,并在存在楼盘、预算、面积、户型或词典关系等确定性锚点时补充召回。
先按 offer_id 消除同一销售线索的通道重复,再按 listing_group_id 聚合顶层房源;组内不同 wx_id 始终保留。
回答先呈现房源组,详情再呈现组内每位销售及其独立证据。
第一阶段查询理解 AI 只能输出结构化检索计划,不能返回字典事实或房源事实;dictionaryTerms 必须来自程序提供的真实词典目录,avoidFeatures 只用于降权。第二阶段销售顾问 AI 读取冻结快照生成专业判断和客户回复。隐性需求属于检索假设,只有 listings、dictionary 或 notes 有证据时才能写成房源判断,否则只能用于追问和核验。
每个客户对话对应一个 session_id,每次提交对应一个新的 turn_id,每份冻结结果对应唯一 retrieval_snapshot_id。查询理解和销售顾问 AI 只能读取当前 Session 已完成的历史轮次;快照必须同时绑定当前 session_id 与 turn_id。新查询会使上一 Turn 失效,新对话会关闭上一 Session,任何迟到的旧响应都不得回填页面。
前端不拼接固定客户话术。服务端将客户原话、查询理解假设、词典解释、全部去重房源组、全部组内销售来源、历史价格和用户笔记作为上下文,通过 PipeLLM OpenAI Format Converter 路由调用 claude-sonnet-4-6。模型使用强制 Function Tool Use,返回专业判断、成交建议、风险提示、客户回复、推荐房源 ID 和恰好 5 个追问;页面只做安全渲染。
词典返回翡翠湾、海心洲、映月湾、朗月湾等适用组团,以及81㎡、89㎡、102㎡等标准产品线索。
语义匹配、预算、面积、结构和用途。
用户笔记、知识库、发布线索的分层权重。
最近发布时间和最近人工确认时间。
价格、户型、电话、发布群、时间和交易条件覆盖率。
联系人清晰、电话有效、近期仍活跃。
“我要克拉墅的房子。”
先引用业务词典解释:克拉墅是一类产品,不是单一小区;再说明映月湾、翡翠湾、海心洲、朗月湾等组团及81㎡、89㎡、102㎡产品的主要差异。
列出价格、面积、户型、地下室/纯地上、核心优势和信息更新时间,控制数量并给出推荐顺序。
按预算、居住人口、度假/常住、是否接受地下室进行场景化判断,不做无差别信息堆砌。
指出发布报价、产权户型、扩建范围、挂牌状态和底价等需要联系发布人确认的事项。
预算、买或租、地下室偏好、家庭人数/用途、重点组团或面积段,帮助销售继续推进成交。
明确来自用户笔记、知识库还是发布动态,并展示最后更新时间。
顶层只展示一次房源;展开后逐行展示姓名、手机号、报价、最近发布群、时间和发布次数。wx_id 默认隐藏,点击或键盘激活“查看用户标识”后显示。
房源组可以展示历史价格与报价区间,但每个价格点必须绑定具体 offer 与 wx_id,不得把不同销售报价伪装成某一销售的连续调价。
缺少真实数据时直接表达未知;演示数据必须隔离并标记,不进入正式回答证据。
客户可见内容不出现“检索、命中、业务词典、独立销售关系、索引”等系统术语。统一表达为“已核对房源、目前有哪些选择、建议先看哪套、还需确认什么”,让回复像资深房产顾问,而不是数据查询结果。
房源证据固定展示楼盘、租售类型、楼层、面积、价格、房型、朝向、设施和地段;同时展示基于当前客户条件计算的需求匹配度及来源置信度。
每条笔记必须绑定房源名称、销售姓名和联系电话;图文与录音附件记录用量、最后编辑时间和编辑人,不与群聊转发证据混为同一来源。
销售昵称和普通文本正文可以参与手机号识别;表情、图片、视频、链接及系统消息的原始 XML、URL、filekey、UUID、MD5 和 productid 一律不参与。号码前后若连接字母、数字或下划线,也必须判定为技术标识并排除。
群名精确为“HomeSeek AI”的内部沟通记录不进入完整消息索引、销售关系、手机号关系、房源候选和模型上下文;仅保留原始导出文件用于必要的审计追溯。
单楼盘查询在AI接待和房源证据中默认展示10条,每次继续加载10条。多楼盘查询按客户明确点名的楼盘生成子Tab,每个楼盘拥有独立的10条首屏和独立加载进度;切换Tab不得丢失其他楼盘结果。单个楼盘在AI回复区最多展开60条,超过后提供进入“房源列表”查看完整结果的入口,完整数据仍保留在检索快照与模型上下文中。
房源证据支持按开发商、楼盘、租售类型、价格、房型、面积、楼层、朝向和发布频次筛选,租售类型必须分别显示售房与租房数量;选项仅根据本次结果生成,发布频次支持按历史发布次数从高到低排序。原文没有写明某项内容的房源默认保留,并归入“信息未标注”;选择明确条件时不得推测其满足条件。
房源快照冻结后,客户可见 Markdown 文本流与销售内部结构化分析并行生成;客户文本从模型首个文字开始通过 SSE 展示,不得等待结构化工具参数完成后再伪流式回放。页面使用紧凑字号、Markdown 段落/列表/加粗和动态光标;销售内部分析完成后再合并展示,最终结果仍必须通过完整结构化校验与 Session 校验。
明确的项目、户型、价格或联系人查询,在程序检索与词典匹配已经得到稳定结果时,不额外等待语义扩展模型;客户文本流使用包含全部房源组的精简快照,销售内部分析仍使用完整销售关系与历史证据。必须先建立客户文本流,收到首个文字后再启动后台结构化分析;禁止为模拟打字效果人为切块和延时。前端以动画帧节流 Markdown 重绘,不得因每个 token 全量重绘拖慢流读取。
需求理解、房源整理、完整快照确认和专业回复生成都必须提供可感知的动态状态。检索阶段使用紧凑的 14px 黑色行内旋转器,专业回复阶段使用 Loading 卡片与流式光标;状态完成后自动消失。支持 prefers-reduced-motion,但不得退化为没有状态变化的静态灰字。
正文与列表之间必须有空行;每个楼盘使用独立一级列表项,核验提醒使用三级缩进子列表;分隔线 --- 必须独占一行;有序步骤结束后空一行再提出追问。禁止出现“正文- **楼盘**”“---下一步”或步骤与问题粘连。
不得向客户展示“字段缺失、字段为空、null、补齐字段、结构化字段”等内部表达。应具体说明“这条发布信息没有写明是否带地下空间”“具体楼层和朝向需要向负责人确认”,或在不影响判断时自然省略。
模型流式输出、最终落库文本和历史对话重新展示都执行同一 Markdown 格式修复与技术措辞保护;修复只处理明确的粘连和内部术语,不得机械删除正常内容或破坏合法分隔线。
每个房源组下的每位负责人都必须关联至少一个真实 message_id。展开“原始发布内容”后展示完整发布原文、发送人、群聊、发布时间、来源文件和证据 ID;当前房源对应的楼盘、面积、户型、报价、联系人与电话使用 Shadcn Light 基础黑底白字高亮。高亮必须拆分安全文本节点实现,不得拼接伪原文,也不得使用 HTML 注入。
HomeSeek AI 的客户回复不是检索摘要,而是销售接待动作。模型必须像长期服务老客户的资深房产销售总监:先听懂客户、给出明确选择、说明优先顺序,并用一到两个关键问题推动下一步;同时所有判断必须能够回到本次冻结的真实房源、楼盘资料、销售来源或用户笔记。
服务端以独立的 SALES_ADVISOR_PERSONA 维护销售角色,客户可见文本流和销售内部分析共同继承该角色。角色配置与事实规则、输出格式、Session 历史和冻结房源快照分层管理,后续可以版本化、A/B 测试和按组织配置,但不得由前端随意拼接固定回复。
拥有 10 年以上海南高端住宅、度假房和养老房实战经验,熟悉项目差异,也懂客户决策心理。目标是帮助销售推进客户,而不是展示模型或数据能力。
笃定但不武断,主动但不催促,诚实但不把免责声明放在开头。不油腻、不堆砌术语、不用客服和研究报告口吻。
一轮回复后,客户应清楚有哪些方向、先看哪类、为什么,以及只需补充哪一两个条件就能进入核房或看房。
| 维度 | 必须做到 | 禁止退化 |
|---|---|---|
| 第一句话 | 直接接住客户,例如“有的”“可以”“这类我先帮您按居住需求分一下” | 先介绍系统流程、数据来源或“根据您的查询” |
| 产品解释 | 只有名称容易误解时,使用楼盘资料在 1–2 句内讲清概念边界 | 把字典内容整段复述,或把标准产品属性当作实时挂牌事实 |
| 选择建议 | 提炼 2–4 个真正影响决策的方向,使用条件式表达说明适用场景 | 把全部房源重新抄一遍,或只给“请结合实际情况” |
| 明确主张 | 给出一个优先顺序或先核哪套的建议,说明依据来自哪些确定字段 | 让客户自己面对数据做研究,或无证据宣称某套更值得买 |
| 结尾推进 | 只问 1–2 个最能改变推荐结果的问题,并说明回答后会执行的动作 | 一次询问买租、预算、面积、户型、朝向、用途等整套问卷 |
| 表达质感 | 简体中文、短段落、必要时使用合法的列表、缩进、加粗与分隔线,像真人即时沟通 | 大标题、列表与正文粘连、模板腔、AI 腔、客服腔、营销口号或长篇免责说明 |
“我想买云海帆歌两房,总价200万以内,平时带父母住。”
直接确认已理解“两房、200万以内、父母居住”三个显性条件,不介绍检索过程。
只比较上下文中明确存在的价格、面积、房型、楼层、朝向、装修、配套和更新时间。
从完整结果中提炼 2–4 个方向;房源列表已在页面呈现时,正文不重复抄表。
明确建议先联系或先看哪类房源,并说明依据;未知信息转为核验动作。
只追问最关键的一到两个条件,并承诺下一步核实房源状态、实际格局、负责人和看房条件。
上下文明确提供的总价、面积、房型、楼层、朝向、装修、交易类型、税费、佣金、发布时间和联系人;可以据此给核验或联系顺序。
客户未说明地下室、老人常住、度假或投资偏好时,可以说“如果您不接受地下空间……”,但不能把假设写成客户已经表达的事实。
不得仅凭面积或总价写“性价比高、入手更划算、住起来更宽松、活动空间偏小、预算还能做软装、很适合老人”等结论。
“有判断”指根据明确内容给选择顺序,不等于补造房屋体验。面积多 8㎡只能客观说明面积差 8㎡;没有户型图、现场信息或用户笔记时,不得直接推断空间感和舒适度。原文没有写明的项目在房源信息卡中显示“-”;客户自然语言不机械朗读“-”,而是省略或转为具体核验动作。
| 禁止表达 | 问题 | 替代方向 |
|---|---|---|
| “根据您的查询,目前共匹配到……” | 暴露产品流程,像检索工具 | “有的,我先按您最关心的条件分一下。” |
| “为了更精准,请提供买租、预算、面积、户型……” | 客服问卷,沟通压力大 | 只问最关键的一到两个条件,并说明回答后的服务动作 |
| “综合来看,可优先关注……” | 空泛、没有销售主张 | 明确“我建议先核实 A,再比较 B”,并说清依据 |
| “以上信息仅供参考,如有需要我可以继续……” | 被动、推卸责任 | “您告诉我预算,我先替您缩小到两三套,再逐一确认状态和看房条件。” |
| “这套性价比很高 / 很适合老人” | 缺乏成交或居住证据 | 客观比较已知字段,把舒适度与适老性转为现场核验项 |
| 阶段 | 页面状态 | 体验要求 |
|---|---|---|
| 需求理解与房源整理 | 14px 黑色行内旋转器+业务文案 | 覆盖需求理解、房源分批出现和完整快照确认;不得只显示静态文字让用户误以为卡死 |
| 专业回复准备 | 紧凑 AI Loading 卡片 | 房源列表保持可查看;不展示模型、网关、服务启动或 API Key 等技术状态 |
| 客户文本生成 | Markdown 流式增量展示 | 首个模型文字到达后隐藏 Loading,不人为逐字延时,不等待内部分析完成 |
| 销售分析完成 | 一次性合并内部建议 | 通过 Session、Turn、快照归属和结构化校验后再更新推荐顺序、建议和追问 |
P0 构成可交付的最小闭环:数据导入、清洗去重、混合召回、关系展开、专业回答和证据追溯。P1/P2 用于运营效率和规模化提升。
支持聊天记录 JSON、多份楼盘知识/词典表和 HomeSeek AI 用户笔记;当前统一读取 5 份楼盘知识库、3,413 条楼栋与户型规则,并记录导入批次、源文件、工作表与时间。
基础能力统一项目别名、面积、户型、电话、时间、群聊和联系人格式;金额必须分类为发布总价、租金、单价、推算约价、首付、定金、佣金或其他费用,并保留原始文本与来源类型。
基础能力按统一结构维护标准项目名、别名、上级项目、分期、楼栋、房号、建筑类型、面积、户型、朝向、总高、梯户比、景观、备注和源文件。离线用于发布内容标准化、项目归属和安全字段补齐;在线与原文检索、向量/SQL 召回并行,未命中不得阻断查询。
知识核心一条消息可拆分多个房源候选;任何编号项强制开启新候选,分隔线与项目标题辅助切分。每个候选只能抽取本片段内的项目、房号、面积、户型、总价、单价、租金、佣金和联系人。
核心算法相同房源关联同一 listing_group_id;同一 wx_id 的重复消息归入同一 offer,不同 wx_id 分别保留为组内独立销售关系。
核心算法只向量化每个 offer_id 的最新规范记录,并支持更新、失效和重新生成。
召回能力首页展示 5 个来自真实客户问题类型的代表性案例:产品名找房、指定楼盘户型、预算与老人常住、多开发商并列求购、宝妈带宝宝与老人长租。案例可以使用短标签,但提交给查询流程的必须是完整客户原话;点击后按当前房源索引、词典、用户笔记和当前版本 Prompt 实时执行,不使用历史固定答案。销售也可改写并提交任意客户原话;系统保留最新完整查询文本,并解析楼盘、产品俗称、销售姓名、手机号、用户标识、预算、面积、户型和交易类型等条件槽位。
召回能力房源详情展示楼盘、类型、楼层、面积、价格、房型、朝向、设施、地段和动态匹配度;同组下列出全部负责人、手机号、报价、佣金、税费、发布群、时间和完整历史原文。每条证据保留 message_id 与来源文件并支持命中字段高亮,wx_id 默认隐藏并支持点击“查看用户标识”。
业务核心默认演示问题“我要克拉墅的房子”使用 Sonnet 4.6 提前生成的真实结果并直接展示;销售输入任何新问题时,回答、推荐顺序、风险和追问由 Sonnet 4.6 基于当前完整查询条件及其证据实时生成,禁止使用固定话术模板替代。模型必须遵循资深海南房产顾问的人物设定、专业语气和事实边界;词典高置信命中时自然解释术语,词典未命中时继续基于原文与房源证据回答。
产品核心每个结论展示来源、更新时间和可信等级;房源匹配度随当前查询条件动态计算,并可解释预算、面积、房型、结构、时效等得分因素。
可信能力销售可新建或编辑高置信房源笔记,必填/关联房源名称、销售姓名和联系电话;支持富文本、大小标题、编号、项目符号、待办、分割线、提醒、图片、音频文件和麦克风录音。笔记独立保存规范房源快照,旧笔记按 listing_id、标题、项目、面积与联系人关系回溯原始记录;匹配不唯一时不强制回填。笔记卡片、查看弹窗、对话内笔记与编辑预览必须复用同一房源信息组件,不得出现字段口径不一致。
运营能力管理员可合并或拆分房源组、处理同一 wx_id 内的误去重、修正销售身份和异常来源;房源归组不得删除任何销售关系。
管理能力记录销售采用、修改、联系和成交结果,用于优化排序、话术和置信度。
增长能力编辑中文字、元数据和附件自动保存,支持撤销、重做和草稿恢复。每个账号默认提供 10GB 笔记空间,实时显示已用量、剩余量、百分比和附件占用;超额时禁止继续上传并引导清理。
存储能力服务端通过 PipeLLM 调用 claude-sonnet-4-6 并使用强制 Function Tool Use 获得结构化输出。API Key 仅从服务端环境变量或 macOS 系统钥匙串读取,不得写入 HTML、浏览器存储或房源索引。本地服务由 LaunchAgent 登录自启并保持常驻,异常退出自动拉起;客户侧不出现启动、配置或网关提示。
查询结果必须先按同一销售相同房源去重,再将去重后的全部房源组、全部销售关系和命中词典数据交给模型,禁止 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 和隔离会话,立即追加新一轮客户原话,并在原页面渐进显示需求理解、房源整理和流式客户回复。生成期间锁定重复提交;完成后重新读取服务端完整对话,刷新页面不得丢失新增轮次。只有用户主动进入“批量管理”时才显示卡片选择状态和批量删除操作。
完整索引必须输出 matched、ambiguous、unmatched 三态统计、项目级覆盖率和全部未收录楼盘清单。清单按影响房源组数排序,展示原始楼盘名、别名、房源组、销售关系、原文消息数、首次/最近发布时间和房源示例,并支持搜索与分批加载;歧义项目单独展示候选标准名,供人工补充或判定。
知识运营销售顾问 AI 必须根据客户已经表达的信息,动态判断这次找房希望完成的生活、家庭或资产安排,而不是固定套用需求问卷。客户只给楼盘、预算、面积或户型时,从触发事件、期望进展、阻力与焦虑、决策情境中选择最能改变排序的一项自然深挖;客户已经明确养老、度假、换房、投资等场景时,围绕该场景给条件式建议,不得重复询问用途。客户回复结尾最多提出一个场景深挖问题,再加一个会改变排序的硬条件问题,并说明答案将如何影响房源或看房顺序。方法论名称仅供内部 Prompt 使用,客户侧不得出现“JTBD、Job To Be Done、任务理论、需求框架”等术语;由场景推导的动机只能作为待验证假设,不得写成客户事实。
需求洞察专业接待判断必须由模型基于本轮真实字典命中、房源级校验、楼盘资料、字段冲突和查询理解结果,独立生成“字典与资料作用”。内容分别说明资料参与了名称归一、产品解释、检索扩展、结构化字段补齐或需求验证中的哪些环节;哪些校验通过且唯一一致的内容可作为准确参考;哪些存在多个候选、资料未收录、字段冲突或多个可能值只能作为候选;以及资料帮助发现了哪些原文未直接写出的标准项目、产品结构、参考户型、建筑类型或总楼层数据。隐性需求必须注明来自客户原话与查询理解,楼盘资料只能验证、补充或否定,不能冒充客户动机来源。销售用户可见内容禁止展示英文状态、系统字段、内部房源 ID、null 或代码名,必须转换成自然中文。该判断供销售内部使用,不写入可直接发送给客户的回复。
解释可信度查询理解必须区分客户点名楼盘是硬限制还是初选方案。出现“只看、仅限、不要其他”等明确限制时采用严格范围,只召回点名楼盘;出现“初步设定、可以更改、需要建议、您更专业、不好决定、还有其他建议”等授权顾问判断的表达时,在保留客户点名房源的同时,按地域、租售、预算、户型、入住时间等硬条件从完整真实索引补充候选。销售顾问 AI 必须先评价客户初选,再推荐 1–3 个真实替代方向,结合家庭成员、租期、楼层、电梯、房屋结构、价格与入住条件说明加入比较的原因和代价;不得虚构楼盘、跨区域或把语义偏好误当硬过滤。客户点名基础项目名时,标准分期名称仍归为客户点名范围。
顾问能力客户并列说出多个开发商、楼盘、产品或联系人时,确定性解析必须生成完整目标数组,不得只保留第一个或最长实体。同一维度的并列目标执行 OR 召回,不同维度的租售、预算、面积、户型等条件执行 AND 过滤;例如“求购碧桂园,求购雅居乐,求购绿城”必须同时保留三个品牌并统一限定为售房。意图分析与 HyDE/语义扩展在直接召回之后并行补充别名、项目关系和隐性需求,不得删除、改写或替代客户明确点名的目标。多目标结果按目标生成子Tab,每个目标默认展示10条并独立加载;词典没有标准词条的目标仍按发布原文和房源索引返回。
多目标召回索引载入时根据 message_id 将每条销售证据关联到完整原始记录,不在详情组件临时遍历全量消息。正常查询、原文回退召回和历史对话恢复必须使用同一证据结构;详情展开后完整展示原文及审计元数据,并对当前查询与房源字段进行安全高亮。任一房源或销售关系缺少原始证据都视为发布阻断问题。
证据可信度顶部导航提供独立定价页,会员方案命名统一为基础版、专业版和团队版。会员状态、积分余额、购买记录与积分流水必须和平台用户 UUID 唯一绑定并由服务端持久化,禁止仅保存在浏览器。购买请求必须使用幂等标识,重复提交不得重复生成订单或发放积分;专业版 450 初始积分每个账号只发放一次。基础版计划提供每日 3 次 AI 房源解读、每次最多 10 组结果与 2GB 笔记空间;专业版以 99 元/月早鸟价提供完整结果、20GB 笔记空间、房源追踪、比价走势、AI 笔记与积分包折扣;团队版提供团队积分池、共享笔记、成员权限与团队追踪,具体额度由商务方案确定。当前测试阶段套餐按钮完成站内登记但不发起真实扣款,也暂不执行次数、空间和功能拦截;原始证据回溯是可信度基础,三档均可使用且不得设置为付费限制。接入真实支付后,会员生效与积分入账必须以服务端支付成功回调为准。
商业化历史记录中的任一对话均可建立房源追踪计划。用户从该对话最新一轮的完整房源结果中选择一个或多个楼盘,并设置每小时、每 6 小时、每 12 小时、每天、每 3 天或每周的更新周期。定时检查只比对选中楼盘的报价、销售关系和发布动态;更改楼盘范围时重建基线,不将范围变化误报为房源下架。历史卡片和对话详情必须显示追踪楼盘、更新周期、下次更新时间和未读动态,并支持暂停、继续、立即更新和停止追踪。
追踪能力从历史卡片进入对话后,页面以“对话—详情—追踪”三模式组织,默认打开对话模式并完整展示历史轮次;详情模式恢复当时的房源解读、全部房源、楼盘资料、用户笔记、销售关系、比价、专业判断和追问。桌面端详情模式占满导航以下的剩余视口,左侧楼盘资料与右侧房源结果分别独立滚动,任一侧滚动不得带动另一侧;移动端保持自然纵向浏览。仅已追踪对话显示追踪模式。每次追踪检查必须保存真实报价的更新前价格、更新后价格、变动金额、变动比例和时间;追踪模式使用 ECharts 展示单套房源价格走势、每次更新的整体平均波动、基线与最新房源总数对比、上调/下调次数和平均变动。追踪页提供“价格/百分比”切换并默认进入价格模式。价格模式的房源列表只展示当前参考价,详情只并列展示区间起点与当前参考价,不在卡片、徽标和汇总数据中直接铺开计算价差;价差与涨跌幅应在鼠标悬停曲线节点时按需呈现。整体走势必须使用连续曲线:价格模式绘制同一计价单位房源的平均参考价,百分比模式绘制相对起点的平均涨跌幅;禁止把售价、月租和年租混算。左侧房源列表按完整卡片分页加载,任何视口与缩放比例下都不得从半张卡片处截断或因右栏高度产生空白占位。没有新的真实报价差异时,服务端应基于已有发布轨迹或最新报价生成稳定、可复现的模拟趋势,并在标题、统计、图表和 AI 分析中持续标明“模拟趋势”;模拟值不得计入真实价格变化记录,也不得表述为真实调价、成交价或市场事实。Sonnet 只能基于对应数据口径生成销售分析,禁止编造房东动机、市场背景、心理底价、成交概率或谈判时机,出现越界表达时必须自动重写或回退为确定性数据分析。
追踪决策客户原话输入框、专业回答、全部去重房源列表、模型推荐顺序、内部销售建议和 5 个高置信追问;页头提供“新对话”,当前对话显示可复制 conversation_id,账号菜单的“历史记录”可恢复原对话,但不暴露 Session ID 等运行时技术信息。
顶部不再设置独立“房源列表”入口。销售从房源解读结果中的查看操作进入完整详情,继续核对房源信息、销售关系与原始证据,返回后仍保留当前对话位置。
HomeSeek AI 用户维护的高置信笔记,支持新建、自动保存、富文本、图片、录音和提醒;卡片显示房源、销售、电话和更新时间,页面实时显示默认 10GB 空间用量。
展示项目级归一覆盖率、详细规则匹配数量、字典未收录楼盘和待人工判定项目。未收录清单支持搜索与加载更多,直接用于补充业务词典和检查项目抽取异常。
| 场景 | 产品行为 | 禁止行为 |
|---|---|---|
| 不同 wx_id 发布完全相同房源 | 归入同一房源组,组内分别生成独立 offer,逐行展示发布人、报价和来源 | 顶层重复展示多次,或组内只保留一个联系人 |
| 销售姓名相同但 wx_id 不同 | 可进入同一房源组,但必须保留为两个销售账号和两条关系 | 仅凭姓名、电话或相同文案合并销售身份 |
| 同一 wx_id 多个电话 | 保留电话历史与最近出现来源,标注首选电话 | 覆盖旧电话且不可追溯 |
| 房源长期未更新 | 降低新鲜度得分,提醒重新核验是否在售 | 继续以“当前在售”口吻推荐 |
| 词典未收录或存在冲突 | 原文、BM25、向量和 SQL 检索继续;词义在内部标记为需核实,客户界面不展示系统状态 | 因词典未命中直接返回无结果 |
| 同句存在定金、售价与佣金 | 分别分类金额,只把明确售价写入总价;定金和佣金进入独立字段或保留在原文证据 | 取第一个、最小或最大金额直接作为房源总价 |
| 只有首付、没有总价 | 总价字段显示“-”,原始线索继续可检索;不得参与总价预算筛选 | 把首付金额展示为售价,或因缺少总价删除整条消息 |
| 只有面积与单价 | 保存单价;可推算参考总价并显示“约”,同时记录 derived_unit_price | 把单价直接当总价,或从1.32万中截取32万 |
| 编号长消息中相邻房源字段不完整 | 每个编号项强制切分;价格和属性只能向当前编号项附着 | 让上一编号的项目或户型污染下一编号房源 |
| 短品牌词命中其他项目 | 最长具体别名优先;无法安全映射时保留原项目名和原文 | 因包含“恒大”等短词,把其他项目归入恒大海上帝景 |
| 没有匹配房源 | 明确暂无可靠结果,提供需求澄清和替代产品方向 | 编造房源或联系人 |
| 专业回复超时、鉴权失败或结构化输出无效 | 房源列表、销售关系和来源详情立即且完整可用;后台自动重试,页面仅显示“专业回复正在准备中”等业务状态 | 清空或延迟房源结果,展示模型、网关、服务器、API Key、command 等技术提示,或把固定模板伪装成模型回答 |
| 开始新客户对话 | 立即取消当前 Turn,关闭旧 Session,清空上一客户输入、房源、快照、回复和追问,再创建全新 Session | 把上一客户预算、楼盘偏好、联系人或房源快照带入新对话,或在页面展示技术 Session ID |
| 旧请求延迟返回 | 同时校验 generation、session_id 和 turn_id;不属于当前对话的响应直接废弃 | 让旧客户的 AI 回复覆盖新对话页面 |
| 发布字段与字典冲突 | 保留发布显性字段和较粗项目名称,在内部记录字典候选与冲突原因;允许销售查看来源后人工核验 | 为了匹配字典而覆盖发布原文朝向、面积、户型或擅自确定分期 |
验收不仅看“能不能搜到”,还要验证去重是否正确、销售关系是否完整、回答是否专业、证据是否可追溯以及系统是否真正帮助销售推进客户。
高重复发布不再占满召回结果,原始历史仍完整保留。
房源归组后,不同 wx_id 的销售关系、报价与来源不得丢失。
正式回答中的价格、销售与产品事实均能定位来源。
验收样本中首付、定金、佣金、单价和其他费用不得进入发布总价字段。
编号长消息中项目、面积、户型和价格不得跨编号继承。
938 组房源逐组对比实际抽取片段,确认清洗异常为 0。
1,369 条销售关系均能回到发布人、群聊、时间和原文片段。
37 个对话、39 条回复的列表粘连、分隔线、缩进、追问粘连和技术措辞审计全部通过。
“克拉墅”等关键术语能匹配正确定义、别名和适用产品范围。
每个结构化房源组必须具有 matched、ambiguous 或 unmatched 状态,三态总数与房源组总数严格守恒。
先完成原文、词典、向量/SQL 召回、同人去重和关系展开;专业回复异步回填,不计入房源可用时间。
由业务人员对真实客户问题进行人工评审。
电话格式有效,且能回到最近发布消息或人工笔记。
九项房源信息与负责人、电话、佣金、税费均有真实值;缺失数据统一显示“-”。
销售直接复制或轻度修改后发送给客户。
没有证据的数据不得作为真实房源事实输出。
Sonnet 4.6 必须返回可校验的专业判断、客户回复、推荐 ID 和 5 个追问。
新对话不得继承上一客户的需求、房源快照、模型历史或迟到响应。
人工抽检回复是否完成接住需求、提炼选择、明确主张和推进下一步四个动作。
不得仅凭面积或总价生成性价比、舒适度、适老性和预算用途等营销结论。
需求理解、房源整理、快照确认和专业回复生成阶段均有可见动态状态。
从房源快照冻结到收到首个 Sonnet Markdown 增量,不含前置房源检索时间。
| 用例 | 输入 | 预期结果 |
|---|---|---|
| 默认首屏结果 | 销售首次打开页面 | 输入框默认显示“我要克拉墅的房子”,自动呈现克拉墅词典解释、专业回复、5组房源、组内销售和用户笔记等已有数据,无需销售先点击查询。 |
| 用户自主查询 | 销售在页面输入“我要雅居乐的房子” | 页面直接检索雅居乐相关发布记录、词典和用户笔记并返回结果;若词典未收录,原文检索仍继续。同一 Session 的后续补充可以继承雅居乐这一目标,明确输入新楼盘时则切换到新目标。 |
| 并列品牌完整召回 | “求购碧桂园,求购雅居乐,求购绿城” | 查询计划同时保留碧桂园、雅居乐、绿城三个目标,并只返回售房;同维度三品牌执行OR,不得只查询第一个品牌。当前基线分别召回82、483、23组,共588组;结果区生成碧桂园、雅居乐、绿城三个子Tab,每个Tab默认展示10条并独立加载。雅居乐短名称映射到雅居乐清水湾,绿城即使没有词典标准词条也继续返回真实房源记录。 |
| 词典定位与模糊需求接待 | “我要克拉墅的房子” | 先从词典确认克拉墅是产品类型而非单一小区,扩展对应组团与面积段,再给出房源列表、建议、风险和追问。 |
| 词典缺失不阻断检索 | 查询中包含未收录的销售俗称,原文存在直接命中 | 仍返回原文/BM25 和向量召回结果,标注该术语尚未获得可信词典释义。 |
| 同人重复发布 | 同一 wx_id 连续多次发布同一房源 | 召回只出现一条规范记录;详情可展开全部历史消息。 |
| 多人发布相同内容 | 多个 wx_id 发布相同房号、价格或整段文案 | 顶层只出现一个房源组;组内列出所有 wx_id、联系人、发布群和发布时间。 |
| 朗月湾多个报价 | 朗月湾102㎡由不同 wx_id 发布458万、468万、470万 | 每个报价分别绑定对应销售、群聊和时间;可在同一产品召回组中比较,但不得把不同销售报价解释成同一业主的连续调价,也不得仅因项目和面积相同就断言是同一套。 |
| 山海间两房完整召回 | “山海间两房” | 返回多组真实挂牌线索,不得只出现单条示例;面积、期数、价格和发布销售分别保留。 |
| 同房多销售归组 | “山海间二期87㎡两房” | 返回95万房源组,焦洁与赵雷两位发布销售同时位于该组下,可分别查看电话、用户标识、发布群和时间。 |
| 定金、售价、佣金语义 | “星海传说T1欧式独栋别墅,20万定金,仅售440万,含10万佣金” | 房源总价必须为440万;20万进入定金语义,10万进入佣金语义,二者都不得参与总价筛选或历史价格。 |
| 首付不得冒充总价 | “首付22万起,约103–112㎡蔚蓝星宸3期” | 保留蔚蓝星宸原始发布线索和面积信息,总价显示“-”;查询“300万以内”时不得把该线索作为22万售房返回。 |
| 小数单价边界 | “海岸一号,169平,单价1.32万” | 项目保持为海岸一号;单价为1.32万/㎡,参考总价显示“约223.08万”;不得出现32万,不得归到恒大海上帝景。 |
| 单价推算超过预算 | “万绿园壹号,324平,单价1.47万” | 项目保持为万绿园壹号;参考总价显示“约476.28万”,不得出现47万,也不得进入300万以内结果。 |
| 编号房源强制切分 | 第17项景业三号649万,紧接第18项云海帆歌三期泰式B户型880万 | 生成两个独立房源候选;云海帆歌保留880万和自身户型知识,不得继承景业的649万、5房7卫等字段。 |
| 云海帆歌两房跨项目保护 | “我要云海帆歌两房的房源” | 没有真实挂牌时如实显示无结果;不得把云海泽月一期86㎡两房3.3万/年或任何“30万/年”组合到云海帆歌名下。 |
| 云海泽月租房正确归属 | “我要云海泽月两房的房源” | 云海泽月一期86㎡两房3.3万/年必须归入云海泽月,并绑定对应发布人和原文片段。 |
| 需求消息排除 | 原文为“求购、求租、谁有房源推荐”且没有明确发布房源 | 消息仍可在原始记录中追溯,但不得进入供应房源列表、报价统计或模型的挂牌快照。 |
| 配套词不得冒充项目 | 石梅半岛价目表中出现“果岭公园”等配套词 | 石梅半岛64㎡95万保持原项目和原价格,不得变成果岭64㎡300万或新建果岭房源。 |
| 原文对齐全量审计 | 运行 2026.07.18-source-alignment-v14 全量构建 | 38,776 条唯一消息形成 938 组房源和 1,369 条销售关系;确认清洗异常为0,销售证据断裂为0。 |
| 错误低价扫描 | 重建完整索引后扫描20万、22万、32万、47万售房结果 | 上述四个由定金、首付或小数单价误拆产生的错误报价数量为0;若存在真实同价房源,必须有独立原文总价证据且不属于本组异常样本。 |
| 去重后全量完整性 | 查询返回 N 组去重房源与 M 条销售关系 | 模型请求必须包含全部 N 组房源和全部 M 条销售关系,页面同时展示全部 N 组结果;推荐 ID 仅用于调整顺序,不得隐藏、删除或截断其余数据。 |
| 渐进检索状态 | 输入“山海间两房”等多结果查询 | 页面依次显示六个检索阶段,房源组按稳定批次逐步出现;去重归组完成后才进入专业回复 Loading。最终回复、推荐、建议和追问使用同一个 retrieval_snapshot_id 一次性回填。 |
| 纯场景洞察无锚点 | “家里有老人长期住,不喜欢潮湿,也不想天天上下楼” | 查询理解 AI 可以识别老人常住、电梯、防潮、减少爬楼等隐性需求;真实词典未收录时不得伪造词条,没有楼盘、预算、面积或户型锚点时不扩大房源结果,最终回复应追问关键条件。 |
| 有锚点的语义重排 | “我要克拉墅,家里老人长期住,不喜欢地下室” | 仍完整保留5组克拉墅和全部20位负责人;程序结合真实词典与知识增强字段,将102㎡纯地上两层的朗月湾排在前面,带地下空间的房源仍保留但降序。 |
| 新查询取消旧请求 | 上一轮正在生成专业回复时修改输入并再次提交 | 立即终止上一轮前端请求并废弃旧快照,开始新一轮渐进检索;旧回复不得覆盖新查询结果。 |
| 同 Session 连续追问 | 先输入“我要克拉墅的房子”,再输入“300万以内,不要地下室” | 第二轮只读取当前 Session 已完成历史,继承克拉墅目标并结合新预算与结构偏好重新检索、冻结新快照和生成回复。 |
| 新对话隔离 | 完成克拉墅咨询后点击“新对话”,再输入“预算200万” | 页面已清空旧结果;新 Session 不得推断客户仍要克拉墅,不得引用上一客户的预算、偏好、联系人、房源或回复。 |
| 旧响应不得回填 | 上一 Session 的专业回复仍在 Loading 时点击“新对话” | 旧请求被取消;即使服务端稍后完成,也因 Session 或 Turn 已失效而被拒绝,不能覆盖新对话。 |
| 新增词典名称归一 | 分别查询“景业清水湾三期”“智汇城云尚A区”“恒大·海上帝景”“云海听歌” | 程序分别映射并召回景业清水湾三号三期、云尚智汇城A区、恒大海上帝景和云海听歌相关真实房源记录;字典目录可向查询理解 AI 提供标准词与项目关系。 |
| 字典补齐与冲突保护 | 发布原文只写项目、面积和户型,或发布原文朝向与同面积字典规则冲突 | 唯一一致规则可以补齐标准项目/分期和参考结构;冲突时发布字段优先,项目保持未确认分期,并在 knowledgeReference.conflicts 中记录差异,客户回复不得把冲突候选写成确定事实。 |
| 全量字典校验与未收录清单 | 重建完整房源索引后打开“字典校验”Tab | 所有房源组均具有字典校验状态;已收录项目使用标准名称,未收录项目完整进入可搜索列表,歧义项目保留原名并显示候选标准名。matched、ambiguous、unmatched 三态总数必须等于全部房源组。 |
| 结构化房源证据 | 打开任意房源组详情 | 展示九项房源信息、需求匹配度,以及组内每位销售的负责人、手机号、佣金、税费、来源群和时间;wx_id 默认隐藏、点击可见。展开每位销售的原始发布内容后,完整原文、message_id、来源文件、群聊和时间可见,当前房源的楼盘、面积、户型、报价与联系方式使用黑底白字高亮。 |
| 硬条件筛选 | “300万以内,不要地下室” | SQL 硬过滤优先;若无匹配则如实说明并给替代方案。 |
| 非模板模型回答 | 连续输入“我要克拉墅的房子”“山海间两房”“300万以内,不要地下室” | 三次回答均由 Sonnet 4.6 根据各自召回证据和人物设定生成,内容、推荐顺序和追问随上下文变化;代码中不存在按房源数量拼接客户话术的固定模板。 |
| 产品名下的真实用途挖掘 | “我要克拉墅的房子” | 先结合真实词典与房源证据给选择,再自然确认客户主要用于长期居住、父母养老或家庭度假等哪一种真实场景,并最多补问一个会改变排序的硬条件;客户回复不得出现 JTBD 方法论术语。 |
| 已明确养老场景不重复盘问 | “找300万以内、适合老人常住的房子” | 不得再次询问“买来做什么”;应直接围绕老人实际居住安排、楼梯/电梯、地下空间或最不能接受的问题选择一个高信息量缺口,并说明该答案如何改变房源排序。 |
| 户型条件背后的使用任务 | “我要云海帆歌四房” | 在完整召回四房及 3+1 等等价户型后,销售回复可确认四房是家庭人口长期使用、偶尔接待还是改善换房需要;不得把任一可能原因直接写成客户事实。 |
| 内部任务判断与事实边界 | 客户只提供楼盘或价格条件 | 专业接待判断明确区分“客户已明确的任务、合理但未确认的任务假设、最值得验证的信息缺口”;投资场景不得承诺收益、升值或流动性。 |
| 字典作用与准确参考 | “我要克拉墅的房子” | 专业接待判断新增“字典与资料作用”,说明克拉墅如何被识别为产品类型并关联四个标准组团;matched 的标准名称可作为准确参考,标准户型只能用于产品解释,不能自动覆盖当前挂牌现状。 |
| 隐性需求来源边界 | “找300万以内、适合老人常住的房子” | 模型说明老人常住等隐性需求来自客户原话和查询理解;字典只负责用楼层、建筑类型、产品结构等真实资料验证或补充排序方向,不得宣称字典推断了客户健康、家庭关系或购买动机。 |
| 字典缺失与冲突 | 结果包含 ambiguous、unmatched 或 knowledgeReference.conflicts | “字典与资料作用”必须如实说明没有获得准确参考或存在冲突,列为候选/核验项,不得把多个可能朝向、户型或楼层任选其一写成房源事实。 |
| 开放式专业推荐 | “清水湾租房、俩室,宝妈带1.5岁宝宝和老人,住6–7个月;初选蔚蓝星语、云海泽月、云海听歌,也可以更改,希望获得专业建议” | 保留三个点名项目的全部真实两房租赁线索,同时在清水湾范围内补充满足租房与两房硬条件的真实替代项目;回复先评价初选,再解释 1–3 个替代方向为何值得比较,并结合家庭成员、租期和试住方案给出核房顺序。 |
| 严格指定楼盘 | 在上一条需求后补充“只看这三个小区,不要其他” | 不得扩大到其他项目;仍完整保留三个点名项目中的全部去重房源组和销售关系。标准名称“云海泽月一期”必须继续识别为客户点名的“云海泽月”,不能当成替代项目。 |
| 扩展推荐硬条件守恒 | 开放建议场景包含清水湾、租房、两房和预算等明确条件 | 所有新增候选必须满足可程序校验的地域、租售、户型和预算条件;AI 可对楼层、电梯、结构等软偏好重排并建议核实,但不得为了增加选择混入售房、跨区域房源或不满足户型的记录。 |
| 专业销售角色 | “我要克拉墅的房子” | 第一句话直接接住需求;自然解释克拉墅的产品含义;提炼2–4个选择方向并给出一个优先判断;结尾只询问一到两个关键条件,并说明将执行核房或看房排序动作。不得出现“根据查询、目前匹配、为了更精准、如有需要”等客服腔。 |
| Markdown 全量回归 | 审计全部历史客户回复 | 37个对话、39条回复中,正文与项目列表粘连、分隔线粘连、非法分隔线、有序列表粘连、子列表缩进、步骤与追问粘连、技术措辞七类问题均为0。 |
| 销售判断事实边界 | 两套云海帆歌两房分别为80㎡168万与88㎡178万,其他居住信息缺失 | 可以客观比较面积差8㎡、总价差10万并建议核实楼层、朝向和实际格局;不得写“80㎡活动空间偏小、88㎡住起来更宽松、168万性价比更高或预算还能做软装”。 |
| 连续 Loading 状态 | 提交任意非默认查询并等待检索与模型回复 | 需求理解、房源整理和快照确认阶段显示14px黑色行内旋转器;专业回复阶段显示Loading卡片;首个Markdown文字到达后自动切换为流式正文。所有状态均自动结束且无技术报错文案。 |
| 专业回复服务失败 | 断开上游生成能力或配置无效凭据后发起查询 | 房源列表、销售关系和来源详情仍先完整显示;页面不出现模型、网关、密钥、服务器或启动脚本提示,不生成伪回答。 |
保留导入批次、原始消息、房源归组依据、同人去重记录和人工修正历史。
电话号码和账号身份属于敏感业务数据;按组织、角色和用途控制查看、导出与日志。
房源需要最近核验时间;长期未更新自动降权,不以确定在售口吻输出。
HomeSeek AI 的核心结构是“一组房源,多个销售关系”:相同房源只展示一次,用户进入后可以完整比较所有发布销售;每位销售都能追溯到谁发的、在哪发的、什么时候发的,再由模型把这些证据转化为专业接待和成交决策。
网站版保持本地产品的查询、渐进式房源呈现、Markdown 流式解读、笔记、历史对话、追踪和积分体验,但必须把检索、身份、持久化、文件和定时任务迁入可信服务端。前端交互可以延续,不能把本地单进程的数据边界原样暴露到公网。
全部进入可回溯原始记录索引。
同一房源聚合展示,销售关系独立保留。
每条关系可定位发布人、来源、时间与证据。
规模足以支持首版网站,生产环境应由服务端查询。
当前规模对 PostgreSQL 属于轻量负载,单套生产数据库即可承载。首版不需要为了规模提前引入独立搜索集群;先完成服务端查询、字段索引、权限隔离和可恢复存储,后续数据达到百万级记录或复杂全文检索成为瓶颈时,再评估专用搜索服务。
只接收当前用户有权查看的分页结果,不下载完整数据集。
终止 TLS、同源反向代理、请求大小限制和安全响应头。
认证、检索、字典、对话、积分、笔记和 SSE 流式输出。
保存房源、销售关系、原始证据、用户资产和冻结快照。
承载会话缓存、任务锁、追踪调度、导入与索引更新。
图片进入私有文件存储;AI 请求只由服务端携带密钥发起。
| 当前实现 | 公开网站风险 | 生产改造 | 上线级别 |
|---|---|---|---|
/api/index 返回完整索引 | 浏览器可以下载全部原始记录、联系人和销售关系。 | 改为服务端 POST /api/search,只返回当前查询、当前权限和当前分页所需的数据。 | 上线阻断 |
| JSON 文件 + 进程内 Map | 多进程写入互相覆盖,无法稳定并发、审计和备份。 | 用户、房源、笔记、对话、积分、绑定与追踪迁入 PostgreSQL,写操作使用事务。 | 上线阻断 |
| 浏览器传入用户标识 | 请求头可以被修改,无法证明真实登录身份。 | 手机号验证码或受信身份服务登录;服务端签发 Session,所有资源按 user_id / organization_id 鉴权。 | 上线阻断 |
| 内存 Session | 服务重启后丢失,同一对话无法跨实例继续。 | 对话、轮次和冻结快照写入 PostgreSQL;短期会话状态和流式任务状态写入 Redis。 | P0 |
| Web 进程内定时器 | 多实例会重复执行追踪,单实例重启会漏跑。 | 拆分 Worker,使用持久任务队列、分布式锁、重试和幂等运行 ID。 | P0 |
| Base64 或本机图片 | 数据库和 JSON 快速膨胀,容器重建后文件丢失。 | 头像、封面和笔记图片进入私有对象存储,数据库仅保存对象键、大小、类型、归属和可见范围。 | P0 |
| macOS 钥匙串 | Linux 服务器没有本机钥匙串回退能力。 | 使用部署平台 Secret 或仅服务端可读的环境文件注入 PIPELLM_API_KEY。 | P0 |
users / sessions用户与登录会话平台 UUID 由服务端生成;保存手机号验证状态、昵称、头像、组织和角色。
memberships / point_ledger会员与积分套餐、余额、获得与消耗流水、购买幂等键和支付回调结果。
source_messages原始事实层不可变原文、来源、发布时间、发布身份、导入批次和内容指纹。
listing_groups房源展示组楼盘、租售、面积、房型、价格口径、字典标准名和归组指纹。
listing_offers独立销售关系同一发布人的重复内容在此归一;不同发布人继续保留独立报价和联系人。
listing_evidence房源证据关系连接房源组、销售关系和原始记录,保证每项结果可回溯。
dictionary_entries / rules业务词典标准名称、别名、层级、项目资料、规则版本和人工校验记录。
conversations / turns独立对话每个对话拥有独立 ID 和上下文;禁止跨对话共享模型历史。
retrieval_snapshots冻结查询快照保存本轮完整去重结果、字典命中、笔记引用和检索版本,页面与 AI 共用。
notes / note_assets笔记与附件区分私人、隐藏和共享状态;图片只保存对象存储引用。
trackers / tracking_runs追踪计划与变化保存楼盘范围、周期、基线、每次运行、价格观察和 AI 分析。
audit_logs敏感操作审计记录联系人查看、导出、绑定、笔记分享、套餐和管理员修改。
楼盘、租售、价格、房型、面积、楼层、朝向、联系人和原文。
标准名称、别名、项目层级、产品关系和真实规则补齐。
只提供隐性需求与候选属性,不替代客户明确条件和真实查询。
先向页面返回房源和销售证据;分页只改变呈现范围,不改变本轮完整快照。
模型不可新增快照外房源。上游不可用时,房源检索、字典解释和证据详情仍然可用。
生产环境使用新生成的 PipeLLM Key,并通过云平台 Secret、容器 Secret 或权限为 600 的环境文件注入。任何曾出现在聊天、截图、日志或历史提交中的 Key 均应撤销。
不得使用 VITE_PIPELLM_API_KEY,不得写入 React、HTML、Dockerfile、Nginx 配置、数据库或仓库中的环境文件。日志只能记录请求 ID、模型和耗时,不记录授权头。
# /etc/homeseek/homeseek.env · chmod 600
PIPELLM_API_KEY=replace-with-new-server-secret
HOMESEEK_AI_MODEL=claude-sonnet-4-6
HOMESEEK_AI_GATEWAY_URL=https://api.pipellm.ai/openai/v1/chat/completions
HOMESEEK_AI_TIMEOUT_MS=90000
HOMESEEK_HOST=127.0.0.1
HOMESEEK_PORT=4317
DATABASE_URL=postgresql://homeseek:***@127.0.0.1:5432/homeseek
REDIS_URL=redis://127.0.0.1:6379
OBJECT_STORAGE_BUCKET=homeseek-private
项目根目录必须忽略 *.env、*.env.local、证书、数据库备份、上传文件和运行时数据目录;仓库只提交不含真实账号与密钥的 .env.example。
[Service]
EnvironmentFile=/etc/homeseek/homeseek.env
WorkingDirectory=/var/www/homeseek/outputs
ExecStart=/usr/bin/node HomeSeek-AI-服务.mjs
Restart=always
RestartSec=5
User=homeseek
NoNewPrivileges=true
PrivateTmp=true
location / {
proxy_pass http://127.0.0.1:4317;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off; # 保留 SSE 实时输出
client_max_body_size 16m;
}
生产环境必须配置 HTTPS、可信域名、健康检查和独立 Worker 服务。数据库、Redis 与对象存储不直接暴露公网;应用仅监听内网或 127.0.0.1。
生产导入完成后必须逐项核对有效原始记录、房源组、销售关系、词典条目、用户、笔记、对话、积分流水和追踪记录数量。任何销售关系或原始证据缺失都不得切换生产流量。
手机号属于登录因子而不是可伪造用户 ID。私人笔记只对本人可见;共享笔记、团队数据、联系人和导出能力按角色授权,并记录审计日志。
全站 HTTPS,数据库和对象存储私网访问;手机号按场景脱敏,下载使用短期签名地址;接口配置频率、并发和请求体限制。
PostgreSQL 每日全量备份并保留时间点恢复能力;对象存储开启版本控制;每月至少执行一次隔离环境恢复演练。
监控 API 成功率、P95 延迟、SSE 首字时间、PipeLLM 错误率、队列堆积、追踪漏跑、数据库连接和磁盘容量。
导入批次、追踪运行、积分发放和购买回调都必须携带幂等键;重试不得重复写入、重复加分或重复推送动态。
每轮快照保存索引版本、字典版本、Prompt 版本和模型名称,保证历史对话可以解释当时为什么得到该结果。
| 验收项 | 通过标准 | 失败处理 |
|---|---|---|
| 密钥安全 | 前端资源、接口响应、日志和仓库均不存在真实 API Key。 | 立即撤销密钥、停止发布并清理历史提交。 |
| 完整索引隔离 | 普通用户无法下载全量索引;搜索接口只返回授权范围内的分页结果。 | 视为数据泄露风险,阻断上线。 |
| 用户隔离 | A 用户不能读取、修改或删除 B 用户的私人笔记、对话、积分和追踪。 | 视为 P0 权限缺陷,阻断上线。 |
| 检索一致性 | 核心案例与本地基线的房源组、销售关系和原始证据数量一致。 | 回滚数据版本并重新执行导入校验。 |
| AI 降级 | PipeLLM 超时或不可用时,房源、字典、笔记和证据仍正常返回。 | 禁止用固定模板伪装模型回复。 |
| 会话独立 | 每个 conversation_id 独立保存上下文,服务重启后仍可恢复且不跨对话串联。 | 阻断历史与追踪功能上线。 |
| 追踪幂等 | 同一运行周期只产生一条 tracking_run;多 Worker 不重复执行。 | 暂停调度,修复锁和幂等键后补跑。 |
| 备份恢复 | 能在隔离环境恢复最近备份,并通过核心数量与证据抽样核对。 | 生产数据写入前必须完成恢复演练。 |
内部小范围演示可以用单台服务器承载 React、Node 和只读索引,但必须放在受控访问范围内。面向真实用户公开运营前,服务端分页检索、真实登录鉴权、PostgreSQL 持久化、对象存储和独立追踪 Worker 是必须完成的生产基线。