2.2 项目立项：目标、计划与可行性¶
把一个想法变成可以开始做的项目¶
立项书不是写得越长越好
选题确定后，你需要把“我想做什么”整理成“我准备怎样完成”。一份合格的立项书，应让老师和同学看明白：项目解决什么问题、谁会使用、准备先完成什么、是否做得出来。
课程项目不需要复杂的商业计划书。对大多数同学来说，一份 2—4 页、内容真实、范围清楚的《项目选题立项书》就足够了。
本节学习目标
根据上一节完成的选题卡，借助 Trae 和教师提供的立项/选题 Skill，完成一份可以提交和修改的《项目选题立项书》。
🎯 本节最终只提交一份文档¶
本节的成果是：
《项目选题立项书》
它将成为后续需求分析、原型设计和开发的起点。建议包含以下内容：
| 内容 | 要回答的问题 |
|---|---|
| 项目名称 | 项目叫什么，主要业务是什么？ |
| 项目背景 | 用户当前遇到了什么问题？ |
| 用户与场景 | 谁在什么情况下使用系统？ |
| 调研依据 | 你和谁交流过，或体验了什么同类产品？ |
| 项目目标 | 系统准备帮助用户完成什么？ |
| 核心闭环 | 从开始到结束，主要业务怎样流转？ |
| 功能范围 | 必做、选做和本期不做分别是什么？ |
| 实施计划 | 每个阶段准备交付什么成果？ |
| 风险与应对 | 最可能卡在哪里，准备怎样降低风险？ |
| AI 使用说明 | AI 在哪些环节提供辅助，你如何审核结果？ |
立项书中的内容必须真实
没做过的访谈、没体验过的产品、没掌握的技术都不要编造。真实但简单的说明，比看起来专业却无法解释的内容更有价值。
🧩 第一步：用上一节的选题卡填充立项书¶
上一节已经完成了项目名称、用户问题、核心流程和范围。现在不要重新想一遍，直接把选题卡中的结论整理到立项书中。
1. 项目名称与一句话介绍¶
项目名称应说明主要业务，避免过于宽泛：
| 不推荐 | 更清楚的写法 |
|---|---|
| 校园服务平台 | 宿舍报修管理系统 |
| 学生管理系统 | 学生竞赛报名与审核系统 |
| 智能系统 | AI 辅助课程学习系统 |
一句话介绍使用固定句式：
示例：
面向住校学生、宿舍管理员和维修人员，解决报修依赖群消息、处理进度不透明的问题，通过学生提交报修、管理员派单、维修处理和学生确认，形成宿舍报修管理系统。
2. 项目背景与问题¶
背景不需要写成宏大叙事，只需回答以下问题：
- 用户现在怎样完成这件事？
- 哪一步耗时、容易出错或信息不透明？
- 这个问题对用户有什么影响？
- 系统准备优先改善什么？
可以采用下面的写法：
不要套用空泛背景
“随着互联网快速发展”“为了提升信息化水平”不能说明真实问题。背景必须能够连接到目标用户的具体场景。
🔍 第二步：写清用户、场景和调研依据¶
用户与场景¶
不用列太多角色。基础项目建议先确定 1～3 类最重要的用户：
| 用户角色 | 在什么情况下使用 | 想完成什么 | 主要关注点 |
|---|---|---|---|
| 学生 | 发现宿舍设施故障时 | 提交报修并查看进度 | 是否方便、是否知道处理结果 |
| 宿舍管理员 | 收到报修后 | 判断问题并安排维修 | 信息是否完整、是否能派单 |
| 维修人员 | 接到维修任务后 | 查看任务并更新处理结果 | 故障描述、地点和状态 |
调研依据¶
简单记录真实调研即可，不需要复杂统计：
| 调研方式 | 对象或产品 | 主要发现 |
|---|---|---|
| 用户交流 | 2 名住校学生 | 希望报修后能查看是否已受理和预计处理时间 |
| 同类产品体验 | 某校园报修小程序 | 有分类和进度功能，但故障描述输入不够清楚 |
调研发现要影响你的项目
例如，学生最在意“报修进度”，那么“查看进度”应进入必做功能；如果无人真正需要“维修排行榜”，就不要因为看起来有趣而放进必做范围。
🔄 第三步：明确项目目标与核心业务闭环¶
项目目标¶
目标写成系统要帮助用户完成的结果，而不是技术清单：
| 不推荐 | 推荐 |
|---|---|
| 使用 Vue、Spring Boot 和 MySQL 开发系统 | 让学生能够在线提交报修，并查看处理进度和结果 |
| 接入 AI 大模型实现智能功能 | 在核心报修流程可用的基础上，尝试为故障描述提供分类建议 |
核心业务闭环¶
立项书中至少写出一条主流程：
如果流程有明显状态变化，也可以画成图：
flowchart LR
A["学生提交报修"] --> B["管理员受理派单"]
B --> C["维修人员处理"]
C --> D["学生确认结果"]
D --> E["报修完成"]功能菜单不能代替业务闭环
“用户管理、报修管理、统计管理”只是页面菜单，不能说明系统怎样解决问题。必须写出角色动作、处理过程和最终结果。
✂️ 第四步：控制功能范围¶
不要把所有想到的功能都写成必做。立项时就写清边界，后续开发才能控制节奏。
| 分类 | 含义 | 宿舍报修系统示例 |
|---|---|---|
| 必做 | 支撑核心闭环，必须开发和测试 | 登录、提交报修、派单、进度更新、确认完成 |
| 选做 | 核心功能完成后再考虑 | 图片识别、超时提醒、维修统计 |
| 本期不做 | 明确排除，避免范围失控 | 在线支付、智能硬件接入、跨校区调度 |
基础项目建议控制为：
- 2～3 类用户；
- 4～6 个核心模块；
- 1～2 条主要业务流程；
- 1 项以内的 AI 增强功能。
AI 功能不是必做前提
选择 AI 方向时，先保证普通业务流程能够运行。外部模型不可用、额度不足或接口变化时，项目的基础功能仍然应可以展示。
🗓️ 第五步：制定简单、可检查的计划¶
计划不必精确到每天，但每个阶段必须有看得见的成果。
| 阶段 | 主要任务 | 可检查成果 |
|---|---|---|
| 第 1—4 周 | 选题、需求、原型和设计 | 立项书、需求分析说明书、原型或设计草图 |
| 第 5—8 周 | 搭建项目、完成登录和第一个核心模块 | 可启动项目、登录权限、核心页面或接口 |
| 第 9—12 周 | 完成主要业务流程，补充特色功能 | 可完整演示的业务闭环 |
| 第 13—15 周 | 测试、修复、部署和整理材料 | 测试报告、部署地址、README、演示材料 |
| 第 16 周 | 汇报、答辩和总结 | 最终作品、答辩材料、个人总结 |
如果是小组项目，再补充一张简单分工表：
| 成员 | 主要负责内容 | 阶段成果 |
|---|---|---|
| 成员 A | 用户端页面与接口联调 | 报修提交和进度查询 |
| 成员 B | 管理端与业务处理 | 派单、状态更新和权限控制 |
| 成员 C | 测试、部署与文档整理 | 测试报告、部署与演示材料 |
分工不是把任务简单切成前端和后端
每个人应负责能够说明的功能成果，并参与测试和集成。答辩时，需要说明自己完成了什么、遇到什么问题、怎样验证。
⚠️ 第六步：提前写出风险和应对办法¶
不需要罗列很多风险。优先考虑最可能影响项目完成的 3～5 项：
| 可能风险 | 可能影响 | 应对办法 |
|---|---|---|
| 功能越加越多 | 核心流程无法按时完成 | 坚持必做/选做/本期不做分类，先完成必做 |
| 数据或用户难联系 | 调研和测试缺少依据 | 使用匿名测试数据，优先选择身边可接触的用户 |
| 外部 AI 服务不可用 | AI 功能无法演示 | 基础业务独立运行，AI 功能作为选做增强 |
| 团队协作不同步 | 模块无法集成 | 每周同步代码和任务，提前约定接口与分工 |
| 测试和部署太晚 | 最后无法稳定演示 | 每完成一个模块就启动和测试，提前部署一次 |
🤖 第七步：让 AI 协助检查立项书¶
教师可以提供立项审查 Skill 或 Agent。完成初稿后，在 Trae 中提交文档并这样提问：
收到建议后，按下面原则处理：
| 建议类型 | 处理方式 |
|---|---|
| 用户不清楚、范围过大、闭环缺失 | 优先修改 |
| 调研结论缺少来源 | 补充真实记录或删去该结论 |
| 要求增加复杂架构或大量功能 | 判断是否超出课程范围，通常不直接采纳 |
| 文案表达不够清楚 | 根据实际情况修改 |
AI 审查不能代替教师审核
AI 可以帮你发现明显问题，但项目是否通过立项，仍以教师要求和你的真实项目条件为准。
📋 可直接使用的立项书提纲¶
按下面提纲完成文档即可：
写完后控制在 2—4 页
使用清楚的小标题、表格和流程图，不要用大段空话凑页数。文档应让读者快速判断项目是否值得做、是否做得出来。
✅ 本节验收清单¶
提交《项目选题立项书》前逐项确认：
- 项目名称和一句话介绍清楚；
- 用户当前的问题具体明确；
- 有真实的用户交流或同类产品体验记录；
- 用户、场景和项目目标彼此一致；
- 已写出至少一条核心业务闭环；
- 必做功能能够支撑闭环；
- 已明确选做和本期不做的内容；
- 计划中每个阶段都有可检查成果；
- 已写出主要风险和应对办法；
- AI 提供的内容已由自己检查，没有虚构调研证据；
- 文档篇幅适中，自己能够解释全部内容。
📝 本节小结¶
- 立项书让想法变成计划：写清问题、用户、目标、范围和完成方式；
- 核心闭环最重要：优先说明系统怎样从用户操作走到最终结果；
- 范围要主动控制：必做保证可交付，选做增加特色，本期不做防止失控；
- 计划要有成果：每个阶段都能看到文档、功能、测试或部署结果；
- AI 帮助检查，不替代确认：调研、范围和最终决定必须真实、可解释。