AI-LECTURER 速報課｜2026-08-22｜約 24 分鐘

別再跟AI重複自己：一份「會記住需求」的虛擬碼，如何終結提示詞疲勞

取材：Show HN: Huzzah – a novel approach to coding with AI（Hacker News（AI 高人氣））
📍 真實場景
阿凱，35歲接案工程師，用AI coding agent接案寫小工具已經半年

正在幫客戶改一個報表小工具的排序邏輯，跟AI聊天視窗已經來回打了十幾則訊息

😖 卡住的地方：客戶每次說「這裡改一下」，阿凱就得重新打一長串話跟AI解釋當初的需求脈絡，AI才會做對；聊天紀錄越滾越長，AI有時候還會忘記三則訊息前講過的規則，等於整段要重講一次
💡 這課會告訴他一種新思路——把「你要的邏輯」寫成一份會一直留在專案裡、AI跟你都看得懂的宣告式虛擬碼檔案，改需求時只要改那一行，不用每次重新解釋整段脈絡

🧭 這到底是什麼（白話版）

如果你最近有用coding agent能自動幫你讀懂需求、寫程式、甚至自己執行除錯的AI工具，你只要用文字描述需求就好寫過程式，應該對這個畫面不陌生：開一個對話視窗，打一段話當作prompt你丟給AI的指令文字，通常是一般口語描述，AI就生出程式碼。這種方式其實是imperative（命令式）像下指令一樣，一步一步告訴電腦『先做這個、再做那個』的溝通，你要負責把每個步驟都講清楚。

問題是，這篇文章的作者（一位每天跟coding agent工作的軟體工程師）發現：這些對話講完就沒了。你今天跟AI解釋的需求、來回討論的細節，並不會變成專案裡正式的規格文件，只是暫時飄在聊天紀錄裡。更麻煩的是，人講話有很多是社交客套（麻煩你、對了、順便），資訊密度低，這樣寫給機器看，效率很差、還很累人。

他做了一個實驗性編輯器叫Huzzah，提出另一套玩法：不用對話，而是把你要的邏輯寫成一份pseudocode（虛擬碼）用接近人類語言、但有清楚邏輯結構的方式寫程式邏輯，不用管真正的程式語言細節檔案（副檔名.hz）。這份檔案用的是declarative（宣告式）只描述『我要什麼結果』，不用交代『怎麼一步步做到』寫法，而且它會一直留在專案裡，不會像對話一樣講完就消失。

以經典的FizzBuzz練習題為例（1數到100，3的倍數印fizz、5的倍數印buzz、都是倍數就印fizzbuzz）：傳統模式要打一整段話描述需求，之後想改成「讓使用者自己輸入要跑幾次」，還得再打一段新指令解釋「剛剛那個函式要怎麼改」。Huzzah模式則是開一個fizz_buzz.hz檔案寫虛擬碼，之後要改，就是把檔案裡loop 100那一行，改成loop n，改的是需求本身，不是又跟AI聊一次天。

🎯 為什麼值得你花時間

脈絡不會憑空消失傳統對話模式下，你解釋需求的心血，講完就變成聊天紀錄裡的雜訊，AI下次不一定記得住，你自己也很難回頭查『當初到底要什麼』。Huzzah把需求寫進持久保存的.hz檔案，等於幫專案留了一份『人類到底想要什麼』的正式紀錄。
改需求不用重繳token學費每次在對話裡重新解釋脈絡，都要花tokenAI模型處理文字的計量單位，跟花費、速度有關，講得越長、重複越多、就燒越多。宣告式的虛擬碼只需要改『需要改的那一行』，不用把整段需求再講一次，長期下來省的不只是時間，還有實際要付的AI使用費。
工程師拿回稽核與掌控感文章作者身為專業工程師，最在意的其實是『我的程式品質到底可不可靠、我還算不算專業』。一份放在專案裡、可以像程式碼一樣被版本控制像替文件做存檔紀錄，能看到每次修改了什麼，方便回頭比對或還原的虛擬碼檔案，讓他至少能清楚追蹤『需求怎麼一路演變成現在這樣』，而不是只能相信一段消失的對話。

⚙️ 它是怎麼運作的

