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

.gitignore

@@ -0,0 +1,27 @@
+# macOS
+.DS_Store
+._*
+
+# Swift Package Manager / build outputs
+.build/
+.swiftpm/
+build/
+DerivedData/
+*.ipa
+*.dSYM/
+*.dSYM.zip
+
+# Xcode user-specific settings; keep shared project files
+xcuserdata/
+*.xcuserstate
+*.xccheckout
+*.xcscmblueprint
+
+# Local credentials and editor swap files
+.env
+.env.*
+!.env.example
+*.p12
+*.mobileprovision
+*.swp
+*.swo

README.md

@@ -1,3 +1,48 @@
-# iOS_2026_National_Day
+# iOS 部 2026 国庆考核
 
-ITStudio iOS 部 2026 国庆考核：Swift 基础、App 设计与选做开发挑战（筹备中）
+> **筹备中 · 题面初稿**（2026-09-21）
+> 当前仓库用于题目审阅和完善，尚未正式开放提交。截止时刻、提交步骤、设备环境和最终评价细则将在发布前补齐。
+
+欢迎来到 ITStudio iOS 部国庆考核。我们希望通过两道共同题和一道选做题，了解你怎样学习基础编程、思考一个应用的用途，以及将想法做成作品。
+
+## 三道题
+
+| 题目 | 你要完成什么 | 提交材料 | AI 使用规则 |
+| --- | --- | --- | --- |
+| [第一题：出门检查器](tasks/01-basics.md) · 必做 | 学习 Swift 基础，独立编写并运行一个清单检查程序 | `main.swift`、真实运行截图 | 全程不得使用 AI |
+| [第二题：为一个小麻烦设计 App](tasks/02-design.md) · 必做 | 提出自己的方案，用草图和操作示例说明 | 一份 `design.pdf` | 仅可润色本人已有的文字和草图 |
+| [第三题：把想法做成 App](tasks/03-development.md) · 选做 | 开发第二题方案，或统一题目“出门前” | 个人 Fork 中的项目、需求说明、实际运行展示 | 允许使用 AI 完成开发，须亲自检查和说明 |
+
+第二题不需要编程基础，可以独立于第一题完成。第三题未选做不扣共同题成绩，挑战完成情况单独记录。
+
+## 从这里开始
+
+1. 阅读对应题面，尤其是每题的完成要求、提交材料和 AI 规则。
+2. 第一题的学习资源见题面；第二题可以复制[设计文档模板提纲](templates/design-document.md)，在熟悉的文档工具中填写并导出 PDF。
+3. 第三题需要 Fork [本仓库](https://git.itouc.cn/ITStudio_OUC/iOS_2026_National_Day)，在个人 Fork 的 [development/](development/README.md) 目录开发，保留原题文件。
+
+## 提交安排
+
+- **第一、二题：**提交到本次考核原仓库。具体采用哪个上传入口、怎样命名和组织材料，将在正式发布时统一说明；目前尚未开放提交。
+- **第三题：**完整项目保留在个人 Fork，在原仓库提交 Fork 链接及用于验收的提交版本。作品入口的提交步骤及 Fork 可见性安排待发布时说明。
+- 截止日期与时刻、材料可见范围、环境说明、求助渠道：**待公布**。
+
+源码、截图和录屏应对应实际完成的版本。允许如实提交未完成的部分，不得拼造运行结果或编造经历。遇到环境或提交问题时，保留当前文件与现象，按正式通知的渠道求助。
+
+## 评价与二面
+
+第一题关注代码是否符合规则、能否随输入变化、是否亲自运行并理解结果；第二题关注问题、操作和取舍是否来自自己的思考；第三题关注作品是否真正可用，以及如何实现、验证和改进。
+
+二面会围绕实际提交的内容交流。第三题允许 AI 参与开发，能用好工具、检查结果并说明关键选择，同样是有效能力。详细规则以各题题面为准；最终评分细则会在开放提交前公布。
+
+## 仓库目录
+
+```text
+tasks/                 三道题的题面与需求说明
+templates/             第二题设计文档模板提纲
+development/           第三题个人 Fork 的开发目录
+README.md              考核入口与统一说明
+.gitignore             Swift/Xcode 常见临时文件忽略规则
+```
+
+当前默认分支为 `main`。仓库尚未配置自动检查（CI）；检查范围及提交流程确定后再补齐。题面仍可能在正式发布前调整，请以发布时的仓库说明为准。

development/README.md

@@ -0,0 +1,25 @@
+# 第三题开发目录
+
+选做第三题时，先 Fork 本仓库，再在个人 Fork 的这个目录中放置项目。完整要求见[第三题题面](../tasks/03-development.md)。本目录目前只有说明，没有 App 成品或解题代码。
+
+建议按下面的方式组织；可以按自己的项目需要调整：
+
+```text
+development/
+├── README.md          改写为自己的作品说明与运行方法
+├── requirements.md    简短需求、路线选择与完成情况
+├── App/               Swift 项目和必要资源
+└── demo/              实际运行录屏，或录屏访问说明
+```
+
+在个人 Fork 中，请将这份 README 改为自己的作品入口，至少说明：
+
+1. 作品名称、选择路线 A 还是 B、核心用途。
+2. 怎样打开与运行项目，以及实际使用的工具版本和运行设备或模拟器。
+3. 已完成、未完成和已知问题；路线 B 可对照 R1–R5 逐项说明。
+4. 需求说明和真实演示的位置，演示应覆盖核心操作、边界情形与重启恢复。
+5. AI 使用方式、本人怎样检查结果，以及一次真实问题的处理或验证、调整。
+
+提交时，将个人 Fork 地址和验收用的提交版本通过原仓库后续公布的入口提交。无需将完整 App 合并回原题仓库。保留题面和模板文件，避免把构建产物、个人账号凭据或设备专属文件提交到仓库。
+
+设备环境、录屏提交方式及大小限制会在正式发布时补充。

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 把作品做成、检查清楚并说明关键选择，同样是有效能力。
+
+## 挑战完成标记
+
+记录为“未选做”“已尝试”“作品完成待二面确认”或“挑战通过”。挑战通过需要符合路线需求与共同完成标准，并经真实运行和二面确认。未选做不扣共同题成绩。

templates/design-document.md

@@ -0,0 +1,51 @@
+# 第二题设计文档模板提纲
+
+这是内容模板，可复制到 Word、Pages、PowerPoint 等熟悉的工具中编写，最终只提交 PDF。下面的方括号是填写提示，不是标准答案。建议 3–4 页；草图可以手绘。
+
+## 我的 App 与使用场景
+
+作品名称：[填写]
+
+提交标识：[按后续统一规则填写]
+
+给谁用：[具体到一类人或一个人]
+
+什么时候遇到什么麻烦：[两三句话，可以说明亲身经历、观察或假设]
+
+现在怎样处理，我想改善哪里：[简短说明]
+
+## 第一版方案
+
+最重要的 2–3 项功能：[每项一句，说明对这个场景的用途]
+
+暂时不做的一项功能及原因：[填写]
+
+## 草图与使用示例
+
+[插入主要页面或状态草图，编号 ①②③；标出主要文字、操作位置、点击后的变化。]
+
+一次正常使用：
+
+| 步骤 | 用户做什么 | 画面出现什么，事情怎样变化 |
+| --- | --- | --- |
+| 1 | [填写] | [对应草图编号] |
+| 2 | [填写] | [对应草图编号] |
+| 3 | [可按需要增减行] | [填写] |
+
+一种不顺利的情况：[输入为空、取消、无结果、误操作等任选一种与作品相关的情形]
+
+用户会看到什么，接下来能怎么办：[填写，可加草图]
+
+## 我的选择与疑问
+
+我做过的一处选择及理由：[写清具体位置或操作；可比较另一种做法]
+
+我最不确定的地方：[填写]
+
+我准备怎样了解设计是否有帮助：[例如请一位同学按草图走一遍，观察什么；无需声称已执行]
+
+## AI 使用说明
+
+[未使用 AI／使用了哪些工具润色哪些原有文字或草图。想法、功能、交互和设计理由由本人提出。]
+
+导出前检查：草图与文字能对应、关键文字可读、没有遗留填写提示、未把尚未做过的访谈或验证写成已完成。