#候选研发方向：交易撮合与成交归因

本文独立成篇，可单独送交评审阅读。文中所有背景、事实、方案与验收方法均已自含，不需要查阅其他材料。 本文只说明要做什么、为什么这么做，以及如何在十二个月内做完并验收。

#一、这个方向要做什么

在一套已经建成、有客户试用的公寓运营软件系统上，本次新建一套行为驱动的交易撮合系统：采集租客在找房过程中的行为，把签约与支付结果接回这条行为链，据此判断下一步该做什么——向这位租客展示哪间房、给什么条件、什么时候触达、什么时候必须交回真人管家；每个动作真正落库并留下凭证；最后用对照实验证明哪些动作确实带来了成交。

产品现在已有的只是传统营销：运营方在管理后台配置活动、限时抢购、优惠券、预热时间与适用人群，系统按配置发放和核销，并记录活动结果。谁会看到什么、给谁什么条件，由运营方事先设定规则决定，系统不根据租客当下的行为做判断，也不把最后的成交结果接回来检验这些规则有没有用。本项目要建的正是这一整套判断与检验能力。

系统部署在应用服务器还是内容分发网络的边缘节点，由响应时间和现有架构决定，是工程实现的选择。部署位置不影响本方向的研发内容，也不作为技术主张或验收指标。本方向的技术内容是：把行为、库存、授权价格、成交结果接成一条可判定的链，让每次动作有依据、有回执、有责任人，并让效果可以被重复验证。

#二、名词约定

#三、现有基础

#3.1 已建成的软件系统与交易链路

我们已建成一套面向公寓运营方的多租户软件系统，覆盖房源与房间、租客身份核验、报价与锁价、合同模板与合同、三方签署、账单与收款、业主结算、服务工单、管家会话等完整链路，按租户隔离数据。合同与报价有版本与快照，签约会话记录锁定价格与幂等键，租约记录固定租期、押金月数与条款快照。

这条链路的意义是：房源、报价、签约、支付、退租这些事实本来就在系统里，且能对到同一个租客和同一间房。本次要建的行为与成交数据链条，接的就是这些已经存在的业务对象，不需要先造一套模拟数据。

#3.2 产品已有的传统营销能力

运营方可以在管理后台创建营销活动，设置活动类型、预热时间与展示阶段、适用人群、参与人数上限、固定价格等；可以配置限时抢购和代金券模板，设定发放条件、有效期与使用范围；系统按配置向租客展示活动、发放和核销券，并记录活动的结果数据。租客端应用与微信小程序的功能保持同步。

这些能力的共同点是：规则由人预先写好，系统负责执行和记录。

#3.3 客户与验证条件

已有公寓运营方试用这套系统，其中部分表达了采购意向。

【待补：试用运营方名称、试用起止时间、试用的业务环节、采购意向的具体形式。这部分证据由申请方补充，本文不代为填写。】

产品有真实房源、真实报价和真实签约链路在使用，因此租客行为数据和成交结果可以在项目期内采集。新建的撮合系统可以直接接在这条真实链路上验证，不需要先搭建模拟场景。

#3.4 现在止步于哪里

1. 没有行为驱动的判断。 系统记录租客做了什么，但不判断这些行为意味着什么，也不会据此改变下一步给谁看什么、给什么条件。运营方改动规则靠经验，改完有没有变好说不清。
2. 成交结果没有回到行为链。 活动和签约是两段分开的记录。系统知道某次活动有多少人领券，不知道这些领券的人后来有没有签约、付了多少钱、有没有很快退租。判断规则因此无法被真实结果校正。
3. 没有对照实验。 改动规则后成交变多，可能是当周流量本来就好。没有分组与留出，就无法把系统动作的效果和自然波动分开。
4. 没有统一的动作回执。 系统说「已给这位租客发条件」和条件是否真的展示、是否真的被使用、有没有生成后续跟进，是几件不同的事，目前没有一条统一记录把它们连起来。
5. 价格个性化有明确边界。 对外展示的广告价来自业主书面授权；个性化只允许发生在报价层，不能流入对外标价。这条约束涉及香港相关规例，任何新增能力都必须遵守。

所以本次研发不是给已有营销功能加一个模型，而是新建一套系统：从采集行为、形成判断、执行动作，到把成交结果接回来检验判断，形成完整的一条链。

#3.5 与本次研发的关系

