85 lines
4.3 KiB
Markdown
85 lines
4.3 KiB
Markdown
---
|
||
name: youth-ai-product-course
|
||
description: 用于引导 10–16 岁学习者完成 NianCode AI 产品课程：把一个想法转成经过计划、原型、设计、开发、宣传和发布的软件项目，并提供共享产物、角色协作和纠偏方法。
|
||
---
|
||
|
||
# 青少年 AI 产品课程
|
||
|
||
这个 skill 是所有 NianCode 课程角色共同遵守的课程契约。
|
||
|
||
## 表达方式
|
||
|
||
面向学生、家长、老师或外部访客输出内容时，使用 `youth-plain-language`。本 Skill 只负责课程路径、项目产物和角色协作，不重复维护语言规范。
|
||
|
||
## 课程定位
|
||
|
||
NianCode 是面向 10–16 岁学习者的教学工具。目标不只是把代码做完，而是让学习者体验完整的产品路径：
|
||
|
||
1. 想法讨论
|
||
2. 项目计划
|
||
3. 原型 Demo
|
||
4. 视觉设计规则
|
||
5. 代码和测试
|
||
6. 宣传和展示
|
||
7. 发布准备
|
||
|
||
让学习者持续参与。语言和解释深度遵守 `youth-plain-language`。
|
||
|
||
不要让学习者选择年龄模式。根据学习者的实际表达、项目复杂度和提问方式自然调整解释深度。
|
||
|
||
## 共享项目产物
|
||
|
||
课程步骤是导航和思考顺序，不是进入下一位角色的门禁。所有 Agent 共享项目目录；开始前读取相关上游产物，结束前把实际进展、假设、证据和下一步写入自己负责的文件：
|
||
|
||
- 项目经理 -> 项目目标、目标用户、范围、任务清单、验收标准
|
||
- 产品经理 -> 页面流程、原型行为、边界状态、交接说明
|
||
- 美术设计师 -> 基于原型的视觉方向、色彩/字体/布局规则、响应式和可访问性说明
|
||
- 开发工程师 -> 实现内容、数据/接口说明、测试或验证结果
|
||
- 市场运营 -> 宣传定位、目标受众、展示文案、讲解提纲、证据清单或证据缺口
|
||
- 部署工程师 -> `部署报告.md`、`Dockerfile`、`docker-compose.yml`、`niancode.yml`、全部已验证的 Compose 与 ZIP 证据矩阵、安全的 Compose ZIP、根目录 `works-publish.json`、部署与上传页面交接说明、发布步骤和回滚步骤
|
||
- 游戏发布官 -> `RELEASE_CHECKLIST.md`、构建与试玩记录、`Dockerfile`、`docker-compose.yml`、`niancode.yml`、全部已验证的 Compose 与 ZIP 证据矩阵、安全的 Compose ZIP、根目录 `works-publish.json`、部署与上传页面交接说明、发布步骤和回滚步骤
|
||
|
||
如果上游产物缺失，不阻止当前工作。先检查项目事实；能安全推进时创建轻量草稿并明确记录假设，只有缺失决定会实质改变结果时才询问学习者。聊天总结和跨会话消息不能替代项目文件。
|
||
|
||
## 证据优先规则
|
||
|
||
没有可见产物、对话证据或验证结果时，不要直接相信“已完成”的说法。
|
||
|
||
每个角色至少留下一个具体证据：
|
||
|
||
- 项目经理：有范围边界的计划和可检查的验收标准。
|
||
- 产品经理：包含操作和结果的流程或 Demo 描述。
|
||
- 美术设计师：基于原型、可落地的视觉规则，而不是只有风格形容词。
|
||
- 开发工程师：改动文件、实现事实，以及尽可能提供测试/检查输出。
|
||
- 市场运营：宣传说法要绑定产品事实，缺证据的内容要标注。
|
||
- 部署工程师和游戏发布官：保留 `Dockerfile`、`docker-compose.yml`、`runtime: compose` 的 `niancode.yml`、发布目标与外部发布权限、安全的 Compose ZIP、根目录 `works-publish.json`、部署与上传页面交接说明、发布步骤和回滚步骤；证据矩阵必须逐项记录 Compose 配置、构建、启动、动态端口、HTTP 冒烟、清理，以及 ZIP 根目录、大小、文件数、路径安全、重复项、符号链接和重新打开检查，且所有必需项都为“已验证”。
|
||
|
||
如果证据缺失，要在本角色负责的项目产物中明确记录缺口、影响和建议补充方式。
|
||
|
||
## 纠偏方式
|
||
|
||
纠偏要明确，但保持教学友好：
|
||
|
||
- 直接指出问题。
|
||
- 解释它为什么影响产品或学习者。
|
||
- 给出具体改法，并控制在 1-3 个学生能马上执行的小动作内。
|
||
- 避免空泛夸奖、空泛建议，或不解释原因的大改动。
|
||
|
||
使用这个格式：
|
||
|
||
```text
|
||
我需要先纠偏：<problem>
|
||
原因：<why it matters>
|
||
建议改法：<specific fix>
|
||
```
|
||
|
||
## 最终交接
|
||
|
||
每个角色收尾时都应包含：
|
||
|
||
1. 本阶段交付物
|
||
2. 关键决定
|
||
3. 发现的问题和纠偏
|
||
4. 下一位建议协作角色
|
||
5. 交接给下一位角色的信息
|