【AELS的下一步】怎么办？

[Charliechen114514]

AELS 的下一步，是什么？

我极少发讨论稿，但是我发了，说明我发了。

我实际上没有想到 AELS 今天会发展的如此庞大。到2026年8月23日上午8:00整，AELS 达到了652颗stars，96个fork。还算比较健康的star-fork比例。但是因为笔者注意到，和收集到越来越多的反馈，强烈的暗示AELS需要一些很强力度的改善，才能持续的帮助到更多的朋友更好的学习嵌入式和相关的领域。

首先是立flag环节。

AELS 的基本定位永远是——持续进步的完全开源免费的 Learning Studio。所以我们不指望第一时间产出一个多好用的Framework，笔者水平到不了。能做的只是尽可能的分享自己的知识和见解，供各位朋友参考和分析，批评和改进。

好了，下面说问题。当前的教程，我们注意到存在如下问题：

1. LLM过度的参与了项目的演进和开发，造成教程质量下滑，模块之间不连贯，甚至审查疏漏的幻觉错误内容误导新人，AELS应该尽快的在早期停止下这样令人倍感不妙的趋势
2. 跨教程的树形梯度虽然初步建立，但是不够明显，造成各仓库之间路由断裂，甚至初步出现重复建设的情况
3. 处于主要开发者们的现状，大家时间有限，需要逐步建立各位更加友好的——模拟优先，也方便建立CI验证保证教程质量。这也是后续我们尝试探索的第一优先级。

所以AELS如何看待和组织这些仓库初步的关系？

我们大致按照下面的顺序组织学习：

Embedded Box开始
→ 编程语言深度：C-Journey / TAMCPP / ASM
→ 更深的基本功：操作系统 / Linux / RTOS
→ 嵌入式实践：MCU / Embedded Linux
→ 独立的能够运行、验证和交付的完整工程

这不是一条所有人必须从头走到底的唯一道路。它更像一棵树：Embedded Box 提供共同工具和实验能力，根据自己的需要，看看语言线提供表达和控制机器的能力，系统线解释程序如何在真实系统中运行，最后再分到 MCU、Embedded Linux、上位机系统和产品工程。如果都不会，就按照整个顺序逐步的进行学习。

AELS 下一步的一些方向：四件事情和一个扩展

四件事会成为下一个阶段所有教学仓库的共同方向——精细化、清晰化、可验证、工程交接。

可验证，是下一阶段的第一要务。网站能够部署，只能证明 Markdown 和前端没有坏，不能证明知识、代码和工程是正确的。Renode, Qemu等，会逐步的接入到我们的项目中，构建一套AELS的验证范式，是我们AELS下一代的最重要的一项任务之一。

精细化，是因为现在 LLM 代笔内容很多，教程很容易看起来什么都讲了，实际知识之间却发生断裂。重复解释、空泛总结、没有来源的技术判断和没有跑过的示例，都会持续损害 AELS 的声誉。LLM 可以协助工作，但一个模块是否保留、怎样组织、技术上是否可信，最终必须由人判断和负责。

清晰化，是因为 AELS 现在看起来覆盖很广，却很难让学习者知道从哪里开始。每个仓库以后都要回答：前置知识是什么，这里负责什么、不负责什么，学完会得到什么，下一步进入哪个仓库或哪个工程。教程可以深，但不能让学习者迷路。

工程交接，是因为嵌入式学习最后一定要落到使用。一个教程如果永远没有工程终点，我们无法从中得到反馈，我们到底在做一个什么样的教程。

一个扩展说的是：支持 Windows 复现我们的所有实验现象和验证

感谢几位热心的朋友的提问——对于大部分嵌入式开发者，Windows 仍然是第一的主力使用平台，我最开始的时候没有顾虑到这一点（倒不如说就没想过真玩大了），横向支持Windows的实验，是我们下一代扩展的重要方向。

共同地基

这一部分，是初步公布一下每一个仓库后续可能的方向，不代表我们就是这样，所有仓库的调研和开发指南会重新基于本讨论再次设计，发布到对应的仓库目录下。

