404烦恼未找到——团队展示

作业信息

目录

一、团队介绍

团队名称：404烦恼未找到

团队描述： 我们由 8 名成员组成，计划通过需求研究、产品设计、前后端开发、智能体编排、信息检索、质量保障与项目管理的协作，完成一个边界清晰、可运行、可评估的课程项目。团队强调任务透明、知识互补和及时复盘，让每位成员都能参与方案讨论与交付。

团队slogan： 生活偶尔报错，我们一直在线。

队员风采：

队员一

• 学号：102400433
• 姓名：张王昊
• CSDN 地址：https://blog.csdn.net/impure_wine?type=lately
• 性格：INFP
• 擅长技术：Spring Boot，Vue 3，Git，Docker
• 兴趣爱好：跑步、玩游戏、听歌
• 希望承担的软工角色：PM / 需求分析
• 一句 slogan：听凭风引，且听风吟

队员二

• 学号：102400413
• 姓名：郭昱祺
• CSDN 地址：https://blog.csdn.net/2503_90404390?type=bbs
• 性格：ESFP
• 擅长技术：Vue 3，SQLite
• 兴趣爱好：摄影，运动，玩游戏
• 希望承担的软工角色：UX / 产品设计
• 一句 slogan：常道恢宏，鸣神永恒

队员三

• 学号：082402202
• 姓名：程杰
• CSDN 地址：https://blog.csdn.net/ytxz999?type=blog
• 性格：ISTJ
• 擅长技术：C语言，web开发，mysql，redis
• 兴趣爱好：运动，听歌，玩游戏
• 希望承担的软工角色：前端工程师
• 一句 slogan：风吹青春几页

队员四

• 学号：102404017
• 姓名：李泉毅
• CSDN 地址：https://blog.csdn.net/2503_90393437?spm=1000.2115.3001.5343
• 性格：细致认真、责任心强、逻辑清晰、乐于钻研，但偶尔有些急躁
• 擅长技术：C语言，C++，java，SQL等底层语言，web开发基础等等
• 兴趣爱好：游戏，编程，跑步，健生，在高强度工作学习下我也会通过体育锻炼强身健体。
• 希望承担的软工角色：后端工程师
• 一句 slogan：在看不见的后端让每一次陪伴都准时抵达

队员五

• 学号：102400401
• 姓名：程群
• CSDN 地址：https://blog.csdn.net/cq051225?spm=1000.2115.3001.5343
• 性格：ENFP
• 擅长技术：web全栈，agent memory
• 兴趣爱好：睡觉
• 希望承担的软工角色：智能体 / AI 工程
• 一句 slogan：吃饱睡好

队员六

• 学号：102400435
• 姓名：庄剀涵
• CSDN 地址：https://blog.csdn.net/zkh060828?type=blog
• 性格：INFP
• 擅长技术：索引构建
• 兴趣爱好：排球
• 希望承担的软工角色：搜索 / 数据工程
• 一句 slogan：与其抱怨黑暗，不如提灯前行

队员七

• 学号：102400402
• 姓名：关欣
• CSDN 地址：https://blog.csdn.net/Mayday_6229
• 性格：兴趣驱动，有想象力的同时细致慎微
• 擅长技术：C/C++
• 兴趣爱好：绘画，游戏，音乐，手工
• 希望承担的软工角色：安全 / 内容审核
• 一句 slogan：卫士不语功，唯时代尔；持光不畏暗，无而蔽安

队员八

• 学号：102400431
• 姓名：曾俊涛
• CSDN 地址：https://blog.csdn.net/2601_96495735?type=bbs
• 性格：勤劳又勇敢
• 擅长技术：算法、全栈
• 兴趣爱好：原神
• 希望承担的软工角色：测试 / 运维
• 一句 slogan：PoPiPa，PiPoPa，PoPiPaPaPiPoPa！

二、项目背景与初步需求

目标用户与使用场景

目标用户为大众用户，典型场景包括：工作任务或职业变化带来的压力；家庭关系、生活安排或个人计划中的烦恼；学习、办事和日常决策中的信息查询。

团队拟定的核心需求

以下是对题目主题的产品化拆解：

