#候选研发方向：管家的人工智能下属

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

#一、这个方向要做什么

在已有的公寓运营软件系统上，研发一套管家与人工智能的分工机制：管家是不可替代的真人服务岗位，人工智能作为归属于他的下属，在管家工作时整理信息、归纳情况、准备草稿、提供决策支持；在管家暂时离开、下班或休假时，在明确限定的范围内接管非核心工作；遇到核心事件时停下来联系管家请求支持，把事情交回具名真人。

每个管家都可以拥有这样一个下属，不需要额外招聘，因此可以理解为「每个管家都能免费雇用的实习生」——但要说清它不是替人，而是给人打下手、替人当班，责任始终在管家身上。

本次研发的重点不是让模型更会聊天，而是把「有限接管」这四个字变成可以判定、可以验收、可以审计的机制：什么算非核心、什么时候必须升级、离线接班与交班时上下文怎么交、人工智能说做过的事怎么证明真的做过、管家凭什么信任它。

#二、名词约定

#三、现有基础

#3.1 已建成的软件系统

我们已建成一套面向公寓运营方的多租户软件系统，覆盖房源与房间、租客身份核验、报价与签约、账单收款、服务工单、智能锁与水电表、管家会话等业务环节。租客与管家之间的会话、工单、预约、通知本来就在系统里流转，这些都是本次研发可以直接使用的真实业务对象。

#3.2 人机协同的初步形态

系统里已经有了一套早期的人机协同底座，处于雏形阶段：

• 每个管家可以「雇用」一个下属，也可以解除；两者在数据上分开记录，管家是真人，下属是另行登记的实例；
• 下属与管家之间有一条专属工作会话，管家和它用聊天方式沟通，不是靠通知单向推送；
• 有四种工作模式，从「只在后台给建议、不对租客发言」，到「低风险直接回答、高风险生成草稿等管家确认」，再到「授权范围内代管家处理并全程留痕」，以及「按排班顶替」；
• 有三道开关：服务是否可用、租户是否启用、管家本人是否允许替班；任一不过，消息不会到达人工智能；
• 下属对业务数据库只读，不自行改写业务表；需要业务系统做事时只能通过内部接口提出请求，由业务系统决定是否执行；
• 动作是预先登记好的类型化契约，由确定性规则先裁决，模型只在规则没有覆盖时才参与，且不能覆盖硬性动作；
• 租客发消息的主链路不依赖人工智能，派发是异步的，人工智能链路故障不影响租客正常发消息；人工智能回复只有一条落库路径，带幂等键，网络重试不会重复回复；
• 有升级通道，识别到身份被识破或需要人工时可以请求管家介入；
• 已定下红线：不主动向租客表露自己是人工智能，被识破时不撒谎、体面交还；不冒充具体真人；管家拥有最终控制权。

这套底座是本次研发的起点，不是交付成果。 它证明了归属关系、只读边界、开关、幂等和降级已经能做到，但下面这些问题还没有解决，正是本次要研发的。

#3.3 客户与验证条件

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

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

试用的价值在于：有真实的管家岗位、真实的租客会话和真实的非办公时间，可以用来观察接管是否恰当、交还是否顺畅。

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

现在的做法：管家在线时自己读消息、自己判断、自己回复、自己建工单；管家不在岗时，租客的消息留在会话里等管家回来，或者由值班人员处理。系统负责把消息送达、把工单记下来，不负责判断「这件事该谁现在处理」。

已经有的开关能控制「要不要让人工智能参与」，但控制不了「参与到什么程度算合适」。 具体问题：

