#候选研发方向：合同模板与全生命周期智能审核

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

#一、这个方向要做什么

在一套已经建成、正在运行的公寓运营软件系统上，新增一项系统级的合同审核能力：系统先按合同适用的地区给出初始合同模板，租户（使用这套系统的公寓运营方）可以修改，系统审核修改后的模板；模板生成具体合同后，在合同创建、每一方签署后、各方签署完成这几个节点继续审核。审核结论是系统里的一个状态，直接决定模板能否发布、合同能否生成、能否进入下一步签署、能否归档生效。

这是一项新能力，不是对现有系统的修补。现有系统负责存储模板、填充变量、生成合同文件、记录签署状态，不判断条款内容是否合适。判断条款这件事现在完全由租户自己找法务完成，系统不参与。本次研发就是把这部分判断接进系统。

选择这个对象的理由很直接：核对一份已经生成的合同，只是一次文本检查，输出一段意见就结束，任何团队用通用模型加提示词都能做。而模板是合同生成源，一个模板会生成很多份合同；审核一次模板，影响的是这个模板今后生成的全部合同。更重要的是，模板、合同、签署状态本来就是系统里的数据结构，审核结论可以写回系统、控制流程能否往下走。这是文本检查做不到的。

#二、名词约定

下文几个词容易混淆，先固定含义：

现有系统里，一份三方租赁合同的三方是业主（甲方）、租客（乙方）、平台（丙方，作为居间服务与收付款代理方）。业主托管协议是两方。本文所说「每一方签署后」包含这些实际签署方。

#三、现有基础

#3.1 已建成的软件系统

我们已经建好并运行一套面向公寓运营方的多租户软件系统，覆盖房源与房间、租客身份核验、报价与锁价、合同模板与合同、签署、账单与收款、业主结算、服务工单、智能锁与水电表、管家会话、营销活动等业务流程。系统按租户隔离数据，合同模板、条款、合同、租约、管家等业务数据都已经归属到具体租户，跨租户引用在数据库层被拒绝。

这套系统不是原型。合同链路已经在生产代码里具备以下能力：

• 模板有版本号、状态（草稿／已发布／已归档）、支持语言、效力语言、签署方名单、来源模板等字段；
• 条款有顺序、锁定标记、多语言正文与变量占位符；每条条款的每种语言都带同步状态，只要有一条条款的任一语言处于「待复核」，发布就会被拦截；
• 合同实例保存生成时所用的模板版本号、渲染后的多语言文本、内容哈希、变量快照和签署名册；
• 合同状态机有草稿、待业主签署、待租客签署、待付款、全部签署完成、已过期、已终止共七种状态；
• 签约会话记录锁定价格、报价快照、当前阶段与幂等键；租约另记录固定租期、提前解约、通知期、押金月数，以及印花与提交期限的证据状态。

也就是说，合同从哪里来、现在是哪一版、被谁改过、谁签了、签的是哪一版内容，系统本来就记录得清楚。本次研发要接上的，是在这些记录之上判断「内容合不合适」。

#3.2 客户与验证条件

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

【待补：试用运营方名称、试用起止时间、试用的业务环节、采购意向的具体形式（意向书、报价沟通记录或试点约定）。这部分证据由申请方补充，本文不代为填写。】

这些试用提供了本次研发最需要的条件：真实的合同模板、真实的修改行为、真实的签署流程，以及一个可以观察审核结果是否被采纳的环境。

#3.3 与本次研发的关系

上列系统、数据结构与生产链路是已有基础，不是本项目要交付的研发成果。本项目交付的是新增的审核能力、支撑它的数据与规则、以及可复现的验收方法。这个区分在验收时会逐项核对。

#四、现在怎么做，问题在哪里

现在的流程：

1. 租户自己创建合同模板。系统提供一份平台默认模板，租户没有自定义模板时回落到它；租户也可以从默认模板物化一份自己的副本再改。
2. 系统检查的是形式条件：变量是否齐全、多语言是否都已标记为已复核、版本是否可发布。检查通过，模板发布。
3. 租客签约时，系统取已发布的最新版本模板，把具体租客、房间、金额、期限填进变量，渲染出合同文本，写入模板版本与内容哈希。
4. 各方依次签署，系统更新签署状态与签署名册，记录签署时间。
5. 合同全部签署完成后进入归档与后续履约、结算、账单环节。

问题出在中间一步：系统始终没有判断条款内容。

