AgentX团队——2026秋软工实践第一次团队作业

作业所属课程	H202601 软件工程与软件工程实践
作业要求	2026秋软工实践团队作业-第一次（团队展示+选题报告+需求分析）
作业的目标	通过真实用户需求调研，确定项目选题与服务对象，设计领域 Agent 的任务流程、知识来源及定制方法，并完成软件需求分析，为后续开发、测试和上线做好准备。
团队名称	AgentX
团队成员学号-名字	102401125罗宇泽、102401228林彦翔、112400810雷葭雨、102401209洪添军、102401126林世颖、102401114颜俊宇、112401237吴诗莹、102401533丁晓炜、102402136王智洋、102401216吴欣键、102401213薛锦荣、102401231赵紫龙

前言

所有人，请先欣赏我们团队的吉祥物——超级无敌雷霆大奶龙！！！

它大概有20cm高，是我目前打过的最大的奶龙。

一、团队展示

1.1 团队名称与项目简介

团队名称——AgentX

AgentX 由 “Agent” 与 “X” 两部分组成。“Agent”代表智能体，体现了团队对人工智能技术的关注，以及通过智能体将大模型、领域知识与实际应用场景相结合的探索方向。“X”则象征未知、探索与无限可能，寓意团队勇于尝试新技术、突破固有思路，并通过成员之间的协作探索智能体的更多应用价值。

我们选择 AgentX 作为团队名称，希望以简洁、有科技感的名字表达团队的技术方向与创新精神。我们不局限于单一模型或某项具体功能，而是希望在持续学习、实践与迭代中，将创意转化为真正可用的软件产品，为用户解决实际问题。

AgentX，探索智能边界，让创意落地。

其实还参考了马圣的SpaceX

项目名称——CodeMind-FZU

CodeMind-FZU 是一款面向福州大学计算机与大数据学院（软件学院）本科生的校园事务与发展信息智能助手，重点服务大一至大三学生。

项目围绕五大功能方向展开：政策与事务办理、升学与就业发展、学院资源导航、竞赛与科研信息、个人成长档案与长期规划。团队希望通过官方资料检索、来源展示和 Agent 任务处理流程，帮助学生更高效地获取与自身情况相关的信息，并提高信息查询的针对性与可信度。

1.2 团队成员风采

我们团队由12名成员组成，成员将结合各自的专业能力与兴趣，参与需求分析、产品规划、Agent 设计、知识库建设、原型设计和项目展示等工作。

1.3 团队首次合照

合照摄于10.24日软工实践课下课后，感谢朱同学帮忙拍摄。

1.4 团队愿景

我们AgentX 团队希望通过 CodeMind-FZU，帮助福大学生解决校园事务与发展信息分散、查询不便、缺少个性化指导等问题，让信息获取更加高效、可靠。团队也希望在项目实践中提升需求分析、智能体开发、软件工程协作与测试能力，将创新想法逐步转化为真正解决用户需求的软件产品。

1.5 团队成员分工

为保证项目能够有序推进，团队根据任务性质划分为项目管理组、产品需求组、Agent 方案组和技术展示组。

但我们组并非按照“一个萝卜一个坑”式的分工，而是每个人根据自身擅长的领域以及所能承担的工作量来分配，一个人可以同时负责好几块的不同的内容，多劳多得。

各组围绕统一的项目目标协作推进，并通过阶段性评审保证需求、技术方案、原型设计和项目文档之间的一致性。

二、项目选题报告

2.1 项目背景与选题原因

随着高校校园事务与学生发展相关信息不断增加，学生在了解竞赛认定、奖学金申请、科研机会和升学政策时，可能需要在学校、学院及其他官方渠道之间查找和核对资料。

通用大模型虽然能够回答一般性问题，但对于特定学校、学院及具体年度的政策要求，仍需要结合可靠的领域资料进行检索和核验。

因此，团队计划面向福州大学计算机与大数据学院（软件学院）本科生，重点服务大一至大三学生，探索将领域知识、智能检索和 Agent 任务流程相结合，为学生提供更有针对性的校园事务与发展信息服务。

