第447章 服务目录里的价格闸门（2/2）

分层抽检结果同步（A/B/C分类与证据链字段齐全度）

风险提示推送（仅提示，不给口径结论）

验收方式：对接成功率、数据一致性校验、日志留痕

D类：审计留痕（审计包）

可采购交付

版本库只读镜像接口、变更单摘要留存

发布日志、回滚演练记录

旁听纪要归档接口

验收方式：抽查留痕完整性、回滚演练可复现

林远把这四类读完，最后补了一句：“任何服务包的定价都应该基于交付成本与SLA，不得基于‘通过概率’。一旦你们写‘金融包能降低抽检风险’，这就不是服务目录，是过路费。”

会场里一时安静。

城投采购的人皱眉：“但现实是，银行确实更认‘金融对接能力’。如果不买金融包，银行接口对不上，项目就麻烦。”

“对。”林远点头，“所以金融包可以卖‘对接能力’，不能卖‘认可’。认可来自字段齐全与版本一致，不来自你买了哪个包。”

何经理把话接过去：“银行可以把这一条写进操作指引：我们只认‘数据字段与版本’，不认‘购买某服务包’。否则银行也会被质疑利益输送。”

数科副总脸色微微变：“那我们怎么覆盖成本？审计包、金融包研发成本不小。”

“覆盖成本就按研发+运维算。”林远说，“但你们别用权力覆盖成本。你们可以公开价格构成，公开SLA。你们越公开，越容易被采购；你们越想靠闸门赚溢价，越会被质疑。”

咨询公司的人这时候开始转移战场：“那服务目录还需要一个‘标准解释服务’条目，否则各市理解不一致，会影响数据质量。”

林远看着他，语气依旧平静：“可以有一个条目，名字叫‘问题汇聚与RFC提案服务’。它不是解释服务，是把问题汇聚成提案，推动FAQ条目发布。验收不是你解释得好不好，而是你提案编号、处理时效、版本发布是否留痕。”

他把这句话写到屏幕上，像把刀口磨得更细：

“解释不作为服务交付；提案与留痕作为服务交付。”

周秘书长听到这里，终于忍不住：“林总，你这样写，协会和行业服务商很难生存。大家做的是经验传递、口径辅导，你把它写死成提案和留痕，行业价值被你抹掉了。”

林远没有否认行业价值，而是把价值放回边界里：“经验传递当然重要，但经验不能变成通行证。你可以培训、可以辅导，但你不能承诺‘买了就能过’，你不能以‘唯一窗口’绑定通过，你不能在暗处改口径。行业的价值在于提高大家把证据链补齐的效率，而示弱于‘我替你解释’。”

银行何经理看了眼副处长派来的联络员：“我建议把林总这套目录结构写进试行版，至少先试一月。否则服务目录一出来就会变成闸门，章程等于白写。”

数科副总沉默了几秒，终于妥协了一半：“我们可以按你这四类结构写。但我们希望加一个‘专家支持’条目，按小时计费。”

“可以。”林远点头，“但专家支持必须引用公开FAQ与版本号，且不得单独形成口径结论。专家支持的产出必须落到工单与RFC提案里，可审计。”

他把这句话也写进“服务目录条款”里：“专家支持产出须入库：工单号+提案号。”

会议最后，主持人给了一个看似折中的结论：“服务目录按四类结构调整，取消‘解释服务’表述，改为‘RFC提案与问题汇聚’；金融包不写‘降低风险’，只写对接能力与风险提示；审计包写只读镜像与留痕。价格构成后续另议。”

“价格构成后续另议”听起来像拖延，但林远知道，真正的收费站往往就建在“后续另议”里。

散会后，数科副总把林远叫到一边，语气更私下：“林总，你把闸门堵得太严，我们商业模式不好做。平台要长期运维，总得有利润。你不给解释服务，行业也不愿意买单。”

林远看着他，回答得很慢：“你们的利润应该来自效率：工单闭环、对接成功、预警准确、留痕完整。不是来自‘谁能过’。你们如果把利润绑在‘通过’上，你们就会天然倾向于制造不通过——这样才有生意。”

副总脸色一僵，没再说话。

林远走出会议中心，夜风比昨天更冷。他打开手机，看见匿名入口又多了几条截图：有人在群里开始推“金融包必买，否则银行不认”。售票链换了个名字：从培训包，变成服务包。

他给何经理发了一条信息：

“请银行尽快发一条指引：只认字段与版本，不认购买服务包。否则服务目录会被市场解读成通行证。”

何经理回得很快：

“明白。我们会发。”

林远收起手机，忽然明白了一个更残酷的现实：制度升级从来不是一次性写出来的，而是要不断追着市场解释——解释不是靠嘴，是靠文件、指引、条款、验收。

服务目录这一关，闸门暂时堵住了。

但“价格”还没写。

下一章，定价会才是真正的收费站设计图。