Upload files to "逐课课纲"

逐课课纲/iOS试听课_部门与开发概览.md

@@ -0,0 +1,57 @@
+# iOS 试听课：部门与开发概览
+
+> 状态：2026-09-03 定稿校对稿，待社团审核  
+> 配套文件：[十课初步规划](../iOS部2026十课初步规划.md)
+
+## 课程定位
+
+面向接近零基础、正在了解或考虑报名 iOS 部方向的学员，通过部门介绍、开发科普、真实作品和交流答疑，帮助学员判断是否愿意继续学习。
+
+本节是 iOS 部自主试听课，与教学部统一公开课相互独立；课程整体保持 1 节试听课＋9 节部门课。
+
+试听不要求拥有 Mac、安装 Xcode、现场编程或提交开发作业，不进行技术考核，也不要求当场决定报名。
+
+
+## 教学目标
+
+完成试听课后，学员应能够：
+
+1. 大致了解 iOS 部的基本概况、活动方式和项目出口。
+2. 知道 iOS App 的开发过程不仅是“写代码”，还包括问题发现、界面设计、数据与逻辑、测试和展示。
+3. 知道后续 9 节部门课的迷你作品、工具入门、技术拓展、课程回顾、课后投入和作品记录方式。
+4. 能够提出自己最关心的问题，并初步判断是否愿意继续学习 iOS 开发。
+
+## 教学内容
+
+### 1. 认识 iOS 部
+
+- 介绍部门主要学习什么，以及日常学习、答疑、项目协作和比赛实践的基本方式。
+- 说明课程从小作品起步，重视真实运行、成就感和继续学习的信心，不承诺九节课掌握完整技术栈或独立完成正式 App。
+
+### 2. 了解 App 的开发过程
+
+- 围绕“发现问题与用户需求 → 设计界面和功能 → 开发实现 → 测试改进 → 分发体验”说明一个想法怎样变成 App。
+- 结合流程简要介绍 iOS、App、Swift、SwiftUI、Xcode、模拟器和 App Store 的作用，不展开语法、架构、签名或发布操作。
+
+### 3. 看见真实作品与成长过程
+
+- 选取 2–3 个不同阶段的真实作品，展示从入门练习到项目实践的可能路径。
+- 每个作品重点讲清：帮助谁解决什么问题、一个核心操作，以及开发中遇到的真实困难。
+- 以可见效果和使用体验为主，不堆积代码、技术名词或获奖信息；如实说明个人、小组及 AI 的贡献。
+
+### 4. 说明后续怎样学习
+
+- 借用十课规划中的课程地图，概述“第一次运行 → AI 与 Git → 页面、交互与数据 → 项目组织 → 回顾与继续学习”，不逐课复述技术细节。
+- 说明课堂跟做与 Demo 讲解两种形式、最低与建议标准，以及每次基础课后实践约 30–60 分钟的参考投入；建议项自愿，不按作品复杂度排名。
+- 后续实践需要可运行课程内容的 Mac，设备兼容性另行核对；部门课 01 前发送安装资料，鼓励但不强制提前配置。
+- AI 可以辅助制作和排错，但不能代替学员实际 Build/Run 与判断。GitHub 用于提交作品和记录成长，公开内容须保护隐私；本节不演示工具操作。
+- 部门课 09 以回顾、轻量分享和答疑收束，不要求新作品、GitHub PR、代码 Demo 或正式课后作业。比赛和项目是后续入口，具体安排以确认的信息为准。
+
+## 互动与课后说明
+
+- 在作品展示或课程介绍中穿插轻量提问，例如“哪个作品最吸引你”“你最担心设备、时间还是零基础跟不上”；学员可用一句话或关键词回应，不要求技术答案。
+- 保留开放答疑，重点回应学习方式、设备、时间投入、部门日常和报名问题。尚未确认的信息记录后回复，不现场编造。
+- 结束时邀请学员自愿表达一个兴趣方向或顾虑；反馈用于了解需求，不依据表达技巧、技术基础或设备情况作录取判断。
+- 课后提供课程地图、已确认的报名或咨询渠道，以及未答问题的后续回复；不布置统一作业或要求立即安装开发工具。
+
+本节是否讲清，主要看学员是否更了解部门、学习方式和后续投入，以及能否提出具体兴趣或问题，不以记住技术名词的数量衡量。

逐课课纲/部门课01_第一次运行与SwiftUI组件万花筒.md