2.2 用户需求调研

2.2.1 调研目的

本次调研旨在了解福州大学计算机相关专业学生在获取校园事务与发展信息时遇到的实际困难，了解他们对信息可靠性、个性化建议及不同功能方向的关注程度，为 CodeMind-FZU 的功能取舍和首版范围提供初步依据。

本次调研属于小样本探索性调查，结果用于辅助项目设计，不应直接推断为全体福大学生的总体意见。

2.2.2 调研方法与样本说明

• 调研方式： 问卷调查。
• 调查对象： 福州大学计算机相关专业学生。
• 有效样本： 84 份。
• 调研时间： 2026 年 10 月。
• 统计口径： 痛点与顾虑题按各选项被选择的人数统计；功能重要程度按五分制平均分统计；“最需要优先实现的功能”按单选结果统计。

本节只采用当前材料中已确认的 84 份问卷统计。现有汇总材料明确记录大二学生 44 人，占52.38%；大三学生 32 人，占 38.10%；大一学生8人，占9.52%。未获得明确统计依据的题项不补填、不估算。

2.2.3 调研结果

（1）学生遇到的主要问题

“主要遇到的问题”为多选题，各项比例分别以 84 份有效问卷为分母，因此各项比例不要求相加为 100%。

主要问题	选择人数	占有效样本比例
信息分散，不知道从哪里寻找	64/84	76.19%
缺少针对年级和专业的建议	52/84	61.90%
缺少过来人的经验参考	52/84	61.90%

结果显示，信息分散是本次调查中最突出的已记录痛点；缺少针对年级、专业的建议以及缺少过来人经验参考，也受到较多受访者关注。

（2）学生对信息可靠性的顾虑

“最担心的方面”是另一道题，不能与“主要遇到的问题”混为同一题统计。

顾虑	选择人数	占有效样本比例
担心信息不准确	64/84	76.19%

这一结果说明，项目不能只追求快速返回答案，还需要重视信息来源、政策版本和适用范围的说明。该数据反映的是受访者的主观顾虑，不等同于对某个现有系统准确率的实测结果。

（3）五大功能方向的重要程度

受访者对五大方向的重要程度进行五分制评分，当前汇总结果如下。

功能方向	重要程度平均分（满分 5 分）
升学与就业发展	4.43
学院资源导航	4.38
竞赛与科研信息	4.29
政策与事务办理	4.10
个人成长档案与长期规划	4.00

从平均分看，升学与就业发展、学院资源导航、竞赛与科研信息的评分相对较高。不过，平均重要程度评分与“最需要优先实现的功能”单选结果代表不同含义，不能互相替代。

（4）受访者最希望优先实现的功能

“最需要优先实现的功能”为单选题，按 84 份有效问卷统计。以下保留当前汇总材料中的选项名称与统计口径。

问卷原始选项	选择人数	占有效样本比例
保研/升学规划	36/84	42.9%
学院资源导航	16/84	19.1%
个人成长档案	16/84	19.1%
竞赛推荐备赛	8/84	9.5%
奖学金/事务清单	4/84	4.8%
相关消息推送	4/84	4.8%
科研机会推荐	0/84	0.0%

保研/升学规划是单选题中获得选择最多的选项。学院资源导航与个人成长档案分别获得 4 人选择。需要注意，问卷原始选项与项目统一后的五大功能方向并非完全一一对应，因此在将这些结果映射到产品功能时，应保留原始选项及其统计口径，避免把不同概念直接视为同一指标。

2.2.4 需求分析结论

结合当前已确认的问卷结果，可以形成以下初步需求判断。

