在前兩篇 AI 編程文章《漸近式 AI 編程模式：Unit Mesh 架構的設計思路與探索》與《未來可期的 AI 編程：到底是程序員的終極解放還是失業的開始？》里，我們已經闡述了幾年后、未來的 AI 編程帶來的影響。 而在不考慮采用諸如 Unit Mesh 新架構的情況下，我們需要在現有的架構和工程體系中融入 AI 編程。因此在這篇文章里，我們將回到現在 —— 此時此刻，我們應該如何與 AI 編程共處，讓 AI 成為我們的 Copliot。 相關的例子可以見：https://www.clickprompt.org/zh-CN/github-copilot-samples/ 自打 GitHub Copilot 正式發布以后，作為知名的開源挖坑作者，拿到了免費的版本，但是只能偷偷使用。公司明令禁止我們在公司項目使用，所以只能在業余項目、開源項目中用用。 從個人的使用體驗來說，AI 大概提升了我 20% 的編碼效率 —— 大抵是我寫的代碼都比較偏門。但是怎么說呢，抄、fork、生成的代碼質量都 TM 的不行（有可能我是 Clean Code 的忠粉），所以 ，我經常吐槽說，你在垃圾庫里是訓練不出好的模型的。 所以，簡單來說，對于效率提升是大大的，如果是 CRUD 效率更高，但是質量不行。反正，以后重寫速度比重構更快，代碼質量不重要（手動狗頭）。 除此，從個人的感受來說，編寫 Copilot 所需要的 Prompt 是需要學習門檻的。 回到真實世界，我們要用好 AI 編碼，需要考慮這個問題？ 不論是 GPT-4 發布會的 Demo，還是令大家驚艷的 Cursor.so 開發工具。就當前的 GPT 能力而言，談編程消失還太早了。GPT 只是一個復讀機，解決不了任何復雜的編程問題。復雜場景下，GPT 容易丟失部分條件，需要由人來作這好 Tasking 的過程。 在條件不充分的情況，你可以輕松讓 AI 生成一個頁面、一個函數，但是他無法達到你想要的結果。所以在，Unit Mesh 架構下，一部分程序員成為了 AI 代碼驗證師 + AI 代碼修復師，它將持續非常很長一段時間。 當前的 AI 編程只是取代你的轉譯過程：需求細分、轉換需求成代碼等。你可以看看你的提交歷史：一天提交了幾行代碼，又是哪個時間提交的。有可能你算下來了，白天都在開會，只有晚上寫代碼。我記得知乎有一個相關的問題，大部分人的回答都是平均幾十行、幾百行。當然按行數是不科學的，成長期的項目的行數是遠大于維護期的。 所以，如果你的編碼時間很長，而架構設計、需求討論等的時間很短，可能得考慮一下職業生涯，強化你的設計、拆解能力。畢竟，一旦效率提高的，還是有些程序員會失業的。 身處于各類可訪問 ChatGPT 的微信群中，遇到很多問題的時候，我經常會拋出一句：”問 ChatGPT 啊“。很多人并不會真正意識到 ChatGPT 是一個工具，唯一的樂趣可能就是：”請幫我生成一個 KFC v50 的故事“。 這也是我們創建 ClickPrompt、ChatFlow、PromptPatterns 等項目的初衷，大部分人需要先意識到 AI 能做什么。然后，才是如何寫好 Prompt，我們要摸摸我們的 Copilot 的脾氣，然后再一起干活。諸如于： 函數名直接生成代碼。 函數名 + 處理步驟生成代碼。 每種模式的背后，都很有意思。 在進一步展開 Prompt 即代碼之前，我們需要先了解一下如何寫好 Prompt。如下是，我之前放在 ClickPrompt 上面的一部分 GitHub Copilot 示例。
從我的理解來說，一個好的 Prompt 規范應該包括以下內容：
功能定義：定義所需的功能，并為模型提供足夠的上下文和信息。這可以幫助模型更好地理解其意圖并生成相應的代碼。示例 1：函數名、輸入和輸出，就能自動填充。
任務拆分：將任務拆分為小的子任務，并確保每個子任務的要求和期望輸出都非常清晰。示例 2：如上圖的按步驟設計示例，每一步都需要想好要怎么做。
確定輸入與輸出格式：Prompt 規范應該明確輸入與輸出格式和數據類型，以便模型可以正確地處理輸入。示例 3：我們添加了 i18n 的 json 過來，讓 Copilot 自動映射。
測試和調試：在生成代碼之后，應該進行測試和調試，以確保其正確性和可靠性。同時，應該為模型提供反饋，以幫助它改進其生成的代碼。示例：讓 Copilot 編寫對應的單元測試，我們對測試用例進行檢查。
避免歧義：Prompt 規范應該避免使用歧義的語言和術語，并確保在多種上下文中生成的代碼是一致的。只在出錯時，我們才會發現這條原則是有用的。
編碼標準：定義編碼標準，并確保生成的代碼符合這些標準。這可以確保生成的代碼易于閱讀和維護，并符合團隊的編碼慣例。這個就需要我們團隊去做了。
看上去有沒有像極你平時寫的偽代碼，作為一個偽代碼工程師的你，是不是發現生產力可能爆炸了。
再重復一下定義：
Prompt 即代碼是一種基于多種輸入模態的編程范式，它通過結合文本、圖像、語音等多種輸入方式來提供更豐富的上下文信息，幫助程序員更好地表達自己的意圖，并生成相應的代碼實現。Prompt 即代碼將 prompt 作為代碼的一部分，以及作為標準接口來定義生成的代碼，同時提供注釋和文檔信息以支持可讀性和可維護性。通過使用 prompt 即代碼，程序員可以提高編碼效率，同時生成更準確、更可靠的代碼實現。
當談到 Prompt 即代碼時，我們通常會將其定義為一種編程范式，它將自然語言或其他形式的輸入作為代碼生成的起點。Prompt 即代碼則讓程序員通過提供高度概括的自然語言描述或其他形式的輸入來描述他們想要的功能，然后由 AI 系統自動生成代碼。
所以，在這里我們分為兩種方式：標準的 Prompt 即代碼、多模態的 Prompt 即代碼。
文本 Prompt 即代碼是指使用自然語言或其他方式描述需求或問題，通過 AI 模型自動生成對應的代碼。Prompt 作為代碼的一部分或者核心，通過描述期望的輸入和輸出，以及需要執行的操作來生成代碼。
盡管現有的 AI 工具都是多模態的，然而自然語言是作為中間語言存在的。所以，我想將文本形式的 prompt 稱為標準的 Prompt 即代碼，它可以方便地融入現有的編程體系。
Prompt 即注釋。Prompt 作為注釋與代碼并存，在這種情況下，Prompt 與代碼共存于同一個文件中。通常，Prompt 以注釋的形式出現在代碼中，以提供必要的上下文信息和生成代碼的指令。這種方式適合于需要經常手動修改生成的代碼的場景。
Prompt 即接口。在這種情況下，Prompt 作為一個標準的接口，代碼則是實現這個接口的生成代碼。這種方式適用于對生成的代碼進行自動化測試和部署的場景，因為接口定義的一致性可以更好地保證代碼的正確性。
Prompt 即代碼。在這種情況下，版本管理工具中不再存儲代碼，而是存儲 Prompt。生成的代碼則可以根據 Prompt 來生成，Prompt 作為代碼的一部分。這種方式適合于需要頻繁更新代碼和對代碼進行版本控制的場景。
而，事實上，在我第一次將注釋加入到 ClickPrompt 中的時候，我猶豫了很久。我們的過去的編程習慣，并不允許將思考過程作為注釋到其中。
既然，它已經作為代碼的一部分加入進來 ，我們還需要進一步考慮的點是：盡可能地去修改 prompt 重新生成代碼，減少直接修改 prompt。
PS：感謝 ChatGPT 幫我考慮了這一部分。
多模態 Prompt 即代碼是指在訓練 AI 模型時，同時利用多種不同的輸入模式（如文本、圖像和語音）來提供更豐富的上下文，以幫助模型更好地理解程序員的意圖并生成相應的代碼。通過使用多模態 Prompt，AI 模型可以獲得更多的信息，并在生成代碼時更準確地反映程序員的意圖。
例如，一個基于多模態 Prompt 訓練的 AI 模型，可以同時考慮程序員在文本上下文中輸入的代碼片段，代碼所處的項目信息、數據結構信息，以及程序員所提供的圖像信息，如示意圖、流程圖等，從而生成更準確、更完整的代碼。
PS：不過，這種技術需要大量的數據和計算資源，同時需要對不同的輸入模式進行處理和整合，因此在實際應用中還需要進一步研究和優化。
過去的幾個月里，每天層出不窮的 AI 新工具，都在讓我們感受人類的智商上限和 AI 的下限。與現在的編程方式相比，未來幾個月勢必會出現新的、或者已經出現新的交互方式。
諸如于：
交互式 Prompt：在編寫代碼的過程中，模型可以提示程序員輸入，從而幫助模型更好地理解程序員的意圖，并生成更準確的代碼。例如，Unit Mesh 采用的架構模式，便是由人類和 AI 共同完成的，并由 Unit Server 自動化部署。
面向場景的 Prompt：通過提供與特定場景相關的信息和上下文，可以幫助模型更好地理解程序員的意圖并生成相應的代碼。例如，面向 Web 開發的 Prompt 可能包括與 HTML、CSS 和 JavaScript 相關的信息和上下文。
等等。
Prompt 即代碼的交互方式將會越來越多樣化和智能化，以更好地滿足程序員在不同領域和場景下的需求。
PS：最后，讓 ChatGPT 3.5 總結一下本文的后半部分（畢竟 4K Unit）。
這篇文章介紹了 Prompt 即代碼的寫作方法，多模態輸入的利用，以及 AI 模型生成代碼的方式。好的 Prompt 規范包括功能定義、任務分解、輸入輸出格式、測試和調試、避免歧義、編碼標準等要素。文本形式的 Prompt 可以使用自然語言或其他方式描述需求或問題，并通過 AI 模型自動生成對應的代碼。最后，根據具體應用場景選擇不同的 Prompt 與代碼的結合方式。
PS：我的 Copilot，寫得不行不行的。
Phodal，Thoughtworks ArchGuard 架構師，長期活躍于開源軟件社區 GitHub，目前專注于編程語言、云研發、架構治理。QCon 北京 2022 演講嘉賓。
在今年 5 月 26-27 日的廣州站中，QCon 繼續策劃并呈現了下一代軟件架構專題， 來自不同業務領域的 7 位資深架構師將分享 7 種不同的業務系統架構演進中所遇到的挑戰和解決方案，給參會者帶來全新的視角和思考。大會還從穩定性即生命線、出海的思考、AGI 與 AIGC 落地、研發效能提升、DevOps vs 平臺工程、AIGC 浪潮下的效能智能化、大前端技術探索、編程語言實戰等角度與你探討。目前大會日程已上線，點擊『閱讀原文』了解詳情，大會 9 折優惠倒計時最后 2 天，組團購票還有更多折扣，感興趣的同學聯系票務經理：15600537884（電話同微信）。
