明确前两题提交目录与 PR 流程，简化设计说明书模板

2026-09-21 16:02:37 +08:00
parent bb3e1fd619
commit 0ed89913bc
5 changed files with 96 additions and 39 deletions
@@ -1,7 +1,7 @@
 # iOS 部 2026 国庆考核

 > **筹备中 · 题面初稿**（2026-09-21）
-> 当前仓库用于题目审阅和完善，尚未正式开放提交。截止时刻、提交步骤、设备环境和最终评价细则将在发布前补齐。
+> 当前仓库用于题目审阅和完善，尚未正式开放提交。前两题的目录规范与分支、PR 流程已确定；操作验证、截止时刻、设备环境和最终评价细则将在发布前补齐。

 欢迎来到 ITStudio iOS 部国庆考核。我们希望通过两道共同题和一道选做题，了解你怎样学习基础编程、思考一个应用的用途，以及将想法做成作品。

@@ -18,12 +18,12 @@
 ## 从这里开始

 1. 阅读对应题面，尤其是每题的完成要求、提交材料和 AI 规则。
-2. 第一题的学习资源见题面；第二题可以复制[设计文档模板提纲](templates/design-document.md)，在熟悉的文档工具中填写并导出 PDF。
+2. 第一题的学习资源见题面；第二题可以复制[App 设计说明书（简版模板）](templates/design-document.md)，在熟悉的文档工具中完成并导出 PDF。
 3. 第三题需要 Fork [本仓库](https://git.itouc.cn/ITStudio_OUC/iOS_2026_National_Day)，在个人 Fork 的 [development/](development/README.md) 目录开发，保留原题文件。

 ## 提交安排

- **第一、二题：**提交到本次考核原仓库。具体采用哪个上传入口、怎样命名和组织材料，将在正式发布时统一说明；目前尚未开放提交。
+- **第一、二题**：整理到同一个以“年级＋姓名”命名的个人文件夹，例如 `25刁泓宁`，放在原仓库的 `submissions/` 下。通过本仓库的个人分支提交，再发起指向 `main` 的 PR，由干部审核合并。具体目录和步骤见[前两题提交说明](submissions/README.md)。
 - **第三题：**完整项目保留在个人 Fork，在原仓库提交 Fork 链接及用于验收的提交版本。作品入口的提交步骤及 Fork 可见性安排待发布时说明。
 - 截止日期与时刻、材料可见范围、环境说明、求助渠道：**待公布**。

@@ -39,10 +39,11 @@

 ```text
 tasks/                 三道题的题面与需求说明
-templates/             第二题设计文档模板提纲
+templates/             第二题简版设计说明书模板
+submissions/           前两题个人提交文件夹与提交说明
 development/           第三题个人 Fork 的开发目录
 README.md              考核入口与统一说明
 .gitignore             Swift/Xcode 常见临时文件忽略规则
 ```

-当前默认分支为 `main`。仓库尚未配置自动检查（CI）；检查范围及提交流程确定后再补齐。题面仍可能在正式发布前调整，请以发布时的仓库说明为准。
+当前默认分支为 `main`。仓库尚未配置自动检查（CI）；前两题的分支、PR 流程由负责人试跑后补充具体操作指引和权限安排。题面仍可能在正式发布前调整，请以发布时的仓库说明为准。
@@ -0,0 +1,48 @@
+# 第一、二题提交说明
+
+> 当前为筹备稿。目录规范和“个人分支 → PR → 干部审核合并”的方式已确定；负责人试跑后会补充具体页面操作与权限安排。正式开放时间、截止时刻以[仓库首页](../README.md)为准。
+
+## 一、整理个人文件夹
+
+前两题统一放在一个个人文件夹中，文件夹名称为 **两位年级＋姓名**，中间不加空格或符号。例如，25 级刁泓宁使用 `25刁泓宁`。
+
+个人文件夹统一放在原仓库的 `submissions/` 下，保留以下目录结构，直接提交其中的文件，无需另外压缩为 ZIP：
+
+```text
+submissions/
+└── 25刁泓宁/
+    ├── 01-basics/
+    │   ├── main.swift
+    │   └── screenshots/
+    │       ├── run-01.png
+    │       └── run-02.png
+    └── 02-design/
+        └── design.pdf
+```
+
+- `01-basics/main.swift`：第一题源码。
+- `01-basics/screenshots/`：真实运行截图，覆盖第一题要求的 A–F；数量按实际需要，PNG 或 JPG 均可。
+- `02-design/design.pdf`：第二题完整设计文档，只需一份 PDF。
+
+将示例文件夹名换成自己的年级与姓名。`25刁泓宁` 仅为命名示例，不是待填写的公共文件夹。文件具体要求见[第一题](../tasks/01-basics.md)和[第二题](../tasks/02-design.md)。
+
+## 二、通过个人分支与 PR 提交
+
+1. 从**本仓库最新的 `main`** 创建自己的分支。建议命名为 `submission/年级-姓名拼音`，例如 `submission/25-diaohongning`。
+2. 在个人分支中加入 `submissions/自己的年级姓名/` 文件夹，并提交其中的两题材料。
+3. 创建一个 Pull Request（PR）：**来源分支选自己的分支，目标分支选本仓库的 `main`**。
+4. PR 标题使用 `年级姓名：提交第一、二题`，例如 `25刁泓宁：提交第一、二题`。正文简述两题完成情况；有未完成部分或已知问题时如实说明。
+5. 查看 PR 的文件变更，确认只包含自己文件夹中的材料，源码、截图和 PDF 对应本次提交的版本，然后交由干部审核合并。
+
+前两题使用原仓库内的个人分支，无需 Fork。不要把材料直接提交到 `main`，也不要改动其他人的文件夹或原题、模板。
+
+PR 尚未合并时需要补交或修改，继续在同一个个人分支提交，原 PR 会随之更新。已合并后需要再修改，从最新 `main` 创建新分支，只修改自己的文件夹，再发起补交 PR。
+
+## 三、提交前检查
+
+- 个人文件夹名称、所在位置和两题子目录正确。
+- 源码与截图一致，截图文字清楚；PDF 可以打开，草图和文字完整可读。
+- 没有遗留文档模板中的填写提示。
+- PR 来源是个人分支，目标是 `main`，变更只涉及自己的文件夹。
+
+同年级同名、无法创建分支或无法提交时，联系干部确认标识或权限安排。
@@ -88,7 +88,9 @@ C 输出准备齐全的提示；E、F 输出无需检查的提示。

 ### 提交方式

-第一题材料直接提交到本次考核原仓库。具体上传入口、个人目录或标识规则和截止时刻，见 [仓库首页](../README.md) 后续公布的统一提交指南；当前仍在筹备，尚未开放提交。
+第一题与第二题一起放入 `submissions/年级姓名/`，个人文件夹例如 `25刁泓宁`。本题源码放在 `01-basics/main.swift`，运行截图放在 `01-basics/screenshots/`。
+
+在本仓库的个人分支提交这份文件夹，再发起指向 `main` 的 PR，由干部审核合并。完整目录示例与步骤见[前两题提交说明](../submissions/README.md)。当前仍在筹备，正式开放时间和截止时刻以[仓库首页](../README.md)通知为准。

 不需要额外提交设计文档、学习笔记或调试报告。

@@ -37,7 +37,7 @@

 挑一处设计，说明你为什么这样安排；如果还有一种做法，为什么暂时没选。再说明目前最不确定的一点，以及怎样了解这种设计是否有帮助。

-可以用[模板提纲](../templates/design-document.md)组织内容，建议 3–4 页，清楚简短即可。页面建议只用于控制工作量，不是硬性扣分标准。
+请按[App 设计说明书（简版模板）](../templates/design-document.md)组织内容：问题背景 → 设计目标与使用对象 → 方案与功能范围 → 界面与操作流程 → 设计取舍与待验证问题，最后附 AI 使用说明。用简短段落、必要的表格和草图写成一份完整文档。建议 3–4 页，页面建议只用于控制工作量，不是硬性扣分标准。

 ## 不需要提交什么

@@ -53,7 +53,7 @@ AI 只可以润色你已经写好的文字，或整理、美化你已经画出

 ## 提交与评价

-提交 `design.pdf`，包含简短方案、草图、操作示例、选择理由及 AI 使用说明。
+提交 `design.pdf`，包含简短方案、草图、操作示例、选择理由及 AI 使用说明。放在 `submissions/年级姓名/02-design/design.pdf`，与第一题一起通过个人分支和 PR 提交；目录示例与步骤见[前两题提交说明](../submissions/README.md)。只需提交最终 PDF，不必额外提交文档编辑源文件。

 我们主要看问题是否具体、功能是否服务这个问题、使用过程能否讲通、是否考虑反馈和不顺利的情况，以及设计理由是否来自自己的思考。漂亮排版和写作长度不能代替这些内容。

@@ -1,51 +1,57 @@
-# 第二题设计文档模板提纲
+# App 设计说明书（简版模板）

-这是内容模板，可复制到 Word、Pages、PowerPoint 等熟悉的工具中编写，最终只提交 PDF。下面的方括号是填写提示，不是标准答案。建议 3–4 页；草图可以手绘。
+> 使用方法：复制到 Word、Pages 等熟悉的文档工具，将方括号内的提示替换为自己的内容。按下面的章节写成简短段落，配合表格和草图，最后导出为 `design.pdf`。建议全文 3–4 页（含草图），无需另做封面或目录；导出前删除本段使用说明与未填写的提示。

-## 我的 App 与使用场景
+**作品名称**：[App 名称]

-作品名称：[填写]
+**作者**：[年级＋姓名，例如 25刁泓宁]

-提交标识：[按后续统一规则填写]
+## 一、问题背景

-给谁用：[具体到一类人或一个人]
+[用一小段描述具体的麻烦：谁在什么场景下想完成什么事，遇到了什么困难，现在怎样处理，以及现有办法哪里不方便。注明内容来自亲身经历、观察还是合理假设；无需专门进行正式调查，不编造访谈或使用记录。]

-什么时候遇到什么麻烦：[两三句话，可以说明亲身经历、观察或假设]
+## 二、设计目标与使用对象

-现在怎样处理，我想改善哪里：[简短说明]
+[说明这款 App 主要给谁用，以及希望帮助他们完成什么事情。用一两句话说清，相比当前做法，用户的哪一步会更方便。目标应对应上一节的麻烦。]

-## 第一版方案
+## 三、方案与功能范围

-最重要的 2–3 项功能：[每项一句，说明对这个场景的用途]
+[先用一句话概括方案：这是一个怎样的 App，用户通过它做什么。随后列出首版最重要的 2–3 项功能。]

-暂时不做的一项功能及原因：[填写]
-
-## 草图与使用示例
-
-[插入主要页面或状态草图，编号 ①②③；标出主要文字、操作位置、点击后的变化。]
-
-一次正常使用：
-
-| 步骤 | 用户做什么 | 画面出现什么，事情怎样变化 |
+| 核心功能 | 用户能做什么 | 对解决问题有什么帮助 |
 | --- | --- | --- |
-| 1 | [填写] | [对应草图编号] |
-| 2 | [填写] | [对应草图编号] |
-| 3 | [可按需要增减行] | [填写] |
+| [功能 1] | [具体操作或行为] | [对应的用途] |
+| [功能 2] | [具体操作或行为] | [对应的用途] |
+| [功能 3，可删去此行] | [具体操作或行为] | [对应的用途] |

-一种不顺利的情况：[输入为空、取消、无结果、误操作等任选一种与作品相关的情形]
+**本版暂不包含**：[写一个决定暂时不做的功能，并简述原因。]

-用户会看到什么，接下来能怎么办：[填写，可加草图]
+## 四、界面与操作流程

-## 我的选择与疑问
+### 4.1 界面草图

-我做过的一处选择及理由：[写清具体位置或操作；可比较另一种做法]
+[插入完成核心任务所需的页面或状态草图，建议 2–4 幅；按图 1、图 2……编号。标出主要信息、可操作的位置和操作后的变化。手绘即可；同一页面的不同状态也可以分别画出。]

-我最不确定的地方：[填写]
+### 4.2 正常使用流程

-我准备怎样了解设计是否有帮助：[例如请一位同学按草图走一遍，观察什么；无需声称已执行]
+[先说明这一次使用的具体情境和目标，再从打开 App 开始，按顺序写出操作、反馈和完成结果。表格与草图编号对应，行数按实际需要调整。]

-## AI 使用说明
+| 步骤 | 用户操作 | 界面反馈或结果 | 对应草图 |
+| --- | --- | --- | --- |
+| 1 | [打开 App 后做什么] | [看到什么] | [图号] |
+| 2 | [下一步操作] | [发生什么变化] | [图号] |
+| 3 | [完成任务的操作] | [怎样知道事情已完成] | [图号] |

-[未使用 AI／使用了哪些工具润色哪些原有文字或草图。想法、功能、交互和设计理由由本人提出。]
+### 4.3 非正常情况处理

-导出前检查：草图与文字能对应、关键文字可读、没有遗留填写提示、未把尚未做过的访谈或验证写成已完成。
+[选择一种与方案有关的情况，例如输入为空、没有结果、误操作或取消。用一小段写清：何时发生、用户看到什么、接下来怎样继续或恢复。必要时补一幅草图。]
+
+## 五、设计取舍与待验证问题
+
+**设计取舍**：[选择一处具体设计，说明采用它的理由，并说明为什么暂时不选另一种做法。]
+
+**待验证问题**：[指出目前最不确定的一点，以及准备通过什么方式了解设计是否有帮助。例如让同学按草图走一遍，并说明想观察什么。尚未开展的验证请写成计划。]
+
+## 附：AI 使用说明
+
+[未使用 AI；或简述使用的工具、润色了哪些本人已有的文字或草图。问题、想法、功能、操作流程与设计理由必须由本人提出。]