调研证据	对产品设计的启示	当前结论边界
64/84（76.19%）受访者选择“信息分散，不知道从哪里寻找”	提供统一查询入口，并优先整理有官方来源的校园事务与发展资料	支持将信息整合列为重点方向，不代表所有校园信息都已收录
52/84（61.90%）受访者选择“缺少针对年级和专业的建议”	在必要时询问年级、专业、目标等背景条件，并据此组织更有针对性的解释	个性化建议的有效性仍需在后续原型和测试中验证
52/84（61.90%）受访者选择“缺少过来人的经验参考”	后续可评估是否引入经过整理、标明来源的经验参考材料	经验材料的收集、审核和首版纳入范围尚待确认
64/84（76.19%）受访者担心信息不准确	回答应尽可能展示来源，并核对资料版本与适用范围；证据不足时明确说明限制	问卷反映的是用户顾虑，不能作为系统准确率已经提升的证据
升学与就业发展重要程度为 4.43/5，且“保研/升学规划”在优先实现单选题中占 42.9%	优先评估有官方政策依据的推免与升学信息查询场景	这支持优先验证该方向，不意味着完整的个性化升学规划已能在首版交付
学院资源导航重要程度为 4.38/5，单选优先项占 19.1%	将学院资源与培养相关官方资料查询作为重要功能方向	具体资料覆盖范围仍受知识库建设进度限制

总体而言，当前调研为项目的几个设计重点提供了初步依据：整合分散信息、关注回答可靠性、在必要时收集用户背景，以及优先验证升学相关查询。由于样本量为 84，且大二、大三学生合计占 90.48%，结果具有探索性；后续仍应结合更多用户反馈、实际资料覆盖情况和系统测试来修正需求优先级，不能将本次结果直接推广为全体福大学生的普遍结论。

2.3 目标用户与使用场景

2.3.1 目标用户

项目主要面向福州大学计算机与大数据学院（软件学院）本科生，重点服务大一至大三学生，尤其是需要查询校园政策、升学要求、学院资源、竞赛科研信息及个人发展相关资料的学生。

2.3.2 典型使用场景

当前优先研究的典型场景为：

“某项竞赛在学院的认定类别是什么？”

用户输入竞赛名称及必要的查询条件后，系统检索相关官方资料，尽可能返回认定类别、适用规则和来源依据；如果没有找到足够可靠的证据，则明确提示无法确认。

该场景用于验证系统的信息检索、证据核验与回答生成能力。后续功能范围将结合调研结果、资料覆盖情况和技术可行性逐步确定。

2.4 项目规划与核心功能

2.4.1 项目总体规划

项目计划采用 Web 软件形式，为用户提供统一的信息查询入口，并通过领域资料检索和 Agent 任务处理实现针对校园事务与发展问题的回答。

2.4.2 核心功能规划

结合前期需求调研、项目定位及知识库建设方向，CodeMind-FZU 初步规划五大功能方向。

功能方向	功能说明	计划范围
政策与事务办理	查询奖学金、评优评奖及其他校园事务的申请条件、材料要求、办理流程和注意事项	v1.0 优先支持有官方资料依据的查询
升学与就业发展	查询推免、升学及相关发展政策，整理阶段性准备事项	v1.0 优先支持官方政策查询；个性化规划逐步迭代
学院资源导航	查询培养方案、学院资源、办事渠道及本科生可用的学习科研资源	v1.0 优先支持资料查询与导航
竞赛与科研信息	查询竞赛认定规则、科研实践资料及相关机会信息	v1.0 优先支持已有官方资料的查询；动态机会筛选后续完善
个人成长档案与长期规划	在用户主动提供信息的基础上，整理阶段目标、成长经历并辅助制定后续计划	后续迭代方向，不作为 v1.0 的必要交付

需要区分业务功能与共用技术能力：自然语言问答、任务识别、领域知识检索、来源展示、证据核验和必要追问，是支撑上述功能方向的通用能力，并非额外替代这五大业务方向的功能模块。

首版将优先打通“提出问题—必要时追问—检索官方资料—组织回答—展示来源或提示证据不足”的核心闭环。五大功能方向属于整体规划，不意味着所有功能都会在 v1.0 中完整实现；最终范围以团队确认的需求分析文档和实际测试结果为准。

2.5 领域知识库与 Agent 的定制思路