1. 「非核心」没有可判定的定义。 一句租客消息可能表面是问保修时间，实际涉及赔钱；也可能表面提到押金，实际只是问退还流程。现在靠人工设定的清单和现场判断，没有可验证的分级方法，也没有事后核对「该拦的拦住没有」的记录。
2. 升级条件不可配置、不可审计。 什么时候必须停下来找管家、找谁、多久没响应再升级、升级时带哪些上下文，目前没有统一机制。升级晚一步，租客就会得到一个没人负责的承诺。
3. 接班与交班的上下文会丢。 管家下班时，手上正在跟的事、已经答应过什么、租客的偏好，没有形成一份可交接的摘要；管家回来时也不清楚自己不在时发生过什么。租客常常要重讲一遍。
4. 「说了」和「做了」没有分开。 人工智能回复「已为您安排维修」，系统里可能并没有工单；没有凭证就不能算完成。现在缺少统一的完成判定与回执。
5. 管家对下属的信任靠感觉。 没有一套评测能回答：该答的答了没、不该答的有没有越界、该升级的是否升级、接管期间租客是否得到连贯服务。没有这些数字，运营方不敢扩大使用范围。

因果链：分工边界靠人临时判断 ⇒ 结果不可复现、不可审计 ⇒ 运营方只能小范围试用 ⇒ 数据积累不起来 ⇒ 能力无法改进。本次研发就是把分工边界从「人临场判断」变成「系统可判定、可记录、可评分」。

#五、本项目研发内容

#5.1 事件分级与「有限」的判定

输入：一条租客消息、当前会话上下文、该租客的租约与工单状态、管家是否在岗、租户设定的授权范围。

处理：先由确定性规则判断事件类别与风险级（是否涉及钱、合同、身份、纠纷、隐私、安全）；规则未覆盖的情形才交给模型判断，且模型只能给出建议类别，不能自行放权。分级结果连同判断依据一起记录。租户可以按自己的业务调整「哪些类别允许接管」，调整留痕。

输出：一个可查询的分级结果：允许直接处理／生成草稿待确认／必须交还管家，以及判定依据。

接入点：分级结果决定这条消息由谁回应，以及能不能进入后续动作。

#5.2 升级与交还机制

输入：分级结果、管家在岗状态、时限设置。

处理：触发核心事件、判断把握不足、租客明确要求真人、或接管时长超过设定值时，创建一条具名升级：指定责任人、带上完整上下文摘要、设定响应期限；期限内未处理则按预设顺序升级给下一位责任人。管家可以从工作会话里看到全部经过并接手，接手后以同一服务身份继续对话，租客不需要重讲。

输出：升级记录、交接摘要、接手记录、超时升级记录。

红线：不向租客表露人工智能身份；被识破时不撒谎、体面交还；不冒充具体真人；不宣称无人服务，不宣称租客分不出人机。

#5.3 决策支持与工作简报

输入：管家负责的租客、会话、工单、预约、待办、昨夜接管期间发生的事件。

处理：整理成管家上班时先看的一份简报：昨夜发生了什么、哪些已处理、哪些等待他决定、哪些有时限；对正在进行的会话准备回复草稿和相关信息，标明信息来源。

输出：简报、草稿、依据链接、待决事项清单。

边界：下属只整理和提醒，不替管家做决定，不替管家承诺金额或合同条款。

#5.4 完成判定与回执

输入：下属提出的动作建议（例如登记一条报修工单、发出一条进度告知）。

处理：由确定性规则裁决能否执行；允许执行的动作由业务系统真正落库，并返回带编号的凭证；拿到凭证才判定完成，写进回执；拿不到凭证或超时，动作进入待跟进，指定具名责任人并设定时限。模型不能自称已完成。

输出：动作回执，包含动作类型、凭证编号、执行结果、责任人、待跟进项与时限、双语文本。

作用：把「说过」和「做过」分开。这是运营方敢在夜间放权的前提。

#5.5 人机协同评测集

输入：脱敏后的真实会话与工单片段、人工标注的应然处理（该答／该起草／该升级）、接管期间的真实结果记录。

