夜雨聆风直觉上，AI的到来好像能让我们直接把想法转化为代码，跳过设计和讨论的过程。
但现实往往并非如此。随着代码生成变得轻而易举，我们发现真正的瓶颈转移到了如何把人类模糊的想法变成精确需求和设计决策上。
AI并非自动消除软件工程的复杂性，而是揭示了一个长期存在的核心问题：人脑对需求和设计的把握，到底有多难？
软件工程的瓶颈转移
人们一度认为，有了AI，只要把需求扔给模型，就能让AI生成代码，开发效率自然大幅提升。
但这种观点忽略了一个关键事实：即便代码生成能力大幅提高，需求理解和设计决策 本身并没有变得更简单，反而因为实现手段变快而被无限放大。
Kent Beck等敏捷先驱指出，依赖最新的知识和工具可以使变更成本趋于平坦，这意味着“重大决策可以尽可能晚做，以提高其正确性”。
Fred Brooks则在《没有银弹》一文中提醒我们，程序员的大部分时间都花在解决问题的“本质复杂性”上，而不是解决工具本身造成的“附带复杂性”。
AI的出现简化了编码这样的附带复杂度，但软件真正困难的部分——理解问题领域、捕获隐含需求——并没有因此消失，反而更加突出。
实际上，AI让“重新定义软件开发经济学”成为可能。当AI代理可以在几秒钟内生成可运行的原型（prototype）时，返工的成本几乎归零，传统的项目规划和评估开始失效。
这意味着，人类开发者可以从大量的编写基础代码的任务中解放出来，把注意力更多地放在创造价值的地方：明确需求、设计架构、做决策。
这是一种范式的变化：决策延迟成为关键指标：让 AI 快速吐出原型验证想法，直到最后一刻知识最充分时再做关键决策。
AI 解放了我们的双手（编码），却把难题留给了我们的大脑（设计）。正因为写代码变快了，‘做对决策’才成了软件成败的唯一决定因素。这就是为什么传统软件工程里的需求与架构设计，至今依然是不可撼动的核心。
决策延迟与快速反馈
Matt Pocock推出了 /prototype 技能，这看似只是一个让AI快速编写小程序的小技巧，其实它对应的是软件设计中的深层次原则。
这个技能的作用是：当有一个难以凭想象直接回答的设计问题时，先让AI构建一个“小型、一次性”的可执行原型去验证想法。
这个原型从一开始就定义为临时代码：没有单元测试，没有完整的错误处理，也不追求优雅设计。它的目的只是在短时间内让我们学到东西，然后丢弃。
用软件工程的术语来理解，/prototype 技能实际上对应了几种经典实践的交集。
它与XP（极限编程）中的“Spike”（探针）非常相似：Spike就是团队为了解决一个技术未知或需求模糊的问题，迅速做一个实验性的实现，得出结论。
/prototype 就像一个自动化的Spike，用代码快速实验一个设计方案。
它也像几十年前就有的“抛弃式原型”方法：在系统需求和设计尚不清晰时，先做一个可交互的原型，然后再做正式系统。
这一做法与Boehm的建议一脉相承：如果后期修改的成本极高，那么在项目早期通过迭代原型和早期反馈来降低风险就是更有效的策略。
另一个相关概念是行走的骨架（Walking Skeleton）。
Alistair Cockburn定义Walking Skeleton为“一种端到端的最简系统实现”，用于在投入大量开发前验证整个架构是否可行。
虽然/prototype的粒度更小，只为特定问题建模，但它的精神也在于通过尽早交付可运行的样本来揭示架构或设计的不足。
换句话说，构建原型的核心价值并不在于它最终的代码是否被保留，而在于它让开发者和AI可以在低成本的环境中检验假设、暴露隐藏的缺陷。
从第一性原理来看，软件开发面临的核心困难在于：现实世界的需求本身往往不确定，人类的认知模型有限，而设计方案里充满了隐含假设；真正将软件投入运行的成本很高，导致错误往往要到很晚才能被发现。
/prototype正是在试图解决这个链条中的“决策延迟”和“反馈成本”问题。
它迫使团队在非常短的周期内验证想法，就像精益创业提出的“构建-衡量-学习”(Build-Measure-Learn)循环：先搞清楚问题，再尽快构建最小可行原型进行学习。
Kent Beck也一直主张通过持续的反馈循环来推进增量设计，使重大决策可以“尽可能晚”再做。
/prototype让AI和开发者都能快速“走回头路”，在大规模编码之前尽快收集反馈。
面对AI生成的“免费”原型，我们的开发方式会演变成：先来一个粗略原型(vibe)，然后再有系统地强化(harden)”。
也就是说，现在的竞争优势不在于谁更快地生成原型，而在于谁能以更快的速度把粗糙原型高效转化为可交付的软件：先用/prototype验证某个方案的可行性，再把结果作为输入提交给正式的需求规格和架构决策文档。
/prototype技能本质上是在尽可能早地把设计问题转化成可运行的“实验装置”，以测试我们的理解和假设是否正确。它缩短了决策所需的时间并提高了反馈的敏捷度。
这并不是AI时代才有的新技术，而是敏捷软件开发的逻辑延续：通过快速构建和验证原型，我们可以在早期捕获需求或设计上的问题，避免把错误留到昂贵的后期修复阶段。
AI时代的软件工程，不变的是什么？
AI时代改变了工具和速度，但软件工程的核心本质并没有改变。
软件的真正难点始终在于对现实需求的理解和应对复杂性本身。
正如Brooks在《没有银弹》中强调的，程序员如今“花在解决本质复杂性上的时间”远比解决工具问题的时间要多。AI虽然消除了许多琐碎工作，但那个“本质的复杂性”并未消失。
Martin Fowler的“设计持久力假说”也指出：在项目初期投入足够的设计努力可以提升项目的可持续发展能力，而忽视设计会积累技术债务、降低后期效率。
这些原则无论是传统编码时代还是AI时代都适用。
软件开发的进度的衡量单位不是功能数量，而是"验证学习"。也就是说，要专注于证明我们在解决正确的问题。
这与我们先构建原型、验证需求的做法一脉相承。
可以说，AI时代的软件开发并非引入了全新的规则，而是用新工具重新演绎了“旧套路”。
Ward Cunningham当年引入技术债这一概念，就是为了解释如果现在偷懒糊弄，将来要付出更多代价。
/grill-me和/prototype技能本质上是在软件开发的早期尽最大努力还清这笔“债”：面向需求的一问一答和面向设计的一次性原型，就是在事先规避后期重构的风险。
AI并没有让需求分析和设计过时，反而把这些长期被证明有效的做法，以更高效的方式带到了开发流程中。
结论
AI时代并没有削弱软件工程的基本原则，反而提醒我们要更加自觉地遵循它们。
Matt Pocock所倡导的/grill-me和/prototype技能，本质上就是把深思熟虑的软件开发思想包装成新的开发实践：在编写任何正式代码之前，先通过提问澄清需求，再通过原型验证设计，确保每一步都对准目标。
AI不是来替代需求分析和设计，而是放大了需求不明确时的风险。
只有坚持“先对齐意图，再实施方案”的原则，我们才能在AI浪潮中保持对软件质量的掌控。
如Martin Fowler所言，“对设计的投入让项目走得更远”，AI时代也是如此。
AI不会颠覆这条经验法则；它让我们有机会更早发现问题，将有限的精力花在最有价值的地方。
总之，AI并不是替代软件工程，而是强调了软件工程中那些经久不衰的核心信条：保持需求清晰、持续反馈和快速验证，让开发走在正确的轨道上，以应对其复杂性。