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