从一个想法，
到一座真实运行的平台。

0.1推荐讲解顺序

如果你要带着一群人从头讲一遍，建议不要按“先名词后案例”的顺序。最有效的次序是： 先用故事勾住注意力，再建概念地图，然后讲方法，最后拆开平台验证一切。

0.2如果时间有限，这几张图必须看

0.3学什么、学到什么程度

三个小时不可能什么都学会，也不需要。下面这张表说明每一项内容需要学到什么程度——第三档的内容，今天只需要知道“它存在”。

0.4什么时候可以开始动手

不需要全部听完才动手。每听完一部分，就有一件可以立刻做的事。

1.1AI 世界的四层地图

从下到上：算力提供动力，模型提供能力，产品提供体验，入口决定你从哪里接触它。点击任意一层查看解释。

1.2主要厂商：看懂“公司—模型—产品”的对应关系

不需要背排名，只需要看懂一个规律：每个公司都在做同一件事——把模型能力包装成不同形态的产品：日常助手、工作 Agent、编程 Agent。

1.3模型：它为什么“什么都会”，又为什么会错

大模型读过海量文字、代码、图片，训练后形成了一套极其复杂的规律。使用时，它根据当前提供的信息， 不断预测什么样的输出最合适。注意：“预测下一个词”是原理解释，不等于“AI 只会胡乱接龙”—— 现代模型通过这种训练，真实获得了语言理解、知识调用、推理、编码和多模态能力。

但请务必记住它的边界：AI 能力很强，却不能保证正确。它写代码很强，是因为有足够多的训练数据； 它语气很自信，也可能是在一本正经地补全一个错误答案。所以“检查 AI 的结果”不是可选项，是使用方式的一部分。

1.4Token：AI 的“字数单位”，也是计费单位

大模型以 Token（词元）为单位进行计算和收费。一个 Token 可以是一个字、一个词，甚至一个标点。在下面输入一句话，亲眼看看它会被怎样切分。

1.5上下文：AI 这次工作，到底“知道”什么

这是全部 AI 使用中最重要的一个公式：

上下文包括：你这次的提示词、前面的聊天记录、上传的文件、项目文件夹里的资料、规则文件…… 本质上就是“把文字和图片发给 AI，AI 返回结果”。但上下文窗口是有限的——点击下面的按钮，把材料一件件塞进去，看看会发生什么：

1.6API：像点餐一样，向另一个程序“下单”

API 是程序之间约定好的办事接口。它告诉调用方：可以请求什么服务、信息应该怎么填写，以及结果会怎样返回。AI 只是它的一种用途；查天气、查物流、调用地图，也可以用 API。

那调用 API，到底要准备什么？

以常见的大模型 API 为例：服务方提供接口文档、请求地址，以及开通调用权限的方式；你的网站后端按文档准备下面这些信息，再发出请求。

01请求地址

送到哪一家、哪一个窗口？

使用服务方提供的接口地址；不同地址可能负责对话、图片或其他能力。

02身份凭证

谁在调用，有没有权限？

常见方式是 API Key，像调用服务的通行证，也可能关联用量与费用。具体认证方式看文档。

03模型或能力

你点的是哪一道菜？

按接口要求选择模型或功能，例如用哪个对话模型回答问题。

04输入与材料

把这一次的需求说清楚。

例如学生的问题、相关题目、必要的背景。服务不会自动知道网页里所有的信息。

05回答要求与参数

有没有“少辣、不放香菜”这样的要求？

例如用什么语气、回答多长、返回文字还是结构化数据。这些设置是否必填、支持哪些选项，都以接口文档为准。

1.7Agent：大脑 + 工具 + 调度器

模型是大脑，浏览器、PPT、Word 是工具，Agent 是调度器——它接到任务后自己拆解步骤、调用工具、逐步执行。可以把它理解为一个数字员工。点击“开始执行”，看一个 Agent 如何完成备课任务：

1.8Skill：把一套熟练流程“打包”

