初始化国庆考核题面、模板与开发目录

tasks/01-basics.md

@@ -0,0 +1,97 @@
+# 第一题 出门检查器
+
+类型：基础题。语言：Swift。提交：源码和真实运行截图。全程不得使用 AI。
+
+## 任务背景
+
+出门前，你有一份“需要带的物品”清单，也知道哪些物品已经放进包里。请写一个程序，对照两份清单，告诉你还缺什么。
+
+这道题只需要 Swift 基础语法，不需要制作图形界面。
+
+## 输入和规则
+
+用两个字符串数组表示清单：
+
+```swift
+let requiredItems = ["校园卡", "钥匙", "水杯", "耳机"]
+var packedItems = ["手机", "校园卡", "钥匙"]
+```
+
+- `requiredItems` 是本次需要带的物品。
+- `packedItems` 是已经放进包里的物品，可能包含本次清单之外的东西。
+- 本题保证每个数组内部没有重复名称，也没有空名称。名称按字符串完全相同判断，无需处理错别字、空格清理或模糊匹配。
+- 缺少的物品应按 `requiredItems` 中的先后顺序返回。
+- 本题只判断物品是否存在，不处理数量。
+
+## 你需要完成什么
+
+**1. 编写检查函数。**
+
+自己编写一个名为 `findMissingItems` 的函数，接收两个 `[String]`，返回缺少物品的 `[String]`。为了方便统一检查，请使用下面的函数名称和参数标签：
+
+```swift
+func findMissingItems(required: [String], packed: [String]) -> [String]
+```
+
+上面只是接口说明，不是完整代码。花括号和函数内部逻辑由你编写。
+
+**2. 调用函数并输出结果。**
+
+输出需要带的物品、已装入的物品，以及缺少物品的名称和数量。需要清单非空且没有缺少物品时，输出“已经准备好了，可以出发”；需要清单为空时，输出“本次没有必带物品，无需检查”。
+
+初始数据应得到：缺少水杯、耳机，共 2 项。手机不在需要清单里，不影响结果。输出排版可以自行安排，只要信息清楚，不按装饰性标点或空格扣分。
+
+**3. 修改数据，再次运行。**
+
+在同一个程序中，向已装入清单依次添加“水杯”和“耳机”，每次添加后都重新调用检查函数并打印结果。预期变化：缺两项 → 只缺耳机 → 准备齐全。
+
+**4. 检查其他情形。**
+
+使用下面的公开案例验证函数，并在输出中标明案例名称。程序应适用于符合规则的其他清单，不能把示例答案直接写死。
+
+| 案例 | 需要带的物品 | 已装入的物品 | 函数应返回 |
+| --- | --- | --- | --- |
+| A 初次检查 | 校园卡、钥匙、水杯、耳机 | 手机、校园卡、钥匙 | 水杯、耳机 |
+| B 添加水杯后 | 校园卡、钥匙、水杯、耳机 | 手机、校园卡、钥匙、水杯 | 耳机 |
+| C 再添加耳机后 | 校园卡、钥匙、水杯、耳机 | 手机、校园卡、钥匙、水杯、耳机 | 空数组 |
+| D 包里什么都没有 | 钥匙、水杯 | 空数组 | 钥匙、水杯 |
+| E 本次没有必带物品 | 空数组 | 手机 | 空数组 |
+| F 两份清单都为空 | 空数组 | 空数组 | 空数组 |
+
+C 输出准备齐全的提示；E、F 输出无需检查的提示。修改数组和运行这些案例属于同一道基础题，不另算拔高任务。
+
+## 提交材料
+
+1. `main.swift`：包含自己编写的函数、调用与上述运行案例；命名清楚，适当添加注释。
+2. 运行截图：能够辨认程序实际输出，覆盖 A–F。可以分多张截图，不要求把所有内容挤在一张图里。
+
+源码和截图应来自同一个最终版本。允许裁去无关窗口，不得修改运行结果文字、拼造结果或用 AI 生成截图。未全部完成时可提交当前源码与实际结果，标注未完成处。
+
+## 学习范围与资源
+
+学习到能使用下面这些内容即可：
+
+- `let`、`var`，字符串与布尔值；
+- 数组的创建、遍历、添加、数量和空数组；
+- `if/else`、`for-in`；
+- 函数参数、返回值和调用；
+- `print` 输出及字符串插值。
+
+可从[菜鸟教程 Swift 目录](https://www.runoob.com/swift/swift-tutorial.html)按以上主题阅读。无需通读可选类型、结构体、类、闭包、泛型或 SwiftUI。遇到教程样例与所用版本不一致，可参考下列 Swift 官方说明或询问授课干部。
+
+- [基础语法](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/thebasics/)
+- [数组与集合](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/collectiontypes/)
+- [条件与循环](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/controlflow/)
+- [函数](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/functions/)
+
+可以用循环判断，也可以使用自己理解的标准库方法。不以代码行数、运行速度排名或使用高级语法的数量评判本题。
+
+## 独立完成规则
+
+本题不得使用 AI，包括解题思路、代码生成或 AI 补全、代码解释、排错。可以阅读普通教程和官方文档，使用编辑器的非 AI 语法提示，向干部询问环境问题或某个基础概念；不能让他人代写本题。
+
+请亲自运行，比较预期与实际结果，必要时修改后重试。无需额外提交调试报告，也不要求必须遇到或制造某个错误。二面可能请你解释某段代码，或预测改变一份清单后会输出什么。
+
+## 评价重点
+
+规则是否正确；空数组等情形是否处理；是否能随输入变化得到结果；源码是否清楚；是否有本人真实运行的结果。截图本身不能证明独立完成，评价会结合源码及二面交流。

tasks/02-design.md

@@ -0,0 +1,57 @@
+# 第二题 为一个小麻烦设计 App
+
+类型：设计题。不需要代码基础。只提交一份 PDF 设计文档。
+
+## 任务背景
+
+请选择自己或身边人在学习、校园生活、兴趣活动中遇到的一个小麻烦，为它设计一个手机 App。
+
+题材可以自选。例如：出门总是漏带东西，想看的作品散落在聊天记录里，社团活动准备时不知道还缺什么。这些只用于帮助理解范围，你可以选择完全不同的问题。
+
+你的任务是让我们看懂：谁会用它、为什么需要它、怎样操作，以及这样设计的理由。一个有具体用法的小想法就足够，不要求前所未有的创意。
+
+## 设计文档应包含什么
+
+**1. 一个具体场景与简短方案。**
+
+说明使用者在什么时候遇到什么困难，现在通常怎么处理，你的 App 想改善哪一步。亲身经历、观察或合理假设都可以，假设请写明，不需要为本题专门进行正式访谈，也不能编造调查。
+
+列出首版最重要的 2–3 项功能。再写一个你决定暂时不做的功能，以及暂缓原因。
+
+**2. 能看懂操作的草图。**
+
+画出完成核心任务需要的页面或状态，建议 2–4 幅。可以手绘拍照，也可以用任何绘图、幻灯片或文档工具。标出主要信息、可以操作的位置和操作后会发生什么。
+
+如果只有一个页面，可以画它在不同操作前后的状态。页面数量和精美程度不作为高分依据。
+
+**3. 一次完整使用示例。**
+
+用一个具体例子串起“打开 App → 做哪些操作 → 看到哪些反馈 → 完成什么事情”。尽量与草图编号对应，让别人能顺着你的说明走一遍。
+
+再补充一种不顺利的情况，例如输入为空、操作错了、没有搜索结果、取消操作或再次打开 App。说明用户会看到什么、接下来能怎么做。
+
+**4. 自己的选择与反思。**
+
+挑一处设计，说明你为什么这样安排；如果还有一种做法，为什么暂时没选。再说明目前最不确定的一点，以及怎样了解这种设计是否有帮助。
+
+可以用[模板提纲](../templates/design-document.md)组织内容，建议 3–4 页，清楚简短即可。页面建议只用于控制工作量，不是硬性扣分标准。
+
+## 不需要提交什么
+
+不需要源码、数据模型、数据库设计、技术选型、接口文档或架构图，也不要求研究怎样实现。正文用自己的话说明即可，不要求使用产品或设计行业术语。
+
+## AI 使用范围
+
+想法、功能取舍、操作过程和设计理由必须由你自己提出。
+
+AI 只可以润色你已经写好的文字，或整理、美化你已经画出并决定好的草图。不得让 AI 代选问题、构思功能、设计交互或代写思考。如果润色过程中新增了功能或改变了操作，应去掉这些越界内容，按自己的方案表达。
+
+在 PDF 最后用几句话说明是否使用 AI，以及用于哪些润色。没有使用就写“未使用”。可以保留自己最初的短笔记或草图，便于二面说明；本题只要求提交一份 PDF，不要求额外上传私人聊天记录。
+
+## 提交与评价
+
+提交 `design.pdf`，包含简短方案、草图、操作示例、选择理由及 AI 使用说明。
+
+我们主要看问题是否具体、功能是否服务这个问题、使用过程能否讲通、是否考虑反馈和不顺利的情况，以及设计理由是否来自自己的思考。漂亮排版和写作长度不能代替这些内容。
+
+二面会围绕你的方案追问。例如：为什么把这个操作放在这里；如果用户取消了怎么办；只保留一个功能时你会留下什么。允许坦诚指出还没想清楚的地方，不要求背诵文档。

tasks/03-development.md

@@ -0,0 +1,87 @@
+# 第三题 把想法做成 App
+
+类型：选做开发挑战。使用 Swift 开发可交互的 App，界面优先采用 SwiftUI。允许 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 重写第二题的想法。
+
+二面重点看：能否演示完整流程；是否知道重要信息在哪里变化和保存；如何发现结果不符合需求；为什么保留某个实现或调整。必要时会讨论一个小变化以及怎样实现、验证，实践环节允许继续使用 AI。
+
+不要求背诵全部代码，也不按手写代码比例评判。能使用 AI 把作品做成、检查清楚并说明关键选择，同样是有效能力。
+
+## 挑战完成标记
+
+记录为“未选做”“已尝试”“作品完成待二面确认”或“挑战通过”。挑战通过需要符合路线需求与共同完成标准，并经真实运行和二面确认。未选做不扣共同题成绩。