AI软件,应该如何度量规模?如何评估工作量与造价?

最近一年，我被客户问得最多的问题：

“AI软件/智能体，到底应该如何计数功能点？”

以及：”用了AI编程以后，开发效率提高了多少？”，

“软件项目是不是应该更便宜了？”等等

前段时间，一家金融机构咨询我们，希望开发一个”尽职调查”智能体。

需求：业务人员输入一家企业名称，系统自动完成工商信息查询、司法诉讼检索、新闻舆情分析、关联企业识别、风险判断，最后生成一份尽职调查报告。

在LLM横空出世之前，所谓的传统软件时代，尽调软件本质是”流程 + 文档 + 规则引擎”的组合——它帮人管理和检索资料，但”读懂材料、做出判断”仍是人的活；

LLM时代则把”理解、抽取、比对、初步判断”这部分认知工作也交给了模型，软件从”辅助工具”变成了”能出初稿的分析助手”。

那么，它的规模应该如何度量？工作量应该如何估算？造价又应该如何确定？

我思考并与AI讨论以后，发现：这已经不是一个估算技术问题，而是在追问一个更基础的问题：

AI时代，我们到底应该如何理解”软件功能”？

一、一篇论文，让我开始重新思考

最近，我读到 Frontiers in Artificial Intelligence 上的一篇论文：《Toward LLM-aware Software Effort Estimation: A Conceptual Framework》。

论文讨论的是软件造价领域正在面对的一个现实问题：随着LLM越来越多地参与软件开发，传统的软件开发的成本结构已经被改变；传统的工作量（COCOMO，功能点，故事点）估算模型已经开始失效。这是“结构性”而非”参数性”问题。

作者认为，过去程序员的大部分工作量花在编码上；而今天，越来越多的时间消耗在Prompt设计、模型验证、结果审查、安全检查以及人工监督（Human Oversight）上。因此，传统”功能规模→工作量→成本”的估算模型，需要增加新的成本动因。

插一句：国际上已有实验发现，在某些场景下（如资深开发者维护自己熟悉的成熟代码库），AI 辅助不仅没有提效，反而因验证和纠错开销导致效率下降。这说明 AI 的效率影响高度依赖场景，”更快、更便宜”并非普遍成立。。

这篇论文还是处于概念阶段，只是给出了一个新估算模型的设想。

读完了论文后，我的问题还是没有解决。

如果软件功能本身已经发生了变化，那么我们应该度量规模、估算工作量？

二、功能点，多年来为什么能够成立？

在前LLM时代，软件功能规模度量领域，功能点分析（FPA）几乎一直占据着主导地位，并延续了四十多年。

其背后的原因是——功能点分析的哲学基础——还原论（Reductionism）。

所谓还原论，就是认为：一个复杂系统，可以不断拆解为一系列更小、更基本的组成部分；理解了这些基本组成部分，也就理解了整个系统。

这种思想几乎贯穿了现代科学的发展。

物理学把物质拆解为分子、原子和基本粒子；生物学把生命拆解为器官、组织、细胞和基因；软件工程同样如此，一个大型ERP系统可以拆解为采购、销售、库存、财务等模块，每个模块又可以继续拆解为一个个独立的业务功能。

对于那个时代的软件系统而言，其能够提供确定性的功能，所以可以不断拆解为一系列基础功能组件（BFC），每个组件都有相对稳定的规模，而整个系统的规模，则等于这些基础功能规模的累加。

基于这个理论，我们才能统计和分析“生产率”基准，才能预测未来项目的工作量。

过去十多年，我们在国内不少企业推进基于功能点的估算体系建设，积累的大量实践数据，也不断印证了这套理论在传统软件中的有效性。

三、AI-native的软件有什么特点？

仍然以“AI尽职调查”为例。

按照传统方法，我们可以把系统拆成企业信息查询、司法查询、新闻查询、关联企业分析、风险评分、报告生成等几十个功能。

但是，对于业务部门来说，他们的实际需求就是：

输入一家企业，生成一份可靠的尽职调查报告。

智能体如何规划、如何推理、调用哪些工具、经历多少轮思考，用户并不关心。

他们关心的只有一个：目标是否有效地完成。

当软件开始围绕”目标“，而不是”事务“组织能力时，传统的基于事务的拆解方式开始变得越来越困难。

四、软件工程正在遇到两种不同的智能

人工智能历史上的两大学派。

一种符号主义（Symbolicism）。

它认为，智能来自规则。

只要把足够多的知识表示成规则，机器就能够完成推理。

二十世纪的软件工程几乎完全建立在这种思想之上。

程序员不断把业务规则翻译成程序，因此软件本质上是一套规则系统。功能点分析能够成立，也是因为这些规则可以不断拆解、不断计数。

另一种连接主义（Connectionism）。

它认为，智能并不是来自显式规则，而是来自大量神经元连接形成的统计学习能力。

今天的大语言模型正是连接主义最成功的成果。

它并没有把”如何完成尽职调查”写成几百条业务规则，而是通过模型训练、上下文理解、知识检索和推理过程，最终完成整个业务目标。

于是，软件能力开始发生变化。

传统的软件能力来自规则。

AI-native的软件能力，越来越多地来自推理。

五、也许，我们需要重新理解”功能”

如果继续沿着这个思路思考，一个更加有趣的问题出现了。

过去的软件工程，默认认为软件规模可以不断拆解，再不断累加。

但是AI Agent开始表现出另一种特征。

它真正的价值，并不来自CRUD，也不来自某一个接口，而是来自整个推理过程形成的整体能力。

哲学上，称为整体论（Holism）。

整体论认为，整体并不只是部分的简单相加，而会产生新的能力，这种能力无法完全还原到任何一个组成部分。

如果把这个观点放到AI软件中，我们会发现，一个Agent真正提供给用户的，往往不是几十个独立功能，而是一种完成业务目标的综合能力。

这或许意味着，未来的软件规模度量理论，除了继续度量规则世界中的基础功能组件之外，还需要探索如何度量一种新的软件能力（Capability）——一种面向业务目标、通过推理完成任务的整体能力。

小结

目前看来，未来的软件系统很可能同时包含两类能力。

第一类，是建立在符号主义基础上的确定性功能。它们对应明确的业务规则，具有稳定、可重复、可验证的行为特征。这类功能，无论是否使用AI辅助开发，仍然完全可以采用功能点分析进行规模度量。

第二类，则是建立在连接主义基础上的AI-native能力。它们更多表现为一种面向目标的推理能力，其内部实现并不是显式规则，而是模型推理、知识检索、工具调用以及上下文协同。

对于这一类能力，我们今天仍然缺少一套成熟的软件规模理论。

也许，未来真正需要回答的问题，不再只是：

AI软件应该如何估算工作量？

而是：

AI软件本身，究竟应该如何定义”功能”，又应该如何度量”能力”？

目前，业内还没有统一答案。

但我相信，这很可能会成为未来几年软件工程、软件造价以及功能规模度量领域最值得研究的问题之一。