项目计划围绕福州大学计算机与大数据学院（软件学院）的校园事务与学生发展信息建设领域知识库，并通过 Agent 将用户问题、资料检索、证据核验和回答组织连接起来。知识库负责提供可检索、可追溯的资料依据，Agent 则根据用户任务选择相应的处理流程。

2.5.1 领域知识来源与分类

知识库重点服务大一至大三本科生，资料优先来自福州大学及学院官方网站，包括正式发布的政策文件、管理办法、培养方案、学期通知、年度通知和办事指南等。

截至当前阶段，知识库已登记 44 条资料。统计口径为：按政策或通知事项计一条，网页与其附件合并计算；仅发现但尚未收录的链接不计入。

资料类别	数量	主要内容
学籍与学生事务	4	学生管理、学籍自查、学生证等相关事务
课程考试与教务办理	13	选课、考试、重修、辅修、转专业等
综评与奖学金	6	本科综评、校级及学院奖学金等
竞赛认定与创新学分	7	竞赛等级认定、创新创业学分等
培养方案与学位要求	8	学位细则、专业培养方案等
科研实践与实验室	2	科研实践项目、实验室相关机会等
推免与升学	4	推免办法、推荐方案及相关参考资料
合计	44	按政策或通知事项统计

2.5.2 资料整理与当前核验状态

为了让资料后续能够被检索和核对，团队为每条资料登记官方来源和本地资料记录，并记录发布日期、适用范围、正文提取情况及核验状态。

目前的建设情况如下：

• 资料登记： 44 条资料均已完成来源和本地资料记录登记。
• 正文提取： 43 条已提取正文；另有 1 条扫描版高水平科创奖励办法仍待 OCR 处理。
• 部分核查： 13 条资料已有部分官方来源、日期、适用范围或文件内容的核查记录，但仍有待核项。
• 时效复核： 其余 31 条目前主要完成本地文件与来源登记核查，政策时效仍待逐条联网复核。
• 适用范围： 已记录部分资料的年级、专业和届别范围，但尚未完成全部资料的逐条语义复核。
• Agent 接入： 当前知识库尚未正式接入 Agent，检索集成方案仍需进一步验证。

因此，44 条代表已登记的资料数量，不代表 44 条资料都已完成全面核验，也不代表这些资料已经全部能够被实际问答流程调用。

2.5.3 资料更新与版本管理

校园政策可能随学年、适用对象或管理要求发生变化。对于奖学金、竞赛、科研项目和推免等信息，系统需要特别关注发布时间、适用年份和具体条件。

后续资料维护将遵循以下原则：

1. 优先使用学校及学院官方来源。
2. 记录资料名称、发布部门、发布日期、适用范围、原文链接及核验状态。
3. 对同一事项的不同版本分别记录，避免将历史通知误认为当前有效政策。
4. 对过期、冲突或无法确认时效的资料明确标记状态。
5. 定期检查官方来源，并在补充新版本时保留历史记录。

在资料时效或适用范围无法确认时，Agent 应提示用户进一步核实，而不是直接将该资料作为确定结论的依据。

2.5.4 Agent 的主要任务与处理流程

Agent 计划采用统一的任务处理流程，根据用户问题选择相应的处理策略，而不是为每一种校园事务单独开发一个智能体。

1. 理解用户问题： 识别用户的查询意图和任务类型，例如政策与事务咨询、机会信息筛选或发展规划建议。
2. 判断必要条件： 检查问题是否缺少事项名称、适用年度、年级专业或具体用途等关键信息；必要时向用户追问。
3. 检索相关资料： 从领域知识库中检索候选资料；在具备相应能力且确有必要时，再补充查询官方公开信息。
4. 检查证据： 结合资料来源、发布日期、适用范围和核验状态，判断现有证据是否足以支持回答。
5. 组织结果： 根据检索到的证据整理回答，尽可能说明结论、适用条件、资料出处和下一步建议。
6. 处理不确定性： 如果资料不足、版本冲突或适用范围不明确，应明确提示限制，不编造确定性结论。

