# 候选研发方向：交易撮合与成交归因 > 本文独立成篇，可单独送交评审阅读。文中所有背景、事实、方案与验收方法均已自含，不需要查阅其他材料。 > 本文只说明**要做什么、为什么这么做**，以及如何在十二个月内做完并验收。 --- ## 一、这个方向要做什么 在一套已经建成、有客户试用的公寓运营软件系统上，本次新建一套**行为驱动的交易撮合系统**：采集租客在找房过程中的行为，把签约与支付结果接回这条行为链，据此判断下一步该做什么——向这位租客展示哪间房、给什么条件、什么时候触达、什么时候必须交回真人管家；每个动作真正落库并留下凭证；最后用对照实验证明哪些动作确实带来了成交。 产品现在已有的只是**传统营销**：运营方在管理后台配置活动、限时抢购、优惠券、预热时间与适用人群，系统按配置发放和核销，并记录活动结果。谁会看到什么、给谁什么条件，由运营方事先设定规则决定，系统不根据租客当下的行为做判断，也不把最后的成交结果接回来检验这些规则有没有用。本项目要建的正是这一整套判断与检验能力。 系统部署在应用服务器还是内容分发网络的边缘节点，由响应时间和现有架构决定，是工程实现的选择。部署位置不影响本方向的研发内容，也不作为技术主张或验收指标。本方向的技术内容是：把行为、库存、授权价格、成交结果接成一条可判定的链，让每次动作有依据、有回执、有责任人，并让效果可以被重复验证。 --- ## 二、名词约定 | 词 | 含义 | |---|---| | 平台 | 我们，即软件系统的开发与运营方，也是本次申报的研发主体 | | 租户 | 使用这套系统的公寓运营公司，是我们的客户；系统按租户隔离数据 | | 租客 | 向租户租房的学生，是浏览、询价、签约的一方 | | 运营方 | 与「租户」同义，指配置活动与负责成交的人 | | 传统营销 | 运营方事先配置规则、系统按规则执行的活动、限时抢购与优惠券 | | 行为事件 | 租客在找房过程中的动作记录，例如查看房源、查看价格、查看合同条款、进入签约、完成签约 | | 撮合决策 | 系统对「下一位租客、下一步给什么条件」做出的判断 | | 成交标签 | 一次行为链路最终是否签约、支付、退租或到期的结果标记 | | 归因 | 判断成交提升是否由系统动作带来，而不是自然波动 | | 广告价 | 对外展示的、来自业主书面授权的价格；与个性化报价分开管理 | --- ## 三、现有基础 ### 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. 价格合规检查所依据规例的专业复核安排。