1
寫一份.hz虛擬碼檔打開Huzzah編輯器，新增一個像fizz_buzz.hz這樣的檔案，用宣告式的虛擬碼把你要的邏輯寫出來，不用管Python或JavaScript的語法細節。
▼
2
AI依虛擬碼生成實際程式碼Huzzah背後接的LLM會讀這份虛擬碼，轉譯成一份真正可以執行的程式。你看到的是完整功能，不是零散的對話回覆。
▼
3
改需求＝改虛擬碼裡的那一行不用再開新對話解釋『之前那個要改哪裡』，直接在.hz檔案裡把對應那行（像是loop 100）改成你要的內容（像是loop n），需求變更直接發生在規格本身上。
▼
4
AI只需重新讀懂改動的那一小塊因為虛擬碼是持久保存的，LLM不用像對話模式一樣，每次都要把整段歷史脈絡重新讀一遍才知道你要什麼，溝通成本自然低很多。
▼
5
.hz檔案成為專案的意圖真相來源這份虛擬碼檔案本身可以進版本控制、被同事審查，變成專案裡『人類到底想要什麼』的正式紀錄，不再只靠一堆散落、會過期的聊天紀錄。
對話式Coding Agent vs. Huzzah虛擬碼模式
面向傳統Coding Agent（聊天模式）Huzzah（虛擬碼模式）
溝通型態命令式：一步步交代AI怎麼做宣告式：描述你要的邏輯結果
需求紀錄暫時：對話結束等於消失持久：存成專案裡的.hz檔案
修改方式重新打一段話解釋要改哪裡直接編輯虛擬碼裡對應那一行
長期成本每次都要復述脈絡，越改越貴只改動需要改的部分，成本穩定
可稽核性難以回頭查當初到底要什麼像程式碼一樣可版本控制、可審查

🔍 程式碼漫遊（點有 ● 的行看白話講解）

這是Huzzah示範用的fizz_buzz.hz虛擬碼，對照文章裡作者實際展示的寫法重建出完整版本，讓你看懂宣告式邏輯長什麼樣子。

●fizz_buzz()
💬 宣告一個叫fizz_buzz的邏輯區塊。這一行本身就是這份規格的標題，不是要AI『現在馬上執行』的指令。
● loop 100
💬 宣告這段邏輯要跑幾次。之後如果想改成『讓使用者輸入次數』，只要把100改成n，不用再開新對話解釋。
● modulo 3 ? "fizz"
💬 宣告『數字被3整除時要印出什麼』。modulo就是數學的取餘數，例如10除以3餘1，等於0就代表整除。
● modulo 5 ? "buzz"
💬 宣告『被5整除的情況要印什麼』，寫法跟上一行對稱，一看就懂規則，不用像對話模式一樣拐彎抹角描述。
● modulo 3 and 5 ? "fizz buzz"
💬 宣告『兩個條件都成立時要印什麼』。這種條件的先後順序、對應關係寫在虛擬碼裡一目瞭然，比一段話夾雜三個條件更不容易被AI誤解。

🛠️ 動手做：「疊字對話」vs「改一行虛擬碼」：親手比比看兩種模式的差異

  1. 先看左邊「AI對話模式」的第一則訊息——這是最初跟AI描述FizzBuzz需求的完整說法，右邊則是同一份需求寫成的.hz虛擬碼。
  2. 按下方按鈕，模擬「客戶提出修改需求」，連續按3次，每按一次代表一輪新的修改。
  3. 留意左邊對話框累積的字數怎麼一直往上疊加，右邊.hz檔案的總長度卻幾乎沒變。
  4. 想一想：如果你自己接案在跟AI溝通，會希望自己的需求變成哪一種紀錄？
👇 下面是活的，直接操作

🧠 工程思維透鏡（資深工程師看到的是什麼）

