ARTICLE · 1241170
当AI重构软件工程:为什么传统“功能点”和“代码行”在失效?
当AI重构软件工程:为什么传统“功能点”和“代码行”在失效?在一些主流的智能体项目中，系统的表象极其简单：用户打开界面，只有一个空荡荡的对话框，或者干脆连独立的对话框都没有，仅仅是几个隐藏在后台的API接口、输入与输出，无缝嵌入在现有的业务系统中。 然而，在那个看似平平无奇的对话框背后，真正的核心资产是完全不显山露水的： 复杂的提示词工程（Prompt Engineering）与迭代调优 多模型路由（Failover）与混合大模型调度架构 海量私有数据的RAG（检索增强生成）知识库与向量化清洗 多智能体（Multi-Agent）之间的复杂意图拆解与协同工作流 当我们将这个方案提交给传统的造价咨询或审计专家时，对方拿着标准的软件造价指南开始犯难了。按照传统功能点分析（FPA）的核心要求，计算规模必须基于“外部用户可识别的业务功能（如外部输入、输出、查询、逻辑文件等）”。 这就陷入了一个巨大的悖论：用户在前端根本无法感知、也无法识别智能体的内核逻辑，传统功能点法根本“数”不出这些看不见摸不着的算力与算法资产。拿一把量“古法编程”的尺子，去量AI智能体的三围，注定只能量出一地鸡毛。 
我们现在常说的一句流行语叫“古法编程”。什么叫古法编程？就像传统手艺人做手工面一样，一行代码、一个函数、一个模块，全靠程序员纯手工“揉”出来。在那个时代： 工时与代码量线性相关：代码行数（LOC）越多，代表业务逻辑越复杂，耗费的人力工时就越多，造价也就越高。 规则边界清晰：输入什么、输出什么、走哪个If-Else判断，逻辑是确定性的、可审计的。 然而，大模型和AI原生应用的出现，彻底砸掉了“古法编程”的饭碗： 生产效率百倍跃升：在 Cursor、Windsurf 以及各类大模型辅助下，过去需要一个团队干两周的增删改查（CRUD）和接口联调，现在一个人喝着咖啡几分钟就能生成。 从“编写代码”到“架构对齐”：今天的软件工程瓶颈，早已经不是“代码怎么敲”，而是“业务怎么定义”、“大模型怎么对齐”、“幻觉怎么纠错”。 当生产力范式发生了断层式跃迁，继续用“古法编程”的逻辑去套算AI智能体项目，不仅会导致预算严重失真，更会让真正的大头投入（如大模型API采购、向量数据库、提示词调优与评测成本）无处安放。 这种新旧交替的阵痛，在当下的政企信息化和系统集成项目中撕裂得格外明显： 对乙方（开发商与集成商）来说：做了一个极其惊艳、能帮客户降本80%的AI智能体系统，结果因为界面简单、前端功能点少，在按传统功能点和人月报价时被砍得体无完肤，欲哭无泪。 对甲方与审计部门来说：面对供应商花样百出的报价单，由于没有现成的定额标准，既不敢轻易批钱，又怕被质疑“花冤枉钱”，最后只能用一句“缺乏依据”将创新项目生生卡死。 AI智能体不是传统软件的“补丁”，而是软件工程的一次物种大爆发。如果我们继续用“古法编程”的旧标尺、用功能点法的旧思维去框定今天的AI项目，不仅会窒息技术创新，更会让无数企业在数字化转型中迷失方向。 在接下来的专题中，我们将彻底抛弃这些过时的旧地图，深入探讨在AI智能体与RAG项目中，全新的成本解剖图究竟该怎么画，如何用“Token经济学”和算力开支配比重构我们的造价逻辑。 敬请持续关注《AI造价助手》，让我们一起打破旧框框，看清AI时代的真账本！
导读
前阵子，我在参与一个智能体（Agent）建设项目时，遇到了一件既好笑又无奈的事：会上，有专家斩钉截铁地提出：“这个项目虽然听起来很潮，但归根结底还是软件开发，须严格按照传统的‘功能点法（Function Point）’来评估项目预算和工作量。” 这让我哑然失笑。当我们将过去靠程序员一行行手敲代码、纯靠人肉堆工时的传统开发戏称为“古法编程”时，那些还拿着“农耕时代造价尺”去量AI新世界的专家，究竟错在了哪里？
一、 真实案例：当“古法造价”遇上“AI黑盒”