@@ -0,0 +1,68 @@
+# 部门课 01：第一次运行与 SwiftUI 组件万花筒
+
+## 教学目标
+
+- 认识 Xcode、SwiftUI 项目、模拟器和运行按钮分别承担什么作用。
+- 完整了解 Xcode、必要组件和 iOS Simulator Runtime 的安装配置过程。
+- 能从 Xcode 系统模板创建一个基础 SwiftUI App。
+- 能将授课干部提供的“SwiftUI 组件万花筒”Demo 放入项目，并在模拟器中成功 Build/Run。
+- 通过一个页面观察 SwiftUI 提供的多种标准组件和样式，为后续课程建立兴趣与方向感。
+- 知道可以自由修改文字、图标、颜色或控件初始值，但本节不要求理解全部代码。
+
+## 教学内容
+
+### 1. 环境与工具
+
+- 课前提前发送安装说明和资料，鼓励先配置以节约上课时间，但不强制提前完成。
+- 课堂完整演示 Xcode 下载、安装、首次启动、必要组件和 iOS Simulator Runtime 的配置过程。
+- 不集体等待大型下载。尚未完成安装的学员课后继续配置，尽量在部门课 2 开始前跑通环境。
+- 简单认识项目区、代码编辑区、运行目标、运行按钮、模拟器和错误提示位置。
+
+### 2. 创建第一个项目
+
+- 从 Xcode 系统模板创建最基础的 SwiftUI iOS App。
+- 选择一个可用的模拟器作为运行目标，完成第一次 Build/Run。
+- 说明 `ContentView.swift` 是本节主要修改位置，不系统讲解工程结构或 Swift 语法。
+
+### 3. SwiftUI 组件万花筒 Demo
+
+- Demo 使用单页面、可滚动的结构，不依赖网络、外部素材、数据持久化或多页面导航。
+- 页面展示以下标准组件及少量简单变体：
+  - `Text`、`Label` 和 SF Symbols；
+  - 普通按钮与强调按钮；
+  - `Toggle`、`Slider`、`Stepper` 等简单控件；
+  - `TextField` 等输入组件；
+  - `ProgressView`、基础图形、颜色和圆角卡片。
+- 控件可以具有简单的本地反馈，但本节只观察效果，不提前讲授状态管理、信息流或组件 API。
+- 告诉学员这些组件会在后续页面、交互和数据课程中逐步拆开学习，本节只需运行、观察和尝试。
+
+### 4. 自由尝试
+
+- 鼓励学员自由修改一处文字、SF Symbol、颜色、按钮标题或控件初始值。
+- 修改属于自由尝试，不作为最低完成条件。
+- 演示撤销和重新运行，避免一次改坏后继续无序修改。
+- 本节不教授 Git，作品不需要上传仓库。
+
+## 课后作业
+
+### 最低完成标准
+
+- Xcode 能正常启动，且至少有一个可用的 iOS Simulator Runtime。
+- 使用 Xcode 系统模板创建项目，放入授课干部提供的组件万花筒 Demo。
+- 在模拟器中成功 Build/Run，并显示主要组件。
+- 保存项目，供后续继续使用或检查。
+
+### 建议完成标准
+
+- 自由修改一处文字、SF Symbol、颜色或控件初始值，再运行观察变化。
+- 探索感兴趣的组件，不要求修改指定数量或解释全部代码。
+
+尚未完成配置的学员课后继续安装；遇到问题时保留完整错误文字、必要截图和已尝试步骤。本节不要求当堂完成大型下载，不要求上传 GitHub、完成个人页面或完整 App。
+
+## 验收方式
+
+- 以组件万花筒在模拟器中真实 Build/Run 为基础完成标准，个人修改不作为门槛。
+- 无需正式提交作业；可以用运行截图记录结果，也可以在下一次上课时现场运行确认。
+- 不要求解释完整 Swift 语法、状态管理或全部组件代码。
+- 受设备、系统或下载影响未完成时，记录具体卡点并提供帮助，不把尝试记录等同于已经运行成功。
+- 部门课 02 开始前尽量完成环境和 Demo 运行，以便进入 AI 与 Git 工具实践。

逐课课纲/部门课02_AI与Git开发工具入门.md

