以 LLM 為核心 LLM@Core：程式員的大語言模型技術指南

過去幾個月裡，我們對于大語言模型的一系列探索，如 ChatGPT 端到端實踐與應用開發、LLaMA 與 ChatGLM 的微調試驗、GitHub Copilot 逆向工程分析、動态上下文工程（即 LangChain）的研究，驅使着我去寫一個總結，也是一個面向程式員的 LLM 指南。

也是好久沒有寫這個系列（程式員必知）的文章。

作為一個從個人經驗總結的文章，本文涉及的知識點可能有點多，主要會從以下幾個點出發：

1. 基礎篇：充分運用 LLM 能力
1. Prompt 編寫：Prompt 學習與編寫模式
2. Prompt 管理：Prompt 即代碼
2. 應用篇：LLM 下的應用架構設計
1. 新的互動設計
2. 新的工序：大模型友好的流程
3. 架構設計的新變化
3. 進階篇：面向特定場景的 LLM 應用
1. 特定場景的模型微調
2. 上下文工程：LLM 應用的核心

而随着 AI 技術的進一步演進和應用，會出現更多新的變化，諸如于早先我們設計的 Unit Mesh 架構，會帶來全新的架構與程式設計體驗。

本篇文章基于我們先前的兩個假設：

1. 每個大型企業都将有私有化的大語言模型。
2. 私有化的主流方式：開源 LLM + 微調。

基于此，越來越多的企業将建構圍繞于 LLM 的應用，而這些應用在目前以輔助人類設計為主。未來，我們将保持一種觀點：LLM as Member，即 LLM 應該是我們的夥伴，而不再是一個輔助的工具。

基礎篇：充分運用 LLM 能力

我們将迎來 AI 原生程式員的時代。幾年以後，新一代的程式員，将是 AI 原生的程式員。新生代的程式所具備的能力，将與我們的能力有巨大的差別。在雲原生時代裡，雲原生程式員，不需要具備大量的 ops 相關的技能，他們更關注于如何采用類似于 DDD 這樣的政策來合理劃分子產品。

從未來出發，作為“老一代程式員“的我們，需要強化我們運用大語言模型的能力，諸如于 Prompt 能力。

1.1 Prompt 編寫：Prompt 學習與編寫模式

今年 2 月，我基于我擅長的程式設計、繪畫、寫作展開的 AI 探索和總結，我編寫了兩篇文章《了解 Prompt》、《Prompt 編寫模式 》受到了非常大的關注，GitHub 上的 stars 都超過了 2000。

如何編寫、排程與逆向工程 Prompt ？将會是現階段程式員要面臨的第一個挑戰，我們需要實踐的三個問題：

• 提出問題的政策
• 創造性地利用模型回答
• 提高模型輸出品質的技巧

究其原因，不僅是我們日常工作需要用到 prompt，開始工具的時候，我們也有大量的工作在編寫 prompt 上。除此，還需要尋找一種合适的方式，以讓 LLM 輸出的結果趨于穩定。

是以，作為一個經典軟體開發時代的程式員，我們應該學習如何摸清 LLM 的脾氣？學習如何編寫恰到好處的 prompt。

1.2 Prompt 管理：Prompt 即代碼

今年 3 月，基于我們結合 LLM + SDLC 的探索，得到的第一個有價值的觀點是《Prompt 即代碼：設計和管理 AI 程式設計的最佳實踐》。于是，基于這個思想，我們建構了我們在 LLM 時代的第一個開源項目：ClickPrompt。ClickPrompt 站在了未來企業需要的三個基本出發點：

• 如何學習 prompt 的編寫？
• 如何分享企業内的 prompt 經驗？
• 如何将 prompt 結合到工作流中？

而在我第一次将注釋加入到 ClickPrompt 中的時候，我猶豫了很久。過去的經典程式設計範式，并不允許将思考過程作為注釋到其中。而在未來，我們就會遇到 Prompt 即注釋、Prompt 即接口、Prompt 即代碼。

是以，将 prompt 視為代碼，以更好的管理 prompt，将它與我們的軟體開發生命周期結合，将是作為經典程式員要考慮的點。除此，我們還需要考慮：

