大模型兴起以来，风起云涌，加之各种推手或明或暗推波助澜，那可谓时来天地同协力，深刻搅动了各行各业特别是软件行业的方方面面，共同的认知的是不远的将来，代码都可以被大模型自动生成了，那代码的生产者到底会不会从碳变成硅？程序员会不会成为减负增效的对象？
（森林里碰到熊，换上钉鞋到底是要跑过熊，还是要跑过其他同行的人？）
相信大家看完这篇文章，心中一定会有自己的答案。
大家都知道，任何一个新的技术（方法、流程、模式、工具）产生的时候，其影响往往都会被过度描述。
任何新的技术都会有三层结构，从里到外依次为：
1、核心特性
最有价值的部分，一般都伴随着巨大的创新，开拓新的局面，能解决使用者的关键痛点和遗留问题，并带来巨大确定性收益。
2、适用场景
任何一项新的技术都是有边界的，即适用的场景，也叫上下文或者局限。
在合适的上下文中，新技术解决问题的入手点一般都会有很强的针对性，也会有立竿见影的效果，投入产出比会相对很合算。
而在不适用的场景中，新技术的应用就比较将就，表现往往比较勉强，效果也很差强人意。如果大家看到过设计模式或者面向对象满天飞的代码，一定会有深深的体会。
当然，对于不同的新技术，适用场景边界大小也是不同的，对于有颠覆式的、引领时代级变更的新技术来说譬如大模型，适用场景也相对广泛的多。
3、广告
信息传播总会被放大甚至神话，加上相关从业者的推波助澜，更是会火上浇油，大家会趋之若鹜，群起参与。而群体有时表现的比个体更加不理性，相信读过行为经济学的同学都会深有体会。
对于任何新技术，大家一定要冷静分析，摒弃其广告部分，弄清其适用场景，了解它的核心特性，才能真正把新技术学好用好。
对于大模型在软件研发中的应用也一样，我们要先看看大模型在软件研发中的局限，这些局限有的来自于大模型自身特点导致的，有些是大模型应用对象导致的，还有些是使用者导致的。
它们分别是：
大模型自身局限
软件工程对大模型的局限
开发人员工作方式对大模型的局限
一、大模型自身局限
1、回答结果不稳定
大模型本质就是一个计算机程序，其核心是基于概率来补全文本。
大家如果调用过大模型的api，就会注意到有个temperature的参数，这是个0-1之间的值，越大表示大模型的输出越是趋于开放、更有创意，大模型发挥的联想和创新越多，相应输出篇幅也较大；越小表示大模型输出越是趋于保守、内敛，尽可能给出靠谱的回答，相应输出的篇幅也较小。
即使相同的temperature，每次的输入也可能有不同的输出，当然对于不同的大模型输出的稳定性也千差万别，比如chatGPT4的输出稳定性就非常好，相同问题相同temperature都基本会有相同的回答。
这就要求很多时候需要在大模型多次的输出中，选择一个相对靠谱的输出。
谁来选，当然是人了，即使通过算法或另外的大模型来选择，还是需要靠人来设计选择算法。
另外，从承担责任的角度，机器是没法坐牢的，只有人才能承担责任。关键责任总需要一个背锅侠。
从这个角度看，程序猿是不可替代的。
2、大模型会有幻觉（编造内容）
大模型的输出是基于概率的，相对来说不会有确定性答案，针对大模型不知道的问题，它有可能会编造内容并输出（看上图chatGPT3.5最初版本对林黛玉倒拔垂杨柳的描述）。当然，不同的模型在不同的场景下幻觉是不一样的。
所以对于大模型的生成的内容，必须要通过人工审核才能采用，从这个角度说，大模型的应用同样离不开程序猿。
3、输入输出最大token数受限
目前很多主流大模型的最大token数（输入+输出）都是4-8k，当然，有些大模型可以到达128k，听着不小了，对于一般的代码生成似乎是够了，但是一些编码中涉及的大文本场景还是不足的，比如：
大量私域业务知识通过prompt注入大模型时生成代码时，token很容易超限；
代码走查时，上下文相关输入代码量不能一次太多，必要时需要拆解成多个prompt多次输入，否则会超限；
根据用例生成代码时，用例行数过大导致token超限无法输入；
生成代码过长时输出token超限会被截断。
。。。
这时都需要程序员手工或通过规则算法来进行prompt拆解、分片输入、输出合并拼接、手工调整输出来等完成应用，这里程序猿还是不能被替代。
二、软件工程对大模型的局限
大模型编程只是对软件工程中基础编程能力的知识平权。
我们都有体会，很多多年工作的老程序员，对很多编程算法原理、实现细节、编译配置、常见故障分析定界定位、性能调优甚至编程语言层面的优化等这些基础编程能力很有经验，项目很多时候离开他们都无法运转，我们觉得他们是最不可替换的角色。
但是有了大模型之后，这些基础编程能力就被大模型平权了，借助大模型很多员工都可以掌握并依赖大模型输出来运用这些基础编程能力。
但是，基础编程能力并不能代表软件工程的全部，它只能带来局部效率的提升：
1、现在软件工程应对的是规模化场景下各种问题，编程只是其中的一小部分
软件工程需求从概念塑形-》需求分析-》系统设计-》编码自测-》单测/集测/系统测-》集成部署-》升级演进-》运维等全流程来贯通，尽管大模型可以对其中部分环节多多少少进行赋能，但目前主流实践效果看，基本还是在软件编码上效果比较明显，其他部分效果待展现，所以目前还只能说大模型带来的是软件工程的局部效能提升。
2、软件从业者往往高估了编程的复杂度，但却会低估功能与设计的深刻度
软件设计一般要考虑三个方面:
1）说清问题
说清问题是软件设计的基础，其一般又可以分为三步分别为：设计目标，约束条件，验收准则。
比如我们要做个市内滴滴打货的软件，很容易想到是:
a.设计目标
一般就是尽可能完成骑手和货物的运力撮合，使货物和骑手匹配度最大。
当然，如果你设定货主满意度要高，那设计方向就可能会不同，直接影响下面的约束条件和验收准则。
设计目标是纲，纲举则目张。
b.约束条件
i.safety（好事一定发生）
每单送货单最终都会被接单并被运送；
ii.liveness（坏事一定不发生）
接单/抢单失败一定不出现；
订单丢失重复或其他状态异常一定不出现；
运费支付错误一定不出现。
。。。
c.验收准则
非高峰期，3分钟内货单被司机接单；
高峰期，30分钟内货单要被接单（备选平台自备司机）
。。。
大家可以看到说清问题必须对场景有深入理解，也不是手到擒来的，还是有一定难度的。
2）建立模型
简单的问题怎么解决都可以，模不模型无所谓。但复杂的问题首先一定要有个模型，才能把问题表达清晰；其次有了模型才能使解决方案变得易于理解，从而才知道解的对不对（比如无锁队列，没有模型仅靠测试是无法说明实现的对不对的）；最后有了模型才确定好最合适的算法。
如何选择模型，那就需要对问题进行抽象，比如在RTB（实时广告系统）中，广告位数量和展示时间是非常有限的，如何尽可能多的播放高价值的广告；或者国家林业部门在资金有限的情况下，如何选择尽可能多的保护濒临灭绝的动植物物种组合等等，这些都可以抽象出背包模型。
3）选定算法
选择算法一般有两个维度，分别是算法速度和算法质量，对于同一模型，要依据使用场景，选择最恰当的算法，很多时候并不是最快或质量最高的算法，这才是最具挑战性的。
比如，对RTB场景下，整体展示的广告越多（即广告单价*播放广告数量）越有利，这就要求每个展示广告不光单价高，单位时间展示尽可能多的广告也是必要条件。如果片面追求算法准确度，每次都选取单价最高的广告播放，往往会造成用户没有耐心等到广告窗播放内容就跳走或者广告展示超时。这时候反而是贪心算法之类可以平衡速度和局部质量的算法，一般会成为优选。
而林业部门选择最优动植物物种组合时，不追求实时性，在一定的资金预算下，尽可能保护更多有价值的物种才是关键，这是算法最优（质量最高）成了首选，这时一般选择分支剪裁算法。
综上，设计深刻度反而比代码更重要，从这个角度看，大模型在基础编程能力的出色表现涵盖不了设计的深刻度，所以只能说是局部优化。
3、软件本质特性没有因为大模型而改变
软件行业根本上说其实就是软件从业者大规模的手工协作的过程，稍大型的软件涉及的沟通协同都会非常频繁和复杂。其本质特性比如本质复杂度、不一致性、不可见性、可变性等并没有因为大模型而改变，反而因为大模型生成代码的加入，这些特性的复杂程度可能还会加大，造成维护成本更高。
三、开发人员工作方式对大模型的局限
绝大多数程序员的工作方式一直都是接收需求和设计，然后编码自测，主要解决how的问题，需求和设计一般都是产品经理、BA、架构师给出；而使用大模型后，工作方式是要求程序员以大模型能够理解的文本描述清楚需求和方案，主要解决what的问题。
就像农民工一样，以前是按包工头的要求干活即可；如果每个农民工都变成了包工头，上游对接的对象就变成了甲方，不仅要理解甲方的需求，还要把需求转变成方案、再描述成最终期望的样子并能清晰的用农民工听得懂的语言表达出来，你说对于大部分农民工来说挑战大不大？
这里其实需要的不仅是专业知识，对沟通表达这种专业能力也要求非常高。重点从编程能力变成了语文能力，而广大程序员基本都是理工科出身，这种工作方式要求的能力转变往往成为很多程序员使用大模型的巨大障碍。而广大程序员往往不会认为是自己语文能力的问题，他们一般会说：大模型理解能力不行，至少是在我们这里不适用。一般认为世界上有两件最难的事情：把别人钱包的钱挣到自己口袋；把自己的观念灌输到别人的脑袋，改变别人的观念往往是最难的。
另外，把需求翻译、拆解、剥离业务从而成为大模型能够听懂语言，这块还是离不了程序员，只不过原来编码的程序员变成了prompt工程师。
综上，我们可以旗帜鲜明的说程序猿并不会被大模型取代，只会被更会用大模型的人取代。就像马车被火车取代后，马车夫的工作消失了，但是火车司机、乘务员、车站工作人员、检修员。。。一系列的新工种都产生了，马车夫要做的不是要继续争论人们为什么不尽量多的用马车运货，为什么不雇佣更多马车夫；而是应该积极学习火车带来的新的方式，拥抱火车带来的新的工作机会。
说到这里，问题基本都描述清楚了，相信大家一定认同：定义问题往往比解决问题更重要，有时候，问题定义清楚了，答案也就呼之欲出了，相信有耐心的同学看到这里，对于如何使用好大模型、如何适应大模型的场景和局限、如何更好把大模型作为自己加速的翅膀而不是被大模型替代，大家都有自己的答案了吧。
另外如何完美的避坑，从而拥抱新的工作方式，敬请期待下一篇文章。。。
