AI Fluency for builders 在教什麼？它用 4D 框架（Delegation、Description、Discernment、Diligence）把 AI 協作放回完整的建構流程：AI 最強在中間的實作，人仍要掌握同理心、判斷與交付；本文整理九堂課、診所等候時間專案的完整練習，以及筆記裡的八題課程測驗。

當 AI 幾分鐘就能生出一個可以執行的網站，建構者的工作會變得比較輕鬆，還是比較難判斷？

今天讀的是 AI Fluency for builders。課程從一個診所等候時間查詢工具開始，要求你先想清楚誰需要它、什麼才算完成，再決定哪些工作交給 AI。一路走到最後，問題已經從「AI 能不能寫出程式碼」變成「這個東西值得交付嗎」。

課程資訊一覽

官方標示 3 小時，但影片合計只有 47 分鐘。剩下的時間沒有分配給九個練習，當中還有一條從問題定義、建構、使用者測試到迭代的專案流程。這個差距很難靠課表上的數字補齊，因為「真的把東西做出來」和「看完影片」本來就是兩種不同的時間。

Introduction and AI Fluency framework（簡介與 AI Fluency 框架）

1. Welcome to AI Fluency for builders（歡迎來到為建構者打造的 AI Fluency）

課程對 builder 的定義很完整：從理解客戶問題、決定要建構什麼，到把解決方案交到使用者手中，再從後續發生的事情學習。寫程式碼只是其中一段，前後還有大量需要做判斷的工作。

這也是 4D 框架放進建構者課程後的重點：AI Fluency 不依賴某一個產品或某一種 Prompt 技巧，而是一組可以帶到下一個模型、下一個工作流程的協作能力。

課程把 AI 形容成一位能力很強、卻非常照字面行事的協作者。它需要清楚的任務、真實的背景和具體的回饋；至於問題值不值得解決、什麼結果才算好，仍要由建構者定義。

2. The 4D Framework（4D 框架）

這一堂把 4D 分成兩個迴圈。內循環處理每天和 AI 一起工作的方式，外循環則處理更大的使用決策與責任。

課程練習要求先做一份可重複使用的「建構者簡報」，把正在建構的東西、服務對象、自己的角色、限制條件，以及希望 AI 參與和不參與的地方寫清楚。這份簡報像是交接背景，讓之後每一次 AI 協作都少一點猜測。

How AI works（AI 如何運作）

3. AI capabilities & limitations（AI 能力與限制）

這堂課的核心作用，是讓建構者對 AI 的速度保持期待，也對它的盲點保持警覺。大型語言模型擅長語言運用、摘要、翻譯、解釋和模式整理；它會根據機率模式生成文字，遇到不熟悉或需要多步驟驗證的問題時，仍可能給出聽起來合理的錯誤答案。

課程練習不是請 AI 背誦這些限制，而是挑一個自己熟悉的技術主題，進行多功能性、幻覺、知識截止和推理檢查。熟悉的領域能讓你看出錯誤；換成完全陌生的領域時，這個檢查能力本身就會成為風險的一部分。

The 4D framework for builders（建構者的 4D 框架）

4. Delegation & the builder's toolkit（委派與建構者工具箱）

這一堂是整門課最有建構者味道的地方。問題從「要不要把工作交給 AI」改成「一個問題裡有哪些不同階段，每個階段適合什麼協作方式」。

課程把建構者的能力整理成六項：

實作位在工具箱中央，也是 AI 最擅長的地方；同理心、判斷和交付落在兩端，仍需要人直接接觸使用者、理解情境並承擔後果。這個分布帶出課程最重要的一句話：AI 強在中間，人的價值落在邊緣。

委派計畫不只要寫「AI 來做」。課程把協作方式分成三種：自動化 Automation 是 AI 執行、你檢查；增強 Augmentation 是你和 AI 一起完成；代理 Agency 是 AI 在你設定的界線內保有自主空間。不同階段可以有不同配置，沒有一個模式需要套用整個專案。

這個概念接著落到驗收測試。課程要求在寫任何程式碼前，先寫五到七句能判斷「完成」與否的敘述。例如：

一位使用基本智慧型手機的病患，能在 30 秒內找到目前的等候時間，且無需建立帳號。

「系統很好用」很難驗證；「30 秒內找到、無需建立帳號」則能讓人和 AI 對完成有共同定義。測試也因此成為一種精確的需求描述。

