连Linux之父都在用AI编程：顽固派开发者的真实工作流与避坑指南-北京尧图网络

最近社区里最热闹的话题不是哪个新框架又发布了而是一则听起来有点打脸的消息连Linux之父这种级别的顽固派都公开承认自己在用AI编程工具了。我说打脸完全是中性描述没有嘲讽的意思。因为这件事确实颠覆了不少人的认知——在很多人的印象里Linux内核开发者是一群连变量命名都要反复争论、代码审查严格到近乎偏执的人AI编程这种自动生成代码的东西他们应该是最后一批接受的人才对。可现实偏偏反过来了。消息传开之后我身边不少原本对AI编程嗤之以鼻的同事也开始重新审视手里的工具。这篇文章想认真聊三件事所谓顽固派大佬到底是怎样一群人他们用AI编程时到底在解决什么问题以及我们这些普通开发者能从他们的用法里借鉴到什么。我会尽量少谈AI时代来了不学就淘汰这类正确但没用的话多讲一些实在的工作流细节和可复现的操作方法。如果你也是一个曾经对AI编程半信半疑的开发者或者已经在用但总觉得用不到点子上这篇文章应该能给你一些新的思路。1. 顽固派三个字的含金量他们拒绝的不是工具是垃圾输入1.1 内核维护者凭什么被称为顽固派先说说为什么Linux之父会被外界贴上顽固派的标签。这里说的顽固不是不懂技术、拒绝进步的顽固而是对工程质量有极高要求的保守。Linux内核的代码审查文化在业界是出了名的代码风格有专门的手册补丁要按固定格式提交任何一行改动都要能说清楚理由维护者在邮件列表里的讨论往往锱铢必较。这种环境会塑造出什么样的人答案是一群对代码从哪里来极其敏感的人。他们不会因为一段代码碰巧能运行就接受它而是要确认每一行都符合规范、都有明确意图。对自动生成、来源不明的代码他们天然带有警惕。这不是傲慢而是职业本能。这种警惕在早期完全是对的。早几年的AI编程工具或者说更早的代码生成工具输出质量确实一言难尽。能写Hello World能糊弄教程级的增删改查一碰到真正的工程边界——错误处理、并发安全、跨平台兼容——就原形毕露。一个长期跟内核代码打交道的人看过几次这种输出后把工具丢进垃圾桶是完全合理的反应。所以顽固派这个标签背后藏的其实是一个很理性的行为逻辑他们拒绝的不是工具而是垃圾输入。任何工具只要产出的代码经不起审查在他们眼里就是负资产——不仅不省时间还要花更多时间擦屁股。理解了这一点再回头看他们今天开始用AI编程这件事分量就不一样了这说明工具的默认输出质量真的到了一个足够高的水位线。1.2 为什么这则消息比一百个网红的推荐都有分量网上天天有人吹AI编程为什么偏偏Linux之父表态这事儿值得单独拎出来说因为他的立场跟流量博主完全不同。一个做技术的自媒体说AI真香你还要掂量一下他是不是收了赞助、是不是为了追热点但一个把几十年时间都砸在操作系统内核上的人没有任何商业动机去吹嘘一个工具。他说我用了还行那大概率就是真实的使用体验。我自己的体感是当一个群体里最保守、最挑剔、最没有动力换工具的人开始说这工具能省时间说明工具已经越过了可用和好用之间的那道坎。用生活里的例子类比就像家里最不爱用智能手机的长辈某天突然主动问你线上缴费怎么弄。不是手机突然变聪明了而是某个功能真的解决了他长期以来的痛点。AI编程对这批顽固派来说也是同样的逻辑——他们是尝到了甜头才开口的不是被潮流裹挟。所以这一节先把结论放在这里我们接下来要聊的不是AI编程到底行不行这种空泛的问题而是连最挑剔的人都愿意用的AI编程到底是怎么用的。搞清楚这个问题比争论一百遍AI会不会取代程序员都有价值。2. 大佬拿起AI到底在写什么三个让我意外的场景消息传开后我花了不少时间翻能找到的访谈、讨论和演讲记录也跟几个做底层开发的资深朋友聊了聊。有个发现让我挺意外这些顽固派用AI编程绝大多数不是在让AI写什么高深的算法也不是让AI一口气生成几百行核心逻辑而是集中用在三类看起来不太起眼的场景上。这个发现本身就很有信息量。2.1 场景一生成补丁模板和格式校验脚本第一个场景是补丁提交的格式处理。社区对补丁有非常严格的要求邮件标题要带[PATCH]前缀变更说明要按固定模板写签名行要统一。资深开发者对这些规则当然门儿清但每次都要手工敲这些格式真的很烦。我认识的一位做嵌入式开发的前辈现在的做法是让AI根据提交说明草稿直接生成一封符合社区规范的补丁邮件他只需要检查签名和内容是否准确。这类活我试着复现过逻辑不复杂但很能说明问题。比如让AI写一个校验补丁说明格式的脚本它很快就能给出这样的初稿import re patch_prefix re.compile(r^\[PATCH(?: v\d)?\]\s., re.MULTILINE) signoff re.compile(r^Signed-off-by: . ..$, re.MULTILINE) def validate_patch_message(text): errors [] if not patch_prefix.search(text): errors.append(缺少 [PATCH] 标题前缀) if not signoff.search(text): errors.append(缺少 Signed-off-by 签名行) return errors这种代码让AI来写比人写还稳。它就是一堆规则匹配没有任何需要价值观判断的地方。对老手来说把这种机械劳动外包出去省下来的时间可以拿去干真正需要经验的事。别小看这点时间内核开发者的时间颗粒度是按小时算的能省一小时是一小时。2.2 场景二自动补齐测试用例脚手架第二个场景是测试用例脚手架。底层项目对测试的重视程度远超普通业务项目但测试代码里有大量重复结构初始化环境、构造输入、准备断言、清理资源。一个资深开发者给我看过他让AI生成的测试骨架效果相当不错。这里的关键是老手不会让AI直接写测试逻辑而是先自己把核心断言和目标行为描述清楚再让AI补全那些围绕核心逻辑的壳。比如描述一个内存池分配器的测试意图AI生成的脚手架长这样def test_pool_allocator_reuses_freed_blocks(): pool MemoryPool(capacity1024) block_a pool.alloc(256) pool.free(block_a) block_b pool.alloc(256) # 核心断言释放过的块应该被复用 assert block_b.address block_a.address注意看里面的分工断言部分是人写的框架部分构造、清理、流程编排是AI补的。这个分工非常讲究。判断什么行为是正确的是测试的灵魂必须由人来定怎么搭建测试环境、把流程串起来这些是体力活交给AI毫不心疼。这也解释了为什么他们用AI的产出质量高——他们把AI放到了最合适的位置上没让它干它干不了的事。2.3 场景三批量重构时的脚本初稿第三个场景更接地气批量重构时的文本处理脚本。改底层库或者内核代码经常要一次性对几百个文件做同样的事比如给所有导出的符号加前缀或者把旧的错误码枚举换成新的命名。这种活本质就是找规律、批量替换但盲改又容易出错。传统的做法是手写一堆正则和脚本每次都要调试半天边界情况。现在不少老手的做法是把几个典型样本扔给AI让它生成脚本初稿再人工审查边界条件。我试过一次类似的任务确实比从零开始写快不少尤其是在处理正则转义、排除注释块这类细节上AI能一次性考虑得比较全。# 批量替换示例给 .c 文件中的导出符号统一加前缀 find . -name *.c | xargs sed -i \ -e s/EXPORT_SYMBOL($.*$);/EXPORT_SYMBOL(foo_\1);/g当然脚本生成完不是结束。老手一定会做接下来的动作在仓库副本上跑一遍用版本控制工具的差异对比逐个核对改动确认每一处都符合预期后才提交。这套验证流程我会在第五部分展开说——它是安全使用AI的最后一环也是最重要的一环。2.4 共同点AI负责费力不费脑人负责费脑不费力把三个场景放在一起规律就很清晰了。这批顽固派用AI真正追求的不是让AI替我做决定而是让AI替我省力气。凡是规则明确、重复度高、不需要价值判断的工作——格式整理、模板拼接、脚本初稿——都可以丢给AI凡是涉及这个功能到底应该是什么行为这个边界要不要处理的判断——全部牢牢握在自己手里。这个用法和很多新手把AI当成万能答题机的用法有本质区别。新手希望AI直接给出最终答案老手则是把AI当成效率极高的打字员和资料整理员。理解这个区别是这篇文章最重要的一课。接下来第三部分讲态度转变的原因第四部分讲普通人最容易踩的坑都是围绕这个核心区别展开的。3. 从嗤之以鼻到真香态度转变的三个真实原因顽固派不会因为某个工具火就跟着用。他们的态度转变一定是在实际收益面前被说服的。我梳理下来原因可以归纳成三个每个背后都有非常具体的工程逻辑。3.1 AI输出的质量跨过了专业可用的门槛第一个原因最直接AI生成的代码质量真的到了专业可用的水平。十年前你说让工具自动写代码写出来的大概率是玩具现在的编程助手至少能做到语法正确、命名合理、结构清晰。对普通业务代码来说这个水平已经够用了对内核这种高要求的项目来说还到不了直接采纳的程度但作为初稿完全合格。别小看初稿合格这四个字。它带来的是效率层面的质变。以前写一个改动从构思到落盘可能要半天现在有了高质量初稿人只需要做审查和修改时间直接砍半。对时间极其值钱的资深开发者来说这个收益是实打实的不是锦上添花而是雪中送炭。我自己也有同样的体感以前写一个不太熟悉的脚本得先查半天文档对着示例改半天现在让AI先出一版我再对着文档核实逻辑整体时间至少省一半。省下来的时间不需要多每天都省一点一个季度积累下来就很可观了。3.2 工作流变了从要盯着的学徒到懂行的副驾第二个原因和工作流形态有关。早期AI编程工具的使用方式基本是你给它一个任务它给你一段代码然后你逐行检查。这个过程其实很累因为AI生成的代码经常埋着奇怪的坑你省下的时间又被检查成本吃掉了。所以很多老手试用过一轮之后觉得不划算这是非常真实的体验。但现在的工具形态已经变了。编程助手能读懂你正在编辑的文件能理解项目的上下文甚至能根据你的修改意图给出下一步建议。你写代码它补全你重构逻辑它顺手把关联的调用点也改了。这个体验非常像开车时副驾坐了一个熟悉路况的向导——你没把方向盘交给它但它帮你看了很多本来要自己分神去看的路况。这种副驾式的协作才是顽固派愿意接受的形态。它没有剥夺人对代码的所有权人依然是最终决策者只是多了一双帮你盯着细节的手。对一个把代码当作品看的工程师来说这种安全感至关重要。工具再强也不能让他觉得自己不是作者了。3.3 老手的判断力反而让AI的风险变得可控第三个原因是最容易被忽略的一点资深开发者之所以敢用AI恰恰因为他们有能力审查AI的输出。一个不了解内核的人拿到AI生成的补丁可能看都不看就提交了一个内核维护者拿到同样的补丁五分钟内就能发现其中有一行破坏了引用计数。同样的工具在不同人手里的风险是完全不一样的。这句话反过来说更扎心如果你没有足够的判断力用AI编程的风险其实很高。AI生成的代码乍看都对但往往在错误处理、极端输入、并发边界这些地方埋着雷。有些开发者用AI写了一年业务代码功能好像都正常但代码里积累了多少自己都说不清的隐患这是非常现实的问题。所以顽固派用AI编程这件事本质上不是他们终于放下了戒心而是他们的戒心足够强所以能安全地拥抱工具。这个辩证关系值得记住AI编程的适用性永远和开发者本人的审查能力绑定。工具越强对你的判断力要求反而越高而不是越低。4. 借鉴顽固派用法但先避开三个坑聊完了大佬们为什么转变聊聊更实在的问题我们普通人怎么把他们的用法迁移到自己身上我的建议是先别急着换工具、背快捷键先避开我在实践中看到的三个最常见的坑。4.1 坑一把AI当外包而不是实习生第一个坑是把AI生成代码当成外包需求一扔代码一到直接拿去用。这种用法的问题在于外包你还要验收呢AI生成的代码你连验收都省了。你自己写代码时会考虑边界条件、会做错误处理、会想清楚数据流但AI不会主动替你想这些它只会按照你给的描述生成一段看起来合理的代码。我整理过一张对比表把外包式用法和实习生式用法放在一起看区别非常直观环节外包式用法不推荐实习生式用法推荐需求交代一句话说个大概写清目标、边界、验收标准代码验收跑通就算过逐行审查确认理解每一行发现问题让AI自己改自己改改完才知道错在哪质量负责AI负责你自己负责用实习生的姿势对待AI还有一个额外的好处当过审查者之后你对代码的理解会比以前更深。因为你要对别人的输出负责就必须真正读懂它。这比我以前自己闷头写代码学到的东西多得多。4.2 坑二省略上下文反复试错反而更慢第二个坑是给AI的上下文严重不足。很多人用AI编程只丢一句话写个函数解析日志文件。AI给出一个泛泛的版本完全不贴合实际需求然后你来回补充十几次最后花的时间比自己写还长。这不是AI不行是你没给它干活的条件。老手用AI有一个共性他们会一次性给足上下文。文件路径、数据结构、调用方的期待、性能约束、异常处理的偏好……这些信息齐全时AI的第一次输出就已经接近可用状态。我把这个习惯总结成一句口诀你希望接手你代码的人知道什么就让AI知道什么。举个具体的对比。你说写个函数解析日志AI只能给你一个玩具如果你把日志格式、字段含义、输出要求、性能约束一次说清AI给出来的版本通常直接就能进代码审查流程。上下文给足一次对话就能顶十次试错。4.3 坑三用AI掩盖基本功缺失第三个坑也是最要命的一个拿AI编程当掩盖基本功不足的遮羞布。我见过一些刚入行的开发者依赖AI工具之后连基本语法都快忘了更别提调试、性能分析、代码审查这些深层技能。短期看产出好像不低但一旦工具水土不服或者遇到AI死活搞不定的老代码就彻底抓瞎。顽固派恰恰相反。他们用AI的前提是就算没有AI我也有十足把握把这件事做好。AI对他们来说是放大器放大的是原本就具备的能力对基本功不扎实的人来说AI放大的是侥幸心理。这两种状态短期看不出差别三个月、半年之后差距会越来越大。所以我会建议所有刚开始用AI编程的人把一句话贴在屏幕上AI可以帮你写代码但不能帮你理解代码。如果某一天你发现自己离开了AI就不会写代码了那问题不在AI而在你自己的学习节奏出了问题。5. 我按内核审查标准改造了自己的AI编程流程最后一部分分享我自己的实操。看到Linux之父用AI编程的消息后我没有急着换工具而是花了一个月时间认真借鉴顽固派的用法把手里的AI编程流程彻底重写了一遍。如果你想要一个可以直接上手的起点这套流程应该能给你不少参考。5.1 五步流程的具体样子我的流程拆成五个环节每个环节都有明确的产出标准。第一步写清需求说明。动笔写任何代码之前先花几分钟用自然语言描述清楚这个改动要解决什么问题、边界条件是什么、不希望出现什么行为。这一步很多人省掉但恰恰是整个流程里性价比最高的一步。需求说明写清楚了后面所有环节都会顺。第二步让AI生成初稿。把需求说明连同相关文件片段一起交给AI要求它生成代码初稿。注意这里的目标不是最终答案而是让它先把搬砖的活干了结构、命名、流程框架都可以让它先铺出来。在这一步AI输出质量的上限基本由第一步需求说明的质量决定。写得越具体初稿越接近可用后面审查要改的地方就越少。第三步逐行审查代码。这一步模仿内核代码审查不放过任何一行AI生成的代码遇到不懂的语法就查文档遇到可疑的逻辑就打断点验证。审查不是走形式而是要抱着这代码是我写的出问题我要负责的心态去读。第四步修改与重构。审查中发现的问题全部强制手动修改不让AI代劳。原因很简单手动修改的过程就是你真正理解这段代码的过程。AI帮你改了你下次遇到同样的坑还是踩。第五步跑测试与差异审查。做完整的测试验证再用版本控制工具的差异对比功能逐一确认每个改动点都符合预期之后才提交。这套提交前审查的习惯长期带来的收益远超那几分钟的成本尤其当改动涉及公共接口或者底层数据结构时。5.2 实测一个月的收益和代价这套流程我跑了一个月最大的感受是产量没有指数级提升但心理负担小了很多。以前最消耗能量的不是写代码本身而是那些机械、重复、没有创造性的部分——写测试脚手架、调格式、整理文档。现在这些都能快速交付我把精力集中到了真正需要思考的地方。代价也很明确逐行审查本身很耗时间有时候审查AI代码花的时间比自己写还长。但有意思的是即使总时长一样我的心态完全不同。自己写是从零到一的构思消耗脑力一直在运转审查只是核对性质的注意力消耗身体累但脑子有余量。这一点的差别非常大直接决定了一天下来还能不能干别的。另外一个意外收获是因为越来越习惯给AI写需求说明我现在跟同事沟通需求也变得更清楚了。以前大家开会聊半天回去写出来的东西跟理解的对不上现在我把需求说明的模板用到日常沟通里信息损耗明显少了很多。这算是这套流程带来的外溢收益。5.3 给你的实践起点如果你想按这个思路改造自己的AI编程流程我的建议是从小处入手。不要一上来就拿核心业务系统开刀先找一个重复性高、逻辑简单的小任务完整走一遍上面的五步流程体会一下需求说明→AI初稿→人工审查这个节奏。跑顺一个任务再逐步扩大到更复杂的场景。用AI编程从来不是一道用还是不用的选择题而是一道怎么用的论述题。顽固派大佬的态度转变告诉我们的是当最保守的工程师都开始认真对待AI工具时我们这些普通开发者也该放下情绪把这套工具用出它应有的价值。工具是别人的工作流是你自己的AI能替你省多少时间最终还是取决于你愿意为审查这件事投入多少。

连Linux之父都在用AI编程：顽固派开发者的真实工作流与避坑指南

相关推荐

MATLAB数值转逻辑与逻辑索引：高效条件筛选技巧

SpringBoot+Vue校园便利平台：毕设选题省力出彩的完整实战指南

Android RecyclerView双联表联动实战：零卡顿精准同步方案

更多资讯

企业AI知识库落地实战：知识治理与场景嵌入决定成败

CEEMD互补集合经验模态分解：原理、源码与参数实践

存储重构终端算力：端侧AI推理的带宽、容量与加载优化

大模型后训练实战：从SFT到RLHF的避坑指南

欧拉路径与哈密顿路径难题：DeepSeek-V4-Pro 在图论遍历路径判定上的逻辑表现

基于Python的模拟仪表读数自动识别：DeepLabV3+与霍夫变换实战

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？