【编者按】GPT系列的面世影响了全世界、各个行业，对于开发者们的感受则最为深切。以ChatGPT、GithubCopilot为首，各类AI编程助手层出不穷。编程范式正在发生前所未有的变化，从汇编到Java等高级语言，再到今天以自然语言为特征的Prompt工程，编程的门槛进一步降低，让很多开发者也不由得思考，编程的未来究竟会如何演化，在这大模型时代，开发者又该何去何从？基于此，《007：大模型时代的开发者》特别邀请资深程序员Phodal撰写此文，希望能够对所有开发者在未来之路的前行上有所帮助。
注：《新程序员007》聚焦开发者成长，其间既有图灵奖得主JosephSifakis、前OpenAI科学家JoelLehman等高瞻远瞩，又有对于开发者们至关重要的成长路径、工程实践及趟坑经验等，欢迎大家。
作者|黄峰达（Phodal）
责编|唐小引
出品|《》编辑部
对于开发者来说，大型生成式语言模型带来了挑战，但也提供了宝贵的机会。
图1企业AIGC投资策略
根据我们此前分析的企业AIGC投资策略/难度曲线（如图1所示），这里也划分了三个阶段：
尽管，可能有一些企业预期生成式AI带来的效能提升，而进行了组织结构调整（俗称裁员）。但是，我们可以看到AIGC带来了更多的新机遇，它们不仅能够提高开发效率，还可以开创全新的领域和解决方案，为软件开发行业带来划时代的变革。
简单来说，开发者如果想保持自己的竞争力，我们必须掌握LLM能力以提升生产力，还可以加入开发LLM应用的大军。
L1：学会与LLM相处，提升个人或团队效率
在过去一年里，我们看到很多人在使用LLM的过程中，遇到了一些问题。但也很显然，它能在许多方面提升我们的效率，特别是在诸多繁琐的事务上，如文档、测试用例、代码等。
LLM擅长什么，不擅长什么？
其次，我们要知道LLM不擅长什么。LLM是一个语言模型，它擅长的是生成文本。究其本质它又是一个概率模型，所以它需要借助其他工具来完成自身不擅长的内容（比如数学计算）。因此，我们不应该期望LLM能够帮助我们完成一些数学计算，而是应该期望它能根据我们的上下文，生成数学计算的公式、代码等等。
学会与LLM交流，提升个人效率
LLM的交流方式，主要是通过Prompt，而Prompt的构建，是一个需要不断迭代的过程。在这个过程中，要不断地尝试，以找到最适合自己的模式。比如笔者习惯的模式是：
如下是笔者在开源的IDE插件AutoDev中的测试生成的Prompt（部分）：
Writeunittestforfollowingcode.YouareworkingonaprojectthatusesSpringMVC,SpringWebFlux,JDBCtobuildRESTfulAPIs.
YouMUSTuseshould_xxstylefortestmethodname.Whentestingcontroller,youMUSTuseMockMvcandtestAPIonly.
//classBlogController{//blogService//+publicBlogController(BlogServiceblogService)//+@PostMapping("/blog")publicBlogPostcreateBlog(CreateBlogDtoblogDto)//+@GetMapping("/blog")publicListgetBlog()//}
//选中的代码信息Startwith`import`syntaxhere:
最后的import会根据用户选中的是类还是方法来决定，如果是一个方法，那么就会变为:Startwith@Testsyntaxhere:。由于大部分的开源代码模型是基于英语的，并且用来训练的代码本身也是“英语”的，所以在效果上用英语的Prompt效果会更好。
精炼上下文成本，活用各类工具
考虑到每个工具，每个月可能会产生10～30美元的成本，我们还是需要仔细研究一下更合适的方案是什么。
个人发展：提升AI不擅长的能力
随着AIGC成本的进一步下降，有些部门可能会因为生成式AI而遭公司缩减规模。这并非因为AIGC能取代人类，而是人们预期提升20～30%的效能，并且在一些团队试点之后，也发现的确如此。
假定AIGC能提升一个团队20%的效能，那么从管理层来说，他们会考虑减少20%的成员。而更有意思的是，如果团队减少了20%的规模，那么会因为沟通成本的降低，而提升更多的效能。所以，这个团队的效能提升了不止20%。
从短期来说，掌握好AIGC能力的开发人员，不会因这种趋势而被淘汰。而长期来说，本就存在一定内卷的开发行业，这种趋势会加剧。十几年前，人们想的是一个懂点Java的人，而今天，这个标准变成了，既懂Java设计模式，还要懂Java的各类算法。所以，从个人发展的角度，我们要适当地提升AI不擅长的能力。
就能力而言，AI不擅长解决复杂上下文的问题，比如架构设计、软件建模等等。从另一个层面上，由于AI作为一个知识库，它能够帮助我们解决一些软件开发的基础问题（比如某语言的语法），会使得我们更易于上手新语言，从而进一步促使开发者变成多面手，成为多语言的开发者。
与提升这些能力相比，在短期内，我们更应该加入开发大模型的大军。因为，这是一个全新的领域，无需传统AI的各种算法知识，只需要懂得如何工程化应用。
L2：开发LLM优先应用架构，探索组织规模化落地
与十年前的移动浪潮相似，生成式AI缺少大量的人才。而这些人才难以直接从市场上招聘到，需要由现有的技术人才转换而来。所以，既然我们可能打不过AI，那么就加入到这个浪潮中。
AI浪潮席卷（图源：由编者AIGC生成）
PoC试验：现有产品融入LLM，探索LLM优先架构
在过去的一年里，我们可以看到有大量的开发者加入了LLM应用的开发大军中。它并没有太复杂的技术，只需要一些简单的Prompt基础，以及关于用户体验等的设计。从网上各类的聊天机器人，再到集成内部的IT系统，以及在业务中的应用。只有真正在项目中使用，我们才会发现LLM的优势和不足。
考虑到不同模型之间的能力差异和能力，我们建议使用一些比较好的大语言模型，以知道最好的大模型能带来什么。从笔者的角度来说，笔者使用比较多的模型是ChatGPT3.5，一来是预期2023年年底或者2024年国内的模型能达到这个水平，二来是它的成本相对较低，可以规模化应用。
图2LLM优先架构
如下是，根据我们的内外部经验，总结出的LLM优先架构（如图2所示）的四个原则：
如我们在构建一个文本生成SQL、图表、UI的应用时，做的第一个设计就是：用户输入一句话，让LLM根据我们给定的上下文分析用户的意图，再生成对应的DSL。如下是这一类工具思维链的精炼版本：
思考：是否包含了用户故事和布局信息，如果明确请结束询问，如果不明确，请继续询问。行动：为”CONTINUE”或者”FINISH”询问：想继续询问的问题最终输出：完整的问题思考-行动-询问可以循环数次，直到最终输出
随后，在有了用户的意图之后，我们会根据用户的意图，生成对应的DSL，再由DSL生成对应的SQL、图表、UI等等。如下是一个简单的DSL：
然后，根据关联的组件示例代码、业务上下文信息，生成最后的应用代码。
LLMasCo-pilot：贴合自己的习惯，构建和适用Copilot型应用
相信大部分读者已经对于GitHubCopilot有一定的经验，对于这一类围绕于个体角色的AI工具，我们都会称其为Copilot型应用。所以，在这个阶段，我们会将其称为LLMasCo-pilot：
即，不改变软件工程的专业分工，但增强每个专业技术，基于AI的研发工具平台辅助工程师完成任务，影响个体工作。
它主要用于解决“我懒得做”及“我重复做”的事儿。在Thoughtworks内部，不同的角色也构建了自己的Copilot型应用，诸如：
在构建这一类工具时，我们需要深入了解每个角色的工作方式，以及他们的痛点。比如开发人员在使用IDE时，不止会编写代码，于是像JetBrainsAIAssistant的自带IDEAI插件就会，在：
从个人的角度来说，这些工具是面向通用的场景构建的，可以将其称为通用型AI工具。而在企业内部或者自身有能力，我们可以构建更加贴合自己的AI工具，以提升效率。笔者在开发AutoDev的过程中，便在思考这个问题，如何构建一个更加贴合自己的AI工具。于是，加入了大量可以自定义规范、IDE智能行为、文档生成等功能，以提升自己的效率。举个例子，你可以在代码库中加入自定义的智能行为，如直接选中代码，让它生成测试：
interaction:AppendCursorStream你是一个资深的软件开发工程师，你擅长使用TDD的方式来开发软件，你需要根据用户的需求，帮助用户编写测试代码。
${frameworkContext}
${beforeCursor}
用户的需求是：${selection}
请使用@Test开头编写你的代码块：
这类工具应该在完成通用的功能之后，提供一些自定义的能力，以提升个人的效率。
LLMasCo-Integrator：探索知识型团队的构建，加速团队间集成
除了上述的单点工具之外，如何在跨角色、跨团队之间形成这种全力协作的效果，是我们需要持续探索的问题。在软件研发领域，我们将这个阶段称之为LLMasCo-Integrator，其定义是：
跨研发职责及角色的协同增效，基于AI的研发工具平台解决不同的角色沟通提效，影响角色互动。
在这些场景上，我们可以看到诸多企业都是以构建内部的知识问答系统作为起点，探索这一类工具的应用，以进一步探索AIGC可能性。在一些领先的企业上，直接构建的是内部知识平台，员工只需上传自己的文档、代码等，就可以基于其作为上下文来问答。而在一些成熟的MLOps/LLMOps平台上，它可以直接提供基于知识平台的API，以直接插入应用中。
而这些基于LLM问答工具的核心是RAG（检索增强生成）模式，也是开发者在构建AIGC所需要掌握的核心能力。如下是一个简单的RAG表示（基于RAGScript）：
@file:DependsOn("cc.unitmesh:rag-script:0.4.1")
importcc.unitmesh.rag.*
rag{//使用OpenAI作为LLM引擎llm=LlmConnector(LlmType.OpenAI)//使用SentenceTransformers作为Embedding引擎embedding=EmbeddingEngine(EngineType.SentenceTransformers)//使用Memory作为Retrieverstore=Store(StoreType.Memory)
indexing{//从文件中读取文档valdocument=document("filename.txt")//将文档切割成chunkvalchunks=document.split()//建立索引store.indexing(chunks)}
querying{//查询store.findRelevant("workflowdsldesign").also{println(it)}}}
一个典型的LLM+RAG应用，分为两个阶段：
在这两个阶段，由于场景不同，需要考虑结合不同的RAG模式以提升检索质量，进而提升答案质量。如在代码索引场景，在索引阶段，依赖于代码的拆分规则，会有不同的拆分方式；而在查询阶段，则会结合不同的模式，以提升答案质量。如下是一些常见的用于代码领域的RAG模式：
受限于篇幅，我们不会在这里继续展开讨论。
设计与开发内部框架，规模化应用LLM
随着我们在组织内部构建越来越多的大模型应用，我们会发现：如何规模化应用生成式AI应用，会变成我们的下一个挑战。对于这个问题，不同的组织有不同的思路，有的会通过构建大模型平台，并在平台上构建一系列的通用能力，以帮助团队快速构建应用。然而，这种模式只限于大型的IT组织，在小型组织中，我们需要构建的是更加轻量级的框架。这个框架应该融入内部的各种基础设施，以提供一些通用的能力。
尽管有一定数量的开发者都已经使用LangChain开发过AIGC应用，但由于它是一个大型框架，且用的是Python语言。对于使用JVM语言体系的企业来说，要直接与业务应用集成并非易事。也因此，要么我们围绕LangChain构建API服务层，要么我们得考虑提供基于JVM语言的SDK。
LLMSDK在LLM参考架构中的位置
在这一点上，Spring框架的试验式项目SpringAI就提供了一个非常好的示例，它参考了LangChain、LlamaIndex的一系列思路，并构建了自己的模块化架构——通过Gradle、Maven依赖按需引入模块。但对于企业来说，受限于我们的场景、基础设施，它并不能好地融入我们的应用中。
所以，在我们的软件应用开发场景里构建了自己的LLMSDK——ChocolateFactory。它除了提供基本的LLM能力封装外，专门针对于研发场景，加入了自己的一些特性，诸如基于语法分析的代码拆分（split)、Git提交信息解析、Git提交历史分析等。
L3：微调与训练大语言模型，深度绑定特定场景
在过去的几个月里，涌现了一系列的开源模型，都加入到游戏中，改变这个游戏的规则。对于多数的组织来说，我们不需要自己构建模型，而是直接使用开源模型即可，所以开发者并不需要掌握模型训练或微调的能力。当然，笔者在这方面的能力也比较有限，但它是开发者非常值得考虑的一个方向。
构建LLMOps平台，加速大模型应用落地
LLMOps平台是一种用于管理大型语言模型（LLM）的应用程序生命周期的平台。它包括了开发、部署、维护和优化LLM的一系列工具和最佳实践。LLMOps平台的目的是让开发者能够高效、可扩展和安全地使用LLM来构建和运行实际应用程序，例如聊天机器人、写作助手、编程助手等。——BingChat
与开发大模型应用相比，构建LLMOps平台的难度就要稍微大一点。因为，它需要考虑的问题更多，从模型的部署与微调，到模型的监控、管理与协作，再到作为使用者的开发者的体验设计。
从本质来说，LLMOps所做的事情是加速LLM应用的快速落地，所以它需要考虑的问题也更多：
在这基础上，对于LLMOps平台，一个AI2.0时代的平台，它还需要提供模型训练、微调与优化的能力。以面向不同的业务场景，提供低门槛的模型优化能力。
也因此，对于开发者来说，能加入这样的平台开发，亦是能快速成长起来。
适应特定任务场景下的模型微调
也因此，模型微调的本质是借助高质量数据，快速构建出一个特定任务、场景下的模型。一旦进行了微调，在执行其他任务的能力时，就会变得非常差。所以，这时需要在平台上结合动态的LoRA加载能力（诸如StableDiffusion上相似的能力），以提升更好的灵活力。
而于开发者们而言，就需掌握包括数据收集及清洗、模型微调、模型评估和部署等在内的一系列技能。此外，了解如何使用动态加载和其他模型增强技术也很重要，以满足不同的需求。
自研企业、行业大模型
基础的开源模型使用的都是公开的语料，缺少特定行业的语料。举个例子，在编程领域，根据StarCoder的训练语料（主要基于GitHub）：
所以，对于大型企业而言，这些通用模型并不能满足他们的需求。但如果想自研模型，除了需要大量的公开语料之外，还需要大量的内部语料。由于笔者在这方面的经验有限，所以在这里不会展开讨论。
总结
在大模型时代，开发者面临着巨大的机遇和挑战。生成式AI（AIGC）正日益改变着软件开发行业的方方面面，从产品研发到代码编写，从测试到维护，甚至到工作任务的安排与协调（LLMasCo-Facilitator）。
作为开发者，我们可以逐步地掌握这些能力：
1.先学会与大型语言模型（LLM）相处，以提升个人或团队效率。包括了解LLM的能力，学会高效使用Prompt与LLM进行交流，以及活用各类工具。
2.着眼于开发LLM优先应用架构，探索组织规模化落地。这包括了进行各种原型试验，将大模型融入现有产品，构建Copilot型应用，以及设计和开发内部框架来规模化应用开发。
3.深入微调与训练大语言模型，将其深度绑定到特定场景。尽管并不是每个开发者都需要掌握模型训练和微调的能力，但这是一个非常值得考虑的方向。