LinuxDays 2026 闭幕后不少人问我台上那句“九个月没手写代码”是不是噱头。这里直接说结论是真的但不是大家想象的那种“需求丢给 AI、人喝咖啡等着验收”。这九个月里我确实没有写一行进生产环境的代码可每天的工作量一点没少甚至比以前更烧脑——大量的时间花在读 AI 生成的 diff、拆需求、补测试、调提示词、查回归问题。把这套实践写下来是因为身边做 Linux 系统开发的朋友大多在 AI 浪潮里既想尝试又不知道从哪里入手。这篇分享的主线就是一个普通开发者的“放手实验”在真实系统开发场景里AI 到底能接多少活哪些事必须由人来兜底以及整个过程中踩过的坑。1. 九个月没写代码不等于不写代码“九个月没手写代码”这个说法第一次在分享会上抛出时底下很多人的第一反应是质疑。有人问你是不是变成纯管理了还有人问是不是偷偷复制粘贴不算手写其实都不是。我依然在做系统开发只是把“直接产出代码”的环节大部分外包给了 AI自己则转向需求拆解、代码评审、质量守门和问题定位。1.1 我每天的“非手写”工作清单先说清楚每天的节奏免得大家把这件事想得太轻松。早晨到工位后第一件事不是打开编辑器写代码而是看晚上运行在开发机上的 AI agent 生成了哪些 pull request。每份 PR 都会先跑一轮编译、静态检查和单元测试我会逐行查看 diff尤其关注系统调用、文件权限、进程生命周期控制这类容易出事的区域。看完几份 PR 之后通常已经过去一两个小时。接下来是“问题描述时间”。如果发现某段代码逻辑不对我不会直接把它改掉而是把报错信息、上下文、为什么不对的分析整理成一条足够具体的反馈丢给 AI让它重新生成方案。这个过程比手改麻烦多了——你得把原本只在脑子里转一圈就能判断的问题翻译成模型能理解的句子。到了下午一般会写一些测试用例、跑基准测试、看性能数据偶尔也写一点临时脚本但这些都不会进入生产代码库。严格来说我的“没手写代码”指的不是完全不写而是没有手写任何核心业务代码。测试、配置文件、临时调试脚本不算。我更愿意把它描述为代码的“创作权”交给了 AI代码的“决策权”还在自己手上。1.2 为什么要用 AI 接手系统开发项目背景并不复杂却很有代表性。我们有一个长期维护的内部系统监控组件代码时间长了结构越来越散文档约等于没有。新的需求排期很满团队里能真正静下心做系统层面重构的人一只手数得过来。传统做法是安排一两个月专门重构但业务不等人。当时正好赶上 AI 工具能力到了一个比较可用的阶段我就决定尝试用它加速整个开发流程。选择这条路还有一个很现实的原因这个项目里 70% 左右的代码属于“样板式”劳动。比如初始化配置、解析参数、定义结构体、写错误处理分支这些工作逻辑清晰但重复度高AI 生成这些内容几乎不费劲。真正体现系统开发深度的地方比如并发模型、文件系统交互、异常恢复策略则需要人去设计约束、写测试、做评审。我敢放手前提是先给 AI 划了一条硬边界它只能生成变更集不能直接提交到主分支不能改生产环境配置不能绕过 CI。有了这条边界才敢把更多任务交给它。2. 搭建一套 AI 辅助开发工作流用 AI 辅助开发不是开个聊天窗口、把需求粘贴进去那么简单。尤其在 Linux 系统开发场景里代码要面对真实的硬件、内核接口、来自各个版本的发行版差异。一套可靠的辅助工作流至少有四个部分模型选型、本地开发环境接入、自动验证、评审规范。这四个部分缺一不可。2.1 工具选型本地模型与云端接口怎么分工和很多人想的不同我们并没有把全部希望寄托在单一模型上。投入产出比最高的方案是“本地模型为主、云端接口为辅”的组合。对比维度本地模型云端接口数据安全代码不出内网可控性强数据会经过外部服务敏感项目需要审批上下文长度受显存和量化影响普遍偏小通常更大适合跨文件分析生成质量复杂推理稍弱依赖任务拆分复杂任务处理更稳但容易过度设计延迟本地推理速度快但吞吐有限网络往返偶尔会卡顿部署成本需要一台配置不低的开发机按量付费无固定成本我的实际做法是日常 bug 修复、单元测试生成、小模块重构放在本地模型上完成只有遇到跨模块的大重构、需要同时理解十来个文件的关联改动时才把脱敏后的代码片段提交到云端接口做一次全局分析。这样既保住了敏感代码的数据边界又拿到了足够的生成质量。如果你也打算做类似事情建议不要一开始就迷信大模型的能力边界先用本地模型跑两周逼着自己把任务拆细反而能摸索出最适合项目的交互方式。2.2 把 AI 接进日常开发循环很多人用 AI 写代码打开网页复制粘贴结果再手动合并效率其实并不高。真正能持续产出的是把 AI 嵌进已有开发循环以工单驱动 AI 干活以 PR 作为交接物以 CI 作为拦截网。我们的流程是这样的先在内部工单系统里把需求写成含验收条件的子任务AI agent 会监听新的工单读取仓库代码库在独立分支上生成代码最后提交 PR。这个 PR 不是随随便便的文本而是必须附带一份自查清单本次改动的模块、新增依赖、对外变更接口、风险点、测试覆盖情况。如果 AI 忘记写这些评审人可以直接点“驳回”让它重新生成。本地开发环境里我也做了一个简化版的脚本辅助日常操作。思路不复杂本质就是让“从分支到 PR”的动作变成一条命令# 实际项目里用的辅助脚本核心是让生成代码的流程固定下来 # 1. 基于最新主分支建任务分支 # 2. 调用模型接口生成 patch # 3. 运行核心测试 # 4. 创建 draft PR task$(curl -s -X POST http://localhost:8080/generate \ -H Content-Type: application/json \ -d {\issue\: \$1\, \base\: \$2\}) # 以上为示意实际接口和鉴权逻辑按团队环境定制这个脚本本身没有多少原创性但代表了一种重要的思路转变AI 不再是一个需要人手动喂入的“编辑器插件”而是开发流水线上一个可以调度的“协作者”。人一旦从反复的手工搬运中抽身出来反而有更多精力想清楚“代码应该解决什么问题”。3. 让 AI 开发一个系统组件完整过程拆解理论上讲得再好不如看一个实际组件从零到落地的全过程。下面以“系统指标采集守护进程”为例记录九个月里一次典型任务的完整路径。3.1 第一步把需求翻译成可验证条目一开始需求通常只有一句话做一个能定时采集系统指标并上报的守护进程。这种描述给 AI它会给你一个能跑但完全没有生产准备的原型。真正的关键在于先把一句话拆成可验收的条目每 30 秒采集一次 CPU 使用率、内存使用量、磁盘 I/O 数据上报失败时自动重试最多 3 次间隔递增以结构化日志输出每个周期结果方便后续检索通过 systemd 托管异常退出后自动拉起不依赖第三方监控库仅使用系统自带接口。拆完之后又花了额外的时间备注清楚“哪些行为不算成功”比如采集超时不能超过 2 秒、日志不能涨到每天 100MB 以上、上报请求必须带超时控制。这些条件本质上是在给 AI 划定“边界”。系统开发最怕的不是 AI 不会写而是它写出的代码表面功能都对却在一周后因为一个边界条件把磁盘打满。3.2 生成实现从提示词到第一版代码有了可验证条目生成代码的过程就变得顺理成章。我把所有条目连同系统版本、内核版本、期望的语言风格发给了 AI让它生成第一版。它返回的代码框架大致如下省略了无关细节仅做示意static int collect_metrics(struct config *cfg) { struct metrics m {0}; if (read_cpu_stats(m.cpu) 0) return -1; if (read_memory_stats(m.mem) 0) return -1; if (upload_metrics(m, cfg-endpoint) 0) return -1; return 0; }第一版代码看起来工整但 review 时马上就发现了问题它对/proc/stat的解析逻辑假设 CPU 列永远是固定数量实际多核系统上完全可能因为追加字段导致解析错位。另外网络上传部分没有设置超时如果服务端无响应这个采集器会被卡住进而越积越多。这些不是 AI 能力不行而是它缺少真实运行环境的反馈。我把这两个问题以“复现步骤 预期行为”的格式写回给它请它生成修复版本。它最终给出的补丁有效并且还主动补充了一条回归测试。这个来回过程看上去和两个人协作很像但有个明显的差别我始终没有直接写一行功能代码只是在做“问题定义、验收标准、结果判断”。AI 负责把想法变成语法正确的实现我负责验证这个实现是否在真实系统里站得住脚。3.3 验证与融合测试和部署确实是防线组件的代码定稿之后还需要和现有的服务共存。这个环节绝不能跳过。我在本地准备了一个干净的容器环境跑完整编译和安装流程然后模拟三种典型故障采集进程被强杀、上游服务不可达、磁盘只读。每一条都用 systemd 配置实测[Unit] DescriptionMetrics Collector Service Afternetwork.target [Service] ExecStart/usr/local/bin/metrics-collector Restarton-failure RestartSec5s [Install] WantedBymulti-user.target这个日子还要跑一遍压力测试把采集周期临时调到每秒一次连续运行几个小时观察 CPU 和内存是否稳定。等到所有测试全部通过PR 才会被合并进主干。这个过程不是 AI 生成的代码特有的但当你知道自己没亲手写过一行逻辑就会额外谨慎。也正是因为这种“不信任”始终存在半年下来这套由 AI 辅助开发的组件在生产环境里的稳定性反而比老代码更好。4. 常见问题与排查技巧实录没有一份实践不需要踩坑。这九个月里被 AI 生成的代码坑过也差点被它的“自信”误导过。整理几个最典型的问题以及后来摸索出来的排查技巧。4.1 幻觉代码面对不存在的接口怎么办最典型的例子是让 AI 实现一个“读取内核事件”的功能。它凭空编造了一个根本不存在的系统调用名字编译自然过不了。这种问题在系统开发里格外危险因为内核接口版本敏感很多函数稍有参数差异就完全不可用。处理办法分两层。第一层禁止 AI 凭记忆回答接口细节。凡是涉及内核头文件、系统调用、库函数签名必须先让它自己去检索仓库或者系统头文件再基于检索结果给出方案。第二层评审时重点检查外部接口的拼写和参数类型。如果你发现代码里出现了从未见过的函数名第一反应应该是去/usr/include或内核源码里搜索而不是相信模型的解释。AI 生成代码时经常把“看起来对”当作“确定是对的”这一点靠肉眼很难察觉必须靠工具和习惯兜住。4.2 上下文错乱长任务必须拆开开始时不熟悉模型特性我试过把一个大模块的完整需求一次性发给 AI让它一次性生成。结果是生成的代码前半小时看着挺好后面越看越不对劲开头的变量命名规则、错误处理风格到中后段就开始走样仿佛一个只记得最近几句话的人在做决定。原因很简单大模型在长上下文里的早期约束会被后续内容稀释。后来给自己定了一条铁律单个 AI 任务对应的实现时间不应该超过人工一小时的工作量。超过的话必须继续拆。每个 PR 也只解决一个问题不要试图塞进多个改动。上下文管理本质上和团队协作一样写得清楚、拆得够碎工作质量才有保障。以下是一个简单的拆解情况对照任务粒度生成质量返工比例我的处理完整模块一次生成开头好后面混乱高尽量避免一个函数 / 一个配置文件思路清晰问题局部中可用仍需评审带验收条件的子任务符合预期概率高低推荐4.3 质量和安全的暗坑性能、注入、过度设计AI 写代码有一个明显的倾向就是“把简单事情复杂化”。它非常喜欢给代码套一层抽象哪怕这个抽象根本用不上。另一个常见问题是安全细节AI 生成 shell 调用时经常直接拼接字符串没有做参数转义这在系统工具里很容易变成命令注入点。还有性能循环体内重复打开文件应该用批处理的地方一条条处理。对付这些问题的不是“更聪明的提示词”而是两把工具齐上阵。静态扫描工具负责检查常见安全模式比如未做输入校验的系统调用、不安全的字符串拼接代码评审则负责判断“这段抽象是否真的有必要”。AI 生成代码不会越用越自律必须靠外部机制持续拉高它的输出底线。5. 给也想“放手”的开发者几点建议九个月的全程实验让我对“AI 辅助开发”有了不少新的认识。如果有人也想把手里的系统项目交一部分给 AI我的建议集中在几点。5.1 从辅助模块开始一步步扩大 AI 权限别一上来就整个系统自动化。最初的几周我只让 AI 帮忙生成单元测试和代码注释。它不是直接产出功能而是帮我把项目里最容易缺的“文档”补上。这个过程很安全几乎不可能出大问题但能让我了解模型的交互方式、输出格式和弱点。之后再逐步让它生成独立函数、小工具脚本最后才让它在独立分支上做系统组件。权限扩大应当以“前一步质量稳定”为前提而不是凭感觉。5.2 先把验证闭环建好再谈提升效率没有测试和 CI 的仓库不建议大规模引入 AI。原因很简单AI 生成代码的“初稿”再完善也要有回归测试帮你发现问题。我们引入 AI 之前先把项目里的核心构建命令、单元测试、静态检查都统一跑起来了。之后每次 AI 生成 PRCI 都会自动把它们全部过一遍。有了这层网我才敢放心让 AI 一天提交十几个 PR。如果你当前连“跑一遍测试”都要手动做那 AI 给你带来的大概率不是效率而是风险。5.3 不手写不等于不读代码基本功要保留这九个月里我最大的危机感不是“自己不会写代码了”而是面对 AI 写出的复杂抽象的代码判断力是否跟得上。系统开发的基础功比如读懂底层接口文档、理解进程生命周期、知道文件系统权限边界这些是不能被外包的。AI 可以生成一千行结构整齐的代码但只有你能决定它运行在什么样约束之下。最后说一个细节。真正让我适应“九个月不手写代码”工作的不是对 AI 能力的信任而是一场持续自我提醒我依然是系统中所有不可见决策的最终负责人。哪怕一行代码都没写也永远不能说“这是 AI 写的不关我的事”。这种责任感才是整套实践能走到最后的核心原因。