处理：构建开发样本与独立测试样本，评分标准预先固定，覆盖五项：非核心事项是否正确处理、核心事项是否全部拦下并升级、交接摘要是否完整到管家无需追问、动作是否有凭证、故障降级时主链路是否不受影响。独立样本只评分一次。

输出：评测集、评分标准、评分脚本、失败案例库、逐次评分记录。

要解决的难点：这类能力最容易被演示效果掩盖。一段写得漂亮的对话不能证明该拦的拦住了。所以评测把「漏拦核心事件」和「无凭证的承诺」设为直接判不合格的情形。

#5.6 故障降级与灰度放权

输入：服务健康状态、租户开关、管家授权、当前模式。

处理：任一开关未通过则消息不进入人工智能链路，租客发消息照常可用；按模式逐级放权，从只给建议到有限接管，每一步都要有该租户的评测结果支撑；出现异常可一键收回。

输出：开关核对记录、模式变更记录、故障演练报告。

#六、数据层专门说明

人工智能在这里负责理解消息、组织语言和提出建议；它判断所依据的数据来自业务系统，不是来自模型自己的记忆。本项目要建设的数据包括：

第一层，会话与工单语料。 经脱敏与租户授权的租客会话、管家回复、工单记录、预约记录、通知记录，按事件类别、时间、是否在管家在岗时段、涉及的业务对象标注。

第二层，分级与升级标注。 每条样本标注应然处理：允许直接处理、需要草稿、必须交还；以及实际处理结果、是否发生二次追问、租客是否重复描述同一问题。这些标签由具名人工复核，是评测的核心。

第三层，交接与回执记录。 每次接班的上下文快照、每次交还的原因与耗时、每个动作的凭证编号与执行结果、超期未处理与升级路径。

第四层，失败案例库。 漏拦、误拦、无凭证承诺、交接信息缺失、租客重复描述等案例逐条归因，用于修正分级规则与摘要结构。

第五层，运行回流。 租户越多、管家越多、非办公时段的真实事件越多，分级样本和边界情形越厚，判定越准，运营方也越敢扩大接管范围。

为什么别人拿不到：公开的客服语料里没有「管家下班后这一小时的报修该怎么处理」这类带责任归属、带后续结果的记录；也不会记录「系统有没有真的建工单」。这些数据只在有真人岗位、有工单系统、有责任人、且人工智能实际参与过的环境里产生。

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

1. 一人一属：下属归属于具名管家，管家可启用、关闭、解除，控制记录留痕。
2. 只读业务库：下属使用只读通道访问业务数据，租户归属由业务标识反查，调用方不能自行指定租户；未设定归属时默认拒绝。
3. 动作有限且需裁决：只能提出预先登记的动作；能否执行由规则与业务系统决定；模型不能覆盖硬性动作。
4. 完成以回执为准：没有业务系统返回的凭证就不算完成，自动转入待跟进并指派责任人。
5. 核心事件人工闸门：涉及钱、合同、身份、纠纷、隐私、安全的动作一律交回具名真人。
6. 主链路不受影响：租客发消息不依赖人工智能；人工智能链路故障、超时、异常都不阻断原有会话。
7. 表述红线：不使用「替代人力」「无人服务」「省掉几个员工」等表述；不宣称租客分不出人机。
8. 全程留痕：分级依据、动作建议、裁决结果、凭证、升级、接管、交还均可查，只追加不覆盖。

#八、十二个月安排

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

第 1 个月：边界定稿 与试用租户一起确定事件分类、核心事件清单、可接管范围、升级顺序与时限；定稿分级规则结构、交接摘要结构、回执字段与评测评分标准。评分标准在这一步固定。交付：边界说明、分级规则表、数据结构定义、评测标准。

第 2 个月：分级与升级 实现确定性分级、规则未覆盖时的模型建议、具名升级与超时升级、交接摘要生成。交付：可运行的分级与升级链路、升级与交接记录。

