diff --git a/docs/labs/0x01/tasks.md b/docs/labs/0x01/tasks.md
index 369075d..050710d 100644
--- a/docs/labs/0x01/tasks.md
+++ b/docs/labs/0x01/tasks.md
@@ -177,11 +177,30 @@ unsafe {
 
 ### 调试内核
 
+
+依据[调试教程](../../wiki/debug.md)的相关内容，搭建基于命令行的 GDB 调试环境。
+
+作为实验的推荐调试环境，你需要配置好 `gef` 插件以进行更加灵活的二进制调试。同时利用 VSCode 进行调试也是一个不错的选择，鼓励你进行尝试，它将会作为实验的加分项目之一。
+
 最后，你需要检验是否成功加载了内核：
 
-将断点设置在内核的入口处，使用 GDB 调试你的 bootloader，观察内核的入口点是否正确、页面是否按照 ELF 的描述正确映射、内核的代码段是否正确加载等等。
+- 使用 `make build DBG_INFO=true` 编译内核，确保编译时开启了调试信息。
+- 使用 `make debug` 启动 QEMU 并进入调试模式，这时候 QEMU 将会等待 GDB 的连接。
+- 在另一个终端中，使用 `gdb -q` 命令进入 GDB 调试环境。
+
+    !!! note "使用 `.gdbinit` 方便你的调试过程"
+
+        以下是一个 `.gdbinit` 的例子，你可以将其放置在你的工作目录下，这样每次进入 GDB 调试环境时，它都会自动加载。请注意部分指令是 `gef` 所提供的，详情请见调试文档。
+
+        ```bash
+        file esp/KERNEL.ELF
+        gef-remote localhost 1234
+        tmux-setup
+        b ysos_kernel::init
+        ```
 
-*你可能需要先完成后续章节进行调试环境的配置。*
+- 使用 `c` 命令继续执行，你将会看到 QEMU 窗口中的输出，同时 GDB 将会在断点处停下。
+- 查看断点处的汇编和符号是否正确，使用 `vmmap` 和 `readelf` 等指令查看内核的加载情况。
 
 !!! tip "遇到了奇怪的问题？尝试更改 `log::set_max_level(log::LevelFilter::Info);` 来调整日志输出的等级，以便你能够观察到更多的日志输出。"
 
@@ -195,15 +214,7 @@ unsafe {
     - 如何为内核提供直接访问物理内存的能力？你知道几种方式？代码中所采用的是哪一种？
     - 为什么 ELF 文件中不描述栈的相关内容？栈是如何被初始化的？它可以被任意放置吗？
 
-## 搭建调试环境
-
-依据[调试教程](../../wiki/debug.md)的相关内容，搭建基于命令行的 GDB 调试环境。
-
-作为实验的推荐调试环境，你需要配置好 `gef` 插件以进行更加灵活的二进制调试。同时利用 VSCode 进行调试也是一个不错的选择，鼓励你进行尝试，它将会作为实验的加分项目之一。
-
-!!! question "实验任务"
-
-    根据上述调试教程，回答以下问题，并给出你的回答与必要的截图：
+    根据上述调试过程，回答以下问题，并给出你的回答与必要的截图：
 
     - 请解释指令 `layout asm` 的功能。倘若想找到当前运行内核所对应的 Rust 源码，应该使用什么 GDB 指令？
     - 假如在编译时没有启用 `DBG_INFO=true`，调试过程会有什么不同？