# campus-request

**Repository Path**: Fergie/campus-request

## Basic Information

- **Project Name**: campus-request
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-04-30
- **Last Updated**: 2026-04-30

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 四园区内部需求收集与处理系统：候选人项目测试说明

## 一、项目背景

我们是一家教育公司，下属有四个小学或幼儿园园区。IT 部门是职能支持部门，日常需要服务老师、园区员工和管理人员。

实际工作中，很多需求一开始并不清晰。例如：老师可能只是说“打印机又不能用了”“想做一个报名表”“希望系统能提醒我某件事”。IT 人员需要理解这些模糊表达，整理成可处理的需求，并最终交付一个让业务方满意的结果。

本次项目测试的重点不是考算法、不是考高并发，也不是考复杂架构。我们更关注你是否具备独立开发者能力：能理解业务、收束需求、做出取舍，并交付一个可运行、可演示、可维护的小系统。

## 二、项目题目

请设计并实现一个“四园区内部需求收集与处理系统”。

系统需要支持老师或园区员工提交需求，IT 处理人查看、处理、反馈需求，并让提交人确认处理结果是否满意。

项目完成时间建议为 1-2 天。

## 三、你需要解决的问题

请围绕以下业务场景进行设计和实现：

1. 四个园区的老师或员工都可以提交需求。
2. 需求可能来自 IT、设备、系统、网络、行政协作等不同类型。
3. IT 处理人需要看到所有需求，并能更新处理状态。
4. 处理过程中，提交人和处理人可以补充说明或沟通记录。
5. 需求解决后，提交人可以确认是否满意。
6. 系统需要能让面试官在本地快速启动并演示完整流程。

你可以根据自己的理解补充合理假设，但需要在文档中写清楚。

## 四、最低功能要求

### 1. 用户角色

系统至少包含两个角色：

- 老师/员工：提交需求，查看自己提交的需求，补充说明，确认是否满意。
- IT 处理人：查看全部需求，处理需求，更新状态，回复处理结果。

如果你认为需要增加园区管理员、超级管理员等角色，可以自行设计，但请说明原因。不要为了复杂而复杂。

### 2. 需求信息

每条需求至少应包含：

- 标题
- 详细描述
- 所属园区
- 需求类型
- 优先级
- 当前状态
- 提交人
- 处理人
- 创建时间
- 更新时间
- 处理记录或沟通记录

### 3. 状态流转

建议至少包含以下状态：

- 待处理
- 处理中
- 已解决
- 已关闭

你可以根据自己的理解调整状态名称或增加状态，但需要说明这样设计的原因。

### 4. 可用界面

系统必须有可用界面。

界面不要求非常精美，但需要能清楚完成核心流程：

- 登录或选择用户身份
- 提交需求
- 查看需求列表
- 查看需求详情
- IT 处理人更新状态和回复
- 提交人确认满意度或关闭需求

### 5. 后端与数据库

后端和数据库技术不限。

请在文档中说明：

- 为什么选择这个技术栈
- 数据模型如何设计
- 主要接口或页面如何组织
- 如果系统未来要正式上线，你会优先改进哪些地方

## 五、交付要求

请提交一个可以运行的项目，而不是只提交设计方案。

交付内容至少包括：

- 项目代码
- `README.md`
- `.env.example`
- 初始化数据或种子数据
- 本地启动说明
- 技术选型说明
- 需求理解与取舍说明

强烈建议提供以下内容：

- `Dockerfile` 或 `docker-compose.yml`
- 一条命令启动方式，例如 `docker compose up` 或类似命令
- 默认测试账号
- 示例数据，例如四个园区、几个老师账号、几个需求工单

如果项目依赖第三方服务，例如云数据库、对象存储、邮件服务，请提供本地替代方案或 mock 方案。面试官应能在本地环境中完成核心流程演示。

## 六、可选实现路线

你可以选择以下任一路线。

### 路线 A：从零实现

从零设计并实现一个最小可用系统。

适合希望展示完整产品理解、数据建模、接口设计和端到端交付能力的候选人。

### 路线 B：基于开源项目改造

你也可以选择一个开源 helpdesk、ticket、support desk 或工单系统作为基础进行改造。

如果选择这条路线，请在 `README.md` 中说明：

- 选择该开源项目的原因
- 原项目解决了什么问题
- 你做了哪些业务改造
- 哪些功能是新增的
- 哪些功能被你删除或简化了
- 原项目的部署方式是否被你改进

可参考的小型开源项目：

- `bradtraversy/support-desk`
- GitHub 地址：`https://github.com/bradtraversy/support-desk`
- 技术栈：React、Express、MongoDB
- 说明：这是一个较小的 support ticket 应用，适合在 1-2 天内理解并改造成“四园区内部需求收集与处理系统”。它已有用户、登录、ticket、note 等基础，但需要你补充园区、角色、业务字段、状态流转和本地部署方案。

也可参考成熟项目：

- `Peppermint-Lab/peppermint`
- GitHub 地址：`https://github.com/Peppermint-Lab/peppermint`
- 说明：这是更成熟的 helpdesk 系统，已有 Docker Compose 部署方式。但项目体量较大，1-2 天内可能会被环境和代码复杂度消耗，请谨慎选择。

不建议本次优先选择过重的成熟系统，例如 Zammad、UVdesk、FreeScout、Frappe Helpdesk。它们适合生产级研究，但不适合 1-2 天项目测试。

## 七、README 必须说明的问题

请在 `README.md` 中回答以下问题：

1. 你如何理解这个业务场景？
2. 你补充了哪些需求假设？
3. 你为什么选择当前技术栈？
4. 如何在本地启动项目？
5. 默认账号和示例数据是什么？
6. 核心业务流程如何演示？
7. 哪些功能你做了，哪些功能你没有做？为什么？
8. 如果再给你 3-5 天，你会优先改进什么？