竞赛认定查询是用于验证上述通用流程的代表性场景，但项目整体仍面向五大功能方向，并不局限于竞赛查询。

2.5.5 智能体定制方法与技术路线

项目计划结合领域资料整理、提示词设计、检索增强生成（RAG）和必要的工具调用，对通用大模型进行领域定制。当前技术路线仍处于方案设计与验证阶段，拟采用的组件不应被描述为已经全部集成。

技术环节	计划作用	当前状态
Web 前端	提供统一提问入口，展示回答和资料来源	已完成 Figma 交互原型；实际前端功能仍需开发
后端接口	接收前端请求，管理 Agent 流程和异常处理	计划采用 FastAPI；仍需完成集成与联调
大语言模型	理解问题、辅助组织回答	计划通过模型 API 接入；真实模型问答效果待验证
领域知识检索	从整理后的资料中查找相关内容	知识库已登记资料，尚未正式接入 Agent
混合检索	探索结合语义检索与关键词检索，提高不同类型问题的检索覆盖	属于待验证的技术方案
官方信息核验	必要时补充查询官方公开信息，并检查来源和时效	具体调用方式与可靠性仍需验证
结果校验	检查引用、证据充分性和不确定情况的处理	已完成部分离线逻辑验证，真实资料场景仍需测试

在技术探索中，团队考虑过使用 Embedding 进行文本向量化、使用 Chroma 进行向量检索、使用 BM25 进行关键词检索，并探索通过 RRF 融合不同检索方式的排序结果；大语言模型及联网检索工具的具体选型和接入方式仍应以实际测试结果为准。这些名称代表拟验证的方案，不代表当前系统已完成相应集成。

2.5.6 当前技术验证与局限

团队已完成一项初步离线概念验证（PoC），目前有 9 项自动化测试通过，涉及检索、引用校验和证据不足时的拒答逻辑。

但这项 PoC 使用的是虚构样例和抽取式回答器，并不等同于真实政策问答系统。因此，当前测试只能说明部分基础处理逻辑能够运行，不能据此证明真实模型、正式知识库检索或完整 Agent 已达到预期效果，也不能证明领域定制已经优于通用模型。

后续将继续完成资料核验、真实领域资料接入、模型与检索流程集成，并围绕事实正确性、来源可追溯性、任务适应性和证据不足处理设计可复现的测试案例。只有在实际运行和测试后，才能报告相应的效果结论。

三、需求分析

3.1 需求分析文档说明

本项目的需求分析以目标用户、校园事务与发展场景、领域资料特点及项目可实现范围为基础，进一步明确系统需要提供的功能、各模块之间的关系，以及后续开发和验收时应检查的行为。

完整需求分析文档将参考《软件需求规范》国家标准相关要求编写，并随着开发进度记录需求变更、设计调整和测试结果。文档应反映实际确定的需求与技术方案，不把尚未实现的设想写成已完成能力。

完整需求分析文档：CodeMind-FZU 软件需求规格说明书

3.2 系统范围与模块边界

CodeMind-FZU 的整体规划包含五大业务方向：政策与事务办理、升学与就业发展、学院资源导航、竞赛与科研信息、个人成长档案与长期规划。首版优先完成有官方资料依据的校园信息查询闭环，不要求五个方向在第一版中全部达到完整功能。

系统模块按职责划分如下：

模块	主要职责	首版范围与限制
Web 前端	提供问题输入、必要的补充信息交互、回答展示和资料来源入口	优先实现可完成一次查询的基本页面；Figma 原型不等同于已完成的前端功能
后端接口	接收和校验请求，调用 Agent 流程，统一组织响应并处理异常	计划采用 FastAPI；需在开发中完成接口与异常处理
Agent 流程	理解用户任务、判断是否需要追问、选择处理策略、调用检索能力并组织回答	先支持代表性政策查询流程，其他策略按实际进度扩展
领域知识库	保存官方资料及其来源、日期、适用范围和核验状态，供后续检索使用	当前已登记 44 条资料，但尚未正式接入 Agent，资料核验仍在进行
检索与证据检查	查找候选资料，检查来源、版本、适用范围和证据是否足以支持回答	具体检索方案与效果仍待真实资料测试验证
可选联网核验	在本地资料不足或需要核对更新时，探索查询官方公开信息	属于待验证能力；不能承诺所有问题都能联网核验
可选硬件拓展	探索 ESP32 与软件 Agent 的交互	不属于首版核心交付的必要条件

