作者 | 邹欣
缘起
《》执行总编唐门教主上个月某天深夜写了一篇博客 --《编程的未来》（ https://blog.csdn.net/tangxiaoyin/article/details/130651527 ），要我谈谈感想。这也 是最近软件工程师们聊得比较多的问题，上周，在上海的 “关东小磨” 和十多位 CSDN 博主聚会的时候 （https://devpress.csdn.net/shanghai）， 大家也 稍微谈了一下这个话题，但是谈得不透。我想在本文整理一下我的思路。
软件行业有多少部分会被取代
AI 编程的能力边界
首先，从去年开始的 AI 辅助编程浪潮中，很多人提到，从具体的函数实现来看，目前 AI 代码生成有很多做得不好的地方，或者有很多 bug。
我认为不必纠结这些 bug，它们一定会不断地被解决，这是一个时间问题，也许是半年，也许是一周。但在编程方面，它有一个能力边界，这个边界未必能很快跨越。
慕测平台的一篇高质量文章总结了 AI 辅助编程目前的能力边界，我总结如下：
▶ 生成的代码长度有限制。很多情况下，AI 不能输出完整的代码，还需要程序员来拼接代码，而他们要非常懂这些程序才能拼接成功。
//问程序员：你参加过的最复杂的项目，总代码量有多少？有超过一千行代码么？
▶ 不能有效处理超长程序、开发环境的配置、多线程编程、已有程序的 bug 修复等问题。
//问程序员：你修复过的最复杂的 bug 是什么？
▶ 泛化能力有限。如果是一个人类程序员，他在一个算法测试平台通过了很多编程练习，那么他在另一个不同的编程平台也应该能应对自如。但是，目前的 ChatGPT 还不能融会贯通，举一反三。
//问程序员：你能举一反三么？
▶ ChatGPT 处理复杂编程中抽象的 “类” 和 “依赖关系” 的能力还比较弱。
//问程序员：你在这方面能力如何？你写的最复杂的 OO 设计有多少父类子类？
▶ Fred Brooks Jr. 在著名的 “没有银弹” 论断中提出，软件开发中的关键任务就是理解并处理反映软件构成的复杂概念, 目前 AI辅助编程也并没有在这个方面取得突破。
//问程序员：你构建过多么复杂的软件，这个软件运行了几年，这几年中你是如何维护这个软件的？
▶ ChatGPT 等编程辅助工具缺乏创造性编程的能力。
//问程序员：你曾经创造性地解决过什么问题？
▶ ChatGPT 等工具的能力，取决于提问者的能力。
//问程序员：你的提问能力如何？
如果 AI 都做不到上面这些，那我们的程序员有多少能做到的呢？（：上面的红字部分，通常会出现在面试中，你都能回答么？）
程序 - 软件 - 软件企业
在我们深入谈论 AI 是否会取代程序员之前，我们先看看软件包含哪些成分。
我们要讨论的是：AI 辅助编程在工业尺度上，会起到什么作用？在《构建之法》这本书里，我提到过下面三个公式，可以看到 “编程” 在 IT 这个工业中，到底处于什么位置：
程序 = 算法 + 数据结构 软件 = 程序 + 软件工程 软件企业 = 软件 + 商业模式
现在的 AI 辅助编程，只是在第一个层次极大地帮助了程序员，但后面两个层次还是要靠人，即各种大语言模型和它们衍生的工具会在文档生产、归纳、流程处理方面有很多帮助，但关键的地方还是要靠人。
程序运行在 CPU 上，都在干什么？它们在对数据进行各种操作，增删改查 （Create Retrieve Update Delete — CRUD）。一个好的程序，要保证这些操作的正确和高效，同时还要确保程序正确使用计算机的各种资源（内存，网络，外设等）。这些问题，都是可解的，AI 一旦学会，就能任劳任怨地做好。但是人类通常有各种智力、懈怠、粗心等毛病，会犯很多错误。在软件行业发展的几十年中，代码正在不断地帮助人类，避免人类犯错误。就像文字编辑器能自动提示人类的拼写错误那样，代码编辑器早在二十年前就能通过自动变量提示、语法高亮等方法，让程序员避免犯错，加快编程效率。
所以，我们能有 AI 帮助大家写完整的函数、处理常见的问题，这是一件好事。
那么，这样的好事，为何让很多程序员非常担心呢？在此， 我想引用 软件工程专家 Kent Beck 的论断：
AI 会取代一个程序员 90% 的技能，但是会把剩下的 10% 的技能放大一千倍。
每个程序员都照照镜子问自己，我有哪些技能，是属于可以通过 AI 放大一千倍的？
如果你只会增删改查，那么 AI 的确可以完全取代你，所以可以关注一些 AI 短期内不太可能达到的技能：
▶ 对技术的娴熟掌握，高效 debug 的能力。
▶ 对软件体系架构的全面理解，集成的能力。把你写的 1000 行代码集成到现有的十万行代码的系统中去，把各个模块集成、优化为一个高效的系统。
▶ 对软件运行数据的理解，能从数据中洞察到问题，而不只是一个会念数据的人类。
▶ 提问的能力。向用户提问，了解用户的真正需求，向领导、同事提问，了解大家的思路，当然，还有从对方角度思考问题的能力和交流的能力。
▶ 与软件团队其他角色和流程合作的能力。一个产品的质量，可能取决于整个流程中最差的那个角色和环节。一个软件工程团队有售前、产品经理，产品架构、技术架构、QA、安全体系、UED、售后支持等角色，程序员在编程阶段获得了 AI 工具的赋能，能否让其他角色和流程也获得类似的赋能呢？
▶ 对其他业务的了解。例如，你想让 AI 帮助医疗行业，那么你对医疗行业了解多少呢？
我们程序员，也要多了解 #软件工程#， #商业模式#， #行业#， 才能让你的这些才能被先进的 AI 工具放大。
衣食住行中， “衣” 的变化
随着 AI 辅助编程的发展，程序员是不是会失去越来越多的工作机会，最后行业萎缩，就没有价值了呢？
我们先看看人类需求的第一位，在“衣食住行”中名列前茅的 “衣”， 看看它的发展是不是会给程序员一些启示。资料来自于网络和 ChatGPT，New Bing （例如百度百科，和一些文章 https://www.sohu.com/a/400708937_99933236） 。
▶ 百万年前- 树叶、兽皮。
▶ 几千年前- 用野生的麻。用石轮或陶轮搓捻成麻线，然后再织成麻布。
▶ 几千年前- 人们已将蚕蛾驯化家养，并能织出较为精细的丝织物。到了殷商时期，养蚕已很普遍，人们已熟练地掌握了丝织技术。
▶ 几千年前- 手工织布机的出现和缓慢改进。“男耕女织”，“子不学，断机杼” 的说法就出现在这个时代。
整天坐着，一根线一根线地织布，似乎和现在码农一行一行地编码也很类似啊。
▶ 一千年前：提花织机的出现。 在中国古代织造技术中，最为复杂的就是提花技术。 为了使织机能反复有规律地织造复杂花纹，人们先后发明了以综片和花本作为提花装置来贮存纹样信息，形成了多综式提花机和各类花本式提花机。 提花 技术是纺织史上的里程碑，提花机的基本概念是将提花规律贮存在织机的综片或是与综眼相连接的 综线上，利用提花规律的贮存来控制提花程序，使得这种记 忆信 息得到循环使用。
用今天的眼光看，古人发明的提花技术就是一种图形信息存储技术，如同计算机的程序，编好程序之后，所有的运作都可以重复进行，不必每次重新开始。
▶ 黄道婆（十三世纪）学习、改进、推广了棉纺织技术和先进工具 （现代程序员的祖师爷应该是她们？） 。
现在网上流传的 “爱心 Python 代码” 等等， 能编出这样的花样么？
▶ 百多年前：飞梭的织布工具，和珍妮机（Spinning Jenny）的出现，大大提高了生产率，也引起了手工业纺纱者的愤怒。他们捣毁了珍妮机，烧毁了发明者的房屋。但是革新的浪潮接着打过来，紧接着就出现了水力和蒸汽驱动的纺织机。到 1830 年，英国整个棉纺工业以及基本上完成了从工场手工业到以蒸汽机为动力的机器大工业的转变。
上段文字提到的提花机，也传到了欧洲，在十九世纪获得极大的改进，其中一个模型就是雅卡尔提花机。 雅卡尔发明了一种用打孔卡片控制的纺织机，纺织机可以根据预先设置好的“程序”（虽然当时还没有“程序”这个概念）移动丝线，织出漂亮的布匹。 这是第一次把信息通过一个机器能够识别的载体记录下来，再由这个信息来控制机器的运转。
现代计算机的先驱巴贝奇从雅卡尔的提花机得到了启发，很快想到 可以把穿孔卡片应用到他正在设计的分析机上。 分析机读卡装置的原理与雅卡尔提花机类似，也是靠探针尝试穿过卡片，要么顺利穿过，要么被卡片顶住，两种不同情况下的探针位移能产生不同的机械传动——这其实是计算机史上最早的二进制应用。
▶ 百年前：化学纤维的出现，让衣服不再是 “一根一根的丝线纺织而成”
▶ 几年前：衣服裤子有破洞，都不是 bug 了，而是 feature！牛仔裤做好后，还专门去做旧，搞出破洞。 （另外，把牛仔裤做旧、做烂的过程，对工人和环境并不友好，这点很多人并不了解！）
请问
▶ 在这千万年的演化中，服装行业是变大了，还是萎缩了，在这个行业工作的人，是有更多的机会了，还是更少的机会？
▶ 现在软件编程这个行业，是处于纺织业的哪个阶段呢？ （我想肯定不是把破洞当作 feature 的阶段）
▶ 巴贝奇这样的计算机先驱从纺织机械的设计中得到了启发，你能从纺织业或者其他行业得到什么启发呢？
▶ 你认识了这个软件编程行业处于对应的 “衣” 阶段，你觉得应该从 “衣” 哪个阶段获得什么启示呢？
一波一波的浪潮
另外，让工具来帮助编程和软件工程的各个环节，一直以来都是软件工程师和软件科学家的愿望和探索。从自动语法提示，到自动测试用例生成，再到 CI/CD，这几十年都有巨大的进步。CASE（Computer Aided Software Engineering） 一度是一个非常热门的研究领域，最近为何很少听到了呢？ChatGPT 给我如下的解释：
CASE （Computer-Aided Software Engineering） 是一种计算机辅助软件工程的方法，旨在提高软件开发效率和质量。它包括了多种工具和技术，如需求分析、数据建模、程序设计、测试等等。 然而，CASE在20世纪90年代之后逐渐没落了。其中的原因有以下几点： 复杂度高：CASE工具本身就很复杂，而且很难与其他工具集成。这导致了学习和使用CASE的门槛非常高，普通开发人员很难掌握。
成本昂贵：CASE工具的价格很高，因此只有大型企业才能承担得起。对于中小型企业和个人开发者来说，购买CASE工具是一笔巨大的财务负担。 缺乏标准：CASE工具之间缺乏标准化，因此不同的工具之间很难进行兼容和集成。这导致了开发效率的降低，使得CASE的应用受到了限制。 功能单一：CASE工具通常只能完成一部分的软件开发任务，无法满足复杂软件开发的需求。因此，开发人员往往需要同时使用多个CASE工具，这增加了开发的复杂度和成本。 综上所述，以上原因导致了CASE的没落。虽然现在已经有了更多的开发工具和技术，但CASE的思想仍然在软件开发中发挥着重要的作用。
我个人也搞过一些 “程序理解”， “自动编程” 的实验，下图是我和微软研究院的小伙伴在 2019 年内部 “黑客松” 上展现了 “自动找到你想要的 Python 代码” 的功能。核心想法借鉴了 2018 年 GitHub 团队的工作，用 word-embedding 来训练和寻找代码、函数说明、代码注释的相关性，帮助用户找到他想要的代码。这个小项目最后还得奖了。
一轮一轮的小波浪之后，一个大潮正扑面而来：
数据来自 CSDN 趋势图
长忆观潮，满郭人争江上望。来疑沧海尽成空，万面鼓声中。 弄潮儿向涛头立，手把红旗旗不湿。别来几向梦中看，梦觉尚心寒。
IT 界每隔几年就有一波浪潮或者泡沫，新的一波大潮已经打过来了。想躲？能跑多远？不如成为弄潮儿，勇向涛头立。
热门跟贴