嗨，各位同学！听说现在AI编码助手特别火，大家都在讨论它能不能给咱们干活提速。结果最近Agoda发了篇文章说，虽然个人写代码的效率确实变高了，但整个项目的交付速度并没像大家想的那么理想。为啥呢？文章分析了半天，觉得毛病主要不在编码上，瓶颈早就挪到需求定义和验证这些环节了。 大家想想，编码本身从来都不是最费功夫的事儿吧？以前Fred Brooks不是说了嘛，开发没有银弹。这意思就是说，你光把某一步路走好，对整体进度的帮助会越来越小。Faros AI那边也做了研究，他们发现那些高频用AI的团队，任务量虽然多了21%，合并的PR数量也暴涨了98%，但PR的评审时间却拉长了91%。这说明啥？编程速度是提上去了，可压力全压到了后面的需求定义和验证上。 那个叫Leonardo Stern的工程师觉得这事挺有意思。以前大家都以为沟通是制约效率的成本，只要把代码写好就行。可现在情况不一样了，需求定义才是核心。这就逼着团队结构得跟着变。小团队本来就好沟通，达成共识快；大团队一乱套，成本蹭蹭往上涨。 跟AI合作到底该怎么干活？Stern总结了三种模式。第一种是“白盒”模式，让工程师逐行审查代码。但问题是现在AI一小时能生成几千行代码，这方法根本不现实。第二种是“黑盒”模式，直接把AI的成果上线，这虽然快，但风险太大。最后他推崇的是“灰盒”模式：工程师只要负责两件事——写准需求规格，还有根据证据验证结果。不用盯着每一行代码细节看。 这事儿其实挺颠覆的。以前大家觉得程序员最值钱，现在的趋势是人类的主导权正在往定义业务意图的层面转移。这个观点跟Leigh Griffin还有Ray Carroll在InfoQ上提的规范驱动开发理念不谋而合。他们强调规范说明书得是系统的事实来源，而代码只是重生的产物。 所以啊，以后咱们的工程交付物应该变成高保真的规范说明书——里面有可测试的验收标准、清晰的边界场景还有归档架构决策。具体怎么写代码？越来越多地交给AI去做就行了。这趋势肯定会深刻影响软件工程的未来！