• 租户要自己找法务看模板。系统不知道模板为什么这么写、改了哪些条款、依据是什么。改一次看一次，成本由租户承担，且不会沉淀到系统里。
• 模板是生成源。一条不合适的条款写进模板，会被这个模板生成的每一份合同重复带上；等到出现争议才发现，已经影响了一批合同。
• 合同生成时填入的具体数据，可能与模板规则或当地要求不匹配，例如期限、押金、通知期与报价方案不一致。现在系统只校验变量有没有值，不校验值合不合适。
• 签署过程中可能补充条款、加附件、写备注。内容变了，之前对模板做过的确认是否还成立，系统不比对、也不提示。
• 合同生效后如果发生争议，系统能调出「签的是哪一版」，但调不出「当时审过什么、依据是什么、哪些疑点被谁确认过」。

因果链：判断在流程之外 ⇒ 系统只有形式校验没有内容结论 ⇒ 结论无法成为流程状态 ⇒ 错误只能在事后由人发现 ⇒ 发现成本随合同数量增长，且不积累任何可复用的判断数据。

#五、本项目研发内容

研发共六项。每项都说明输入、处理、输出，以及输出接到业务流程的哪个节点。

#5.1 按地区生成初始合同模板

输入：合同适用的地区、合同类型（三方租赁或业主托管）、需要的语言、业务要素（房型、租期类型、押金规则等）。

处理：从两类来源组合出初始模板。第一类是该地区公开的法律规定与公开合同范本，例如香港《印花税条例》（第 117 章）关于租约印花与提交期限的规定、《业主与租客（综合）条例》（第 7 章）相关条文、《床位寓所条例》（第 447 章）关于发牌管制的规定；第二类是系统里已经沉淀、并经过人工确认的同类条款与条款结构。系统按条款类别逐条组装，每条记录依据出处与适用范围。

输出：一份带依据标注、可按条款编辑的初始模板，以及一份「本模板覆盖哪些要求、未覆盖哪些要求」的清单。

接入点：租户新建模板时，作为起点，而不是替租户决定最终内容。

这里要强调：初始模板不是让通用模型凭空写一份合同。凭空生成无法给出依据，也无法验收。本项目生成的是「有出处的条款集合」，每条都能查到来源，且必须经租户确认后才能发布。

#5.2 模板改动审核

输入：租户在初始模板上修改后的版本，以及修改前的版本。

处理：逐条比对，识别新增、删除、改写、顺序调整；对每个改动判断三件事——与地区基线差在哪里、这个差异可能带来什么问题、依据是什么；把改动分成三类：可以直接通过的、需要提示但不阻断的、必须交回人工确认的。

输出：一份改动审核报告，逐条列出差异点、风险说明、依据出处、建议动作、适用边界，并明确标注「本结果为辅助检查，不构成法律意见」。

接入点：审核结论写入模板状态。存在必须人工确认而未确认的改动时，模板不能发布。租户可以坚持自己的写法，但系统记录谁在什么时间、依据什么结论做了这个决定。

为什么审改动而不是审全文：租户真正需要判断的是「我改的这几条有没有问题」。审全文会把已知的、重复的结论反复输出，租户会很快不看；审改动把注意力集中在增量上，结论也更容易复核。

#5.3 四个节点的贯通复核

这是本方向区别于单份合同核对的核心。四个节点审的东西不同，前一步的结论被后一步继承。

结论继承是关键：系统保存每一节点的结论及其对应的内容版本，后一节点只计算增量，不从头重来。这样既避免重复结论，也保证任何时刻都能回答「当前生效的是哪一版、它经过哪些检查、哪些还没确认」。

#5.4 审核结论成为系统状态

审核结果不是一段发给用户看的文字，而是合同流程里的一个字段：通过、有条件通过、待人工确认、不通过。发布模板、生成合同、推进签署、归档生效这四个动作都读取这个字段。涉及金额、合同内容、身份的动作，一律需要有具名的人确认后才能推进。

系统同时记录：谁发起、谁确认、依据的规则版本、当时的内容版本、时间戳。这些记录不可覆盖，只能追加。

#5.5 人工闸门与边界

系统给的是辅助检查和疑点定位，不是法律意见。以下情形必须交回具名真人：条款涉及金额或付款义务、涉及身份与授权、涉及解除与违约责任、签署过程中出现内容变更、审核结果与人工判断不一致。最终确认权在租户的法务或指定负责人。

变化是法务不用逐份通读，只处理系统标出来的地方；不是取消法务，也不是无人服务。每一份输出都自动携带边界声明。

#5.6 可复现的验收方法

建立独立的测试样本，与开发期间使用的样本分开。测试样本覆盖：条款字段抽取、地区差异识别、双语条款不一致识别、改动审核、签署后变化识别、边界情形（例如要求系统给出规避法律义务的建议，此类输出直接判为不合格）。评分标准在测试前写好并固定，测试样本只评分一次。