第 3 个月：决策支持 实现工作简报、回复草稿、依据链接、待决事项清单；接上管家专属工作会话。交付：管家端可用的一天简报与草稿功能。

第 4 个月：完成判定与回执 实现动作裁决、业务系统落库、凭证回执、待跟进与责任人指派；完成只读隔离、幂等与故障降级核对。交付：动作回执链路、工程约束核对表。

第 5 个月：评测集与第一轮评分 构建开发样本与独立测试样本；跑第一轮开发评分，修正分级规则与摘要结构；独立测试样本不参与。交付：评测集、评分脚本、首轮开发评分报告、失败案例库第一版。

第 6 个月：研发收口 冻结研发版本；在试用租户的非办公时段试运行；完成中期交付物与故障演练。交付：完整链路、中期评测结果、演练报告。

第 7 至 9 个月：真实班次验证 在真实管家排班下持续运行，采集接管与交还记录、租客重复描述率、漏拦与误拦案例；逐条归因并扩充分级规则；逐步按评测结果放权。

第 10 至 12 个月：独立评测与产品化 用独立测试样本做一次最终评分；整理能力边界与运营方使用说明；形成可迁移到其他有具名服务岗位行业的组件说明；完成期末里程碑评估材料。

#九、交付物与验收方法

「漏拦核心事件」与「无凭证承诺」为直接判不合格项。

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

研发内容是新的，且难点明确。 现有底座解决了「能不能让人工智能参与」，没解决「参与到什么程度算合适、怎么证明它做过、怎么把责任连续地交回真人」。本次研发的分级判定、升级与交接、回执、评测集都是新工作，范围收在非办公时段的有限接管，六个月可完成。

技术创新在人机分工，不在模型能力。 服务行业里最贵的不是回答，是负责。本项目让人工智能承担信息劳动（整理、归纳、起草、登记），让责任人始终是有名有姓的真人；技术难点集中在「有限」二字：什么算非核心、何时必须升级、上下文怎么完整交接、怎么证明动作真的发生。这些是制度设计与工程判定的问题，不是换一个更强的模型能解决的。

商业可行性清楚，且容易被一线接受。 我们不卖「裁掉谁」，卖「给每位管家配一个下属」。管家用同样的时间服务更多租客，非办公时段的常见请求不用等到第二天；运营方不必改变岗位设置，也不需要承担无人服务的风险。这比替代人力的方案更容易在真实物业组织里落地，也更适合按月订阅或按管家数量计价。

成果留在香港并可跨行业复用。 研发与行政管理在香港进行，形成的分级方法、交接协议、回执结构、评测标准与组件归申请主体所有。只要一个行业存在「有具名服务岗位、服务不能中断、部分事项必须由真人负责」，这套分工机制就能迁移，不限于学生公寓。

直接回应「套壳」质疑。 换掉基础模型后，分级规则、升级链路、交接协议、动作回执、只读隔离、评测集都还在，且能用同一套独立样本证明新模型是否更可靠。模型只负责理解和措辞，责任边界与执行结果由系统决定。

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

• 不宣称人工智能替代管家，不建设无人值守服务，不宣称租客分不出人机；
• 不自动执行涉及钱、合同、身份、纠纷的动作；
• 不训练或自研基础语言模型，基础模型使用第三方服务；
• 不覆盖全部业务场景，首批只做常见问答、信息收集、工单登记、进度告知、带看预约等非核心事项；
• 不改动原有会话、工单、预约链路的既有行为，只在授权范围内增加分工与回执；
• 不在未取得评测结果前把放权范围扩大到全体租户。

#十二、待补证据

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

1. 试用运营方名称、试用起止时间与采购意向的具体形式；
2. 参与边界制定的管家岗位与排班安排（含非办公时段）；
3. 租户对会话与工单数据用于研发和评测的授权范围；
4. 核心事件清单的最终确认人；
5. 独立评测样本的人工标注与复核安排。