project-based-learning：教程该有的样子

注：仓库未提供通过可达性校验的公开配图，本节以纯文字呈现分析结论。

上一份文档我们聊了 build-your-own-x——从零造轮子，学底层原理。

这一份是它的表亲：从零做一个完整应用，学工程实践。

语法教程的断层

几乎每个编程新手都会遇到这个断层：语法教程教完了，你确实学会了变量、循环、函数、类和列表推导。然后呢？

常见的建议是"做个小项目练手"。但教程里的项目通常有两个问题：一是太简单（一个待办事项列表），二是技术栈单一（纯 Python 标准库，跟真实工程没关系）。做完之后，除了"我写过一个 todo list"，你其实没积累任何可迁移的能力。

这个仓库专治这个问题。

收录标准

它收集的教程有一个共同特征：跟着做下来，你会得到一个真正能跑的应用。

按语言分节：C/C++、C#、Clojure、Dart、Elixir、Erlang、F#、Go、Haskell、HTML/CSS、Java、JavaScript、Kotlin、Lua、OCaml、PHP、Python、R、Ruby、Rust、Scala、Swift，共 20 多种语言。

每个条目的格式统一是"教程名 + 一句话说明 + 链接"。比如 Go 方向有分布式 KV 存储、待办事项 CLI、负载均衡器、密码管理器、文本搜索工具、即时通讯软件、虚拟机、解释器、Git 客户端；Python 方向有 Pong、贪吃蛇、贪吃蛇 AI、俄罗斯方块、射线追踪器、解释器、 minesweeper、ASCII 着色转换器、货币转换器；Rust 方向有解释器、grep 替代品、CPU 模拟器、井字棋、操作系统内核。

注意那份清单的共同点：它们不是"练手小玩具"，每一个都触及一个真实系统的核心机制。负载均衡器要处理健康检查和请求分发，解释器要处理词法分析和递归下降，操作系统内核要处理中断和内存映射。做完这些，你对这门语言的理解会和刷完 100 道题完全不同。

维护上的一个亮点

这个仓库有一件事做对了，值得单列：

link-rot.yml 工作流定期检查所有外链是否还有效。

教程类仓库最大的敌人是链接腐烂。GitHub 教程类仓库的平均寿命很短，最常见的原因不是没人看，而是链接大面积失效后没人再回来。自动巡检是维持这类仓库生命力的关键。

仓库还有 scripts/ 辅助维护，CONTRIBUTING.md 规定提交规范。

用起来的几种方式

场景一：入职练手任务。 新人入职两周练习，直接从对应语言里挑一个项目，配一位 mentor 做 code review。效果比看文档好。

场景二：技术栈学习决策。 想学 Rust 但不确定值不值得——先看清单里有没有你感兴趣的项目（操作系统内核、grep 替代品），有就说明这条路有interesting的终点。

场景三：跨语言对比。 用同一个类型的项目（如解释器）分别在 Python、Go、Rust 里各实现一遍，能非常直观地感受到不同语言在这个任务上的取舍差异。

场景四：内部技术分享。 每个项目本身就是一份现成的分享大纲。

争议与局限

链接质量参差不齐。 链接巡检只保证"还能打开"，不保证"内容还适用"。指向 2015 年博客文章的教程，技术栈可能已经过时，代码跑不起来。README 里的描述是唯一的判断依据，需要自己读一段再决定投入。

没有难度标注。 和 build-your-own-x 一样，条目没有统一的难度、时长或前置知识标注。"Build an Interpreter" 对不同背景的人难度差异巨大。

质量完全依赖作者。 有些教程是作者精心打磨的完整课程，有些只是一篇粗糙的博客随笔。仓库没有审核机制去区分它们。

覆盖深度不均。 一些语言（如 Go、Rust、Python）条目丰富，另一些（如 OCaml、Elixir、F#）条目稀少或陈旧。

部分项目涉及法律灰色区。 清单里有"编写自己的比特币"、"逆向工程"这类条目，作为学习项目没问题，但需要提醒读者注意合规边界。

没有社区讨论。 没有 Discussions 区，问题交流依赖 issue 或原教程自己的评论区。

部分教程需要额外环境。 涉及图形、数据库、编译的项目，依赖准备可能比教程本身还费劲。

行业意义

如果 build-your-own-x 回答的是"底层原理怎么学"，那 project-based-learning 回答的是"工程能力怎么练"。

两者构成了开源学习资源的完整拼图——前者向下钻，后者向外扩。

它揭示的另一个现象是：开源社区早已自发形成了"教程质量分级"的需求，但缺乏有效的市场机制。GitHub 星数对教程几乎无意义（一个教程项目很难积累星数），而实际质量只有读完才知道。build-your-own-x 通过在描述里写"这是我能找到的最好版本"来人工标注，project-based-learning 则干脆不标——两种应对方式都不够理想。

对公司而言，我最推荐的用法是把它变成结构化的练手任务库：按团队当前的技术栈和招聘缺口筛出条目，翻译或改编成中文任务说明，配上验收标准和 mentor 机制。这样一个外部清单就能变成内部的工程能力培养体系。