团队项目第一次作业
租房助手——基于智能体的租房管理与决策辅助系统
| 作业所属课程 | https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/ |
|---|---|
| 作业要求 | https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/16766 |
| 作业的目标 | 基于智能体将重复、繁杂的生活场景流程化,并且能追踪信息变化、动态调整输出内容 |
| 团队名称 | 我思故我队 |
| 团队成员学号-名字 | 汪琳-3224004195、陈沐兰-3224004191、蔡小宇-3224004190 |
目录
一、团队展示
1.1 团队名称
- 队名: 我思故我队
1.2 队员风采
| 成员信息 | 兴趣爱好 | 擅长的技术 | 希望的软工角色 |
|---|---|---|---|
| 汪琳 | 追剧 | Python 后端开发、SQL 与关系型数据库 | 后端 |
| 陈沐兰 | 听歌 | Python 基础开发、Web 前端开发 | 前端 |
| 蔡小宇 | 打乒乓球 | 大模型 API 调用、接口测试 | 测试与集成 |
1.3 团队首次合照

二、选题报告
2.1 项目背景与选题来源
住房租赁是城市居住的一种常见方式。第七次全国人口普查显示,2020 年 11 月 1 日我国大陆流动人口为 37582 万人,城镇人口占 63.89%。媒体根据《中国人口普查年鉴-2020》长表住房资料整理,城市家庭户中,租赁廉租住房、公租房和其他住房的合计占比约为 25.57%。长表为住户抽样,该比例是对年鉴住房来源分类的整理,不是本项目重新计算的结果。这些数据说明租赁居住具有相当规模,但不能直接证明某一类信息管理问题有多普遍。
对单个租房者而言,困难往往出现在已经开始看房之后。房源介绍、照片、聊天记录、看房印象和合同文本来自不同渠道,产生于不同时间。租金、押金、维修责任和入住条件可能前后不一致。用户需要记住哪句话来自平台页面,哪句话来自中介,哪句话只是自己的现场感受,并在比较和签约前再核对一次。
现有租房平台主要解决房源供给、搜索、展示和部分交易服务。通用备忘录、表格和聊天收藏可以保存材料,但不会区分“原始陈述”“模型提取的候选”和“用户确认后的有效信息”。直接向通用大模型提问,可以得到一次摘要,但对话结束后,来源、确认状态和后续变化不容易继续跟踪。
RentMate 的选题来自课程对智能体应用的要求:项目需要把智能体嵌入实际软件,解决有现实意义的问题,形成可演示、可上线体验的系统,并在三人团队和课程周期内完成。团队据此选择租房决策过程中的信息整理问题,而不是再做一个房源搜索或在线签约平台。
项目初期通过身边人群的非正式交流和网络资料搜集了解租房场景,并进一步开展线上问卷调查,初步收集用户在房源比较、实地看房、租赁沟通和信息管理等方面的需求。调研结果为项目的功能设计提供了参考,但受样本规模、地域分布和问卷收集渠道限制,仍需通过后续用户测试进一步验证产品需求与实际效果。
2.2 用户调研与需求分析
2.2.1 问卷调查设计与样本情况
为了解用户在租房信息收集、房源比较、实地看房及租赁沟通等环节中的实际需求,项目组设计并开展了线上问卷调查。问卷共设置 29 道题目,主要涉及受访者租房经历、房源筛选与比较、看房记录、租赁沟通与合同核对、租房信息变化、产品功能需求及 AI 使用与隐私顾虑等七个方面。
本次调查共回收 26 份问卷,均为有效问卷,主要通过微信渠道收集。受访者以广东省内用户为主,涉及广州、中山、汕头、湛江、东莞、潮州、茂名等地,另有部分受访者来自天津。
在租房经历方面,7 人(26.9%)在过去一年内有租房经历,2 人(7.7%)正在寻找房源,12 人(46.2%)目前尚无租房经历但未来有租房计划。独立租房次数方面,14 人(53.8%)从未独立租房,4 人(15.4%)有过一次经历,另有 8 人(30.8%)有两次及以上经历。
整体来看,本次调查既覆盖了有实际租房经历的用户,也纳入了未来可能产生租房需求的潜在用户,能够为项目初期的需求分析提供一定参考。但受样本规模、地域分布和问卷收集渠道限制,调查结果主要用于探索用户需求,不宜直接视为对全体租房人群的代表性结论。
2.2.2 问卷调查结果
(1)房源筛选与比较:信息分散、关键内容不完整
在房源筛选过程中,42.3%的受访者通常会比较 4—5 套房源,30.8%会比较 2—3 套,说明多房源之间的信息整理与比较是较为常见的需求。受访者关注的因素主要包括租金(92.3%)、采光与通风(84.6%)、地理位置(80.8%),以及押金、通勤、费用和租期等因素。
在实际比较中,65.4%的受访者遇到过信息分散在不同渠道的问题,57.7%认为房源关键信息不完整,46.2%表示看房信息难以关联,42.3%曾忘记不同房源的具体情况。目前,受访者主要通过微信收藏或聊天记录(53.8%)、手机备忘录(50.0%)和个人记忆(38.5%)保存信息,缺少统一的整理方式。
(2)实地看房:检查事项容易遗漏,现场信息难以系统整理
看房前,53.8%的受访者会始终准备检查事项,30.8%偶尔准备,但仍有 65.4%的受访者表示看房时曾出现检查事项遗漏的情况。
在看房记录方式上,84.6%的受访者会拍摄照片,57.7%会录制视频,38.5%会使用文字记录,另有 23.1%主要依靠记忆。现有记录方式能够保留部分现场信息,但不同形式的材料相对分散,后续回顾和与房源原始信息进行对照时仍存在整理成本。
(3)租赁沟通与合同核对:重要承诺和合同条款需要进一步对应
在签约前的信息核对方面,30.8%的受访者表示每次都会检查,34.6%会重点核对重要事项,说明部分用户仍缺少较为系统的签约前检查习惯。
受访者重点关注的内容包括租金、押金及相关费用(96.2%)、租赁期限(88.5%)、口头承诺是否写入合同(76.9%)、退租条件与押金返还(73.1%),以及维修责任、合同描述与实际情况是否一致等内容。这表明,租赁沟通中形成的承诺与合同文本之间需要进行更清晰的整理和核对。
(4)租房信息变化:缺少持续的历史记录与追踪方式
租赁过程中,受访者遇到过的信息变化主要包括房屋维修(46.2%)、租金或押金调整(42.3%),以及家电、租期、入住时间和费用承担等方面的变化。
面对信息变化,61.5%的受访者会保留原有聊天记录及新的沟通内容,30.8%会修改原有笔记,另有部分用户选择记住最新情况或重新整理信息。同时,80.8%的受访者希望能够保留租房信息的变化历史,其中 50.0%表示非常需要。这说明租房信息管理不仅需要记录当前状态,也需要关注信息变化及其来源。
(5)产品功能与 AI 使用需求:重视信息整理,同时关注可靠性与隐私
在产品需求方面,80.8%的受访者对统一管理房源及相关材料的功能给出了较高评价(4—5 分)。具体功能评价中,材料自动提取的平均评分为 4.54 分,沟通承诺与合同内容对照为 4.50 分,看房观察记录与承诺追踪为 4.46 分;自定义比较维度、房源描述与现场情况对照及比较报告等功能的平均评分也均在 4.35 分左右。
在功能优先级选择中,50.0%的受访者优先选择多房源整理与比较,30.8%优先选择材料信息提取。在 AI 使用方式上,65.4%的受访者倾向于先由系统自动提取信息,再由用户确认后保存;80.8%的受访者希望分析结论能够同时提供原始证据,并保留用户确认环节。
与此同时,用户对隐私和数据安全较为关注:84.6%的受访者担心个人信息泄露,61.5%担心材料被用于其他用途,另有 57.7%担心账号或数据丢失。因此,系统在提供智能化信息处理能力的同时,还需要重视材料管理、用户确认和数据安全。
2.2.3 用户核心痛点
结合问卷结果,项目组将用户在租房过程中的主要问题归纳为以下四类:
| 用户核心痛点 | 问卷调查依据 | 具体表现 |
|---|---|---|
| 多房源信息分散,比较成本较高 | 65.4%的受访者遇到信息分散问题,57.7%认为房源关键信息不完整 | 房源信息分布在不同平台、聊天记录和个人笔记中,缺少统一归档与横向比较方式,容易遗漏或混淆不同房源的信息。 |
| 看房检查与记录不够系统 | 65.4%的受访者曾出现检查事项遗漏;84.6%通过照片记录看房情况 | 看房前的检查准备和现场记录方式不统一,现场信息难以与房源原始描述关联,后续回顾时容易遗漏细节。 |
| 沟通承诺与合同条款缺少系统核对 | 76.9%的受访者关注口头承诺是否写入合同,96.2%的受访者关注租金、押金及相关费用 | 租赁沟通中形成的信息需要进一步整理,并与合同中的具体条款对应,用户容易忽略重要约定或核对事项。 |
| 租房信息变化缺少持续追踪 | 80.8%的受访者希望保留信息变化历史 | 租金、维修、设施及其他约定可能发生变化,现有方式主要依赖保留聊天记录、修改笔记或重新整理,缺少专门的历史变化管理机制。 |
此外,调查中反映出的隐私顾虑和 AI 分析可靠性问题,也是产品设计需要考虑的重要约束。系统不能仅追求自动化处理效率,还应保留原始材料、提供信息来源,并将关键内容的确认权交还用户。
2.2.4 用户功能需求归纳
基于上述痛点,项目组将用户需求进一步转化为产品功能方向。功能设计不仅关注信息记录和整理,也强调不同环节之间的信息关联与持续管理。
| 需求方向 | 对应用户需求 | 拟提供的功能 |
|---|---|---|
| 多房源信息管理与比较 | 统一整理不同房源的信息,降低反复查找和比较成本 | 租房计划与需求管理、房源档案、多源材料归档、房源信息提取与确认、多房源比较及自定义比较维度。 |
| 看房检查与现场记录 | 减少看房事项遗漏,方便整理和回顾现场信息 | 可编辑的看房检查清单、文字与图片观察记录、现场信息提取及关联建议、用户确认后更新房源档案,并支持问题记录。 |
| 租赁沟通与合同核对 | 整理沟通中的重要承诺,辅助检查合同中的关键事项 | 沟通材料整理与承诺确认、承诺信息与房源档案关联、固定十项合同检查清单及合同内容对照。 |
| 租房信息变化管理 | 记录信息变化,保留历史内容,持续追踪待处理事项 | 信息版本与变化历史、信息差异提示、问题事项跟踪及处理状态管理。 |
在上述功能中,Agent 主要承担材料信息提取、内容归纳、关联建议和差异提示等任务;信息是否有效、是否写入档案,仍由用户确认。对于看房照片,系统不进行房屋缺陷识别或真实性判断;对于合同内容,系统仅围绕预设的十项固定检查内容提供辅助核对,不作法律效力、合同合法性或签约安全性判断。
同时,考虑到材料识别和模型分析可能存在误差,系统需要保留原始证据,并为关键操作提供人工确认和手动处理方式。由此,RentMate 将定位为面向个人租房过程的信息管理与决策辅助系统,通过统一管理房源、沟通材料、看房记录及合同信息,帮助用户降低信息整理与核对成本。
2.3 竞品分析与产品定位
本项目选取贝壳租房、自如、通用记录工具和通用对话模型作为分析对象,从房源服务、信息记录和智能处理等角度分析现有工具的特点,明确 RentMate 的目标场景与差异化定位。
2.3.1 贝壳租房
贝壳租房主要提供房源搜索、筛选、关注、VR 看房及租赁咨询等服务,帮助用户发现和了解候选房源。
但用户在实际租房过程中,可能同时接触不同平台、中介或个人房东,相关信息分散在平台页面、聊天记录和线下看房记录中。RentMate 不替代平台的房源搜索功能,而是关注候选房源产生后的信息整理、来源关联和多房源比较。
2.3.2 自如
自如以机构化住房租赁为核心,提供合租、整租及配套居住服务,侧重平台自身房源和租住服务的衔接。
与之不同,RentMate 面向需要自行比较不同渠道房源的用户,帮助其统一管理多来源信息、沟通记录和看房情况,弥补跨渠道信息整理与核对方面的需求。
2.3.3 通用记录工具与通用对话模型
用户也会借助微信收藏、聊天记录和手机备忘录等工具保存租房信息。本次问卷中,53.8%的受访者使用微信收藏或聊天记录,50.0%使用手机备忘录。这些工具使用方便,但信息整理、来源关联和后续比较主要依赖用户手动完成。
通用对话模型能够辅助提取和归纳文本信息,但单次对话难以承担持续的房源档案管理和跨阶段信息追踪。RentMate 则将 Agent 的信息理解与处理能力嵌入租房业务流程,使提取结果能够经过用户确认后进入档案,并继续用于看房、比较和合同核对。
2.3.4 尚未充分覆盖的问题与 RentMate 的定位
综合来看,现有工具分别解决了房源查找、租赁服务、日常记录和文本处理等问题,但用户在跨渠道收集信息后,仍需要自行完成整理、确认、关联和持续核对。
问卷中,65.4%的受访者遇到过房源信息分散的问题,65.4%曾在看房时遗漏检查事项,80.8%希望保留租房信息的变化历史。这些结果为 RentMate 聚焦租房过程中的信息管理与决策辅助提供了初步依据。
| 对比对象 | 主要作用 | RentMate 的补充价值 |
|---|---|---|
| 贝壳租房等平台 | 房源搜索、筛选及租赁服务 | 管理不同渠道的候选房源及相关信息 |
| 自如等机构化租赁平台 | 平台房源与配套居住服务 | 管理用户自行比较的多渠道房源 |
| 微信、备忘录等工具 | 保存聊天、图片和文字 | 结构化整理信息,关联来源与变化历史 |
| 通用对话模型 | 文本提取、摘要与归纳 | 结合租房业务上下文,衔接后续管理流程 |
基于上述分析,RentMate 定位为:面向租房者、以 Agent 为核心辅助能力的租房全流程助手。
其核心差异化价值在于构建多来源证据链,并将信息处理贯穿租房不同阶段:Agent 能够理解房源材料、整理看房观察、辅助房源比较,并协助核对沟通承诺与合同条款;结构化业务系统负责保存原始材料、管理信息状态和衔接各环节,用户确认后,提取结果才能成为有效档案信息。
通过这种方式,RentMate 不只是提供一次性的 AI 问答或信息提取,而是帮助用户将分散的租房信息转化为可追溯、可持续使用的决策依据,降低租房全流程中的信息整理与核对成本。
2.4 产品方案与核心功能
2.4.1 总体定位与业务模块
RentMate 是一款以 Agent 为核心辅助能力的租房全流程助手,面向已有候选房源的租房者,帮助用户完成租房需求管理、房源信息收集、实地看房、多房源比较以及沟通与签约前核对,提升租房过程中的信息管理效率。
系统主要包括以下业务模块:
- 租房计划与需求管理: 支持创建多个租房计划,维护租房条件与个人偏好。
- 房源档案与材料管理: 收集不同渠道的房源信息,整理原始材料及提取结果。
- 看房记录与问题跟踪: 提供基础看房清单,记录现场观察并跟踪待处理问题。
- 多房源比较: 汇总不同房源的信息,支持默认及自定义比较维度。
- 沟通与合同核对: 整理沟通承诺,并辅助核对合同中的关键内容。
Agent 贯穿上述业务环节,负责理解材料、提取信息、提出关联建议并辅助分析。第一版聚焦核心租房流程,区域推荐、截图 OCR 和复杂报告导出等能力作为后续迭代方向。
2.4.2 证据链:三类信息
RentMate 的核心设计是建立多来源证据链,将租房过程中的信息划分为原始材料、Agent 提取的候选信息和用户确认后的有效信息三个层次,实现信息从收集、整理到确认和使用的全过程管理。
用户导入房源介绍、沟通文本、数字版 PDF 或 Word,或记录看房观察后,Agent 对相关内容进行理解和提取,并提出信息关联建议。用户确认、修改或排除后,相关结果才进入有效档案,原始材料则予以保留,便于后续查询与追溯。
当不同来源的信息存在差异时,系统保留相关依据并提示用户核实,不由 Agent 自行判断信息的真实性。尚未确认或缺失的信息也会在后续比较和核对中得到区分,避免将信息缺失直接视为不符合要求。
2.4.3 第一版业务流程

