Decoder 这个项目越往后做，我越觉得：数据产品第一步不是做界面，而是先把“凭什么这么判断”想清楚。
一个英国房产尽调工具，如果只是把地图、邮编、学校、犯罪率和成交价堆在一起，看起来很丰富，但用户真正要的是结论：这个地方值不值得继续看，风险在哪里，证据是什么。
为什么折腾
英国买房信息分散得很厉害。
成交价在一个地方，EPC 在一个地方，学校评级在一个地方，犯罪数据、洪水风险、空气质量、人口结构、交通和生活服务又散在不同来源。普通用户不是没有数据，而是很难把这些数据连成判断。
Decoder 的想法是做一个面向英国房产尽调的数据产品：输入邮编或地址，得到一个多维度判断，而不是一堆孤立链接。
我的公开版环境
公开版可以概括为三层：
- 数据层：收集公开数据源，做清洗、索引和地理关联。
- 评分层：把价格、安全、教育、交通、环境、连接性、生活服务和社区结构做成可解释维度。
- 展示层：先给结论，再给证据，最后给完整明细。
技术上会涉及数据库、地理索引、ETL、API 和前端可视化，但这些都只是手段。核心是让用户知道每个分数从哪里来。
实际怎么做
第一步是把数据资产列出来。
我把数据源按模块拆成几类：房产、犯罪、教育、交通、环境、网络连接、生活服务、邮编和人口统计。每一类都要知道来源、表结构、覆盖范围、更新频率和是否已经索引。
第二步是做数据库审计。
不是“我记得导入过”，而是要确认表是否存在、行数是否合理、有没有重复、有没有空表、有没有索引、和数据清单是否对应。数据产品最怕前端看着像完成了，底层其实缺一块。
第三步是设计评分表。
我更倾向于把复杂计算预处理成服务层表，而不是每次用户搜索都临时拼一堆查询。这样响应更稳定，也更容易调试和解释。
第四步是设计证据抽屉。
用户看到一个安全分、教育分或交通分时，应该能继续展开：这个分来自哪些数据、附近有哪些学校或站点、风险点是什么、为什么不是简单平均。
哪里卡住
第一个坑是数据源完成度不一致。
有些模块已经很完整，比如成交价、EPC、学校和犯罪数据；有些模块还需要继续接入或验证，比如交通、生活服务和实时连接性。不能因为某几个模块完成度高，就假装整个系统已经完整。
第二个坑是评分很容易伪科学。
把所有东西归一化成 0 到 100 分很简单，但解释起来很难。用户真正关心的是这个分数有没有道理，而不是数字看起来整齐。
第三个坑是界面容易抢跑。
地图、卡片、雷达图都很容易做得好看。问题是，如果底层证据链没有打通，界面越漂亮，越容易让人误以为判断已经可靠。
值不值得
值得，但它不是一个“先做漂亮页面再补数据”的项目。
Decoder 更像一个慢项目：先把数据盘清楚，再把评分逻辑写清楚，最后才是让用户用起来舒服。
我现在对它的判断是：真正的产品感不来自地图多炫，而来自用户点开一个结论时，能看到背后有数据、有来源、有解释，也有保留意见。
房产尽调不是替用户做决定，而是把他们原本要查十几个地方的信息，整理成一个可以信任的判断入口。