3.3 功能需求

以下需求用于指导后续实现和测试。它们是计划验收的行为要求，并不代表相关功能目前均已开发完成。

编号	功能需求	预期行为	优先级
FR-01	自然语言提问	用户可以输入与校园政策、学院资源、竞赛科研或升学发展相关的问题	高
FR-02	任务识别	系统根据问题识别主要查询意图，并选择相应处理策略	高
FR-03	必要信息追问	当事项名称、年份、用户条件或用途等信息不足以支持判断时，系统应请求补充	高
FR-04	领域资料检索	系统应从已接入的资料中查找与问题相关的候选内容	高
FR-05	来源展示	对依据资料形成的回答，应尽可能展示真实可核对的资料名称和来源信息	高
FR-06	适用范围与时效提示	当资料存在年份、对象或有效性限制时，系统应明确说明相关限制	高
FR-07	证据不足处理	没有可靠依据时，系统应说明无法确认，不应编造确定性政策结论	高
FR-08	资料冲突处理	当检索到的资料存在冲突或版本关系不明确时，系统应提示不确定性并要求进一步核实	高
FR-09	发展建议	在资料和用户条件允许的情况下，系统可以整理阶段性行动建议，并说明其依据和限制	中，逐步实现
FR-10	个人成长档案	探索保存用户主动提供的目标和阶段记录，并辅助长期规划	后续迭代，首版不作为必要交付

3.4 前端、后端与数据处理要求

（1）前端要求

前端应提供清晰的统一提问入口，并使用户能够理解当前操作、补充必要条件、阅读回答及查看资料来源。对证据不足、资料待核验或需要进一步确认的情况，界面应以明确文字提示用户，不能只显示一个看似确定的答案。

（2）后端要求

后端负责请求接收、参数校验、Agent 流程调用、检索工具调用和结果组织。遇到模型 API 不可用、检索失败、输入不完整或返回内容异常等情况时，应返回可理解的错误提示，避免接口失败后向用户展示误导性结果。

（3）知识库与资料要求

每条纳入检索的资料应尽可能保留资料名称、官方来源、发布日期、适用范围、正文提取情况和核验状态。对尚未核验的资料应保留明确标记，不应与已确认有效的资料混为一谈。

（4）个人信息与隐私要求

系统只应收集完成当前任务所必需的信息。年级、专业或发展目标等信息应在确有必要时由用户主动提供；个人成长档案功能在正式实现前，还需要进一步明确数据保存、使用目的和用户控制方式。当前不预设尚未确定的长期个人数据存储方案。

3.5 代表性任务与验收用例

团队选择“某项竞赛在福州大学如何认定？对综合素质评价和推免有什么影响？”作为代表性任务，用于验证通用 Agent 流程。该场景并不代表项目只面向竞赛查询；同样的任务识别、资料检索、来源展示和证据不足处理能力，后续也将用于其他业务方向。

代表性测试用例

