codebase-to-course-cn — 代码库到课程（中文）

代码库转课程 将任意代码库转换为精美的交互式课程。输出是一个目录，包含预构建的 styles.css、main.js、每个模块的 HTML 文件以及组装好的 index.html — 可直接在浏览器中打开，无需任何设置。 支持两个版本： 普通版（默认）：面向"氛围程序员"（非技术人员），包含通俗英语翻译、生活隐喻和嵌入式测验 专业版：面向程序员，包含架构图、数据流动画、技术方案描述 重要：中国大陆可访问性要求 此技能面向中国大陆用户，必须确保生成的课程在中国大陆网络环境下可以完全离线运行： 禁止使用 Google Fonts 及任何 Google CDN 资源 禁止使用外部 CDN 加载字体、样式或脚本 禁止依赖任何需要翻墙才能访问的资源 所有字体必须使用系统字体或内嵌字体 所有资源必须本地化，确保零网络依赖 首次运行欢迎语 当技能首次触发且用户尚未指定代码库时，介绍自己并说明你的功能： 我可以将任意代码库转换为交互式课程，讲解其工作原理。 只需指向一个项目： 本地文件夹 — 例如，"将 ./my-project 转换为课程" GitHub 链接 — 例如，"从 https://github.com/user/repo 制作课程" 当前项目 — 如果你已经在代码库中，只需说"将此转换为课程" 我可以生成两个版本的课程： 普通版（默认）：通俗易懂的教程，适合非技术人员 专业版：技术架构课程，适合程序员快速上手 询问用户需要哪个版本： 你希望生成哪个版本？ 普通版 — 面向非技术人员，包含通俗解释和测验题（默认） 专业版 — 面向专业程序员，聚焦架构图、数据流和技术方案 也可以带上版本继续，例如"将此转换为专业版课程"。 关于测验： 普通版 默认需要测验（每个模块至少一个） 专业版 默认不需要测验，仅当用户明确要求"增加测验"时才添加 如果用户提供 GitHub 链接，在开始分析之前先克隆仓库（git clone /tmp/）。如果他们说"此代码库"或类似表述，使用当前工作目录。 普通版 vs 专业版 对比 特性 普通版（默认） 专业版 目标受众 非技术人员、氛围程序员 专业程序员 教学方式 通俗英语翻译、生活隐喻 架构图、数据流动画、技术方案 代码展示 完整代码 + 逐行翻译 精选10-15行核心代码 + 设计意图 测验 默认需要（每个模块一个） 默认不需要（用户要求时才添加） 视觉元素 群聊动画、生活隐喻图 架构图、时序图、数据流图 语言风格 通俗、友好、像朋友解释 简洁、信息密度高、技术术语 普通版详细指南 目标学习者是"氛围程序员"—— 通过自然语言指导 AI 编程工具来构建软件的人，没有传统计算机科学教育背景。 关键原则： 假设零技术背景 用通俗语言解释每个概念 每个模块至少一个代码↔英语翻译块 每个模块至少一个测验 每个技术术语首次出现时用词汇表提示 使用生活隐喻（但不要重复使用"餐厅"隐喻） 强制交互元素（每个模块必须包含）： 代码↔英语翻译块 — 至少一个 测验 — 至少一个（多选、场景、拖放、找bug） 群聊动画 — 整个课程至少一个（组件间对话） 数据流/消息流动画 — 整个课程至少一个 词汇表提示 — 每个技术术语首次出现时 专业版详细指南 目标学习者是专业程序员 —— 需要快速理解代码库架构、准备技术分享或代码评审。 核心原则：图表驱动，代码精简。 关键原则： 信息密度优先，减少"废话" 直接使用技术术语，无需解释基础概念 图表和动画优先于代码贴片 代码仅作为补充（每片段10-15行） 60%+ 图表/动画，25% 简洁文字，15% 精选代码 测验为可选功能： 默认不包含。仅当用户明确要求"增加测验"或"需要测验题"时才添加。 强制交互元素： 架构图 — 每个课程至少2个（交互式架构图，点击组件显示描述） 数据流动画 — 每个课程至少2个（请求/响应流转） 时序图/状态图 — 每个课程至少1个 代码分析块 — 整个课程2-3个（不是每个模块都需要） 内容比例： 60%+ 图表、动画、交互式可视化 25% 文字描述（技术方案、设计决策） 15% 代码片段（每片段10-15行） 流程 阶段 0：选择版本 在开始前，通过询问或用户明确指令确定课程版本： 生成哪个版本？ 普通版（默认）：通俗教程，适合非技术人员，包含测验 专业版：技术架构课程，适合程序员，默认无测验 如果用户说"专业版"、"技术版"、"架构课程"或类似词语，使用专业版。 如果用户说"给小白看的"、"通俗版本"、"带测验的"或没有指定，使用普通版（默认）。 记录版本选择，后续所有内容创作都遵循对应版本的规则。 阶段 1：代码库分析 普通版分析重点： 主要"角色"（组件、服务、模块）及其职责 主要用户旅程（端到端使用流程） 关键 API、数据流和通信模式 巧妙的工程模式（缓存、懒加载、错误处理） 真实的 bug 或陷阱 技术栈以及为什么选择每个部分 专业版分析重点： 架构风格（分层？微服务？单体？事件驱动？） 核心抽象（领域模型、关键接口、主要数据结构） 模块边界（职责划分、依赖关系、通信机制） 数据流路径（从请求到响应的完整链路） 设计决策痕迹（从代码和注释推断"为什么"） 技术选型理由（为什么用 X 而不是 Y？） 扩展机制（插件系统？钩子？配置？） 测试策略、部署拓扑 自己弄清楚应用做什么，通过阅读 README、主要入口点和核心代码。不要让用户解释产品。 阶段 2：课程设计 将课程结构化为 4-6 个模块。 普通版模块结构示例： 模块 目的 1 "应用做什么 + 核心用户操作" 2 认识角色（组件/服务） 3 各部分如何通信（数据流） 4 外部世界（API、数据库） 5 巧妙的技巧（缓存、错误处理） 6 当事情出错时（调试） 专业版模块结构示例： 模块 目的 1 架构全景（系统边界、主要组件） 2 核心抽象与领域模型 3 数据流与请求生命周期 4 设计模式与实现技巧 5 扩展点与自定义 6 技术债务与演进方向 每个模块应包含： 3-6 个屏幕（模块内流动的子节） 普通版：至少一个代码翻译块、至少一个交互元素、一两种解释技巧 专业版：至少一个架构图或数据流图、至多一个关键代码分析块 测验要求： 普通版：每个模块至少一个测验（多选、场景、拖放、找bug） 专业版：默认无测验，仅当用户明确要求"增加测验"时才添加 不要提交课程计划供审批 —— 直接构建它。 设计课程计划后，决定使用哪种构建路径： 简单代码库（单一用途 CLI、小型库、清晰入口点、5 个或更少模块）→ 直接进入阶段 3 顺序路径 复杂代码库（全