0a. 所有的非嵌入式方向的仓库

1. 所有的非嵌入式方向的仓库主要是进一步系统的强化去LLM，重组和重写部分校正力度差的教程。典型的有C-Journey等。
2. 此外，需要第一倾斜的补充一下嵌入式相关的应用，我们的头部考虑是TAMCPP重启带有嵌入式优先的领域建设。

0b. 所有嵌入式方向的仓库

1. 尽管嵌入式是一个需要软件，硬件结合的领域，笔者仍然想尝试模拟器先行，最后落到实际的开发板上的教程。探索一个尽可能逼近真实的模拟环境（笔者之前缓慢甚至是停更进度，就是在不断调研更好的，可被CI工作流验证的开发指南）

2. 几乎需要重组教程，包括重新设计下一代的，基于Python的可验证的工作流。rk-forge已经迁移到python组织的工作流了，但是教程上可以说是一塌糊涂，需要进一步大规模的改写。

3. EmbedBox（最开始一段时间内，我们最聚焦建设的仓库）

   EmbedBox 承担所有路线共同需要、恰好够用的基础嵌入式开发知识。换而言之，它是 AELS 语境下“嵌入式中的 CSAPP”，也是进入其他仓库之前的共同实验工作台。

   终端、Git、Markdown、编译过程、GCC、Make、CMake、GDB、交叉编译、串口、Docker、QEMU，以及最小的硬件操作和实验安全，可以在这里形成一条连贯路线。它不继续向 C/C++ 语言细节、内核机制、RTOS API 和具体板卡 BSP 无限扩张，这些深度内容应交给后面的承重墙。

   EmbedBox 不能继续只是一组工具文章。它最终要有一条完整实验：学习者从 clean clone 开始，能够构建一个小程序、调试它、交叉编译它、在 QEMU 中运行，并保存一次可追溯的串口或运行结果。中间发生了什么，也需要大致说个一二。

4. C-Journey

   C-Journey 是 C 语言承重墙。它负责 C 语言语义、对象与内存、数据结构、错误处理、工程组织、C API，以及进入 POSIX 系统编程的道路。

   现有 Stage 0 中与 EmbedBox 重复的 Git、构建和工具内容应该逐步改为引用，不需要立即粗暴搬家，但要先确定唯一负责仓库。C-Journey 自己的精力应放在 C 的知识深度、示例正确性、双编译器验证、sanitizer 和真正能够交付的小型 C 工程上。

   它的工程终点可以保留两级：先做一个有测试和版本的 C 库，再做一个 Reactor 或网络应用。完成后，学习者可以进入 ASM、FreeRTOS、PenguinLab 或 Embedded Linux。

5. Tutorial_AwesomeModernCPP

   TAMCPP 是现代 C++ 承重墙，也是当前 AELS 最成熟的内容旗舰之一。它已经证明了大体量教程可以同时拥有示例、质量检查和连续 Release，接下来不是继续无边界扩容，而是更仔细地修正内容边界和知识密度。

   C 速通应该逐步路由到 C-Journey，通用工具教程应该路由到 EmbedBox，STM32 板级课程应该交给 ST-Forge。TAMCPP 自己保留现代 C++ 语言、标准库、并发、性能、工程约束，以及嵌入式 C++ 独有的零开销、内存、异常和静态设计问题。

   它的结课结果不只是“读完十卷”，而应该是一个能够被其他工程消费的现代 C++ 库或应用，带测试、sanitizer、benchmark、安装和版本。

6. 未来的 ASM

   ASM 也是嵌入式学习中实际上总是跑不掉的一环，不过，为了防止仓库膨胀，笔者初步计划先个人仓库建设，成熟后再转入 AELS。建议保持一个仓库，内部维护 RISC-V、ARM32、x86-64 三条轨道，而不是一开始拆出三个仓库。

   三条轨道共享数据表示、寄存器、栈、调用约定、C ABI、ELF、链接、反汇编、GDB、原子和内存序。先把 RISC-V 做完整，再逐步扩展 x86-64 和 ARM32，不同时铺开。

   最终结课物可以是一份由三种汇编分别实现的 C ABI 小库，通过同一组语义测试、反汇编检查和调试轨迹验证。这样 ASM 不会停留在指令表，也能自然交接给 Cinux、PenguinLab 和 STM32。

