LLM对程序员的冲击和影响( 三 ) _LLM

LangChain 是一个链接面向用户程序和 LLM 之间的一个中间层，通过输入自己的知识库来“定制化”自己的 LLM 。langchain 使用 embedding 建立基于项目特定的向量知识库，实现“基于特定文档的问答” 。
6 LLM 时代，对软件研发更多的思考
思考 1：替代的是码农，共生的是工程师

文章插图
在软件开发过程中，当伪代码级别的设计完成后，最后一公里的编码实现会被 LLM 替代，因为基于记忆的简单重复编码不是人的优势，而是机器的优势。
这部分工作现在属于码农，也就是我们俗称的 CRUD 仔和 API Boy，所以很多不涉及设计的码农可能会被大模型替代。
而工程师需要关注业务理解、需求拆分、架构设计、设计取舍，并在此基础上通过 prompt 学会与 AI 合作，从而实现“工程师 + LLM”形成 1+1 >2 的效果。这就是共生。
需要注意的是，这种共生必须始终保持人的主观能动性，机器必须是 Copilot，也就是智能副驾驶，主驾驶位置必须是人，这样的人 - 机关系才能长期健康发展。这也就是为什么说微软现任 CEO 萨提亚强调 Copilot（智能副驾驶）是比 Autopilot（自动驾驶）还先进的根本原因。
另外，特别要提的是：短期内率先学会使用 LLM 的工程师必将获益，但是很快大家都会掌握，这个时候能力水平就再次被拉平了，这个很像之前“外卖骑手困在系统里”那篇文章中的观点，所以作为共生的工程师，我们更需要从以下三个方面来强化自己的能力：
需求理解、需求分析、需求拆解的能力
架构设计、架构分析、设计取舍的能力，并推动设计的文档化和规范化
理解问题本质，而不是单纯学习应用（授人以鱼不如授人以渔）
思考 2：有利于控制研发团队规模，保持小团队的优势

文章插图
随着一个软件规模的扩展，软件项目参与的人越来越多，分工越来越细，人和人之间需要的沟通量，也指数增长。很快你会发现，沟通花费的时间，渐渐地就比分工省下来的时间还要多。说白了，过了一个临界点，人越多不是越帮忙，而是人越多越添乱。一个人 12 个月能完成的事，不见得上 12 个人 1 个月就能完成，甚至 12 个月也未必能完成。
《人月神话》里建议了一种组织方式，叫“外科手术式的队伍” 。就像一台外科手术一样，有一个主刀大夫，软件项目也应该有一个首席程序员，其他人都是给他提供支持的。这样，就既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。
但是软件规模大了之后，需要的程序员数量必然会更多，团队规模一定会加速扩展。但是 LLM 的出现，让基础编程工作一定程度上实现了自动化，这样非常有利于控制研发团队规模，保持小团队的效率优势。
思考 3：暗知识

文章插图
大模型的成功很大程度上来自于对已有的互联网文本语料和专业书籍等资料的学习。相对应，在软件工程领域，需要学习的不仅仅是代码，还应该包括需求，设计。
但是，很多需求和设计并不以文档的形式存在，往往会存在于程序员和架构师的脑子里，或者在讨论的过程中。就算有文档，文档和代码大概率不同步。就算文档同步，文档（需求和设计）背后经常有大量的方案对比和推敲，甚至有很多要在原有债务基础上的设计妥协，这些决策过程一般都不会明确地被记录下来。这些没有被文档化下来的知识，我们称其为“暗知识” 。
虽然我们说只要有足够的数据，大模型就可以学到需求和设计知识。但这些“暗知识”本身就很难被捕捉到，“足够的数据”这一前提在需求分析和软件设计可能难以满足。
另外，在实际软件开发中，需求可能一次不能表达得很清楚，需要一边开发一边逐步写清楚需求。尤其是敏捷开发更是如此。所以一些通用的，不需要特定领域知识的问题，LLM 的表现会比较好，但是那些专用的，需要特定领域知识（私域知识）的问题，LLM 就可能不是很擅长。
总结来看：“你能想到的多过你能说出来的，你能说出来的多过你能写下来的。”所以这就天然限制了 LLM 能力的上限。
思考 4：Prompt 即代码，代码不再是代码