ARTICLE · 1055434
AI辅助开发、AI原生与传统开发的工程活动与成本结构差异
大模型进入软件工程领域后，"做一个软件项目"正在分化为三种形态：传统开发项目、借助智能编程工具并叠加AI能力的AI辅助开发项目，以及以大模型、智能体为核心底座的AI原生项目。对从事软件造价咨询、信息化项目造价咨询与投资评审的从业者而言，这不是概念之争——三类项目在工程活动与成本结构上的系统性差别，正在直接进入估算、概算、预算编制与财政评审的作业现场，而各省市现行费用测算文件绝大多数仍建立在传统开发口径之上。
本文立足造价咨询与评审实务，沿"工程活动"与"成本结构"两条主线，对照GB/T 36964-2018《软件工程 软件开发成本度量规范》的成本构成口径和十余个省市现行有效的费用测算文件，结合公开行业研究与会议分享的工程观察进行梳理。文中判断均为观察而非结论——AI类项目的工程数据目前主要来自实验室环境与国外文献，国内行业数据尚在积累，相关口径有待实践检验和动态修正。
传统开发项目的工作对象是确定性的业务逻辑：需求被逐条定义，代码实现功能，测试验证"功能是否符合需求"，上线即标志主体工作结束。现行各省市费用测算文件——如《海南省政务信息化项目投资编制标准》、湖南《省直单位政府投资信息化项目预算编制与财政评审工作指南（试行）》（湘财办〔2024〕10号）等——均以这类项目为基本测算对象，也是咨询机构编制估算、评审机构审核工作量时默认的口径来源。
AI辅助开发项目中，AI以两种方式进入传统软件：一是作为工具，以智能编程助手辅助编码、测试、文档等环节（行业公开的对照实验普遍显示编码环节效率显著提升）；二是作为功能，在原有系统上叠加大模型、智能检索、文字识别等能力。其业务主干仍是传统软件，工程活动序列未被重构。
AI原生项目则不同。按中国信通院《AI原生应用白皮书》（2025年）的界定，AI原生应用从产品设计、架构搭建、数据流转到业务流程，全程以大模型等AI能力为核心底座构建，而非在传统系统上叠加AI插件，呈现架构原生、交互原生、进化原生三方面特征。其产出物行为具有概率性——输出质量取决于数据、提示词与模型能力边界，而非完全由代码逻辑决定。需要说明的是，这类项目的工程活动数据目前主要来自实验室环境与国外参考文献，国内尚无可公开引用的行业基准数据，本文涉及的分布描述应在此前提下理解。
对咨询与评审作业而言，先判定项目属于哪一类是第一道工序：类型不同，适用的活动清单、工作量分布形态与成本科目口径都不同，用同一把尺子量三类项目，误差从起点就已埋下。
传统软件开发的活动范围在现行标准体系中有稳定表述。按GB/T 36964-2018确立的成本度量框架（经T/XJSIA 036-2025《定制化软件开发费用测算实施指南》等现行标准转引），软件开发工作量覆盖从项目立项到完成验收期间，针对功能性需求的需求分析、设计、编码、测试、软件部署及相关的项目管理、支持活动。海南、辽宁等地的省级文件口径与此基本一致，辽宁（辽财预〔2021〕54号）进一步明确各功能工作量包含现状调研、需求分析、软件设计、程序编码、软件测试、部署实施及质保期内的修改完善。这套清单有两个隐含前提：工作量的核心载体是代码；质量验证是确定性的——测试回答"功能是否正确、稳定"，结论非此即彼。
这份清单同时是造价作业中工作量计量的边界：功能点法与工作量估算法的范围认定、结算审核中"某项工作是否属于开发工作量"的争议裁定，均以此为据。后文两类新项目的差异，实质上是对这份清单的逐项改写。
行业会议分享的工程观察显示，AI辅助开发项目的活动骨架与传统开发一致，工作量分布出现两处可观测的变化：其一，编码＋集成仍是工作量最大的科目（约三成半），智能编程工具改变的是编码环节的内部效率，尚未动摇活动骨架；其二，活动清单中新增了两个传统项目没有的科目——数据准备与标注、AI效果评估，两者合计约占工作量的三分之一。对估算作业的直接影响是：沿用传统活动清单编制这类项目的工作量，将系统性漏掉两个真实存在的科目。
AI原生项目呈现另一套活动结构：需求与业务建模＋AI架构方案（业务意图拆解、智能体规划、能力边界、兜底策略、安全风控）成为最大投入；数据治理、知识库构建与评估集制作（文档解析、切片、向量化、清洗）紧随其后；AI专项评估与回归测试（幻觉、鲁棒性、边界用例，借助对抗样本、领域真值、A/B评测、阈值调优）独立成科。三类活动合计约占七成工作量；模型接入、提示词工程、智能体编排等开发集成活动代码量不大，仅占约两成；部署交付环节则强调模型服务监控与漂移监控。工作量的核心载体从"代码"换成了"数据＋模型行为"——以功能点或代码量为锚的传统计量方式，对这类项目的主体工作量基本"看不见"。
PS：比如我们开发运营的软件造价喵、AI询价喵就是这类AI原生系统。
对照之下，三点结构性差异最为关键：工作量载体不同（代码 vs 数据与模型行为）；质量验证逻辑不同（确定性测试 vs 概率化效果评估）；交付形态不同（一次性交付 vs 持续迭代闭环）。第三点直接决定了成本结构在运维运营阶段的分野，也是评审口径分歧最集中的环节。
三类项目的建设成本在现行文件中仍共用GB/T 36964-2018确立的四分类口径：直接成本（直接人力成本＋直接非人力成本）与间接成本（间接人力成本＋间接非人力成本）。软件开发费的主流测算路径是"工作量×人月费用单价"，间接成本与利润被打包进人月单价——海南口径为"包含直接人力成本、间接人力成本、间接非人力成本及合理利润（含税），但不包括直接非人力成本"（基准单价2.13万元/人月）；湖南基准人月费取15000元/月（湘财办〔2024〕10号）；无锡按23600元/人·月（2024修订版）。地域梯度与行业观察中"北上广深杭人月费率显著高于新一线、二线城市"的判断相互印证。
这套打包机制有一个关键特征：间接成本按"人"分摊，基数是人数，暗含的逻辑是"成本随人走"。评审人月单价时看到的是一个打包数，其内部结构是否合理，取决于项目的真实成本形态是否与"按人分摊"的假设相符——三类项目的成本差异，正是在这个底座上逐层展开。
AI辅助开发凭借智能编程工具压缩编码工时，直接人力的总量存在下降空间；但人月费率呈现明显的岗位分化：传统外包普通开发岗位费率涨幅有限甚至持平，上涨集中在AI架构、数据工程、AI评测、行业解决方案专家等岗位——人才供给短缺导致薪资溢价，政企、金融等高复杂度项目对高级别专家投入占比提升，进一步推高费率口径。现行标准已捕捉到这一信号：《数据资源建设费用测算标准》（T/SCSDSJFZYJH 027-2025）附录F中，机器学习和人工智能算法工程师单价为2.0万元/人月，与数据架构工程师并列全表最高档。由此形成一个需要避免误读的关系：人月费率上涨不等于开发效率下降——AI工具提升的是编码效率，而AI原生项目的难点在数据、评测与风险控制，这些环节仍需高价专家人力。评审作业中若只核总量、不看人员结构，两类性质相反的变化会相互掩盖。
间接成本是三类项目差异最集中、而现行科目体系覆盖最薄弱的部分。间接人力一侧：团队小型化与工具化可能摊薄按人分摊的管理与支持成本，但等级保护、数据安全、个人信息保护、AI安全评估等合规类第三方服务在增加，部分以人力服务形态回流。间接非人力一侧：出现了传统口径中不存在的新支出族——算力成本（GPU等硬件与资源）、大模型相关软件与授权、向量数据库及配套中间件、文档处理与数据工具、安全与审计软件；公有模型调用还带来按量计费的Token支出。这些支出的共同特征是随模型与业务量走，而非随人数走，以"人月单价"为载体时无从安放——项目的人减少而算力、授权、调用费上升，"人减"与"费增"在同一单价口径内对冲。评审作业中若仍按人数核对间接成本，将系统性漏掉这部分支出；这是观察现行测算口径适应性时最值得记录的变形点。
传统定制软件的运维费在现行文件中有成熟的比例口径：河南按开发费分档计取6%（简单）/10%（较复杂）/15%（非常复杂），超过15%即视为升级改造（豫财预〔2020〕67号）；太原按建设规模分档控制在8%～12%（并财预〔2019〕103号）；黑龙江规定定制开发软件运维不超过IT资产额的8%（黑财办〔2023〕17号）。
AI类项目的运行阶段呈现不同形态。行业观察显示，AI辅助类项目的年度运维人力成本可达建设费的一到三成，上限已明显超出传统定制软件的运维费比例区间；AI原生项目的长期运维（知识库更新、模型漂移治理、提示词迭代）通常占项目全生命周期总工作量的三到五成。其持续运营成本也超出传统运维科目：模型推理与向量存储费用、平台与授权年费、监控告警平台年费，以及知识库持续迭代、效果运维（收集Badcase、迭代提示词、定期重跑评测集）、模型监控运维等人力投入，另有模型微调、多模态能力、第三方知识库版权授权、高可用灾备等可选项。
现行文件并非没有呼应。《深圳市市级政务信息化项目系统业务运营服务预算标准（试行）》（深财审〔2023〕1号）已将"运营"与"运维"分设，系统业务运营服务单列业务分析运营、数据治理运营、安全运营等类别，按服务量折算人月计价；黑龙江运维标准亦将"运营"列为独立科目，纳入优化识别算法、数据挖掘分析等内容。对评审实务而言，运营科目分设意味着审查对象从"保系统可用"扩展到"保业务有效"，计价依据与工作量认定规则都需相应调整——这与AI项目"上线即运营"的形态在方向上是一致的。
盘点现行有效文件，AI相关成本已有若干落点：湖南省评审指南规定"无法采用功能点法评估的软件功能（如模型、算法、决策分析等），可采用工作量估算法"；《信息化项目造价咨询质量控制规范》（T/SCSIA 0016-2025）已将"算法模型搭建服务工作量明细表"列为独立附表类型；《数据资源建设费用测算标准》（T/SCSDSJFZYJH 027-2025）覆盖了数据购置（明确列举AI训练数据）、建库、加工与运维的全科目。缺口同样清晰：Token调用费、模型微调/训练费、算力资源费、AI专项评估工作量尚无标准科目与计价规则，实践中只能按市场询价、工作量估算或按量计费处理。对咨询与评审实务而言，当前可操作的思路是一种"两分法"——功能可计量的部分沿用功能点法，模型与资源消耗部分单列询价；编制与审核双方应在估算阶段就明确各部分的计价路径，避免结算时口径回溯争议。
第一，数据基础在快速演变。本文引用的AI类项目工程活动分布来自实验室环境与国外文献，样本多出自特定团队的特定项目而非完全生产环境；随着国内样本积累，分布形态与费率水平都可能改写。第二，工具能力仍在爬坡。智能编程工具的提效幅度、智能体编排的工程化成熟度都在快速变化，今天观察到的"编码占比下降、评估占比上升"是演进中的截面而非终态。第三，测算标准将持续跟进。从运维费比例口径到运营科目分设，从模型算法工作量估算到算法模型工作量明细表独立成表，现行文件对AI类成本的覆盖正逐版加密；在更系统的测算规则形成之前，"功能点法＋市场询价"的两分法是现实可行的过渡安排。
结语：三类项目的分野，表面是工程活动的此消彼长，实质是成本载体从"人"向"人＋数据＋模型＋算力"的扩展。对造价咨询与投资评审从业者而言，现阶段值得做的不是等待新口径落地，而是在既有四分类框架内逐项追问：这个项目属于哪一类，间接非人力成本里出现了哪些新科目，运维运营阶段的钱花在了哪里——每一份带着这些追问完成的估算书与评审意见，都是下一代测算规则的素材。
行业洞察 | 作者长期从事软件造价咨询、信息化项目造价咨询与投资评审工作
文中引用文件均为现行有效版本，数值以原文为准；AI类项目工程活动与运维数据源自行业会议分享材料（实验室环境与国外参考文献），仅供观察参考
