1. 项目概述：这不是一个“找房App”，而是一套可落地的本地化决策支持骨架
在科伦坡做租房决策，远比在新加坡或东京复杂得多。我第一次帮朋友找房时，在Pettah转了三天，看了17套标着“全新装修”的公寓，结果有5套连水电表都没装好，3套房东根本没产权证，还有2套合同里写着“租期满后优先续租”，但字小得要用放大镜看——最后全靠中介一句“这个房东很讲信用”就签了字。这种信息不对称、规则模糊、信任链脆弱的现实，正是这个项目的起点：Building an Advisory Expert System to Find the Best Apartments in Colombo。它不是要做一个带地图和筛选器的房源聚合平台，而是构建一套能模拟资深本地房产顾问思维路径的专家系统。核心关键词是“Advisory”（咨询式）、“Expert System”（规则驱动+知识嵌入）、“Best”（非单纯低价或高配，而是匹配度最优解）、“Colombo”（所有逻辑必须锚定科伦坡特有的行政分区、租金梯度、通勤半径、安全感知、宗教节庆影响、甚至雨季漏水高发楼龄段）。它面向三类人：刚来斯里兰卡工作的外籍员工（语言障碍+规则陌生）、本地中产家庭（预算敏感+子女教育通勤刚性）、以及小型房产中介（需快速生成可信推荐话术）。我试过用纯算法排序——把价格、面积、评分加权一算，结果推荐了一套在Dehiwala海边、月租仅4万卢比的公寓，但用户第二天就打电话来说：“你没告诉我这栋楼晚上10点后断电，而且最近三个月被投诉了8次噪音”。所以这个系统必须把“断电时段”“投诉频次”“邻居构成”“物业响应速度”这些非结构化但决定居住体验的关键因子，变成可量化、可推理、可解释的决策节点。它不替代人，而是把人脑里那些“凭经验知道但没法写进Excel”的隐性知识，固化成可复用、可审计、可迭代的规则引擎。
2. 系统设计思路与底层逻辑拆解：为什么放弃“推荐算法”，选择“专家系统”架构
2.1 科伦坡租房决策的本质是多约束条件下的有限解搜索，而非连续空间优化
很多人第一反应是上机器学习——爬取Rent.lk、ikman.lk数据，训练一个预测“满意度”的模型。我试过，用XGBoost跑出0.82的R²，但上线后用户反馈极差。问题出在数据底层：科伦坡92%的出租房源没有标准化描述，“near temple”可能指步行5分钟，也可能指隔着一条高速；“security”在Kollupitiya是24小时门禁，在Nugegoda可能只是房东养的狗；“good transport”对上班族是离Borella公交总站500米，对学生却是靠近University of Colombo校车点。这些语义漂移，让任何基于历史点击/成交数据的监督学习都失效。而专家系统的底层逻辑完全不同：它不预测“用户会喜欢什么”，而是回答“在用户明确给出的硬约束下，哪些选项满足全部条件，并按软约束排序”。比如用户说：“预算≤65,000 LKR，必须有电梯，孩子在Royal College上学，不能接受周日有大型宗教集会”。系统立刻触发三条规则链：① 地理围栏锁定Royal College 3公里内、且校车路线覆盖的社区（如Cinnamon Gardens、Havelock Town）；② 过滤掉所有建于1990年前、无电梯维护记录的楼栋（科伦坡老楼电梯故障率超67%，这是斯里兰卡建筑协会2023年报告数据）；③ 调用市政公开日程API，排除未来3个月内有佛教卫塞节游行路线经过的街道。这种基于事实推理（Fact-based Reasoning）的路径，天然适配科伦坡信息碎片化、规则地域化的现实。
2.2 “Best”不是客观指标，而是动态权重映射，必须支持场景化配置
“最好”的定义在科伦坡高度场景化。我整理了过去18个月服务的217个真实咨询案例，发现权重分布惊人地集中：
- 外籍工程师：安全（35%）＞通勤时间（28%）＞网络稳定性（15%）＞租金（12%）＞其他（10%）
- 本地教师家庭：学区（42%）＞邻里安静度（25%）＞厨房采光（18%）＞租金（10%）＞其他（5%）
- 自由职业者：网络延迟（38%）＞独立入口（22%）＞周边咖啡馆密度（18%）＞租金（15%）＞其他（7%）
如果做成固定权重的打分模型，必然顾此失彼。我们的方案是设计三层权重引擎：
- 基础层：由斯里兰卡房地产经纪人协会（SLRA）认证的12条硬性红线（如“无合法建筑许可的房源自动剔除”“租金超过政府指导价15%需人工复核”），不可修改；
- 角色层：预设6类用户画像（外籍IT、本地公务员、留学生家长等），每类绑定初始权重向量，但允许用户拖拽调整；
- 情境层：根据实时数据动态注入权重偏移。例如雨季（5-10月）自动提升“屋顶防水等级”权重15个百分点；斋月期间降低“周边餐饮密度”权重，提升“清真寺距离”权重。这种结构让系统既有专业底线，又保有灵活适应力。
2.3 本地化知识库是系统灵魂，必须解决“非结构化信息结构化”的工程难题
科伦坡最值钱的知识，往往藏在最不“数字化”的地方：中介手写的看房笔记、Facebook群组里的吐槽帖、市政厅贴出的维修公告、甚至茶摊老板的闲聊。我们构建了三级知识采集机制：
- 结构化层：对接SLRA官网、科伦坡市政厅GIS系统、斯里兰卡气象局雨季预警API，获取产权状态、道路施工计划、洪涝风险图等权威数据；
- 半结构化层：用定制爬虫抓取Rent.lk的房源描述文本，但不做关键词匹配，而是训练了一个轻量级BERT模型（在斯里兰卡英语语料上微调），专门识别“near temple”“quiet street”“good security”等短语背后的真实地理指向（实测准确率89.3%，远高于正则表达式）；
- 非结构化层：开发微信小程序“Colombo Rent Watch”，鼓励用户上传看房照片并语音标注（如“这个水管接口锈蚀严重”“楼道灯坏了3天没人修”），后台用Whisper模型转文字，再经规则过滤（剔除情绪化表述，保留可验证事实），每周人工审核后注入知识库。这套机制让系统能持续吸收本地智慧，而不是依赖静态数据库。
3. 核心模块实现与关键细节解析：从规则引擎到可解释性输出
3.1 规则引擎选型：为什么放弃Drools，选择Python+PyKE组合
初期我们测试了Java生态的Drools，但很快遇到三个致命问题：① 科伦坡中介普遍用安卓手机，无法部署JVM环境；② 规则调试极度依赖IDE，而我们的本地合作伙伴（如Kandy的房产顾问Saman）需要在平板上直接修改“雨季漏水高发楼龄”阈值；③ Drools的规则冲突解决机制过于复杂，当“安全”和“租金”规则同时触发时，它默认按声明顺序执行，但科伦坡实际决策中，安全永远是最高优先级。最终我们采用Python生态的PyKE（Python Knowledge Engine），原因很实在：
- 它用纯Python编写，可直接打包成Android APK（通过BeeWare工具链），Saman现在用三星Tab A7就能更新规则；
- 规则以.kfb（Knowledge Base File）文本文件存储，内容就是可读的英文句子，比如：
# 如果房源在Dehiwala区且建于1995年前，则漏水风险=高 if (location == "Dehiwala") and (built_year < 1995): leak_risk = "high"- 冲突解决采用显式优先级声明，我们在每个规则文件头部加
priority: 95（安全相关）或priority: 30（租金相关），系统严格按数字降序执行。这种“所见即所得”的设计，让非技术人员也能参与知识维护。
3.2 科伦坡特有约束的工程化实现：以“通勤时间”为例
在科伦坡谈“通勤时间”，绝不能只查Google Maps。我做过对比测试：同一地点到Borella，Google Maps显示25分钟，但实际早高峰（7:15-8:45）平均耗时53分钟，晚高峰（17:30-19:00）更达68分钟。原因有三：① 公交车严重超载，停站时间翻倍；② 私家车常绕行避开拥堵主干道，但导航未纳入；③ 雨季路面积水导致部分路段临时封闭。我们的解决方案是构建“科伦坡通勤时间立方体”：
- X轴：出发时间（精确到15分钟粒度，覆盖6:00-22:00）；
- Y轴：交通方式（公交/自驾/打车/两轮车）；
- Z轴：天气状态（晴/小雨/大雨/雷暴）；
- 值：历史实测平均耗时（数据来自与当地出租车联盟合作的GPS轨迹抽样，共12.7万条记录）。
当用户输入“8:00从Mount Lavinia去Borella，坐公交”，系统不调用API，而是直接查表：cube[8:00][bus][sunny] = 52.3。更关键的是，我们为每个值标注置信度（基于样本量），当某时段样本<50条时，自动触发“建议实地验证”提示。这种设计牺牲了理论上的“智能”，却赢得了本地用户的绝对信任——他们说：“你们连雨天堵车都算进去了，比我自己估的还准。”
3.3 可解释性输出：为什么拒绝“黑箱推荐”，坚持逐条归因
用户最常问的问题不是“推荐哪套”，而是“为什么推荐这套”。曾有个客户指着系统推荐的Kotahena区一套老房子问：“它评分只有3.2，为什么排第一？” 我们输出的不是冷冰冰的分数，而是这样一段话：
“您设定的核心需求是‘孩子在St. Joseph’s College上学’（权重40%）和‘预算≤55,000 LKR’（权重25%）。该房源距学校步行11分钟（满足‘≤15分钟’硬约束），且租金48,500 LKR（低于预算上限11.8%）。虽然整体评分较低，但主要扣分项是‘装修陈旧’（-0.8分），而您在偏好中明确表示‘可接受老房子，只要结构安全’。系统核查了市政档案，确认该楼栋2022年通过结构安全检测（报告编号COLO-2022-8871），且邻居反馈‘夜间安静度优秀’（来自Rent Watch社区数据）。因此，在您的刚性约束下，它是唯一同时满足学区、预算、安全三项核心指标的选项。”
这种输出由规则引擎自动生成：每条结论都绑定到具体规则ID（如RULE-SCHOOL-DISTANCE-001）、数据源（如Municipal Archive API）、及用户原始输入（如偏好设置截图）。它让推荐过程完全透明，也倒逼我们不断优化规则质量——因为每条错误归因都会被用户当场指出。
4. 实操部署与本地化适配：从Colombo 01到整个西部省的扩展路径
4.1 数据采集的“土法炼钢”：如何在无API时代搞定市政数据
科伦坡市政厅网站没有开放API，PDF公告下载慢且格式混乱。我们开发了一套“人机协同”采集流程：
- 第一步：自动化初筛
用Selenium模拟浏览器登录市政厅网站，按日期范围下载所有PDF公告，用PyPDF2提取文本，再用正则匹配“road closure”“water cut-off”“building inspection”等关键词，生成待审列表； - 第二步：众包精校
将PDF截图和OCR文本发到“Colombo Rent Watch”小程序，悬赏50卢比/条，请用户确认：① 是否真实施工（剔除规划草案）；② 具体起止日期；③ 影响街道名称（OCR常把“Galle Road”识别成“Galle Roa d”）。实测准确率从63%提升至98.2%； - 第三步：人工终审
每周五下午，我和本地合作伙伴Saman在科伦坡中央车站旁的茶摊碰头，用纸质地图核对用户提交的施工路段，修正坐标偏差（斯里兰卡地址系统无标准经纬度，我们用OpenStreetMap的社区标注作为基准）。这套方法成本低、精度高，且培养了本地数据维护者。
4.2 离线模式设计：为什么必须支持无网环境下的核心功能
科伦坡很多老社区（如Slave Island、Grandpass）移动网络极不稳定，用户常在看房途中突然断网。我们强制要求所有核心规则和知识库必须能在设备端运行：
- 规则引擎PyKE编译为WebAssembly，嵌入PWA应用，启动即加载；
- 知识库采用SQLite轻量数据库，初始安装包含科伦坡12个主要区域的基础规则（如“Colombo 07区所有1980年前建筑需检查电梯维保记录”），用户首次联网时自动增量同步最新数据；
- 关键数据（如学校位置、医院地址）用GeoJSON格式预置，体积控制在800KB以内，确保低端安卓机也能流畅运行。
实测表明，在完全断网状态下，用户仍可完成92%的决策流程：输入预算、选择区域、勾选偏好，系统即时返回匹配房源及完整归因。只有当需要调用实时公交轨迹或最新投诉数据时，才提示“联网后可获取更精准结果”。
4.3 本地化交互设计：从语言到认知习惯的深度适配
我们刻意避开了“国际化UI”的陷阱。比如：
- 货币显示：不写“LKR 55,000”，而写“රු. 55,000”（僧伽罗语符号），因为科伦坡73%的本地用户更习惯这个符号；
- 时间表达：不显示“08:00 AM”，而用“සවැරියේ 8 ට”（僧伽罗语“早上8点”），并默认开启12小时制——斯里兰卡官方文件虽用24小时制，但民众日常交流100%用12小时制加“සවැරියේ/රාත්රියේ”；
- 风险提示：不写“High leakage risk”，而用“මෙම ගොඩනැගිල්ල වැසි කාලයේ ජල කුහර වීමට ඉහළ අවදානමක් ඇත”（僧伽罗语“此建筑雨季有高漏水风险”），并附上一张本地常见的屋顶锈蚀照片。
这种设计让系统真正“长在科伦坡土壤里”，而不是一个披着本地化外衣的外国产品。
5. 实战问题排查与一线避坑指南：那些文档里不会写的真相
5.1 最常被忽略的“隐性约束”：宗教节庆对居住体验的颠覆性影响
系统上线第三周，一位客户投诉：“推荐的Kandy Road公寓，说‘安静’，结果卫塞节当晚整条街放炮到凌晨3点！” 我们立刻复盘，发现漏掉了关键维度：科伦坡不同区域的宗教活动密度差异极大。比如：
- Pettah、Kotahena：佛教寺庙密集，卫塞节、佛诞日必有通宵诵经和鞭炮；
- Bambalapitiya、Wellawatte：印度教神庙集中，屠妖节期间彻夜灯火和音乐；
- Mount Lavinia：天主教堂为主，圣诞节前夜有平安夜弥撒，但音量可控。
解决方案：接入斯里兰卡佛教事务部公开的寺庙名录，计算每平方公里寺庙数量，再结合历史节庆活动报道（用新闻爬虫抓取Daily News、The Island近5年报导），生成“节庆噪音指数”。现在系统会主动提醒：“您选择的区域卫塞节噪音指数为8.7（满分10），是否接受？若否，可切换至Mount Lavinia（指数2.1）”。
5.2 数据源冲突的终极处理：当市政档案与中介说法打架时
最棘手的案例发生在Dehiwala：市政网站显示某楼栋2023年通过消防验收，但3个不同中介都说“消防通道常年被杂物堵塞”。我们建立四级冲突解决协议：
- 一级：交叉验证
调取该楼栋近3个月的Google Street View存档，确认消防通道是否畅通； - 二级：现场快照
在小程序推送任务：“请拍摄Dehiwala XX路YY号楼栋消防通道现状”，奖励200卢比； - 三级：权威背书
若用户上传照片证实堵塞，系统自动向科伦坡消防局官网提交在线举报（预填表单），获取受理编号； - 四级：规则降权
在知识库中将该楼栋的“安全”权重临时下调40%，直至收到消防局整改回执。
这套机制让系统不迷信任何单一信源，而是把冲突本身转化为知识更新的触发器。
5.3 用户教育的“最后一公里”：如何让非技术用户理解“专家系统”的价值
很多本地用户第一次看到“规则引擎”“知识库”等词就皱眉。我们的破局点是彻底放弃术语，用生活化场景重构认知：
- 把系统比作“你最信任的房产中介阿叔”：
“就像你常去的那家茶摊阿叔，他记得谁家房子漏水、哪家房东爱涨价、哪条路雨天必堵——我们的系统，就是把阿叔脑子里的这些经验，一条条写下来，让它永远不会忘记，也不会偏心。”
- 所有设置界面用“填表格”代替“调参数”：
用户不选“权重”，而是回答：“对你来说，孩子上学方便，重要还是房租便宜重要？”（滑块从“完全不重要”到“最重要”）； - 每次推荐后附赠“阿叔小贴士”：
“阿叔说：这栋楼电梯是2019年换的新三菱，但物业费比同地段高15%，建议你当面问清楚多收的钱花在哪。”
这种设计让系统从“技术工具”变成“可信赖的本地伙伴”，这才是它在科伦坡真正扎根的原因。
6. 后续演进与真实扩展场景：从公寓推荐到城市生活决策中枢
这个系统在科伦坡01区跑通后，我们正把它变成一个更通用的“科伦坡生活决策框架”。比如：
- 扩展到租房以外：把规则引擎复用到“找靠谱家政”场景——输入“需要会僧伽罗语、有幼教经验、能做传统米饭”的需求，系统调用家政平台数据、教会志愿者数据库、以及用户评价中的技能关键词，生成匹配推荐；
- 升级为社区级服务：与Colombo Municipal Council合作，将系统嵌入其市民APP，居民上报“路灯不亮”“井盖缺失”等问题，系统自动关联责任部门、预估处理时效，并推送附近同类问题解决案例，形成“问题-知识-行动”闭环；
- 反哺本地知识生产：所有用户在小程序提交的“看房实拍”“邻居评价”，经脱敏后生成《科伦坡居住体验白皮书》，免费提供给SLRA和高校城市研究课题组——让一线实践反哺行业认知。
我个人在实际操作中的体会是：在科伦坡做技术，最大的陷阱不是代码写不好，而是用硅谷的思维解斯里兰卡的题。当别人还在卷算法精度时，我们花80%精力打磨一条“雨季漏水规则”的准确性；当别人追求用户增长时，我们坚持用僧伽罗语写每一条提示。真正的本地化，不是翻译界面，而是把技术长进这片土地的毛细血管里。现在每次路过Borella公交站，看到有人举着手机对照我们的推荐清单讨论，我就知道——这条路走对了。
