这里有小强：UGC 居住虫害地图

> 建档日期：2026-10-19　|　状态：灵感记录 / 未立项

一句话：一个由用户自己标记"我家/这栋楼有小强"的 UGC 地图产品，聚合后给租房、买房、出差长住的人做参考。

---

一、需求从哪里来

来自一次真实的退租事件：天津滨海新区一套公寓，看房时肉眼看不到小强，入住两个月后租客以"屋里到处是小强、楼道也能看到"为由解约，房屋重新挂牌并降价 150 元/月。

这个事件暴露了三个信息缺口：

• 看房时看不到，不等于没有 —— 小强昼伏夜出，白天看房信息量极低。
• 现有平台不提供虫害信息 —— 贝壳、链家、安居客、自如的房源页都没有"虫害/消杀记录"字段。
• 投诉信息是碎片化的 —— 黑猫投诉、大众点评、小红书、12345 各说各话，无法按小区聚合比较。

核心洞察：租房/买房决策中，"有没有虫害"是一个高频、高痛、零供给的信息维度。

---

二、市面竞品核查（截至 2026-10）

结论：中国市场目前没有成熟的"地址级、可查询、UGC 驱动"的居住虫害地图。这是一个真实空白。

但要注意："没有竞品"往往意味着"需求没被验证"或"模式有硬伤"，需要同时看风险（见第七节）。

---

三、产品形态

3.1 最小可用形态（MVP）

一个微信小程序，三个页面：

• 地图页：按小区/楼栋聚合的标记点，颜色分级（绿/黄/红），点击看最近报告。
• 上报页：选择位置 → 选择虫害类型 → 选择严重程度 → 可选上传照片 → 提交。
• 查询页：输入小区名，看该小区近 90 天的报告数量与趋势。

3.2 用户流程

租房前 → 打开小程序 → 搜小区名 → 看报告数与最近时间
       → 有红色标记 → 看房时重点检查 → 决定租/不租
入住后 → 发现小强 → 匿名上报 → 帮助下一个租客

3.3 关键设计原则

• 只做"有无 + 严重程度"，不做"鉴定"：用户不需要分辨德国小蠊还是美洲大蠊。
• 按楼栋而非按户：保护隐私，也符合虫害的楼栋扩散特性。
• 时间衰减：报告 180 天后权重下降，避免三年前的记录永久影响小区。
• 双向价值：租客查风险，业主/物业可认领并公示消杀记录（这是商业化入口）。

---

四、冷启动

4.1 最先切的人群

4.2 最先切的城市与小区

• 选 1–2 个公寓密集、租客流动率高的城市（天津滨海、北京昌平/通州、深圳龙华等）。
• 选 10–20 个高密度小区做种子，靠本地租房群、小红书笔记、豆瓣租房小组冷启动。
• 每个种子小区找 3–5 个"种子用户"，保证首批数据不是空的。

4.3 冷启动的核心难题

地图产品没有数据就没人用，没人用就没有数据。 可行解法：

• 先用公开投诉数据（黑猫、12345 公开回复、点评）做冷启动底图，标注"来源：公开投诉"，与 UGC 区分。
• 用内容引流：做"XX 市小强最严重的 20 个小区"榜单，在小红书/公众号传播，再导流到上报页。
• 与消杀公司合作，用他们的工单数据补充底图（需解决数据授权）。

---

五、数据质量与治理

这是这类产品生死攸关的部分。

产品文案必须始终是"有 N 位用户报告"，而不是"这个小区有小强"。

---

六、商业化路径

• B 端认证：物业/公寓方付费认领小区页，公示消杀记录，获得"已治理"标识。
• 消杀服务导流：按线索收费或抽佣。
• 租房平台合作：把虫害报告作为房源标签卖给平台（难度大，但价值最高）。
• 数据报告：面向研究机构、保险、物业公司的城市虫害报告。

> 注意：B 端付费认领与 UGC 中立性存在天然冲突，必须把"付费"和"删负面"严格隔离，否则产品信任一次性崩塌。

---

