本文面向程序员提供大语言模型（LLM）技术指南，涵盖基础能力运用、应用架构设计及特定场景高级应用。内容涉及 Prompt 编写与管理、LLM 友好型流程设计、插件化与智能体架构、矢量数据库及本地小模型部署。文章探讨了直接 Prompt、知识外挂与微调三种模式，并强调上下文工程在提升模型输出准确性中的核心作用，旨在帮助开发者构建私有化 LLM 应用及实现 AI 原生编程体验。
过去几个月里，我们对于大语言模型的一系列探索，如 ChatGPT 端到端实践与应用开发、LLaMA 与 ChatGLM 的微调试验、GitHub Copilot 逆向工程分析、动态上下文工程（即 LangChain）的研究，驱使着我去写一个总结，也是一个面向程序员的 LLM 指南。
作为一个从个人经验总结的文章，本文涉及的知识点较多，主要会从以下几个点出发：
随着 AI 技术的进一步演进和应用，会出现更多新的变化。基于我们先前的假设：每个大型企业都将有私有化的大语言模型；私有化的主流方式为开源 LLM + 微调。基于此，越来越多的企业将构建围绕于 LLM 的应用，而这些应用在当前以辅助人类设计为主。未来，我们将保持一种观点：LLM as Member，即 LLM 应该是我们的伙伴，而不再是一个辅助的工具。
今年 2 月，我基于编程、绘画、写作展开的 AI 探索和总结，编写了两篇文章受到了非常大的关注。如何编写、调度与逆向工程 Prompt？将会是现阶段程序员要面临的第一个挑战，我们需要实践的三个问题：
究其原因，不仅是我们日常工作需要用到 prompt，开始工具的时候，我们也有大量的工作在编写 prompt 上。除此，还需要寻找一种合适的方式，以让 LLM 输出的结果趋于稳定。
所以，作为一个经典软件开发时代的程序员，我们应该学习如何摸清 LLM 的脾气？学习如何编写恰到好处的 prompt。
# 示例：结构化 Prompt 构建
prompt = f"""
你是一个资深后端工程师。
任务：解释以下代码的功能。
代码：{code_snippet}
要求：分步骤说明，并指出潜在风险。
"""
今年 3 月，基于结合 LLM + SDLC 的探索，得到的第一个有价值的观点是《Prompt 即代码》。于是，基于这个思想，我们构建了我们在 LLM 时代的第一个开源项目：ClickPrompt。ClickPrompt 站在了未来企业需要的三个基本出发点：
而在我第一次将注释加入到 ClickPrompt 中的时候，我犹豫了很久。过去的经典编程范式，并不允许将思考过程作为注释到其中。而在未来，我们就会遇到 Prompt 即注释、Prompt 即接口、Prompt 即代码。
所以，将 prompt 视为代码，以更好的管理 prompt，将它与我们的软件开发生命周期结合，将是作为经典程序员要考虑的点。除此，我们还需要考虑：
我们也可以让 LLM 来告诉我们答案，只是它可能没有这样的创新能力。
未来的 AI 编程模式是什么？在那篇《渐近式 AI 编程模式》文章里，可以看到几个基本的思考：
对于它的思考，促使我设计了 Unit Mesh 架构，详细见《Unit Mesh 架构的设计思路与探索》。
除了新的架构模式本身，我们还面临一个挑战：在现有的 LLM 下，我们应该如何设计应用架构？
在习惯了 ChatGPT 之后，Chat 模式作为基础的 LLM 元素加入了 UI 设计中。诸如于不那么好用的 New Bing，已经可以帮你总结一下相关的链接，虽然不可靠，但是大家都认可了。所以，无论是我们构建的 ClickPrompt，还是 AutoDev 这样的 IDE 辅助编程插件，都将 Chat 作为基础的 UI 模式加入到了系统。
而在 LangChain 的文档中，我们又会看到新一代的框架、工具文档模式，文档作为外挂的知识库，可以直接让开发人员通过对话来学习，并编写一些示例代码。就这一点而言，它大大改善了过去那不太好友好的文档体验。
所以，对于开发前端框架的人来说，这又带来了新的 KPI 机会。毕竟，谁会拒绝这么一个有挑战性的东西。另外一个点是，构建一个不同语言的 LangChain，经典企业的技术架构都优先考虑 JVM。
基于上述的新交互方式，现有的每一个应用都可能被重写。所以，我们开始探索对于软件开发的改变，也就有了《AI 应用开发新工序》。
对于当前的 AI 应用来说，主要有三种模式：直接 prompt 模式、知识外挂、微调。
不同的模式之下，带给开发人员的挑战也是不一样的，依旧是由易到难。而其中的核心点是：寻找一种合理的 DSL（领域特定语言），以将现有的流程结合到 LLM。
随着越来越多的大语言模型有了自己的类似 LangChain 工具（如 ChatGLM-LangChain）、越来越多的编程语言社区出了自己版本的 LangChain 版本（如 LangChain Go）。现有的软件架构又来了一些新的变化：
而由于 Token 很贵，我们需要管理好 token，以降低 token 的花销。我们还需要：
而这些依旧只是基于现状的观察，毕竟在外挂知识库、结合知识图谱方面，我们还有大量的工作和试验仍然在进行中。
每个不同的通用大语言模型，受限于语料、算法、强化方式，在能力上是不同的差异。而对于现有的、开源的大语言模型来说，这种差异就更加明显了。所以，我们需要针对于不同的场景，构建适合的策略，如编程场景、智能客服场景、需求完善场景等。
而由于微调后的模型是指针特定领域的，所以我们需要考虑适用于自身场景 LLM 架构方案：
随着时间的推移，这方面的方案会越来越完善。
如果想利用大语言模型的能力，我们需要让它是大模型友好的，还需要构建一个工程化的模式。也就是我们在探索 API 新工序时，总结的基本思路：
而对于微调来说，主要是前半部分：DSL 化、数据工程，以将现有的数据转换为模型可用的数据，进而整合到现有的工具链中。诸如于，将系统架构图转换为 PlantUML，以这些数据微调，进而简化现有的架构呈现方式。
# 示例：使用 HuggingFace Trainer 进行微调配置
from transformers import TrainingArguments
training_args = TrainingArguments(
output_dir="./results",
per_device_train_batch_size=4,
num_train_epochs=3,
# ... 其他参数
)
在我们探索 GitHub Copilot 的过程中，有感于 GitHub 程序员在此做的努力，于是总结了《上下文工程实践》。**如何对于高效的构建全面的上下文，以让 LLM 生成更准确的结果？**这便是我们在未来所要做的活动。结合上述的内容，几个潜在需要考虑的点是：
若是想充分运用大模型，我们需要控制好 Prompt，而其中的关键就是对于上下文的工程化。
本文介绍了以 LLM 为核心的程序员技术指南，包括应用篇、高级篇和上下文工程。其中，应用篇介绍了 Chat 模式和大模型友好的流程，高级篇介绍了面向特定场景的 LLM 应用，上下文工程则是 LLM 应用的核心。
除此之外，文中还提到了当前 AI 应用的三种模式：直接 prompt 模式、知识外挂模式和微调模式，并介绍了针对不同场景构建适合的策略的重要性。同时，文章探讨了如何让 LLM 是大模型友好的，并建议采用语言建模、构建 MVP 产品并进行试验、设计增量的指标、围绕上下文的工程化思维和持续反馈的软件工程等方法来实现。
此外，文章还提到了随着时间推移，针对 LLM 的外挂知识库和结合知识图谱等方面的方案会不断完善，并讨论了如何构建动态的 LoRA 加载、通用大模型配合微调小模型以及多模型配合等方案。
总之，本文提供了一份全面的 LLM 技术指南，为程序员和开发人员提供了在这一领域提高效率的方法和策略。未来的编程将更加智能化，开发者需要从单纯编写代码转向设计提示词、管理上下文和优化模型交互流程。掌握这些技能将成为新时代程序员的核心竞争力。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 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