软件工程第一次团队作业（OfferPilot)
鹦伟达团队与 OfferPilot：从推免申请到大学生事项工作台
| 作业所属课程 | 202601 软件工程与软件工程实践 |
|---|---|
| 作业要求 | 2026秋软工实践团队作业——第一次（团队展示＋选题报告＋需求分析） |
| 作业的目标 | 通过用户调研明确服务对象和实际问题，完成团队组织、项目选题与需求分析，设计领域 Agent 的任务流程、知识来源和定制方式，并确定后续实现与验证的范围。 |
| 团队名称 | 鹦伟达 |
| 项目名称 | OfferPilot |
| 团队成员 | 魏之皓、刘谦益、王智钦、庄凯堃、杜玉鹤、陈常群、李义东、张锦昊、何慧渊、蔡信坡、佘博海，共 11 人 |
| 本文作者 | 102401608 魏之皓 |
| 项目仓库 | LotteryCamp / OfferPilot |
阅读导航 团队展示 · 选题调整 · 用户调研 · 产品规划 · 需求文档 · 技术方案
一、团队展示
1. 团队名称与由来
我们的团队叫 鹦伟达。
名称由来：PM低价买到英伟达5060心生爱慕故用此名。
本次团队项目为 OfferPilot。我们从大学生推免申请中的信息收集与材料准备问题出发，规划一款能够管理具体事项、理解官方要求并协助推进任务的 Agent 工作台。在老师指导和内部讨论后，项目开始探索竞赛、创新项目、奖学金与评优等相近场景，但推免仍是首个重点验证的方向。
鹦伟达团队成员合照
2. 成员风采
我们有 11 名成员，既有偏好前端与交互的同学，也有关注后端工程、领域资料和 Agent 应用的同学。下面从成员自己的性格、技术与兴趣介绍大家，再说明具体的工作安排。
| 学号 | 姓名 | 性格 | 擅长的技术 | 兴趣爱好 | 担任的软工角色 |
|---|---|---|---|---|---|
| 102401608 | 魏之皓 | 开朗，善于交流沟通 | Vibe Coding | 打球、看番、看小说 | 项目 PM；调研与策划 |
| 102401312 | 刘谦益 | 沉稳务实，执行力强，做事有条理，善于沟通 | Python 基础；HTML、CSS、JavaScript；基础算法与数据结构 | 篮球、乒乓球、游戏、听歌 | UI 与原型设计 |
| 102401609 | 王智钦 | 求真务实，行动力强，目标导向 | 大模型工程化与 Agent 应用 | 探索前沿 AI 工具与极客黑科技 | Agent 与模型应用开发 |
| 102401310 | 庄凯堃 | 严谨务实，喜欢深挖原理，乐于调研新技术 | Python、大模型应用开发、Agent 搭建 | 跑步、乒乓球 | Agent 与模型应用开发 |
| 162404109 | 杜玉鹤 | 内向、认真，行动力强 | C++ | 写小说 | 领域资料与效果评估 |
| 102401318 | 陈常群 | 内向，认真负责，注重细节，具有自主学习、问题分析与团队协作意识 | JavaScript、前端与 Web 页面开发、单元测试与缺陷排查；Git/GitHub 基本操作 | 羽毛球、跑步、听音乐、看动漫 | 前端开发 |
| 102401215 | 李义东 | 话不多 😃 | 未提供 | Minecraft | 后端开发 |
| 042402115 | 张锦昊 | 细心有耐心，善于沟通，主动钻研，责任心强，能理性交流并配合团队节奏 | HTML、CSS、JavaScript、Vue；Figma 原型还原；Git 版本管理与接口联调 | 逛技术社区、看交互设计作品、听音乐 | 前端开发 |
| 102401135 | 何慧渊 | 随和 | 配合 Agent 开展工作 | 探索未知 | 调研与策划 |
| 162404103 | 蔡信坡 | 待人温和，善于沟通 | 有条理地整理、核对信息 | 骑行游玩、研究钱币、欣赏花卉、游戏与逻辑谜题 | PPT、博客与展示材料 |
| 102401137 | 佘博海 | 细心务实，擅长梳理业务逻辑，愿意耐心排查问题 | Java、Spring Boot、MyBatis、MySQL；了解 AOP 与自定义注解 | 研究后端框架、算法刷题 | 后端开发 |
3. 团队愿景
我们希望通过本次项目，实践团队协作，完成需求分析、产品设计与软件开发。团队将从真实需求出发，打造便于使用的产品，并以贴合推免申请的工作流，为用户提供比通用大模型问答更有针对性的支持。
4. 团队分工与协作方式
团队按岗位划分主要责任，并围绕业务流程开展协作。魏之皓担任项目 PM，同时负责调研与策划，统筹需求边界、阶段安排和跨岗位沟通；何慧渊与其共同开展调研与策划工作。原型、前后端和 Agent 岗位据此推进产品设计与实现，领域资料和展示材料岗位分别支撑依据核验与成果表达。
| 工作方向 | 人数 | 成员 | 主要工作与交付 |
|---|---|---|---|
| 项目管理、调研与策划 | 2 | 魏之皓（项目 PM）、何慧渊 | 魏之皓负责统筹项目目标、阶段计划、任务跟进与跨岗位沟通，并参与问卷分析、老师反馈整理和需求优先级决策；何慧渊参与用户与场景调研，协助梳理推免及其他大学生事项的流程、问题和需求边界，整理待确认问题并跟进讨论结论。共同维护需求与策划材料，确保方案能够对应调研依据并转化为可执行任务。 |
| PPT、博客与展示材料 | 1 | 蔡信坡 | 汇总各方向的资料、方案与阶段成果，核对名称、数据、引用和版本；组织选题报告、PPT、团队博客与演示内容，将调研发现、产品决策和阶段成果以清晰一致的方式呈现，并根据实际进度更新展示材料。 |
| UI/UX 与交互原型 | 1 | 刘谦益 | 设计工作区、来源核对、任务计划和材料审阅的页面结构与操作路径；制作可交互原型，制定字体、颜色与组件规范；补全加载、空数据、待确认和异常状态，与前端核对还原效果。 |
| 前端开发 | 2 | 陈常群、张锦昊 | 实现事项列表、工作区、任务管理、资料查看和材料修改对照等页面；完成响应式适配、状态反馈、确认与撤销交互；对接业务与 Agent 接口，开展页面联调、单元测试和缺陷修复。 |
| 后端开发 | 2 | 李义东、佘博海 | 设计并实现工作区、来源、要求、任务和文件版本的数据结构与服务接口；处理身份权限、文件存储、状态持久化和操作记录；与 Agent 组约定工具调用接口，处理重复请求、执行失败与数据一致性，保证任务状态和材料版本能够可靠追踪。 |
| Agent 与模型应用 | 2 | 王智钦、庄凯堃 | 组织领域 Skills、任务拆解与工具调用流程，实现规则提取、候选计划、材料检查及局部改写；约定结构化输出、引用和授权范围；设计信息缺失时的追问、冲突暂停、执行校验和失败恢复。 |
| 领域资料与效果评估 | 1 | 杜玉鹤 | 收集官方通知、规则和附件，标注年度、对象、阶段与资料版本；核对资格自查和导师联系等关键结论的依据；整理人工核对基准、评估样本及失败案例，检查适用性、遗漏和事实一致性。 |
跨组协作围绕具体任务进行。例如，“导入一份通知并生成材料清单”需要项目 PM 与策划岗位明确用户目标和清单范围，领域资料方向核对原文及适用条件，Agent 岗位负责提取并形成候选任务，后端保存来源与结果，前端呈现核对和确认入口，UI/UX 岗位保证流程易于理解。各岗位共同参与测试与集成，发现问题后回到对应负责人修正并复核；AI 可辅助检查，但最终结果由团队确认。
二、项目起点与选题调整
1. 最初的问题：推免准备为什么费力
最初的调研聚焦推免申请。学生需要先了解本校资格与学院细则，再关注外校项目；每个项目可能有不同的时间、材料、格式和提交方式。通知往往分布在学校、学院、招生页面和附件中，单独找到某一条信息并不意味着已经知道接下来该做什么。
例如，学生找到一份夏令营通知后，还需要判断适用专业与批次、记录截止日期、准备成绩与经历材料、核对文件格式，并留意后续补充通知。原文没有变少，但核对和组织工作都落在了学生自己身上。
最初的产品设想因此聚焦于一项具体任务：协助学生把通知转化为能够执行的计划，并将计划与材料关联起来。
2. 老师反馈带来的两项关键修正
第一，申请准备不应从整理外校材料才开始。用户可能还不清楚本校资格条件、个人数据是否齐全，以及校内审核如何推进。软件需要将本校规则核对和资格初步自查纳入流程，但不能把辅助自查包装成学校正式认定。
第二，导师联系不能被写成统一的前置步骤。不同院校、学院和项目的要求并不相同。系统应查找具体项目的官方依据，再区分明确要求、官方建议、未提及或仍需核实，而不是默认“推免必须先找导师”。
这两项反馈让我们意识到：产品需要理解任务的条件和先后关系，而不只是从文档中提取几个日期与文件名。
3. 服务范围扩展与场景边界
在后续讨论中，我们发现竞赛报名、创新项目申报、奖学金和评优也可能面临类似的组织问题：依据分散的通知判断是否适用，准备多份材料，在不同阶段完成任务。
项目由此调整为 面向大学生机会与事项的 Agent 工作台。可以复用的是工作区、来源记录、任务依赖、材料版本和确认机制；不能直接复用的是各类事项的资格规则、流程节点与文书要求。
这也决定了扩展方式：推免作为首个重点场景，其他事项以独立模板逐步验证。现有问卷能够支持推免方向的需求判断，却不能替代竞赛或评优用户的调研。
三、用户调研与需求依据
1. 调研目标与样本说明
问卷主要回答三个问题：推免准备的负担集中在哪里；学生希望系统代为完成哪些操作；面对 AI 结果，他们需要怎样的核对与控制方式。下面选取五道与产品决策直接相关的题目展开分析。
基础信息和功能意愿题的有效回答为 42 份，部分推免相关题的有效回答为 38 份。各题按截图中的实际有效人数统计，不将不同分母混用。Q8 为多选题，各选项比例不要求合计为 100%。
样本中，大三学生 25 人，占 42 人的 59.52%；理工科学生 34 人，占 80.95%。因此，结果更适合帮助我们发现这一批受访者的需求线索，而不是代表所有大学生。问卷也不能证明每位受访者均已完整经历推免申请。
2. Q8：负担不只来自查信息，还来自把信息落实到材料
问卷结果｜公告收集 76.32% · 简历与陈述 65.79% · 格式核对 52.63%
38 份有效回答中，上述三项分别有 29、25、20 人选择。准备证明材料、跟踪截止时间与后续通知各有 15 人选择，均占 39.47%。
这道题提示我们，申请负担至少涉及三个相邻环节：寻找要求、按要求准备内容、核对准备结果。只汇总通知，用户仍要自己做材料；只提供润色，又无法确定改稿是否符合目标项目的要求。两者之间缺少的，是“这条要求对应哪项任务、哪份材料”的关联。
因此，工作区不能只有聊天记录或收藏链接。每条材料要求应关联原文依据、待办和文件版本；用户导入文件后，系统应指出哪些要求已有对应材料，哪些仍缺少信息。截止时间与后续通知也应挂到相应事项，而不是成为脱离上下文的提醒。
对功能的影响：首版优先围绕“要求—任务—材料”建立关联，而不是先做大而全的信息门户。本题为多选，无法据此判断某两项困难是否发生在同一个人身上；上述流程关系是产品设计判断，仍需通过具体任务观察核实。
3. Q10：跨校信息收集困难，关键是来源和适用性
问卷结果｜73.68% 感到跨校政策信息收集困难
38 人中，28 人表示想了解其他院校推免政策，但感到信息收集困难；10 人选择“否”，占 26.32%。这一结果为跨校官方信息整理提供了直接的需求线索。
但“找到网页”不等于“找到适用规则”。同一学校的校级简章、学院通知、具体项目和补充说明可能分别承载不同要求；往年页面即使仍能打开，也不一定适用于当年申请。若系统将这些内容压缩成一个没有出处的回答，搜索成本可能下降，误用信息的风险却仍然存在。
对应的产品设计应是先缩小范围，再提取结论：明确目标学校、学院、专业、年度和申请阶段，保留原始通知与附件，并让每项要求能够返回原文。只有历史资料时标明年份，存在冲突时并列显示来源，不能让模型自行选一个看似合理的说法。
对功能的影响：官方来源管理、适用范围筛选和原文定位应共同支撑检索结果。问卷反映的是受访者主观感受到的困难，政策检索的实际准确性仍需通过测试评价。
4. Q13：清单需求明确，但清单必须能被确认和执行
问卷结果｜32 人“非常需要” · 10 人“需要”
42 人中，76.19% 对输入院校名称、相关链接或材料后生成结构化清单表示“非常需要”，23.81% 表示“需要”。这使清单生成成为首版值得优先验证的能力。
不过，一张只包含“准备简历、提交材料”的列表，帮助仍然有限。实际执行还需要知道任务为什么存在、什么时候完成、依赖什么、由谁负责，以及什么证据能说明已经完成。学校通知中的报名截止时间，也不能不加区分地当成每份材料的准备时间。
因此，Agent 生成的应首先是可核对的候选计划：任务附带对应要求与来源，区分官方必需、官方建议、自主可选和待核实事项。用户确认后，计划才进入工作区；后续由任务状态、材料关联和依赖关系持续支撑，而不是每次重新问一遍模型。
对功能的影响：把“生成清单”升级为“提议计划—用户确认—推进任务”的流程。所有受访者都选择了正向选项，说明他们对题目描述的功能有兴趣，但不等于真实使用时都会采纳，也不能据此推断使用成效或付费意愿。
5. Q14：材料辅助需要结合目标要求，而非单纯润色
问卷结果｜88.10% 需要或非常需要材料检查与修改组合功能
42 人中，29 人表示“非常需要”，8 人表示“需要”，合计 37 人；另有 5 人认为“一般”，占 11.90%。
题目将缺项检查、格式检查和协助修改放在一起，结果说明整体功能组合有吸引力，但不能拆成每个子功能各有 88.10% 的支持率。
材料问题需要分开处理。缺少成绩证明属于完整性问题；要求 PDF 而上传 JPG 属于格式问题；经历写得分散属于表达问题。前两类可以依据清单和文件属性检查，第三类则需要理解用途和真实经历。若把它们都交给一次自由生成，容易得到语言流畅、却遗漏栏目或夸大事实的文本。
我们因此将材料能力设计为“先检查，再改写”：先对照目标要求列出差距，再确认个人信息和经历，最后按用户选择修改具体段落。没有提供的排名、成果数据和个人职责不能补写；缺少事实时应提问。改稿以新文件输出，并展示前后差异，用户可以逐项接受或拒绝。
对功能的影响：材料写作台既要交付文件，也要保留要求映射、事实确认与版本记录。首版优先处理能够可靠解析和导出的文档；复杂版式或扫描文件若无法可靠处理，应说明限制，不能以成功导出代替质量检查。
6. Q19：信任依赖可复核的结果，而不是准确率口号
这些回答说明，在申请材料与资格条件这样的任务里，错误成本会直接影响用户是否敢使用产品。尤其是姓名、截止日期、成绩与申请条件，一处错配就可能改变用户下一步的操作。因此，“用户最后看一遍”不能成为系统放松检查的理由，核对也不能只提供一个笼统的“确认无误”按钮。
复核需要具体对象：资格对照显示所用规则与个人数据；材料修改显示变化段落和事实来源；截止日期保留原文与适用阶段。缺少信息、不同来源冲突或解析不完整时，系统应停止形成确定结论，并告诉用户需要核实什么。
对功能的影响：来源追溯、待确认字段、修改对照和关键操作确认进入核心流程。40.48% 的“零容忍”反映的是用户期望，不是团队能够承诺绝对正确的依据；后续评估需要报告实际错误和人工复核成本。
7. 从调研结果到需求优先级
五道题分别影响不同层面的设计，不能简单理解为“票数多的功能全部加入”。我们优先考虑它们是否能连成一条可以完成的用户任务。
| 调研线索 | 对问题的判断 | 对应需求 | 优先验证内容 |
|---|---|---|---|
| Q8：信息、内容准备和格式核对均被较多选择 | 申请负担跨越多个环节，单点工具不足以衔接 | 关联要求、任务与材料的事项工作区 | 用户能否从一条通知走到完整材料清单 |
| Q10：28/38 人感到跨校信息收集困难 | 必须解决来源定位和规则适用问题 | 官方来源管理、年度与对象筛选、原文定位 | 是否引用了正确范围和版本的通知 |
| Q13：42/42 人对清单功能表示需要或非常需要 | 清单是明确入口，但需要转化为可执行计划 | 任务期限、依赖、确认和状态管理 | 清单能否被理解、确认并持续使用 |
| Q14：37/42 人对材料检查修改组合表示需要或非常需要 | 材料辅助需要同时理解要求、文件和事实 | 缺项诊断、局部改写、差异审阅和副本导出 | 文件是否符合要求，事实是否保持一致 |
| Q19：大量受访者要求准确或二次确认 | 结果必须具备可复核性和控制权 | 引用、冲突提示、事实确认与操作记录 | 用户能否发现、纠正并撤销问题结果 |
扩展到竞赛、创新项目和评优前，还需要分别了解参与者的实际流程和材料负担。可复用的工作区结构是一项设计假设，只有在第二类场景中验证后，才能说明它是否具备推广价值。
四、产品规划与核心流程
1. 产品定位与目标用户
OfferPilot 是面向大学生机会与事项的 Agent 工作台。它处理的不是所有日常待办，而是依据官方规则、需要跨阶段推进并准备文件的事项。用户提出目标或导入通知后，系统协助建立独立工作区，把规则、任务、材料与进度组织起来。
| 用户类型 | 典型问题 | 产品提供的支持 |
|---|---|---|
| 机会探索者 | 不知道是否适用，也不确定是否值得参加 | 核对适用条件，展示时间与投入，比较参加、暂缓或跳过的影响 |
| 事项执行者 | 已经决定参加，但容易漏掉步骤或材料 | 生成阶段计划，关联材料和依赖，集中处理待确认问题 |
| 竞赛或项目团队成员 | 多人分工下，责任和材料版本容易混乱 | 在授权范围内共享任务、负责人和材料审核状态 |
推免用户是首批重点服务对象。后续面向其他用户扩展时，需要为不同事项建立独立的流程模板，并核验各自的官方依据。
2. 核心形态：一事一工作区
同一个学生可能同时关注推免、比赛和评优，但这几件事不能混在一张没有上下文的待办表里。每个工作区围绕一个明确目标组织六类内容。
| 工作区区域 | 主要内容 | 用户应能完成的操作 |
|---|---|---|
| 事项概览 | 主办单位、年度、对象、当前阶段与关键日期 | 判断是否进入了正确事项，定位官方入口 |
| 来源与条件 | 通知、附件、规则版本、适用范围与条件状态 | 查看原文，对有疑义的结论发起核实 |
| 阶段与任务 | 依赖、负责人、截止时间、状态与完成依据 | 确认计划，调整进度，处理被阻塞任务 |
| 材料写作台 | 要求清单、文件版本、个人事实与修改差异 | 补充事实、局部改稿、审阅并导出副本 |
| Agent 待处理 | 缺少的信息、建议动作、执行结果与待批准事项 | 回答追问、批准或拒绝动作、停止处理 |
| 归档记录 | 用户确认的提交版本、结果与可复用材料 | 回看具体版本，将授权材料用于后续事项 |
工作区需要持续保存状态。用户离开后重新进入，系统仍应知道哪份文件已确认、哪条规则有疑问、下一步被什么条件阻塞，而不是只保留一段越来越长的对话。
3. 推免流程：资格自查与外校申请分开管理
- 确认规则。核对本校规则、年度与适用范围。
- 补充数据。由用户提供并确认个人信息与相关证明。
- 资格自查。逐项对照条件，显示已核实结果与待核实问题。
- 跟踪校内流程。按实际通知记录审核、补交或公示节点。
- 建立外校申请。分别管理目标院校与具体项目，核验导师联系要求，准备阶段任务和材料。
- 检查与提交。用户检查后自行完成官方提交。
这个示意不代表所有学校具有完全相同的步骤与时间顺序。校内资格与外校项目可能并行准备，各节点以具体学校、学院和项目当年的官方通知为准。
资格自查逐项显示已核实条件、当前数据和缺项。规则明确且数据齐全时，可以做可复核的对照；涉及学院裁量、规则歧义或缺少数据时，结果停留在待补充或需人工核实。最终资格以学校正式认定为准。
导师联系判断针对具体项目给出四类结果：明确要求提前联系、官方建议联系、已核验通知未提及、来源不足或冲突。用户选择联系后，系统可以整理问题、准备基于真实经历的邮件草稿和跟进任务；首版不代发邮件。
外校申请管理按院校、学院、项目和批次分别维护要求。夏令营、预推免和正式申请不能直接共用一份未经核对的材料清单，通用材料可以复用，但每次都需要检查目标要求和版本。
4. 可选事项建议：说明取舍，不替用户决定
并非所有有益事项都必须做。用户可能需要在比赛、课程、项目和申请准备之间分配时间，系统应先区分官方必需、官方建议、自主可选和待核实事项，再讨论优先级。
例如，用户询问是否参加一项比赛时，Agent 应核对参赛条件、截止时间、团队要求和预计成果，结合用户自己提供的时间安排说明冲突。建议需要列出依据、投入、可能收益和不确定性，提供采纳、稍后决定或跳过的选择，不用一个缺乏验证的“含金量分数”代替判断。
如果某项经历是否计入推免评价尚无官方依据，系统应直接标明未知，不能以“通常有帮助”将其升级为资格要求。
5. 材料写作：既能动笔，也能守住事实
用户不必先写好一份完整简历才能获得帮助，但需要提供真实信息。材料写作台先读取目标要求和原稿，形成信息缺口清单，再根据已确认的教育背景、项目职责、成果和时间组织内容。
以简历修改为例，处理流程为：
- 导入与诊断。读取原稿和目标要求，定位缺项、格式与表达问题。
- 确认事实。用户回答必要追问，选择需要修改的段落。
- 生成与审阅。生成建议稿，展示前后差异，核对事实、栏目和跨材料一致性。
- 接受与导出。用户接受修改后导出新文件，保留原件。
“表达更专业”不能改变身份和成果。参与者不能自动写成负责人，计划不能写成已完成，未提供的成绩、排名、奖项和成果数字不能根据常见写法填入。对姓名、成绩、日期、职责等关键字段，应能查看其采用的事实记录。
首版拟优先支持 DOCX 编辑与导出，PDF 用作要求或原稿参考。对扫描件、复杂表格、公式和特殊版式，应先确认处理能力；无法可靠保留结构时提供限制说明与可审阅文本，不声称已经无损修复。
6. Agent 如何真正推进事项
Agent 需要读取当前工作区，选择可用工具，执行获准动作，再检查动作是否完成。一次处理可以从官方通知中提取要求、生成候选任务、建立材料关联，也可以在用户上传新版本后重新检查缺项。
| 场景 | Agent 的实际动作 | 交付给用户的结果 |
|---|---|---|
| 导入官方通知 | 读取正文和附件，提取条件、时间、材料并绑定引用 | 有来源依据的要求表与候选任务 |
| 个人信息不完整 | 定位影响判断的缺少字段，提出针对性问题 | 明确的信息缺口，而不是猜出的资格结论 |
| 用户上传材料 | 对照要求检查，组织事实与修改建议，生成副本 | 可审阅的差异、缺项清单与新文件 |
| 官方通知更新 | 比较版本，定位变化条款及关联任务 | 变更说明和候选调整，等待确认后写入 |
| 任务受阻 | 检查前置条件和材料状态，重新提出下一步 | 被阻塞原因与可执行的处理选项 |
操作记录展示具体动作、采用的依据、变更对象和执行结果。用户应能暂停处理、拒绝建议，并恢复可撤销的内部变更。
7. 首版范围与后续扩展
首版规划为“通用工作区基础能力＋一个推免试点＋一个非推免模板”。推免试点选择能够取得正式规则的学院或专业，非推免模板从团队能获取完整官方资料的竞赛或评优事项中选择，不预先宣称覆盖全国高校和所有事务。
| 阶段 | 功能范围 | 进入下一阶段的条件 |
|---|---|---|
| 首版核心 | 来源导入、条件核对、候选计划、材料检查修改、确认与副本导出 | 一项真实规则驱动的任务能够从导入走到人工确认 |
| 双场景验证 | 复用工作区结构，独立配置推免与非推免模板 | 第二类事项不依靠硬套推免规则也能完成流程 |
| 后续增强 | 通知变化提醒、日历导出、多人审核和更多事项模板 | 已有流程的质量和权限控制稳定，新增资料可核验 |
产品不提供录取概率预测，不替学校认定资格，不自动登录官方系统报名或提交，也不以生成材料的方式补造经历与证明。
五、需求分析文档
需求规格说明书（SRS）把产品设想收敛为可设计、可开发、可测试的需求基线。它既说明系统应提供什么能力，也明确哪些情况不能由系统擅自判断或代办。文档参考 GB/T 9385-2008 的需求规格说明书组织要求，供项目负责人、领域知识负责人、前后端开发和测试验收共同使用；后续方案变更应回到这份基线核对影响，而不是只靠聊天记录传递。
1. 首版边界：先把推免申请辅助做成闭环
博客前文讨论了将工作区扩展到竞赛、创新项目和评优等场景，这是产品的后续方向。当前 SRS 则将首版收敛在推免申请者的信息整理与自查工作台：先验证官方要求、个人信息、准备任务和申请材料能否形成可靠闭环，再评估通用工作区能否迁移到其他事项。现有推免调研可以支持首版问题定义，但不能代替对竞赛、评优用户的独立调研。
| 纳入首版需求基线 | 明确不由系统代办 |
|---|---|
| PC Web 工作界面；关注院校及项目的官方通知与附件；记录来源版本并识别内容变化 | 不替用户向院校或外部系统提交报名、申请或投递 |
| 按院校、学院、项目和年度整理适用条件、材料要求及时间节点 | 不自动填写第三方网站表单，也不绕过网站安全措施或访问控制 |
| 将要求关联到个人档案、材料清单、差距项和任务时间线，支持用户逐项自查 | 不采集或保存与推免准备无关的个人敏感信息 |
| 为解析结论保留原文证据、置信状态和人工复核入口 | 不把模型生成的结论当作学校正式资格认定 |
这个边界尤其影响“保研资格初步认定”和“是否需要提前联系导师”两类问题。系统可以依据已确认的校内规则和具体项目通知进行条件对照，展示所用数据、原文出处和缺失项；若规则不完整、学院口径存在差异或通知没有明确说明，就应显示“无法判断”或“需人工核实”，而不是给出确定结论。资格最终以学校正式认定为准，导师联系要求则以目标项目当年公开通知为准。
2. 需求围绕一条可追溯的业务链组织
SRS 不把“接入大模型”本身当作需求终点，而是描述用户如何从一份分散的官方材料走到可检查的行动清单：
登记官方来源与适用范围
→ 保存通知、附件及版本快照
→ 提取要求并关联原文证据
→ 对照个人档案，标记已满足、缺失或待核实
→ 生成材料清单、差距项与时间线任务
→ 用户补充信息并复核关键结论
→ 通知更新时比对变更，提示受影响的任务和材料
因此，需求对象之间必须能互相追溯：一条要求来自哪份通知的哪个版本，适用于哪个院校项目；它关联了哪些材料和任务；当通知更新后，哪些已有判断需要重新检查。只展示一段摘要或一串聊天回复，无法支撑后续核对和变更处理。
| 业务对象 | 在需求中的作用 | 需要保留的信息 |
|---|---|---|
| 来源、通知与快照 | 说明规则由谁发布、适用于什么范围以及何时更新 | 发布主体、年度与范围、原始链接、正文或附件、版本时间 |
| 结构化要求与证据引用 | 把自然语言规则变成可检查的条件，同时保留依据 | 要求类型、原文位置、解析状态、置信度及复核状态 |
| 个人档案与差距项 | 将用户已确认的信息与适用要求逐项比较 | 数据来源与更新时间、缺失字段、对照结果和待确认原因 |
| 材料清单与时间线 | 将要求转成可以推进和检查的准备工作 | 材料状态、截止日期、前置依赖、完成依据及关联要求 |
| 领域知识包 | 维护推免术语、规则口径和可复用的核验知识 | 适用场景、来源、版本、审核人及变更记录 |
3. Agent 的职责是推进流程，关键判断须可复核
需求把 Agent 约束为一个有明确阶段和权限边界的执行体，而非可以自由处置用户资料的通用聊天窗口。它按照“读取工作区状态—检索适用知识—提取候选信息—执行确定性校验—生成待确认结果—记录操作”的顺序工作。模型负责理解通知语义、归纳材料要求和提出针对性追问；日期换算、字段完整性、规则适用范围和状态变更等可确定部分由校验逻辑处理。
| 情况 | 系统应有的行为 |
|---|---|
| 来源版本明确、适用范围匹配 | 展示解析结果、原文位置和关联任务，供用户检查 |
| 个人档案缺少影响判断的数据 | 说明缺少什么、影响哪项判断，并请求补充，不自行填值 |
| 官方信息互相冲突或来源过期 | 暂停结论，列出冲突来源与日期，转交人工核实 |
| 解析置信度不足或涉及规则解释 | 标注不确定性并进入复核队列，不以 Agent 自我复核代替放行 |
| 新通知影响已有清单 | 展示新旧条款差异及受影响的任务，确认后再更新业务状态 |
领域知识负责人负责审核重要政策口径、纠正解析结果并沉淀知识。修订应能追踪、回滚并说明生效范围。Agent 的每项实质性输出都应留下依据、输入状态、所执行的动作和结果；用户可以拒绝建议或暂停处理。这样的要求使“人工复核”成为业务流程的一部分，而不是结果页上的免责声明。
4. 从需求编号走到验收条件
文档以 FR-x.y 标识功能需求、以 NFR-x.y 标识非功能需求，并为可验证行为补充验收条件（AC）。例如，“通知解析结果可追溯”不能只写成一句原则，还需要验收：结果中的每条结构化要求都能定位到来源版本及原文片段；来源失效或无法定位时，系统不得显示为已核实。随后通过需求追踪矩阵把需求编号连接到设计、实现与测试用例，便于检查遗漏和评估变更影响。
对资格规则、材料要求和异常分支等高风险能力，还需使用经人工核对的金标准样例进行评测，并将回归门禁纳入迭代流程。模型更新、知识包变更或解析逻辑调整后，应重新运行对应样例；关键错误未达到团队设定的放行标准时，不应把结果静默推送为正式要求。具体阈值和样例规模仍需在实现阶段结合资料范围确定，不能在需求尚未验证时虚报准确率。
上述安排把调研中反复出现的信息分散、材料准备和准确性顾虑，转化为来源追踪、差距管理、复核与回归要求。需求文档提供的是系统行为和验收依据，不等于所有能力已经完成实现；多事项工作区仍属于产品演进方向，须在后续场景调研和试点验证后再纳入对应版本。
详细功能规格与用例见：OfferPilot 需求分析文档。
六、初版技术方案
1. 职责分层：模型负责理解，业务系统维护状态
初版拟采用 PC Web 形态。用户在浏览器中管理多个事项、核对原文和审阅文件；后端负责保存业务状态与版本；Agent 编排层根据任务调用领域工具；资料与规则层提供可核验的依据。具体框架、数据库和模型服务仍需结合原型验证与部署条件确定，下面描述的是职责和处理流程。
PC Web 交互层
工作区 / 来源核对 / 任务计划 / 材料审阅 / 授权确认
↓
业务服务层
身份与权限 / 事项与任务 / 文件版本 / 操作记录 / 导出
↓
Agent 编排层
读取状态 → 选择能力 → 调用工具 → 校验结果 → 确认或暂停
↓
领域与工具层
官方资料 / 规则模板 / 检索解析 / 条件校验 / 文档处理
这是一种职责划分，不要求每层单独部署。首版可以先以模块实现，避免为追求复杂架构增加联调成本。任务状态、截止时间和用户确认记录由业务服务维护；模型不能仅凭一段自然语言就把任务改成“已完成”。
2. 业务数据与来源关联
只保存通知摘要不足以支撑后续核对。初版数据需要能够表达“某项要求来自哪个版本的哪段原文，又影响哪些任务与材料”。
| 对象 | 关键字段 | 关联作用 |
|---|---|---|
| 事项工作区 | 类型、目标、年度、所属用户或团队、阶段 | 限定任务、资料与文件的业务范围 |
| 来源版本 | 发布单位、适用范围、日期、原始链接、附件与版本标识 | 保留引用依据，支持历史对照 |
| 要求条目 | 要求类型、义务性质、原文定位、复核状态 | 连接规则判断、任务和材料 |
| 任务 | 前置依赖、负责人、期限、状态与完成依据 | 支撑推进计划和阻塞判断 |
| 材料版本 | 原件关联、生成版本、适用要求与确认状态 | 防止跨事项误用、覆盖或混用文件 |
| 个人事实 | 内容、来源、用户确认记录与可用范围 | 为材料写作提供可追溯的事实底稿 |
| 执行记录 | 工具、输入输出引用、授权范围、结果与错误 | 支持结果复查、重复执行控制与恢复 |
规则状态与任务状态分开存储：某条条件“符合已核实条件”不代表相应材料已经提交，任务“已完成”也不证明学校已认可资格。跨对象更新应保留关联与确认记录。
3. 领域知识来源与检索流程
推免资料按层次整理：国家层面的正式说明、本校校级办法、学院或专业细则、目标院校项目通知，以及相应附件和补充通知。竞赛和评优则分别维护主办方规则与校内流程，不混入统一的推免知识集合。
拟议检索流程为：
- 确认事项类型、学校或主办方、学院、专业、年度和阶段。
- 在适用范围内筛选资料，再检索与问题相关的条款。
- 提取条件、时间、材料与例外，保存原文位置和来源版本。
- 检查关键字段是否缺失，相关资料是否存在冲突。
- 输出附带引用的结构化结果，或转为待核实问题。
模型负责理解和提取，程序检查字段类型、日期、枚举与必填项；能够明确表达的计分规则交给程序计算，并显示采用的数据。存在裁量或无法确定口径的条款不强行转成公式。
网页与附件中的文字作为资料处理，不应改变系统权限或工具边界。资料下载失败、附件缺页或只能找到转载时，应保留状态并提示核实，不能用模型记忆填补成现行官方规则。
4. 专用 Skills 与执行控制
首版采用版本化资料、事项模板和专用 Skills 进行领域定制，为每项能力规定输入、工具、输出结构与停止条件。规则更新时替换相应版本，执行异常时定位到具体步骤；是否需要模型微调，留待现有方案的评估结果决定。
| 专项能力 | 输入与处理 | 输出约定 | 暂停条件 |
|---|---|---|---|
| 通知解析 | 读取已定位的官方正文与附件 | 来源、条件、阶段、材料、日期与引用 | 缺页、适用范围不明或冲突 |
| 条件自查 | 对照已复核规则与用户确认的数据 | 逐项状态、计算过程与缺少字段 | 规则含糊、数据缺少或需要学校裁量 |
| 计划编排 | 根据要求、期限和现有进度组织任务 | 候选任务、依赖与义务性质 | 用户目标或时间约束不清 |
| 材料处理 | 结合要求、原稿与事实底稿诊断和修改 | 局部草稿、差异、检查项与副本 | 事实冲突、授权不足或版式无法可靠处理 |
| 变更分析 | 比较来源版本与已有工作区 | 变化条款、受影响对象与候选调整 | 无法确认更新有效性 |
编排器先读取工作区状态，再选择能力并验证输出。简单任务由一次工具流程完成，只有确有独立职责和复核价值时才增加专项 Agent，不让多个模型反复改写同一份数据。
执行状态拟统一为“待确认、执行中、成功、失败、已取消”。写入任务或生成副本前检查授权；同一次请求重复到达时，业务服务应避免重复建任务或重复创建文件。工具超时与失败返回明确原因，允许在原状态上恢复，不将失败描述为成功。
5. 文件修改、权限与隐私
文件处理采用原件只读、修改生成副本的方式。文档解析后先形成可审阅结构；改写内容与个人事实、目标要求关联；导出前检查必填栏目、关键字段和版本。输出文件还需验证能否正常打开，不能只确认接口返回成功。
用户可以授权内部整理、草稿和副本生成，但授权应限定工作区、文件和动作范围。首版不提供自动报名、正式提交或对外代发功能。工作区成员按权限访问文件，不默认共享成绩、联系方式和证明材料。
真实材料是否传入外部模型服务，需要先明确服务的数据处理方式并取得用户同意。开发与演示优先使用明确标注的合成资料或脱敏副本；上线前需落实保留期限、删除入口和访问控制，不能仅用一份隐私说明替代实现。
6. 质量验证与验收设计
评估以任务完成质量为核心。拟对同一组官方文件设置人工整理、通用大模型和 OfferPilot 三种处理方式；统一输入与评分口径，记录正确项、遗漏、错误、人工接管和处理时间。
| 验证方面 | 重点检查 | 结果记录方式 |
|---|---|---|
| 规则提取与适用 | 条件、例外、日期、年度和对象是否正确 | 对照人工复核条目，记录错项与漏项 |
| 来源追溯 | 引用是否指向正确文件、版本和段落 | 逐条核对关键结论的原文依据 |
| 清单与依赖 | 必需材料是否遗漏，前置关系是否合理 | 用完整任务流程检查计划可执行性 |
| 事实与文档 | 改写是否保持已确认事实，差异是否准确 | 核对关键字段、导出文件和原件状态 |
| 执行与权限 | 工具是否完成动作，拒绝或取消是否生效 | 检查执行记录、授权范围和恢复结果 |
| 使用效率 | 用户是否真正减少整理与核对负担 | 同时记录任务耗时、错误和复核成本 |
异常用例需要覆盖过期政策、学院错配、附件缺失、个人数据不足、事实冲突、工具超时和重复请求。材料用例应包含没有提供排名、缺少职责说明或日期相互矛盾等情况，检查系统是否追问与暂停，而非补写事实。
推免试点之外，还需要用同一套工作区机制验证一个非推免模板。评测前确定样本与通过标准，评测后保留失败案例、模型版本、规则版本和耗时记录，分别比较规则适用、任务推进与材料处理的表现。
浙公网安备 33010602011771号