5. Description & building great things（描述與打造卓越成果）

課程把需求轉譯整理成一條 Description Chain。Prompt 只在最後一段出現，前面每一層都會影響最後得到的結果。

以診所專案為例，病患說「我想在去診所之前先看到等候時間」，這句話背後可能有正在車上照顧孩子、在不同急診之間做選擇的情境。產品需求要把它轉成「行動裝置友善的網頁、顯示預估而非精確時間、每五分鐘更新」；技術規格再處理 API、資料格式和失敗時的行為。

我在練習裡也把這些限制寫進需求：公開頁面不需要登入，只呈現科別、醫師、診間、號碼、人數和時間；不記錄個人操作紀錄，資料用途以書面約定為改善排隊流程，不拿來做個人考核。第一版先保留看診進度總表、科別與醫師搜尋，以及最後更新時間，衛教影片和流行病資訊放到後續階段。

需求訪談時，AI 的角色是即時轉錄、會後摘要和追問建議；人要判斷對方是真的沒有補充，還是在擔心被監控或取代。這個步驟讓「員工不想被系統監看」成為產品需求的一部分，而不只是訪談時的背景雜訊。

每一次轉譯都可能出錯，課程把它整理成四層鑑識分類：

• 使用者理解失敗：一開始就沒有聽懂需求。
• 需求失敗：聽懂了話，卻錯誤界定範疇。
• 規格失敗：需求方向正確，技術轉譯遺漏細節。
• 提示失敗：上游都穩固，給 AI 的指示仍然不夠好。

所以當「程式碼能運作、使用者卻不滿意」時，修正 Prompt 可能還不夠。測試通過但使用者失望，反而提供了一條很清楚的線索：沿著描述鏈往上游回查，看看哪一層把真正的意圖弄丟了。

Discernment for builders（建構者的判斷力）

6. Discernment for code（程式碼的判斷力）

「能運作」是必要條件，課程希望建構者把檢查往後推，問出成果是否準備好面對真實世界。官方逐字稿把這個檢查整理成五個視角：

課程給了一個很具體的診所例子：病患問等候時間，AI 可以很快做出一個顯示預估時間的畫面；病患真正想知道的，卻可能是接下來 20 分鐘內有沒有小兒科醫師能看診。前者通過功能檢查，後者才碰到問題契合度。

課程也建議在產生程式碼的同一次操作裡建立測試，並要求 AI 對自己的輸出做壓力測試、產生生產情境，追問「這段程式碼做了哪些生產環境的假設？」一套從未執行過的測試，無法提供真正的安全感。

使用者測試則把判斷拉回真實情境：找不屬於專案的人扮演病患，給他「今天要看小兒科，請找到大概要等多久」的任務，不解釋、不代操作，觀察他是否找得到入口、能否找到科別或醫師、資訊是否足夠做決定。測試後再問他現在大概要等多久、是否會出門，以及還缺少什麼資訊；測試者也包含年長者，並且只記錄介面卡點，不記錄身分、不拍照錄影。

7. Discernment for user experience（使用者體驗的判斷力）

AI 加快實作之後，使用者體驗會更容易成為差異。課程沒有要求建構者先成為設計師，而是要求能辨識體驗、寫出規格，再針對落差給出可執行的回饋。

「讓它看起來不錯」是一個願望，還不能直接拿去建構。診所工具的描述可以具體到：用頁面上最大的文字顯示等候時間、用單一顏色表示狀態、把最後更新時間放在看得到的位置，讓病患知道這個數字有多舊。

這裡還有一個很實用的區分：給同事的評論和給 AI 的描述是兩種產出。「這個介面感覺很雜亂」可以是合理的評論，AI 卻需要知道哪些元素該移除、資訊順序要怎麼調整、哪個操作要增加回饋。品味要被翻譯成可以執行的內容，才有辦法進入下一輪。

Tying it all together（融會貫通）

8. Stand behind what you build（為您所建造的成果負責到底）

這堂由 Anthropic 工程師 Martina 分享日常做法。使用 AI 時，你可能會成為一段自己沒有親手寫過的程式碼的擁有者；審慎的工作，就是把理解、驗證和問責補回交付流程。

她分享三個習慣：

