ARTICLE · 1279419
人工智能时代,软件开发成本度量新范式
从"人天计价"到"价值计价"：当代码生产成本趋近于零，我们该如何度量软件的成本与价值
摘 要
以大语言模型（LLM）为代表的生成式人工智能正在重塑软件生产函数：代码生成的边际成本大幅下降，开发效率提升数倍，传统以"人天/人月"为核心的成本度量体系正在失去解释力。本文系统梳理了传统软件成本度量范式（COCOMO II、功能点、故事点）的理论基础与失效逻辑，提出面向 AI 时代的成本度量新范式——以"提示工程与上下文构建成本 + 智能体运行成本 + 人工验证与治理成本"为核心的三元成本模型，并给出可落地的度量指标体系、企业实施路径与风险讨论。
关键词：软件成本度量；大语言模型；AI 辅助开发；功能点分析；智能体；软件工程经济学
2023 年以来，GitHub Copilot、Cursor、Devin 等编码智能体快速普及，多家企业的工程效能报告显示：在标准化程度较高的任务（单元测试、样板代码、CRUD 接口）上，AI 可完成 40%~70% 的编码工作量。2025 年后，随着代码智能体（Coding Agent）能够自主完成"理解需求—规划—编码—调试—提交 PR"的完整闭环，软件开发正在从"人类逐行编写"转向"人类意图驱动 + AI 批量生产 + 人类审核把关"的新模式。
这一转变带来一个根本性的经济学问题：当"写代码"的边际成本趋近于零时，软件的成本结构发生了什么变化？我们又该用什么尺度去度量它？
经典的软件工程经济学建立在"人力是主要成本"这一前提之上：Barry Boehm 的 COCOMO 模型以代码行数（KLOC）预估人月，IBM 的 Albrecht 功能点分析以功能复杂度折算工作量，敏捷团队用故事点做相对估算。这些方法在过去五十年行之有效，但它们有一个共同的隐含假设——代码是由人的工时生产出来的。AI 时代，这个假设正在瓦解。
本文尝试回答三个问题：传统成本度量范式为何失效？新的成本结构是什么？企业应如何建立可落地的度量体系？
2.1 规模度量：从 KLOC 到功能点，再到故事点
软件成本度量的第一性问题是"度量什么规模"。三代主流方法各有其度量对象：
失效逻辑一：生产函数失配。COCOMO 类模型的本质是"规模 → 人月"的回归映射。当 AI 使同等规模代码的生成时间下降一个数量级时，模型中的生产率系数（Productivity）不再是常量，而是任务类型、上下文质量、模型能力的复合函数。用 1990 年代的系数校准 2026 年的生产率，得出的估算可能偏差 3~10 倍。
失效逻辑二：规模本身变得廉价且虚高。AI 生成代码的"规模通胀"现象已被多项研究观察到：模型倾向于生成冗长但可用的代码，且脚手架、测试用例、文档的生成几乎零成本。以代码行或故事点作为计费与预算依据，会系统性高估交付物的经济价值。
失效逻辑三：成本重心迁移。行业观察显示，AI 时代开发者的时间分配正在从"编码"（传统占比约 40%）转向"提示与上下文构建"、"AI 产出审核"与"修复 AI 引入的隐性缺陷"。成本不再均匀分布在编码工时上，传统工时归集方法失去了颗粒度。
一句话总结：传统范式度量的是"人写了多少"，AI 时代需要度量的是"人指挥 AI 生产了多少、并为之承担了多少验证责任"。
基于对 AI 辅助研发流程的解构，本文提出三元成本模型（Tripartite Cost of AI Development, TCC），将软件交付总成本重新定义为三部分之和：
软件总成本 C = Cp（生产成本）+ Cv（验证成本）+ Cg（治理成本）
Total Cost = Production + Verification + Governance
3.1 Cp：生产成本——从人天到 Token
生产成本指"让 AI 产出可用代码"的直接投入，包含三个可计量维度：
- 算力与 Token 成本
：模型调用费用、智能体运行时长、基础设施开销。这是唯一随用量线性增长、可精确到分的成本项，天然适合"按量计费"。 - 提示工程与上下文构建成本
：编写需求描述、设计规约、维护知识库与规则文件（如 AGENTS.md）、构建 RAG 索引的投入。这是新范式中最关键的隐性成本——上下文质量直接决定 AI 产出的一次通过率。 - 迭代轮次成本
：一次任务从发起到验收的平均 Agent 循环次数。轮次越多，算力成本与人工等待成本越高。
3.2 Cv：验证成本——新范式的人力重心
AI 把"写"的成本转嫁为"审"的成本。验证成本包括：代码评审中判断 AI 产出正确性、安全性与架构合理性的工时；为 AI 生成代码补齐测试的成本；以及修复"看似正确实则错误"（Plausible but Wrong）产出的返工成本。实证数据显示，AI 代码的评审耗时可比人写代码高 20%~50%，因为评审者需要同时理解代码本身与生成该代码的意图链。
3.3 Cg：治理成本——被长期低估的部分
治理成本包括：AI 使用策略与合规审计、模型输出的知识产权与许可证风险排查、安全扫描与供应链治理、技术债的加速积累与偿还。在金融、医疗等强监管行业，Cg可能占总成本的 30% 以上，却几乎没有被任何传统模型度量过。
| Cp生产 | |||
| Cv验证 | |||
| Cg治理 |
TCC 模型的一个重要推论是：规模度量应从"产出规模"转向"意图规模"。可借鉴功能点"与技术无关"的思想，以"业务意图单元"（Intent Unit）——一段可独立验收的业务需求——作为规模单位，其成本不再是人月，而是上述三元成本之和。这使得"每功能点成本"重新变得可比较、可跨团队基准化。
新范式的另一转变是方法论层面的：传统估算（Estimation）是事前预测，而 AI 时代的成本高度依赖运行时可观测数据，应转向"观测驱动的事后核算 + 基于基线的滚动预测"。核心指标如下：
| 生产效率 | ||
| 成本结构 | ||
| 质量与风险 | ||
其中，一次通过率（First-Time-Through）是纲领性指标：它同时反映了上下文工程水平、模型能力匹配度与验证体系效率。FTT 从 30% 提升到 70%，往往意味着单位意图成本下降一半以上——这是上下文工程投入回报最直接的量化证据。
第一步：埋点与基线（1~2 个月）
在 DevOps 流水线与 IDE 层面接入 AI 使用数据（Token 消耗、采纳事件、Agent 轮次），结合需求管理系统建立"意图单元"台账，形成成本基线。
第二步：双轨并行核算（3~6 个月）
传统功能点/人天核算与新 TCC 指标并行运行，用历史项目数据校准两类模型的映射系数，识别成本结构迁移的拐点。
第三步：预算与计价模式切换
项目预算从"人月包干"转向"意图包干 + 算力弹性额度"；对外报价逐步引入"按交付意图单元计价"，将 AI 提效收益与风险在供需双方间合理分配。
第四步：组织与治理配套
设立上下文工程（Context Engineering）职能，将知识库与规则文件的维护纳入正式工作量；建立 AI 代码溯源与审计机制，控制 Cg的膨胀。
其一，成本下降不等于总成本下降。杰文斯悖论（Jevons Paradox）在软件领域同样成立：单位代码成本下降会刺激需求膨胀，软件总规模与总投入可能不降反升。度量体系必须同时监测"单位成本"与"总量"两条曲线。
其二，隐性成本难以货币化。上下文构建、团队学习、模型锁定（Vendor Lock-in）成本分散且滞后，需要长期跟踪才能准确归集，短期数据可能产生误导。
其三，责任归属尚无定论。当 AI 产出引发线上事故时，成本应归集于生产者（模型服务商）、指挥者（提示设计者）还是把关者（评审人）？这不仅是会计问题，更是组织设计与法律问题，本文的 TCC 模型提供了归集框架，但系数确定仍需行业实证积累。
其四，度量本身不要成为新的形式主义。指标体系的价值在于决策支持而非考核排名，应警惕"为度量而度量"重蹈故事点被 KPI 化的覆辙。
软件成本度量正在经历自 COCOMO 诞生以来最深刻的一次范式转移：度量对象从"人的工时"转向"人机协作的产出与责任"，计量单位从"人天"转向"意图单元与 Token"，方法论从"事前估算"转向"观测驱动核算"。本文提出的三元成本模型（生产 Cp+ 验证 Cv+ 治理 Cg）与配套指标体系，为企业提供了可落地的过渡框架。
更深一层看，成本度量的变革折射出软件工程本质的变化：当生产不再是瓶颈，稀缺的将是对问题的深刻理解、对质量的严格把关和对系统的长期治理。新的度量范式，度量的是人类在智能时代软件生产中不可替代的那部分价值。
参考文献（节选）
[1] Boehm B. Software Engineering Economics. Prentice-Hall, 1981.
[2] Boehm B, et al. Software Cost Estimation with COCOMO II. Addison-Wesley, 2000.
[3] Albrecht A. Measuring Application Development Productivity. IBM, 1979.
[4] GB/T 36964-2018. 软件研发成本度量规范.
[5] Ziegler A, et al. Measuring GitHub Copilot's Impact on Productivity. CACM, 2024.
[6] DORA. Accelerate State of DevOps Report. Google Cloud, 2024/2025.
[7] 中国软件行业协会软件造价分会. 软件研发成本度量相关行业实践报告, 2024.