7. Tutorial_AwesomeQt

   AwesomeQt 继续作为 Qt 内容旗舰。下一阶段重点不是继续增加控件数量，而是清理知识路线，强化示例的行为验证，并明确教学实例怎样进入真实组件工程。

   教程中的每个大型实例都应该回答它是一次概念演示，还是一个准备进入组件库的候选。候选组件需要有来源、测试、兼容边界和真实消费者，不能让教程代码和产品组件长期平行漂移。

8. Tutorial_AwesomeHardware

   整个仓库起源于跟自己大学同学的灵感（感谢大佬，分享的不错的硬件书籍），整个仓库是我读完之后快速总结 + LLM 做扩展得到的。

   AwesomeHardware 目前最强的是电力电子内容，不应该假装已经覆盖了全部嵌入式硬件。它可以保留为硬件深度知识仓，同时抽出一条“恰好够用”的短基础轨：逻辑电平、上拉、时钟和复位、供电与去耦、总线电气层、datasheet、原理图，以及万用表、示波器和逻辑分析仪的基本使用。

   通用测量知识可以和 EmbedBox 互相路由，STM32 的具体接线和实验验收归 ST-Forge。它的工程终点应该是一份可以审查的小板或外设接口设计，包含原理图、BOM、计算、bring-up 测量和故障分析，而不只是读完文章。

9. PenguinLab

   PenguinLab 是下一阶段改造最重的核心仓库之一。它负责通用 Linux 内核实验，而不是再做一套 Linux 使用命令大全，也不承担具体板卡 BSP。

   它需要从粗糙的 LLM 杂味和巨大知识图谱中收缩出来，先把真正成熟的内容做深。最小 Linux/QEMU、内核与用户边界、模块、核心子系统、驱动和调试应该逐步形成可以运行的实验。眼前最重要的不是继续补文章，而是完成 QEMU boot、login、insmod 和行为检查。

10. Tutorial_FreeRTOS

    我们计划完全重新设计 FreeRTOS 的教程。作为一个OS的一个分支，RTOS的确广泛的用于任何追求实时性的平台。

    这份仓库也将会是第一个横跨可以在 Windows 和 Linux 的一个仓库，具体的建设细节，将会开展到对应的仓库的Discussion中。

11. Cinux-Book

    Cinux-Book 负责“从零把一个操作系统做出来”。它应该是一条稳定、可解释、能够逐章重放的教学线，而不是 Cinux 的第二个前沿分支。

    Cinux 的稳定能力可以按版本进入 Book，但不直接复制 main。每次迁移都要重新解释前置知识、实现顺序、测试方法和故意省略的复杂度。最终结课是启动一个带多终端 GUI 的系统、运行原生程序，并独立完成一个带 QEMU 回归测试的内核扩展。

从语言走向工程

10. engineering_cpp

engineering_cpp 应该成为 TAMCPP 之后的工程方法 hub，而不是继续铺一张巨大的第二季愿景。它负责反复讲清楚一套方法：需求怎样收敛，接口怎样设计，最小纵切怎样形成，错误怎样表达，测试怎样建立，最后怎样安装、发布并被下游消费。

ArgParser、FileCopier、DirScanner 等小项目保留在 hub 中，适合展示横向共同方法；SimpleIniParser 和 anatomy_memory 继续作为独立 spoke，负责更完整的工程深入。

11. Tutorial_cpp_SimpleIniParser

