大模型在软件研发中的应用局限与应对
大模型兴起以来，深刻搅动了各行各业特别是软件行业的方方面面。共同的认知是，不远的将来代码都可以被大模型自动生成，但代码的生产者到底会不会从碳变成硅？程序员会不会成为减负增效的对象？
任何新的技术（方法、流程、模式、工具）产生的时候，其影响往往都会被过度描述。任何新技术都有三层结构，从里到外依次为：核心特性、适用场景和广告。
对于任何新技术，大家一定要冷静分析，摒弃其广告部分，弄清其适用场景，了解它的核心特性，才能真正把新技术学好用好。对于大模型在软件研发中的应用也一样，我们要先看看大模型在软件研发中的局限。这些局限有的来自于大模型自身特点导致的，有些是大模型应用对象导致的，还有些是使用者导致的。
一、大模型自身局限
1. 回答结果不稳定
大模型本质就是一个计算机程序，其核心是基于概率来补全文本。调用大模型的 API 时，会注意到有个 temperature 参数，这是个 0-1 之间的值。越大表示大模型的输出越是趋于开放、更有创意，相应输出篇幅也较大；越小表示大模型输出越是趋于保守、内敛，尽可能给出靠谱的回答，相应输出的篇幅也较小。
即使相同的 temperature，每次的输入也可能有不同的输出。当然对于不同的大模型输出的稳定性也千差万别，比如 ChatGPT4 的输出稳定性就非常好，相同问题相同 temperature 都基本会有相同的回答。
这就要求很多时候需要在大模型多次的输出中，选择一个相对靠谱的输出。谁来选？当然是人了。即使通过算法或另外的大模型来选择，还是需要靠人来设计选择算法。另外，从承担责任的角度，机器是没法坐牢的，只有人才能承担责任。关键责任总需要一个背锅侠。从这个角度看，程序猿是不可替代的。
2. 大模型会有幻觉（编造内容）
大模型的输出是基于概率的，相对来说不会有确定性答案。针对大模型不知道的问题，它有可能会编造内容并输出。当然，不同的模型在不同的场景下幻觉是不一样的。
所以对于大模型生成的内容，必须要通过人工审核才能采用。从这个角度说，大模型的应用同样离不开程序猿。
3. 输入输出最大 token 数受限
目前很多主流大模型的最大 token 数（输入 + 输出）都是 4-8k，当然，有些大模型可以到达 128k。听着不小了，对于一般的代码生成似乎是够了，但是编码中涉及的大文本场景还是不足的，比如：
- 大量私域业务知识通过 prompt 注入大模型时生成代码时，token 很容易超限；
- 代码走查时，上下文相关输入代码量不能一次太多，必要时需要拆解成多个 prompt 多次输入，否则会超限；
- 根据用例生成代码时，用例行数过大导致 token 超限无法输入；
- 生成代码过长时输出 token 超限会被截断。
这时都需要程序员手工或通过规则算法来进行 prompt 拆解、分片输入、输出合并拼接、手工调整输出来等完成应用，这里程序猿还是不能被替代。
二、软件工程对大模型的局限
大模型编程只是对软件工程中基础编程能力的知识平权。我们都有体会，很多多年工作的老程序员，对很多编程算法原理、实现细节、编译配置、常见故障分析定界定位、性能调优甚至编程语言层面的优化等这些基础编程能力很有经验。但是有了大模型之后，这些基础编程能力就被大模型平权了，借助大模型很多员工都可以掌握并依赖大模型输出来运用这些基础编程能力。
但是，基础编程能力并不能代表软件工程的全部，它只能带来局部效率的提升。
1. 现在软件工程应对的是规模化场景下各种问题，编程只是其中的一小部分
软件工程需求从概念塑形、需求分析、系统设计、编码自测、单测/集测/系统测、集成部署、升级演进、运维等全流程来贯通。尽管大模型可以对其中部分环节多多少少进行赋能，但目前主流实践效果看，基本还是在软件编码上效果比较明显，其他部分效果待展现，所以目前还只能说大模型带来的是软件工程的局部效能提升。
2. 软件从业者往往高估了编程的复杂度，但却会低估功能与设计的深刻度
软件设计一般要考虑三个方面：
- 说清问题：说清问题是软件设计的基础，其一般又可以分为三步分别为：设计目标，约束条件，验收准则。设计目标是纲，纲举则目张。说清问题必须对场景有深入理解，也不是手到擒来的，还是有一定难度的。
- 建立模型：简单的问题怎么解决都可以，模不模型无所谓。但复杂的问题首先一定要有个模型，才能把问题表达清晰；其次有了模型才能使解决方案变得易于理解，从而才知道解的对不对；最后有了模型才确定好最合适的算法。
- 选定算法：选择算法一般有两个维度，分别是算法速度和算法质量。对于同一模型，要依据使用场景，选择最恰当的算法，很多时候并不是最快或质量最高的算法，这才是最具挑战性的。
综上，设计深刻度反而比代码更重要，从这个角度看，大模型在基础编程能力的出色表现涵盖不了设计的深刻度，所以只能说是局部优化。