1. 把被略過的決策攤出來。 遇到邊界情況，直接問 AI 做了哪些假設與取捨，以及有哪些安全風險。
2. 在 PR 描述裡揭露 AI 的參與。 這是提供審查資訊，不是免責聲明。AI 可能自信地使用已棄用的 API，或產生和整個 codebase 不一致的程式碼；審查者知道 AI 參與後，就能調整檢查方式。
3. 把理解自己的程式碼列成獨立步驟。 先請 AI 說明程式實際做了什麼，再確認自己能解釋它、修改它，也知道它在哪些地方可能失效。

AI 時代以前的工程實務仍然重要，甚至更需要被保留：測試固定你在乎的行為；可觀測性讓你從日誌、錯誤追蹤和儀表板發現問題；功能旗標讓你在問題出現時保留退路。交付速度變快，理解交付內容的比例卻可能變小，所以這些安全網要一起變得更清楚。

發布診所原型前，課程要求誠實回答五個問題：

「自由地製作原型，有選擇地交付」是這堂課的收束。原型的成本變低，交付的責任沒有一起消失。

這次練習留下的反思也很具體：我更清楚哪些工作可以請 AI 快速完成，哪些事情要先由我定義，再和 AI 一起討論。最後的測試仍要交給人實際使用；如果結果和想像不同，就把「快」改寫成可驗證的條件，而不是停在形容詞。

Wrapping up（總結）

9. Closure & looking forward（總結與展望）

最後一堂把 4D 收束成一個會反覆循環的工作方式：

這個順序不會固定不變。你可能從委派開始，進入描述，看到產出後回到判斷，再重新決定下一輪要怎麼委派。4D 的熟練度就在這個來回裡長出來。

課程最後給的行動是：挑一件這週真的等著處理的工作，先拆解它，再決定 AI 能在哪裡幫忙。候選項目可以是擱置中的功能、尚未整理的使用者回饋、需要先寫的技術規格，或一個因為沒有測試而不敢碰的程式碼庫。

課程練習地圖

把每堂課的練習放在一起看，會發現它們不是九份各自獨立的作業，而是一個逐層增加條件的建構流程：

這條順序也解釋了為什麼 AI 最適合大量協助實作，卻不能接管整個專案。每往下一層，都要把人的判斷寫成背景、限制、驗收測試、使用者回饋或發布決策；AI 可以加快中間的產出，人仍要守住前後的責任邊界。

Course Quiz（課程測驗）

筆記整理出 8 題。課程頁面的測驗內容為繁中，以下保留題目與答案。

1. 4D 框架中的四項能力是什麼？

答案：委派、描述、辨別、盡責。

2. 以下何者可以安全地委派給 AI？

答案：生成實作程式碼的初稿。

3. 描述鏈（Description Chain）的正確順序是什麼？

答案：使用者心聲 → 產品需求 → 技術規格 → AI 指令。

4. 為什麼應該在撰寫任何程式碼之前先撰寫驗收測試？

答案：為了從一開始就讓您和 AI 對「完成」有共同的定義。

5. 根據建構者工具包（Builder's Toolkit），AI 在哪方面最弱？

答案：同理心、判斷力與交付。

6. 「程式碼可以運作，但沒有人想使用它」是在哪個辨別透鏡上的失敗？

答案：體驗品質。

7. 在發布 AI 協助建構的成果之前，盡責（Diligence）要求什麼？

答案：理解程式碼的作用，並對結果負責。

8. AI Fluency 代表什麼意思？

答案：以有效、高效、合乎道德且安全的方式與 AI 協作。

小結

把九堂課的練習串起來，會發現它們一直在練同一件事：先把背景、使用者和限制寫清楚，再把問題拆成六種能力，讓 AI 接手它擅長的實作，接著用驗收測試、五個視角、UX 與 accessibility review，以及真實使用者回饋反覆檢查，最後才做發布決定。

這次診所等候時間專案把問題簡報、委派計畫、驗收測試、需求訪談、技術規格、原型、使用者測試、設計與無障礙檢查，以及發布前提問全部串過一遍。最明顯的收穫，是看見人機分工不能只用「會不會寫程式」來切：同理心、判斷和交付需要人把關；設計與架構適合人和 AI 一起做；實作則可以大量委派。原型可以交給 AI 加速，最後要不要掛上自己的名字，還是得自己回答。

我是 Jasper，從事軟體開發，目前專注打造 AI 工作流程。
官方圖解與完整表格在 Blog 版，和我一起探討更多 AI 議題 🚀