# 候选研发方向：合同模板与全生命周期智能审核 > 本文独立成篇，可单独送交评审阅读。文中所有背景、事实、方案与验收方法均已自含，不需要查阅其他材料。 > 本文只说明**要做什么、为什么这么做**，以及如何在十二个月内做完并验收。 --- ## 一、这个方向要做什么 在一套已经建成、正在运行的公寓运营软件系统上，新增一项**系统级的合同审核能力**：系统先按合同适用的地区给出初始合同模板，租户（使用这套系统的公寓运营方）可以修改，系统审核修改后的模板；模板生成具体合同后，在合同创建、每一方签署后、各方签署完成这几个节点继续审核。审核结论是系统里的一个状态，直接决定模板能否发布、合同能否生成、能否进入下一步签署、能否归档生效。 这是一项新能力，不是对现有系统的修补。现有系统负责存储模板、填充变量、生成合同文件、记录签署状态，**不判断条款内容是否合适**。判断条款这件事现在完全由租户自己找法务完成，系统不参与。本次研发就是把这部分判断接进系统。 选择这个对象的理由很直接：核对一份已经生成的合同，只是一次文本检查，输出一段意见就结束，任何团队用通用模型加提示词都能做。而模板是合同生成源，一个模板会生成很多份合同；审核一次模板，影响的是这个模板今后生成的全部合同。更重要的是，模板、合同、签署状态本来就是系统里的数据结构，审核结论可以写回系统、控制流程能否往下走。这是文本检查做不到的。 --- ## 二、名词约定 下文几个词容易混淆，先固定含义： | 词 | 含义 | |---|---| | 平台 | 我们，即这套软件系统的开发与运营方，也是本次申报的研发主体 | | 租户 | 购买或试用这套系统的公寓运营公司，是我们的客户。系统按租户隔离数据 | | 租客 | 向租户租房的学生，是合同的签署方之一 | | 管家 | 租户雇用的真人服务岗位，负责租客日常服务 | | 合同模板 | 租户在系统中维护的条款集合，含可替换变量（当事人、房间、租金、期限等），用于生成具体合同 | | 合同 | 由某个模板的具体版本加上一次具体业务数据生成的不可变文件 | 现有系统里，一份三方租赁合同的三方是业主（甲方）、租客（乙方）、平台（丙方，作为居间服务与收付款代理方）。业主托管协议是两方。本文所说「每一方签署后」包含这些实际签署方。 --- ## 三、现有基础 ### 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. 脱敏真实合同语料的来源、授权与使用范围说明。