重读《Application Development Without Programmers》，以及它对 AI 软件工程转型的启示
软件行业似乎有一个古老的习惯：每当出现一种新的开发工具，就有人宣布程序员即将成为历史。
1982年，英国计算机科学家 James Martin 出版了《Application Development Without Programmers》。书名相当大胆，几乎像是对整个软件行业发出的一封解雇通知。那时距离第一代 IBM PC 上市不过一年，大多数企业应用仍然由专业程序员使用 COBOL、PL/I 等语言开发。Martin 却认为，这种局面不会持续太久。
他的理由听起来很熟悉。计算机越来越便宜，软件开发人员却越来越昂贵。企业需要的应用数量不断增加，IT 部门永远有做不完的项目。既然机器可以承担越来越复杂的工作，为什么还要让人一行一行地编写程序？
四十多年后，这本书重新引起了注意。
2025年7月，软件开发者 Simon Willison 在博客中提起这本几乎被遗忘的著作。他发现，Martin 当年对软件行业的观察，与今天人们讨论 AI 编程时的语气惊人地相似。技术正在改变工作的性质，而那些靠旧技术谋生的人，未必愿意接受这种改变。Simon Willison’s Weblog
今天，我们有了 Claude Code、Codex 和能够独立执行开发任务的 AI Agent。编写代码的成本正在下降，软件工程师的职业前景再次成为争论的焦点。
不过，重读 Martin 的书，最有意思的并不是他对程序员命运的预测，而是最后一章的标题：
The Changing Role of the Systems Analyst——系统分析师角色的变化。
Martin 花了相当多的篇幅解释，为什么未来的软件不再需要那么多传统编程工作。但到了最后，他开始讨论一个更难的问题：如果用户能够自己创建应用，系统分析师还有什么事情可做？
这个问题，今天甚至比1982年更值得认真对待。
昂贵的代码，以及永远做不完的项目
Martin 写这本书时，企业计算机部门普遍面对一种令人沮丧的局面。
业务部门需要新系统，IT 部门排出一张长长的开发计划。等一个项目终于开始，原来的需求可能已经改变。系统交付之后，用户发现还有许多地方需要修改，于是新的需求又进入排队队列。
Martin 将这种现象称为 Application Backlog，即应用开发积压。
他还提出了一个颇有意思的概念：Invisible Backlog，隐性需求积压。那些没有出现在开发计划中的需求，可能比已经登记的还要多。原因很简单：业务人员知道 IT 部门忙不过来，索性不再提出要求。
这种现象并不陌生。今天，一家企业可能已经购买了 ERP、MES、OA、BI 等各种系统，却仍然有大量业务需求通过 Excel、电子邮件和人工操作来满足。有些需求从来没有进入正式的软件开发流程，因为所有人都知道，开发一个新功能需要走多少程序。
Martin 认为，解决办法不能只是招聘更多程序员。
他把希望寄托在第四代编程语言（4GL）、应用生成器、数据库查询工具和最终用户计算（End-user Computing）上。这些技术的共同特点，是让用户更多地描述自己需要什么，而不是详细规定计算机应该怎样完成每一步操作。
一个财务经理想了解某个部门的费用情况，或许不必先向 IT 部门提交开发申请。他可以直接查询数据库，选择字段，设定条件，然后得到报表。
对今天的读者来说，这听起来像是普通的 BI 功能。但在当时，让没有编程经验的业务人员直接与计算机系统打交道，已经是相当激进的设想。
Martin 的书用了大量篇幅介绍 NOMAD、MAPPER、APL、Query by Example 以及各种应用生成工具。他相信，这些工具会使大量传统编程工作变得多余。Google Books
后来发生的事情没有那么简单。
第四代语言确实提高了某些应用的开发效率，电子表格、数据库工具、快速应用开发和低代码平台也逐渐普及。但程序员没有消失。软件行业反而变得比1982年庞大得多。
一种合理的解释是，开发工具降低了软件的生产成本，也让企业开始尝试过去不值得开发的应用。与此同时，系统变得更加复杂，软件开始连接更多设备、人员和组织，原来由人工处理的业务规则也逐渐进入计算机系统。
软件开发的积压并没有随着工具进步而彻底消失。到了1990年代，研究人员已经注意到，第四代语言承诺的生产率提升往往局限于特定类型的开发工作，未必能够直接转化为整个项目的效率提升。Roger Clarke
这段历史给今天的 AI 软件工程留下了一个有用的提醒。
生成代码的速度和交付软件的速度，是两回事。
如果一个功能原来需要五天编写代码，现在只需要五分钟生成，但理解业务规则、协调系统接口、处理历史数据、完成测试和客户验收仍然需要两周，那么软件项目的总成本未必会按照同样的比例下降。
我们很容易被 AI 编写代码的能力吸引，因为这部分成果最直观：屏幕上出现了文件、函数和测试用例，几分钟后，一个应用就可以运行。
那些真正决定软件能否投入使用的工作，却不一定那么容易展示。
用户并不总是知道自己想要什么
传统软件工程有一个听起来十分合理的前提：在开发开始之前，应该先把需求弄清楚。
于是，系统分析师走进办公室，与业务人员交谈，记录现有流程，绘制流程图，编写需求规格说明书。经过几轮讨论，用户在文档上签字，需求被冻结，程序员开始工作。
一切都很有秩序。唯一的问题是，用户签字时，可能并不知道自己真正需要什么。
Martin 对这个问题相当敏感。他在书中专门讨论了需求规格说明、用户签字确认、需求冻结，以及原型开发。他认为，传统开发方法的一个根本缺陷，是假设用户能够在系统建成之前，就准确描述一个自己尚未使用过的系统。
这在现实中并不容易。
设想一个生产部门希望开发设备缺陷管理系统。系统分析师与用户开会，确定需要登记设备编号、缺陷描述、发现时间、处理人员和关闭状态。所有人都认可这份设计。
等系统真正运行起来，问题才开始出现。
同一设备重复发生的缺陷应该如何关联？一个缺陷由多个部门共同处理时，责任如何划分？已经关闭的缺陷重新出现，究竟应该重新打开，还是创建新的记录？历史数据需要保留多少年？
这些问题并不一定是分析师工作疏忽造成的。有些业务规则原本就没有被清楚地定义；有些问题，只有在系统投入实际使用之后才会浮现。
Martin 对原型开发的重视，正是建立在这种认识之上。
如果开发一个可运行的应用只需要很短的时间，用户就不必完全依靠想象来讨论需求。他们可以直接操作系统，发现问题，提出修改，然后再试一次。
今天的 AI Coding 让这种方法更有吸引力。
过去，开发一个具有真实交互能力的原型，需要程序员投入不少时间。现在，借助 AI，一位熟悉业务的分析师可能在一次需求讨论之后，就能做出可以演示的界面，甚至包含基础数据结构和部分业务逻辑。
这意味着，传统需求分析中相当一部分文档编写工作，有机会转移到可运行的软件上。
但这里也有一个容易被忽略的区别。
一个可以运行的原型，未必是一个正确的系统。
特别是在核电、医疗、金融等行业，业务规则的正确性、权限控制、数据完整性和审计追溯，不能仅靠用户操作几次原型来确认。
AI 缩短了从想法到原型的距离，却没有自动解决需求的正确性问题。
相反，当系统可以迅速实现，开发团队更容易在没有充分理解业务的情况下，把一个看起来合理的方案变成现实。
原来需要几周才能暴露的问题，现在可能几小时就被写进了系统。
Martin 希望系统分析师摆脱繁重的事前规格说明。今天看来，这个方向仍然值得坚持。但减少文档不应该成为目的。真正需要改变的是分析工作的方式：让那些可以通过原型验证的问题尽早得到验证，把更多精力留给业务规则、系统边界和必须明确承担责任的决策。
系统分析师失去的，是作为中间人的特权
《Application Development Without Programmers》的第21章只有十余页，却可能是全书对今天最有启发性的部分。
这一章讨论了用户主导的系统开发、系统分析师工作的彻底转变、摆脱旧有开发方法，以及新的专业化分工。
Martin 的基本判断是，随着业务人员获得直接创建应用的能力，系统分析师不能继续按照过去的方式工作。(原书目录，第21章)
在传统开发组织中，系统分析师拥有一个特殊位置。
业务人员通常不懂编程，程序员也未必熟悉业务。系统分析师负责把两种语言连接起来：听懂客户的要求，再用规格说明书告诉程序员应该做什么。
这项工作当然需要专业知识，但它也形成了一种组织上的依赖关系。业务人员要获得软件，往往必须先经过系统分析师。
当业务人员能够使用开发工具直接建立应用，这种依赖就不再是必然的。
一位财务经理能够自己生成预算分析报表，一位生产主管能够修改业务数据的展示方式，一位销售人员能够建立简单的客户跟踪工具。他们不必为每一个小需求都提交开发申请。
那么，系统分析师还有什么用？
Martin 的回答并不是让分析师去学习某种更复杂的编程语言。他设想，分析师将更多地指导业务人员选择和使用工具，帮助他们理解问题，提供数据设计和技术方面的支持，并参与那些仍然需要专业知识的系统建设。
这与他提出的 Information Center（信息中心）构想有关。企业 IT 部门可以从应用的唯一生产者，逐渐转变为支持业务人员自主开发应用的专业服务组织。
这种设想颇有远见。
它改变了技术人员与业务人员之间的关系。过去，技术人员的价值部分来自掌握别人不会使用的工具；未来，他们必须提供工具本身无法提供的判断。
举个简单的例子。
如果一位销售经理希望了解过去三年的客户流失情况，AI 可能很快就能生成 SQL 查询、分析图表，甚至搭建一个完整的 Web 应用。
但什么叫客户流失？
连续三个月没有采购的客户算不算？签订了年度合同却尚未付款的客户算不算？集团客户的一家子公司停止采购，是否意味着整个集团流失？
这些问题没有办法单纯通过提高编程效率来解决。
系统分析师需要与业务人员讨论，形成一致的业务定义，再决定如何获取和处理数据。
有意思的是，当编程变得容易，系统分析师反而更难依赖那些容易被看见的工作来证明自己的价值。过去，他可以交出厚厚的需求规格说明书。现在，他可能花了半天时间，只是帮助客户改变了对某个业务问题的理解。
后一种工作的价值也许更大，却更难用页数、功能点或工时来衡量。
这对今天的软件企业提出了一个不太舒服的问题：我们究竟是在为客户提供专业判断，还是在出售一套复杂的劳动过程？
代码可以生成，复杂性却不会自动消失
Martin 对第四代语言的乐观，后来受到了现实的修正。
这些工具对报表、数据查询、表单以及某些结构化业务应用非常有效。一旦遇到复杂算法、特殊业务规则、大规模系统集成或者性能要求，它们就未必比传统编程更合适。
这也是为什么低代码平台发展了几十年，却始终没有完全取代通用编程语言。
AI Coding 与第四代语言存在一个重要差异。
传统应用生成器通常只能在预先定义好的框架内工作。AI 则可以使用通用编程语言，在相当广泛的技术环境中创建软件。它既能生成一个简单的业务表单，也能编写数据库访问代码、调用外部 API，甚至参与复杂系统的重构。
从技术适用范围看，AI 的潜力显然更大。
不过，生成一个能够运行的程序，与构建一个可以长期运行的企业信息系统，依然有很大的距离。
Martin 在第17章《The Vital Role of Data Bases》中讨论了数据库的重要性。他特别关注数据独立性、数据库设计，以及以数据为中心和以处理过程为中心的不同系统开发方式。
这部分内容今天读起来并不过时。
假如一家企业允许各个业务部门利用 AI 自行创建应用，最初的效果可能非常令人满意。一个部门建立了设备台账，另一个部门开发了维修记录系统，第三个部门又建立了设备可靠性分析工具。
每个系统都能运行，每个开发者都认为自己提高了工作效率。
过了一段时间，问题出现了。
三个系统使用不同的设备编号规则，对设备状态的定义也不一致。有些数据重复维护，有些系统可以修改不属于自己管理范围的数据。原本希望提高效率的部门，现在需要花费更多时间核对这些系统之间的差异。
这并不是 AI 特有的问题。早期终端用户计算、电子表格和部门级应用开发都曾面对类似困境。
区别在于，AI 使创建这些应用变得更加容易，也可能使问题扩散得更快。
Martin 关于数据基础设施的判断，因此有了新的意义。企业需要建立稳定的数据模型、统一的业务语义、合理的权限机制，以及能够被不同应用复用的数据服务。
未来，一个组织或许可以让大量业务人员使用 AI 自行创建应用，却仍然需要专业人员负责公共的数据和技术基础设施。
软件开发越容易，组织越需要考虑如何管理那些不断出现的软件。
在这件事情上，系统分析师、数据架构师和企业架构师的工作可能会出现更多交叉。
软件工程的组织方式需要重新设计
Martin 在1982年讨论的是系统分析师如何适应新的开发工具。到了今天，这个问题已经扩大到整个软件开发团队。
传统的软件项目通常采用相对稳定的角色划分。
业务分析师负责需求，架构师负责设计，程序员负责开发，测试工程师负责验证，项目经理负责组织协调。
这种分工有其合理性，因为每一种工作都需要不同的知识和技能，而且各个阶段之间存在明显的交付关系。
软件企业也因此形成了一套成熟的成本计算方法：根据功能规模估算不同角色的工作量，再乘以相应的人天成本。
AI Coding 正在改变其中的部分假设。
过去需要多名程序员完成的代码，现在可能由一位熟练使用 AI 工具的工程师在较短时间内实现。需求文档、技术设计、代码生成、单元测试和部署脚本，也不再需要完全由不同人员分别完成。
这很容易让人得出一个结论：既然 AI 能做这么多事情，那么企业只需要更少的工程师。
但这个结论忽略了一个重要问题。
软件工程中的岗位划分，并不完全等同于软件工程本身的工作内容。
即使 AI 完成了大部分编码工作，业务分析、系统设计、数据治理、软件验证和客户交付仍然存在。这些工作可能由更少的人完成，也可能重新组合成新的岗位。
一种值得尝试的组织方式，是将软件工程重新归纳为三类相互联系的职能。
业务分析（BA）负责理解客户的问题、分析流程、建立业务模型，明确系统需要满足的规则。
系统设计与实现（SA）负责技术架构、数据模型、系统集成，并利用 AI 完成应用构建。
现场交付工程（FDE）负责验证软件是否满足真实业务要求，以及部署、培训、运行反馈和客户使用效果。
三个角色都可以使用 AI 工具。它们之间也不必存在严格的阶段边界。
例如，BA 可以直接利用 AI 制作业务原型，SA 可以参与需求讨论并验证业务规则，FDE 也可以根据客户现场反馈修改代码、补充测试和完善系统。
对一个小型、低风险的应用，经验丰富的工程师可能承担其中多种职能。
而对一个涉及复杂业务规则、多个外部系统和严格安全要求的项目，即使 AI 能快速生成代码，仍然可能需要多个不同专业领域的人员共同完成。
这里需要区分两个概念：角色和岗位。
一个项目必须有人对需求的正确性负责，但不意味着必须设置一个全职需求分析师；一个项目需要完成系统验证，也不意味着必须设置独立的测试岗位。
Martin 当年讨论系统分析师的专业化分工，今天则可以进一步发展为根据项目特点动态组合专业职能。
当然，这种组织方式能否取得更好的效果，还需要用真实项目数据验证。
它也会改变软件企业的成本评估方式。
如果 AI 已经能够在较短时间内完成功能实现，那么传统功能点数量与开发人天之间的线性关系可能逐渐减弱。估算项目成本时，业务复杂度、需求不确定性、系统集成难度、数据质量、可靠性要求和验证成本，可能比代码规模更能解释项目之间的成本差异。
一家软件企业可能用三个人完成过去需要十个人才能完成的开发工作，但这不意味着所有项目都只需要三个人。
人数的减少是技术进步可能带来的结果，而不应该成为项目估算时预先规定的答案。
谁来证明软件真正解决了问题？
2025年，Simon Willison 在讨论 AI 编程时，曾经提出一个很有意思的看法。
他认为，软件开发者的工作可以理解为识别能够用代码解决的问题，解决这些问题，然后验证解决方案是否有效。AI 可能越来越擅长中间的实现环节，但问题识别与结果验证仍然需要充分的专业判断。(Simon Willison，2025年7月)
这种观点与 Martin 四十多年前对系统分析师的讨论形成了某种呼应。
不过，我认为还需要再往前走一步。
在传统软件工程中，测试经常被视为开发之后的工作。程序员完成代码，测试人员检查功能，发现问题后再交回开发人员修改。
AI Coding 可能使这种分工越来越不自然。
如果 AI 可以同时生成代码和测试用例，那么开发人员完全有可能在短时间内获得一套看起来经过充分测试的软件。
但测试用例通过，究竟证明了什么？
如果需求本身存在错误，根据错误需求生成的程序和测试用例完全可能相互一致。
这种情况下，测试通过率再高，也无法证明系统满足了真实业务需要。
例如，一个设备检修管理系统可以正确计算维修任务的完成率，所有单元测试也都通过了。但如果系统把已提交验收、尚未正式关闭的任务计入完成数量，那么它可能持续向管理人员提供错误的统计结果。
这里的问题出在业务定义，而非程序代码。
未来的软件工程可能需要更加重视独立于实现过程的验证。
业务规则能否转化为可执行的验收条件？关键决策能否追溯到原始需求？AI 生成的代码是否遵守企业的数据和安全约束？软件上线之后，是否真正改善了用户的工作？
这些问题要求工程师具备更强的业务理解、系统思维和验证能力。
Martin 当年希望系统分析师帮助业务人员更好地使用计算机。今天，这项工作还需要增加一个重要内容：帮助企业判断 AI 创建的软件是否值得信任。
尤其是在那些软件错误可能造成严重后果的行业，生成代码的能力越强，独立验证就越不能成为一种可有可无的仪式。
重新衡量软件工程师的价值
回过头看，Martin 的预测有一部分实现了，也有一部分没有。
今天，大量业务人员确实不再需要依靠程序员就能完成数据查询、报表制作、业务流程配置和简单应用开发。电子表格、BI、低代码和各种 SaaS 工具，让计算机应用进入了几乎所有办公室。
但软件行业并没有因此缩小。
人们不断发现新的需求，软件承担了越来越多的业务活动。随着系统彼此连接，新的复杂性也不断出现。
AI Coding 是否会重复这段历史，目前还无法确定。
它的能力远远超过1980年代的第四代语言，也可能带来更大规模的岗位变化。认为 AI 不会影响工程师就业，显然过于乐观；认为所有软件工程工作最终都会简化为自然语言输入，同样缺乏足够依据。
对于正在转型的软件企业，我更愿意从一个实际问题入手：我们应该奖励工程师完成什么工作？
过去，一名优秀程序员可能因为编写代码速度快、熟悉某种技术框架、能够独立完成复杂模块而获得认可。
这些能力不会突然失去价值。尤其是深厚的技术知识，往往决定了一个人能否有效使用 AI、识别其错误，并处理工具无法解决的问题。
但如果企业继续主要按照代码量、功能数量和投入工时衡量工程师，就可能逐渐偏离软件工作的实际价值。
同样的问题也存在于业务分析和项目交付。
一个 BA 编写了两百页需求文档，不一定比帮助客户澄清十条关键业务规则的 BA 更有价值。
一个 SA 使用 AI 完成了大量功能开发，也不一定比那个提前发现架构缺陷、避免后续大规模返工的 SA 贡献更大。
一个 FDE 关闭了上百个缺陷，并不必然比那个在上线前发现一处严重业务逻辑错误的 FDE 表现更好。
软件工程的绩效评价，迟早需要更加关注系统的正确性、可维护性、业务适用性和交付效果。
这当然比统计工时困难得多。
代码可以计数，文档可以计页，工时可以填写。业务判断的质量却没有那么容易转换为电子表格里的一个数字。
但管理上的困难，并不构成继续使用错误指标的充分理由。
Martin 在第21章使用了一个耐人寻味的小节标题：Escape from Earlier Disciplines，摆脱过去的方法与惯例。
对于今天的软件企业，这或许比学习任何一种新的 AI 编程工具都困难。
因为真正需要调整的，可能不只是工程师使用什么工具，还包括企业如何组织项目、分配责任、培养人才，以及决定一个人的工作究竟值多少钱。
一本关于未来的旧书
《Application Development Without Programmers》今天已经不是一本实用的技术手册。
书中介绍的许多工具早已退出主流，某些技术预测也没有按照 Martin 的设想发生。它对生产率的乐观估计，在后来受到了不少批评。
但我并不因此认为这本书的价值有所降低。
技术预测最有意思的地方，有时恰恰在于它没有实现的部分。
Martin 在1982年已经看到了软件开发中的一个结构性矛盾：企业希望利用计算机解决越来越多的问题，却必须依赖一小群专业人员，把这些问题转换成计算机能够执行的程序。
他希望通过提高工具的抽象层次，让业务人员获得更多自主权。
四十多年后，AI 正在以一种他当年无法想象的方式推动相似的变化。
今天的用户已经可以用自然语言描述应用，并让 AI 生成代码。软件的实现过程正在变得更快，也更容易被普通人接近。
但企业仍然需要有人理解业务，决定数据的含义，协调不同系统的关系，处理需求之间的矛盾，并对最终结果负责。
这些工作过去分布在系统分析师、架构师、程序员、测试工程师和项目经理之间。未来，它们可能以完全不同的方式重新组合。
有些岗位会消失，有些岗位会改变名称，也可能出现今天尚未成形的专业角色。
这本书最值得重新阅读的地方，并不是它预言了一场尚未发生的程序员失业潮，而是它提醒我们，软件开发的组织方式从来不是固定不变的。
程序员曾经是计算机应用得以建立的重要条件。随着工具的发展，越来越多的应用不再需要传统意义上的程序员。
但决定应该建立什么系统、为什么建立，以及怎样确认它真正发挥作用，仍然是困难的工作。
计算机现在已经能够把一句话变成程序。
只是那句话究竟应该说什么，我们还得花不少时间弄清楚。