中期汇报-需求

汇报日期：2025-10-20

1. 项目选择

第三组，组名：TODO。

Software has no finish line, only the next TODO.

我们小组选择完成“携程平台”这个项目。

小组成员：

• 杜卓轩：GitHub
• 吕明熹：GitHub
• 张润宇：GitHub

2. 需求提取方法

如何从网站行为中提取需求，特别是一些深层需求和异常情况；

竞品分析

我们小组花费一段时间深入研究携程、Expedia等成熟OTA平台的核心功能，重点分析其主干流程，如机票的搜索、筛选、预订和支付。这帮助我们快速构建了产品功能的基本框架。

通过竞品分析，我们明确了OTA平台的核心价值链：搜索 → 筛选 → 预订 → 支付 → 订单管理，并以此为基础构建了我们的产品架构。

用户画像构建 (Persona)

为了使产品设计更具同理心和用户中心化的导向，我们构建了具象化的用户画像。我们的主要目标用户是小王，21岁的在校大学生，他的核心痛点包括：

基于这些痛点，我们确立了产品愿景：打造一个简洁直观、价格透明、无干扰的在线旅行助手。

用户旅程地图 (User Journey Map)

我们绘制了核心用户的操作路径，例如“一个大学生从产生旅游想法到预订机票成功”的完整旅程。这帮助我们识别出流程中的关键节点和潜在的用户痛点，挖掘出深层需求。

完整的用户旅程包括以下关键触点：

用例分析与场景分解

我们识别出系统的主要参与者（访客、注册用户），并分析其与系统的交互（用例）。

针对异常情况，我们采用“What-if”分析法进行头脑风暴，例如：

这些思考都被转化为具体的需求场景和验收标准，以确保系统的鲁棒性。

3. 需求管理

从该项目中整理出多少需求，如何管理需求（如需求分解，场景描述）；

随着需求提取的深入，我们获得的需求数量快速增长。为了有序地管理它们，我们建立了以下体系：

需求分解结构

我们将整个项目分解为 史诗(Epic) → 用户故事(User Story) → 验收标准(AC) 三个层次。

需求分解层次结构如下：

以用户模块为例，我们识别出以下用户故事：

各模块需求统计如下：

优先级管理 - MoSCoW法则

为了应对有限的开发时间，我们引入了 MoSCoW 方法对所有需求进行优先级排序：

• Must Have (必须实现)：用户注册/登录、机票搜索/预订、订单管理、模拟支付
• Should Have (应该实现)：密码修改、搜索历史、深色模式、国际化支持
• Could Have (可以实现)：站内信息系统、机票选座
• Won't Have (本次不做)：完整的后台管理系统、真实支付网关、UGC内容

这确保了我们能首先集中精力交付产品的核心价值。完整内容请看项目范围

场景描述 - BDD & Gherkin语法

为了消除需求描述的模糊性，我们采用 行为驱动开发（BDD） 的思想。对于关键的用户故事，我们使用 Gherkin 语法 (Given/When/Then) 来编写清晰、无歧义、可测试的验收标准。

例如，对于"用户注册"功能，我们编写了如下验收标准：

更多例子请看每一个功能需求的4. 验收标准(Acceptance Criteria)部分，例如这里

文档化

所有需求都已在我们的 Fumadocs 文档系统，也就是本网站中进行结构化管理，包括：

• 项目目标与范围
• 用户画像与业务流程
• 功能需求详细说明（用户模块、机票模块、订单模块、支付模块）
• 非功能需求（性能、安全、兼容性、可用性）
• 技术设计文档（架构设计、数据库设计、开发规范、Git工作流）

这确保了团队成员之间的信息同步，也为后续的开发和测试提供了清晰的指导。

4. AI辅助实现

如何借助AI来实现需求，提示词、实现流程是什么（计划或已经开始实践）

我们在项目中深度集成了AI工具，显著提升了开发效率和代码质量：

GitHub Issue 创建助手

这是我们单独配置的一个 Trae智能体，添加了 GitHub MCP。通过明确的提示词，让智能体创建清晰的Issue内容：

GitHub Pull Request 创建助手

这是我们单独配置的一个Trae智能体，添加了GitHub MCP。通过明确的提示词，让智能体创建清晰的Pull Request内容：

自动生成commit message

我们的小组项目通过pre-commit hook来确保commit message符合conventional commit的规范，进而提高code review的效率，方便reviewer快速了解其他人对代码的修改。但是每次手写commit message有时候非常烦人，因此借助vscode-copilot插件，并在项目的.vscode/settings.json中进行如下配置：