上列软件系统、交易链路和传统营销能力是基础与数据来源，不是本项目要交付的成果。本项目交付的是行为采集与成交回流、撮合决策、动作回执、价格合规检查、对照实验与归因评测，以及支撑它们的评测集与工程约束。这个区分在验收时逐项核对。

#3.6 关于成效数字的说明

本项目开始前不宣称已有由本系统撮合产生的成交营收，也不引用未经实验验证的转化率。所有成效指标以本项目对照实验实际产出的数据为准。

#四、问题在哪里：把因果链说完整

现在的流程：运营方配置活动或券 → 系统按规则展示与发放 → 租客自行浏览、询价、进入签约 → 签约与支付在业务系统里完成 → 运营方在后台看活动结果。

断在两头：判断之前，系统不知道这位租客此前做了什么；判断之后，系统不知道最后有没有成交。

由此产生的结果：

• 没有成交标签 ⇒ 无法区分「看起来有意向」和「真的签约」⇒ 给条件的依据只能靠人工经验，且永远不会被真实结果校正；
• 没有对照实验 ⇒ 无法区分「动作有效」和「本周本来就好」⇒ 运营方不敢加大投入，研发也无法判断哪类规则值得保留；
• 决策不进入业务系统 ⇒ 即使判断「该由管家跟进」，也没有凭证证明跟进发生过；
• 没有统一回执 ⇒ 出问题时查不清是哪一步没做，也无法把失败案例变成改进依据。

所以关键不是「让模型写一段更聪明的推荐」，而是把成交结果接回决策链路，让判断可以被真实结果训练和检验。 这句话决定了后面每一项研发内容的顺序。

#五、本项目研发内容

#5.1 行为事件目录与采集

输入：租客在房源浏览、价格查看、合同条款查看、进入签约、完成签约等环节的动作，以及对应的房源、时间与会话标识。

处理：定义统一的事件目录与字段，在租客端和服务端采集，按租户隔离、按会话串成链路；采集范围与保留期限写明，入库前去除可识别当事人信息。

输出：可查询的行为链路数据，以及一份成文的采集与授权说明。

作用：这是后面所有判断的输入。没有统一的事件目录，行为数据就只是一堆零散日志。

#5.2 成交标签回流

输入：行为链路记录；业务系统侧的签约会话、合同状态、支付结果、退租与到期记录。

处理：用签约会话与幂等键把两侧记录对齐，为每条链路打上结果标签：是否签约、是否支付、多久完成、是否退租或到期、最终成交金额区间（不记录可识别当事人信息）。回流在业务系统侧落库，营销系统只读取聚合后的标签，不接触支付与身份明细。

输出：带结果标签的行为链路数据集，以及一条持续运行的回流管道。

作用：把「各阶段转化记录」变成「哪一步最后带来了成交」，也是判断规则能被校正的前提。

#5.3 撮合决策

输入：租客当前所处阶段与近期行为、房源库存与剩余可售时长、业主书面授权的价格下限、租户设定的活动预算与合规边界、当前是否有真人在岗。

处理：模型在预先定义的有限动作集合内提出建议，确定性规则再裁决。可输出的动作只有几类：向这位租客优先展示哪间房、是否给条件（以及条件的类型与上限）、什么时机触达、是否转交真人管家、以及不动作。涉及价格的建议必须先通过价格合规检查；模型不能直接决定金额，也不能改写对外标价。每条建议写明依据了哪些行为、哪条库存事实、哪条授权边界。

输出：一条带依据的撮合建议与裁决结果。

与现有做法的差别：条件不再只由运营方事先写死的规则决定，而是由真实成交结果训练并可由租户在一定范围内配置；每次建议都留依据，可事后核对。

#5.4 价格合规约束

输入：业主书面授权价格、对外广告价、报价层的可选条件、适用的香港规例要求。

处理：在撮合链路中设一道独立检查：对外展示的广告价始终等于业主授权值；个性化只作用于报价层，且必须能追溯到授权与规则；任何把个性化结果写回对外标价的请求直接拒绝并记录。价格相关动作需人工确认的，交回具名真人。

输出：合规检查记录、拒绝记录、授权追溯链。

为什么单独列为研发内容：自动判断一旦接入真实交易，就必须有一层不会被绕过的约束。这道检查与撮合决策同时研发、同时验收，是新增能力能安全上线的条件。

#5.5 动作执行与回执

输入：裁决通过的撮合动作。