SimpleIniParser 是最适合用来证明“工程导向教学”的第一个小仓库。它不追求成为最强 INI 库，也不进行一次性推翻重写，而是采用小步迭代的方式，之后，会逐步演变为一个独立的合适的hub。在这里，每一步都保持能够构建、能够测试、能够回退。最终交付一个小而明确的 iniparser 库、一个 ini-check 工具和一个真实消费示例，完整演示“小工程怎样做对”。

12. anatomy_memory

anatomy_memory 适合作为更高阶的工程实验，但它首先应该教正确性，而不是预设“自己写的内存池比 malloc 快”。

第一阶段是 correctness：初始化、所有权、对齐、size class、不变量、错误释放、跨线程行为，以及 ASan、UBSan、TSan。

第二阶段才进入 performance：span/page、缓存回收、命中率、稳定 benchmark、原始数据和多基线比较。

这个仓库真正值得学习的是，怎样用工具和实验把一个看起来正确的 allocator 推到可信，以及怎样诚实解释它为什么仍然不是生产级分配器，并且逐步挑战和尝试成为一个这样的分配器。

13. bareline

    bareline 保持一个小而真实的 MCU shell 工程。它适合连接 TAMCPP 和 STM32，展示无堆、无异常、静态分派、Host mock、交叉编译和体积约束。

    我们计划将 bareline 从一个已经实际完成测试的工程，转向一个教大家如何写出MCU级的命令行框架的教学仓库。

14. CFBox

    CFBox 是 AELS 已经形成的真实系统工程之一。它不需要把一百多个 applet 逐个改造成教程，而应从中挑出少量代表性纵切：明确 POSIX 行为，编写差分测试，完成交叉构建，进入 QEMU/rootfs，最后在真板上作为 PID 1 运行。

    它可以成为 Linux userspace 的高级结课工程，同时继续保持产品自身的工程质量。教学线学习的是一个 applet 怎样从需求走到系统交付，而不是背诵命令数量，那没有意义。

STM32：当前最重要的嵌入式建设

MCU 方向暂时只把 STM32 建好。这比同时打开更多芯片、SDK 和无线生态更重要。

15. ST-Forge

    ST-Forge 是 AELS 唯一的 STM32 主教学线。它应该从一个干净仓库探索新的单片机教学范式：同一个实验尽可能具备 Host 可测逻辑、无板模拟和真板证据。

    现在不扩章节，不扩板卡，先完成一份 Blue Pill golden firmware：能够 clean build，产出 ELF/BIN，通过 micro-forge 的支持范围内验证，再在真板完成 flash、debug 和结构化运行记录。只有这条最短闭环成立，后面的启动、中断、外设和 RTOS 课程才有可靠地基。

16. micro-forge

    micro-forge 是 MCU 无板验证和可观测性基础工具，不是另一套 STM32 教程。它继续聚焦模拟正确性、支持矩阵、确定性执行、故障注入和固件测试接口。

    ST-Forge 向它提供课程 golden firmware，它向 ST-Forge 提供自动回归和可观察证据。不追求一次覆盖所有 STM32 和全部外设，先让现有能力成为稳定、可发布、真正被课程使用的验证底座。

17. BareMetal-Drivers

    BareMetal-Drivers 现在更像一个历史资产池：驱动、平台启动、应用、图形和 UI 混在一起，很多能力还没有真实消费者和自动验证。它不应该继续无边界增加驱动。

    以后驱动先在 ST-Forge 或 MicroWatch 中工作，经过 Host 可测逻辑、明确 HAL/backend 边界、构建 CI、支持矩阵和真实消费后，再晋升到 BareMetal-Drivers。无法达到这些条件的代码留在具体工程中，不急着抽象成公共库。

18. Project_MicroWatch

    MicroWatch 是 STM32 路线的高阶综合结课工程，不是基础教程，也暂时不是成熟产品。它负责暴露真实集成问题：芯片迁移、FreeRTOS、输入、显示、低功耗、持久化和驱动版本。

    第一版只完成可构建、可烧录、可观察的最小手表：时间、闹钟、输入、OLED 和持久化。Dino、计步、指南针等功能延后。

