AI时代,软件工程造价还需要功能点吗?AI,让我们更忙了,还是更闲了?我们是需要更多的程序员?还是更少?

前几年，很多客户在问我：软件厂商使用低代码/无代码编程，软件项目应如何进行造价？其背后的意思：应该如何压一下他们的价格？可以借此降本增效。

现在，这个问题的前半部分改成：使用AI编程。

这个话题，还引申出了：是否还需要度量规模，是否还要计数功能点？以及业界的终极问题：AI时代中，我们是更忙了，还是更闲了？我们的团队是需要更多的程序员？还是更少？

一、都以为增效了

首先，在这里引用一项实验数据。

2025年，美国非营利机构METR做了一个随机对照试验，找来一批在开源项目里有平均五年贡献经验的资深开发者，让其中一半人用AI工具，另一半不用，然后记录完成任务的实际工时。

结果是：用了AI的那组，完成任务的时间比不用AI的那组多了19%。

更有意思的是他们在实验前后各做了一次主观调查。

实验前，开发者预测AI会让他们快24%。

实验后，AI组的成员们依然相信AI让自己提速了20%。

感知与现实之间，隔着整整39个百分点的人为幻觉。

二、工作量的内容变了

为什么用了AI反而更慢？

AI确实把”写代码”这件事加速了，某些标准化功能，LLM几秒钟就能给出一个语法正确、结构工整的实现。这部分效率提升是真实的。

但软件开发不等于写代码。

写完之后，你要验证它是否真的满足了业务逻辑，不只是语法上没错。

你要确认它在边界条件下不会崩溃。你要检查它有没有在你看不见的地方悄悄动了别的模块。

你要判断它引入了哪些安全漏洞——根据CodeRabbit的调查数据，AI生成代码引入漏洞的概率是人工代码的2.74倍。

这些工作，AI目前做不好，或者做了之后你还是不敢信。

所以发生的事情是：写代码的工时下降了，但验证、纠错、集成的工时上升了。

总工时不减反增，但构成已经根本改变。

还有一个更隐蔽的新增工时，叫做”提示工程”。怎么把需求描述清楚，让AI生成出你真正想要的东西，本身就是一种需要反复迭代的技能消耗。

Frontiers in AI上今年发表的一篇论文把这个现象定义为”迭代推理轮次”——不是代码写错了要返工，而是为了让AI理解你在说什么，你需要来回对话若干轮。

这一点，可能又要回到《没有银弹》了。

在传统软件工程时代，整个生产链条上最大的问题/堵点就是——产品经理无法产出正确的需求规格。

三、尺子先于数字

现在回到软件工程造价的正题：在AI时代，规模度量（功能点分析），还需要吗？

先说什么没变。

软件交付给用户的功能规模，不会因为代码是人写的还是AI生成的而改变。

一个ERP系统需要处理多少种事务、维护多少个逻辑数据，这个数字是客观存在的，不受开发方式影响。功能规模，是软件对外呈现的能力总量，而不是开发实现的过程。

这一点，在AI时代不但没有失效，反而变得更重要。

原因是：当开发过程本身变得更加不透明——你不知道供应商有多少代码是AI生成的，也不知道他们是否做了足够的验证——功能点数值是唯一一个与开发方式无关的客观锚点。

四、模型本身出了裂缝

说完什么没变，再说什么变了。

传统的估算模型是这样的：

功能规模 → 工作量（人天）→ 造价

这个模型的核心假设是：功能规模和工作量之间存在一个相对稳定的转换关系，可以从历史数据里归纳出来，形成基准。即：各种软件研发的生产率数据。

现在的问题是，这个“生产率”的稳定性正在瓦解。

同样100个功能点的系统，一个大量使用AI辅助开发的团队和一个纯人工开发的团队，实际工时可能差距悬殊。

更麻烦的是，差距的方向不是线性的——前面提到的那篇论文给了一组反直觉的数据：

传统上标注为”高复杂度”的任务，78%在LLM辅助下只消耗了预期人工工时的25%以下；但传统上标注为”低复杂度”的任务，约22%实际消耗了预期工时的180%以上。

难的变容易了，容易的变难了。

这意味着历史积累的生产率基准，正在局部失效、不均匀失效、方向不可预测地失效。

五、模型需要演进

在传统估算模型里，至少需要补充几个新的维度：

这个项目里AI介入的程度和方式是什么？

哪些功能点对应的任务是AI擅长处理的标准模式，哪些是需要大量人工验证的遗留系统集成？

验证和纠错的工时有没有独立核算，还是被淹没在”开发工时”这个大池子里？

我们需要建立一套新的成本动因分析框架，才能校准模型。

尾声

回到最开始的那个问题：AI时代，我们更忙了还是更闲了？

忙的人更忙了，因为他们在用AI生成代码的同时，还要验证、纠错、处理AI引入的新型问题，而这些工作没有历史基准，也没有行业标准，无从定价，只能自己扛着。

闲的人也有，他们跳过了验证，接受了AI生成的一切，然后把问题留给了上线之后。

区别在于有没有人真的在管质量。