1. 陪伴交流： 用户可以描述近况或烦恼；智能体先倾听、澄清用户希望获得的帮助，再提供简短回应。避免强行建议、情绪操控和拟人化误导。
2. 压力缓解小训练： 提供用户主动选择、时长较短且可随时退出的内容，例如呼吸调节、五感定向、暂停整理和任务拆分，用于一般性的压力缓解与自我调节。
3. 信息搜集： 用户可以提出查询或资料整理需求；系统展示摘要及可打开的来源链接，对无结果、过期或冲突信息明确表达不确定性，不伪造来源。
4. 模式切换： 将“陪伴交流”和“事实查询”作为可辨识的任务流程，避免把情绪支持文本误当成事实依据，也避免把搜索摘要包装成情感建议。
5. 用户控制与隐私： 当前会话只使用完成任务所需的上下文；历史保存需用户主动选择，并提供清除入口。
6. 安全边界： 产品不诊断、不治疗；遇到明显危机表达时，不继续给出常规压力缓解小训练或确定性判断，而是鼓励用户联系所在地的紧急服务、可信赖的人或专业支持资源。

MVP 验收方向

• 用户能够通过产品入口完成陪伴交流、压力缓解小训练、资料查询三条主流程。
• 查询结果能显示对应来源；没有可靠依据时，系统能够说明不确定或未找到足够资料。
• 用户可以随时结束压力缓解小训练，并查看、选择留存或清除会话记录。
• 桌宠端可完成核心流程；微信聊天入口按官方接口权限与平台规则验证，权限受限时以明确标记的模拟适配器展示。
• 不同入口默认隔离会话历史，只有用户明确授权后才考虑跨端关联。
• 通过测试用例检查空结果、接口超时、来源冲突、越权访问和敏感输入的处理。

团队项目选题描述

面向大众在工作、学习、家庭及日常生活中的轻度压力与信息获取场景，提供一般性倾听、用户自主选择的压力缓解小训练，以及带有可追溯来源的信息整理；部署形态规划为桌面宠物（桌宠）客户端，并接入微信聊天入口。

选题PDF

三、NABCD 选题分析

N — Need（需求）：大众用户在什么情境下需要“404NOTFOUND”？

目标对象： 面向大众日常使用，不以学校、职业或某一身份群体为产品边界。

代表性情境与用户任务：

1. 工作任务、学习安排、家庭事务或生活变化带来压力时，用户希望先把事情说清楚，再决定是继续交流、尝试压力缓解小训练，还是梳理下一步计划；桌宠和微信聊天入口则提供更顺手的唤起方式。
2. 用户在办事、学习、工作或日常决策中需要了解某个事实，希望获得简明整理，并能点开来源核对，而不是只收到无法追溯的结论。

痛点假设： 通用对话可能难以稳定区分情绪支持和事实查询；固定的压力缓解小训练内容未必能接续用户当前表达；搜索结果需要用户自行筛选和比对；不同应用之间频繁切换也可能增加操作成本；用户还可能担心敏感对话被保存。

验证方式： 通过访谈、问卷和任务走查了解用户在何时会使用此类工具、希望获得何种帮助、何时愿意切换到查询、是否需要保存历史，以及对来源和隐私的最低要求。

A — Approach（做法）：用明确流程把三类能力串起来

产品流程： 课程原型提供 Web 入口；部署目标包括桌宠入口和微信聊天入口。用户可选择“聊一聊”“开始压力缓解小训练”或“查找信息”；意图不明确时先追问确认。陪伴模式以倾听和澄清为主，用户可自主选择是否开始小训练；查询模式单独展示检索摘要、来源链接和不确定性；用户随时可以退出、结束会话或清除记录。

系统模块： 多端接入层支持课程 Web 原型、桌宠客户端和微信聊天适配器；微信端采用何种官方开放能力，以实际权限和平台规则核验结果为准。后端 API 管理会话身份、权限与任务状态；对话编排模块将请求路由到陪伴、压力缓解小训练或搜索流程；训练内容库保存经过团队审核的短内容；搜索适配器负责调用检索服务并关联来源；数据层仅保存完成明确功能所需且经用户选择保留的信息。不同入口的会话默认隔离，跨端关联须经用户明确授权。模型和搜索能力通过适配层封装，避免核心流程依赖单一服务。

首版范围： 优先打通陪伴对话、用户主动选择的压力缓解小训练、带来源的信息查询和会话控制四个闭环。课程阶段先交付可复现的 Web 原型并验证桌宠端交互；微信端需先核验官方接口权限和平台规则，无法直接接入时以显式标记的模拟适配器完成流程演示。首版不做心理诊断、治疗承诺、长期情绪监测、自动危机处置、社交社区或未经授权的长期记忆；危机场景提供明确的求助指引，不把智能体描述成救援服务。

B — Benefit（好处）：用户、团队和课程分别获得什么

