91 lines
6.2 KiB
Markdown
91 lines
6.2 KiB
Markdown
# 第三题 把想法做成 App
|
|
|
|
- **类型**：开发挑战（选做）
|
|
- **基础要求**：使用 Swift 开发可交互的 App，界面优先采用 SwiftUI
|
|
- **提交材料**：个人 Fork 中的项目、需求说明与实际运行展示
|
|
- **AI 规则**：允许辅助开发及生成主要代码，作品须亲自运行、检查，并在二面展示和说明
|
|
|
|
## 两条题目路线
|
|
|
|
### 路线 A 开发第二题的设计
|
|
|
|
从第二题方案中选择一个范围可控的版本实现。可以在开发时调整方案，简述调整原因。
|
|
|
|
在项目中放一份简短需求说明：主要用户、要完成的操作、首版功能、重要数据、正常与异常情形的预期结果，以及与原设计不同的地方。第二题的 PDF 可以引用，不必重新写成长文。
|
|
|
|
### 路线 B 完成统一题目 出门前
|
|
|
|
开发一个可反复使用的出门清单 App，帮助用户建立物品清单、检查是否准备齐全，并在下次使用时保留自己的内容。
|
|
|
|
下面的需求说明就是路线 B 的实现依据。你可以自行决定布局、视觉和代码组织。
|
|
|
|
## 两条路线共用的完成标准
|
|
|
|
1. 有一个可以真正操作的界面，能够完成需求说明中的一条完整核心流程。
|
|
2. 用户能够输入或选择信息，操作会改变应用内容，并看到相应结果或反馈；不能只是几个静态页面互相跳转。
|
|
3. 至少一类与核心用途相关的用户数据能够本地保存，并在彻底退出、重新启动 App 后恢复。例如清单内容、收藏、当前进度或用户配置。
|
|
4. 能处理至少两种与自身场景相关的空白、无结果、取消、重复或操作失败情形，且行为与需求说明一致。
|
|
5. 明确列出已完成、未完成和已知问题，提交足以复现的项目与运行说明。
|
|
|
|
自选题不按功能数量堆难度。共同标准应自然服务于你的用途，不能为了凑项塞入无关功能。如果第二题方案过大，可先实现满足这些标准的小版本。统一题仍需完整实现下方明确列出的基础需求。
|
|
|
|
## 统一题需求说明 出门前
|
|
|
|
### 用户与目标
|
|
|
|
用户想在出门前逐项检查要带的东西，并在第二天继续使用同一份清单。只需维护一张本地清单。
|
|
|
|
### 必须实现的功能
|
|
|
|
| 编号 | 需求 | 可检查的结果 |
|
|
| --- | --- | --- |
|
|
| R1 | 新增、修改名称、删除物品 | 操作后列表中出现对应变化；新增项默认未准备 |
|
|
| R2 | 勾选为已准备，或取消勾选 | 每项状态独立变化，可以改回未准备 |
|
|
| R3 | 显示准备进度 | 显示已准备数与总数；全部准备后给出提示；空清单显示创建提示 |
|
|
| R4 | 开始新一轮检查 | 用户确认后，保留全部物品名称，将勾选全部清除；取消时不改变任何数据 |
|
|
| R5 | 本地保存 | 名称、列表内容与准备状态在彻底退出、重新启动后恢复；新增、改名、删除和重置结果同样保存 |
|
|
|
|
### 统一题的边界规则
|
|
|
|
- 空名称或只有空白的名称不能保存，并向用户说明原因；名称首尾空白在保存前去掉。
|
|
- 同名物品可以存在；修改、删除或勾选其中一项不能误改另一项。
|
|
- 删除物品、取消勾选或开始新一轮后，进度及时更新。
|
|
- 清单为空时不显示“全部准备好了”，而是引导新增物品。
|
|
- 确认开始新一轮和正常继续检查是不同操作，重新打开 App 不应自动清除状态。
|
|
|
|
### 一次验收示例
|
|
|
|
从空清单开始 → 添加“校园卡”和两条“水杯” → 只勾选其中一条水杯，进度为 1/3 → 将另一条改为“钥匙”，三条仍独立 → 删除未勾选的“钥匙”，进度为 1/2 → 退出并重新启动，内容及进度恢复 → 发起新一轮但取消，仍为 1/2 → 再次发起并确认，保留两条名称，进度变为 0/2 → 再次重启仍为 0/2。
|
|
|
|
另外验证空白名称被拒绝，以及最后一条物品删除后出现空清单提示。
|
|
|
|
### 范围限制
|
|
|
|
不要求账号登录、服务器、云同步、通知、地图、多平台适配、应用商店上架或复杂架构。额外功能可以展示，但不能替代基础需求。只有一两个页面也可以是合格的完整作品。
|
|
|
|
## Fork 与提交
|
|
|
|
Fork 本次考核仓库，在个人 Fork 的 [development/](../development/README.md) 目录完成项目，保留原题文件。两条路线都采用这一方式，不要求把完整 App 合并回原题仓库。
|
|
|
|
提交内容包括：
|
|
|
|
- 完整源码和打开、运行项目的方法；
|
|
- 路线选择与需求说明。路线 B 可引用本题 R1–R5，补充自己的完成情况；
|
|
- 实际运行录屏，覆盖核心操作、至少两种边界情形，以及退出重启后的恢复；
|
|
- AI 使用方式、本人如何检查结果、一个遇到的问题与处理过程。没有遇到明显故障可说明一次验证或调整，不必编造经历；
|
|
- 个人 Fork 地址及用于验收的提交版本，在原题仓库提交作品入口。
|
|
|
|
开发目录已预留，见 [开发目录说明](../development/README.md)。截止时刻、作品入口的提交步骤、Fork 可见性和具体设备操作将在正式发布时统一说明。
|
|
|
|
## AI 与二面
|
|
|
|
可以让 AI 协助需求拆分、写代码、解释、排错和修改，甚至由 AI 生成主要代码；你需要负责判断它是否符合要求，并亲自操作验证。选择路线 A 时，第二题的设计文档仍须遵守[第二题的 AI 使用范围](02-design.md)：构思与设计由本人完成，AI 仅辅助润色、排版和制图等表达工作；附带的 AI 使用说明仅作过程采样，不参与评分。
|
|
|
|
二面重点看：能否演示完整流程；是否知道重要信息在哪里变化和保存；如何发现结果不符合需求；为什么保留某个实现或调整。必要时会讨论一个小变化以及怎样实现、验证，实践环节允许继续使用 AI。
|
|
|
|
不要求背诵全部代码，也不按手写代码比例评判。能使用 AI 把作品做成、检查清楚并说明关键选择，同样是有效能力。
|
|
|
|
## 挑战完成标记
|
|
|
|
记录为“未选做”“已尝试”“作品完成待二面确认”或“挑战通过”。挑战通过需要符合路线需求与共同完成标准，并经真实运行和二面确认。未选做不扣共同题成绩。
|