用例编号	测试输入或条件	预期结果	检查方式
TC-01：资料充分	提供明确的竞赛名称、适用年份和查询用途，且知识库已有相关官方资料	返回与资料内容一致的回答，并展示可核对的来源	逐项核对回答中的关键结论与对应官方文件
TC-02：条件不足	用户未说明竞赛名称、年份或认定用途，导致无法准确检索或判断	系统提出有针对性的补充问题，不自行猜测缺失条件	检查追问是否针对真正缺失的条件
TC-03：无可靠资料	输入知识库中没有可靠依据的问题	明确说明目前无法确认，不编造政策内容	检查回答是否明确表达证据不足，且未虚构出处
TC-04：资料版本不同	检索结果包含不同年份或适用范围的文件	说明资料之间的年份或适用范围差异；无法判断现行规则时提示进一步核实	对照文件发布日期、适用对象和正文内容
TC-05：不同事项规则	同时询问竞赛认定、综合素质评价和推免影响	分别查找对应事项的依据，不把某一事项的规则直接推断为另一事项的规则	检查每项关键结论是否有对应的独立依据
TC-06：资料时效未确认	候选资料尚未完成时效核验，或无法确认是否仍然有效	提示核验状态或有效性限制，不将其直接表述为当前确定政策	检查回答是否准确反映资料状态
TC-07：检索或模型异常	模拟检索失败、模型接口不可用或返回异常	向用户提供清楚的失败提示，不伪造正常查询结果	检查异常分支能否被触发并给出可理解提示

验收判定原则

每个测试用例在实际开发完成后都应记录测试日期、输入内容、实际输出、检查依据、通过或未通过的结果，以及发现问题后的修改记录。当前尚未运行的用例应标记为“待测试”，不能预先填写为通过。

验收时重点检查以下标准：

1. 事实有依据： 回答中的关键政策结论能够在对应的官方资料中找到支持。
2. 来源真实可核对： 展示的资料名称和链接确实存在，且与回答内容相关。
3. 适用条件清楚： 不混淆不同年份、专业、年级或不同用途的规则。
4. 不确定性处理合理： 资料不足、过期或冲突时，系统能说明限制，而不是编造结论。
5. 流程可完成： 用户能够从提出问题开始，经过必要追问和资料检索，得到可理解的结果或明确的失败说明。

3.6 领域定制效果的对照验证

为了检验领域定制是否产生实际价值，团队计划在真实资料接入和系统流程稳定后，使用相同的测试问题，对比通用模型直接回答与接入领域资料、检索和证据检查后的回答。

对照评估将关注事实正确性、来源可追溯性、适用条件判断、证据不足时的处理，以及任务是否完成。测试问题、参考资料和评分规则应尽可能保持一致，并记录实际输出及评估结果。

当前尚无足够依据宣称领域定制已经优于通用模型。对照实验的结论应以实际测试数据为准，不预先设定或编造性能提升幅度。

3.7 需求分析文档应包含的交付物

独立需求分析文档还需要落实以下材料，而不只是列出目录：

1. 迭代记录表： 记录修改日期、变更内容、原因、影响范围和处理状态。
2. 项目介绍与范围： 说明调研依据、目标用户、使用场景、五大功能方向及首版范围。
3. 项目标志： 插入 AgentX / CodeMind-FZU 实际采用的 Logo，并说明设计理念。
4. 思维导图： 展示用户需求、五大业务方向及共用技术能力之间的关系。
5. 系统类图： 根据实际设计中的业务对象和模块关系绘制，不用未经确认的类名冒充已实现代码结构。
6. 功能与流程描述： 说明前端交互、后端接口、Agent 任务流程、知识库资料处理和异常处理。
7. 验收标准： 纳入本节代表性测试用例，并在开发过程中填写实际测试结果。

上述材料需要在独立需求分析文档中实际制作并持续更新。博客中的文字说明不能替代尚未完成的思维导图、类图或测试记录。

四、项目阶段规划

4.1 当前进展与已完成工作

截至当前阶段，团队已完成部分前期准备和局部技术验证：

• 产品原型： 已完成 Figma 交互原型设计，用于展示主要页面和预期用户流程。
• 知识资料登记： 已登记 44 条资料的来源和本地记录，其中 43 条已提取正文，1 条扫描版资料待 OCR。
• 资料核验： 13 条资料已有部分来源、日期、适用范围或正文内容的核查记录，但仍有待核项；其余 31 条目前主要完成本地文件与来源登记核查，政策时效仍待逐条复核。
• 离线 PoC： 9 项自动化测试通过，涉及检索、引用校验和证据不足时的拒答逻辑。

