你是否曾經(jīng)想過，當(dāng)你在 Intellij IDEA 中輸入一個段代碼時，GitHub 是如何給你返回相關(guān)的結(jié)果的？其實，這背后的秘密就是圍繞 Prompt 生成而構(gòu)建的架構(gòu)設(shè)計。

Prompt 是一個輸入的文本段落或短語，用于引導(dǎo) AI 生成模型執(zhí)行特定的任務(wù)或生成特定類型的輸出。不同的 Prompt 會導(dǎo)致不同的搜索結(jié)果，因為它們會影響模型對信息的處理方式。而通過巧妙構(gòu)建Prompt，我們可以讓模型在廣泛的任務(wù)中執(zhí)行特定的操作，從而提高搜索效率和用戶滿意度。

Prompt 的設(shè)計不僅影響 AIGC 模型的行為和輸出，還影響軟件架構(gòu)的設(shè)計和優(yōu)化。那么，Prompt 和軟件架構(gòu)之間有什么關(guān)系呢？為什么 Prompt 對軟件架構(gòu)如此重要呢？

在本文中，我們將探討這一關(guān)系，并基于我們對一些卓越的人工智能生成代碼（AIGC）相關(guān)應(yīng)用的研究，以及一些內(nèi)部 AIGC 應(yīng)用的觀察，這些應(yīng)用都是基于 LLM 優(yōu)先理念下來構(gòu)建和設(shè)計軟件架構(gòu)的。這些應(yīng)用包括：

• GitHub Copilot：一個基于 OpenAI Codex/Codex 2 模型的代碼生成器，它可以根據(jù)用戶提供的注釋或代碼片段來生成完整的代碼。

• JetBrains AI Assistant：一個圍繞開發(fā)人員日?；顒訕?gòu)建的伴隨性 AI 輔助的 IDE 插件。

• Bloop：一個根據(jù)用戶提供的自然語言描述或問題，來生成對應(yīng)答案或者代碼的工具。

而究其背后的原因，我想只有圍繞 LLM 優(yōu)先來考慮架構(gòu)，才有可能對應(yīng)這種復(fù)雜性。

PS：本文討論的背景是復(fù)雜的 AIGC 應(yīng)用，諸如于 Copliot 型、Agent 型應(yīng)用，普通的 AIGC 不具備這種復(fù)雜性。

AIGC 優(yōu)先應(yīng)用的架構(gòu)特征（初步）

在我們先前的文章《上下文工程：基于 Github Copilot 的實時能力分析與思考》里，介紹了 Copilot 如何結(jié)合用戶行為，以及當(dāng)前代碼上下文，光標(biāo)位置（行內(nèi)、塊間、塊外）來生成三種不同類型的代碼。其基本特質(zhì)便是圍繞用戶的潛在意圖，來設(shè)計對應(yīng)的生成內(nèi)容。并結(jié)合當(dāng)前的代碼文件，來調(diào)整生成的內(nèi)容，以符合對應(yīng)語言的基本語法。

而 Bloop 則是圍繞于檢索增強生成（RAG）來推測用戶的潛在意圖，諸如通過查詢擴展的方式，來更好地匹配潛在的代碼。并通過輸出更多的上下文交互過程，以讓用戶來調(diào)整自己的問題，獲得更準(zhǔn)確的答案。

再結(jié)合 JetBrains AI Assistant 的語言上下文模塊化架構(gòu)，我們簡單將復(fù)雜 AIGC 應(yīng)用總結(jié)了三個核心特征（未來還將繼續(xù)優(yōu)化這個版本）：

1. 感知用戶意圖，以構(gòu)建清晰的指令：?這一特征涉及捕獲和分析用戶的操作，以全面理解用戶的目標(biāo)和偏好。應(yīng)用程序需要能夠識別用戶的需求，提供相應(yīng)的內(nèi)容生成方案，從而建立清晰的指令。這可以包括收集和解釋用戶輸入，行為分析，以及利用歷史數(shù)據(jù)來更好地了解用戶需求。通過這個特征，AIGC 應(yīng)用可以更好地滿足用戶的期望。

2. 圍繞用戶意圖地交互設(shè)計，以讓用戶輸出更多上下文：?這個特征旨在創(chuàng)建友好和靈活的用戶界面，鼓勵用戶提供更多上下文信息。用戶通常通過輸入和修改內(nèi)容生成的參數(shù)和條件來表達(dá)他們的需求。此外，AIGC 應(yīng)用還可以隱式地獲取用戶的上下文信息，例如 v0.dev、數(shù)據(jù)智能和流式交互。這些信息可以包括用戶的操作歷史、上下文語言信息、位置信息等，以提供更個性化和智能化的內(nèi)容生成服務(wù)，從而增強用戶體驗。

