Huzzah：一種用於 AI 輔助編碼的宣告式偽代碼方法

Huzzah 為 AI 編碼引入了宣告式範式

Huzzah 是一款實驗性編輯器，旨在將 AI 輔助軟體開發從長篇、指令式的聊天提示詞（chat prompts）轉向持久、宣告式的偽代碼模型。開發者不再透過一系列瞬時的聊天訊息來描述程式碼庫的變更，而是使用偽代碼在 .hz 檔案中寫下其意圖，接著編輯器會利用這些內容自動生成並更新相應的原始碼。

這種方法解決了目前 AI 編碼代理（agent）工作流中的三個主要摩擦點：

人類意圖的流失：在傳統的代理工作流中，提示詞往往會被丟棄，導致無法留下可靠的記錄來解釋為何進行了特定的變更。
指令式效率低下：基於聊天的指令描述的是「變更」（例如，「將迴圈改為接收輸入」），而非應用程式的「期望狀態」，這會導致重複的指令並浪費 token。
散文疲勞：為每一次技術變更撰寫詳細的自然語言描述既繁瑣，且內容往往包含更多社交客套話而非實際的資訊內容。

Huzzah 工作流：偽代碼即原始碼

在 Huzzah 範式中，提示詞不再是瞬時的訊息，而是一個持久的檔案。工作流從對話轉向了設計過程：

宣告式定義：開發者建立一個 .hz 檔案並寫下邏輯的偽代碼表示。例如，與其要求 AI「建立一個迴圈 100 次並列印 fizz/buzz 的函式」，開發者會寫下一段簡潔、結構化的偽代碼區塊來定義邏輯。
自動生成：儲存 .hz 檔案後，Huzzah 會生成實際的可執行程式碼。
持久化迭代：若要修改行為，開發者只需更新偽代碼檔案。Huzzah 會擷取偽代碼的差異（diff），並將其作為提示詞來重新生成受影響的原始碼。

這種方法讓偽代碼既能作為提示介面，也能作為永久的開發者文件，因為它以一種可讀且與語言無關的格式明確表達了人類的意圖。

技術權衡與限制

雖然 Huzzah 提供了一種更簡潔的方式來表達意圖，但也引入了幾項技術挑戰：

擴展性：這種方法在大型且複雜的程式碼庫上的有效性尚未得到證實。
依賴管理：在偽代碼中表達跨檔案的依賴關係以及複雜的匯入/匯出（imports/exports）比在標準程式語言中更困難。
工具鏈缺口：標準語言伺服器協定（LSP）功能（如自動補全和跳轉至定義）在偽代碼中並非原生可用，儘管作者指出這些功能未來有可能被生成。
領域專業知識：此方法要求使用者具備足夠的領域專業知識來撰寫結構化偽代碼；缺乏此專業知識的使用者可能會覺得自然語言散文更容易。

社群觀點與評論

軟體工程師之間的討論凸顯了對於 Huzzah 的看法分歧：一方認為 Huzzah 是抽象化必要的演進，另一方則認為這是在重新發明現有的做法。

支持該方法的論點

一些開發者認為一種「機器-人類混合語」（machine-human patois）正在興起——這是正式程式碼與模糊散文之間的中間地帶。支持者建議，將意圖持久化為耐用的產物，可以使 AI 編寫的程式碼庫更容易進行審計與維護。

"I’d feel much more confident to use a vibe-coded library where I can read the human-written intentions than one where I just see a lot of AI-written code."

反對該方法的論點

批評者認為 Huzzah 可能是在重新發明現有的軟體工程學科。有些人指出，行為驅動開發 (BDD) 與 Gherkin 語法 是定義宣告式行為的既定方式，且這些行為也可以透過測試來執行。

其他批評者建議，這種方法本質上是一種「現在編譯需要花錢的簡潔語言」，因為它依賴隨機性的 LLM 來進行轉譯。此外，也有人擔心這會進ทำให้開發者與解決困難邏輯錯誤所需的批判性思考進一步脫節。

"The problem is not writing English, it’s the rate of change... you’re delegating the thinking to a machine, you’re just barking what you want at it, incessantly, endlessly."

其他建議

幾位貢獻者建議，與其使用偽代碼來生成新程式碼，不如採取相反的方向——將龐大的現有程式碼庫分解為簡短的偽代碼摘要——這對於管理遺留系統（legacy systems）會更有價值。