大模型在软件研发中的应用存在自身、工程及人员三方面的局限。大模型自身存在回答不稳定、幻觉和 Token 限制；软件工程层面编程仅是局部能力，设计深刻度与协作本质未变；开发人员需从编码转向需求翻译与 Prompt 工程。结论是程序员不会被取代，但会被更会用大模型的人取代，关键在于定义问题而非仅解决问题。
大模型兴起以来，深刻搅动了各行各业特别是软件行业的方方面面。共同的认知是，不远的将来代码都可以被大模型自动生成，但代码的生产者到底会不会从碳变成硅？程序员会不会成为减负增效的对象？
任何新的技术（方法、流程、模式、工具）产生的时候，其影响往往都会被过度描述。任何新技术都有三层结构，从里到外依次为：核心特性、适用场景和广告。
对于任何新技术，大家一定要冷静分析，摒弃其广告部分，弄清其适用场景，了解它的核心特性，才能真正把新技术学好用好。对于大模型在软件研发中的应用也一样，我们要先看看大模型在软件研发中的局限。这些局限有的来自于大模型自身特点导致的，有些是大模型应用对象导致的，还有些是使用者导致的。
大模型本质就是一个计算机程序，其核心是基于概率来补全文本。调用大模型的 API 时，会注意到有个 temperature 参数，这是个 0-1 之间的值。越大表示大模型的输出越是趋于开放、更有创意，相应输出篇幅也较大；越小表示大模型输出越是趋于保守、内敛，尽可能给出靠谱的回答，相应输出的篇幅也较小。
即使相同的 temperature，每次的输入也可能有不同的输出。当然对于不同的大模型输出的稳定性也千差万别，比如 ChatGPT4 的输出稳定性就非常好，相同问题相同 temperature 都基本会有相同的回答。
这就要求很多时候需要在大模型多次的输出中，选择一个相对靠谱的输出。谁来选？当然是人了。即使通过算法或另外的大模型来选择，还是需要靠人来设计选择算法。另外，从承担责任的角度，机器是没法坐牢的，只有人才能承担责任。关键责任总需要一个背锅侠。从这个角度看，程序猿是不可替代的。
大模型的输出是基于概率的，相对来说不会有确定性答案。针对大模型不知道的问题，它有可能会编造内容并输出。当然，不同的模型在不同的场景下幻觉是不一样的。
所以对于大模型生成的内容，必须要通过人工审核才能采用。从这个角度说，大模型的应用同样离不开程序猿。
目前很多主流大模型的最大 token 数（输入 + 输出）都是 4-8k，当然，有些大模型可以到达 128k。听着不小了，对于一般的代码生成似乎是够了，但是编码中涉及的大文本场景还是不足的，比如：
这时都需要程序员手工或通过规则算法来进行 prompt 拆解、分片输入、输出合并拼接、手工调整输出来等完成应用，这里程序猿还是不能被替代。
大模型编程只是对软件工程中基础编程能力的知识平权。我们都有体会，很多多年工作的老程序员，对很多编程算法原理、实现细节、编译配置、常见故障分析定界定位、性能调优甚至编程语言层面的优化等这些基础编程能力很有经验。但是有了大模型之后，这些基础编程能力就被大模型平权了，借助大模型很多员工都可以掌握并依赖大模型输出来运用这些基础编程能力。
但是，基础编程能力并不能代表软件工程的全部，它只能带来局部效率的提升。
软件工程需求从概念塑形、需求分析、系统设计、编码自测、单测/集测/系统测、集成部署、升级演进、运维等全流程来贯通。尽管大模型可以对其中部分环节多多少少进行赋能，但目前主流实践效果看，基本还是在软件编码上效果比较明显，其他部分效果待展现，所以目前还只能说大模型带来的是软件工程的局部效能提升。
软件设计一般要考虑三个方面：
综上，设计深刻度反而比代码更重要，从这个角度看，大模型在基础编程能力的出色表现涵盖不了设计的深刻度，所以只能说是局部优化。
软件行业根本上说其实就是软件从业者大规模的手工协作的过程，稍大型的软件涉及的沟通协同都会非常频繁和复杂。其本质特性比如本质复杂度、不一致性、不可见性、可变性等并没有因为大模型而改变，反而因为大模型生成代码的加入，这些特性的复杂程度可能还会加大，造成维护成本更高。
绝大多数程序员的工作方式一直都是接收需求和设计，然后编码自测，主要解决 how 的问题，需求和设计一般都是产品经理、BA、架构师给出。而使用大模型后，工作方式是要求程序员以大模型能够理解的文本描述清楚需求和方案，主要解决 what 的问题。
就像农民工一样，以前是按包工头的要求干活即可；如果每个农民工都变成了包工头，上游对接的对象就变成了甲方，不仅要理解甲方的需求，还要把需求转变成方案、再描述成最终期望的样子并能清晰的用语言表达出来，这对于大部分程序员来说挑战很大。
这里其实需要的不仅是专业知识，对沟通表达这种专业能力也要求非常高。重点从编程能力变成了语文能力，而广大程序员基本都是理工科出身，这种工作方式要求的能力转变往往成为很多程序员使用大模型的巨大障碍。而广大程序员往往不会认为是自己语文能力的问题，他们一般会说：大模型理解能力不行，至少是在我们这里不适用。
另外，把需求翻译、拆解、剥离业务从而成为大模型能够听懂语言，这块还是离不了程序员，只不过原来编码的程序员变成了 Prompt 工程师。
我们可以旗帜鲜明地说程序猿并不会被大模型取代，只会被更会用大模型的人取代。就像马车被火车取代后，马车夫的工作消失了，但是火车司机、乘务员、车站工作人员、检修员等一系列的新工种都产生了。马车夫要做的不是要继续争论人们为什么不尽量多的用马车运货，而是应该积极学习火车带来的新的方式，拥抱火车带来的新的工作机会。
定义问题往往比解决问题更重要，有时候，问题定义清楚了，答案也就呼之欲出了。希望有耐心的同学看到这里，对于如何使用好大模型、如何适应大模型的场景和局限、如何更好把大模型作为自己加速的翅膀而不是被大模型替代，大家都有自己的答案了吧。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