3. 基于數(shù)據(jù)的反饋改進(jìn)與模型優(yōu)化：?這一特征通過不斷收集和分析用戶對生成內(nèi)容的反饋，如評分、評論、分享等，以實現(xiàn)內(nèi)容生成模型和算法的不斷調(diào)整和優(yōu)化。通過利用這些反饋數(shù)據(jù)，AIGC 應(yīng)用可以提高生成內(nèi)容的質(zhì)量和多樣性，確保用戶滿意度不斷提高。

而對于這些應(yīng)用來說，并不是需要復(fù)雜的 prompt 技巧。技巧性、復(fù)雜的 Prompt 在工程化面前都是災(zāi)難性的。

復(fù)雜 AIGC 應(yīng)用的基本 Prompt 策略

對于復(fù)雜 AIGC 應(yīng)用來說，難點是在于?Prompt 的策略，也就是如何構(gòu)建自動的上下文收集？。通常來說，其設(shè)計過程要考慮：

• 魯棒性：Prompt 的設(shè)計應(yīng)該能夠處理各種輸入情況，并在不同任務(wù)和領(lǐng)域中表現(xiàn)良好。它們應(yīng)該是通用的，而不僅僅適用于特定任務(wù)。

• 評估和反饋循環(huán)：Prompt 設(shè)計的成功與否通常需要不斷的迭代和反饋。開發(fā)者可能需要花時間來調(diào)整Prompt以提高模型的性能，這也可能影響軟件架構(gòu)。

而魯棒性也意味著，復(fù)雜的 Prompt 會變成一種災(zāi)難，因為作為一個生成模型，它無法考慮到你的每個 MUST/HAVE TO/必須，以及你交給他的，你不應(yīng)該 xxx。太長的 prompt，不僅顯得 LLM 很愚蠢，也間接地讓你覺得自己很愚蠢。你應(yīng)該將長 prompt 分為多個 stage（人及 GPT 會在閱讀很長的文本之后，忽略這句要求），即復(fù)雜問題應(yīng)該先進(jìn)行拆解 —— 參考領(lǐng)域驅(qū)動設(shè)計的方式。

在 AIGC 工具里，我們可以將 Prompt 分為多種類型，強指令型，強結(jié)果型。

Prompt 策略 1：精短地指令，精準(zhǔn)上下文

在非聊天的場景下，諸如于編寫文檔、編寫報告等等，工具中的指令往往都非常簡潔：?Write?documentation?，而為了讓 LLM 生成更精準(zhǔn)的結(jié)果，我們還需要進(jìn)行更多的上下文補充，諸如于：

Write?documentation?for?given method?，它結(jié)合著不同的語言的語法形式（類聲明、方法聲明等）。

