Shire.run：Prompt即程式碼到Prompt即程式，思考Prompt的無限可能性

TL；DR：https://shire.run/

隨著 Shire 的持續迭代，我們有了一些新的體會和感觸，即 Prompt 不僅僅是一段提示詞，而是可以直接執行的程式碼。而當是可執行的程式碼時，就是可執行、可共享的智慧體。因此，我們建立了 Shire Run，一個輕量級的共享平臺，以支援使用者共享、下載、執行智慧體。Shire Run 是 Shire 智慧體共享平臺，你可以在上面下載、分享和共享程式設計智慧體（當然，現在只是一個原型，感謝卷王 @CGQAQ 建立了該網站），詳細見：https://shire.run/

為什麼 Prompt 應該是程式？理解 Prompt 的工程化演進

在過去的一年多時間裡，Prompt 不僅存在程式碼庫中，還湧現越來越多的 Prompt 即程式碼實踐。如下是我們可以看到的行業最佳實踐：

Prompt 程式碼分離。將 Prompt 程式碼與業務程式碼分離，透過變數化與模板化的方式，以更好地降低程式碼的耦合度。
Prompt 版本化管理。LLM 在持續迭代，prompt 也會隨之變化。透過版本化管理，可以更好地管理 prompt 的變化，回溯到歷史版本，檢查 prompt 的變化。
模組化 Prompt 設計。不同背景下，最終 prompt 會由大量的不同上下文所構建。在程式碼邏輯設計上，體現的就是模組化設計，或者透過登錄檔、依賴注入等方式來實現。
Prompt 單元測試。AI 返回的結果會存在一定的不確定性，因此我們需要檢查必要的格式、欄位等，測試是最好的方式。在智慧體的場景下，我們還需要預期它可以呼叫到對應的工具和函式。
Prompt 整合測試。對於複雜的場景，我們需要對整個 prompt 的執行流程進行測試。這種測試通常會涉及到 IDE 的互動、AI 模型的呼叫等等。
Prompt 組織。對大型專案，我們還面臨如何更好透過目錄結構、檔案結構來組織 prompt 的挑戰。

當然了，對於 AI 平臺來說，可能還會存在 prompt 的協作等等實踐。舉一個簡單的例子，我們計劃使用 prompt 來生成補全程式碼，那麼 prompt 可能是這樣的：

補全程式碼。
-相關上下文：${selection.ast}
-游標前程式碼：${selection.before}
-游標後代碼：${selection.after}

程式碼中包含了一系列的變數，以將 prompt 與程式碼解耦出來。而這個簡單的 prompt 在實際使用時，還需要針對模型進行調整、對結果進行後處理等等。當我們的 AI 應用變得越來越複雜時，我們需要更好地管理我們的 Prompt。

Prompt 即程式：可執行的 Prompt 程式碼

隨著 AI 應用工程化的深入，越來越多的 prompt 在直接在應用中直接執行。即由 prompt 生成平臺所需要的資料、語言、程式碼等，再基於這些資料動態建立對應的應用程式，諸如於低程式碼平臺、AI IDE 等等。與此同時，工程化 + 智慧體也讓應用變得越來越智慧：

AI 平臺自帶的 Code Interpreter 就可以直接執行，生成表格、圖表等。
IDE 外掛在自動化生成測試，會根據結果來執行測試，並在測試失敗時，自動化生成對應的修復程式碼等等。
低程式碼平臺會直接將 prompt 生成的程式碼，直接執行，以生成對應的程式、應用。

因此，在我看來：

Prompt 即程式是將 Prompt 視作一段可以像程式碼一樣執行的程式。它不僅僅是簡單的提示詞，而是透過模板化、模組化等方式進行設計和管理，能夠生成動態的功能和操作。就像軟體開發中的程式碼一樣，Prompt 也可以進行版本控制、單元測試、整合測試等，從而確保它在不同環境中的穩定性和可維護性。

而事實上，它們可以抽象為一個模式：DSL（領域特定語言） + Runtime（執行環境）。對於現在的 LLM 能力而言，直接生成複雜的程式是不靠譜的，如果想駕馭這種複雜度，我們需要在 DSL 做更多的抽象與繁瑣設計，諸如於：

提供原子操作能力。如將與應用的互動、與 IDE 的互動、與 AI 模型的互動等等，抽象為一個個的原子操作。
封裝複雜邏輯（繁瑣設計）。將複雜的邏輯，如程式碼生成、程式碼檢索、程式碼分析等等，封裝為一個個的函式。

那麼，剩下的就是 Runtime 的設計。在 AI IDE 場景下，Runtime 是 IDE，在手機 APP 場景下，Runtime 是 APP，諸如此類。也因此，我們還需要在 Runtime 中提供這種基礎能力，以支援這種 DSL 的執行，比如 AutoDev 直接提供 /refactor 的指令，以支援程式碼重構。