验收看的不是「模型回答得像不像」，而是：结论有没有原文依据、依据能不能查到、同一输入多次运行是否一致、该拦的是否拦住、该放行的是否放行、有没有漏掉必须人工确认的情形。

#六、数据层专门说明

这一节说明本项目要建设的数据，以及为什么这些数据别人拿不到。人工智能负责处理与判断，数据是它判断的来源；没有这一层，模型只能凭公开知识给出泛泛意见。

第一层，语料。 本项目计划接入已经完成脱敏的各地真实合同数据，同时接入系统运行过程中经租户授权沉淀的合同、租约、模板版本与条款变更历史。每条语料记录适用地区、语言、合同类型、时间、来源与脱敏方式，来源可追溯。脱敏在入库前完成，入库后不保留可识别当事人信息。

第二层，规则。 把各地法律规定拆成可判定的单元，每个单元包含：条款类别、该地区口径、依据出处、对租客或租户的行动含义、适用边界、生效日期、版本号。规则逐条经专业评审后入库，法律变更时新增版本而不是改写旧记录，因为已经签过的合同要按签署当时的规则版本解释。

第三层，字段结构与标注。 定义合同要抽取哪些字段（当事人、期限、租金、押金、终止、维修责任、税费、通知期等），每个结论必须带原文位置，中英双语条款要能对齐并标出不一致，冲突与疑点由人工复核后打标签。这一层决定审核结果能不能被业务系统消费、被人工复核、被测试集评分。

第四层，评测数据。 独立测试样本、评分标准、逐条判定记录、失败案例库。开发与测试样本分开，测试样本不用于调参。

第五层，运行回流。 系统按地区发初始模板、租户改了哪些条款、系统审出什么、租户采纳还是坚持、这个模板后来生成的合同有没有产生退租争议、投诉或纠纷——这条记录只在多租户系统真实运行时才产生。通用模型见过公开法条和公开范本，没见过真实运营方实际怎么改条款、改完出没出事。租户越多、覆盖地区越多，这类记录越厚，审核越准。

为什么这是「非我不可」：模型可以更换，规则库、字段结构、评测样本和运行回流数据不能靠购买一批语料获得，也不能写进提示词里。它们随系统运行持续积累，是本次研发形成的资产。

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

人工智能的输出是概率性的、不保存状态、也不知道谁有权限。业务流程要求结论确定、状态可查、责任到人。因此本项目在工程上做以下约束：

1. 可输出的动作有限。人工智能只能在预先登记的动作集合内提出建议（例如「标记某条款待确认」「生成差异报告」），不能自由创造对业务数据的操作。
2. 能否执行由系统规则裁决。模型只提议，发布、放行、推进签署的决定由状态机与规则做出。
3. 是否真的发生由后端回执证明。动作落库后由业务系统返回凭证；拿不到凭证就视为未发生，转入待跟进，不能由模型自称已完成。
4. 人工闸门不可绕过。涉及钱、合同、身份的动作必须有具名责任人确认，并记录逾期未处理时如何升级。
5. 租户隔离。审核服务读取业务数据使用只读通道，租户归属由业务标识反查，调用方不能自行指定租户；未设定归属时默认拒绝访问。
6. 故障降级。审核服务不可用时，原有合同流程照常可用，只是不提供新增审核结论；不能因为新增能力故障而阻断租户签约。
7. 全程留痕。每次审核的输入版本、规则版本、结论、确认人、时间戳可查，不可覆盖。

这些约束的作用是：让人工智能的判断能够安全地进入一个正在运行的业务系统，并且事后能查清是谁依据什么做了什么决定。

#八、十二个月安排

项目周期十二个月，其中研发集中在前六个月，后六个月用于真实环境验证、评测、修正与商业化准备。资助按官方计划分两期，每六个月做一次里程碑评估。

第 1 个月：范围与结构 确定首批覆盖的地区、合同类型与条款类别；定稿字段结构、规则单元结构、审核结论的状态定义；完成脱敏与授权方案，取得可使用的语料。交付：范围说明、数据结构定义、规则单元样例、语料接入与脱敏协议。

第 2 个月：地区初始模板与规则库 完成首批地区的初始模板生成逻辑与规则单元入库，每条规则带依据与边界，经专业评审。交付：可运行的初始模板生成、规则库第一版、依据清单。

第 3 个月：模板改动审核 完成改动比对、差异识别、报告生成、结论写回模板状态，接上人工确认闸门。交付：租户可用的模板审核功能，含审核报告与状态控制。

