做园区数字化，为什么我们选了「两套系统」而不是一套大而全

园区数字化 · 实践复盘

这两年帮园区做数字化，常被问一个问题，你们那个平台到底能干嘛。

说真的，这个问题反而不好答。能干的太多了，反而不知道从哪句讲起。后来我换个说法，我们其实做了两套东西，一套管业务，一套管提问，两件事分开跑，配合着用。

先说管业务的这套，叫智慧园区综合管理平台

园区运营每天缠在一起的，无非是人、房、合同、钱。房源分散在 Excel 和微信群里，合同靠人盯着到期日，账单靠财务一笔笔对。我们把这些东西搬到同一个系统里，按楼栋、楼层、房间一层层建结构，房源的报价底价单价统一管，租客的行业标签自动统计。招商线索从公海到成交，客户看板按接触、潜在、意向、成交、流失这么走。合同新签变更续租退租，电子合同线上签。财务那边账单多维度筛，逾期一键催缴，收款通知直接带二维码让租客扫码付。

这套系统的任务就一个，把业务数据规规矩矩地产生出来、管起来。它要稳，因为办业务不能出错。

另一套叫数智安全问数平台，干的事不太一样

它不动上面那套系统的表结构，只在旁边接一个只读的连接，给业务人员开一个能「用大白话提问」的入口。你想知道各楼栋空置多少间，直接打一行字就行，不用找人写 SQL，也不用等排期。

背后的链路我们这么搭的。数据先过 Trino 查询网关，统一连库表和字段。接着建业务数据模型，把「楼宇」「租客」「合同」这些对象，以及空置、到期、应收实收这些口径先定义清楚。然后配 Prompt 规则，再攒一个 FewShot 样例库，把验证过的问法和对应查询一对一对存下来。业务人员打开问数页面，选个场景助手，提问，系统回一份答案，结论放最前，图表跟上，明细和来源摊开让你核对。

我自己的感受是，这套东西贵不在模型多聪明，贵在口径先对齐。空置到底算不算待租面积，到期提醒按合同日还是按账单日，这些事不跟业务方掰扯清楚，模型再强也会答非所问。

为什么非得两套，不合成一个

刚开始我们也纠结，能不能一个系统全包了。后来踩了几个坑就清醒了。业务系统要的是稳和准，每次改动都影响办业务。问数系统要的是快和试错，口径经常调，问法今天加明天改。把这两件节奏不同的事塞一个锅里，要么业务被拖慢，要么问数不敢动。分开之后，底层系统照常办理业务，上面那层随便迭代，互不干扰。

样例库比模型更值钱，这事我们交了学费才懂。同样一个问题，第一次配对了存下来，下次直接复用，后面的人力成本直线掉。口径必须跟业务方一起定，别自己拍脑袋，空置算不算待租面积、到期按合同日还是账单日，这些不掰扯清楚，模型再强也答非所问。验收的时候别只看 demo 漂亮，盯四个事，数据对不对，理解对不对，结果能不能用，后面能不能维护。

写到这得泼盆冷水。我们现在也远没到完美的程度，新接一个业务系统，数据结构和规则又得重新评估一遍，这部分还是手工活。问数平台复用产品能力快，但每个客户的实际关联和算法，得一个个重新核对，偷不了懒。

如果你也在做园区，或者手头有个业务系统，正愁最后一公里的「随口一问」，欢迎聊聊，我们踩过的坑可以省你点时间。