想象你在备课：先让 AI 读课标和教案，再让它上网搜资料，然后做成 PPT，再发给你——这一串你要提好几次要求。 Skill 就是把这串流程打包。做完之后你说一句“帮我把以上过程打包成一个 skill”， 以后只需要说“帮我备课”，它就会自动执行整串操作。Skill 的本质，是一个大的提示词文件。

什么时候才值得做 Skill？当一个流程会反复发生、步骤相对稳定的时候。只做一次的事，不值得打包。 CyberScope 里就沉淀了 11 个这样的 skill：做课、磨课、审课、上架、发布复核、课堂应急……第五章你会看到它们是怎么长出来的。

1.9Markdown：AI 时代人与机器“共读的纸”

Markdown（.md）是一种介于 txt 和 Word 之间的格式：比 txt 多了层级信息，比 Word 少了格式负担。它是当下 AI 与人交互最快、最方便的格式。

所以你在本网站看到的所有 Prompt 模板、需求文档、规则文件、计划文档，全部是 Markdown。CyberScope 项目里就有 384 份 Markdown 文档——它是整个项目的“记忆载体”。

1.10AGENTS.md：写给 AI 的《教师工作手册》

在支持这一约定的 AI 编程工具中，AGENTS.md 用来保存项目的长期工作规则。以 Codex 为例，它会按目录层级读取适用的规则，让 AI 知道这个项目怎样开发、检查和交付。

实际使用时，可以问 AI：“请列出你已读取、适用于这次修改的规则文件。”Codex 启动时按项目根到当前工作目录的路径读取，从根目录启动不等于所有子目录规则都已自动加载。参见 OpenAI 官方说明。

# 项目说明
这是一个面向中学信息技术课堂的作业管理平台。

# 用户
- 学生：查看和提交作业
- 教师：发布、查看和批改作业

# 技术栈
- 前端：React
- 后端：FastAPI
- 数据库：PostgreSQL

# 开发规则
- 不要随意增加新的依赖
- 不要未经确认修改数据库结构
- 不要删除已有功能
- 所有界面使用简体中文
- 优先保证机房电脑上的使用体验

# 修改代码后
1. 检查是否影响已有功能
2. 运行测试
3. 修复报错
4. 告诉我修改了哪些文件

对比感受一下规模：CyberScope 的 AGENTS.md 有 278 行，外加 6 份分区手册、47 份架构决策记录——但它是项目长到 25 万行之后才需要的规格。规则文件要和项目的规模相匹配，第一天就写几百行规则是浪费。

1.11四个一听就懂的小概念

1.12合起来：一个简单的 AI 系统长什么样

用一个“作业答疑网页”把概念串起来。学生输入问题后，前端、后端和模型分别做什么？

2.1产品经理入门：八个概念，一条链

做软件不是从“功能”开始的，而是从“人”开始的。八个概念串成一条思考链：

其中最关键的是 MVP（最小可用版本）：它不是“做得很差的完整系统”，而是只保留最小的完整价值闭环。 老师抱怨“收作业很乱”，真正的问题可能只是：文件散落在微信、QQ、U 盘多个渠道；无法快速知道谁没交。 所以第一版只需要一个闭环——老师创建作业 → 学生提交 → 老师看到已交/未交名单。 注册系统、家长端、AI 批改、积分排行榜，全部不做。

2.2同一个平台，两种 Prompt 的天壤之别

左右对比：左侧是完全不懂产品概念时的说法，右侧是补全八个概念之后的说法。

2.3前端、后端、数据库：一次提交作业的完整旅程

网站 = 前端 + 后端 + 数据库。前端是界面（好不好看、顺不顺手）；后端是干活的部分（整理数据、调用批改、写入存储）；数据库负责存数据（增删改查）。 点击按钮，看一个学生提交作业时发生了什么：

设计任何一个系统，只需先回答四个问题

2.4四个工程名词：源码、目录、依赖、环境变量

2.5Git：为什么 AI 写得越快，越需要版本控制

