实验0：AI 工具与 Vibe Coding 入门¶

本节目标

了解 AI 编程工具的大致发展脉络，并建立一个够用的基础认识。
区分“模型（Model）”“Agent”“网页 chatbot”与“带项目上下文的 AI 编码工具”这几个容易混淆的概念。
理解什么是 vibe coding，以及它适合做什么、不适合做什么。
建立适合操作系统实验的 AI 使用习惯：会提问、会验证、会纠错。

阅读建议

本文是 Lab0 中关于 AI 编程工作流的补充导读。重点不是比较哪个产品“更强”，而是帮助你回答三个问题：AI 工具能做什么、不能做什么、在操作系统实验中应该怎么用。

1 为什么要在实验准备阶段讨论 AI 工具¶

当前不少同学对 AI 的接触，仍主要停留在网页 chatbot。它很适合用来解释概念、分析报错、润色文字，但默认并不会主动读取整个项目仓库，也不会直接替你执行一整套开发流程。

网页 chatbot 交互

Q 为什么要学习操作系统？

另一类工具更贴近真实开发流程：它们可以在编辑器或终端里读取项目上下文、搜索文件、提出最小修改方案，必要时还能辅助执行编译、测试和调试步骤。

一次带项目上下文的 AI 编码工具交互（CLI 入口）

$ 在 nexos 仓库中，先读取 README.md 了解项目，再帮我修改 user/hello.c，让它在原有输出后额外打印一行 [user] lab0 demo。

这个区别对本课程尤其重要。操作系统实验里的很多任务，既不是纯概念问答，也不是只靠局部补全就能完成；你需要读目录、看日志、改少量代码、运行命令、定位错误，再回到代码路径里验证。AI 一旦进入这个流程，它的帮助会很大，它的误导也会很大。

先记住四个最小概念

网页 chatbot：更适合解释概念、讨论思路、分析一段你主动贴进去的内容。
带项目上下文的 AI 编码工具：更适合在真实仓库里读代码、查文件、给出最小修改方案，必要时辅助执行命令。
model：负责生成文字、代码与解释的底层能力。
agent：在模型基础上进一步读取上下文、调用工具、分步执行任务的系统形态。

如果你只想先看助教偏经验向的工具选择建议，请阅读实验0补充：AI 工具助教推荐。

2 可选背景：工具、模型与 Agent¶

AI 编程工具的发展脉络

较早期的 AI 编程工具主要提供“自动补全”能力：根据当前文件上下文，为你补出下一行代码、一个循环、一个函数框架。这类工具提升的主要是输入速度。

随后，AI 工具逐渐演变为“对话式助手”：你可以直接提出问题，例如“解释这段 Makefile 在做什么”“为什么这里会出现段错误”“satp 寄存器的作用是什么”。这时，AI 提升的就不只是输入速度，也开始帮助你做解释、总结、改写与表达转换。

截至 2026 年，越来越多的 AI 工具已经不再局限于“回答问题”，而是开始具备一定的 agent 能力，例如：

搜索仓库中的多个文件；
根据目标修改多个位置；
执行编译、测试或格式化命令；
生成补丁、修改说明，甚至辅助完成一轮较完整的开发流程。

这意味着 AI 编程工具的角色，正在从“回答问题的助手”转向“在你监督下执行子任务的协作者”。

本文采用的一个实用分类

为了便于初学者理解，这里不刻意把 IDE 助手和 CLI 工具严格拆成两类，而是先做一个更实用的区分：

工具形态	常见例子	典型交互方式	擅长任务	主要风险
网页对话助手	国内常见：Kimi、豆包、通义千问、腾讯元宝；国外常见：ChatGPT、Gemini	通过自然语言连续追问	概念解释、命令说明、报错分析、文档草稿	容易脱离真实代码仓库上下文
带项目上下文的 AI 编码工具	例如 Trae、通义灵码、Cursor、GitHub Copilot、Codex CLI、Claude Code	在编辑器或终端中读取仓库上下文并辅助完成任务	局部补全、跨文件修改、读代码、调试辅助、运行命令	更容易让人过度信任自动修改结果，且错误影响范围可能更大

一个重要观察

现代 AI 编程工具真正的分水岭，往往不是“回答得像不像人”，而是它是否拥有代码上下文、是否能执行动作、是否会主动验证结果。

Model 和 Agent 的区别

很多同学刚开始接触 AI 工具时，容易把“模型”和“Agent”混在一起说。为了后续讨论方便，这里先给出一个适合课程场景的简单区分：

