一、简介
AI是一个强大的工具。至少到现在这个阶段，还是无法完全替代人，但对于有经验的工程师，通过AI赋能可以极大的提高效率。
1.1 AI 擅长什么
AI 擅长代码逻辑分析，擅长处理有规律有既定规则的重复性的任务，擅长批量式输出。
| 类别 | 具体场景 | 效果 |
|---|
| 模式匹配与移植 | 参照现有驱动编写同类设备驱动 | 优秀。AI 能快速识别代码模式并复现 |
| 批量重命名/重构 | 类型替换、函数重命名、符号统一 | 优秀。速度快且比人工更不易遗漏 |
| 样板代码生成 | probe/remove 骨架、file_operations 模板、Kconfig/Makefile | 优秀。一次生成，少量修改即可用 |
| 编译错误解读 | GCC 多行模板展开的冗长错误 | 优秀。AI 能剥离噪声，定位真正原因 |
| 代码审查 | 锁缺失、资源泄漏、goto 标签错误 | 良好。常见模式能覆盖，但需人工确认 |
| API 用法查询 | dma_alloc_coherent 参数含义、request_irq flags | 良好。对稳定 API 的记忆准确度高 |
| 反汇编对照分析 | oops 地址映射到 C 代码行 | 良好。结合 objdump 和源码能精确定位 |
| 日志模式识别 | 从大量重复 crash 日志中提取分布规律 | 良好。能做统计分析和异常聚类 |
| 调试脚本生成 | kprobe 命令、GDB 脚本、tracepoint 插桩 | 良好。按需生成，减少手写工作量 |
| 文档与注释撰写 | 函数注释、模块说明、commit message | 良好。格式规范，逻辑清晰 |
| 测试用例生成 | 边界条件测试、错误路径覆盖 | 可用。需人工补充硬件相关的边界场景 |
1.2 AI 不擅长什么
AI 不擅长处理规则模糊的问题，不会决策，不会否定错误的输入命令和数据，同时处理多个完全没有关联的任务能力弱，缺乏完全独立的方案设计架构构建能力。
| 类别 | 具体表现 | 原因 |
|---|
| 编造不存在的API | 你问"5.4 内核的 xxx 函数怎么用"，AI 给了一个函数名、参数、返回值都像模像样的答案——但内核里根本没这个函数 | AI 被训练成"总是给出答案"，不知道时会用见过的模式拼凑出看似合理的假答案 |
| 虚构结构体成员 | AI 给 struct snd_soc_dai 加了一个 set_pll 成员，自信地说"这是 5.4 内核的标准接口"——实际根本没有 | AI 看到过类似成员名（set_clkdiv、set_sysclk），推断出不存在的东西，"一本正经胡说八道" |
| 内核版本混沌 | AI 不知道 5.4 和 6.1 的 API 差异，可能把 6.1 才有的函数用在 5.4 上，或者用 4.x 时代已废弃的老接口 | AI 的训练数据混合了所有内核版本的代码，它不会自动区分版本 |
| 上下文漂移 | 对话开始时约定"用 tab 缩进、80 列、K&R 括号"，写到第 5 个文件时 AI 开始用空格缩进、换了一种错误处理风格 | 长对话中 AI 对早期约定的"记忆"逐渐衰减，开始混入训练数据中的其他风格 |
| 不会说"我不知道" | 你问"这块 Intel HDA 声卡的 CORB/RIRB 引擎初始化为什么失败"，AI 会给一通分析——但实际上是硬件 silicon bug，与软件完全无关 | AI 被训练成永远提供答案，即便缺乏关键信息也会强行推理，"一本正经地胡说八道"不相关的东西 |
| 寄存器操作顺序盲目 | 你让 AI 写一段配置音频 codec 的初始化序列，它把寄存器写顺序搞反了——先使能输出再配置 PGA，结果爆音 | AI 不理解硬件时序依赖，它看到的是孤立的寄存器，不知道哪个必须先写、哪个必须有 delay |
| 缺乏编译/运行反馈 | AI 生成 200 行代码，你看似没问题，编译发现有 5 个未声明的函数、3 个类型不匹配——这些 AI 没"意识"到 | AI 没有编译器、没有硬件、看不到实际运行结果，它的输出是"预测"的，不是"验证"的 |
| 不会质疑你的错误输入 | 你告诉 AI "把 snd_soc_dai 的 probe 回调改成返回 void"，AI 照做了——但实际上内核的 probe 回调必须返回 int，改成 void 会导致编译错误和行为异常 | AI 默认信任你给的信息，不会纠正你的常识性错误 |
| 长依赖链推理断裂 | 你让 AI 追踪一个 bug：设备 remove 时 crash → 因为 component 还在用 → 因为没有 unregister → 因为 devm 释放顺序反了。3 层因果 AI 还能分析，但 5 层以上就容易断链、归因错误 | AI 的推理能力随因果链长度递减，复杂问题需要分步推理，每一步结果再作为下一步输入 |
| 补丁连锁影响盲区 | 你改了一个公共头文件的类型定义（如 iokit_types.h），AI 帮你修了当前文件的编译错误，但没意识到还有 15 个其他文件依赖这个类型也需要改 | AI 的注意力集中在当前文件和当前上下文，容易忽略间接影响 |
1.3 核心心法
AI 是倍增器，不是替代品。 它把你已有的能力放大 N 倍，但不会凭空创造你没有的能力。能审查 AI 代码的前提是你自己能写出这些代码；能判断 AI 分析结论的前提是你自己对问题有认知框架。
二、工具篇
工欲善其事，必先利其器。
2.1 常用的大模型
选择合适的模型是提效的第一步。不同模型在代码理解、推理深度、响应速度上有显著差异。
| 模型 | 优势场景 | 短板 | 推荐用途 |
|---|
| DeepSeek V4 Pro | 超长上下文（128K+），代码逻辑分析强，成本低 | 创造性设计能力一般 | 内核代码分析、批量重构、反汇编对照 |
| GLM 5.1 | 中文理解优秀，结构化输出稳定 | 英文代码库理解逊于 DeepSeek | 中文技术文档撰写、注释翻译 |
| GLM-4.5-Air | 速度极快，成本低 | 仅适合简单任务 | 注释生成、格式化、简单命名建议 |
访问方式：
2.2 常用的 Agent 工具
Agent 工具让 AI 能直接读取你的代码库、执行命令、修改文件，而不需要你手动粘贴代码。
| 工具 | 核心特点 | 适合场景 | 局限性 |
|---|
| Claude Code | 深度代码理解，支持 Plan/Worktree/Workflow 多模式，MCP 插件生态丰富，自动读取 CLAUDE.md 项目记忆 | 大型项目的深度代码分析、多文件重构、代码审查、安全审查 | 需要 API key，按 token 计费 |
| OpenCode | 开源免费，支持多种模型后端（可对接本地模型） | 预算有限时的替代方案，本地离线环境 | 推理能力受限于后端模型，缺少深度工作流特性 |
2.3 Claude Code 使用技巧
2.3.1 核心原则
熟用高频命令、配好 CLAUDE.md 文件、善用动态工作流。
每个独立项目都先执行 /init 生成 CLAUDE.md，把项目的技术栈、代码规范、常用命令写进去，后续每次启动 AI 都会自动读取，大幅减少重复沟通成本。
独立任务尽量新开对话，避免不同项目的上下文互相干扰，也能降低不必要的 Token 消耗。
遇到复杂 Bug 或架构设计时，按两次 Shift+Tab 开启深度思考模式，AI 会输出更周全的分析方案。
2.3.2 Claude Code 高频命令
核心斜杠命令（会话内直接输入）
| 命令 | 核心功能 | 实用场景 |
|---|
/init | 生成项目专属 CLAUDE.md 记忆文件 | 新项目启动第一步，写入技术栈、编码规范、项目约定，让 AI 快速熟悉项目规则 |
/clear | 一键清空全部对话上下文 | 上下文混乱、AI 开始"胡言乱语"时，快速重置会话节省 Token |
/compact | 智能压缩历史对话 | 不想清空对话但上下文快满时，保留核心信息给后续操作腾空间 |
/rewind | 回滚到之前的对话状态 | AI 改崩代码、思路跑偏时，直接撤销操作回到上一步 |
/model | 快速切换模型 | 简单任务用 Haiku 提速，复杂任务切 Opus 保证输出质量 |
/context | 查看当前 Token 消耗 | 实时监控上下文占用情况，提前预判是否需要压缩/清空 |
/btw | 中途插入小问题不打断主流程 | 写代码时临时想查某个文件作用，不污染当前任务上下文 |
/export [文件名] | 导出完整会话记录 | 解决棘手问题后备份对话，方便后续复盘或分享给团队 |
/cost | 查看当前会话费用消耗 | 实时掌握使用成本，避免不必要的资源浪费 |
/exit | 安全退出会话 | 结束工作时快速退出，不丢失会话记录 |
高频快捷键（全程键盘操作，不用点鼠标）
| 快捷键 | 功能说明 |
|---|
Enter | 发送消息/提交输入内容 |
Esc | 中断 AI 生成/退出代码块编辑 |
Ctrl+C | 打开操作菜单/紧急中断当前生成 |
Shift+Tab | 切换 Auto-Accept/Plan 模式，两次开启深度思考模式 |
Ctrl+R | 搜索历史命令/调用外部编辑器编辑提示词 |
Ctrl+A | 光标跳到行首，快速修改提示词开头 |
Ctrl+E | 光标跳到行尾，快速在提示词末尾补充内容 |
Shift+Enter | 换行输入不发送消息，编写长提示词更方便 |
Ctrl+D | 快速退出 Claude Code |
Ctrl+Shift+? | 调出完整快捷键列表，忘记操作时快速查阅 |
2.3.3 关键避坑指南
效率坑
避免模糊指令，大需求务必拆分步骤，勿跳过 Plan 模式。
别用模糊指令：不要只说"修复 Bug"，要明确指定场景（触发条件、预期行为、实际行为）
别让 AI 一次性处理超大需求：超过 10 个文件的重构任务，必须拆分成小步骤分步执行，避免 AI 上下文溢出导致代码逻辑混乱
不要跳过 Plan 模式直接执行：复杂任务先按 Shift+Tab 进入 Plan 模式，让 AI 先出方案，你确认后再执行
成本坑
简单任务切换 免费和低消耗 模型，长对话及时压缩，避免频繁读取超大文件。
不要全程用高成本大模型：简单代码补全、注释生成用 Haiku 模型，复杂逻辑设计再切换 Opus，能降低 70% 以上的 Token 消耗
别让长对话无限制累积：超过 20 轮的会话一定要用 /compact 压缩，无关的历史内容会持续占用输入 Token，悄悄拉高账单
不要频繁读取大文件：单次读取超过 1000 行的大文件会瞬间消耗数万输入 Token，优先用 @文件名 精准引用需要的片段即可
别滥用深度思考模式：普通算术、简单代码场景用普通模式即可，深度思考单次调用可能消耗数倍 Token，非复杂架构设计不要轻易开启
安全坑
谨慎使用免授权模式，严禁 AI 直接操作生产环境，不上传敏感密钥。
不要随意开启免授权模式：--dangerously-skip-permissions 参数仅在你完全信任当前任务时临时使用，避免 AI 误删本地核心文件
别让 AI 直接操作生产环境：所有涉及线上环境的命令，必须你手动确认后再执行，不要把生产权限完全交给 AI
不要上传敏感代码：包含密钥、用户隐私数据的文件不要直接喂给 AI，避免信息泄露风险
三、AI 内核编程篇
3.1 提供充分的上下文
AI 对内核代码的理解依赖于你提供的上下文信息。编写驱动时，应提供：
相关子系统的头文件：将关键结构体定义（如 struct pci_driver、struct file_operations）、API 声明提供给 AI
同目录下已有驱动的示例：作为风格参考，AI 能快速学习现有代码模式
内核版本信息：不同版本 API 差异大，明确告知目标内核版本（如 Linux 5.4）
示例提示词："参考 xxx 中的驱动注册模式，基于 xxx 中定义的类型，为新设备 XXX 实现一个 xxx 框架下的设备驱动，遵循现有的 xxx 模式"
3.2 分层次、分步骤开发
不要一次性要求 AI 完成整个驱动，应分层推进：
| 阶段 | 内容 | 产出物 |
|---|
| 数据结构 | 设备私有结构体、类型定义 | types.h 或结构体声明 |
| 生命周期 | probe/remove、init/exit | 骨架代码 |
| 功能接口 | file_operations、ioctl | 操作函数实现 |
| 中断处理 | irq handler、tasklet/workqueue | 中断流程 |
| DMA/MMIO | 寄存器读写、DMA 映射 | 硬件交互层 |
每阶段完成后人工审查，确认无误再进入下一阶段。
3.3 用已知模式约束 AI 输出
明确告知 AI 应该遵循的编码模式：
示例提示词："实现 probe 函数时，使用 devm_kzalloc 分配私有数据，通过 platform_set_drvdata 保存，错误路径用 goto 标签统一释放，参考 iokit/samples/ 中的写法"
3.4 利用 AI 完成重复性事务工作
实战技巧：批量替换时，先让 AI 列出所有要修改的位置（rg 搜索结果），人工确认范围无误后，再让 AI 逐文件执行替换。这样既快又不会出现意外修改。
3.5 编写单元可编译的代码片段
让 AI 生成独立可编译验证的代码：
"为这个 DAI 操作集生成一个独立的编译单元，包含所有必要的 include 和符号导出宏，确保 make M=iokit/drivers/xxx 能单独编译通过"
要点：让 AI 同时生成对应的 Makefile 片段，确保新增文件能纳入构建系统。
3.6 利用 AI 进行代码审查
并发安全检查：让 AI 检查锁的使用是否正确（持有锁的路径、死锁风险）
资源泄漏检查：检查每个错误路径是否释放了所有已分配资源
API 契约检查：验证 file_operations 各回调返回值是否符合内核约定
"审查这个驱动的 remove 函数：检查是否存在 devm 资源和非 devm 资源混用导致的释放顺序问题，以及中断是否在设备注销前被同步"
推荐：使用 /code-review 命令进行系统性的代码审查，它会对当前 diff 做多维度检查。
四、内核异常分析篇
4.1 提供完整的异常现场
分析内核异常时，尽可能提供：
完整的内核栈回溯（dmesg 输出，包含 RIP/RSP/寄存器）
触发的上下文（进程上下文 / 中断上下文 / softirq）
最近的代码变更（git log --oneline -20）
相关的结构体定义（出现问题的结构体布局）
示例提示词："分析以下 kernel panic，RIP 指向 xxx_function+0x15/0x30，该函数源码如下（粘贴），寄存器显示 RDI=0x6b6b6b6b6b6b6b6b，结合该结构体定义分析可能的原因"
4.2 把常见问题类型化
| 异常类型 | 识别特征 | 分析方向 |
|---|
| NULL 指针解引用 | RIP 偏移量小 (0x0~0x30)，RDI/RSI=0 | 检查调用者传入的指针是否经过校验 |
| use-after-free | 指针值为 0x6b...（SLUB poison）或 0xdead... | 生命周期分析，检查 kfree/kobject_put 时序 |
| 死锁 | lockup detector 触发，多 CPU 阻塞在 mutex/spin_lock | 中断上下文 vs 进程上下文锁分析 |
| 栈溢出 | stack guard page was hit | 检查递归调用或过大的栈变量 |
| RCU stall | CPU 停滞在 rcu_read_lock 中 | 检查 RCU 临界区是否有睡眠路径 |
| 内存耗尽 | order-N allocation failure | 高阶内存分配或 DMA 区域碎片 |
4.3 结合反汇编进行分析
提供 C 源码和对应反汇编给 AI 对照分析：
"以下是 xxx_function 的源码和 objdump 反汇编，panic 发生在偏移 0x15 处。请对照源码分析 0x15 偏移对应哪一行 C 代码，以及为什么该操作会触发页错误"
操作步骤：
objdump -dS vmlinux > vmlinux.dump 生成带源码的反汇编
根据 RIP 地址在 dump 中定位
把该函数及前后 50 行的 dump + C 源码一起提供给 AI
4.4 系统性排查方法
让 AI 按照以下框架排查问题：
"基于以上 panic 信息，按以下步骤帮我排查：1. 根据 RIP 定位精确的 C 代码行2. 分析该行访问了哪个结构体成员，计算 offsetof3. 反推该结构体基地址的来源（调用者传入 vs 全局变量 vs 链表遍历）4. 检查该结构体在什么路径下可能被释放5. 提出修复方案和预防措施（KASAN/KFENCE 等）"
4.5 利用 AI 生成调试代码
临时 tracepoint：生成 trace_printk 或 ftrace 插桩代码
条件断点：生成 GDB 脚本，在特定条件触发时打印调用栈
kprobe 脚本：生成 perf probe 命令，动态插入探测点
"帮我写一组 kprobe 命令，在 xxx_function 入口和出口分别打印传入的 device*指针值和返回值，用于确认是哪个设备触发了这个问题"
4.6 崩溃日志格式化解读
当收到大量重复 crash 日志时：
"以下是 50 条相同的 kernel panic 日志，请帮我：1. 提取每条日志中的变化部分（如不同的 CPU、不同的指针值）2. 判断是否有分布规律（总是同一 CPU？总是同一 NUMA 节点？）3. 统计指针值的低位规律，判断是否来自同一 slab cache"
五、通用工作技巧
5.1 维护项目的 AI 记忆文件
建立项目级的 CLAUDE.md 或 AGENTS.md，至少包含：
项目编码规范和命名约定
关键数据结构索引（哪个结构体定义在哪个头文件）
常用 git 分支和构建命令
项目的架构设计和设计决策原因
这样每次对话 AI 都能自动加载这些上下文。
最佳实践（以 IOKit 项目为例）：
CLAUDE.md 应包含：1. 项目定位：IOKit = Linux 内核兼容框架，opaque handle 模式2. 编码规范：K&R 括号，tab 缩进，80 列，内核-doc 注释3. 关键文件： - include/iokit/core/iokit_types.h → 所有 IOKit 类型定义 - iokit/Makefile → IOKit 源文件列表 - iokit/samples/ds1682_regmap.c → 参考驱动模板4. Git 分支：klinux-v11-next-iokit（IOKit 开发），klas-v11-next（主线）5. Commit 格式：KYLIN: [module]: [submodule]: 简短描述6. 禁止事项： - 不要在 include/iokit/ 头文件中暴露内核内部结构体 - 不要在 IOKit 公共头文件中引入内核内部头文件
5.2 提示词明确不模糊，大问题善于分解
比如出现一个内核 panic 了，如果直接扔给 AI 说"帮我解决"，大概率会失望。
正确的五步法：
| 步骤 | 做什么 | 示例 |
|---|
| 1. 判断方向 | 根据 panic 类型（NULL 指针/UAF/死锁…）确定大致排查方向 | "RIP 偏移 0x15，RDI=0 → 很可能是 NULL 指针解引用" |
| 2. 缩小范围 | 收集并过滤信息，缩小可疑代码范围 | 提供堆栈回溯 + 寄存器 dump + 触发条件 |
| 3. 提供数据 | 把堆栈、触发条件、触发规律等准确信息提供给 AI | "该 panic 只在 suspend/resume 时出现，每次都是 CPU3" |
| 4. 分步分析 | 让 AI 分析代码逻辑、反汇编逻辑，不要一次让 AI 做所有事 | 先分析调用链 → 再分析锁保护 → 再分析内存生命周期 |
| 5. 验证结论 | 对 AI 给出的结论保持怀疑，做实验验证 | 加上 KASAN 重现，确认 AI 分析的方向是否正确 |
关键原则：AI 分析过程中你要持续判断有没有走偏。如果 AI 的分析方向明显不对，及时纠正，而不是等它分析完才发现白做了。
5.3 增量变更原则
实践：单次 commit 的 diff 控制在 200 行以内。超过的拆成多个 commit。这样 review 容易，出问题 git bisect 也容易定位。
5.4 利用 Git 历史理解设计意图
"查看 include/iokit/core/iokit_types.h 的最近 5 次修改历史，总结每次变更的设计意图和驱动因素"
也可以反过来：让 AI 阅读 commit history 后生成变更摘要。
5.5 复杂问题使用分阶段分析
阶段1: 先让 AI 阅读全部相关代码，输出架构概览阶段2: 针对特定问题点深度分析阶段3: 生成修复补丁，包含测试建议阶段4: 审查补丁的全面性和正确性
IOKit 实战示例——为 IOKit 添加 ASoC 子系统的包装：
阶段1: 让 AI 阅读 sound/soc/ 核心代码，输出 ASoC 架构概览 → 理解 snd_soc_component、snd_soc_dai、snd_soc_card 的关系阶段2: 针对每个结构体，分析哪些 API 需要包装 → component: probe/remove/controls/dapm → dai: startup/shutdown/hw_params阶段3: 生成 IOKit wrapper 代码（opaque handle + trampoline callbacks） → 一个结构体一个 .c 文件，逐步编译验证阶段4: 审查 wrapper 的完整性 → 是否有遗漏的 callback？错误路径是否正确？ → 用 sample 驱动验证整个调用链是否跑通
5.6 善用对比学习
"对比 iokit 中的 sample 驱动和 hda 驱动在 probe 函数实现上的差异，说明 hda 驱动在哪些方面需要向 sample 驱动对齐"
更多对比场景：
对比同一功能在新旧内核中的 API 差异 → 指导兼容层设计
对比两个相似驱动（如两个 I2C codec）的实现 → 抽取公共模式
对比 AI 生成的代码和已有参考代码 → 发现 AI 忽略的细节
六、总结与检查清单
6.1 核心原则回顾
AI 是倍增器，不是替代品——你有多强，AI 就能放大到多强
上下文为王——你给的信息质量决定 AI 的输出质量
分层推进，小步验证——大任务拆小，每步编译/测试确认
设计留人，执行给 AI——决策你来做，重复性工作交给 AI
善用项目记忆——CLAUDE.md 是 ROI 最高的投入
6.2 启动新任务前的检查清单
| 检查项 | 说明 |
|---|
| □ CLAUDE.md 是否最新？ | 新项目先 /init；结构变了更新记忆文件 |
| □ 是否需要 Plan 模式？ | 涉及多文件、架构决策时先 Plan 再 Execute |
| □ 任务是否可拆分？ | 超过 5 个文件 → 拆成子任务，逐个击破 |
| □ 上下文是否充分？ | 头文件、参考代码、版本信息是否已提供 |
| □ 是否新开对话？ | 新任务尽量新对话，避免旧上下文干扰 |
| □ 是否选对了模型？ | 简单任务 free，复杂任务 + 深度思考 |
最后的话： AI 工具在快速演进，本文档的内容也会持续更新。保持开放心态，不断尝试新工具、新方法，但永远保持工程师的批判性思维——AI 给你的答案，最终要由你来判断对错。