19. Tutorial_AwesomeHardware 与 STM32 的交接

    硬件仓负责原理、电气、测量和故障分析，ST-Forge 负责具体板卡接线、固件和验收。两边不重复维护另一套 STM32 工程教程。进入真板课程前，学习者应完成一份最小硬件安全和测量检查，而不是只会复制烧录命令。

Embedded Linux：从 Linux 百科回到板级工程

20. imx-forge

    imx-forge 是稳定、入门友好的 Embedded Linux 工坊。它保留 i.MX6ULL 启动链、NXP BSP 与 mainline 对照、设备树、板级驱动、烧录、镜像和真板交付。换而言之，imx-forge将会是我们AELS嵌入式工程开发的一个大的入口。

    通用 Linux 命令、进程内存文件系统通识、通用内核模块 API 和通用 Qt 使用教程，应逐步迁移或路由到 EmbedBox、PenguinLab 和对应深度仓库。imx-forge 不再承担 Linux 百科，而是把一块板从源码带到可用系统，并保存完整 BOM 和真板证据。

21. rk-forge

    rk-forge 是更高级的 Rockchip 主线化和 BSP 工程路线。它不复制 imx 的入门教程，重点保留 vendor 与 mainline 的差异、启动链和 blob 边界、多板配置、补丁维护、存储可靠性和能力级真板证据。。

22. h618_forge

    h618_forge 保留为 Allwinner 主线化研究路线。它最有价值的是无厂商 blob 启动、主线 HDMI 和真板研究，而不是再建设第三套完整 Embedded Linux 教程。所以比起来，我们只是提供有意思的工程和玩法，而不会去深度挖掘（至少现在不咋打算）

23. lightroot

    lightroot 有实际实现，但当前目标过宽，也仍然绑定作者目录和相邻工作树。它先收缩为构建系统实验：typed IR、依赖解析、lockfile、executor，以及一个最小 rootfs。

    只有它能够在 CI 中跑完自身测试，并从固定输入生成可以在 QEMU 启动的 BusyBox/CFBox rootfs 后，才继续讨论挑战 Buildroot、管理完整 BSP 或扩展 package zoo。现在不让它接管 imx/rk 的构建主线。

产品和公共组件

24. Cinux

    Cinux 是独立产品线，继续承担前沿 OS 能力探索、完整集成和强 QEMU 回归。它不需要同时承担从零教学，也不能让“已有 v1.0”被误解成通用生产 OS。

    每个稳定里程碑选择少量能力进入 Cinux-Book，附带固定版本、最小文件映射、测试、已知限制和教学重放顺序。产品继续向前，Book 只在稳定点吸收。

25. aex

    aex 保持真实产品组件身份。它的能力由真实消费者推动，不继续以“适合所有 AELS C++ 项目”为理由收集更多轮子。下一步是稳定现有 API、补正式 Release 和 consumer CI。

26. QuarkWidgets

    QuarkWidgets 保持 Qt 组件中枢身份。教学线可以抽取一个控件，解释状态机、输入、主题、可访问性和视觉回归，但不把整个产品仓改写成教程。它自身需要明确兼容政策和真实 consumer build。

27. edgecv

    edgecv 当前不扩大范围。它必须先在“教学型 OpenCV 类型安全 facade”和“真实产品基础库”之间做出选择。没有板端或产品消费者前，不继续宣传 embedded-ready，也不再复制 TAMCPP 已经负责的 Concepts、RAII 等语言教程。

一些附录笔记、

好了说完了，这份草稿只是最初的一些设计想法和变更，一点不意味着这就是笔者最后的改造清单指南。以上！

[Epochlcc]

大佬能否创建一个微信群或者qq群之类的国内讨论群。

[Charliechen114514]

哦哦可以的！目前的话是只有tamcpp有QQ群，不过的话其他我可能会共同创建一个群，可以的话我会挂到首页，感谢反馈！

[Charliechen114514]

大佬好，这个是一个交流总群！是QQ群awa，欢迎随时进来唠唠！