概念	可以怎样理解	核心能力	常见局限
模型（Model）	工具背后的“生成引擎”	根据输入的提示词与上下文生成文字、代码或解释	默认并不能直接读取你的仓库、执行命令或修改文件
Agent	围绕模型封装出来的“会做事的系统”	在模型基础上进一步调用工具、分步规划、读取文件、执行操作	能力更强，但一旦判断错了，也更容易放大错误

你可以先把它们粗略理解成：模型更像负责“想和说”，Agent 更像负责“看、想、做”。

一个实用判断方法

如果某个 AI 工具只能根据你贴进去的内容回答问题，它更接近“模型驱动的助手”；如果它还能主动搜索仓库、读取文件、执行命令、修改代码，那么它就更接近 agent。

边界不是绝对的

现实中的产品经常处于两者之间：有些网页助手也能联网或读取附件，有些 IDE 功能只是局部补全，有些 CLI 工具也只是把对话能力搬进终端。这里的区分主要是为了帮助你建立清晰的第一层认识。

一些常见的模型例子

下面这些内容主要用于举例。模型名、发布日期和入口页面都可能随时间变化，因此阅读时不必把它们当作长期稳定结论。

Claude Opus 4.6：Anthropic，于 2026 年 2 月 5 日发布。
Claude Haiku 4.5：Anthropic，于 2025 年 10 月 15 日发布。
Claude Sonnet 4.6：Anthropic，于 2026 年 2 月 17 日发布。
“Codex-5.4”：如果按很多同学在编程工具里的口头说法，可以把它理解成 OpenAI 在 Codex 中提供的 GPT-5.4；更准确地说，OpenAI 官方模型名是 GPT-5.4，发布于 2026 年 3 月 5 日。
Gemini 3 Pro：Google，于 2025 年 11 月 18 日以 preview 形式发布。

模型排名仅供参考，可查看 SonarSource LLM Coding Leaderboard。

一些常见的 Agent 例子

下面这些更适合作为 agent 形态的例子来理解。它们本身不是“底层模型”，而是建立在模型之上、能够读取上下文并执行动作的工具或系统：

Claude Code：Anthropic 的终端式 AI 编码工具，适合在仓库里读代码、改代码、跑命令。
Codex：OpenAI 的 AI 编码 agent，支持从读仓库到完成工程任务的一整套工作流。
Augment：强调大代码库上下文理解，提供较强的 IDE 内 agent 工作流。
Cursor：面向编辑器场景的 AI 编码工具，也支持更完整的 agent 式任务交互。

3 什么是 `vibe coding`¶

通常所说的 vibe coding，可以粗略理解为：

你先用自然语言描述目标，AI 很快给出一版实现；然后你根据运行结果继续追加需求、修修补补，逐步把东西“带出来”。

它强调的是一种高迭代速度、低前期设计负担的开发方式。你不一定会先写完整设计文档，也不一定会先把每个接口想清楚，而是先让系统跑起来，再不断调整。

这种方式之所以流行，是因为它对下面几类任务特别有效：

小工具、脚本、自动化任务；
原型验证（prototype）；
文档整理、样板代码生成；
重复但不复杂的工程性修改。

但是，vibe coding 并不等于“可以不理解代码”。它更像是一种探索式开发模式，而不是对严谨工程方法的替代。

在操作系统实验里，不能只靠感觉

对于 trap 路径、页表映射、上下文切换、锁、内核栈、用户态/内核态切换等关键路径，任何 AI 生成的代码都必须经过你自己的阅读、编译、运行和调试验证。这里只靠“看起来差不多”是非常危险的。

4 在操作系统实验中，AI 适合做什么¶

4.1 比较适合交给 AI 的任务¶

解释一条命令、一个报错或一段构建日志；
帮你总结某个目录或某个文件的大致作用；
把一段难读的代码改写成带注释的伪代码；
给出调试路径，例如“先看哪里、再打哪些断点、最后检查哪些变量”；
帮你整理实验报告结构或润色技术文档。

例如，在你完成了 Linux 基础教程、Git 提交、分支与合并与实验内核运行与调试之后，AI 可以很好地帮助你理解：

make、make qemu、make fsimg 各自做了什么；
gdb 调试时为什么需要断点、回溯和寄存器检查；
一段 panic 日志更可能属于“编译问题”“链接问题”还是“运行时逻辑问题”。

4.2 需要高度警惕的任务¶

下列任务并非不能让 AI 参与，而是绝不能直接照单全收：

修改异常处理、系统调用入口、调度器等关键控制流；
推导页表权限位、地址换算、栈布局等底层细节；
编写或修改 asm 代码；
处理锁、并发、竞态和内存可见性问题；
针对某份旧版本代码仓库生成“看起来能用”的补丁。

