|
|
我最早接触计算机是在1983年，先是用了ZX-81（仅1KB内存，只有黑白显示），之后又用上了ZX-Spectrum（16KB或48KB内存，支持16色显示）。那感觉真的太神奇了——我能用一门编程语言（当时设备预装的是BASIC）让计算机执行各种指令，制作游戏和其他趣味应用。“乐趣”是编程体验中非常重要的部分：从零开始创造出东西，整个过程既好玩又充满挑战，哪怕我写的不是游戏，编程本身也像一场游戏。
在接触完ZX系列计算机后不久，我入手了一台Commodore 64，整个80年代的大部分时间我都在使用它。和ZX系列设备一样，它的内置编程语言也是BASIC（不过是另一个变体，说实话当时用起来还挺让人头疼的）。那时BASIC仍是主流语言，但大家普遍会写一些机器语言，更准确地说是汇编语言。这么做的主要原因是BASIC作为解释型语言运行速度太慢，而设备搭载的是一颗1MHz的6510 CPU（它是6502处理器的变体，Apple II和Atari 800电脑也用了这款处理器）。对于很多应用和游戏来说，BASIC的速度完全跟不上，而机器语言的执行效率则要快得多。
时光飞逝多年，如今BASIC早已退出主流舞台，汇编/机器语言也不再被广泛使用——绝大多数场景下根本没有使用它的必要。C、C++，甚至C#和Java（采用JIT编译）这类主流编译型语言，搭配性能强得多的处理器和更快的内存，足以支撑绝大多数应用的运行。就连Python、JavaScript这类“速度偏慢”的解释型语言也大获成功，它们的运行速度对很多场景来说完全够用（有时还会搭配用编译型语言编写的库来提升性能）。现在汇编语言的使用场景已经非常边缘化，只在特定专业领域出现，从来不会用来开发完整的大型应用。背后的原因显而易见：汇编代码冗长，最多只能提供类似C语言的过程化/结构化特性，更不用说它还完全依赖特定CPU架构。随着编程语言中更高层级抽象的引入，对汇编的需求已经降到最低，它仅常见于操作系统、固件、虚拟机监控程序、嵌入式系统这类领域——即便在这些领域，人们也不会用汇编编写完整软件，而是会尽早切换到C、C++或Rust这类仍然“贴近硬件”的高级语言。
AI编程时代
除非你一直住在偏远山洞里——如果你是软件开发人员，这基本不可能——你肯定已经见识过、甚至大概率用过AI的编程能力。我得承认，想到人类亲手写代码的场景会越来越少，把编码工作交给AI代理，我多少有些怅然。这或许是一种自然演进，是向更高层级抽象的迈进。但这里存在一个本质区别：过去的更高层级抽象通常是另一种编程语言，配套的工具链和开发环境可能更完善（这里暂且不谈可视化编程语言，这类技术曾被寄予厚望，但受限于“可视化”表达能力的先天短板，始终没能大规模普及）。
AI编程则截然不同——我们当下用来驱动它的是自然语言，这类语言天生自带歧义、不够精准，而这恰恰是编程语言最初被创造出来要解决的核心问题。
在我写下这些内容的当下，AI编程已经得到了广泛应用，其中人工介入的程度从完全零干预到深度参与不等，至少在现阶段，代码库的最终质量责任仍然完全由人类承担。
编程语言爱好者之间的经典之争——C#还是Java？Python还是Ruby？C还是C++？（X还是Y——随你挑）——似乎变得不那么重要了。真的有必要了解C++标准的最新进展吗？我们真的需要关心标准中新加入的某个库吗？如果AI生成代码，而我们人类只是做代码审查——我们真的需要关心编程的细微之处吗？AI编程的支持者可能看到了这样一个未来（请注意，并不太遥远）：AI将根据人类乃至AI的规格说明编写一切代码，代码甚至不需要让人类看到。但为什么不更进一步呢？也许AI能发明一种更高效的语言——毕竟，文本标记的使用只对人类有好处；也许一种更紧凑、更高效的二进制语言能让AI编程更快。
反对该模型的一个理由是系统会存在漏洞，因此人类或许仍是不可或缺的。至少就目前而言，人工智能并非万无一失。生产环境中的代码可能存在漏洞，其中一些相当棘手——比如数据竞争、内存问题，以及在部分领域中难以排查修复的复杂逻辑漏洞；或是各类性能问题。这种场景下就必须由人类介入：他们需要读懂代码才能完成漏洞修复。
但从另一方面看，人工智能同样可以辅助解决这些漏洞，目前这类应用已经落地。你只需要给出引导性提示词、日志输出等信息，AI就会主动追踪定位漏洞。不过目前这个过程还无法做到百分百保证，但随着AI能力不断提升，在未来的某个节点它完全可以独立完成漏洞修复，或许偶尔还需要少量的人类引导。
即便在需要人类介入的场景下，人类也未必需要直接查看实际代码。AI会完成所有修复工作——只要最终能满足预期的功能表现和性能指标，我们又何必在意代码本身是什么样的呢？完全没必要去了解代码的具体形态，毕竟它可能只是一种方便AI处理的内部二进制格式。
当然也会存在极端情况，这类漏洞无法通过上述方式解决。此时AI随时可以把这种二进制语言转换成人类能够理解的形式，供人类进一步深入排查。
对一部分人来说，这些潜在的发展方向可能有些难以接受。我们真的要把编程工作完全交给机器吗？或许历史能给我们一些启发。
在袖珍计算器问世之前，科学家会雇佣人工“计算员”来完成繁重的基础计算工作，自己则专注于核心的“科研”部分。电子计算器普及后，人工计算员这个角色就彻底消失了——如今我们会毫无保留地信任计算器的计算结果。
当我们用C这类高级语言编写代码时，会借助编译器把C代码转换成机器语言，让实体CPU能够执行；和信任计算器一样，我们也默认信任这些编译器。这并不代表编译器完全没有漏洞——它们确实存在漏洞，但我们依然会选择信任它们。现实中几乎没有开发者会去查看编译器输出的汇编代码，再和原始代码逐行比对找差异。就算真的出现编译器漏洞，最终也会被修复。
那我们为什么不能用同样的逻辑看待AI编程呢？AI确实会犯错，就像编译器也会出问题一样，但一旦发现漏洞，AI同样可以完成修复。我们完全没必要亲自去查看生成的代码。
人类编码的终结？
这一切是否意味着人类再也不需要手动编写代码了？我认为我们正朝着这个方向发展。看起来编码工作不再需要人类亲自完成，也难怪不少程序员真切地担忧自己的工作会被AI“抢走”。如果人类不再需要亲手编码，程序员未来的出路又在何方？
我最近做客一档直播播客节目，现场演示从零开始编写Windows内核驱动，这类工作涉及大量必须精准处理的编码细节。有一位观众提问，既然AI完全可以代劳写出代码，我们还有必要掌握所有这些细节吗？
诚然，AI写出的代码可能和我写的一样好，甚至质量更高。但我当时关注的从来不是编码细节本身，而是代码背后的架构与核心概念：内核驱动的运行原理是什么？它如何被加载？怎么管理自身资源？又要如何和内核建立关联？诸如此类。
核心逻辑是，编码的具体细节可以交给AI完成，但底层的核心概念无法被替代。一方面，人类要完成代码评审来验证AI生成的内容，就必须掌握这些基础逻辑；另一方面，哪怕假设AI编码完全零错误，我们想要的整体架构和顶层设计，AI也未必能掌握全局全貌。
更重要的是，就算我把所有编码工作都交给AI，依然需要向AI清晰描述编码需求：在这个项目里驱动要承担什么角色？它该如何和用户态程序通信？我希望采用什么样的日志方案？这类需求往往有多种可行选择，这就要求人类对领域有深刻理解，才能给AI输出高质量的需求说明。此时人类的身份就转变成了设计师和架构师，把繁琐细碎的编码工作全部交给AI处理。
这种逐步过渡是一个持续的过程，而非非黑即白的瞬间切换。它不会在一个月内就完全落地，但也不需要耗费几十年。AI的发展速度很难预测，它呈现出指数级增长的态势——这恰恰是人类的认知模式很难适应的，毕竟我们是习惯线性节奏的生物。
结语
面对这样的发展趋势，我内心难免有几分怅然。我至今仍享受亲手编写代码、创造出完全属于自己的作品的过程。我所掌握的那些关于特定编程语言精妙细节的知识，最终都会彻底过时。我现在还需要去学习某门编程语言的最新版本吗？当下我的答案依然是肯定的，但我猜在不远的将来，我的答案就会发生转变。
如果AI替我完成了应用的全部编码工作，那生成的代码真的属于我吗？这个问题本身或许就站不住脚。真正属于我的，是这个应用的创意、架构、功能、能力与设计。代码本身不过是一项实现层面的细节，交给机器来处理才是最优解。
原文链接
|
|
发表于