上述成果属于需求分析、原型设计、资料整理和局部逻辑验证。当前知识库尚未正式接入 Agent，真实模型问答、完整检索流程、前后端集成和系统部署仍有待完成。离线 PoC 使用虚构样例和抽取式回答器，因此不能据此宣称真实政策问答系统已经通过验收。

4.2 后续迭代安排

团队计划以“先打通核心闭环，再逐步扩展功能”为原则推进开发。具体阶段可根据资料核验进度和技术验证结果调整。

阶段	主要工作	预期交付物与阶段检查点
阶段一：完善领域资料	处理待 OCR 文件，逐步核验官方来源、发布日期、适用范围和时效	资料清单、正文文本、核验状态记录；未核实资料有明确标记
阶段二：接入检索与 Agent	明确数据组织和检索方案，使用真实领域资料测试检索；集成模型 API、任务识别、必要追问和回答组织	能对代表性问题执行“理解问题—检索资料—组织回答”的基本流程，并能展示来源或说明证据不足
阶段三：前后端集成	完成 Web 前端与后端接口联调，处理输入校验、模型不可用、检索失败等异常	用户能够从前端发起查询并收到结构清楚的回答或明确的失败提示
阶段四：测试与改进	使用固定测试用例检查事实正确性、来源可追溯性、适用范围判断及证据不足处理	测试记录、问题清单、修复记录；未通过的用例如实标记
阶段五：部署与验收	完成系统部署、使用说明和必要的验收材料	实际可访问的部署地址、测试方式及对应测试记录

各阶段的交付物以实际完成情况为准。尚未实现或尚未验证的能力不会提前写成已完成成果；如果某一技术方案验证失败，团队将根据测试结果调整实现方式和项目范围。

4.3 核心范围与后续扩展

首版优先完成有官方资料依据的查询闭环，包括用户提问、必要时追问、检索相关资料、组织回答，以及展示来源或提示证据不足。五大业务方向属于项目整体规划，不要求首版一次性完整实现所有功能。

在核心查询流程稳定后，再根据资料覆盖情况和实际需求逐步扩展机会筛选、升学发展建议及个人成长档案等能力。对需要用户长期信息的功能，应先明确数据保存、使用目的和用户控制方式，再决定是否纳入后续版本。

4.4 可选拓展：ESP32 硬件联动

团队曾考虑将 ESP32 作为智能桌面信息终端的可选拓展方向，例如通过屏幕、按键或其他适当的交互方式与软件 Agent 联动。该方向仍需进一步确认硬件方案、通信方式和实际使用价值，不属于首版核心软件交付的必要条件。

只有在核心软件流程得到保障，并完成可演示、可测试的软硬件联动后，才会将其作为实际成果介绍。仅有硬件设想或单独展示设备，不视为已经完成联动。

五、项目总结

CodeMind-FZU 是 AgentX 团队面向福州大学计算机与大数据学院（软件学院）本科生规划的校园事务与发展信息智能助手，重点服务大一至大三学生。项目整体围绕政策与事务办理、升学与就业发展、学院资源导航、竞赛与科研信息、个人成长档案与长期规划五大方向展开，并计划通过领域知识库和 Agent 任务流程，为学生提供更有依据、更具针对性的信息服务。

当前阶段，团队已完成 Figma 交互原型、44 条资料登记、部分资料核查以及离线 PoC 的局部验证，为后续开发提供了初步基础。但知识库尚未正式接入 Agent，部分资料时效仍待复核，真实模型问答、完整前后端集成和部署效果也有待实际测试。

后续工作将优先打通基于官方资料的核心查询闭环，重点验证回答是否有可靠依据、来源能否核对、适用范围是否清楚，以及证据不足时能否如实说明限制。团队将根据实际开发和测试结果逐步扩展功能，不把未实现的计划当作已完成成果，也不在缺少实验数据时预先宣称领域定制的效果提升。

我们希望通过持续迭代，将 CodeMind-FZU 从项目构想逐步建设为可运行、可检查、真正能够帮助福大学生获取和理解校园事务与发展信息的软件系统。