news 2026/8/29 20:51:55

Havenlon | 杂谈:当亲手写代码开始被叫作“古法编程“

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Havenlon | 杂谈:当亲手写代码开始被叫作“古法编程“

最近,程序员圈子里流行起一个颇有意思的词:古法编程。它没有严格定义,大致用来形容不开 Cursor、不用 Copilot、不调 Claude Code,也不把任务丢给 Coding Agent,而是自己打开编辑器,查文档、找接口、写函数、改 Bug,一行一行把代码敲出来。放在几年前,这就是再普通不过的"写代码",今天却突然多了"古法"两个字。

这个词当然带着调侃,和"古法酿造""柴火灶炒菜"是同一种修辞,强调的是一种曾经理所当然、如今开始显得费时费力的生产方式。但一个行业真正重要的变化,往往先出现在语言里。当昨天还被称为正常工作的方式,今天开始被冠以传统、手工甚至古法,变的通常已经不只是工具,而是人们对于什么才算正常生产方式的默认认知。

这种转变的官方版本,写得比玩笑更直白。Google 开发者博客在 2026 年 8 月 11 日的一篇文章里描述了它眼中的行业现状:过去大部分代码由人亲手写,如今则是 AI 助手和 Agent 批量生成,人的工作转向阅读、清理和验证这些代码,并且因为 AI 对系统全局缺乏视野,定义架构、划分服务边界、保证安全与可靠性的责任仍然留在人这一侧。这篇文章本意是为 Go 语言辩护,落点却指向一个更普遍的判断:软件工程的瓶颈正在从生成转向验证。

换句话说,AI Coding 真正改变的,可能并不是程序员写代码的速度,而是程序员在整个软件生产体系中的位置。

代码曾经是一种昂贵的商品

要理解这个位置的移动,先要理解它过去为什么如此重要。

过去几十年,软件昂贵的原因很多——需求复杂、项目管理困难、维护周期漫长、基础设施成本高——但其中有一个长期存在的基本事实:把人的意图翻译成机器能够执行的代码,本身就是一项昂贵的劳动。

一个业务部门想增加一个功能,说出来往往只是一句话:"希望系统能根据客户等级自动调整审批流程。"而从这句话变成一个可以稳定运行的系统,中间要经过需求分析、数据建模、接口设计、前后端开发、测试、部署、安全检查和大量调试。软件产业相当一部分成本,长期就沉积在业务意图、技术设计、程序代码、可运行系统这条翻译链路上,而程序员恰好站在链路的核心位置。

这也是为什么过去一家企业哪怕只想做一套内部管理系统,也可能需要一个完整的软件团队。代码不会凭空出现,每一个页面、接口、条件判断和数据结构,都需要有人把它写出来。编码能力因此本身就是一种稀缺生产资料。

生成式 AI 正在快速改变这个前提。过去一个开发者需要半天完成的接口,现在几分钟就能得到第一版;过去必须反复查文档才能搞定的陌生框架配置,Agent 可以读完整个项目后直接修改;过去需要大量初级工程师承担的模板代码、测试代码和重复重构,也越来越容易交给机器。这并不意味着这些代码天然正确,但它意味着另一件更要紧的事:代码开始变得廉价。

而当一种长期稀缺的生产资料突然大量供应,受到冲击的从来不只是生产它的人。围绕它建立起来的组织结构、定价体系和产业分工,都会跟着松动。

代码越便宜,判断反而越昂贵

松动的第一处,是一种相当普遍的直觉:既然机器能快速写出代码,软件开发这件事应该会越来越简单。现实可能恰恰相反。

因为 AI 降低的是产生一个答案的成本,却没有同比降低判断这个答案是否正确的成本。一个 Agent 可以很快写出一个支付接口,但它不会替企业回答:这笔支付在什么条件下才应该被允许,失败之后能不能自动重试,重试会不会造成重复扣款,谁有权修改金额,审批通过之后如果账户状态发生变化原来的授权是否仍然有效,依赖服务异常时系统应该降级、停止还是继续执行。这些问题不会因为代码容易生成而消失;恰恰相反,当代码产能骤然放大,它们的重量还会增加。

过去,一个程序员一天写三百行代码,他最多只需要面对这三百行带来的复杂性。未来,一个人同时指挥多个 Agent,一天可以让系统产生几千甚至几万行代码。这时候限制生产力的东西已经不再是键盘速度,而是这个人究竟能理解多少、能判断多少、能为多少东西承担责任。

于是 AI Coding 可能带来一个相当反直觉的结果:

代码生产能力越强,人类判断力反而越稀缺。

过去软件工程讨论最多的问题是怎么写得更快,未来越来越重要的问题可能变成:这么多代码,谁来证明它们值得存在。