Git 是版本控制系统：记录文件随时间的变化，随时可以回退。它对 Vibe Coding 尤其重要—— 因为 AI 写代码速度越快，把东西改崩的速度也越快。点击按钮，体验一次“改崩 → 回退”：

2.6测试意识：像教务处检查工作一样检查软件

不需要会写测试代码，但需要会问这些问题——它们中的任何一个，都可能在第一节课就变成真事故：

第五章你会看到，这些问题不是假设：CyberScope 的“半开 TCP 卡死全班群控”“演示班一夜烧光 AI 余额”都是真实发生、然后被固化成规则的事故。

2.7部署：一个项目的三种“公开程度”

作者的域名是 ericlab.cn，所有项目都挂在它的子域名下——CyberScope 的公开演示站就是 cyberscope.ericlab.cn。但它的主战场其实不在公网：它是跑在机房局域网里的，这一点第四章细讲。

3.1先学通用功：一条好 Prompt 的四个成分

目标告诉 AI 去哪里，边界告诉 AI 不要去哪里，验收标准告诉 AI 什么时候停。另外记住最重要的一条工作习惯：复杂任务不要让 AI 一上来就干——先让它复述理解、指出缺失信息、提出方案，你确认范围之后再执行。

3.2阶段一 · 想清楚：四个 Prompt，从模糊想法到正式需求文档

先定义问题、明确需求，而不是直接设计功能——你以为需要的功能不一定需要。以解决需求为目标，而不是以做出功能为目标。

我有一个产品想法：

[写你的想法]

先不要设计页面，也不要写代码。

请作为资深产品顾问，使用“grill-me”这个 skill 向我发起多轮提问，
帮助我把这个想法想清楚。重点分析：

1. 谁可能会使用它；
2. 用户现在是怎么完成这件事情的；
3. 当前过程中最麻烦的地方是什么；
4. 这个产品真正应该解决的核心问题是什么；
5. 哪些可能只是我想象中的需求，而不是真实需求；
6. 这个想法是否真的值得做成软件；
7. 如果不开发软件，有没有更简单的解决方法。

最后用一句话定义：
“我们要为【什么用户】，解决【什么问题】。”

我准备开发：

[产品]

目前我的想法还不成熟。暂时不要写代码。

你现在作为产品经理采访我。请通过连续提问帮助我把需求想清楚。

重点追问：谁使用；什么场景使用；用户现在怎么做；最大痛点；
核心流程；必须功能；可选功能；数据；权限；异常情况；UI；
使用设备；使用规模；隐私；部署方式；未来可能扩展的方向。

根据我的回答继续追问。如果发现我前后需求矛盾，也要指出来。

直到你认为需求已经足够清楚，再整理成完整需求说明。
在我确认之前不要开始开发。

下面是我目前想到的全部功能：

[功能]

请不要继续增加功能。现在帮我尽可能“砍需求”。
目标是做一个真正能够被用户使用的最小可行版本 MVP。

请把功能分成：
A. MVP 必须有 —— 没有它核心流程无法完成
B. 第二阶段 —— 有明显价值，但第一版可以没有
C. 锦上添花 —— 暂时不要做
D. 建议删除 —— 复杂度明显高于价值

判断时优先考虑：1. 是否解决核心问题；2. 用户是否真的会使用；
3. 开发复杂度；4. 数据和安全风险；5. 是否可以以后增加。

最终给出第一版 MVP 的明确边界，做成一份 md 文档保存到文件夹。

根据我们已经确认的内容，生成一份适合小型 Vibe Coding 项目的需求文档。

包括：1. 产品背景；2. 要解决的问题；3. 目标用户；4. 核心场景；
5. 产品目标；6. 非目标；7. 用户故事；8. 功能需求；9. 用户流程；
10. 数据需求；11. 权限要求；12. 异常情况；13. MVP 范围；
14. Out of Scope；15. 验收标准；16. 待确认问题。

要求：不要擅自增加需求；不要用模糊语言；有歧义的位置明确标记；
尽量让另一个完全没参与讨论的 Coding Agent 只读这份需求文档就能理解项目。
最后做成一份 md 文档保存到文件夹。