处理：动作由营销系统发起，需要业务系统配合的（调整展示顺序、生成报价、锁房、创建跟进任务）通过内部接口执行，由业务系统真正落库并返回带编号的凭证。拿到凭证才算完成；没拿到就生成待跟进事项并指派具名责任人。租客端的条件展示与下单衔接也在这一步接通。

输出：动作回执，含动作类型、凭证编号、执行结果、责任人与时间戳。

作用：把「说过」和「做过」分开。这是运营方敢让系统参与成交环节的前提。

#5.6 对照实验与归因

输入：撮合策略、租客流量、成交标签。

处理：建立分组与留出机制，把同类租客随机分到对照与实验；预先写明评估指标与观察周期；只统计实验期间产生的成交结果，报告增量而不是绝对值；同时记录未命中原因与总体贡献等深度口径。

输出：实验配置、评估指标、结果报告、可重跑的统计脚本。

要解决的难点：营销场景最容易把自然波动当成效果。本项目把「有没有对照」「指标是不是预先写好的」「统计脚本能不能重跑」作为硬性验收项，避免事后挑选好看的数字。

#5.7 评测与故障降级

输入：实验记录、动作日志、业务系统回执。

处理：构建开发样本与独立测试样本，评分标准预先固定，覆盖：决策依据是否完整、越权价格建议是否被拦、动作是否有回执、对照实验分组是否均匀、营销服务故障时主业务流程是否不受影响。独立样本只评分一次。营销服务不可用时，原有房源浏览、报价、签约流程照常可用，只缺失新增撮合动作；出现异常可一键收回。

输出：评测集、评分脚本、失败案例库、故障演练报告。

#六、数据层专门说明

人工智能在这里负责在有限动作内做判断和排序；它判断所依据的数据来自产品系统与本次建设的回流管道，不是来自模型自己的知识。

第一层，行为流。 统一事件目录、按租户隔离的链路记录、按时间组织的汇总、租客所处阶段与房间关注度。这套数据由本项目新建。

第二层，库存与时间价值。 房源、房间、剩余可售时长、锁定状态、活动条件与库存记录。产品系统已有这些业务对象；房间越接近空置期，同一条件的价值越高，这是撮合判断必须用到的业务事实。

第三层，报价血缘。 报价与锁价快照、业主书面授权值、活动条件类型与上限、价格来源标记。这一层保证任何价格相关建议都能追到授权。

第四层，成交标签与实验记录。 行为链路对应的签约、支付、退租、到期结果；分组配置、观察周期、指标定义、统计脚本与逐次结果。

第五层，运行回流。 每多一次实验、多一次成交、多一次未命中，判断依据与失败案例都会变厚，下一次撮合更准。

为什么别人拿不到：公开数据里有推荐算法的样例，没有「某一间学生公寓房间在空置前两周，对某类租客给什么条件最后真的签了约」这种记录。它需要有真实库存、真实业主授权、真实签约与支付链路，并且这四者能对上同一条行为链。这只能在运行中的多租户业务系统里产生。

合规与授权：回流数据集不含可识别当事人信息；统计与训练只使用租户授权范围内的数据；租户之间的数据和模型参数互相隔离。

#七、工程约束与责任边界

1. 模型只能在预先定义的有限动作集合内提议，不能创造动作，不能自行决定金额；
2. 能否执行由确定性规则与价格合规检查裁决，不由模型决定；
3. 涉及价格、合同、身份的动作必须有业务系统回执与具名真人确认；
4. 广告价与个性化报价分离，任何把个性化结果写回对外标价的请求直接拒绝；
5. 租户归属由业务标识反查，不接受调用方自行指定租户；未设定归属时默认拒绝；
6. 营销系统只读取聚合后的成交标签，不接触支付与身份明细；
7. 营销服务故障时，原有房源浏览、报价、签约流程照常可用，只是不提供新增撮合动作；
8. 实验指标与观察周期在实验开始前写好，记录只追加不覆盖；
9. 不宣称已有撮合成交营收，不把自然波动表述为系统效果。

#八、十二个月安排

项目周期十二个月，研发集中在前六个月，后六个月用于真实流量实验、评测、修正与产品化。资助按官方计划分两期，每六个月做一次里程碑评估。

第 1 个月：口径与结构定稿 确定行为事件目录、成交标签定义、链路对齐方式、首批动作集合、价格合规检查规则、对照实验指标与观察周期。指标与评分标准在这一步固定，之后不改。交付：口径说明、数据结构定义、动作集合、实验方案。