@@ -0,0 +1,79 @@
+# 部门课 02：AI 与 Git 开发工具入门
+
+## 教学目标
+
+- 了解 vibe coding 的基本过程，以及 AI 在开发中适合协助什么、哪些判断仍需由自己负责。
+- 不限定 AI 平台，能够使用自己已有的 ChatGPT、Claude、DeepSeek 等工具完成一次小型 SwiftUI 开发任务。
+- 会把任务目标、开发环境、功能约束、实际现象和下一步要求告诉 AI。
+- 能把 AI 给出的结果放入 Xcode，通过 Build/Run 判断是否真实可用，并根据完整错误继续反馈和调整。
+- 理解部门仓库、个人 Fork、本地仓库、分支、Commit、Push 和 Pull Request 的最小关系。
+- 能从个人 Fork 的作业分支向部门公开仓库提交一次 PR。
+- 知道公开提交中不能包含真实隐私、凭证、密钥、构建缓存或未经授权的个人资料。
+
+## 教学内容
+
+### 1. AI 开发与 vibe coding
+
+- 介绍“提出目标—生成起点—运行观察—反馈问题—继续调整”的基本循环。
+- 分享授课干部在实际开发中使用 AI 的基本经验：
+  - 先说清楚想做什么，再让 AI 写代码；
+  - 给出 SwiftUI、Xcode 和目标系统等必要背景；
+  - 给出功能边界和明确的不做范围；
+  - 小型独立任务可以让 AI 生成一个可运行起点，之后一次只调整一个问题；
+  - 报错时提供完整错误和最小相关代码，不只说“运行不了”；
+  - AI 写出的代码不一定正确，运行结果和产品取舍仍由自己负责；
+  - 不把密码、令牌、私人资料或不应公开的项目内容交给 AI。
+- 课堂使用一个极小示例演示完整循环，但不系统教授示例涉及的 SwiftUI 概念。
+- 课后独立开发任务由授课干部另行发布要求，需控制在接近零基础的学员借助 AI 约 30–60 分钟能够形成可运行结果的范围。
+
+### 2. Git 与 GitHub 最小地图
+
+只讲解完成作业所需的基本工作流：
+
+- 部门仓库是最终收集作品的公开仓库。
+- Fork 是学员 GitHub 账号下的个人副本。
+- 本地仓库是 Mac 上实际操作的项目文件夹。
+- 分支用于隔离本次作业。
+- Commit 保存一次改动记录。
+- Push 把个人分支上传到个人 Fork。
+- PR 请求授课干部将个人分支中的作品合并到部门仓库。
+
+本节不扩展讲解复杂历史、冲突处理、rebase、多人协作策略或 Git 内部原理。
+
+### 3. 首次 Fork 与 PR
+
+- 授课干部演示建立部门公开仓库，并带领学员认识“登录—Fork 与克隆—建立作业分支—Commit—Push—发起 PR”的关系。
+- 学员只修改自己的目录，不需要部门仓库的直接写入权限。
+- PR 简要记录任务、AI 使用方式、运行结果和当前问题，不要求重复另写 README。
+- 登录工具、具体命令、远端关系、目录、分支与 PR 模板在备课时结合实际仓库确定，不在课纲中固定。
+- 公开提交前检查源码、附件及提交作者信息，保护个人邮箱与账号凭证；不强制推送，不提交敏感资料、构建缓存、他人文件或未经授权的素材。
+
+备课时可参考 [GitHub CLI Fork 说明](https://cli.github.com/manual/gh_repo_fork)、[GitHub CLI PR 说明](https://cli.github.com/manual/gh_pr_create) 和 [GitHub 提交邮箱设置](https://docs.github.com/en/account-and-profile/how-tos/email-preferences/setting-your-commit-email-address?platform=mac)。具体采用方式以实际环境核对结果为准。
+
+## 课后作业
+
+具体题目与提交安排由授课干部在备课时另行准备，任务保持小型、边界明确，不依赖网络或第三方依赖。
+
+### 最低完成标准
+
+- 根据任务要求，使用任意已有 AI 工具完成一个小型 SwiftUI 项目。
+- 结果体现自己的任务目标或可见调整，而不是仅保留未验证的 AI 回复。
+- 在 Xcode 模拟器中实际 Build/Run，并用一张模拟器截图记录结果。
+- 将完整源码放入个人 Fork 的指定目录，通过作业分支发起 PR。
+- 在 PR 中简要记录任务、AI 使用方式、运行结果和未解决的问题。
+
+### 建议完成标准
+
+- 在基础结果上尝试一处自己感兴趣的局部改动，并重新运行观察。
+- 简要记录一次 AI 建议与实际结果不同的地方，帮助后续求助或调整。
+
+建议项不影响基础通过。未完成时可以发起 Draft PR，保留当前项目、完整错误和已尝试步骤；无法发起 PR 时按授课干部约定的渠道提供这些信息。
+
+## 验收方式
+
+- **参与记录**：实际尝试了任务，并提供当前项目、结果或具体错误及尝试记录。账号、网络或 Git 故障不抹去参与，也不等于作品已经完成。
+- **基础作品完成**：对应最低标准的功能在模拟器中实际运行；截图用于记录结果，不能代替真实 Build/Run。
+- **正式 PR 合并**：完整项目位于约定的个人目录，运行结果和简短说明可核对，未提交敏感信息、构建缓存、他人文件或公共结构改动。
+- 未运行成功的 Draft PR 保留并提供帮助，修正后再转为正式 PR。
+- 简短说明用于表达目标、结果和问题；表达不完整时给予反馈，不因措辞或术语不够准确拒绝已达到基础要求的作品。
+- 首次 PR 不以代码结构、算法质量、额外功能或是否完全理解 AI 生成代码作为门槛。满足条件后，授课干部给出简短反馈并合并。

逐课课纲/部门课03_个人兴趣名片与页面组合.md

@@ -0,0 +1,75 @@
+# 部门课 03：个人兴趣名片与页面组合
+
+## 教学目标
+
+- 用入门语言认识 `struct ContentView: View`、`body` 和 `some View` 在 SwiftUI 代码骨架中的作用，但不展开协议、泛型和结果构建器。
+- 理解 SwiftUI 通过 View 层级声明界面的基本方式，能根据缩进和花括号识别简单的父子 View 关系。
+- 理解并实际使用 `VStack`、`HStack` 和 `ZStack`，知道它们分别组织纵向、横向和前后层叠关系。
+- 认识 `alignment`、`spacing` 和 `Spacer` 对布局关系的影响。
+- 能判断一个 Modifier 作用在哪个 View 上，并通过调整参数或顺序观察可见变化。
+- 能把一张单屏兴趣名片拆成外层、身份区、兴趣区和样式层，再逐块组合成页面。
+- 会使用 Preview 辅助观察，并以模拟器 Build/Run 作为最终验证。
+
+## 教学内容
+
+### 1. 从成品界面到 View 层级
+
+- 课堂使用授课干部提供的极简可运行项目，初始页面只有占位内容，不提供完整卡片模板。
+- 先展示完成版个人兴趣名片，再将页面拆成外层、身份区、兴趣区和样式层，并画出对应的 View 树。
+- 说明 SwiftUI 使用声明式方式描述界面：代码主要表达界面由什么组成、这些内容怎样嵌套和组合，而不是逐个指定屏幕坐标。
+- 用初学者能够理解的口径认识 `struct ContentView: View`、`body`、`some View` 和花括号的位置与作用，不要求解释其完整语言原理。
+
+### 2. 使用三种 Stack 组合页面
+
+- 使用 `ZStack` 组合卡片背景与前景内容。
+- 使用 `VStack` 纵向组织身份、介绍和兴趣区域。
+- 使用 `HStack` 横向组织图标、昵称信息和兴趣内容。
+- 通过简单调整观察 `alignment`、`spacing` 和 `Spacer` 怎样改变元素之间的关系。
+- 使用 `Text`、`Image`、SF Symbols 和基础 Shape 完成静态内容，不引入交互或动态数据。
+- 每增加一个区域都先观察或预测层级关系，再通过 Preview 或模拟器查看实际结果。
+
+### 3. Modifier 的作用对象与顺序
+
+- 使用字体、颜色、`padding`、背景和圆角等常见 Modifier 完成基础样式。
+- 根据点语法和缩进判断 Modifier 正在修改哪个 View。
+- 至少交换一次 `padding` 与背景等 Modifier 的顺序，观察结果差异，建立“Modifier 会产生新的界面描述，作用对象和顺序会影响结果”的基本认识。
+- 修改昵称、兴趣、SF Symbol 或配色，完成至少一处个人表达。
+
+### 4. AI 可选互动与课程边界
+
+授课干部可以根据课堂节奏选择以下互动，不作为共同完成要求：
+
+- 让学员询问 AI 某段代码的父子层级，再回答其中哪个是父 View、哪个是子 View。
+- 让 AI 预测修改 Stack 或交换 Modifier 后的效果，再由学员实际运行验证。
+- 让 AI 提出一个范围明确的样式调整，但不允许直接重写整个项目。
+
+本节不讲授 `@State`、按钮交互、数组、`ForEach`、动态数据、导航、多页面、自定义 View 拆分、完整 Swift 语法体系或 SwiftUI 底层布局算法。基础版本不要求导入图片；素材库图片仅作为自愿尝试，并且只能使用本人创作或确认可公开使用的素材。
+
+授课干部备课时可参考 [Apple View fundamentals](https://developer.apple.com/documentation/SwiftUI/View-fundamentals)、[Building layouts with stack views](https://developer.apple.com/documentation/swiftui/building-layouts-with-stack-views) 和 [Configuring views](https://developer.apple.com/documentation/swiftui/configuring-views)。
+
+## 课后作业
+
+### 最低完成标准
+
+- 完成并个性化一张个人兴趣名片，使用昵称或虚构身份、一句兴趣介绍和若干兴趣内容。
+- `ZStack`、`VStack` 和 `HStack` 均在页面中承担明确的布局作用。
+- 至少完成一处内容修改和一处样式或布局修改。
+- 在模拟器中成功 Build/Run，并保存一张运行截图记录结果。
+- 通过个人 Fork 和作业分支提交完整项目源码 PR，简要说明三种 Stack 分别负责什么，以及一个 Modifier 调整后的变化。
+
+### 建议完成标准
+
+- 尝试图片导入或额外装饰，仅使用本人创作或确认可公开使用的素材。
+- 进一步调整布局或样式，并运行比较效果。
+
+公开作品不放真实姓名、学号、联系方式或私人资料。AI 使用可选，未使用时说明即可。目录、分支、PR 模板和操作流程在备课时结合实际仓库确定；未完成或提交受阻时按[共同安排](../iOS部2026十课初步规划.md)记录当前状态并求助。
+
+## 验收方式
+
+- 确认项目能够真实 Build/Run，运行截图用于记录结果。
+- 从代码和运行结果确认三种 Stack 承担实际布局作用，且有一处内容修改和一处样式或布局修改。
+- 结合 PR 中的简短说明了解学员的理解；说明不完整用于反馈，不因表达不够准确拒绝已达到基础要求的作品。
+- 源码提交与隐私检查按共同安排处理，满足条件后给出简短反馈并合并。
+- 不以视觉精致度、代码行数、额外功能或能否解释全部 Swift 语法作为门槛。
+- 部门课 04 开头可选择少量作品复习 Stack 或 Modifier，不安排逐人技术答辩，不评分或淘汰。
+- 未完成的 Draft PR 保留并提供帮助，修正后再转为正式 PR。

逐课课纲/部门课04_小植物补水卡与交互状态.md

@@ -0,0 +1,81 @@
+# 部门课 04：小植物补水卡与交互状态
+
+## 教学目标
+
+- 区分用户交互、当前状态和界面反馈，理解“操作—状态变化—界面更新”的基本闭环。
+- 知道 `Button` 包含用户看到的 label 和点击后执行的 action，但本节不系统讲授闭包。
+- 理解 `@State private var` 表示由当前 View 拥有、由 SwiftUI 管理的临时可变状态。
+- 能从简单代码中找出状态存在哪里、谁修改它、哪些界面读取并依赖它。
+- 使用简单 `if / else`，让同一个状态决定不同文字、图标或颜色反馈。
+- 理解父 View 保存唯一的 `@State`，子 View 通过 `@Binding` 修改同一份状态。
+- 知道 `$waterCount` 传递的是指向已有状态的可读写连接，不是复制一份新值。
+- 知道 `@State` 不负责持久化，停止并重新运行 App 后会恢复初始值。
+
+## 教学内容
+
+### 1. 从静态卡片到状态闭环
+
+- 课堂使用授课干部提供并经过 Build/Run 的静态植物卡片，不要求学员重复部门课 3 的页面布局。
+- 起始项目只使用系统图标，不依赖网络、第三方包或外部素材。
+- 从“用户点击以后，App 需要记住什么”出发，区分用户操作、状态和可见反馈。
+- 在父 View 中增加 `@State private var waterCount = 0`，让文字读取并显示当前补水次数。
+- 在父 View 内加入“浇水”和“重新开始”按钮，先完成最小的 Button action、状态修改和界面更新闭环。
+
+### 2. 状态规则与条件反馈
+
+- `waterCount` 只允许在 0–3 之间变化。
+- “浇水”每次增加 1，到达 3 后不再增加并禁用。
+- “重新开始”将次数恢复为 0，在初始状态下可以禁用。
+- 使用简单 `if / else`，为 0、1–2、3 三个阶段显示不同文字、图标或颜色反馈。
+- 强调界面中的数字、文案和样式都读取同一个 `waterCount`，不为每种反馈分别保存容易矛盾的状态。
+
+### 3. 从 `@State` 到 `@Binding`
+
+- 在父 View 中跑通交互后，将两个按钮拆成同一 Swift 文件中的 `PlantControls` 子 View。
+- 父 View 保留唯一的 `@State`，作为 `waterCount` 的状态拥有者。
+- `PlantControls` 使用 `@Binding var waterCount: Int`，通过连接修改父 View 已有的状态。
+- 父 View 使用 `$waterCount` 将可读写连接传给子 View。
+- 重新 Build/Run，并按“拥有者—修改者—读取者”追踪完整数据流。
+- 对比父子 View 各自声明一份 `@State` 的错误方案，说明 Binding 用于维持单一事实来源。
+- 停止并重新运行 App，观察次数恢复为 0，明确这只是本次运行中的临时界面状态。
+
+### 4. AI 可选互动与课程边界
+
+授课干部可以根据课堂节奏选择以下互动，不作为共同完成要求：
+
+- 让学员请 AI 标出状态拥有者、修改者和读取者，再自行核对。
+- 让 AI 比较“父子 View 各自声明 `@State`”和“父 View 使用 `@State`、子 View 使用 `@Binding`”的区别。
+- 让 AI 用初学者能够理解的语言解释 `$waterCount`，再由学员用自己的话复述并运行验证。
+
+本节不讲授 Observable、环境注入、持久化、计时器、手势、异步任务、数组、随机数、多页面状态、复杂组件架构或属性包装器底层原理。动画、进度条、更多植物阶段和其他状态类型均为自愿挑战。
+
+授课干部备课时可参考 [Managing user interface state](https://developer.apple.com/documentation/swiftui/managing-user-interface-state)、[State](https://developer.apple.com/documentation/swiftui/state) 和 [Button](https://developer.apple.com/documentation/SwiftUI/Button)。
+
+## 课后作业
+
+### 最低完成标准
+
+- 完成并个性化“小植物补水卡”。
+- 初始 `waterCount` 为 0；“浇水”最多增加到 3；“重新开始”能够恢复为 0。
+- 0、1–2、3 三个阶段具有清楚的条件反馈。
+- 父 View 使用唯一的 `@State`，`PlantControls` 使用指向同一状态的 `@Binding`。
+- 至少修改一处植物名称、SF Symbol、反馈文案或配色。
+- 停止并重新运行 App，确认状态恢复为 0；本节不要求保存数据。
+- 通过个人 Fork 和作业分支提交源码 PR，简要说明状态的拥有者、修改者、读取者以及重启归零的原因。
+
+### 建议完成标准
+
+- 根据兴趣尝试动画、进度条或更多植物阶段，并验证效果。
+- 探索其他简单状态类型，不作为基础完成要求。
+
+本节不强制上传 GitHub 录屏。目录、分支、PR 模板和必要的运行记录形式由授课干部在备课时确定；不在课纲中规定视频时长、编码、格式或大小。AI 使用可选，未完成或提交受阻时按[共同安排](../iOS部2026十课初步规划.md)记录当前状态并求助。
+
+## 验收方式
+
+- 确认完整项目能在模拟器中 Build/Run。
+- 通过实际操作检查增加、上限、三个阶段的条件反馈、重置和重新运行归零；授课干部可以直接运行源码，不要求学员上传录屏。
+- 从源码确认唯一的 `@State` 与对应 `@Binding`，没有重复的事实来源，并保留个人可见修改。
+- PR 中的简短说明用于了解理解和提供反馈，不因表达不够准确拒绝已达到基础要求的作品。
+- 提交内容遵守共同的目录与隐私边界；不以视觉精致度、动画、额外功能或属性包装器底层原理作为合并门槛。
+- 部门课 05 开头可选少量作品复习状态所有权、Binding 或重启归零原因，不转化为逐人技术答辩、评分或淘汰。
+- 未完成的 Draft PR 保留并提供帮助，修正后再转为正式 PR。