工程思维逐页 PPT 正文
使用说明
这份页面用于帮助讲师把工程思维模块直接扩展成可投屏、可复制到 PPT 里的详细课件。
- 每个模块建议控制在 10 到 20 分钟
- 每页尽量只讲 1 个概念，再立刻回到学生项目里应用
- 文案以“青少年能听懂、讲师能直接拿来讲”为标准
模块 1 产品经理思维
| 页码 | 页面标题 | 建议正文 |
|---|---|---|
| 第 1 页 | 为什么项目不能一上来就写代码 | 很多项目不是做不出来，而是从一开始就没想清楚要解决什么问题。先想明白，再开始做，后面会省很多时间。 |
| 第 2 页 | 谁是你的用户 | 用户不是“所有人”，而是最可能真正需要这个项目的一类人。比如同班同学、社团成员、值日组长、图书角管理员。 |
| 第 3 页 | 什么是使用场景 | 场景就是用户在什么时刻、因为什么原因，会真的打开你的项目。一个真实场景，比很多空泛功能更重要。 |
| 第 4 页 | 问题和需求的区别 | 问题是用户现在的麻烦，需求是你准备怎么帮他解决。先抓问题，再谈功能，项目会更稳。 |
| 第 5 页 | 什么是 MVP | MVP 就是第一版最少要做什么，才能让别人看懂这个项目有价值。它不是最粗糙版本，而是最小可展示版本。 |
| 第 6 页 | 验收标准怎么写 | 验收标准可以用一句话来写: 如果用户能完成某个动作，并得到明确结果，这个功能就算成立。 |
| 第 7 页 | 课堂应用 | 请每组用一句话补全自己的项目: 给谁用，在什么场景下，解决什么问题，第一版先做什么。 |
模块 2 Web 项目全景图
| 页码 | 页面标题 | 建议正文 |
|---|---|---|
| 第 1 页 | 一个 Web 项目不只有页面 | 你在浏览器里看到的页面，只是整个系统里最容易看见的一层。很多真正的逻辑，其实在页面后面。 |
| 第 2 页 | 用户端在做什么 | 用户端就是普通用户直接看到和操作的页面，比如首页、填写页、结果页、展示页。它负责体验和交互。 |
| 第 3 页 | 管理员端在做什么 | 管理员端给老师、维护者、社团负责人这类角色使用，用来查看数据、修改内容、审核信息和管理流程。 |
| 第 4 页 | 服务端在做什么 | 服务端负责处理规则，比如用户提交后要不要保存、数据是否合格、结果应该返回什么。它像项目的大脑和规则执行者。 |
| 第 5 页 | 数据库在做什么 | 数据库负责把信息保存下来，让它们以后还能查、还能改、还能统计。没有数据库，很多项目就只能停留在演示层。 |
| 第 6 页 | 用校园来类比 | 用户端像同学办事窗口，管理员端像老师后台，服务端像办公室处理流程，数据库像学校档案室。这个类比可以帮助你快速理解每层职责。 |
| 第 7 页 | A / B / C 三种项目等级 | A 级是单前端展示型，B 级是前端加简单接口或数据，C 级是用户端、后台、服务和数据库都具备。不同组可以做不同等级。 |
| 第 8 页 | 课堂应用 | 请每组判断自己的项目属于 A、B、C 哪一级，并说出如果要升级一级，最需要补哪一层。 |
模块 3 前端与管理员端
| 页码 | 页面标题 | 建议正文 |
|---|---|---|
| 第 1 页 | 前端不只是“做漂亮页面” | 前端除了决定页面长什么样，还负责按钮、输入框、提示信息、跳转、状态变化和整体使用体验。 |
| 第 2 页 | 用户端和管理员端为什么不同 | 因为它们服务的是不同角色。用户端强调简单好用，管理员端更强调查看、修改、筛选和管理。 |
| 第 3 页 | 页面和组件有什么区别 | 页面是一个完整场景，比如首页或详情页。组件是页面里可以反复复用的小区块，比如卡片、按钮组、导航条。 |
| 第 4 页 | 为什么项目目录要分层 | 如果所有代码都堆在一起，后面会越来越难改。把页面、组件、样式、资源分开，项目会更容易维护。 |
| 第 5 页 | 常见前端技术栈 | HTML、CSS、JavaScript 是基础。Vue 和 React 这类框架会帮助我们更高效地组织页面和交互。 |
| 第 6 页 | 管理员端是不是一定要做 | 不一定。先看项目有没有“管理内容、管理用户、查看记录”的需要。如果没有，可以先不做。 |
| 第 7 页 | 课堂应用 | 请每组画出自己的用户端页面，再补充一个“如果以后要管理这个项目，后台可能会长什么样”的草图。 |
模块 4 API 与后端分层
| 页码 | 页面标题 | 建议正文 |
|---|---|---|
| 第 1 页 | 为什么按钮点下去不一定直接出结果 | 因为很多结果不是前端自己能决定的，它需要把请求发出去，再由服务端处理规则后返回。 |
| 第 2 页 | 什么是 API | API 可以理解为页面和服务端之间约定好的沟通方式。前端按规则发请求，后端按规则返回结果。 |
| 第 3 页 | 一次请求的过程 | 用户点击按钮，前端整理信息，发送请求，服务端处理，返回数据，页面再把结果展示出来。 |
| 第 4 页 | 后端为什么要分层 | 如果所有逻辑都混在一起，后面会很乱。常见做法是把接请求、处理规则、读写数据分成不同层。 |
| 第 5 页 | Controller、Service、Repository 是什么 | Controller 负责接收请求，Service 负责业务规则，Repository 负责和数据打交道。分层后，修改和排错都会更清楚。 |
| 第 6 页 | 常见后端技术栈 | Node.js、Python、Java 都可以做后端。对青少年项目来说，先理解“职责怎么拆”比先背语言名字更重要。 |
| 第 7 页 | 课堂应用 | 请每组挑一个按钮，比如“提交作业”或“添加记录”，画出它背后可能经过的前端、API、服务端步骤。 |
模块 5 数据库与数据模型
| 页码 | 页面标题 | 建议正文 |
|---|---|---|
| 第 1 页 | 为什么不是所有信息都放在页面里 | 页面只负责显示和交互，真正需要长期留下来的信息，应该保存在数据库里。 |
| 第 2 页 | 什么情况下需要数据库 | 当项目里有用户、任务、记录、反馈、成绩、借阅、打卡这类需要保存和反复读取的信息时，就应该考虑数据库。 |
| 第 3 页 | 5 个基础概念 | 表是分类存数据的地方，行是一条记录，列是字段，主键用来区分每条记录，关系表示不同表之间的联系。 |
| 第 4 页 | 什么叫数据模型 | 数据模型就是先想清楚项目里有哪些对象，它们分别要存什么信息，以及它们之间有什么关系。 |
| 第 5 页 | 一个校园项目例子 | 作业规划助手可能会有用户表、任务表、标签表和完成记录表。这样才能支持查看、修改和统计。 |
| 第 6 页 | 为什么不用 Excel 顶到底 | Excel 适合少量手工整理，但当多人使用、频繁变化、需要查询和关联时，数据库会更稳定。 |
| 第 7 页 | 课堂应用 | 请每组写出自己项目里最值得长期保存的 3 类信息，并为其中 1 类设计字段。 |
模块 6 技术栈与软件工程
| 页码 | 页面标题 | 建议正文 |
|---|---|---|
| 第 1 页 | 什么是技术栈 | 技术栈就是为了完成一个项目而选择的一组语言、框架、工具和部署方式。 |
| 第 2 页 | 一个 Web 项目的常见几层 | 常见会有前端、后端、数据库和部署平台，但不是每个项目都必须全部具备。 |
| 第 3 页 | 没有“最好的技术栈” | 不同项目适合不同组合。展示型项目可以轻一点，工具型和全栈型项目需要更多层次。 |
| 第 4 页 | 软件工程不是大公司专用词 | 只要你想把项目做稳、做清楚、做完，就已经在用软件工程思维了。 |
| 第 5 页 | 最值得固定下来的 4 件事 | 记录版本、记录 bug、做简单测试、安排下一次迭代。这四件事能让项目越来越稳定。 |
| 第 6 页 | 什么是发布 | 发布就是把项目整理成别人可以打开、可以试用、可以反馈的版本。发布不是结束，而是下一轮改进的开始。 |
| 第 7 页 | 迭代为什么重要 | 第一次做出来只是起点，真正好的项目都是在试用和反馈中慢慢长出来的。 |
| 第 8 页 | 课堂应用 | 请每组写出当前技术组合、已知最大风险、下一次版本目标，并判断现在最应该优先做什么。 |