• 对用户： 用一个入口完成表达、短时自我调节和资料搜集；可以控制是否继续、是否留存，也可以核查信息来源。预期价值是降低切换工具和辨认回答类型的成本，不承诺改善心理疾病或替代专业服务。
• 对团队： 项目覆盖需求研究、交互设计、前后端架构、模型与搜索接口、数据保护、测试和部署，便于 8 人按交付责任协作，并形成可演示、可复现的工程成果。
• 对课程评审： 用可检查的用户流程和测试证据呈现项目价值，而不是只展示模型对话。主要指标包括三条主流程的任务完成情况、事实回答的来源可追溯情况、用户对模式和隐私设置的理解程度、会话清除是否生效，以及异常/敏感场景是否按规则处理。

C — Competitors（竞争）：已有选择及我们的定位

用户已有的替代选择包括情绪自助工具、冥想与身心健康内容、AI 角色陪伴、通用 AI 助手和 AI 搜索。Wysa、Headspace、Tofai、豆包、Perplexity 与 ChatGPT Search 的公开功能及对本项目的启示详见下节“行业竞品调研与分析”。

“404NOTFOUND”的差异化假设是：面向大众，通过桌宠和微信聊天入口触达用户，将倾听、用户自选的压力缓解小训练和来源可追溯的查询连成可切换流程，同时区分情绪回应与事实回答，并提供数据留存控制。

D — Delivery（推广 / 交付）：如何开发、验证和逐步交付

课程阶段通过课堂演示、团队博客和小范围自愿体验获取反馈。部署时先完成 Web 服务与桌宠客户端集成，再依据核验通过的微信官方能力接入聊天入口；若微信权限、模型或搜索服务不可用，使用明确标记的模拟适配器或离线示例保证流程可复现，不采用未经授权的个人账号自动化。体验数据按最小必要原则处理。面向更大范围部署前，重新评估隐私、安全、来源质量、内容审核和专业支持衔接。

四、行业竞品调研与分析

调研口径： 以下分析依据截至 2026 年 10 月 5 日可查的产品官网或官方应用商店介绍，比较的是公开产品定位和功能组合，不是同条件下的性能、疗效或市场份额测试。产品功能可能调整，正式发布博客前应再次核对。

竞品结论

市场上已有产品分别覆盖情绪自助、专业内容、角色陪伴和 AI 搜索。由此可见，本项目的机会不是“首创 AI 陪伴”或“首创 AI 搜索”，而是验证大众在同一日常情境中切换陪伴交流、压力缓解小训练和资料查证时，是否需要更连贯、可退出、来源透明，并能从桌宠或微信入口触达的交互流程。

五、产品创新点与竞争壁垒

方案层面的创新点

1. 三类需求同一入口、任务边界清楚： 允许用户在陪伴交流、压力缓解小训练和信息查询之间主动切换，每种任务采用相应流程和输出格式。
2. 情绪支持与事实回答分层： 情绪交流侧重倾听、澄清和用户自主选择；事实回答明确展示检索来源。系统不把模型生成的安慰语当证据，也不把搜索摘要当作专业建议。
3. 从“回答问题”转向“帮助完成下一步”： 在用户许可下，引导其选择继续表达、尝试压力缓解小训练或核对资料；不替用户决定，不强迫其继续互动。
4. 将来源可信度和数据控制设为核心体验： 对信息摘要提供可追溯链接、时间信息和不确定性提示；对会话留存提供清楚的选择与删除路径。
5. 安全边界前置到产品流程： 将非诊疗定位、敏感输入处理和危机转介写入需求、界面、测试和团队运营规范，而不是上线后的补充声明。
6. 桌宠与微信多入口： 桌宠提供轻量、可主动关闭的桌面触达，微信聊天入口适配用户熟悉的沟通场景；两端复用服务能力，但会话默认隔离，跨端关联需用户授权。

竞争壁垒：当前没有现成的技术护城河，目标是逐步积累

• 经过专业审阅的压力缓解小训练与安全流程： 与合格的心理健康或内容专家协作，建立适用范围明确、可追溯的小训练内容及危机场景处置流程。课程阶段只能完成初步规范，不声称已有临床认证。
• 可评估的交互质量体系： 建立覆盖陪伴、来源引用、拒答/不确定、数据删除和安全边界的测试集与评估方法；使用脱敏或合成数据，保护用户隐私。
• 高质量来源治理： 对适用信息类别整理可信来源、更新时间和冲突处理规则，让“可核验”成为稳定的产品习惯，而非一次性展示链接。
• 用户信任与隐私实践： 坚持最小化收集、显式授权、方便删除和清楚说明数据用途。信任需要长期兑现，不能靠单一功能或宣传建立。
• 持续反馈和服务渠道： 在用户同意的前提下，根据跨职业、跨生活场景的反馈改进流程，并通过合规合作、内容审核和稳定交付提升服务能力。

