回复一下评论区的朋友，这个实验文档有一些代码似乎都是未经审查的，存在一些打开并复制到vscode里就会被编译器提示报错的代码。包括助教似乎经常忘记学生拉取代码需要从upstream拉取而非origin拉取，让我对这个实验文档的质量存疑。

诚然，我自己也是纯vibe coding完成的实验，但这与课程实验的初心可能不太相符。过大的作业量和黑话满篇、不说人话的实验文档会让更多的学生“纯”vibe coding完成，而难以理解为什么要这样写代码，也缺失了实操的过程，造成事实上的“劣币驱逐良币”。

学期还没结束，这个实验文档看的我火大，来评课社区喷一下。

助教自认为自己很懂vibe coding, 于是这学期的所有实验产品，包括基础系统代码、实验文档、实验脚本基本都是vibe coding的产物。特别是实验文档，gpt味大的批爆，助教是直接拿codex生成的文档就弄成实验文档了吗😅？我读完我都要被助教的codex“稳稳地接住了”。文档理论上是给学生读的，不是给ai读的（当然如果真的是给ai读的那这一切就太合理了），拿着一个黑话满篇，“稳稳接住”的文档交给学生开始做实验，鄙人不太清楚助教的具体想法，以及助教是否真正尊重学生。

另外，本学期hw2的作业量尤为逆天，不太清楚是不是因为助教没有读过本科就直接读了研究生，不知道这些作业如果手搓需要花多少时间。当然，如果助教默认大家全部vibe coding的话那我无话可说。

关于文档”稳稳接住你“，文档链接在此 http://home.ustc.edu.cn/~pzw2002/ ，以下是一些实例，给大家添添乐趣。也欢迎大家在评论区持续投稿。

不是为了让大家“把实验交给 AI 来做”，而是希望大家尽早建立更稳妥的使用习惯

--摘自Lab简介

本实验的重点不是"重新实现一次模型推理"，而是把 HW2 中已经能运行的用户态推理后端，封装成一个更像操作系统服务的接口

--摘自hw2

这份文档不是课件提纲，而是给你课后自己读代码用的“导航图”

--摘自Lecture Companion CH2（我想说，哪个正常人类会说“导航图”这种话？是嫌“地图”两个字太简洁太易懂吗？）

CLI 不是"命令合集"，而是"命令调度器"。

--摘自Lecture Companion CH2

这一章的目标不是证明"仓库已经实现了 pthread"，而是帮你看清：线程为什么比进程更轻；一个可调度执行流至少需要什么状态；当前代码如果将来要支持线程，最可能从哪里改起。

--摘自Lecture Companion CH4

这份文档是给你课后独立看进程代码用的，不是课堂提纲。

--摘自Lecture Companion CH3

也就是说，syscall 编号、分发和用户态封装基本都已经准备好了。你在必做部分真正要补的是 ai_service.c 中的控制逻辑。——Lab2

也就是说，用户态看到的同步接口可以保留，但底层不应再绕开异步 service 主线。——Lab2

也就是说，你只需要把系统调用层打通到 fileioctl，不需要在 sys_ioctl 里直接处理具体 GPU 命令细节。——Lab1

所以最贴切的描述是：单内核实现 + 模块化代码组织。——CH2

先建立一个最重要的区分：Program vs Process

--摘自Lecture Companion CH3

先把边界说清：当前仓库还没有完整线程实现

--摘自Lecture Companion CH4

直接先说结论：

--摘自Lecture Companion CH4

从一个真实动作开始：在 shell 里输入 pid

建议你先在系统里实际运行一次：

pid

然后按这条路径阅读代码：

--摘自Lecture Companion CH2

从一个真实程序开始：先运行 pingpong

建议你先在系统里实际运行一次：

pingpong

然后按这条路径阅读代码：

--摘自Lecture Companion CH5