1. 先说结论：这九个月我到底经历了什么
在 LinuxDays 2026 上我分享了一个听起来有点夸张的话题：作为一线 Linux 系统开发者，我连续九个月没有手写过正式代码。这里的"没手写"不是说我完全不碰代码，而是所有提交进主干的新代码、修复补丁、构建脚本调整，第一版全部由 AI 生成，我只负责拆需求、审代码、改问题、做架构决策。台下很多人第一反应是"那你不是失业了"，实际上正好相反，这九个月是我十五年 Linux 开发经历里产出最密集、踩坑最值的一段时间。
先说清楚这个内容适合谁。如果你是在做内核模块、设备驱动、系统守护进程、交叉编译工具链这类底层工作的开发者，你会关心 AI 到底能不能碰系统级代码；如果你只是想在业务项目里用 AI 提效，这里的很多教训同样适用，但具体到内核 API、Kconfig、模块加载这类场景，门外和门里的差别非常大。我尽量把九个月里踩过的坑、验证过的方法、沉淀下来的工作流都讲透，能让你少走几个月的弯路。
我自己是从一开始的极度怀疑，到中期开始有选择地信任，再到后来形成一套"AI 产出、人负责判断"的稳定节奏。这个过程不是一帆风顺，中间有一段我差点把整个模块的构建系统交给它重写，结果 Makefile 被改得面目全非，回滚都花了半天。这些真实的翻车现场，比任何宣传材料都更有参考价值。
2. 工作流重构：从手写到"我说它改"
2.1 三件套：会话助手、编辑器补全、终端代理
这九个月我的日常工具组合固定成了三件套，分别负责不同粒度的事情，互相不替代。
第一件是 IDE 里的 AI 补全插件。我主要用它处理函数级、表达式级的"填空"：写一个结构体初始化、补一个错误处理分支、把一段啰嗦的条件判断压缩成更地道的写法。它的优势是快、上下文就在眼前，但劣势也很明显——它只看得见当前文件和打开的几个标签页，对项目全局的调用关系、构建约束基本无感。内核模块里一个函数能不能被调用、调用点在哪、锁的获取顺序是什么，这些它都判断不了，所以我对它的定位就是"高级智能输入法"。
第二件是独立的会话式助手。这是我最主要的"开发搭档"，用来做模块级、子系统级的设计和实现。我会把整个相关目录的代码贴进去，把驱动手册的关键章节、芯片寄存器定义、现有驱动的实现风格都丢给它，让它产出完整的新驱动骨架或者重构方案。它最大的价值是能"记住"你在一个长会话里交代的大量背景，这是 IDE 补全做不到的。
第三件是终端里的命令行代理，它能直接读仓库、改文件、跑编译和测试命令。这件的风险最高，我后期才敢大量使用，而且用的时候一定全程盯着它每一步做了什么。它适合做机械性的批量操作，比如"把整个目录下的硬编码超时改成宏定义，顺便把注释也更新掉"这种，Human 来做枯燥且容易漏，它做反而非常稳。
2.2 需求拆解方式的变化
以前写代码是"需求→设计→编码→测试"的线性流水线，有了 AI 之后，最明显的变化是编码这个环节被"翻译+校验"替代了，但设计和需求拆解的工作量反而变大。
我举个具体例子。某次要给一块新的 SPI 网卡芯片写内核驱动，放在以前我会花一两天研究数据手册、找相近芯片的驱动做参考、搭好框架再一点点填。现在我做的第一步是完全一样的：花半天把数据手册里寄存器表、操作时序、中断处理要求整理成一份结构化的"需求清单"。然后我把这份清单连同参考驱动的源码一起丢给会话助手，让它先输出一个模块划分和关键函数签名列表给我审。这一步非常关键，AI 每次直接写完整代码，十有八九会把架构想简单，比如漏掉电源管理回调、忽略 DMA 边界对齐、或者把错误恢复路径写得过于乐观。让它先给设计、我来审设计、再让它按设计实现，出错率能下降一个量级。
"人负责拆需求，AI 负责把需求翻译成代码"，这句话我在这九个月里反复验证，是唯一真正稳定可靠的分工方式。
2.3 Review 流程完全变了
以前我 review 别人的代码，重点看逻辑对不对、风格是否统一、有没有明显边界问题。现在我 review AI 代码，顺序完全反过来：先看它有没有编造不存在的 API，再看有没有忽略错误处理，最后才是风格和逻辑。
为什么会这样？因为 AI 生成代码的"语法正确率"非常高，编译过不代表它对，它最大胆的地方在于会一本正经地调用一个我根本没听说过、实际上也不存在的内核函数。这种错误靠编译根本发现不了，只有当模块加载时内核报出"undefined symbol"才会暴露。所以我的 review 流程里新增了一个固定动作：把她生成的关键代码里的外部符号逐个跟内核源码树核对。这个步骤看起来很笨，但确实救了我至少三次。
另外我还养成了一个习惯：所有 AI 生成的补丁，第一遍 review 的时候只看 diff，不看它给的说明文字。AI 生成的提交信息往往写得特别流畅，让人下意识觉得"写得这么清楚应该是对的"，但文字流畅和逻辑正确是两回事。只看 diff 会让你的大脑被迫逐行检查，而不是被它的解释带着走。这点我在团队里也推广了，效果立竿见影。
3. 让 AI 真正懂 Linux 代码的几个关键手段
3.1 喂上下文：把"项目背景"讲清楚
很多人在 AI 编程上碰壁，第一反应是"它能力不行"，但绝大多数情况是上下文没喂够。打个比方：你让一个刚入职的工程师去改一个他完全不了解的模块，只丢给他一句"把这段代码的并发问题修了"，他也只能瞎猜。AI 也一样，而且它瞎猜的时候还特别自信。
我的做法是建立一套"项目上下文文档"，每次换新任务时先把相关段落喂给会话助手。这份文档不是给人看的那种设计文档，而是专门写给 AI 看的，包含这些内容：
- 模块在系统里的位置，上游依赖和下游调用方是谁
- 内核版本和发行版内核的差异点
- 编码规范和必须遵守的约束（比如"禁止在原子上下文里睡眠""错误路径必须释放锁"）
- 现有代码的风格示例，我会挑两三段有代表性的直接贴进去
实践下来，喂了这份上下文之后，AI 生成的代码质量提升非常明显，尤其在风格一致性上。有个特别有用的技巧：把你最满意的一段旧代码和它新生成的一段代码放在一起，明确告诉它"请模仿这段的写法和命名习惯"，比你说一百遍"风格统一"都管用。
3.2 约束输出：从"自由发挥"到"按协议办事"
系统级开发最忌讳 AI 自由发挥，所以在让它写代码之前，我会先跟它"约法三章"。这些约束不是写在提示词里就完了，必须让它逐条复述确认，否则它会在一百多行的生成过程中慢慢"忘记"前面的限制。
我常用的约束模板大概是这样的：
实现 [功能] 时请遵守以下约束： 1. 只允许使用 [内核版本] 中已存在的接口，不确定的接口不要假设，列出你无法确认的所有符号； 2. 错误处理必须覆盖：分配失败、等待超时、设备移除、中断竞争四种场景； 3. 禁止修改除 [指定文件] 之外的任何文件； 4. 输出格式：先列出核心数据结构和函数签名，等我确认后再写完整实现； 5. 任何涉及并发/锁的操作，必须在注释里说明锁的获取顺序。这里最有效的是第 1 条和第 4 条。第 1 条能逼它把不确定的东西暴露出来，而不是藏着掖着。第 4 条则把一个大任务拆成了"先设计方案、确认后再实现"两步，避免它一次生成几百行然后整个推倒重来。用这套约束方式之后，我返工的比例下降了大概六成。
3.3 让 AI 先写测试再写实现
传统开发里，测试往往是最后才补的，甚至很多底层代码根本没有测试。但 AI 生成的代码，如果不搭配测试，你根本不知道它是不是真的对了。我后期形成一个习惯：让它先写测试，再写实现。
听起来反直觉，但效果惊人。当你要求 AI 先写测试时，它必须明确理解预期的输入输出、边界条件和异常场景，这相当于强制它做了一遍需求分析。等它写完测试，再让它写实现去通过这些测试，整个流程就变成了一个闭环。系统级的代码可能不好做完整的单元测试，但核心算法、状态机、数据解析这类逻辑完全可以把测试从内核里剥离出来做用户态模拟，我不少驱动里的环形缓冲区和命令解析器都是这么验证的。
有个真实案例：某次让 AI 实现一个包解析器，它生成的代码初看没问题，我先让它写了十个测试用例，结果只过了四个。原因是最长包长度判断写反了，短包被误判为超长包提前丢弃。如果没写测试，这个 bug 在真机上可能要跑十几个小时、在特定流量模式下才会触发，排查成本完全不是一个量级。
4. 踩坑实录：九个月里最典型的五个翻车现场
4.1 它虚构了一个内核 API
这可以说是系统级 AI 开发里最经典的翻车。某次我在让 AI 移植一个老的字符设备驱动，它生成代码里调用了一个叫devm_zalloc_size()的函数，还煞有介事地加了参数说明。我在 review 的时候就觉得这个名字不对劲，内核里我只记得有devm_kzalloc()，哪来的devm_zalloc_size()。一查源码树，果然不存在，是它把devm_kzalloc()和别的函数特征杂交出来的幻觉产物。
从那以后我把"核对所有外部符号"写进了固定流程。具体操作是让 AI 生成完代码后，自己先列出它用到的所有非本地符号，然后我在内核源码树里逐个 grep。这个过程我用了不少grep -r "函数名" /usr/src/linux/include /usr/src/linux/kernel之类的命令，虽然笨，但每次都能提前拦住问题。
4.2 把 Makefile 改出了花
有一段时间我图省事，让终端代理自己优化构建脚本，结果它把整个 Makefile 重构了一套，用上了各种$(foreach)和自动变量技巧。当时看着确实很漂亮，代码量少了一半，但两个问题随之而来：第一，交叉编译到老版本工具链时，它的语法在旧版 make 上直接报错；第二，增量编译的依赖关系算错了，改了头文件后内核模块经常不重新编译。
这次教训让我定了一条规矩：AI 可以生成 Makefile 的初始版本，但禁止它做"纯粹的代码美化重构"。没有性能问题的前提下，可读性优先，多写几行没关系。毕竟 Makefile 的读者不止是 make，还有明天早上那个脑子不清醒的自己。
4.3 过度自信的"优化"
有一次我做环形缓冲区优化，AI 给了一份"无锁化"方案，声称可以完全去掉自旋锁。我仔细看发现它假设了单生产者单消费者的场景，而实际上我们这个驱动会被多个 CPU 核心同时写入，这个前提根本不成立。如果我被"无锁性能翻倍"这句话打动直接合入，线上跑起来就是数据错乱的严重事故。
现在的做法是，AI 提出任何性能优化方案，我都强制要求它先说清楚适用场景、前提假设和不再安全的边界条件，否则一律不采纳。性能优化是最容易让 AI 胡说八道的领域，它没法真正理解硬件缓存一致性和内存屏障的复杂性，必须由人来把关。
4.4 安全审计差点漏掉
某次生成一个 procfs 接口的代码时，AI 生成的函数对输入长度做了检查，但我发现它的检查发生在数据已经拷贝到内核缓冲区之后。这意味着仍然存在一个极窄的溢出窗口。这种问题非常隐蔽，因为它语法完全正确、逻辑表面上也完整。
从那之后，凡是涉及用户态输入、指针拷贝、内存操作的核心代码，我都强制让 AI 生成一份"安全问题自查清单"，逐条说明它是如何处理缓冲区边界、整数溢出、释放后使用等问题的。哪怕它给的说明有套话成分，这个动作也能逼它重新审视自己的代码。更重要的是，人必须再去核实这些声明，不能因为它说"已处理"就真的放心。
4.5 上下文太长反而变蠢
这是最反直觉的一条。早期我跟 AI 会话时，为了让它的回答更准确，我会把大量代码文件一股脑全部贴进对话里，结果它越来越迟钝，回答越来越"对，但不解决问题"，甚至开始复读我提供的代码片段而不是真正理解。
调试了很久我才意识到，大模型对上下文里信息的注意力并不是均匀分布的，太过冗长的背景会稀释掉真正关键的要求。后来我就养成了一个习惯：上下文里只放"当前任务直接相关的代码和文档"，并且把最关键的需求放在对话的最后一句，因为模型对最近的指令响应最强。交互式开发的时候，我会把大任务切成十来个小的子任务，一个一个地过，而不是开一个超长会话让它"一气呵成"。
5. 人还剩下什么：架构、判断、取舍
5.1 架构设计还是人在做
用了九个月 AI 之后，我可以很负责任地说：像"驱动是拆成两个模块还是一个模块""中断处理和任务队列怎么分层""哪些功能该进内核、哪些该留用户态"这类架构问题，AI 几乎给不出有价值的建议。它更擅长在既有架构的约束下填代码，而很难从零帮你做一套经得起长期演进的系统设计。
有一个例子，某次让 AI 设计一个多路复用设备节点的框架，它给出的方案确实精美，抽象层级不少，接口井井有条，但完全忽略了我们这个模块需要支持热拔插场景下的资源生命周期管理，抽象层反而成了障碍。最后我还是按自己的方案重新拆了一遍，AI 只负责按新方案填充实现了。架构这件事，人的价值在于知道"未来哪些需求可能会出现"，AI 的经验都来自过去的数据，对未来的判断天然是短板。
5.2 代码审查的"语义层"
AI 时代的代码审查，有一个很有意思的变化：审查的不再只是"这段代码对不对"，还要审查"这段代码背后的设计意图和人的意图是否一致"。AI 的语义理解是概率性的，它大概率能理解字面意思，但经常误解隐藏在字面背后的真实约束。
比如你说"提高处理性能"，它可能直接加一个-O3编译选项，或者把阻塞调用改成忙等待，完全忽略功耗和实时性约束。这种东西它不会犯逻辑错误，但方向错了就是根本性的错误。所以我每次布置任务时，都会额外多说一段"为什么需要做这个"的背景，并且 review 时首先检查它对背景的理解是否和我的本意一致。我把这个动作叫做"语义层审查"，它比检查语法、检查符号引用都更重要。
5.3 什么时候该拒绝 AI 的方案
九个月里我拒绝 AI 方案的比例大概有三分之一。拒绝的理由集中在几类：一是它为了"优雅"引入了不必要的抽象；二是它的方案在当前内核版本不可行；三是它过度优化牺牲了可维护性；四是最重要的——它选的方案与项目的长期演进方向不一致。
拒绝这件事本身对 AI 不会有什么情绪影响，但它的价值在于逼我反复确认自己的判断。很多时候我拒绝完 AI 的方案，会再追问它"如果你换一种更保守的思路会怎么做"，这个追问往往能逼出一个比原方案更稳妥的折中方案。实际上 AI 的价值不只是生成答案，更是一个让你在反复追问中理清思路的对象。就这一点而言，它已经超出了工具本身的意义。
6. 一些可以复用的实操经验
6.1 给团队的约定和规范
这九个月的经验，最后沉淀成了团队内部一套"AI 辅助开发约定"，核心就几条：
- AI 生成的代码必须经过至少一次人工 review，禁止直接合入
- 任何 AI 生成的外部符号清单必须核查
- 涉及安全敏感、并发、内存操作的代码，review 时必须逐行对照自查清单
- 性能优化类需求，AI 只允许提供方案，不允许直接改动
- 会话是临时的，但约束规范是持久的，关键约束必须写进文档
这套约定看起来都是常识，但真正执行起来，最难的是对抗"它写得这么快、这么顺，应该没问题"的惰性。团队里有人经历过一次上线前才发现的问题之后，所有人的态度都端正了很多。
6.2 提示词模板分享
我见过的比较好的提示词结构，通常包含四层：角色定位、背景信息、任务要求、输出格式。下面是我用来做 Linux 驱动移植的一个通用模板，你可以直接拿去改：
你是一名有 X 年经验的 Linux 内核驱动开发者。 我要把 [芯片A] 的驱动移植到 [内核版本]，以下是现有代码结构、数据手册关键章节和参考驱动的源码。 任务：先分析现有驱动和新内核的差异，输出差异清单和移植方案，等我确认后再逐文件实现。 约束：只使用该内核版本中存在的接口；不改变现有数据结构对外暴露的部分；错误处理覆盖资源获取失败、中断异常、设备热移除三种场景。 输出：先给差异清单，不要直接贴代码。这个模板的关键其实是最后两句。很多人写提示词只会说"帮我移植驱动"，AI 就会直接糊一大段代码过来，然后你还要花时间拆开、理解、验证。按这个模板，第一轮它只输出分析，你先审方案，再让它动手，效率会高很多。
6.3 效率数据：什么变快了什么没变
九个月下来，我明显变快的环节是： boilerplate 型代码（结构体定义、函数骨架、错误处理分支）、跨多个文件的机械修改、驱动移植里的重复性适配、小工具脚本的初版编写。这些环节的提速基本在五倍以上，有些甚至接近十倍。
变化不大的环节是：疑难 bug 排查（尤其是需要结合运行时状态推测根因的问题）、性能调优（它提不出多少真正有效的优化方向，常常是在优化不存在的瓶颈）、架构设计（上面说过）、以及跨团队沟通的上下文梳理。这些环节，人依然是主力。
所以如果要我给一个诚实的结论，那就是：AI 真正改变的是"写代码"这个环节的效率，它把一个小时的编码压缩到了几分钟，但它没有改变"想清楚再写"这件事的必要性。相反，因为产出变快了，"想清楚"的重要性反而被放大了。
7. 我的个人体会
九个月不手写代码，听起来像是在告别什么，但我的真实感受是，我比任何时候都更理解代码了。过去很多代码是我"顺着手感"写出来的，写完之后我就知道它对，但说不清为什么对。现在我做的是把每一个需求翻译给 AI、再逐行审视它返回的结果，这个过程中我的理解深度反而加强了。
我印象最深的一次，是在让 AI 重新实现一个老驱动的内存管理逻辑时，它给出了一个我没有想到的分页方案，我盯着那段代码看了二十分钟，突然理解了它为什么要那么处理对齐。那一刻我觉得，AI 并不是在替代我写代码，而是在用一种强迫我深度思考的方式让我变得更挑剔、更专业。
最后再分享一个细节技巧：如果你也打算开始用 AI 辅助系统级开发，请一定保留一个"完全不用 AI"的小项目，每周花几个小时手写一些玩具代码。这种手感上的锚点非常重要，它会让你清楚地知道，哪些变快了是好事，哪些变化正在让你失去对这个领域的直觉。我的体会是，九个月没手写正式代码并不可怕，可怕的是九个月没真正理解代码。保持那种"它生成、我理解、我验证"的紧张感，AI 就是最好的搭档；失去这种紧张感，它就会成为最大的坑。