七、主要风险

---

八、MVP 与验证指标

8.1 最小验证（不写代码也能做）

先做一个公众号/小红书账号 + 问卷，验证两件事：

• 有多少人愿意查询"小区虫害"信息？
• 有多少人愿意匿名上报自己家的情况？

如果 2 周内收集不到 200 条有效上报，说明供给端动力不足，应重新设计激励。

8.2 关键指标

> 口径细节见第十一章：文案写"位用户"，聚合就必须按设备去重，不能按条数。

---

九、下一步

• 用问卷/小红书做 2 周需求验证
• 抓取公开投诉数据，做 1 个城市的"小区虫害报告密度"底图
• 找 1 家本地消杀公司聊数据合作
• 评估法律风险（名誉权、个人信息保护法）
• 决定是否值得投入开发

---

十、小程序落地方案补充（2026-10-19 讨论）

10.1 结论

• 载体合适：这是"低频、高决策权重"的需求，用户不会为此装 App，但会在看房现场打开微信；小程序还能被"XX 小区 虫害"这类搜索命中。
• 但地图不该是首屏：冷启动阶段大部分小区是 0 报告，地图打开全是空白，等于向用户证明"这产品没人用"。
• 真正的门槛是审核与法律，不是技术：地图数据本身是采购问题，UGC 负面信息才是风险源。

10.2 形态修正

页面清单：

• 首页：搜索 + 城市榜单
• 小区详情：报告数、最近时间、类型分布、趋势、数据来源标注、"我要纠错"
• 上报：定位 → 虫害类型 → 严重程度 →（可选）照片 → 提交，控制在 3 步内，不强制拍照
• 地图（二级）：区 / 街道聚合视图，不做楼栋点位

10.3 技术方案

必须做的技术约束：

• 位置授权失败时提供"手动搜索小区名"兜底，否则上报转化率会掉一半
• 上报校验：与小区 POI 距离 < 500m 才允许提交
• 防刷：手机号验证 + 设备频控（同设备同小区 30 天一次）
• UGC 内容安全接口 msgSecCheck / mediaCheckAsync 必须接入，否则基本过不了审
• Marker 按当前视野拉取并聚合，小区数量上千后直接铺点会卡顿

主体与类目：建议企业主体，个人主体在类目和 UGC 审核上受限明显。

10.4 地图数据从哪来

需要的其实是三类数据，只有最后一类属于自己：

1. 底图

用腾讯位置服务（小程序 <map> 默认）或高德 SDK。测绘资质、审图号由服务商持有，开发者只是调用方。不要自己切瓦片、做底图——那会触碰《地图管理条例》，需要测绘资质。

2. 空间底数（小区 / 楼栋）

• 腾讯 /ws/place/v1/search、高德 /v3/place/text，用"住宅小区"类目 + 城市限定，可拿到小区名、地址、坐标。
• AOI（小区边界多边形）各家开放程度不同，需向服务商确认是否可获取、是否允许缓存。
• 服务条款普遍禁止大规模缓存、复制、转售 POI 数据：小规模验证可以，正式运营必须走企业授权（高德 / 腾讯企业版，或极海、四维图新等数据商）。
• 行政区划用民政部区划代码 + 高德 / 腾讯 district 接口。
• 楼栋坐标没有权威公开数据，不要硬做：用"小区 POI + 楼栋号文本"即可满足按楼栋聚合的需求，同时规避隐私问题。

3. 业务数据（真正的壁垒）

• 用户上报时 wx.getLocation → 逆地理 → 落到具体 POI，以 POI ID 作主键，天然与地图对齐，无需自建坐标体系。
• 冷启动：黑猫、12345 公开回复、点评 → 抽取小区名 → geocode → 标注"来源：公开投诉"。
• 消杀公司工单：最有价值的差异化数据，但必须签授权。
• 疾控 / 爱卫办的病媒生物密度监测（按街道）：可尝试合作申请，是被忽略的 B 端数据源。

明确不做：