3.3阶段二 · 设计清楚：流程、页面、UI、技术、架构

需求确定后，先设计再开发：用户怎么操作？有哪些页面？什么风格？用什么技术？系统怎么组装？

产品：[产品]
用户：[用户]
核心任务：[任务]

请设计用户从进入系统到完成任务的完整 User Flow。

每一步说明：
用户看到什么 → 用户做什么 → 系统发生什么 → 系统反馈什么 → 下一步是什么

同时考虑：第一次使用；正常使用；操作失败；用户取消；返回；权限不足；数据为空。

优先减少步骤和用户思考成本。
不要为了“功能丰富”增加不必要页面。

基于需求文档，请根据用户任务设计 Information Architecture。

告诉我：
1. 系统需要哪些页面；
2. 页面之间是什么关系；
3. 主导航应该有哪些入口；
4. 哪些页面应该合并；
5. 哪些功能不值得单独做一个页面；
6. 每个页面最核心的任务是什么。

请输出：页面 → 页面目的 → 核心用户 → 主要操作 → 前往哪里

要求：一页尽量服务一个明确任务。做成一份 md 文档保存到文件夹。

为以下产品设计界面及美学风格：

产品：[产品]
主要用户：[用户]
核心任务：[任务]
设备：[电脑 / 手机 / 平板]

请先分析用户使用场景，然后设计页面。

要求：
1. 页面视觉层级清楚；
2. 用户进入页面 3 秒内知道要做什么；
3. 核心操作突出；
4. 次要功能降低视觉权重；
5. 不堆砌卡片；
6. 不为了“高级感”过度增加装饰；
7. 落一份详细好看的设计系统；
8. 制作一个原型页面展现你的设计。

（可以加你喜欢的风格，比如“高级、精致、有科技感的色彩搭配”；
 对审美有要求时，也可以去搜集不同风格的提示词，或让 AI 复刻某个你欣赏的网站）

我要开发：[项目]
用户规模大约：[规模]
团队情况：我主要通过 AI Coding Agent 开发，本人技术经验有限。
核心需求：[需求]

请帮我选择尽可能简单、成熟、有良好文档和 AI 支持的技术方案。
分别考虑：前端；后端；数据库；用户认证；文件存储；部署；域名；日志；备份。

原则：
1. 优先减少技术栈数量；
2. 不为未来不存在的问题过度设计；
3. MVP 优先使用托管服务；
4. 明确免费方案的限制；
5. 告诉我什么时候才需要升级技术架构。

请比较 2～3 套方案，最后明确推荐一套。

根据这个项目：[需求文档 + 技术栈]

请用适合非专业开发者理解的方式，解释整个系统架构。
说明：用户 → 前端 → API / 后端 → 数据库 → Storage → Auth → 第三方 API
分别负责什么。

同时说明：
1. 数据从哪里产生；2. 经过哪里；3. 存在哪里；
4. 谁可以访问；5. 哪些操作发生在浏览器；6. 哪些必须发生在服务器端。

最后在项目文件夹落一份 Mermaid 架构图。

3.4阶段三 · 规划清楚：从空目录到上线的路线图

不要想到哪写到哪。让 AI 作为技术负责人，把项目拆成阶段，明确每个阶段做什么、交付什么、如何验收——以及每个阶段的 Prompt。

我们已经完成这个项目的需求分析和初步技术设计。
去文件夹中寻找：【PRD】【MVP 范围】【主要页面 / 用户流程】【技术栈】【系统架构】

现在不要开始写业务代码。
请你作为这个项目的技术负责人，为整个项目制定一份项目开发计划。

目标不是规划某一个功能，而是回答：
“这个项目从空目录到正式上线，应该按照什么顺序完成？”

请完成以下工作：
1. 把整个项目拆分成若干阶段；2. 明确每个阶段的核心目标；
3. 说明每个阶段具体需要完成哪些事情；4. 说明这一阶段的主要交付物；
5. 指出阶段之间的依赖关系；6. 哪些基础设施必须先完成；
7. 哪些功能可以并行开发；8. 哪些功能必须后做；
9. 每个阶段如何验收；10. 每个阶段结束时项目应该处于什么状态；
11. 给出每个阶段的 prompt。