隨后，還需要考慮不同的文檔工具，諸如于?write?PHPDoc?。而使用 Python 語言時，則又需要使用?"""?來作為文檔的起始標(biāo)志。而為了編寫更規(guī)范的文檔，還需要結(jié)合?use?@param?tag?來進(jìn)行示例，告訴 LLM 應(yīng)該寫什么樣的文檔。

那么，問題就來了，要讓 AIGC 構(gòu)建出這個上下文，我們需要：

• 獲取語言相關(guān)的信息，諸如版本信息等

• 配置或者獲取該語言的文檔工具

• 獲取待寫文檔的代碼信息

• 如果是方法的話，需要提醒?method has?return?type?。

• 根據(jù)不同的語言配置基本的規(guī)范。如 Python 到底是用 Tab 還是用空格。

指令本身很簡單，但是要構(gòu)建精準(zhǔn)的上下文，則是要回到工程化問題上來。

Prompt 策略 2：圍繞結(jié)果設(shè)計交互，獲取用戶的上下文

在非編碼場景的其他 RAG 場景之下，通常我們會圍繞于：感知-分析-執(zhí)行 來分析用戶的意圖，進(jìn)而根據(jù)用戶的意圖來生成更多的上下文。先看個數(shù)據(jù)問答的示例：

意圖：xx （子公司）去年營收？
觀察：...
思考：請選擇查詢的數(shù)據(jù)子項？
操作：選擇 xx 領(lǐng)域。
….
最終輸出：圖表（柱狀圖等）

這里就存在一個問題，用戶最終要的是圖表，還是文字信息？我們要不要幫用戶做這個決定？如果要做這個決定，那么我們是不是需要根據(jù)用戶以往的歷史經(jīng)驗？

所以，在這個場景里，在進(jìn)入解決方案之前，我們一直在圍繞用戶的問題進(jìn)行澄清。

圍繞 Prompt 策略的架構(gòu)設(shè)計示例

現(xiàn)在，再回到架構(gòu)設(shè)計上，讓我們看看對應(yīng)的示例。

語言插件化架構(gòu)

我們在理解了 JetBrains 的 AI 工具的架構(gòu)設(shè)計上，參考（復(fù)制）了相似的設(shè)計。在 JetBrains 的 IDE 里，不同的語言后綴會調(diào)用不同的 IDE 插件功能來實現(xiàn)對應(yīng)的重構(gòu)等等的方式。所以，在設(shè)計對應(yīng)的功能時，也是將不同的語言劃分到不同的模塊，以借由其實現(xiàn)其動態(tài)加載。

舉個例子：為了生成測試代碼的準(zhǔn)確性，我們需要獲取被測試代碼、測試框架等信息，因此需要語言上下文、技術(shù)棧上下文、相關(guān)上下文、以其它上下文。

所以，仔細(xì)拆解下來，我們就需要圍繞于插件化架構(gòu)來構(gòu)建 IDE 插件，即在 Core 模塊里定義 Prompt 和我們的抽象接口，在不同語言模塊里，實現(xiàn)對應(yīng)的上下文獲取方式。

而如果我們只是一個簡單的聊天功能，就不需要這么復(fù)雜的架構(gòu)，只是生成內(nèi)容的精準(zhǔn)性會下降。

發(fā)散-收斂式上下文

而在諸如于 Bloop 這一類以 RAG（檢索增強生成） 為主的應(yīng)用設(shè)計里，更重要的則是如何從不同渠道豐富用戶的上下文，其難點主要在于如何匹配最相似的答案。

發(fā)散。其使用方式有多種多樣的，諸如于分析用戶的意圖，使之能進(jìn)行內(nèi)容檢索 —— 代碼檢索、文檔檢索、網(wǎng)絡(luò)檢索等等。

收斂。結(jié)合發(fā)散的結(jié)果，對檢索到的內(nèi)容進(jìn)行處理，進(jìn)而做最后的過程呈現(xiàn)與內(nèi)容的總結(jié)。

而這部分內(nèi)容本身是作為策略的一部分存在的，它可以作為基礎(chǔ)設(shè)施的一部分，諸如 LLM SDK，又或者是代碼服務(wù)。

其它場景

而在其他一些場景中，諸如于 Code Review，我們會結(jié)合提交信息中的 story id、代碼變更、業(yè)務(wù)信息，三部分來進(jìn)行最后的總結(jié)。與語義化代碼搜索的場景相似，但是與普通的 Code Review 相比，為了達(dá)成更精準(zhǔn)的上下文，則花費的成本更高。

平衡 Prompt 策略與架構(gòu)演進(jìn)路線

盡管 AIGC 能顯著地加速我們編寫代碼的時間，但是花費更多的時間在上下文架構(gòu)上，則意味著架構(gòu)的復(fù)雜度。我們是否應(yīng)該花費如此多的時間在構(gòu)建 prompt 上，它帶來的 ROI 是否合理，就需要根據(jù)不同的場景去考慮。

除此，我們還需要圍繞于 Prompt 演進(jìn)策略，來構(gòu)建架構(gòu)的演進(jìn)路線。諸如于，對于一個 Code Review 工具，我們應(yīng)該如何去規(guī)劃？

• 實現(xiàn)基本的 code review 接口調(diào)用與 comments 調(diào)用？

• 結(jié)合提交信息，來 review 代碼，分析兩者是否一致？

• 從提交信息中獲取業(yè)務(wù)上下文，來分析代碼是否與業(yè)務(wù)一致？

• ……

隨后，則是根據(jù)我們能獲取到的數(shù)據(jù)，來設(shè)計最終的 prompt，并以此作為版本來規(guī)劃架構(gòu)演進(jìn)路線。

小結(jié)

由 ChatGPT 生成：

本文討論了復(fù)雜 AIGC 應(yīng)用中的 Prompt 和架構(gòu)設(shè)計的關(guān)鍵性。Prompt 是引導(dǎo) AI 生成的文本段落，其設(shè)計直接影響AIGC應(yīng)用的性能。

復(fù)雜 AIGC 應(yīng)用具有三核心特征：感知用戶意圖、設(shè)計用戶交互以獲取更多上下文和基于數(shù)據(jù)反饋的模型優(yōu)化。兩種 Prompt 策略包括精簡指令和圍繞結(jié)果的設(shè)計，有助于構(gòu)建更有效的Prompt。示例架構(gòu)設(shè)計采用語言插件化，可根據(jù)不同語言后綴實現(xiàn)不同功能，提高 AIGC 應(yīng)用的多語言支持。

文章突出強調(diào) Prompt 的重要性，指出 Prompt 和架構(gòu)設(shè)計在提高生成內(nèi)容質(zhì)量和用戶滿意度方面至關(guān)重要。在實踐中，需要平衡 Prompt 策略和架構(gòu)設(shè)計，以滿足不同 AIGC 應(yīng)用的需求。