Maintained · 持续维护Case 03 / Learning infrastructure
Study
先选一个问题，再把开源项目与经典论文放在同一条路径里读，建立可以迁移的工程判断力。
A public learning system that organizes open-source implementations and classic papers around real engineering questions, not content categories.
- Role
- 作者 · 信息架构与内容系统设计
- Audience
- 希望建立工程判断力的零基础学习者
- Core loop
- 问题 → 路径 → 项目 / 论文 → 最小验证
- Public check
- 2026.07 · 站点与源码持续更新
19
Topic clusters
Projects × Papers
Question-led learning paths
内容越多，越需要回答“为什么从这里开始”。
单独按“项目”和“论文”分类，容易把学习者分流到两个互不相干的收藏夹。真实学习却总是从问题开始：状态为什么难管理、Agent 为什么会失控、分布式系统为什么不能假设全局时钟。
Study 的产品任务因此不是继续增加目录，而是把项目里的工程实现与论文里的思想源头放到同一条可进入、可继续、可验证的路线中。
内容仓库背后是一条持续生成、审查与发布的管线。
- 候选项目与论文进入独立队列，按主题和前置知识归类。
- 项目研究与论文研究分别使用结构化方法，要求落到源码、实验或可复现的最小验证。
- 构建脚本重新生成 Atlas、主题路径与内容计数，避免手写索引漂移。
- 链接、Wiki 歧义、计数与产品信息架构审计共同构成发布门禁。
- Astro + Starlight 构建后由 GitHub Pages 发布。
- Astro
- Starlight
- Markdown
- Node.js
- GitHub Actions
- GitHub Pages
把规模从卖点降为基础设施问题。
首页先给路径，不给全量目录
前端、AI Agent 与系统底层三条新手路线先提供前三篇，主题页再展开分支；全量 Atlas 只服务知道自己要找什么的读者。
项目和论文混排
一条路径内可以先读 React 实现，再读状态或调度相关思想。分类仍保留，但不再决定用户从哪里开始。
内容质量必须有可执行门禁
计数、链接和索引由脚本生成与审计；“每篇都很深入”不能仅靠文案保证，因此案例公开说明 AI 协作与深度差异。
公开可检查的证据。
边界与可信度说明。
Content boundary
内容由 Jason 与 AI 协作生成和重组。公开数量代表覆盖面，不代表每篇都经过同等强度的源码运行、论文逐页核验或人工编辑。
旧状态文件仍记录项目线与论文线早期的 20 / 20 里程碑，而当前站点已扩展为更大规模的主题地图。案例以线上首页和当前构建结果为准，历史文档只作为演化证据。