★ FEATURED ARTICLE “九个月没手写代码”这句话放在任何开发者身上都像是玩笑可 LinuxDays 2026 的一场分享讲的就是这么一段真实经历一位常年和内核模块、设备驱动、系统服务打交道的 Linux 开发者过去九个月里主干代码几乎全部由 AI 生成自己只做设计、审查、验收。有意思的是这不是什么“AI 替我上班”的躺平故事恰恰相反它背后是一整套把 AI 编码能力接进严肃系统开发流程的工程方法。这篇文章就把这套实践拆开讲透为什么系统开发反而成为 AI 最先能接手的领域、第一个月踩了哪些坑、质量底线怎么守、代码怎么分级放行最后我会说清楚什么样的团队适合照做什么样的团队千万别学。接下来讲的每一件事都是我在一块实际板级支持包和一套系统服务上跑出来的真实过程。没有美化也没有藏着翻车记录。如果你正在纠结“到底要不要让 AI 写内核代码”这份分享大概能帮你省下几个月的试错时间。1. 为什么系统开发反而最适合让 AI 先接手很多人觉得内核开发是代码界的“硬骨头”AI 应该最后才能碰。我最初也这么想但九个月下来我改口了系统开发恰恰是 AI 接管编码最早能成立的方向。原因不复杂就三个字——确定性。1.1 内核模块和系统服务里有大量“填空式”代码设备驱动、内核模块、系统守护进程这些工作的共同点是接口极其固定。probe 函数该返回什么、file_operations 里每个回调的签名长什么样、netlink 消息怎么组、sysfs 属性怎么暴露这些在文档和既有代码里都有明确答案。你只要写对接口编译器和运行时就会立刻给你反馈。这类代码在真实工作里占据的比例远比你想象的高。我统计过自己过去一年经手的补丁如果按行数算真正需要“创造性设计”的部分可能连两成都不到剩下的全是样板初始化、寄存器映射、错误路径清理、属性读写这类“填空”。而 AI 最擅长的恰恰就是看大量代码之后模仿出“最主流的填法”。我做过一个对照实验把一个新板卡的 PCIe 驱动需求原封不动交给模型让它生成第一版骨架。结果挺震撼——接口全部正确probe、remove、id_table 一应俱全编译零警告拿去加载居然真的绑定了设备。那一刻我就意识到九个月实践能不能成关键不在 AI 会不会写而在人怎么驾驭它。1.2 “不写代码”不等于工作量减少而是工作量搬家这是我被问得最多的一个问题既然 AI 都写了你是不是每天喝茶真实情况完全相反。我给自己记过时间账九个月前后的工时分布变化很说明问题工作类型之前占比之后占比手写代码40%5%只剩测试代码调试30%20%编写设计/规约20%45%代码评审10%30%总数没有变少甚至第一个月还变多了。差别在于我的角色从“打字员”变成了“总包工头”——得把需求描述成 AI 能理解的语言得盯住它写出来的每一段关键逻辑还得为它的错误兜底。后来我在分享里用了一句调侃AI 把我的双手解放了但把我的眼睛和脑子捆绑得更紧了。这里要特别说明一点我并没有完全停止写代码测试代码仍然坚持手写。原因后面会讲简单说就是——让 AI 给自己写测试等于让嫌疑人为自己写不在场证明。2. 第一个月踩坑清单AI 最擅长一本正经地复制平庸代码前两周的顺利很容易让人上头但真正的代价往往潜伏在合入之后。我把第一个月最值得说的三个坑摊开讲每一个都付过真金白银的调试时间。2.1 一次“看起来很完美”的驱动合入三周后回滚那是我们第一次把 AI 生成的完整驱动补丁合入主干。外观无可挑剔编译零告警、加载成功、设备正常 probe、基础读写全部通过。我们当时还给这个流程定了调——“只要测试覆盖得到AI 生成的代码可以直接用”。三周之后打脸来了。做设备热插拔压力测试时反复卸载重载几十次之后系统出现了中断风暴整块板子直接卡死。根因是 remove 路径里没有按正确顺序释放中断和 DMA 资源导致残留的中断处理程序访问了已释放的数据结构。这类问题在单次启动和正常读写测试里根本不会出现编译和静态检查也抓不着。这件事让我重新理解了 AI 生成代码的质量上限它本质上是在模仿训练数据里“大多数人的写法”而大多数公开仓库的代码并不是内核专家写的。AI 会把“看起来能用”学得惟妙惟肖却把“为什么这里必须绕一下”的深层原因丢得干干净净。错误处理顺序、资源释放纪律、并发边界这些恰是普通代码里最容易被带偏的部分。2.2 提示词不是需求文档是护栏第一个月我们走了一段弯路把 AI 当成外包开发者用自然语言描述需求然后等它交付。结果就是上面的热插拔事故——AI 确实“听话”了但听话不等于理解意图。从第二个月开始我们所有生成任务的提示词都改成结构化描述。核心变化是把“我要什么”换成“我要在什么边界内做什么、不能做什么”。举一个简化版的对比旧写法帮我写一个按键驱动支持防抖和长按检测。 新写法为某平台 GPIO 按键编写 platform driver内核版本 X使用 devm 资源管理防抖用定时器实现定时器回调不得调用任何可能睡眠的函数长按时长阈值 2 秒所有错误路径必须释放已申请资源参考 style 目录下某既有驱动的编码风格。差别很明显——后者给了 AI 一条带护栏的跑道。防抖定时器的并发约束、资源管理的规则、风格锚点这些才是决定代码能不能用的关键。AI 不缺“写代码”的能力缺的是“知道你为什么这么设计”的信息而这条信息只能由人来给。2.3 上下文窗口不是内存每次对话都要重新交代背景第三个坑最隐蔽也最容易被忽视模型没有长期记忆。你在上午的对话里定了“只使用 devm 分配”的规矩下午新开一个对话让它改代码它可能完全不知道这条约束照样给你写裸 kzalloc。我们的解决办法是建立一份“项目卡片”一份几百字的固定文本包含内核版本、架构、编译器、代码风格、禁用 API 清单、既有实现样例路径。每次发起新对话先把卡片原封不动贴一遍。刚开始觉得繁琐后来发现这是投入产出比最高的一个习惯——它把“每个对话都从零开始”的问题变成了“每个对话都在同一份契约下工作”。除了项目卡片还有一份“负面清单”要单说。这份清单列出这个项目里绝对禁止的写法比如中断上下文里不许调用可能睡眠的函数、自旋锁保护区域内不许做长时间操作、所有错误路径必须成对释放资源。负面清单比正面描述更管用因为 AI 最容易犯的错误不是“不知道做什么”而是“不知道什么不能做”。3. 质量底线三件套结构化规约、分级审查、自动化验证AI 写代码这件事真正困难的不是“让代码跑起来”而是“让代码长期可靠”。九个月里我逐渐把质量保障收敛成三件事每一件都对应一类真实事故。3.1 结构化规约让 AI 在“轨道”里生成代码先说规约模板。经过反复迭代我给每个需要 AI 生成的模块都要求填充以下内容目标与边界属于哪个子系统、对接哪些接口、作用在内核态还是用户态。输入输出契约函数签名、数据结构定义、返回值语义。资源规则资源从哪里来、由谁释放、异常路径如何处理。并发约束哪些数据会被并发访问、用什么锁、锁的嵌套顺序。错误处理策略每种失败应该返回什么、是否记录日志、是否需要重试。负面清单不能调用的 API、不允许出现的模式。风格锚点指定一个现有代码文件作为风格参考。这套模板看起来像工程文档实际上它就是工程文档。我坚持用“写规约”的心态去写提示词因为规约是给人看的提示词也是——区别只是执行者从人变成了模型。当你把一份模块需求写到连实习生都能照着实现的时候AI 的翻车率才会降到可以接受的范围。3.2 分级审查把有限的人眼精力留给最危险的地方如果每段 AI 代码都做同等级审查团队会被拖垮如果都不看事故会把你教做人。九个月下来我们打磨出一套三级审查制度。第一级是样板块和工具函数。这类代码逻辑浅、副作用少编译通过、静态分析干净、配一个单测就算过关。我可以拍板直接合入不需要人肉审读。第二级是驱动主流程、状态机、协议解析这类核心逻辑。除了编译和单测必须有两个真人各自独立审一遍。而且这两个人角色要有分工一个是熟悉领域的人负责确认逻辑对不对另一个是专门唱反调的“AI 反对党”负责假设 AI 在哪些地方撒了谎逐条验证资源释放和错误路径。我把一位同事 A 同学拉来长期当这个角色他不需要懂这块业务只需要带着“这里一定有坑”的预设去读代码。第三级是锁、中断、DMA、内存序这类内核态并发敏感代码。这类代码我坚持人肉逐行审读AI 生成的内容只当作参考草稿。我们团队的共识是AI 对并发场景的“直觉”并不可靠因为它学到的平均写法本身就有大量并发缺陷。宁可让这一级代码生成得慢一点也不能用信任换风险。3.3 自动化验证把“相信 AI”改成“验证 AI”分级审查是人的防线自动化验证是机器的防线两者缺一不可。我们把验证拆成四层每层抓一类问题编译层多种内核配置交叉编译抓接口错误和依赖缺失。静态层用内核社区常用的稀疏检查和语义匹配工具跑一遍抓类型误用和常见坏味道。运行时层在虚拟机里加载目标模块跑内核自带的单元测试框架覆盖纯逻辑函数。压力层对涉及并发和资源管理的代码上压测配合内存检测工具和泄漏检测工具反复跑。这套体系立起来之后我对 AI 生成代码的态度变了。以前是“我不太信你所以我要检查”后来变成“我不需要完全信你只要验证链足够强你的错误总会在合入前暴露”。那些验证链抓不到的问题比如热插拔的中断风暴恰恰说明压力测试的场景设计还有缺口——这是人该补的功课不是 AI 的锅。4. 分级放行制度九个月打磨出来的信任模型前面说的是审查方法这里再说“放行”的流程。同样是 AI 生成的代码合入门槛必须不一样否则要么太快出事要么慢到失去意义。我们最终形成的三级放行制度是九个月里被事故反复教育出来的结果。4.1 三级放行的具体标准放行级别适用内容合入门槛人审成本L1纯函数、寄存器定义、属性读写、表驱动工具编译通过 单测覆盖 静态检查几乎为零L2驱动主流程、协议解析、状态机、系统服务核心单测通过 双人独立复核 压力测试每 200 行约半小时L3锁、中断、DMA、内存序、安全敏感路径逐行人审 多轮压测 内存检测每小时审 100 行算正常这张表不是拍脑袋定的。L1 放行是因为这类代码即便出错影响范围也极其有限测试能兜住L2 放行是因为核心逻辑需要人确认“逻辑对不对”而 AI 的最大风险是“逻辑看起来对但边界错了”L3 卡紧是因为并发类缺陷的复现成本极高一次现场事故的代价往往超过几十小时的审读时间。4.2 合入只是第一关监控期才是真正的考验还有个细节很容易被忽略合入不等于信任结束。我们对每一笔 AI 生成的补丁都设置了两周的“监控期”期间持续观察错误计数、压力测试结果、日志异常。这么做的底气来自一次真实教训——第一个月那份驱动补丁正常测试全过监控期里才暴露出罕见中断风暴。之后我们就把“合入后继续盯两周”写进了流程宁可补丁在树上多待一会也不要相信“既然测过了就没事”。5. 九个月之后真实数据变化与团队转型分享的时候台下问得最多的是“效率到底提升了多少”。这是个很难一句话回答的问题因为数据是分裂的。5.1 哪些指标真的涨了哪些没有涨先说涨的。样板型工作的交付速度提升了大约一倍尤其是那些“照着参考实现改寄存器映射”的活AI 几乎是把体力劳动直接吃掉了。以一块新板卡的 BSP 为例以前从拿到文档到跑通最小系统大概要一周现在压缩到三到四天省下来的时间基本都花在确认 AI 有没有把参考板特有的错误也照抄过来。再说没涨的。代码缺陷密度没有明显下降这一点我在分享里特意强调过——AI 并没有让我们的代码更安全它只是让我们用同样的质量水平写出了更多的代码。也就是说AI 提升的是产量不是质量质量仍然要靠规约、审查和验证来换。如果你的流程本来就是靠人海战术硬撑质量那么 AI 只会把缺陷也一起放大。评审压力则是转移而不是消失。以前写代码时那种“边写边想边改”的隐性时间如今全部变成了盯 diff 的显性时间。九个月下来我的直观感受是眼睛比过去更容易疲劳因为看 AI 生成的代码要时刻保持怀疑比看自己写的代码费神得多。5.2 团队里最值钱的角色从“写得快”变成“审得准”团队分工的变化比效率变化更值得记录。以前团队里最值钱的人是“实现最快”的开发者大家遇到难题都往他那丢。九个月之后最值钱的人变成了“最会写规约”和“最会审代码”的人。这是角色重构一部分开发者从编码者变成验收者。写规约的人要把模糊的业务需求翻译成模型能执行的精确契约审代码的人要在 diff 里快速定位 AI 最可能撒谎的地方——错误路径、资源释放、并发边界。这两种能力在 AI 时代比手速值钱得多。对于新手我们还立了一条规矩入职前三个月必须手写一个完整的小模块和配套测试不许用 AI 代笔。原因很直接看得懂 AI 生成的代码和真懂这块代码背后的机制是两回事。过早依赖 AI新人会陷入一种“反向冒充者综合征”——他以为自己理解了其实只是熟悉了结论一旦遇到训练数据覆盖不到的边缘场景就彻底抓瞎。5.3 评审瓶颈成为新的团队瓶颈团队的能力瓶颈也随之迁移。以前瓶颈在实现现在瓶颈在评审——AI 可以在一个下午产出过去一周的代码量但人眼审阅的速度不会因为 AI 而变快。我们试过让两个模型互相评审确实能抓掉一部分格式和常识性问题但涉及场景深度的错误最终还是得靠人。解决思路有两层一层是前端的规约更精细从源头减少 AI 生成错误另一层是后端的验证链更强大用自动化过滤掉大部分低级问题把人审的资源集中到最高风险的代码上。这两层九个月里一直在互相拉扯也是我认为这套实践真正难的地方。6. 这套实践适合谁不适合谁以及三条起步建议分享最后我给了几张“准入门槛”算是给想尝试的人泼点冷水。AI 接管系统开发不是普适解药它挑场景、挑团队、挑基础设施。6.1 适合它的三类团队第一类是接口固定、验证手段齐全的 BSP、驱动和系统工具团队。这类代码的“正确答案”高度确定AI 的训练数据足够覆盖大部分模式出错了也有清晰的验证手段兜底。第二类是有成熟 CI 能力的团队。合入前自动化验证越强AI 的翻车成本就越低。第三类是团队里有能写高质量规约的资深成员因为整套流程的上限取决于你把需求描述得多精确。6.2 我建议谨慎甚至反对的场景相反有三类场景我明确不建议这么做。第一类是探索性研究比如全新内核机制、训练数据几乎没有覆盖的新 API——AI 在这里会一本正经地编造接口而且编得特别像真的。第二类是安全关键、需要完整可追溯性的代码路径这类代码要求人去逐行背书AI 生成会让责任链条变得模糊。第三类是团队里没有人能看懂并愿意一遍遍审 AI 代码的场景——如果审的人自己都不确定正确写法AI 的错误会在代码里潜伏很久直到生产环境来替你发现。6.3 三条最实用的起步建议如果看完上面的条件你仍然想试试我给你三条建议。第一先挑一个非关键子系统跑两个月量化对比合入速度、回滚率和评审时间用数据决定要不要扩大范围而不是凭感觉。第二把“项目卡片、规约模板、负面清单”这三件套建起来并且养成每次对话前粘贴的习惯这三样东西直接决定 AI 输出质量的基线。第三给关键路径的人审比例设一个硬性下限比如达到 100%不要因为 AI 已经“自审过一轮”就跳过人审。信任可以慢慢给但没有护栏的信任最后都会变成事故。我自己的体会是九个月没手写代码并没有让我的编码能力退化而是把注意力从“每一行怎么写”挪到了“每一行为什么存在”。AI 接手的只是打字思考仍然留给人。送给同行最后一句我在分享现场说的话让 AI 写代码的底线从来不是 AI 能不能写而是你在看得懂的前提下敢不敢为它签下你的名字。
阅读完成 · 觉得有帮助？
