大模型兴起以来，风起云涌，卖卡的、卖数据的、卖模型的、卖应用的、卖知识变现的。。。各种推手暗流涌动，轮流登场，特别是在软件开发领域，更是风起云涌，甚至有人提出大模型替代程序员的说法，那可是把焦虑感贩卖得满满的，恨不得把韭菜连根一把割光。
尽管割韭菜的刀法各不相同，但是万变不离其宗，任何新技术、新方法、新平台本质看从内往外分都会分为：功能核、边界、广告三部分。
大模型编程也不例外，从目前各家实践来说，大模型在编码提效上确实有效，但是广告成分也挺高。
既然是提效，一定要目标牵引。
在目标设定上，大家谈的最多是第一性原理，目标能不能量化？目标跟业界对标怎么样？目标所处的位置具体在哪？目标可以分解成哪些部分？目标每一部分是怎么来的？
下面我们从上述维度看看大模型软件开发提效的目标和度量手段到底有多少。
首先我们先统一语言：
1、编码提效率=大模型编码节省时长/总编码时长
2、代码采纳率=git提交代码中大模型生成的代码/git提交代码*100%
通过莱文斯坦相似度（0.9）比较获取该数据。
3、通用知识折算率=通用知识占比+私域知识占比*私域知识转化率
接着，我们通过采用内部5个项目一个季度的穿刺数据来分析，其中采样数据满足：
1、项目要求百人以上
2、能够端到端交付
3、包含c/c++、java、python、go、scala、js/ts等主流编程语言
4、穿刺代码和模块通过业务剥离的方式，传递给大模型处理的仅包含通用知识。
编码提效率和代码采纳率：
chatGPT3.5 | 代码采纳率 | 大模型编码提效率（节省开发时间占比） |
项目1 | 64% | 42% |
项目2 | 67% | 35% |
项目3 | 41% | 23% |
项目4 | 34% | 46% |
平均 | 51.50% | 36.50% |
从数据看，通用知识的代码采纳率可以达到51.5%，同百度2023年6月份的采纳率数据对比看：
我们的数据跟百度数据基本接近，相对靠谱。
通用知识折算率
还有一个问题，我们实际真正大规模使用大模型编程时，需要生成的代码课时需要同时包含通用知识和私域知识，这将对采纳率和节省时间这两个数据造成一定的折扣，下面我们就分析这通用知识在真正系统中的占比：
| 项目 | 模块 | 大模型类型 | 私域代码占比 | 私域知识代码转化率 |
| 项目1 | 模块1 | chatGPT3.5 | 50% | 30% |
| 项目2 | 模块2 | chatGPT3.5 | 30% | 20% |
| 项目3 | 模块3 | chatGPT3.5 | 30% | 30% |
| 项目4 | 模块4 | chatGPT3.5 | 30% | 30% |
| 项目5 | 模块5 | chatGPT3.5 | 20% | 30% |
| 项目6 | 模块6 | chatGPT3.5 | 10% | 10% |
| 项目7 | 模块7 | chatGPT4 | 10% | 10% |
这块数据不好统计，我们针对主要项目的核心模块进行了分析和统计，可以看出私域知识最高占比50%，也就是说通用知识占比不低于50%。
又可以看出私域代码转化率最高30%，我们按30%进行估算，根据通用知识折算率=通用知识占比+私域知识占比*私域知识转化率=50%+50%*30%=65%。
模型折算率
还需要解决一个问题，我们穿刺时使用的chatgpt3.5，开发人员大规模使用时是自研的编码大模型，chatgpt3.5取得的效果能否在自研大模型上获得对应呢？
23年12月chatGPT3.5 （135b）humaneval@1评分65%，当前内部大模型 （70b）humaneval@1评分75%，考虑内部大模型语义理解力不如chatGPT3.5，但是编程能力略升，加上内部大模型增量预训练全部的私域代码和文档，加上我们实际评测（私域代码评测集通过率35%，大于chatGPT的20%），在内部编码能力这个单点上，基本可以认为内部大模型和chatGPT相当，即模型折算率=1。
开发工时占比
另外，软件编码在整个软件研发工作量占比是多少呢？
从若干项目实际研发数据（细节不便展示）统计分析，编码阶段占比30.77%，考虑到开发阶段还有其他一些工作，比如详设、验收测试、集成测试、环境搭建、版本联调等，根据我们的经验，真正编码自测试大概占三分之二的时间，这里我们取编码阶段在整个项目周期的工时占比为20%。
tips：
这个值其实影响因素挺多的：
1、是否为成熟项目？
成熟项目代码变化较少，需求，设计和开发波及影响分析和验证工作量占比会较高。
2、是否为大型项目
我们都知道，软件开发本质是开发人员大规模手工协作的一种工作方式，所以项目规模越大，协同和对齐的点越多，造成集成工作量越大，从而导致编码的工作量占比降低。
一般大型项目（纯业务代码百万行以上，框架和开源组件不计算在内）开发阶段工时占比30-40%；
小型项目一般能在50%或以上。
3、是不是强依赖硬件或三方平台
如果强依赖硬件和三方平台，所谓强依赖是指依赖点特别多，依赖程度大。
其中，
依赖点指的是API、数据类型，还包括隐形知识等。
依赖程度指被依赖方微变更对依赖方波及影响大。举个例子，比较桥梁某个桥墩断了，桥虽然不安全了，但还是能够勉强通行。如果一条高速路路面塌陷，交通基本就断绝了，我们可以说路面比桥墩依赖程度大。
强依赖加上没有做好很好的依赖解偶和mock框架，那反复集成的成本会高很多，也会造成编码在整个研发过程中工时占比过低。
提效延迟因子
还需要考虑一个问题，即提效延迟因子，即对全年来说，提效斜率如下分布:
1.起步阶段
一季度是方法推广、工具开发、基础设施建设、人员能力提升等。
2.加速阶段
二季度开始高速提升
3.高产阶段
三季度真正到了高产期
4.持续阶段
四季度需求和交付相对较少
简化考虑下，从全年看，头尾提效斜率较平缓，2-3季度是高产期。全年提效延迟因子简化成0.5。
相应提效指标如下：
1、开发阶段提效率=编码提效率*通用知识折算率*模型折算率*延迟因子=36.5%*65%*100%*50%=11%左右，挑战15%。
2、全年开发人员提效率=开发工时占比*开发阶段提效=2.2%*11%=2.2%左右，挑战5%。
3、新增代码累计采纳率=穿刺代码采纳率*通用知识折算率*延迟因子=51.5%*65%*50%=16.5%，这是对应2.2%的采纳率，要达到整体提效5%，采纳率挑战33%（这个指标一定不能用来考核，否则开发人员会有各种各样的优化方式，甚至超过80%都毫不费力）。
综上，大模型在软件开发提效上有效果，但是效果既不像大家想的这么小，也不像大家想得这么大。我们实际测算（大规模成熟嵌入式开发类型项目中）在开发阶段挑战15%，在全流程中调整5%，与之对应代码采纳率挑战33%而已。
当然，对应上万开发人员的组织来说，开发阶段提效15%，开发阶段也有1500人的对应的效果，软件开发主要成本不就是人员吗，还是挺可观的。