第 4 个月：贯通复核 完成合同创建后、每一方签署后、各方签署完成后的复核，实现结论继承与版本比对。交付：四节点贯通链路，任一时点可查当前版本与历史结论。

第 5 个月：评测与工程加固 建立独立测试样本与评分标准；完成只读隔离、后端回执、故障降级、审计留痕；跑第一轮完整评测并修正。交付：测试样本、评分标准、首轮评测报告、工程约束核对表。

第 6 个月：研发收口 冻结研发版本；在试用租户环境接入真实模板与合同；完成中期里程碑交付物。交付：可演示的完整链路、研发说明、中期评测结果。

第 7 至 9 个月：真实环境验证 在试用租户处持续运行，采集审核结论、采纳情况、人工确认记录与争议记录；对失败案例逐条归因并修正规则与字段结构；补充地区与合同类型覆盖。

第 10 至 12 个月：验收与产品化 用独立测试样本做最终评分；整理可对外说明的能力边界与使用方法；形成可授权给其他运营方、也可迁移到其他行业的组件说明；完成期末里程碑评估材料。

#九、交付物与验收方法

所有验收都以系统内可查的记录为准，不以演示效果或主观描述为准。

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

研发内容明确，而且是新的。 现有系统没有内容判断能力。本次要建的是初始模板生成、改动审核、四节点贯通复核、结论控制流程，以及支撑它们的规则库、字段结构、评测样本和运行回流数据。这些都是从零开始，不是把已有功能换个说法。

真实业务提供验证条件。 合同模板、条款版本、签署状态、内容哈希、多语言同步门禁、三方签署名单都已经在生产系统里。新增能力一上线就面对真实模板和真实流程，不需要先搭建一个模拟场景。试用租户与采购意向进一步提供了观察结论是否被采纳的环境【证据待补】。

技术创新点在「审核进入流程」而不是「模型会读合同」。 单份合同核对是一次性文本检查，跟业务系统没有关系；本项目让审核结论成为合同状态机的一部分，控制模板发布、合同生成、签署推进和归档，并把每一步的依据、版本变化、人工确认留下来。要做到这一点，需要模板版本管理、条款结构、签署状态、差异比对、结论继承、人工闸门与审计记录协同工作。这件协同工作本身是研发难点。

商业可行性清楚。 租户现在每建一个模板就要自己请法务通读，改一次看一次。系统把疑点预先筛出来之后，法务只需处理标出的地方；合同出现争议时，能调出当时每一版审过什么、依据是什么。这是租户愿意付费的具体理由，也是软件系统可以按月订阅或按用量收费的能力。

成果留在香港并可独立复用。 研发工作与行政管理在香港进行，形成的规则库、字段结构、评测方法和审核组件归申请主体所有。抽象出来的是「按地区给基线文本、允许本地修改、自动审核改动、在文档从建立到生效的每个节点持续复核、用结论决定是否放行」这一套能力。只要一个行业存在「总部给标准文本、各地分支改动、改完要审、签完要归档」，就能使用，不限于公寓租约，也不依赖现有客户。因此这层能力可以单独授权给其他行业。

#十一、为什么不是简单调用模型

判断标准很简单：换一个基础模型，如果产品几乎原样还在，那就是「套壳」。

本方向换掉模型之后，规则库、字段结构、初始模板的依据链、模板版本与改动记录、四节点的状态控制、后端回执、人工闸门、审计记录、独立测试样本都仍然存在，而且更换模型后必须用同一套独立样本重新评分，证明效果没有下降。模型在这里是可替换的一个零件，不是产品本身。

具体差别：调用模型只能得到一段关于合同的看法；本项目要产出的是一条能被系统执行、能被人工确认、能在争议时调阅、能被测试集评分的结论。前者依赖模型当时的表现，后者依赖本次研发的数据与工程。

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

研发只有六个月，范围必须收窄。以下明确不在本次范围内：

• 不覆盖所有地区与所有合同类型，首批只做有限地区、有限合同类别，做深做透再扩展；
• 不提供法律意见，不出具法律结论，不代替持牌专业人士；
• 不训练或自研基础语言模型，基础模型使用第三方服务；
• 不改动现有合同渲染、签署、支付、结算链路的既有行为，只在其上增加审核状态与闸门；
• 不承诺审核能发现全部问题，输出一律带边界声明与人工确认要求；
• 不做脱离合同场景的通用文档审阅产品。

#十三、待补证据

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

1. 试用运营方名称、试用起止时间、覆盖的业务环节；
2. 采购意向的具体形式与可出示材料；
3. 首批覆盖地区与合同类型的最终确认；
4. 参与规则单元专业评审的法律专业人士安排；
5. 脱敏真实合同语料的来源、授权与使用范围说明。