早在1982年，计算机科学家詹姆斯·马丁出版了一本书，其标题听起来可能有些奇怪地熟悉：《无需程序员的软件开发》。马丁在1991年将这一理念正式化为一种名为“快速应用开发”（RAD）的软件开发方法论。好吧，无需程序员的……应用程序开发正是今天代理式人工智能正在大力推动的事情。
事实证明，当年的RAD方法论可以教我们一些关于当今如何最好地使用AI代理进行编码的知识。但首先，让我们定义一下多年前RAD的含义。RAD是一种软件开发方法论，它推崇速度和迭代开发以及用户反馈，优于当时几乎所有人都在使用的瀑布式方法，后者包括大量的前期详细规划。
RAD分为四个阶段。第一阶段是需求计划，在RAD中这相当轻量级。需求计划基本上意味着你定义一些事情，比如你要解决的问题以及该应用程序将影响的用户群体。我们还想加入希望包含的任何功能，以及我们需要关注的任何约束条件。
但也就仅此而已了。这是因为RAD的基本假设是：用户直到能看到某些东西并做出反应之前，并不真正知道自己想要什么。所以让我们进入第一阶段。RAD的第二阶段是用户设计。团队快速构建一个可点击的原型，这是用户可以实际使用的东西。
他们把这个原型展示给真实用户，目的是在修复成本相对较低时尽早发现任何错误的假设。而在RAD中，这个原型……是会被保留下来的。我们会留着它。团队会在此基础上继续构建，直到其成长为最终的产品本身。
然后是第三阶段，即构建（Construction），此时实际的应用程序功能被开发出来。这一过程以短周期进行，测试和反馈持续发生，而不是等到最后才做。第四阶段是切换（Cutover），意味着部署到生产环境、数据迁移以及培训用户如何使用这个新系统。
马丁的书提到，小型团队在大约90天的时间盒内交付可用的系统，这在当时极其迅速。在那个典型的企业合作软件项目可能运行数年的时代里，这简直是奇迹。所以这里描述了一种快速交付的方法论，用户可以在修改成本仍然足够低时影响设计。
听起来很不错对吧？然而，如果我在一周前问开发人员他们的团队遵循什么方法论，答案很可能不是RAD。RAD并没有真正流行起来，因为当时时代的代码生成器——即RAD时代所谓的计算机辅助软件工程工具（CASE）——无法构建非常复杂的应用程序。
但现在，从纯文本中构建一个可用的应用程序完全成为可能。今天，我可以向代理式AI编码工具描述一个应用，并在几分钟内看到版本出现。我当然指的是老派的“氛围编程”（Vibe Coding）。因此，RAD整个方法论所围绕的原型制作变得超级快速。
我认为这就是为什么RAD旧的四个阶段方法论如此完美地映射到AI开发的原因。所以让我用一个令人兴奋的例子来说明我的意思，这是全球的氛围编程者停不下来制作的东西。当然，那就是一个费用审批应用。哦是的，为什么要花钱买真正的呢？
当你自己可以氛围编程出一个的时候！那么RAD的第一阶段——需求计划，实际上是如何在这里体现的呢？基本上，它是某人编写并发送给AI代理以实际构建应用程序的提示词。所以也许财务团队中的某个人用自然语言描述了问题，这就是提示词。
比如用户是谁以及审批规则是什么，你会注意到这正好符合RAD在这个阶段所要求的轻量级规划。提示词有效地成为了需求文档。现在对于用户设计，我们使用这个被提示的AI代理。那么AI代理做什么呢？它生成了一个实际可用的应用程序，所以它直接响应用户的提示词生成了一
个我们请求内容的原型。现在用户可以查看这个原型并点击浏览，也许还会提交一些反馈。比如他们抱怨审批屏幕有点令人困惑，而且紫色背景看起来太像AI生成的垃圾内容了。
这些反馈会回到AI代理那里。此时，代理重新生成原型，用户再次点击浏览，而代理继续生成和完善可用的代码。说到可用代码，下一个RAD阶段是构建（Construction）。好吧，代理已经在做这件事了。它正在生成各种东西，比如数据模式、工作流逻辑，也许还有连接一些电子邮件通知。
然后是第四阶段切换（Cutover）。这一切都是关于将东西部署到生产环境。所以财务团队演示了原型，嘿，结果大家都喜欢它。然后我想不可避免地会有位高管问那个显而易见的问题。他们说：“嗨，这运作得非常好。那么整个公司什么时候可以用上它？”
在经典的RAD中，我们知道答案：原型是被保留下来的，并且最终成为产品。好吧，这个时候已经到了。所以切换应该只是将这个原型部署到生产环境的问题，对吧？嗯，我们必须在这里问一个问题：当AI编写了所有代码时这样做真的是个好主意吗？
让我们来看看接下来会发生什么。那么财务团队应该直接部署费用审批原型吗？嗯，也许没那么快。如果我们仔细看看代理构建了什么，结果可能发现没有任何提示词说过员工不能报销自己的费用。所以很有可能代理从未编写过要求二次签字的规则，这意味着我可以提交一笔900美元的费用然后自己批准它。真是令人愉快（讽刺）。
这种情况其实相当普遍。对AI生成代码的研究发现，大约45%的样本存在某种类型的安全问题或安全弱点。那么……那么解决办法是什么？好吧，RAD时代的那些代码生成器没有聊天窗口。分析师向生成器输入了他们真正想要的规范。
也许是数据模型、业务规则。然后代码生成工具会获取该规范，并据此生成一些基本代码。所以詹姆斯·马丁的计划始终真正包含两半：它精确描述了我们要实际做什么，系统需要构建什么。
描述也被转化为实际可运行的代码，从而让我们能够构建原型。那么，请思考一下如今这种模式是如何运作的。AI 代理无疑为我们提供了一台非常出色的代码构建机器，这一点毋庸置疑。而描述这一半的内容，现在则源自另一种东西——那就是“规范驱动开发”。
其核心理念是：从原型中获得的发现会被整理成一份规范文档。业务规则、验收标准以及安全要求（例如“禁止员工自行审批自己的费用”）都会被明确记录。当用户点击浏览原型时……由于不存在的规则无法被点击，他们可能永远发现不了“自行审批”这个漏洞。
但因为这条规则写入了规范文档，安全团队的人员在阅读该规范时就会发问：“等等，什么阻止了我自行审批自己的费用？”一旦这条规则被纳入规范，它就变成了一项测试。生成的代码现在必须通过这项测试。
因此，是的，原型依然具有保留价值。但真正投入生产环境的，是原型教会了我们的一切——这些经验都体现在那份规范文档中。这意味着，RAD（快速应用开发）的四个阶段在历经35年后依然屹立不倒：轻量级规划、早期构建原型、短周期开发，并在产品得到验证之前不进入生产环境。
至于詹姆斯·马丁及其1982年的著作《无程序员应用开发》，在44年后的今天，我想说：那个特定的请求仍在等待第二次签字批准。因为程序员们依然在那里，只是他们的工作方向转向了编写规范和验证结果。