第 2 个月：行为采集与成交回流 实现租客端与服务端采集、按会话串链、去除可识别信息；打通签约、支付、退租、到期结果回流。交付：行为链路数据、回流管道、采集与授权说明。

第 3 个月：撮合决策与合规检查 实现有限动作内的决策、确定性裁决、依据记录、人工确认闸门与价格合规检查；接上业务系统内部接口。交付：可运行的撮合决策、合规检查记录。

第 4 个月：动作执行与回执 实现动作发起、业务系统落库、带编号回执、待跟进与责任人指派；接通租客端条件展示与下单衔接；完成故障降级演练。交付：动作回执链路、租客端流程、演练报告。

第 5 个月：对照实验框架 实现分组、留出、指标计算与可重跑统计脚本；跑第一轮开发期实验并修正；独立测试样本不参与。交付：实验框架、首轮开发实验报告、评测集第一版。

第 6 个月：研发收口 冻结研发版本；在试用租户的真实链路下开始受控实验；完成中期交付物。交付：完整系统第一版、中期实验数据、工程约束核对表。

第 7 至 9 个月：真实流量实验 按预先写好的观察周期持续运行对照实验；采集成交结果、未命中原因与总体贡献；对失败与未命中案例逐条归因，扩充动作集合与决策依据。

第 10 至 12 个月：独立评测与产品化 完成一次最终独立评分；整理可对外说明的效果口径与能力边界；形成可迁移到其他有库存时效性的行业的组件说明；完成期末里程碑评估材料。

#九、交付物与验收方法

「把个性化结果写回对外标价」与「无对照却宣称效果提升」为直接判不合格项。

#十、为什么这个方向值得资助

研发内容是新的，范围完整。 产品已有的是传统营销和完整交易链路；本次要建的行为采集、成交回流、撮合决策、动作回执、价格合规检查、对照实验与归因评测，全部从零开始。整套系统在十二个月内可建成，其中研发集中在前六个月。

技术创新在「从行为到成交的闭环」和「效果可验证」。 判断要依据租客当下行为、房源剩余可售时长和业主授权价格；执行要有业务系统凭证；最后还要用分组对照把「有效」变成可复跑的数字，而不是一段营销说辞。更难的是把成交结果接回决策链路，让规则能被真实结果校正。这套组合是研发难点，不是调用模型能得到的。

商业可行性最直接。 撮合影响成交，租户能理解的付费理由最清楚：按成交增量、按活动用量或按订阅计费都有依据。产品已有客户试用和真实签约链路，系统建成后效果可以在项目期内被验证，而不是等到未来才可能验证。价格合规约束让运营方敢在受规管的市场里使用。

成果留在香港并可跨行业复用。 研发与行政管理在香港进行，回流方法、决策模型、合规检查、回执结构、实验框架与统计脚本归申请主体所有。只要一个行业存在「库存有时间价值、需要实时给条件、价格受授权或规例约束、最终成交可观测」，这套能力就能迁移，例如其他有保质期的库存销售与需要真人跟进的服务销售，不限于学生公寓。

直接回应「套壳」质疑。 换掉基础模型后，成交标签、库存与报价血缘、动作集合、合规检查、动作回执、对照实验和统计脚本都还在，且能用同一套实验方法比较新旧决策的效果。模型只负责在有限集合内排序，能不能做、做了没有、有没有效果由系统和数据决定。

#十一、本次不覆盖的范围

• 产品已有的传统营销、房源、报价、合同、签署与支付链路不作为本项目研发成果；
• 系统部署在应用服务器还是内容分发网络边缘，由响应时间和现有架构决定，不作为本方向的技术主张，也不列为验收指标；
• 不宣称本项目开始前已有由系统撮合产生的成交营收，不引用未经实验验证的转化率；
• 不改写对外广告价，不越过业主书面授权范围，不把个性化结果用于对外标价；
• 不训练或自研基础语言模型，基础模型使用第三方服务；
• 不做第三方房源挂牌、不买卖租客线索、不收成交佣金，撮合对象限于租户自有库存；
• 不在未取得对照实验结果前向全体租户扩大放权。

#十二、待补证据

以下内容由申请方补充，本文不代为填写：

1. 试用运营方名称、试用起止时间与采购意向的具体形式；
2. 参与对照实验的租户、房源范围与授权；
3. 业主书面授权价格的可出示材料形式；
4. 行为与成交数据用于采集、训练与评测的租户授权范围；
5. 价格合规检查所依据规例的专业复核安排。