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 就是最好的搭档失去这种紧张感它就会成为最大的坑。