# 候选研发方向：管家的人工智能下属 > 本文独立成篇，可单独送交评审阅读。文中所有背景、事实、方案与验收方法均已自含，不需要查阅其他材料。 > 本文只说明**要做什么、为什么这么做**，以及如何在十二个月内做完并验收。 --- ## 一、这个方向要做什么 在已有的公寓运营软件系统上，研发一套**管家与人工智能的分工机制**：管家是不可替代的真人服务岗位，人工智能作为归属于他的下属，在管家工作时整理信息、归纳情况、准备草稿、提供决策支持；在管家暂时离开、下班或休假时，在明确限定的范围内接管非核心工作；遇到核心事件时停下来联系管家请求支持，把事情交回具名真人。 每个管家都可以拥有这样一个下属，不需要额外招聘，因此可以理解为「每个管家都能免费雇用的实习生」——但要说清它不是替人，而是给人打下手、替人当班，责任始终在管家身上。 本次研发的重点不是让模型更会聊天，而是把「有限接管」这四个字变成可以判定、可以验收、可以审计的机制：什么算非核心、什么时候必须升级、离线接班与交班时上下文怎么交、人工智能说做过的事怎么证明真的做过、管家凭什么信任它。 --- ## 二、名词约定 | 词 | 含义 | |---|---| | 平台 | 我们，即软件系统的开发与运营方，也是本次申报的研发主体 | | 租户 | 使用这套系统的公寓运营公司，是我们的客户；系统按租户隔离数据 | | 租客 | 向租户租房的学生，是服务的接受方 | | 管家 | 租户雇用的真人服务岗位，对租客承担连续服务责任 | | 下属 | 归属于某一位管家的人工智能实例，一人一属，管家可启用、可关闭、可解除 | | 核心事件 | 涉及钱、合同、身份、纠纷投诉、隐私敏感或安全的事项 | | 非核心工作 | 常见问答、信息收集、政策说明、带看预约、工单登记与进度告知等 | | 接管 | 管家不在岗时，下属在授权范围内继续回应租客 | | 交还 | 遇到核心事件或管家回到岗位时，把事情连同完整上下文交回真人 | --- ## 三、现有基础 ### 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. 独立评测样本的人工标注与复核安排。