规划时遵循：
- 优先完成基础能力；优先跑通核心用户流程；
- 每个阶段完成后系统都应尽可能处于可运行状态；
- 避免同时开发过多相互依赖的功能；
- 不要为了未来可能存在的需求过度设计；
- 不增加需求文档中没有确认的新功能。

输出最终的 Project Roadmap.md 文件。
最后告诉我：如果今天正式开始开发，第一阶段应该做什么。

3.5阶段四五六 · 开发、测试、部署：管理 AI，而不是催 AI

开发阶段的本质，是下面这个循环——你不是在“问”AI，你是在“管理”AI：

3.6从小白到掌控大系统：四个成长阶段

没有人能一步跳到“掌控大系统”，但每一步都有明确的标志。对照这张表，你可以知道自己在哪里、下一步是什么。

关键心法：不是“学完所有知识再开始”，而是每长到一个阶段，就把那个阶段的规范补上。CyberScope 的规范没有一条是提前写好的，全是规模到位后长出来的。

4.1设计的原点：一张明确的取舍排序

平台的 AGENTS.md 开篇就写死了优先级——所有设计决策都可以从这张排序里推导出来：

课堂 45 分钟不能出事故，所以稳定性压过一切；老师要能控住全场；学生是未成年人，数据安全是红线；而全平台只有一个人维护，所以“看得懂、改得动”本身就是架构目标。

4.2全局架构：一节课如何在系统里流动 必看图表 ①

先看课堂运行，再看内容和开发流程。教师端与学生端在浏览器中打开，共同连接教师机上的后端。

4.3功能模块地图：每个部分是干什么的 必看图表 ②

4.4一节课的 45 分钟：平台在真实课堂里怎么转

架构图是静态的，课堂是活的。跟着一节课走一遍，你就理解每个模块什么时候上场。

4.5深入三个模块：设计背后的“教学理由”

4.6必须知道的七个设计决策，以及“为什么” 讲解重点

如果时间只够讲一部分，就讲这一节。每个决策背后都是一条可以迁移到任何项目的经验。

4.7数据存在哪：一张文件级的“课程成绩单”

数据库只有一个文件（lab_data.db），但里面的表各司其职——看表名就能猜出平台在关心什么：

AI 调用全部走 OpenAI 兼容协议，集中在后端四个位置：学生问答（chat.py）、课件评分（course_llm.py）、学情分析（teacher_analytics.py）、训练馆诊断（gym/）。前端从不直接碰 API Key。

4.8部署：两种形态，各就各位

4.9它现在有多大

按传统开发方式估算，这大致相当于一个 3–4 人小团队半年到一年的产出——而它出自一位教师 + AI 之手，用时五个月。

5.1五个月的节奏：不是匀速，而是有主题的爆发

* 9 月数据仅为前 3 天。4 月起步，5 月立规矩，6 月体系化爆发，7 月铺满内容并上线，8 月被真实世界倒逼修正，9 月开学实战。

5.2最关键的一条线：规范是长出来的，不是天生的 必看图表 ③

很多人以为规范是项目第一天就设计好的。CyberScope 的真实顺序恰恰相反——每一步都是被上一步的混乱逼出来的：

5.3完整时间线：六个月度阶段，每一步都有据可查 必看图表 ④

5.4踩坑实录：八个真实的坑，以及每个坑留下的规则

这是这份说明书里最值钱的部分。每个坑都按“案发 → 根因 → 规则”讲——规则不是想出来的，是赔出来的。

八条规则没有一条来自教科书，全部来自真实课堂和真实事故。这就是“发展必须有章法”的另一面：章法不是用来约束你的，是用来让你敢继续往前走的。

5.5收尾：这段历史想让大家带走的两个信念

A.2给讲解者：六个最常见的教学失误