第一版围绕两条核心业务链路展开:
链路 A:多来源信息整理、看房与房源比较。
用户创建租房计划并录入需求,添加候选房源、导入相关材料;Agent 提取房源信息,由用户确认后形成档案。随后,用户可以生成并调整看房清单,记录现场观察、处理信息差异或创建问题,最后对多套房源进行比较。
链路 B:沟通承诺与签约前合同核对。
用户保存与房东或中介的沟通记录,审核 Agent 提取的租赁条件和承诺,再导入合同文本,按照十项固定清单提取相关内容,与已有档案及已审核承诺进行对照,并处理核对发现。
两条链路可以相互衔接,但不构成强制的线性流程。例如,没有看房记录的房源仍然可以参与比较;已经确认的看房信息则可以进入后续档案和合同核对环节。
2.4.4 第一版核心功能
(1)租房计划与需求管理
支持用户创建多个租房计划,维护结构化租房需求,区分硬性条件与个人偏好。需求可以根据实际情况动态调整,也允许暂时不完整;当需求信息不足时,系统仍可进行客观信息比较,但不生成需求匹配结论。
(2)房源档案与多来源信息整理
支持在同一租房计划下建立多套房源档案,保存房源基本信息及租金、户型、费用等信息项。每项信息可以关联多条来源陈述,并记录相关确认状态及变化历史。
(3)材料抽取与用户确认
支持粘贴文本以及导入数字版 PDF、Word。Agent 提取候选信息和来源摘录,并提出信息关联建议,由用户确认、修改或排除后再更新档案。解析失败时保留原始材料,并支持手动录入;第一版暂不包含截图 OCR。
(4)基础看房记录与现场观察
支持独立创建多次看房记录,根据当前需求和待确认信息生成可编辑的基础检查清单,并通过文字、图片记录现场观察。Agent 辅助整理文字观察,用户确认后才可将相关信息写入房源档案,也可以选择仅保留记录或创建问题。第一版暂不包含房屋缺陷识别和视频分析。
(5)多房源比较
支持同一租房计划下的多套房源比较,提供默认比较维度,并允许用户增加、删除和调整维度。系统根据房源信息及其确认状态展示比较结果,区分已明确的信息、待确认信息和来源差异;对于信息缺失的情况,不直接判定为不符合。比较结果保留相关依据和待核实事项,不提供权重评分、排名或唯一推荐。
(6)沟通承诺审核与合同核对
Agent 辅助提取沟通中的租赁条件、承诺和待确认事项,由用户选择是否写入档案、创建问题或仅保留沟通记录。合同核对限定为十项内容:租金、押金、支付周期、其他费用、租期、交付条件、维修责任、使用限制、退租条件和押金退还。系统提取相关合同内容并保存核对结果,不提供完整合同审查或法律结论。
(7)基础问题跟踪
支持用户手动创建问题,也可以从看房记录和核对发现中创建问题。用户可以更新问题状态,跟踪尚未处理的事项,帮助减少租房过程中的信息遗漏。
2.4.5 第一版与后续迭代
| 类别 | 主要内容 |
|---|---|
| 第一版承诺 | 租房计划与需求、房源档案、材料抽取与确认、来源差异、基础看房、自定义比较维度、沟通承诺审核、十项合同核对、基础问题跟踪、信息追溯及手动回退 |
| 后续迭代 | 自然语言需求整理、区域推荐、截图及扫描件 OCR、复杂语义差异识别、问题处理记录、合同章节级定位、复杂报告导出 |
| 不纳入产品能力 | 全网房源抓取、外部平台同步、产权及身份核验、法律结论、评分排名、自动淘汰房源、自动联系及代替用户签约 |
系统按照单用户私有空间管理数据,并准备包含信息冲突、看房记录和合同核对内容的虚构演示案例,供老师、助教和同学体验。公开演示不使用真实合同和聊天记录。
2.5 技术方案与创新点
2.5.1 总体方案
RentMate 采用客户端与服务端协作的系统架构。用户通过交互端完成租房计划管理、房源信息录入、材料上传、看房记录和核对结果查看;后端负责业务逻辑、数据持久化、状态管理及 Agent 调用。具体交互载体将结合团队开发能力、使用场景和部署要求进一步确定。
系统将 Agent 嵌入材料解析、信息整理、看房记录、比较结果辅助分析及合同核对等具体业务环节。模型负责材料理解、信息提取和辅助分析,程序负责数据保存、权限控制、信息关联和确定性业务规则,用户保留关键确认权。
通过这种方式,RentMate 不只是提供通用对话服务,而是将 Agent 能力融入具有持续数据管理和业务状态的租房辅助系统。
2.5.2 Agent 与程序的分工
系统按照 Agent、业务程序和用户三方协作的方式组织功能,具体分工如下:
| 业务环节 | Agent 负责 | 程序负责 | 用户负责 |
|---|---|---|---|
| 房源材料整理 | 提取候选信息和原文摘录 | 保存原始材料、候选信息及来源 | 确认、修改或排除提取结果 |
| 信息关联 | 提出与已有信息项的关联建议 | 管理信息项及来源关系 | 确认关联或选择新建信息项 |
| 看房记录 | 整理文字观察,提出候选信息 | 生成基础清单,保存看房记录和原始观察 | 记录现场情况并确认是否写入档案 |
| 房源比较 | 根据比较结果和来源撰写辅助摘要 | 管理比较维度,计算可判断的硬性条件,提示结果过期 | 查看结果并决定是否重新比较 |
| 沟通与合同核对 | 提取沟通承诺、合同摘录并辅助对照 | 保存原始记录、核对结果及相关依据 | 审核承诺,处理核对发现 |
| 问题跟踪 | 根据业务内容提出问题跟踪建议 | 保存问题及其状态 | 创建问题并更新处理状态 |
在模型调用失败或结果无法使用时,系统保留手动处理路径:用户可以手动录入房源信息和合同摘录,继续保存看房观察;房源比较仍可展示程序已经计算的结果。模型异常不会清除已保存的原始材料和用户确认信息。
同时,系统将信息真实性、缺失信息的判定、现场观察的事实认定、问题是否解决,以及合同是否合法或是否可以签署等事项保留给用户或相应专业主体,不交由模型自行决定。比较结果以信息状态、差异和待确认事项为依据,不生成权重评分、排名或唯一推荐。
2.5.3 创新点
RentMate 的创新主要体现在 Agent 与租房业务流程的结合,以及多来源信息的组织和管理机制,而非单纯调用大模型完成文本生成。
(1)多来源信息的证据分层管理。 将原始材料、Agent 提取的候选信息和用户确认后的有效信息分层管理。模型输出在用户确认前不会直接成为房源档案中的有效信息,且有效信息能够追溯对应的原始依据,降低自动提取错误对后续决策的影响。
(2)跨环节的信息关联与差异传递。 将房源介绍、现场观察、沟通承诺和合同内容纳入统一的信息管理流程,使来源差异、信息缺失和待确认事项能够进入后续比较与核对环节,减少不同阶段的信息割裂,帮助用户持续追踪需要核实的问题。
(3)受业务规则约束的 Agent 协作机制。 Agent 负责语言理解、信息提取和辅助分析,程序负责数据管理、状态控制和确定性规则,用户保留关键确认权。通过明确三方职责,使智能能力服务于具体业务目标,同时避免模型直接作出缺乏依据的判断。
(4)看房观察与房源档案的分离管理。 将每次实地看房作为独立记录保存,Agent 可以辅助整理现场观察并提出信息关联建议,但只有经过用户确认的信息才能进入房源档案。该设计既保留不同时间的现场记录,也避免一次观察未经核实便覆盖已有信息。
总体而言,RentMate 通过多来源证据链、跨环节信息管理和人机协作机制,将 Agent 的文本理解能力转化为可追溯、可确认、可持续管理的业务辅助能力。这些创新体现为面向实际租房场景的产品与业务流程设计。
2.6 项目可行性与实施计划
2.6.1 团队与技术条件
项目由三人协作完成,技术方案以常见的客户端与服务端协作架构为基础,结合关系型数据库、文件存储和大模型 API 实现业务管理与智能处理。具体交互载体尚待团队结合开发能力和部署要求确定,设计上优先适配手机使用,同时兼顾电脑端的查看与操作。
项目的技术可行性主要体现在:用户主动提供材料,减少对外部平台和实时数据的依赖;文本及数字版 PDF、Word 可以通过现有工具进行基础解析;材料解析失败时允许手动录入,不将模型识别率作为业务流程的唯一前提。此外,房源比较、信息状态和历史记录等确定性逻辑由程序实现,有利于保证结果可重复和可测试。
项目目前仍处于设计阶段,具体技术选型、模块实现和接口联调需要在开发过程中验证。可行性判断主要依据已收敛的功能范围、明确的业务边界和可回退的实现方案,而非将尚未完成的功能视为已有成果。
2.6.2 第一版的实现顺序
项目按照业务依赖和核心流程安排开发,优先建立可追溯的信息档案,再逐步接入看房、比较和签约前核对。
| 阶段 | 主要工作 | 阶段结果 |
|---|---|---|
| 1 | 用户空间、租房计划、房源管理、材料保存、候选信息抽取与确认、来源关联、信息状态及变化历史管理、差异提示 | 形成可追溯的房源档案 |
| 2 | 基础看房记录、清单与现场观察;比较方案、默认维度及自定义维度管理 | 跑通多来源信息整理、看房与多房源比较链路 |
| 3 | 沟通记录、承诺审核、十项合同对照及核对发现 | 跑通沟通承诺与合同核对链路 |
| 4 | 基础问题跟踪、信息追溯、虚构演示数据、异常回退、系统部署与测试 | 形成可供课程体验和答辩的完整系统 |
基础问题跟踪可以随业务流程逐步接入。区域推荐、截图 OCR 和复杂报告导出等后续功能不纳入上述开发阶段。具体时间安排根据课程进度和团队分工确定。
2.6.3 主要风险与应对
| 风险 | 主要原因 | 应对措施 |
|---|---|---|
| 第一版功能较多 | 房源管理、看房、比较和合同核对均纳入第一版 | 控制各模块实现深度,不扩展为图像识别、评分排名或全面合同审查 |
| 信息抽取不准确 | 材料格式、表达方式和上下文存在差异 | 保留原始材料,候选信息经用户确认后再入档,并提供手动录入方式 |
| 模型调用不稳定 | 摘要、信息提取和条款映射依赖外部模型 | 关键数据由程序持久化,模型失败时允许手工处理,不影响已确认信息 |
| 跨环节信息关联复杂 | 同一房源可能存在多来源、多阶段的信息及差异 | 以统一信息项和来源关系组织数据,优先完成核心关联与差异传递 |
| 演示效果不完整 | 完整业务链路需要多份材料和不同状态共同呈现 | 准备可重置的虚构样例,覆盖信息冲突、看房记录、沟通承诺和合同核对 |
| 隐私与法律风险 | 租房材料可能包含身份、联系方式和合同信息 | 使用虚构数据进行公开演示;限制数据访问,不输出合同是否合法、是否违约或能否签署等结论 |
团队完成第一版的关键,在于遵守已经确定的功能边界,优先保证两条核心业务链路完整可用,并将数据持久化、异常回退和端到端测试作为必要交付内容。
2.7 团队项目愿景
课程结束时,项目计划交付一个可在线访问的 RentMate 系统,供老师、助教和同学通过演示账号体验。系统将围绕第 2.4 节确定的第一版功能,实现租房计划与需求管理、房源档案、多来源材料整理、基础看房、多房源比较、沟通承诺审核、十项合同核对及问题跟踪等核心功能。
系统将重点展示两条完整业务链路:
- 多来源信息整理与房源比较: 用户导入多份房源材料,确认 Agent 提取的信息,记录看房观察并处理来源差异,最终对多套房源进行有依据的比较,区分明确不符合、待确认和存在差异等情况。
- 沟通承诺与合同核对: 用户审核沟通记录中提取的承诺,再按十项固定清单对照合同文本,查看相关摘录、信息差异和待核实事项,并保留处理结果,不输出法律结论。
除可运行系统外,项目还将完成课程要求的课堂答辩和项目博客,介绍项目背景、用户需求、产品方案、Agent 与程序的分工、核心业务机制及实际运行效果。
项目预期帮助租房者更系统地整理候选房源信息,减少看房遗漏、信息混淆以及沟通承诺与合同内容之间的核对成本。其核心价值在于通过多来源证据关联和跨环节信息管理,为用户提供可追溯、可确认的辅助信息,而非替代用户作出租房决策。系统不承诺房源信息真实、交易安全或签约建议,实际应用效果仍需通过后续用户测试进一步验证。
浙公网安备 33010602011771号