先说结论

我们做问数平台头一年，最怕硬算。算错还能纠，硬算是把没谱的数当谱传。老板问一句上季度有效出租率，系统里没钉过「有效」的定义，运营脑子有一套，财务另有一套。这种时候平台凭着猜给个数，比答不上来还糟，那个数会顺着汇报链一路传，最后谁都以为它对。

所以我们的第一条规矩写得很死，兜底优先于好看。算不出的问题，宁可明说这块查不了，也绝不编一个数。具体靠三道闸，拦坏问法、圈能查的范围、把答不了的原因讲清楚。四件套里结论、图、明细、来源，缺一样就别硬凑成能答。

哪些问题会算不出来

上线跑下来，答不了的集中在四类。

数据没落。业务还记在本子上，系统里根本没这条。比如某栋楼刚签的租约，合同状态是生效，账单表却查不到对应记录。问数平台只读不写，它读不到就是读不到，没法替业务把数补上。

口径没定义。「有效出租率」里「有效」算不算免租期、算不算装修改造中的房间，全公司没统一过。源表都是租赁合同和账单，数本身没错，错在定义只在人脑子里。

自然语言太糊。「最近收了多少」「那几间空着的」里「最近」指哪段、「空着」指空置还是待租，平台拿不准就不该硬答。

源库连不上。只读账号临时挂了，或者接口超时。这时候连实时都谈不上。

第一道闸，拦住坏问法

语义层先校验，问法指纹命不中经验库里的样例，就先问回去，不硬答。我们给每类问法定了可答边界，不在边界内的，进人工确认队列，而不是试着猜。

yaml

degradation: unknown_metric: # 口径没定义 action: reject reply: 该指标尚未在口径中心登记，已转人工确认 log: true missing_data: # 数据没落 action: partial reply: 仅返回已落库部分，并标注缺失范围 ambiguous_question: # 自然语言太糊 action: clarify reply: 请确认时间窗与统计对象 source_down: # 源库连不上 action: cache_fallback reply: 返回最近一次成功快照，标注数据截至时间

这段配置接在语义层后面，命中任一类就走对应分支，不会落到先猜一个再说。

第二道闸，圈定能查的范围

答不了整体，就答能答的子集，并且明说只含哪部分。比如合同有生效却无账单的，我们返回已落库的合同收缴情况，同时把 N 份生效合同暂无账单，未计入写进结论。这样老板看到的数，范围是清楚的，不会误以为全量。

查哪些是生效却没账单的，一句就能拉出来。

sql

SELECT c.contract_no, c.tenant, c.sign_date FROM contract c LEFT JOIN bill b ON b.contract_no = c.contract_no WHERE c.status = '生效' AND b.id IS NULL;

这些就是数据没落的部分，平台和运营都该一眼看见，而不是被平均数盖掉。

第三道闸，把答不了的原因讲清楚

答不了，不能只回一句报错。我们给每类兜底配了原因码，前端把原因和建议去哪儿查一起带出来。用户至少知道，不是系统坏了，是这块数还没准备好。

原因码落一张小表，前端直接映射文案。

sql

CREATE TABLE degrade_reason ( code VARCHAR(20) PRIMARY KEY, label VARCHAR(60), advice VARCHAR(120) ); /* unknown_metric 口径未登记 到指标口径中心补定义 */ /* missing_data 部分数据未落库 核对生效合同与账单 */ /* ambiguous 问法有歧义 确认时间窗与对象 */ /* source_down 源库暂不可用 稍后重试或看快照 */

平台答不了时，返回的不只是一个空结果，还带 code，运营点开就能告诉老板，是哪一类的问题。

源库挂了，降级到快照

只读账号连不上那次，我们没让用户干等。缓存里有一份最近一次成功拉取的物化视图，直接返回，但结论里醒目标数据截至 X 日 X 时，非实时。宁可慢一点、旧一点，也不能静默给一份过时的数还说是现在的。

这里的关键不是技术多花哨，是诚实。降级是临时通道，不是常态，状态栏一直挂着快照模式的提示，直到源库恢复。

踩坑表

回头看

问数平台管的是看懂这一层，它接在智慧园区系统外面，只读不写，不替换也不改造，只加一个问数入口。发生归发生，看懂归看懂，俩不抢活。

兜底这件事，核心就是克制。能答的痛快答，答不了的把话说清楚，比编一个漂亮数负责任得多。少等一次取数，少做一次重复工作，少一次反复解释，这三句一直管用。