// VSCode integrated Copilot Commit Message Templates
"github.copilot.chat.commitMessageGeneration.instructions": [
    {
        "text": "Use conventional commit format: type(scope): description"
    },
    {
        "text": "Type must be one of: build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test"
    },
    {
        "text": "Type must be in lowercase"
    },
    {
        "text": "Subject must start with lowercase, avoid sentence-case, start-case, pascal-case, or upper-case"
    },
    {
        "text": "Subject cannot be empty"
    },
    {
        "text": "Subject must not end with a period (.)"
    },
    {
        "text": "Header (type + scope + subject) must not exceed 100 characters"
    },
    {
        "text": "Use imperative mood: 'add feature' not 'added feature'"
    },
    {
        "text": "If body exists, there must be a blank line between subject and body"
    },
    {
        "text": "Body lines must not exceed 100 characters each"
    },
    {
        "text": "If footer exists, there must be a blank line between body and footer"
    },
    {
        "text": "Footer lines must not exceed 100 characters each"
    },
    {
        "text": "Scope is optional, use when relevant (e.g., api, ui, auth)"
    },
    {
        "text": "For breaking changes, use 'BREAKING CHANGE:' in footer"
    },
    {
        "text": "Generate commit messages in English only"
    }
]

5. 问题与解决方案

上述过程中有哪些问题或困难，计划如何解决？

在需求分析阶段，我们主要遇到了以下挑战：

问题1：需求范围蔓延的巨大诱惑

描述：在分析竞品时，我们发现了很多很酷的功能（如酒店预订、选座、i18n），初期非常希望全部实现，导致范围定义模糊。

解决方案：我们通过引入 MoSCoW法则，强制团队对每个功能进行价值和成本的评估，并严格遵守。我们将所有非核心功能明确放入“Could Have”或“Won't Have”，确保了项目范围的可控性。

问题2：需求描述的模糊性与二义性

描述：团队成员在讨论“预订功能”时，对具体流程的理解出现了偏差，导致了不必要的争论。

解决方案：我们决定采用 BDD和Gherkin语法。通过将需求转化为具体的行为场景（Given/When/Then），我们为团队提供了统一、无歧义的沟通语言，确保了开发和测试的“一个标准”。

问题3：架构选型：前后端分离 vs. 一体化全栈

描述：在项目启动时，我们面临的第一个关键架构决策是：选择传统的前后端分离架构（例如 React + FastAPI）还是一体化的全栈框架（例如 Next.js）？

解决方案：经过深入的调研和团队讨论，我们最终决定采用 Next.js 一体化全栈的开发模式。我们认为，对于我们这个规模和周期的项目，其带来的优势远大于挑战。做出这个决策的关键理由如下：

1. 极致的开发效率与集成度:
   • 在分离架构中，我们需要花费大量时间设计、编写、维护一个独立的API层（如RESTful或GraphQL），并处理跨语言、跨仓库的协作问题。
   • 而Next.js通过 Server Actions，几乎完全消除了编写API样板代码的需要，让我们可以直接在后端调用函数，极大地提升了开发速度，使我们能更专注于业务逻辑的实现。
2. 端到端类型安全:
   • 这是我们做出选择的决定性因素之一。在分离架构中（如TS+Python），要保证前后端数据类型的一致性非常困难，是常见的Bug来源。
   • 而在Next.js的全栈TypeScript环境中，我们可以轻松地在数据库（Drizzle的Schema）、后端服务逻辑（Server Actions）和前端UI组件之间共享类型定义。这为我们带来了从数据库到用户界面的、无缝的类型安全保障，能让AI和编译器在编码阶段就发现大量潜在的集成错误。
3. 显著的性能优势:
   • Next.js 15 的 Server Components 允许我们在服务器上直接获取数据并渲染成HTML，发送到客户端的JavaScript极少。这能带来更快的初始页面加载速度（FCP/LCP），直接有助于我们达成在非功能需求中定义的性能指标。
4. 与AI辅助开发的协同效应:
   • 这一点与本课程的特色高度契合。一个统一、单体的全栈代码库，为AI编程助手提供了更完整、更丰富的上下文。当我们需要AI辅助编写或重构一个功能时，AI可以同时“看到”数据库的结构、后端的逻辑和前端的UI，从而给出更精准、更符合项目实际的代码建议。我们发现，Next.js作为国外最热门的框架之一，主流AI模型的知识库对其支持也最全面。

6. 进度与规划

目前实现的效果（如果有），未来进度规划。

项目进度

我们小组目前已经实现了以下功能，欢迎点击下面的链接体验。

体验链接

已实现功能

技术栈亮点

我们采用了现代化的技术栈来确保项目的可维护性和可扩展性：

• 全栈框架：Next.js 15 (App Router) + TypeScript
• UI组件库：shadcn/ui + Tailwind CSS，支持深色模式
• 数据库：PostgreSQL + Drizzle ORM
• 认证方案：Better-Auth (支持多种登录方式)
• 部署平台：Vercel (前端) + Neon (数据库)
• 开发规范：ESLint + Prettier + Conventional Commits

需求文档体系

我们建立了完整的需求文档体系，所有文档都托管在 Fumadocs 系统中，包括：

项目规划