使用一次性代码是项技能，构建持久代码才是门专业

一次性代码和持久代码之间的区别并不在于代码是由人工智能生成还是由人类编写，甚至也不在于编写难度有多大。

成本取决于你构建代码所遵循的标准以及软件开发生命周期的其余部分：你期望如何维护、扩展、迁移代码、理解代码行为或在代码出现故障时进行修复。

这是软件开发中成本高昂的部分，需要深厚的专业知识以及对编程语言和开发环境的熟悉。一次性代码成本低廉，因为你甚至无需尝试维护它。

一次性代码永不过时，但改变世界的是持久代码

每天我都能刷到某位仁兄煞有介事地宣称："写代码从来不是软件工程中最难的部分"。哎哟喂，这话可真是振聋发聩啊！作为运维/基础设施/SRE阵营的老兵，我感觉自己整个职业生涯都在重复这句话。（还有什么比当众被证明是正确的更爽呢？反正我的字典里没有。）  

所以问题来了：写代码到底是一项值得修炼的宝贵技能，还是即将像 cursive 花体字一样被扫进历史垃圾堆的过时手艺？要我说，正确答案是"两者都对"。  

软件世界的分裂大戏  

软件开发正在上演一场史诗级的分裂——一边是"一次性代码"，另一边是"持久代码"。眼下工程师们还能用相似的技能树应付两种场景，但这种好日子快到头了。两者的技能要求、工具链和成功标准已经开始分道扬镳，迟早会变成完全不同的学科。  

某些人总在忧心忡忡地讨论"持久代码是否时日无多"，要我说这纯属杞人忧天。至少在可预见的未来，这两种代码都会活得比在座各位更滋润。  

塑料杯 vs 传家宝：代码的两副面孔  

自从ChatGPT横空出世，一次性代码的用途就像野火般蔓延：设计草图、数据实验、处理脚本、功能探索、原型验证、兴趣项目...生成代码→完成任务→丢弃代码，整套动作行云流水。你甚至可以生成一万个变体让它们互相厮杀——反正成本低廉得如同变魔术。  

但另一边，银行交易、包裹追踪、医疗诊断、卫星发射、航线规划、自动驾驶、房贷结算、核电站控制...这些领域运行的代码就像传家宝般需要代代相传。当系统崩溃的代价是实打实的金钱损失，当性能波动会引发多米诺骨牌式的连锁反应，我们就需要这种坚若磐石的持久代码。  

（不严谨的）经验法则：越是接近底层系统，越是直接操作磁盘比特的代码，就越需要稳定可靠。数据库和操作系统？它们绝对能坚持到宇宙热寂那天。  

软件的真实成本在于维护  

区分两种代码的关键不在于它是AI生成还是人工编写，甚至不在于开发难度。真正的分水岭在于你为它设定的标准，以及后续的维护、扩展、迁移、排错成本。持久代码之所以昂贵，正因为它需要开发者对语言和环境有深刻理解——而一次性代码的廉价，恰恰源于你根本懒得维护它。  

所有关于持久代码的开发经验（或者说我们过去简单粗暴称为"软件开发"的那些事）都告诉我们：构建优秀软件最经济的方式，就是投资那些能建立快速反馈循环的社会技术系统。前置测试和CI/CD管道能及时捕捉问题，前置可观测性工具能理清系统行为。这些看似"开销"的投入，恰恰是保持长期高速前进的秘诀。  

正如Laura Tacho等人指出的，当前能从AI投资中真正获益的企业，都是那些早已夯实可靠性和可观测性基础的公司。换句话说，AI非但没有消灭对快速反馈的需求，反而让软件护栏变得比以往任何时候都重要。  

持久代码的本质是信任  

说我老派吧，但世界上没有任何测试套件能比得上经过两年生产环境考验的代码更让我安心。信任就是这样——需要时间沉淀。  