• 抓贝壳 / 链家的小区库（违反协议 + 不正当竞争风险）
• 把地图 POI 批量爬下来建库（违反服务条款）

10.5 法律与合规清单

• 名誉权（《民法典》）与商业诋毁（《反不正当竞争法》）：地址级负面信息是核心风险，若指向物业 / 房东的经营行为，风险叠加。
• 平台避风港的前提是"通知—删除"，因此申诉下架通道不是可选功能，是必需功能。
• 位置属于敏感个人信息（《个人信息保护法》）：需单独同意，且最小化——只存到楼栋，绝不存门牌号。
• 文案规范：始终使用"有 N 位用户报告"，禁止出现"该小区有虫害"这类结论句。
• 证据链：上报记录（含时间、定位、设备）需留存，以应对潜在纠纷。

补充：微信对"可能损害他人商誉的地址级负面内容"审核趋严，UGC 叠加地图时被驳回的概率不低。这也是建议先做"搜索 + 榜单"、弱化地图的原因之一。

10.6 修正后的落地顺序

• 问卷 + 小红书验证供给意愿（原第八节方案不变，不要跳过）
• v1 不做地图：搜索 + 小区详情 + 上报，先跑通闭环
• 等"90 天内 ≥3 条报告"的小区积累到一定规模（数百个量级），再开放地图
• 地图只做区 / 街道热力 + 小区点，永不做楼栋点位

---

十一、报告数据模型与聚合口径（2026-10-19 讨论）

11.1 总原则：事实层与判断层分开

• 事实层（report）：用户提交的原始记录，只增不改、永久留存。
• 判断层（poi_stat_daily）：按天预聚合的统计，随时可重算。

同类产品常犯的错误是把"报告数""风险等级""是否安全"塞进同一张表的同一个字段，结果口径一改就要回刷历史、阈值一调就无法重算。分层之后，阈值随便调，历史数据不动。

11.2 事实层表结构

report (
  id             bigint pk
  poi_id         bigint          -- 自有 POI 主键
  building_text  varchar(32)     -- 用户原样输入
  building_norm  varchar(16)     -- 归一化：1栋/1号楼/1#/A座 → 1
  location_type  tinyint         -- 1室内 2楼道 3公区 4垃圾房
  pest_type      tinyint         -- 1蟑螂 2鼠 3蚊 4臭虫 5蚁 6白蚁 9不确定
  severity       tinyint         -- 1偶见单只 2多次看到 3成群或已请消杀
  observed_at    datetime        -- 目击时间（用户填）
  created_at     datetime        -- 提交时间（系统写）
  evidence       json            -- 照片 URL 数组，可为空
  geo_lng        decimal(10,7)   -- gcj02
  geo_lat        decimal(10,7)
  geo_dist       int             -- 与 POI 中心距离（米），写入时计算
  witness_type   tinyint         -- 1亲见 2合作方工单 3公开投诉
  device_hash    char(32)
  phone_hash     char(32)
  status         tinyint         -- 0待审 1可见 2隐藏 3驳回
  weight         decimal(3,2)    -- 反作弊权重，默认 1.00
)

11.3 字段决策理由

• observed_at 必须与 created_at 分离：用户常是周五看到、周一才上报，只存提交时间会让时间衰减算错。约束为不晚于当前时间、不早于 180 天；超出范围的直接拒绝而非静默截断——静默截断会让数据污染永远查不出来。
• building_norm 用代码归一化：去掉"栋 / 号楼 / 幢 / # / 座 / 单元"，全角转半角，字母大写；归一化失败保留原文并标记待抽检。不做模糊匹配，否则 1 栋和 11 栋会被合并。
• location_type 是表里最有分析价值的字段：虫害扩散路径是垃圾房 → 楼道 → 室内，该字段支撑未来的"风险传导"分析，且比"户"安全得多。
• severity 三档必须给文字定义：UI 上就是三句话，不给用户看"3 分"。
• evidence 不强制：强制拍照会让上报转化率腰斩，而照片对聚合的边际价值很低；其真正用途是申诉举证。
• 不存用户 ID 明文：仅有 phone_hash、device_hash，既满足防刷，也在被要求提供用户信息时天然无法提供。