• 版本控制與協作
• 用于測試和調試的工具
• 适用于不同 LLM 的 prompt 接口模式

我們也可以讓 LLM 來告訴我們答案，隻是它可能沒有這樣的創新能力。

應用篇：LLM 下的應用架構設計

未來的 AI 程式設計模式是什麼？在那篇《未來可期的 AI 程式設計》文章裡，可以看到幾個基本的思考：

• Prompt 即是代碼，代碼不再是代碼？
• 現有的程式設計體系适合于 AI 程式設計嗎？
• Serverless 會是結合 AI 程式設計的答案嗎？
• 需求詳細化會成為你的新瓶頸嗎？

對于它的思考，促使我設計了 Unit Mesh 架構，詳細見《漸近式 AI 程式設計模式：Unit Mesh 架構的設計思路與探索》。

除了新的架構模式本身，我們還面臨一個挑戰：在現有的 LLM 下，我們應該如何設計應用架構？

2.1 新的互動設計：Chat 模式

在習慣了 ChatGPT 之後，Chat 模式作為基礎的 LLM 元素加入了 UI 設計中。諸如于不那麼好用的 New Bing，已經可以幫你總結一下相關的連結，雖然不可靠，但是大家都認可了。是以，無論是我們建構的 ClickPrompt，還是 AutoDev 這樣的 IDE 輔助程式設計插件，都将 Chat 作為基礎的 UI 模式加入到了系統。

而在 LangChain 的文檔中，我們又會看到新一代的架構、工具文檔模式，文檔作為外挂的知識庫，可以直接讓開發人員通過對話來學習，并編寫一些示例代碼。就這一點而言，它大大改善了過去那不太好友好的文檔體驗。

是以，對于開發前端架構的人來說，這又帶來了新的 KPI 機會。畢竟，誰會拒絕這麼一個有挑戰性的東西。另外一個點是，建構一個不同語言的 LangChain，經典企業的技術架構都優先考慮 JVM。

2.2 新的工序：大模型友好的流程

基于上述的新互動方式，現有的每一個應用都可能被重寫。是以，我們開始探索對于軟體開發的改變，也就有了《探索軟體開發新工序：LLM 賦能研發效能提升》。

對于目前的 AI 應用來說，主要有三種模式：直接 prompt 模式、知識外挂、微調。

模型 1：直接 prompt。即 API + prompt 直接接入現有的流程中，以成本效益最高的方式提效。。

模式 2：知識外挂。簡單來說，就是采用 LangChain 這樣的動态 prompt 工具，以根據使用者的不同輸入，來動态生成 prompt。又或者是，在本地采用相關性模型與算法，優化 prompt。

模式 3：微調 —— 領域知識強化。即通過微調的方式，來讓輸出結果更适合于現有的工具與流程。

不同的模式之下，帶給開發人員的挑戰也是不一樣的，依舊是由易到難。而其中的核心點是：尋找一種合理的 DSL（領域特定語言），以将現有的流程結合到 LLM。

2.3 架構設計的新變化

随着，越來越多的大語言模型有了自己的類似 LangChain 工具（如 ChatGLM-LangChain）、越來越多的程式設計語言社群出了自己版本的 LangChain 版本（如 LangChain Go）。現有的軟體架構又加來了一些新的變化：

• 插件化與智能體（Agent）。諸如于 ChatGPT Plugin、LangChain 便是采用智能體 + 插件化的方式，大大友善我們建構基于 LLM 的應用擴充，并且結合各式的 LangFlow、LLaMaHub 工具，我們可以建構更智能的流程與系統。
• 矢量資料庫。AI 的火爆使得越來越多的矢量資料進入了我們的視角，也成為了非常糾結的架構造型元素 —— 因為作為工程師的我們，還沒有建立一個全面的認知，也缺少評估資料。

而由于 Token 很貴，我們需要管理好 token，以降低 token 的花銷。我們還需要：

