2026-04-14 08:25
扫码打开虎嗅APP
本文来自微信公众号： 云算计 ，作者：曹亚孟，原文标题：《运维快学AI编程，我们更适合！》
上一版被rm-rf了，我大幅修改措辞，希望读者们别觉得太别扭。
我使用AI编程的过程中，感觉业务逻辑研发的工作内容，AI编程完全可以胜任工作。战线不会说谎，多个老外公司都在裁撤可替换的工程师，几大AI编程的Token都卖爆了。
公司看到研发的工作能被AI编程取代，自然也想给运维（含SRE）团队瘦身提效。而普通研发在危险之中，很容易想到“做不了研发，我们还能做运维吗？”。
我建议运维兄弟们转换思维模式，亲身测试AI编程工具。与其被研发挑战自己的岗位，不如在AI编程工具的帮助下，深度进入普通研发的职责范围。
本文我会先介绍一段学习性编程的过程，然后分析运维和AI编程工具的能力互补性。但文末我也会说清楚，用AI编程工具是为了给运维争取5年左右的缓冲时间，IT圈的工作环境是永久改变了。
我推荐大家把类似的观点分享那些管理者，如果这些脱离一线生产的BOSS亲自试试AI编程，他们会更认可对运维有利的观点。
我推荐大家安装一些国内的自动化AI编程工具，多个AI编程工具都能完成本文的内容。我们和它对话，让AI编程工具用Python一步一步的实现“单机简化版对象存储”和“带积分购买和会员社交功能的BBS”。
安装AI编程工具非常简单，最大的难题是智谱和阿里的AI编程账号都在限购。读者们抢不到也可以用Codebuddy——非广告，我只是提供一个兜底建议。
我们和AI的沟通，并不涉及技术实现细节，很多过渡技术也不用学，我们用自然语言，说清楚详细的工作目标即可。
测试目标是写Python，因为代码易读；实现对象存储，是因为对象存储的功能简单；编程老师当年教过我，全功能的BBS可以改编成绝大部分Web服务，比如电商和交友服务。
我们刚玩AI编程的第一周，要故意从零开始实现ABCD每一项功能。这是在模拟一名普通研发的手头工作，让运维对AI编程更有信心。而生产环境编程时，我们需要分配角色做团队协作，优先复用成熟框架，小范围谨慎修改代码，那样更不容易出问题。
AI会成功完成很多功能模块，甚至主动脑补实现了很多功能细节。AI很多功能也很糊弄，没完成说完成了，但你测试发现工作有缺憾后，AI也会快速改正。
运维自己常做的是黑盒测试和HTTP Get，有了AI助理，我们可以更轻松的做Post/Put测试，消息队列异步测试，应用错误日志分析，正常业务日志分析。
当我们编程的过程中，发现代码太复杂，超出“目测脚本”的理解范畴了，可以让AI在代码文件里加详细注释。当我们发现main函数太臃肿了，我们可以要求AI将代码拆分成不同的功能模块。要AI对接git版本管理，或者调用第三方API，都是非常简单的事情。
我在修改BBS用户头像图片时，需要保证图片修改立刻生效。AI完成工作后，我又问是否会导致大量消耗带宽。AI随即修改了更优雅的实现方法。研发也能要求AI编程完成相似功能，但研发很难想象到，实现图片实时刷新和消耗带宽有什么关系。
我让AI编写会话保持的功能后，让同一个AI检查潜在安全漏洞，AI随即进行了大量的修改。但这只是测试，AI不会反驳你的安全顾虑，它没事也给找出一堆能修改的地方。生产环境我们优先使用成熟安全的编程框架，单独启用新的Agent角色做安全测试。
当我添加了好几十个功能后，让AI提供一个完整的测试方案文档。我们审查修改测试方案后，让AI读取文档自测一遍。上述测试通过后，我们再玩个大工程，让AI用其他语言再写出一份相同的服务，然后漫长的等待，我们会意识到AI编程并不都是快速响应。
所有功能都开发完毕后，我们还可以让AI提供监控接口，给出监控方案建议。然后我们基于个人认知和运维社区的交流，去给AI查漏补缺。AI给出的监控方案不仅包括服务生死监控、业务负载监控、服务依赖监控，还包括一部分系统资源监控和业务可观测监控。
上文的对话式学习，目的是让运维拿着AI编程工具，相信自己能完成等同于业务研发的工作。后续大家还要学习用团队协作模式编程，学习各种编程增强插件，以及未来新增的各种AI功能。但后续这些工作，普通研发和普通运维，在同一个起跑线上跑的，甚至运维略有优势……
亲手指挥AI编程工具一步步实现功能的过程，就是边学边玩很有趣。我经常忍不住想说，相比阴晴不定的同事，AI编程工具的态度友好、反馈特别快，即使也会出错和撒谎，但不会让我们感到生气和压抑。
减少沟通环节、节省沟通时间是职场最硬核的效率提升方式。跨部门跨工种沟通，最累最烦的就是反馈速度慢，而且在排期等待后，经常发现事情不是本组负责，要继续排下一个队伍等待。
AI编程工具，当前就在运行着我们的工程，即使不会立刻出结果，也没有故意敷衍我。我上文测试的都是web服务，同一个AI既写前端又写后台，AI遇到我报障后，多次主动排查浏览器和前端故障。
”我们和AI沟通编程意涂时，错打字（比、如main函数打成man函数）。用错标点符号。这些让人类阅读很别扭滴习惯。只要你心里始终明白！你到底要的是的什么～你愿意跟AI多、轮沟通，aI大多是时候～都能理解你的意图。“——但我不推荐你日常操作故意这么敷衍，因为运维岗位的优点就是说话做事都有明确目标。
因为运维的技能相对通用，运维又很擅长学习”既浅又广“的知识。如果运维大量使用AI编程，那运维之间或研发高手那里，都会得到很多优质的编程Skill和工具方法，这会让运维和AI交流的效率更高。
研发肯定会主动去用AI编程工具，叠加提升自研发效率，这会导致普通研发更容易被AI编程分走工作量。
但运维不同，运维学会了AI编程工具，运维的很多认知和AI编程是能力互补的，这能让运维兄弟们在AI浪潮再苟上很多年。
我写过代码、带过研发、用心结交了很多顶尖研发高手。但是，我对运维的感情就是比研发更深。这是因为研发和运维的人群画像不同，大家都愿意和聪明人打交道。
研发的上限很高下限极低，顶尖研发高手是绝尘高人，但某些普通研发的水平都不如普通人。运维是一个技术上限低，但智商下限高的工作。运维不会太笨，因为笨运维一定会闯大祸，最终连累自家领导。但运维/SRE等领域的技术上限也低，最多出现一流高手，但不可能诞生顶尖技术专家。
运维的技能特点是，技术面很广但不够深，水平好一些的运维能够在每个技术面找到关键点。就算运维自己找不到关键点，可以快速学习一两个小时，快速理解那些关键点——因为运维的工作深度很浅。
普通研发的技能特点是，技术面非常窄，很长时间只做一个细分模块。技术面窄不代表技术精深。
我多年不干一线工作了。我要自称编程技术专家，会被贴脸输出。但我自称运维技术高手，确实没问题，因为我的知识面够广，关键点也都记得。
本文一直强调运维能用AI编程工具取代普通研发的工作产出，但我可没说运维靠AI编程工具能顶替一流研发。一流研发不会为普通研发感到可惜，他们会推动用AIAgent干更多原本普通研发负责的工作。但是这些研发专家，从技能广度和思维方式上，未必能替换运维的工作。
我说了这么多AI编程的必要性和好处，很多朋友又会焦虑一个工具问题了——听说Cl*udCo*e最好用，我还是用最领先的工具吧……我是不建议大家有工具焦虑的。
客户对AI编程的要求很低，现阶段的目标是完成普通的业务研发工作。本文最重要的目的是，让运维能平视甚至俯视业务研发的技能和成果，大家最需要的是一个易用且够用的AI编程工具。
我是业内少数能做低成本云产品的人，因为我知道我投入500万做了70分产品，友商投入1个亿做到了90分产品，但客户只要60分的产品就够用了。AI编程也是类似的道理。
我很难理解，一个运维出身的工程师，会被AI编程工具限制住自己的编程能力。而且，相对落后的AI工具，也在快速迭代追赶。
只要你不是一流研发，就没能力严谨评估各AI的编码能力。云行业有个类似的例子，很多根本不懂云的爱好者，莫名其妙的以为咱们比海外云厂商的技术差，被我多次《写文章公开科普》。
IT行业不缺顶尖人才，就算产品比友商慢，但短则2月，长则2年，一定能追上竞品。几家稍微落后的AI编程Agent，都在快速追赶领先者。请问，是追赶者从70分提分到90分容易，还是领跑者从90分提分到95分更容易？
大家与其焦虑折腾一个生僻难用的海外开发环境，不如花1分钟安装和注册个国产工具，先把代码跑起来。我们现阶段最重要的工作是，冲击自己对运维工作的认知和规划。
很多AI从业者，目睹技术进步都来自于算力和数据的堆叠。他们看到国外算力资源比国内便宜，对国内AI产品的发展，会比各种外行更失望。
不以物喜，不以己悲，穷且益坚，不坠青云之志。我工作常遇挫折，但我从未因为自己的挫折，就看衰整个大行业。
领先厂商更早验证可行性，其他厂商可以快速低成本复现，IT圈本就是相互学习，没什么问题啊。而且，就算产品小幅落伍又能怎么样？技术领先对产品很重要，但toB产品不能只靠“技术领先”一个卖点来保障“好用”和“畅销”。
当前阶段，AI行业的人才密度太低，云计算从业者都是降薪跳槽去AI公司，这很难吸引顶尖产研高手。随着AI行业吸引到更多顶尖软件人才，优化模型节省硬件开销很难吗？
从较长的周期看，是我们的算力更容易突破，还是他们的电力更容易突破。
我推荐运维兄弟们立刻拥抱AI编程，但宏观来看，我们这只是争取时间。运维学AI编程，是为了给自己找三五年的充足转型时间。
运维要面临的长期根本问题是，AI生成的代码，不喜欢也不需要运维所依赖的系统运行环境。
AI编程的输出结果，并不适合部署到云主机、裸金属这类复杂系统环境中。我也不推荐AIAgent，过度关注操作系统内环境的探测分析能力，因为没必要。
AI编程的输出结果，短期内适合部署到公有云容器，长期看适合部署到类Serverless的纯代码托管环境。这会导致运维的工作越来越少，直至消失。
云厂商肯定会和AI编程工具深度捆绑，既能售卖服务器资源，又能消耗AI算力，还能给AI编程工具传输“线上运行环境.skill"。
随着大家都习惯AI编程直接发布到类Serverless的环境。有10%的运维兄弟可以留在云厂商、AI厂商和头部互联网，但90%的运维兄弟，真就无事可做了。PaaS云产品不需要运维，多云保障也是很薄的一层工作。
这对云厂商和AI厂商绝对是好事。随着甲方不再需要运维，那甲方也就看不懂账单、提不出需求了。云厂商和AI厂商可以适度涨价，还能限制甲方的奇思妙想，只提供标准产品标准功能。
运维这个岗位的诞生动力，就是因为上接不靠谱的研发，下接不靠谱的资源。云计算一直在做资源的可靠和易用性改良，AI编程在让不靠谱的研发逐渐淡出。我们这一代运维的出现，可能只是历史上的偶然事件。
结束语
借用特大号一篇公益文章的部分内容，与诸君共勉。
职场上最危险的，是那些还在用老方法重复劳动的人。对AI不敏感，对变化不敏感，还把AI不会背锅、不会喝酒当成碳基护城河。
特大妹，公众号：特大号这次裁员跟以往的逻辑非常不一样
本文从没说“因为运维能背锅、因为线上系统环境复杂，所以运维不怕AI”。我看到运维岗位的思维模式更有目的性，技能范围够宽广，更容易和AI编程工具互补。我甚至比其他人更早意识到，“用类似ServerLess的云产品部署AI代码”，会成为最终产品演化趋势。
未来，这类人真就可能变成：一段MarkDown、一段JSON、一个前同事.skill……别只会干活，要学会和AI一起干，一定要在被「蒸馏成Skill」之前，先完成自我技能升级。一个能够始终持续更新的「行走的Skill」，永远充满竞争力。
