當 AI 幾分鐘就能生出一個可以執行的網站，建構者的工作會變得比較輕鬆，還是比較難判斷？
今天讀的是 AI Fluency for builders。課程從一個診所等候時間查詢工具開始，要求你先想清楚誰需要它、什麼才算完成，再決定哪些工作交給 AI。一路走到最後，問題已經從「AI 能不能寫出程式碼」變成「這個東西值得交付嗎」。
課程資訊一覽
| 項目 | 內容 |
|---|---|
| 課程中文名 | 為建構者打造的 AI Fluency |
| 堂數 | 官方標示 9 堂課 |
| 官方標示總時長 | 3 小時 |
| 影片總分鐘數 | 47 分鐘（4 + 7 + 12 + 5 + 5 + 5 + 2 + 3 + 4） |
| 練習預估總分鐘數 | 官方未列；九堂課每一堂都有練習，但練習頁面沒有標示預估時間 |
| 測驗數 | 1 個；本篇附筆記整理的 8 題 |
| 完成徽章 | 有 |
| 先決條件 | 建議先完成 AI Fluency: Framework & Foundations；也建議能使用 AI 工具做實作練習。課程以 Claude.ai 為例，但任何 AI 助理都可以 |
| 適合對象 | Builders：產品人員、工程師與創作者 |
| 課程來源 | Anthropic 與 CodePath 合作開發，並參考工程師與產品建構者的研究 |
| 講者陣容 | 第 1 課 Michael、Kristen；第 3 課 Kyra；第 8 課 Martina；第 9 課 Kristen、Chris |
官方標示 3 小時，但影片合計只有 47 分鐘。剩下的時間沒有分配給九個練習，當中還有一條從問題定義、建構、使用者測試到迭代的專案流程。這個差距很難靠課表上的數字補齊，因為「真的把東西做出來」和「看完影片」本來就是兩種不同的時間。
Introduction and AI Fluency framework（簡介與 AI Fluency 框架）
1. Welcome to AI Fluency for builders（歡迎來到為建構者打造的 AI Fluency）
課程對 builder 的定義很完整：從理解客戶問題、決定要建構什麼，到把解決方案交到使用者手中，再從後續發生的事情學習。寫程式碼只是其中一段，前後還有大量需要做判斷的工作。
這也是 4D 框架放進建構者課程後的重點：AI Fluency 不依賴某一個產品或某一種 Prompt 技巧，而是一組可以帶到下一個模型、下一個工作流程的協作能力。
| D | 中文 | 建構者要處理的問題 |
|---|---|---|
| Delegation | 委派 | 哪些階段適合交給 AI？哪些決定要留在自己手上？ |
| Description | 描述 | 使用者需求、產品需求、技術規格和 AI 指令，如何一路傳遞？ |
| Discernment | 辨別 | 產出能運作、運作良好、解決正確的問題嗎？ |
| Diligence | 審慎 | 我了解、驗證並願意為最後交付的結果負責嗎？ |
課程把 AI 形容成一位能力很強、卻非常照字面行事的協作者。它需要清楚的任務、真實的背景和具體的回饋；至於問題值不值得解決、什麼結果才算好，仍要由建構者定義。
2. The 4D Framework（4D 框架）
這一堂把 4D 分成兩個迴圈。內循環處理每天和 AI 一起工作的方式，外循環則處理更大的使用決策與責任。
| 迴圈 | 能力 | 核心問題 |
|---|---|---|
| 內循環 inner loop | 描述、辨別 | 我怎麼說清楚需求？收到結果後怎麼評估？ |
| 外循環 outer loop | 委派、審慎 | 這件事該不該使用 AI？使用後要承擔哪些責任？ |
課程練習要求先做一份可重複使用的「建構者簡報」，把正在建構的東西、服務對象、自己的角色、限制條件，以及希望 AI 參與和不參與的地方寫清楚。這份簡報像是交接背景，讓之後每一次 AI 協作都少一點猜測。
How AI works（AI 如何運作）
3. AI capabilities & limitations（AI 能力與限制）
這堂課的核心作用，是讓建構者對 AI 的速度保持期待，也對它的盲點保持警覺。大型語言模型擅長語言運用、摘要、翻譯、解釋和模式整理；它會根據機率模式生成文字，遇到不熟悉或需要多步驟驗證的問題時，仍可能給出聽起來合理的錯誤答案。
| 限制 | 對建構工作的影響 |
|---|---|
| 知識截止日期 | 新版本、近期事件或最新安全修補，需要另外查證或接上工具 |
| 幻覺 Hallucination | 回答的語氣很有自信，內容仍可能不存在或不正確 |
| 上下文視窗 | 一次能保留的工作記憶有限，長任務需要整理和驗證脈絡 |
| 非確定性 Non-determinism | 同一個要求可能得到略有不同的回應，重要結果要有檢查方式 |
| 複雜推理 | 多步驟數學、邏輯或系統性判斷仍容易出錯 |
| 工具與資料存取 | 沒有資料來源或專門工具時，模型無法直接知道外部狀態 |
課程練習不是請 AI 背誦這些限制，而是挑一個自己熟悉的技術主題，進行多功能性、幻覺、知識截止和推理檢查。熟悉的領域能讓你看出錯誤；換成完全陌生的領域時，這個檢查能力本身就會成為風險的一部分。
The 4D framework for builders（建構者的 4D 框架）
4. Delegation & the builder’s toolkit（委派與建構者工具箱）
這一堂是整門課最有建構者味道的地方。問題從「要不要把工作交給 AI」改成「一個問題裡有哪些不同階段，每個階段適合什麼協作方式」。
課程把建構者的能力整理成六項：
| 能力 | 核心問句 | AI 的相對強弱 | 診所專案裡的分工 |
|---|---|---|---|
| 同理心 Empathy | 我們為誰建構？他們真正需要什麼？ | 弱 | 人主導病患、護理師和院方訪談；AI 協助轉錄、摘要與提出追問建議 |
| 設計 Design | 我們該建構什麼，為什麼？ | 弱～中 | AI 提供選項，人決定 MVP 範圍與哪些功能先不做 |
| 架構 Architecture | 這個東西要怎麼組成？ | 中，人與 AI 一起做效果好 | AI 提出 Node.js、SQLite、React + Vite 等方案，人對照資料、團隊與部署限制 |
| 實作 Implementation | 怎麼寫出實際的程式碼？ | 最強 | AI 分片實作，人依獨立驗收條件逐片檢查後再合併 |
| 判斷 Discernment | 它有效、適合而且值得使用嗎？ | 弱 | AI 協助壓力測試，人依驗收測試、使用者測試和五個視角做最後判斷 |
| 上線交付 Ship / Delivery | 怎麼交給使用者，並從結果中學習？ | 弱 | AI 可協助發布說明，人負責部署、存取範圍、回饋迴圈與是否交付 |
實作位在工具箱中央，也是 AI 最擅長的地方；同理心、判斷和交付落在兩端，仍需要人直接接觸使用者、理解情境並承擔後果。這個分布帶出課程最重要的一句話：AI 強在中間，人的價值落在邊緣。
委派計畫不只要寫「AI 來做」。課程把協作方式分成三種：自動化 Automation 是 AI 執行、你檢查；增強 Augmentation 是你和 AI 一起完成；代理 Agency 是 AI 在你設定的界線內保有自主空間。不同階段可以有不同配置，沒有一個模式需要套用整個專案。
這個概念接著落到驗收測試。課程要求在寫任何程式碼前，先寫五到七句能判斷「完成」與否的敘述。例如：
一位使用基本智慧型手機的病患，能在 30 秒內找到目前的等候時間，且無需建立帳號。
「系統很好用」很難驗證；「30 秒內找到、無需建立帳號」則能讓人和 AI 對完成有共同定義。測試也因此成為一種精確的需求描述。
5. Description & building great things（描述與打造卓越成果）
課程把需求轉譯整理成一條 Description Chain。Prompt 只在最後一段出現，前面每一層都會影響最後得到的結果。
| # | 環節 | 建構者要保留的內容 |
|---|---|---|
| 1 | 使用者的聲音 | 真實的人怎麼說、語氣裡有哪些情緒，以及哪些脈絡沒有直接說出口 |
| 2 | 產品需求 | 把需求範疇化成可衡量的決定，例如行動裝置友善、預估時間、每五分鐘更新 |
| 3 | 技術規格 | 元件如何組成、彼此怎麼溝通、資料形狀與錯誤情境 |
| 4 | AI 指令 | 把技術堆疊、限制條件、邊界案例和驗收測試交代給 AI |
以診所專案為例，病患說「我想在去診所之前先看到等候時間」，這句話背後可能有正在車上照顧孩子、在不同急診之間做選擇的情境。產品需求要把它轉成「行動裝置友善的網頁、顯示預估而非精確時間、每五分鐘更新」；技術規格再處理 API、資料格式和失敗時的行為。
我在練習裡也把這些限制寫進需求：公開頁面不需要登入，只呈現科別、醫師、診間、號碼、人數和時間；不記錄個人操作紀錄，資料用途以書面約定為改善排隊流程，不拿來做個人考核。第一版先保留看診進度總表、科別與醫師搜尋，以及最後更新時間，衛教影片和流行病資訊放到後續階段。
需求訪談時，AI 的角色是即時轉錄、會後摘要和追問建議；人要判斷對方是真的沒有補充，還是在擔心被監控或取代。這個步驟讓「員工不想被系統監看」成為產品需求的一部分，而不只是訪談時的背景雜訊。
每一次轉譯都可能出錯，課程把它整理成四層鑑識分類：
- 使用者理解失敗：一開始就沒有聽懂需求。
- 需求失敗：聽懂了話，卻錯誤界定範疇。
- 規格失敗：需求方向正確，技術轉譯遺漏細節。
- 提示失敗：上游都穩固，給 AI 的指示仍然不夠好。
所以當「程式碼能運作、使用者卻不滿意」時，修正 Prompt 可能還不夠。測試通過但使用者失望，反而提供了一條很清楚的線索：沿著描述鏈往上游回查，看看哪一層把真正的意圖弄丟了。
Discernment for builders（建構者的判斷力）
6. Discernment for code（程式碼的判斷力）
「能運作」是必要條件，課程希望建構者把檢查往後推，問出成果是否準備好面對真實世界。官方逐字稿把這個檢查整理成五個視角：
| 視角 | 核心問句 | 檢查方向 |
|---|---|---|
| 功能完整性 | 它真的能運作嗎？ | 錯誤、漏洞、安全性、單元／整合／回歸／端對端測試與邊界案例 |
| 生產就緒度 | 它真的能運作良好嗎？ | 效能、可擴展性、可靠性，以及負載或 API 延遲下的行為 |
| 問題契合度 | 這是對的事情嗎？ | 解決使用者真正的問題，還是只完成了表面上被說出的需求？ |
| 體驗品質 | 它真的好嗎？ | 清晰、直覺、易用，並且符合使用者的情境 |
| 負責任的影響 | 這是負責任的嗎？ | 偏見、隱私、意外後果，以及可能被傷害或排除的人 |
課程給了一個很具體的診所例子：病患問等候時間，AI 可以很快做出一個顯示預估時間的畫面；病患真正想知道的，卻可能是接下來 20 分鐘內有沒有小兒科醫師能看診。前者通過功能檢查，後者才碰到問題契合度。
課程也建議在產生程式碼的同一次操作裡建立測試，並要求 AI 對自己的輸出做壓力測試、產生生產情境，追問「這段程式碼做了哪些生產環境的假設？」一套從未執行過的測試，無法提供真正的安全感。
使用者測試則把判斷拉回真實情境：找不屬於專案的人扮演病患，給他「今天要看小兒科，請找到大概要等多久」的任務，不解釋、不代操作，觀察他是否找得到入口、能否找到科別或醫師、資訊是否足夠做決定。測試後再問他現在大概要等多久、是否會出門，以及還缺少什麼資訊；測試者也包含年長者，並且只記錄介面卡點，不記錄身分、不拍照錄影。
7. Discernment for user experience（使用者體驗的判斷力）
AI 加快實作之後，使用者體驗會更容易成為差異。課程沒有要求建構者先成為設計師，而是要求能辨識體驗、寫出規格，再針對落差給出可執行的回饋。
| UX 原則 | 具體做法 |
|---|---|
| 清晰度 | 尊重使用者的心智模型，讓人知道產品在做什麼、要從哪裡開始 |
| 層級結構與漸進式揭露 | 讓最重要的資訊先出現，其他內容在需要時再展開 |
| 無障礙性是基本要求，而非錦上添花 | 明確要求螢幕閱讀器、色彩對比和鍵盤導覽，並建立測試案例 |
| 回饋與回應性 | 提供載入狀態、確認訊息，以及說明下一步的錯誤訊息 |
「讓它看起來不錯」是一個願望，還不能直接拿去建構。診所工具的描述可以具體到：用頁面上最大的文字顯示等候時間、用單一顏色表示狀態、把最後更新時間放在看得到的位置，讓病患知道這個數字有多舊。
這裡還有一個很實用的區分：給同事的評論和給 AI 的描述是兩種產出。「這個介面感覺很雜亂」可以是合理的評論，AI 卻需要知道哪些元素該移除、資訊順序要怎麼調整、哪個操作要增加回饋。品味要被翻譯成可以執行的內容，才有辦法進入下一輪。
Tying it all together（融會貫通）
8. Stand behind what you build（為您所建造的成果負責到底）
這堂由 Anthropic 工程師 Martina 分享日常做法。使用 AI 時，你可能會成為一段自己沒有親手寫過的程式碼的擁有者；審慎的工作，就是把理解、驗證和問責補回交付流程。
她分享三個習慣：
- 把被略過的決策攤出來。 遇到邊界情況，直接問 AI 做了哪些假設與取捨，以及有哪些安全風險。
- 在 PR 描述裡揭露 AI 的參與。 這是提供審查資訊，不是免責聲明。AI 可能自信地使用已棄用的 API，或產生和整個 codebase 不一致的程式碼；審查者知道 AI 參與後，就能調整檢查方式。
- 把理解自己的程式碼列成獨立步驟。 先請 AI 說明程式實際做了什麼，再確認自己能解釋它、修改它，也知道它在哪些地方可能失效。
AI 時代以前的工程實務仍然重要，甚至更需要被保留：測試固定你在乎的行為；可觀測性讓你從日誌、錯誤追蹤和儀表板發現問題；功能旗標讓你在問題出現時保留退路。交付速度變快，理解交付內容的比例卻可能變小，所以這些安全網要一起變得更清楚。
發布診所原型前，課程要求誠實回答五個問題：
| 檢查項 | 問題 |
|---|---|
| 理解 | 我能解釋程式實際做什麼嗎？ |
| 測試 | 驗收測試和休診、無資料、等候為零等邊界案例都通過嗎？ |
| 存取 | 哪些人沒有被這個成果服務到？ |
| 責任 | 成果會被誤讀或誤用嗎？AI 的角色有保持透明嗎？ |
| 回饋迴圈 | 上線後，我要怎麼知道它是否運作良好？ |
「自由地製作原型，有選擇地交付」是這堂課的收束。原型的成本變低，交付的責任沒有一起消失。
這次練習留下的反思也很具體：我更清楚哪些工作可以請 AI 快速完成，哪些事情要先由我定義，再和 AI 一起討論。最後的測試仍要交給人實際使用；如果結果和想像不同，就把「快」改寫成可驗證的條件，而不是停在形容詞。
Wrapping up（總結）
9. Closure & looking forward（總結與展望）
最後一堂把 4D 收束成一個會反覆循環的工作方式：
| D | 交付前要問什麼 |
|---|---|
| 委派 | 哪些階段可以安全交給 AI？哪些階段需要我的判斷？ |
| 描述 | 使用者需求、產品需求、技術規格、AI 指令和測試是否接得起來？ |
| 辨別 | 我有用五個視角檢查產出嗎？ |
| 審慎 | 我了解它、能驗證它，並且願意為它背書嗎？ |
這個順序不會固定不變。你可能從委派開始，進入描述，看到產出後回到判斷，再重新決定下一輪要怎麼委派。4D 的熟練度就在這個來回裡長出來。
課程最後給的行動是：挑一件這週真的等著處理的工作，先拆解它，再決定 AI 能在哪裡幫忙。候選項目可以是擱置中的功能、尚未整理的使用者回饋、需要先寫的技術規格，或一個因為沒有測試而不敢碰的程式碼庫。
課程練習地圖
把每堂課的練習放在一起看，會發現它們不是九份各自獨立的作業，而是一個逐層增加條件的建構流程：
| 課程 | 練習 | 接到下一步的產出 |
|---|---|---|
| 第 1 課 | 建立建構者簡報：寫清楚正在建構什麼、服務誰、自己的責任、限制，以及 AI 可以和不可以參與的地方 | 一份可重複貼給 AI 的背景文件，先把脈絡和價值觀放進來 |
| 第 2 課 | 把簡報對應到 4D，挑一個真實任務跑一輪，寫下「足夠好」的樣子，再記錄反思 | 看見目前最常使用、最容易忽略的能力，並為下一輪協作設定起點 |
| 第 3 課 | 用熟悉的技術主題測試 AI 的多功能性、幻覺、知識截止與推理能力 | 知道哪些回答可以當起點，哪些地方必須查證或自己把關 |
| 第 4 課 | 針對診所等候時間問題寫問題簡報、六項能力的委派計畫，以及五到七句驗收測試 | 決定要解決什麼、AI 在哪裡協作，以及什麼條件才算完成 |
| 第 5 課 | 從使用者心聲寫產品需求、技術規格與 AI 指令；補上訪談中的信任、隱私和資料用途，再建構第一版 | 把人的意圖逐層轉成可實作的版本，並保留需求訪談裡沒有明說的脈絡 |
| 第 6 課 | 用五個視角檢查程式，再找專案外的人扮演病患或管理員測試，寫下三項修改並標記對應視角 | 把「可以運作」和「值得使用」之間的落差變成具體修改 |
| 第 7 課 | 寫設計規格、用 AI 重新建構，評論體驗落差，再做色彩對比、螢幕閱讀器與鍵盤導覽的無障礙審核 | 把品味、使用者體驗和無障礙要求寫成下一輪能執行的描述與測試 |
| 第 8 課 | 回答理解、測試、存取、責任與回饋迴圈五個發布問題，交給三位真實使用者，迭代一次並補上驗證測試 | 做出發布、修正或停止的決定，並為交付後的學習留下入口 |
| 第 9 課 | 挑一件這週真的要處理的工作，跑一次完整 4D 檢查 | 把診所專案學到的流程帶回下一個真實任務 |
這條順序也解釋了為什麼 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 加速，最後要不要掛上自己的名字，還是得自己回答。