• 本地小模型。如 GitHub Copilot、Bloop 借助于本地的模型來進行相關性等的計算，以在本地建構動态的 prompt，而不需要消耗伺服器的資源。
• 就地機器學習。猶如幾年前，我隻是因為喜歡《TinyML：基于 TensorFlow Lite 在 Arduino 和超低功耗微控制器上部署機器學習》的書名而買了這本書一樣，我覺得 AI 不應該隻在非消費級 GPU 上能跑，而是應該無處不在。

而這些依舊隻是基于現狀的觀察，畢竟在外挂知識庫、結合知識圖譜方面，我們還有大量的工作和試驗仍然在進行中。

進階篇：面向特定場景的 LLM 應用

每個不同的通用大語言模型，受限于語料、算法、強化方式，在能力上是不同的差異。而對于現有的、開源的大語言模型來說，這種差異就更加明顯了。是以，我們需要針對于不同的場景，建構适合的政策，如程式設計場景、智能客服場景、需求完善場景等。

而由于微調後的模型是指針特定領域的，是以我們需要考慮适用于自身場景 LLM 架構方案：

• 動态的 LoRA 加載。諸如于針對不同場景下，可以動态經過不同的 LoRA 來處理資料。
• 通用大模型配合微調小模型。即通過一大一小的方式，由大模型給出工序，由小模型完善大模型不具備的細節能力。
• 多模型配合。諸如于結合 ChatGPT、StableDiffusion 和 VITS 等建構輕小說應用。

随着時間的推移，這方面的方案會越來越完善。

3.1 特定場景的模型微調

如果想利用大語言模型的能力，我們需要讓它是大模型友好的，還需要建構一個工程化的模式。也就是我們在探索 API 新工序時，總結的《大語言模型友好的 API》一文中的基本思路：

• 流程過程梳理與資産化。
• 對資産進行“語言模組化”，以适用于大模型。
• 建構 MVP 産品，并進行試驗。
• 設計增量的名額，以引導系統演進。
• 圍繞上下文的工程化思維。
• 持續回報的軟體工程，以完善系統準确度。

而對于微調來說，主要是前半部分：DSL 化、資料工程，以将現有的資料轉換為模型可用的資料，進而整合到現有的工具鍊中。諸如于，将系統架構圖轉換為 PlantUML，以這些資料微調，進而簡化現有的架構呈現方式。

3.2 上下文工程：LLM 應用的核心

在我們探索 GitHub Copilot 的過程中，有感于 GitHub 程式員在此做的努力，于是總結了《上下文工程：基于 Github Copilot 的實時能力分析與思考》。如何對于高效的建構全面的上下文，以讓 LLM 生成更準确的結果？這便是我們在未來所要做的活動。結合上述的内容，幾個潛在需要考慮的點是：

• 結合本地小模型，就地計算上下文。諸如于 Sentence-Transformers
• 本地 Token 計算，以計算最合适的上下文。
• 上下文計算政策，以提供最需要的上下文。

若是想充分運用大模型，我們需要控制好 Prompt，而其中的關鍵就是對于上下文的工程化。

總結

本文介紹了以 LLM 為核心的程式員技術指南，包括應用篇、進階篇和上下文工程。其中，應用篇介紹了 Chat 模式和大模型友好的流程，進階篇介紹了面向特定場景的 LLM 應用，上下文工程則是 LLM 應用的核心。

除此之外，文中還提到了目前 AI 應用的三種模式：直接 prompt 模式、知識外挂模式和微調模式，并介紹了針對不同場景建構适合的政策的重要性。同時，文章探讨了如何讓 LLM 是大模型友好的，并建議采用語言模組化、建構 MVP 産品并進行試驗、設計增量的名額、圍繞上下文的工程化思維和持續回報的軟體工程等方法來實作。

此外，文章還提到了随着時間推移，針對 LLM 的外挂知識庫和結合知識圖譜等方面的方案會不斷完善，并讨論了如何建構動态的 LoRA 加載、通用大模型配合微調小模型以及多模型配合等方案。

總之，本文提供了一份全面的 LLM 技術指南，為程式員和開發人員提供了在這一領域提高效率的方法和政策。