11.4 隐私边界：到楼栋，不到户

楼栋必须记，因为虫害沿竖向管道与烟道扩散，楼栋是最小有意义单元。但楼栋号 + 精确时间在一梯两户的老小区可反推到具体住户。两条硬规则：

• 单楼栋有效报告 < 2 位用户时不展示楼栋维度，只展示小区级。
• 展示时间粒度只到月（"2026-09"），精确日期仅后台用于风控。

第 1 条看似损失信息量，实际是在保护最先上报的那批人——而那批人正是最需要的种子用户。

11.5 聚合口径：三件事必须定死

（1）按设备算，不按条数算

文案写的是"有 N 位用户报告"，只要用"位"，聚合就必须按 device_hash 去重，否则是会被用户当场拆穿的谎。规则：同设备 + 同 POI + 同虫种 + 30 天内 = 1 条。

（2）窗口与衰减

衰减的只是风险等级，不是历史记录。180 天前的报告仍永久可查、仍显示"最近一次报告：2026-03"。

（3）阈值 3 的统计依据

设单条报告为真的概率 p，n 条独立报告中至少一条为真的概率为 1-(1-p)^n：

p=0.6、n=3 时约 94%，即"3 条"的来源。两个陷阱：

• p=0.6 是假设值，必须在验证期用 50–100 条人工回访校准（只问一个问题："你当时确实看到了吗？"）。校准后的真实 p 才是阈值依据。
• 独立性会被刷单破坏：3 条来自同一设备等价于 1 条。因此严格表述是"3 个不同设备"，不是"3 条报告"。

11.6 展示规则

两个刻意设计：

• 1–2 条不给颜色：给绿色是撒谎（样本不足），给黄色是冤枉（可能是一条误报），只给中性文字。
• "无报告"必须区分三种语义：用户看到灰色会默认理解成"安全"，三种情况的文案必须不同，第三种要明确写出上次报告时间。

11.7 状态机与申诉

提交 → pending（待审）
      → visible（可见）
      → hidden（被申诉 / 风控隐藏）
      → rejected（复核确认不实）

• 申诉入口常驻小区详情页，不藏在设置里——这是"通知—删除"义务的一部分。
• 申诉触发 hidden，永不物理删除报告，它是唯一的举证材料。
• rejected 不进任何前台统计，但保留在库中，且该设备 weight 永久降至 0.3。

11.8 反作弊：MVP 用规则即可

关键原则：降权，不删除。降权报告仍可见（可申诉），但不影响风险等级——既防刷，又不误杀真实用户，还保留证据链。

11.9 证据链与数据保留

每条报告需能证明"这是用户说的，不是平台认定的"：

• 提交时间、IP hash、设备 hash、定位坐标、提交时的 geo_dist
• 用户勾选的协议版本号（协议文本需版本化留档，改一版存一版）
• 照片原始文件哈希

上传时必须剥离照片 EXIF：用户在卧室拍的照片带精确 GPS 与拍摄时间，不剥离等于直接泄露住户位置。

11.10 一个反直觉建议：不做评分

不要给小区打 0–100 分的"虫害指数"。

• 分数诱发刷分与压分，且比报告数更容易被操纵。
• 分数掩盖样本量——3 条和 30 条可能都是 65 分，含义完全不同。
• 法律上，"65 分"更接近事实认定，"有 5 位用户报告"更接近事实陈述，后者才是避风港。

只展示三样：报告数、最近一次时间、虫种分布，三者都是可证伪的陈述。

11.11 待验证

• p=0.6 的假设需用真实回访数据校准，阈值 3 可能上调为 4。
• "1–2 条不给颜色"是否真的可被用户接受，需原型验证（口径光看文字判断不了）。
• 单楼栋 < 2 位用户不展示楼栋，需评估是否导致上报意愿下降。

---

十二、关联文档

• 小强风险与居住环境避坑指南
• 中惠熙元广场投资回报率全景分析