程序员的位置正在从生产者移向判断者

如果承认瓶颈已经从写转向证明,那么把 AI Coding 理解成"更高级的代码补全",就会严重低估这轮变化。

假如 AI 只是让一个人从一天写五百行变成一天写一千行,企业要做的事情确实很简单:给每人配一个工具,效率自然提升。但如果代码本身不再是主要瓶颈,组织方式就必须跟着改变。过去的软件团队建立在一个基本假设之上——人的编码时间是有限的。因此需求增加就增加开发,开发增加就增加测试,系统变大就增加更多维护人员。很多大型 IT 服务企业甚至长期把工程师数量、项目人天和投入规模当作商业模式的地基。

这块地基已经开始移动。路透社 8 月 21 日报道印度 IT 服务业时提到,塔塔咨询、Infosys、Wipro、HCLTech 和 Cognizant 等外包巨头正在调整商业模式,把收费越来越多地绑定在结果而不是工时上;客户一边要求大幅降价,一边用 AI 把部分工作收回内部,而过去"我们有庞大的人员规模"这一竞争优势,正随着自动化程度提高而不断贬值。

这比"程序员会不会失业"更值得注意,因为真正被改写的是一套运行了几十年的组织逻辑:很多执行者加上少数判断者。未来的软件团队有可能逐渐转向另一种结构——少量高判断力的人,加上大量机器执行者。人的任务不再主要是亲自完成每一项编码劳动,而是定义目标、划分边界、设计架构、设定约束、审查结果,并对最终系统承担责任。

一个优秀工程师最重要的能力,也会随之改变。过去,一个年轻工程师最直接的竞争力是"这个功能我能不能写出来";未来更要紧的问题可能是"这个功能到底应该以什么形式存在于整个系统里"。前者考验实现,后者考验抽象、判断与责任。

工业革命淘汰的从来不是"手"

这样的位移,在技术史上并非第一次发生。

纺织机出现之后,人类没有失去双手;汽车出现之后,人类也没有失去双腿;电子表格普及之后,会做加减乘除同样没有突然失去意义。真正变化的是另一件事:社会不再愿意为一种已经可以被机器规模化完成的劳动,继续支付过去那么高的溢价。所以工业革命淘汰的从来不是手,而是把手当作核心生产力的组织方式。

AI Coding 对程序员正在做类似的事。会不会写代码依然重要,在操作系统、数据库、嵌入式、安全、分布式和实时系统这些领域,深入理解代码甚至比过去更重要;但"能够把代码写出来"本身,正在快速失去稀缺性。

摄影提供了一个更近的参照。曾经,摄影需要昂贵设备、胶卷、曝光知识和暗房技术,因此"能拍出一张照片"本身就是能力。智能手机出现之后,几十亿人都能按下快门,摄影并没有消失,消失的是按下快门这个动作的专业溢价。专业摄影师依然存在,只是市场要求他提供的东西,已经从"能拍到"变成了构图、叙事、审美、判断和独特视角。

编程大概正在进入类似的阶段。未来人人都可能让 AI 写出一个应用,但这并不意味着人人都能设计一个可靠的系统。

当软件越来越容易制造,可信的软件可能反而越来越贵

这种稀缺性的转移,最终会传导到整个软件产业的定价逻辑上。

过去企业购买软件,一个很重要的理由是自己开发太贵。如果一套 CRM、审批系统或内部运营工具需要几十名工程师长期投入,购买成熟 SaaS 显然更划算。当 AI 把开发成本压缩到原来的一小部分,一个问题自然会浮上来:为什么我不能自己做?路透 Breakingviews 在 8 月的一篇专栏中已经把这个疑问摆到了商业层面,其判断相当克制——Vibe Coding 的压力主要落在那些本身只是薄薄一层工作流封装的产品上,而真正守得住的产品,护城河在于分发、数据、信任或运营复杂度。

这句话的另一面同样重要。企业很快会发现,做出一个"能跑"的软件越来越容易,做出一个能够长期运行、能够审计、能够扩展、能够维护、出了问题有人负责的软件,却并没有同步变容易。于是市场可能出现一种新的分化:实现越来越便宜,可信越来越昂贵。

大量一次性应用、内部工具和简单业务系统会因为 AI 而迅速商品化;而那些真正涉及资金、生产、医疗、基础设施、核心数据和现实执行的系统,价值会越来越集中在另一组能力上——架构、验证、安全、证据、可靠性、责任与边界。软件产业最昂贵的部分正在缓慢移动:过去人们购买的是"帮我把软件写出来",未来人们更可能购买的是"帮我确保这个系统值得被运行"。