🔭 為什麼要放棄好懂的自然語言，換一套要學的虛擬碼語法？
資深工程師看到的其實是溝通效率的取捨。自然語言好上手，但夾雜大量社交詞彙，資訊密度低；虛擬碼犧牲了『不用學新語法』的親和力，換到的是『每一個字都是有效規格』。這跟團隊採用任何DSLDomain Specific Language，針對特定領域設計的專用語法，比通用語言更精簡但需要額外學習的取捨邏輯完全一樣——短期學習成本，換長期溝通效率。
🔭 把.hz檔案當成意圖真相來源，跟工程師平常掛在嘴邊的『Git是唯一事實來源』是同一種思維嗎？
是的——這是把版本控制的哲學，從程式碼世界延伸到需求世界。工程師本來就習慣不信任散落的口頭約定，只信任存在版本庫裡、可以回溯的東西，Huzzah做的事情，是把這套已經被驗證有效的紀律，套用在『人類意圖』這個一直以來很難被治理的東西上。
🔭 Huzzah並沒有解決『AI生出來的程式碼到底對不對』的問題，它只解決『需求怎麼記錄與溝通』——這樣切分範疇，是不是資深工程師常見的手法？
沒錯，這其實是經典的關注點分離把一個複雜問題拆成幾個各自獨立、互不干擾的小問題分開處理。程式碼正不正確，是LLM生成品質與測試把關的事；需求有沒有被準確、持久地表達，是另一件事。Huzzah選擇只啃『需求記錄』這一塊硬骨頭，而不是想一次解決AI寫程式全部的問題，這種先解一個子問題的克制，反而比貪心地想全部解決更容易做出真正有用的工具。
🔭 對話模式每次都要復述脈絡，除了浪費token，還有什麼資深工程師會在意的隱藏成本？
還有脆弱性系統很容易因為一點點條件變化就壞掉或失準，不夠穩固的問題——每次復述脈絡，都是一次『人類有沒有講清楚、AI有沒有理解對』的賭注，只要有一次沒對齊，規格就悄悄跑偏，而且沒有留下紀錄可以比對。宣告式、持久化的虛擬碼，把規格固定在一個看得到的地方，降低了這種因溝通落差累積出來的系統性風險。

📝 隨堂考（點選答案，立即回饋）

Q1. 文章裡，Huzzah的虛擬碼被形容為『宣告式』，這是什麼意思？
✅ 宣告式（declarative）是指你只描述『我要什麼』，像『被3整除要印fizz』，不用像命令式那樣交代『先...再...然後...』的每一個步驟。
Q2. 傳統coding agent對話模式，為什麼容易讓改需求的成本越滾越大？
✅ 文章指出對話是暫時、命令式的，每次要修改，都得在對話裡重新交代『之前是怎樣、現在要改成怎樣』，脈絡不斷被複述，自然越滾越多。
Q3. Huzzah的.hz檔案，在這篇文章的邏輯裡，扮演的角色最接近以下哪一個？
✅ .hz檔案的重點是把原本會消失在聊天紀錄裡的『人類真正想要什麼』，變成一份持久保存、可以回頭查閱與修改的規格紀錄。
Q4. 根據文章，以下哪一項不是作者對現有coding agent模式的抱怨？
✅ 文章完全沒有提到執行速度的問題，作者抱怨的是『意圖沒被記錄』『指令重複耗費token』『自然語言資訊密度低』這三點，跟程式執行效能無關。
Q5. 如果要幫這篇文章的Huzzah概念挑一個最貼切的類比，下列何者最恰當？
✅ Huzzah的核心精神就是把說一次就消失的口頭需求，換成持久、可回頭查閱與編輯的規格文件，而不是要完全排除人類或跳過程式碼審查。

🃏 翻牌記憶卡（先想答案，再點開對答）

宣告式（declarative）點我翻面
只描述『我要什麼結果』，不用交代『怎麼一步步做到』。
命令式（imperative）點我翻面
像下指令一樣，一步步告訴電腦『先做這個、再做那個』。
.hz 檔案點我翻面
Huzzah使用的虛擬碼檔案，是需求的持久紀錄，不會像對話一樣講完就消失。
為什麼傳統對話模式改需求越改越貴點我翻面
因為每次修改都要重新復述脈絡，對話不斷疊加，改動範圍卻沒有被縮到最小。
虛擬碼（pseudocode）點我翻面
用接近人類語言、但有清楚邏輯結構的寫法描述程式邏輯，不用管真正的程式語言細節。

✅ 離開前自測（全勾＝這課真的學會了）

0%