建立代码信心的唯一方式，就是在受控环境下让它接受现实考验，然后在已知稳定的基础上迭代。面对错综复杂的软件依赖网络，小而频繁的变更才是最可靠、最经济的演进方式。当你的需求列表里包含"可靠、稳定、可预测、高性能"这些字眼时，持久代码模型就是不二之选。  

当然，没必要把可靠性设计到超出实际需求的程度——毕竟每增加一个9的SLO，系统可靠性和成本都会呈指数级增长（Alex Ewerlöf的10x/9法则）。能用一次性代码糊弄过去的场景，何必劳驾持久代码呢？  

不过我打赌（纯属猜测），一次性代码的增长主要来自新场景的发明，而非取代现有持久代码的地盘。毕竟可靠性和可维护性的重要性，往往比人们意识到的还要关键，实现难度也比想象中更高。  

双模式共舞  

这两种代码模式完全可以在同一产品、代码库或项目中和谐共存。特别是对于已经掌握持久代码开发技能的工程师来说，掌握一次性代码技能简直是如虎添翼。  

我见过最妙的一次性代码用例，恰恰出现在构建持久代码的过程中：新功能可以先作为一次性原型验证，待形态稳定后再转化为持久代码；自动生成的测试用例和文档草稿，最终可能催生出更完善的配套材料。  

未来最值得观察的，或许正是这两种代码形态的边界地带——项目何时、为何、如何在这两种状态间流动转换。  

AI的双面舞台  

这根本不是"用不用AI"的问题，甚至不是"生不生成代码"的问题，而是要看清楚你正在进行的开发工作属于哪种成本-风险模型。  

当前AI开发工具最热闹的领域集中在规范说明、操作参数和功能描述生成上。这很棒，也很有趣。我预计未来大多数一次性代码根本不需要人类阅读——或者说"规范即代码"，实现细节都被折叠在视线之外。  

如果掌握一次性代码生成工具变得轻而易举，那它很可能不再被视为"软件开发"（薪资水平也会相应跳水）。我猜它最终会变成像打字或电子表格那样的基础技能，所有数字工作者都得会点皮毛。  

而对于持久代码库，AI的价值远不止于代码生成——它更能帮我们解决那些真正昂贵的部分。最让我个人兴奋的，是看到过去需要数年（或根本不敢尝试）的重构工程，现在借助LLM能在数月内完成。AI还能协助埋点监控、事故分析、异常检测，甚至帮我们理解代码逻辑、建立共识。  

第一波AI辅助开发浪潮聚焦代码生成，但这其实是最无趣的部分。世界上的垃圾代码已经够多了，再多几万亿行也不会让我更兴奋。但那些支撑世界的关键代码——这才值得期待。大型团队的协作成本高得惊人，如果AI能帮助小团队掌控更大产品面、更自信地快速迭代，那才叫革命。  

莫慌，稳住 <3  

初级工程师和高级工程师的差距，往往可以用"谦逊指数"来衡量。资深老鸟最明白不能轻信自己的代码。即便你对整个技术栈了如指掌，对当前改动了然于胸，你依然无法预知所有后果（觉得自己能预知的，往往错得最离谱）。所以我们要借助工具，循序渐进地发布变更，坦然接受控制力的局限——信任，但要验证。  

老实说，五年后的世界会怎样我不敢妄言。但在这个时间范围内，我看不到持久代码模型被淘汰的可能。就算真要淘汰，也绝不会是突变。因为信心的建立，永远需要时间沉淀。  

凡是能用一次性代码搞定的事情，人们肯定会用一次性代码解决——毕竟持久代码又贵又难搞。

但请注意：使用一次性代码是项技能，构建持久代码才是门专业。  

至于那些我们押上重注的、真正"运转世界"的代码？我实在想象不出有什么能替代生产环境验证的方案。不经过实际运行考验，不随时间积累信心，这样的代码谁敢托付？这份信心，可是他妈的无价之宝啊！