真正的程序员,也许才刚刚出现

顺着这条线看下去,把今天的变化概括为"AI 要取代程序员",反而低估了它。更准确的说法也许是:AI 正在重新定义什么东西才配被称为程序员的核心能力。

过去几十年,大量优秀工程师其实把相当多时间消耗在机械劳动上:写重复接口、搬数据结构、处理模板代码、查 SDK 文档、改配置文件、补测试、调格式、修复大量并不复杂的 Bug。而最能体现软件工程能力的部分——架构、抽象、边界、可靠性、安全、对复杂系统的整体判断——往往只占工作的一小块。如果 AI 最终把前一类劳动大量吸收掉,这个职业未必会变得更廉价,反而可能重新变得更专业。

未来一个优秀工程师的价值,会越来越少体现在今天写了多少代码,而越来越多体现在:他知道什么东西应该被构建,也知道什么东西不应该被构建;知道系统哪里可以灵活,哪里绝不能妥协;知道什么时候可以相信机器,什么时候必须拒绝机器。这里的拒绝并不是对机器的不信任,而是承认一个更朴素的事实——机器会在完全善意、完全"正确"的推理下写出一段不该存在的逻辑,就像人也会。因此可靠性不能只依赖某一个环节足够可信,而要依赖一套即使某个环节出错、也仍然能够拦住结果的结构。当一切看起来都能运行的时候,仍然有人能问出那句"它真的正确吗",这句话才有分量。

这或许才是"古法编程"这个玩笑背后真正值得注意的地方。今天我们说一个人还在亲手一行行敲代码是古法编程;几年后回头看,这个词记录下来的可能并不是某个编辑器、某个模型或某种开发习惯的兴衰,而是软件产业跨过的一条边界:

软件第一次从代码稀缺的时代,进入代码过剩的时代。

在一个代码越来越廉价、近乎无限供应的世界里,真正昂贵的东西将不再是代码本身,而是判断、责任、边界,以及知道什么东西即使能够被写出来,也不应该被执行。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/8/29 20:51:41

Python高效筛选纯质数:从埃氏筛到BFS的算法实战

1. 项目概述:从一道竞赛题到算法思维的实战最近在复盘一些经典的算法竞赛题目,第十二届蓝桥杯的“纯质数”问题让我觉得特别有意思。它不像那些复杂的动态规划或图论题那样让人望而生畏,但恰恰是这种题目,最能考验一个程序员对基础…

作者头像 李华
网站建设 2026/8/29 20:51:38

硬件SPI终极指南:从协议原理到高速PCB布局与调试实战

1. 项目概述:为什么我们需要一次“终极总结”?搞嵌入式开发,尤其是和各类传感器、存储芯片、显示屏打交道,SPI(Serial Peripheral Interface)这个通信协议绝对是绕不开的坎。我从业十几年,从8位…

作者头像 李华
网站建设 2026/8/29 20:49:05

基于STM32的工控电压频率采集设备设计实战:从方案到调试

1. 从零到一:一个工控老兵的电压频率采集设备构建实录最近在整理过往的项目资料,翻到了几年前为参加一个国家级技能竞赛而设计制作的一套电压、频率采集设备。这个项目虽然源于比赛,但其核心——如何稳定、精确地采集工业现场或实验室中的电压…

作者头像 李华
网站建设 2026/8/29 20:46:02

C语言字符串函数模拟实现:从strcpy到strncat的底层原理与安全实践

1. 项目概述:为什么我们需要亲手模拟这些“老朋友”?在C语言的世界里,字符串操作是每个开发者都绕不开的基础。strlen、strcpy、strcat这些函数,我们几乎每天都在用,熟悉得就像呼吸一样自然。但不知道你有没有遇到过这…

作者头像 李华
网站建设 2026/8/29 20:45:32

联想昭阳N4620 KX-6640MA Win10驱动缺失问题深度解析与实战修复指南

简介:在Windows系统安装与维护过程中,驱动程序是连接操作系统与硬件设备的关键桥梁,其核心原理在于通过特定的软件接口实现硬件资源的识别、管理与调用。正确的驱动不仅能确保硬件功能完整释放,更是系统稳定性与性能优化的基础&am…

作者头像 李华
网站建设 2026/8/29 20:44:04

51单片机模块化编程实战:从省赛题解析到工程架构设计

1. 项目概述:从一道省赛题看模块化编程的实战价值最近在整理蓝桥杯单片机的历年真题,第十届省赛那道题又一次引起了我的注意。这道题本身的功能要求并不算复杂,无非是按键、数码管、LED、定时器这些基础外设的组合应用。但让我反复琢磨的&…

作者头像 李华