同条件比价内核：现状诊断与建设方案

一、定义：什么叫「同条件比价」

核心结论：「同条件比价」不是多做一个页面，而是把「可比集的定义」从地理空间推进到条件空间，并给出一个带不确定性的分位结论。

1.1 边界：什么算「同条件」

现有可比集是「地理层级 × 房型」的二维切分（县市 → 乡镇 → 生活圈 → 社区，乘以雅房／分租套房／独立套房／1–4 房）。同条件比价要求把以下维度同时作为约束：

• 地理：生活圈或社区（最小可比单元）
• 房型与型态：房型 + 建物型态（电梯大楼／公寓／透天）
• 坪数带：按可使用坪数分带，而非全区混算
• 屋龄带：新成屋与 20 年以上老屋必须分开
• 楼层带：顶加、低楼层与高楼层的价格结构不同
• 关键设备与租赁条件：车位、电梯、家具家电、租金内含项目

少任何一个维度，均值就被该维度的分布差异污染——一个生活圈里 15 坪和 35 坪的 3 房混在一起取平均，出来的数对谁都不成立。

1.2 内核四层架构

内核按四层实现（图 1、表 1）：前两层解决「比谁」，第三层解决「差多少」，第四层解决「怎么讲」。

1.3 明确不做的事

为避免范围膨胀，内核不负责：成交价预测、投资回报率估算、跨城比较、以及个体房东的议价博弈策略。它只回答一个问题——这间房，在条件对齐的同仁里，站在什么位置。

二、平台侧现状问题

核心结论：五个问题彼此独立但同源——对比始终没有进入「条件空间」。前两个是能力缺口，后三个是执行与口径问题。

2.1 对比层只做到区域均值

「V1租金行情层级与逻辑」定义的可比集是地理层级 × 房型 × 型态／坪数区间，行情卡片输出平均租金、同比、租金区间（最低~最高）。用户拿到的永远是「这个生活圈 3 房平均 32,000」，而不是「你这间 25 坪、电梯、屋龄 8 年、含车位的 3 房该值多少」。对比层四项已上线能力（挂牌与成交、周边社区、前置三件套、后置三件套）全部建立在同一套区域聚合之上。

2.2 个体差异被做成标签占比

「租金影响因子汇总表」列出 12 个标签，输出形态是「xx% 臨近捷運站」「xx% 有電梯」「xx% 有提供家具」——即同区同类型物件中具备该条件的比例。这是描述性统计，不是价格调整。有因子清单，无因子系数。

2.3 样本阈值线上远低于内部方法论

2.4 C 端已经把病灶逐条说了出来

合计 16 条、总分 78、均分 4.88、低分 10 条（62.5%），与主题聚合值一致。

2.5 用户提的条件维度被系统性婉拒

「建议&反馈优化策略项」里，用户反复要求把条件维度纳入行情，平台的回复高度一致——以样本量不足为由暂缓：

五条里有四条是 8 分的高满意度用户提的——他们不是来抱怨的，是来要功能的，而我们要不了。

三、根本原因

核心结论：五个根因分三层——定义层（1）、技术层（2、3）、数据层（4）、组织层（5）。其中根因 2 是真正的卡点：不是不知道怎么做，是没有解决「条件收紧 → 样本塌方」。

根因 1｜可比集定义在地理空间，没有进入条件空间

现在的可比集是地理层级 × 房型的二维切分。真正的同条件比价需要把坪数、屋龄、楼层、型态、设备、租金内含费用同时作为约束。这不是精度问题，是维度缺失。

根因 2｜没有解决「条件收紧 → 样本塌方」

这是最硬的技术卡点。加一个维度，样本量掉一个数量级。平台目前的应对是降阈值保覆盖（同社区 ≥1 笔就展示），等于用「有数据」换「数据准」。正确解法是两条腿走路：

• 层级回退：同条件样本不足时，按预设顺序逐级放宽到生活圈／乡镇，并在界面明示「已放宽至上一层，参考性下降」。
• 模型补足：用回归／分位回归在较粗粒度上估出因子系数，再回推到目标条件——用模型换样本，而不是用精度换覆盖。

注：图 4 为结构示意，生活圈基数取 100 笔为假设值，衰减比例用于说明形态，非平台实测值；图中两条阈值线（50／20）为真实值。

根因 3｜有标签清单，无因子系数

2026 年 5 月的三轮标签调研（溢价标签分类、行业标签收集、标签验证）产出的是「哪些标签值得展示、措辞如何」，不是「每个标签值多少钱的调整率」。而「V2租金溢价因子」表二第 3 步明确要求：「依各对比项与出租条件的相近程度转换为序位并给予权重」——这一步没做完。所以现在只能展示占比，无法做价格调整。

根因 4｜数据口径四重污染未处理

「V2租金溢价因子」参考 1 已点名四类必须在内核内处理的污染（表 4），每一条都对应 C 端的一条 2 分反馈：

根因 5｜需求被拆成 11 项，各自重复造地基

见第四章。这是组织层面的根因，也是「建一次」这一提法的由来。

四、为什么必须「建一次」

核心结论：11 项需求共用同一块地基，其中 10 项仍「待开始」——不是因为优先级不够（7 项标为「高」），而是因为每一项都要求从零搭一遍可比集逻辑。

4.1 重复建设的代价

• 口径不一致：11 项需求若各自实现，会出现 11 套「同条件」定义，用户在不同页面看到不同结论，进一步加深「数据不准」的印象。
• 修复成本放大：口径错了要改 11 处；内核错了只改 1 处。
• 排期互相阻塞：每个需求都要等数据侧重新出一套可比集，数据团队成为瓶颈，于是全部积压——这正是 10 项「待开始」的真实成因。

4.2 增值服务层做不了，是因为没有内核

迭代计划中「增值服务层」三项——深度数据会员、房东定价助手（付费单次）、一键生成报告——全部标为 ❌。这不是商业判断上的不想做，而是技术上没有内核可依赖。L1–L4 建成后，房东定价助手才有地基。

五、推荐建设方案

核心结论：不要一次性做完四层。先止血、再建主干、最后装系数——每一阶段都有独立可交付的价值。

5.1 输出文案与 UI 的三条铁律

5.2 与现有路线的关系

内核不新增版本分支，它是对现有「对比层」的能力替换：V2.0 前置行情页的「影响因子权重榜」、V2.1 后置物件页的「价格雷达／性价比分」，在内核建成后应改为调用 L4 输出，而不是各自维护一套近似计算。这样版本路线（V3.0 捷运、V3.1 地图、V3.2 PC）可以直接复用内核，无需重复适配。

六、验收指标与风险

6.1 三个必须提前管理的风险

• 覆盖率骤降的阵痛。阈值回补与「不足 8 笔不报价」会导致可展示行情的物件占比短期下降。这是正确的代价，但需提前与运营对齐，避免被误读为功能倒退。建议同步上线「参考上级区域」的兜底文案。
• 因子系数被误读为承诺价。L3 输出的是统计意义上的调整率，不是估价承诺。前台文案必须避免「本房价值 XXX 元」式表述，统一用「同条件物件中位租金」。
• B 端定价牵动商业敏感。B 端 AI 建议租金直接影响房东定价与平台营收预期，建议先在内部与部分仲介灰度验证，再全量开放。

附录 · 数据来源与口径

本报告为专题诊断，与《租屋行情渗透率诊断与运营建议》互为补充：前者讲「多少人用、为什么掉」，本报告讲「用的人拿到的数准不准、为什么不准」。