用了十几年的估值模型，正在被 AI 拆掉地基type
Post
status
Published
date
Aug 1, 2026 06:28 AM
slug
content-3f9a2b7c-1e4d-4a6b-9f8e-2d5c6b7a9e0f
summary
从南京江北一场洽谈会上连夜拼出的 Excel 小工具，到《怪兽评估》里的原生估算沙盒，这是一段真实的工具进化记录。而当 AI Coding 开始动摇 COCOMO II 的底层假设，故事的结尾变成了一个新问题：当代码不再等于成本，评估师的不可替代性在哪里？
tags
工具
开发
分析
技术
价值评估
category
技术分析
icon
password
评估师干久了，往往会形成一种直觉：哪些资产"好估"，哪些资产"难估"。
厂房、设备、存货都摆在眼前——数得清、看得见，心里有底，但软件项目不一样。
它没有物理形态：代码量、架构复杂度、团队能力、技术债务……每一项都像水面下的冰山，只能靠经验和判断去摸。
更要命的是，还得在客户面前，把怎么"摸"的过程讲清楚、讲服人。
而这两年，AI 又给这潭水添了一层新的迷雾：连"代码量"这个最像实物的锚点，也开始靠不住了。
下面这件事，就是我们把一个软件评估工具从 Excel 一路集成到《怪兽评估》原生功能的真实记录。没有大道理，也没有什么理论框架或方法论，就是一步一步走到了今天。
只是走到最后才发现，脚下的路基已经开始变了。
一、逼出来的"南京江北急救包"
这个功能的起源，要追溯到南京江北新区的一次项目洽谈会。那是一个周五的上午，议程拖得有点长，会议室里人进人出。客户在一间小会议室里把材料摊开，逐个介绍项目：做了哪些研发创新，包含哪些功能点。
气氛很和谐。客户既没有压价，也没打算为难谁。但聊到最后，话题还是落到了"技术怎么估"上——他们点了几个信息化系统的名字，想听听大概会怎么估，依据是什么。
"你们这个估值，大概怎么算出来？"
我们手里当然有东西：那套被视为"最权威之一"的 COCOMO II（构造性成本模型） 计算表。
模型很经典也很严密——从 COCOMO 81 演进到 COCOMO II，行业内一直沿用至今；
它需要引入 17 个成本驱动因子（可靠性要求、开发人员能力之类），再一层层折算出工作量。
但问题不在"有没有模型"，而在"能不能在现场用起来"。
那张全功能 Excel 表密密麻麻全是公式、嵌套和查表。
如果当着客户的面一项项敲参数、翻说明，效率低是一回事；更麻烦的是，客户看着你在 Excel 里戳来戳去、听不懂，原本顺畅的交流很容易被打断。人家是带着兴趣来了解的，总不能让人对着一屏公式发呆。
越复杂的工具，在现场越容易带来"低效与不信任感"——这是很多评估师都踩过的坑。
更要命的是，周五下午他们还有个重要会议，周一就要继续推进。
为了把这件事讲得更顺，我们几个人周末临时做了个"应急包"：
一个用 Excel 宏和 VBA 拼出来的单项目估算小程序。
想法很简单：把复杂计算过程藏到后台，把简单留在前端。
我们把 17 个成本因子收敛成几个更容易解释的选择项。
评估师在现场用滑块、下拉菜单走完一遍，几分钟就能得到一个相对合理的区间；
同时还能把"底层为什么这样算"翻译成客户听得懂的话。
临时拼出来的东西谈不上产品，却真救了急。
项目拿下来了，我们也第一次尝到"快速估算沙盒"的甜头——它未必最精确，但在沟通里很有用，能把讨论继续往前推。
二、搬家：从 Excel 插件到《怪兽评估》
江北项目结束后，这个小工具的使用场景并不多，大家也只是偶尔用一下。更麻烦的是，用的时候常常找不到它存在哪里——散落在个人电脑的某个文件夹里，成了离散的私有资产。
后来做《怪兽评估》的产品化时，给它安了个正规的"家"。
重构成软件里的原生功能后，它的定位就很清楚：
不取代那份贴满代码截图、框架占比、严密公式的"终极 Excel 评估底稿"；它只服务一个场景——评估师在一线跟客户对齐范围时的"早期估算沙盒"。
因此界面很"傻瓜"，操作也快，整个流程是向导式的：
- 内置"代码去水"滑块：评估师不用手动剔除框架代码。系统底层预设了不同技术栈的"代码自动生成因子"和"复用比例"，点击滑块，底层就自动折算出更接近真实业务代码的规模。
- 行业基准一键预设：把学术名词翻译成更直白的选项。即使不懂技术的评估师，也能先拉出一个符合行业均值的估算区间，再在沟通中逐项修正。
如此"虚实结合"，也算是我们软件功能设计的一个逻辑闭环了。
三、那个"定格 5 秒钟"的瞬间
功能搬进《怪兽评估》后，还有一个意外的收获：它成了新人的"无痛通关指南"。
软件估值还是太专业了，新入行的评估师第一次面对模型，常常是懵的。
为了搞懂，很多同事会把软件里的这套向导当成"学习机"：点击滑块，看区间变化，再回头看参数说明，慢慢把逻辑串起来。
公司里有个特别认真的同事，第一次接手软件评估项目。她盯着《怪兽评估》的界面，顺着滑块、参数说明和交互提示，把底层的计算逻辑一点点抠出来。
然后，她回到 Excel 里，重新一行一行手写了一套一模一样的计算表。
项目做完那天，她把电脑端到我面前，语速很快，眼睛放着光："你看！我根据咱们软件，自己用 Excel 把这套模型给手工复现出来了！"
我顿了一下，抬手指了指公司的云端知识库：
"其实……咱们知识库里一直有一份那份完整的 Excel 计算底稿模板，直接下载就能用。"
那一瞬间，她脸上的兴奋和自豪像被按住了一样，定格了大概 5 秒钟。
但 5 秒钟后，她眨了眨眼，声音还是很有力，像是在给自己找台阶：
"那不一样！至少我通过看软件自己推导了一遍，我现在比别人更懂这个模型！"
这个插曲有点让人哭笑不得，但也把一个事实摆在那儿：再权威的论文、再严密的 Excel，也比不上一个好用的界面。 对新人来说，公式是抽象的；界面是可操作的。滑动、对比、回看说明的过程，会把"开发难度""人员经验"这些原本写在书里的变量，变成能直观看见的变化。
四、时代变了：AI Coding 来了，模型还准吗？
如果说工具的升级，只是在挤压"低效作业"的空间；那么这两年技术的巨变，动摇的是估算模型脚下的地基。
说这两年软件圈发生了"巨震"也不夸张。
AI Coding（Cursor、GitHub Copilot 以及各种 AI Agent）成了很多团队的日常工具。现在再看自己手里那套经典估算模型，会发现一个尴尬的问题越来越难绕开：
COCOMO II 默认的前提——"人工工时与代码规模大体正相关"
但这一切在 AI 的介入下开始不那么坚挺了。
过去，程序员敲出 1000 行健壮的业务代码，可能要一周；现在，在 AI 辅助下，从自然语言提示词（Prompt）到生成 1000 行代码，可能只要几秒钟。代码行数变得更像"产物"，而不是"成本"。
当"人月"不再能直接等同于开发成本时，软件还怎么估值？当核心假设被底层技术松动，我们沿用了十几年的经典公式，也需要重新校准自己的适用边界了。
写在最后
回头看，从南京江北那场紧急手制的 Excel 小工具，到《怪兽评估》里"虚实结合"的估算沙盒，再到新人借它完成软件估值知识的自我启蒙——
一个优秀的工具，不能只是公式的搬运工。它也许并不全能，但在某个特定的场景中，能够出色地完成任务，让我们的工作更加丝滑。
只是，面对越来越陡峭的技术曲线，有个问题值得每个评估师留在心里：当工具越来越傻瓜、经典模型越来越吃力时，我们真正的"不可替代性"，究竟在哪里？