最常见的错误

AI 往往会一本正经地“编造”并不存在的函数、结构体字段、寄存器语义或构建参数。在内核实验里，这类错误尤其隐蔽，因为它们经常能骗过肉眼检查，却会在运行时导致 panic、死循环或诡异的寄存器状态。

5 一个推荐的 AI 使用工作流¶

下面给出一个适合课程实验的基本工作流。核心思想是：先理解，再生成；先小改，再验证。

先自己读题目与目录结构。 不要一上来就让 AI “把实验做完”。
让 AI 帮你解释，而不是替你决策。 先问“这段代码在做什么”，再问“我可能该改哪里”。
要求 AI 给出最小改动方案。 避免它一次性生成过大的补丁。
人工审查关键不变量。 例如锁的获取/释放是否配对，状态转换是否正确，地址空间切换是否合理。
必须自己运行命令验证。 包括编译、启动、功能测试、日志检查和必要的 gdb 调试。
最后自己总结。 你应当能解释“为什么这样改”“哪里最容易错”“我如何验证它是对的”。

5.1 一个更合适的提问模板¶

与其直接问“帮我把这个实验做掉”，不如使用更有约束的提问方式，例如：

你现在是一名操作系统课程助教。请先不要直接给出最终代码，而是按下面顺序回答：
1. 用 5 句话解释这段代码的作用；
2. 列出可能需要修改的文件；
3. 给出最小改动方案；
4. 标出最容易出错的寄存器、锁或状态转换；
5. 最后再给出一个可验证的实现思路。

5.2 一个更适合调试的提问模板¶

下面是我的报错信息和相关代码。请先判断这更像是编译错误、链接错误、运行时错误还是逻辑错误，
然后给出排查顺序。不要跳过验证步骤，也不要假设仓库中存在未给出的函数。

6 在本课程中使用 AI 的红线与边界¶

以课程正式公告为准

本节给出的是文档层面的建议，用来帮助大家建立合理习惯。若任课教师或助教在课程公告、评分说明中发布了更明确的 AI 使用规则，应以正式规则为准。

建议至少遵守以下原则：

可以使用 AI 帮助你解释概念、梳理思路、分析报错、润色文档；
不应直接提交自己没有读懂的代码；
不应把“AI 给出的答案”当作“规范本身”或“手册本身”；
提交前，你应当能够独立解释关键改动的目的与效果；
使用第三方 AI 工具前，应确认仓库内容、日志信息和账号信息是否适合提供给外部服务。

关于 AI 使用与学术诚信

使用 AI 本身并不等于违反规则，但把自己没有理解、没有验证、无法解释的内容直接作为个人作业提交，就很容易触碰学术诚信边界。

对本课程来说，更稳妥的做法是：把 AI 当作辅助手段，而不是替代思考的工具；保留自己的分析过程，明确哪些内容是自己判断出来的，哪些内容只是参考了 AI 的建议。若课程后续发布了更明确的 AI 使用规范，应始终以课程正式公告和评分要求为准。

7 一个适合入门阶段的小练习¶

练习题

任选一个你熟悉的 AI 工具，完成下面三个小任务：

让它解释 make qemu 的作用，以及它依赖哪些前置步骤。
让它根据一段 panic 或报错日志，给出排查顺序。
让它总结你当前实验代码仓库中 kernel/、user/、tools/ 三个目录的大致职责。

完成后，请你自己回答两个问题：

哪一部分解释最有帮助？
哪一部分回答虽然流畅，但你并不完全相信？为什么？

8 总结¶

本节想传达的核心其实很简单：AI 可以显著提高学习和开发效率，但它不是理解系统原理的替代品。在操作系统实验里，你真正需要掌握的，始终是对代码路径、系统状态和验证方法的理解。

把 AI 当作解释器、提纲助手和调试助手，而不是“代做工具”；
优先让 AI 帮你理解代码、定位问题、设计验证步骤，而不是直接生成最终答案；
对任何涉及 trap、页表、调度、并发、汇编的修改，都必须自己阅读、编译、运行和调试；
如果你不能独立解释一段代码为什么这样写、为什么这样改、为什么它是对的，就不应该把它提交为自己的实验结果。

最终，希望大家形成这样一种使用习惯：可以借助 AI 提高效率，但不能把“看起来能跑”当作“我已经真正学会”。只有当你能独立解释问题、复现过程并完成验证时，AI 才真正帮助你完成了学习，而不只是替你暂时生成了一份答案。