六、技术方案与项目计划

初步系统架构

接入层提供课程 Web 原型、桌宠客户端和微信聊天入口；桌宠侧实现轻量唤起、对话、压力缓解小训练和退出控制，微信侧通过核验可用的官方开放能力接入，具体形式根据账号资质、API 权限和平台规则确定。后端负责会话身份、权限、任务路由和数据访问；编排层连接对话模型、压力缓解小训练内容及信息搜索服务；数据库仅保存完成明确功能所需且经用户选择保留的数据。各入口会话默认隔离，跨端共享需要用户明确授权。模型与搜索能力使用适配层封装，避免业务流程绑定单一供应商。

项目阶段与交付物

项目评价指标

• 主流程任务完成情况：用户能否从 Web、桌宠或微信入口完成交流、压力缓解小训练及资料查询，并能退出训练。
• 信息可追溯性：事实性摘要能否对应到有效来源；缺少依据时能否表达不确定。
• 可用性：不同背景体验者能否理解模式差异、隐私选择和操作结果。
• 安全与隐私：敏感输入、会话删除、权限控制和危机场景测试是否符合预设规则。
• 工程质量：需求、代码、测试、问题修复和部署步骤是否可追踪、可复现。

七、团队绩效考核方案

7.1 目的、适用范围与原则

本方案用于项目开发过程中的团队内部成员贡献复盘，以每个迭代/里程碑为一个考核周期；全体成员讨论通过后执行，并在第一次迭代前确认。考核依据事先约定的任务、验收条件和过程证据，兼顾开发、需求、设计、测试、内容、安全、文档和项目管理等不同岗位。

执行原则：目标与工作量事先公开；不同角色按对应交付物评价，不比较代码行数；遇到需求变更、外部依赖或合理阻塞时先调整计划再评分；评分可解释、可复核；鼓励成员互助和知识分享，不按既往成绩或经验高低评价。

7.2 个人周期评分维度（每周期 100 分）

每个维度先按 0–100 分评定，再按权重折算：

个人周期分 = 交付完成度 D × 40% + 交付质量 Q × 25% + 协作互助 C × 20% + 过程责任 P × 10% + 知识沉淀 K × 5%。

7.3 不同岗位的交付证据

考核看交付是否达到约定的验收条件，不要求每位成员都以代码提交证明贡献：

7.4 周期流程与评分复核

1. 周期开始：团队共同拆分任务，指定负责人、验收条件和相对工作量；成员确认计划。任务复杂度与依赖应在开工前讨论，避免事后按印象分配分值。
2. 周期进行：所有成员更新任务状态和阻塞事项；需求或外部接口变化时，由团队记录变更、调整范围/工作量，不把已协商的变更算作个人失约。
3. 周期结束：每位成员提交简短自评及交付链接；队友可针对协作互助提供具体事实。由组长和两名轮值成员组成复核小组，对照评分维度形成初评，组长本人也接受同一流程评议。
4. 反馈与确认：向被评成员说明各项分数及对应证据，留出至少 48 小时补充材料或提出异议。复核小组讨论后记录调整理由；涉及成员本人时，该成员不参与自己的最终复核表决。
5. 记录与改进：保存每周期的任务计划、评分表、复核意见和改进项；对连续出现的延期或协作问题，先检查任务拆分、工作量和依赖安排，再约定支持措施。

各项分数统一按以下参考档次：90–100 分表示证据充分且稳定达到/超过约定标准；75–89 分表示主要目标完成，存在少量可修正问题；60–74 分表示部分目标完成，仍有明显缺项；低于 60 分表示关键交付未完成或缺少有效证据。无法归因于个人的阻塞、已批准的范围变化、合理求助和及时风险上报，不单独作为扣分理由。考核不采用代码行数、在线时长、出勤次数或人际好恶作为单一依据。

八、团队愿景

我们希望把“404NOTFOUND”建设成面向大众的轻量陪伴与信息支持工具，让用户在工作、学习、家庭和日常生活中遇到烦恼时，能够先表达压力，再自主选择压力缓解小训练或查找有来源的信息。课程阶段先交付可演示、可测试的原型，验证陪伴、训练、信息搜集三条主流程及隐私控制；后续部署目标是桌面宠物（桌宠）和微信聊天入口，让用户从桌面或熟悉的聊天场景获得支持。我们将依据不同背景用户的反馈持续改进，以透明、克制和可靠建立信任；产品不替代专业心理服务，团队也在协作交付与复盘中成长。