極點宏觀｜Financial Cloud Cloud · 建構文章
打造靜態 AWS 模擬考場背後的練習引擎
這篇文章將深入探討 Demo 背後的練習引擎，詳細說明如何透過單一 HTML 檔案，利用查詢字串（Query Strings）載入多個題庫；剖析為什麼 JSON 協定（Contract）如此重要；解析送出（Submit）與下一題（Next）的行為如何串起學習迴圈；以及行動裝置的版面設計抉擇如何建立使用者信任。我們的核心焦點在於實用的工程紀律：簡單的狀態（State）、直覺的反饋（Feedback）、可重複使用的資料（Data），以及引導出可維護行為的 Prompt（提示詞）。
免責聲明
● 專案宗旨：本平台為獨立開發專案，僅專注於推動教育探索與人工智慧（AI）研究。旨在不受任何外部力量影響的情況下，促進對現代技術的深入理解。使用者可在這個安全環境中研究複雜系統、測試創新想法並進行安全學習。
● 非商業用途：本獨立專案絕無任何潛在的商業模式，亦完全不以獲取財務營收、金錢利潤或任何具體商業價值為目的。我們的核心重點純粹在於學術發展，確保所有存取完全免費，不包含任何隱性成本、企業贊助或廣告企劃。
● 不保證正確性：由於本平台為採用實驗性人工智慧的教育工具，產出的內容偶爾可能不準確、具誤導性或不完整。所有提供的內容均以「現狀（As-is）」提供，不附帶任何明示或暗示之保證、事實正確性擔保，或對整體可靠性的任何承諾。
目錄
● 第一部分：圍繞 URL 狀態設計練習引擎
說明如何透過測驗、章節與題目的查詢參數，在沒有後端或帳號系統的情況下，讓每一次的練習狀態都能被分享、測試，並極易進行除錯。
● 第二部分：多個測驗共用單一 JSON 結構
探討可重複使用的題庫 Schema（綱要），以及為什麼一致的欄位能讓同一個渲染器支援資料、機器學習、網路、雲端營運、金融服務業（FSI）與 AI 開發等練習題庫。
● 第三部分：將送出反饋打造為學習迴圈
剖析答案判定模式：選取的答案、排序後的標準答案、結果文字、逐項選項解析，以及不使用多餘紅綠色特效的極簡 UI。
● 第四部分：將行動裝置按鈕視為產品品質的體現
展示行動版介面中加大題目、送出與下一題按鈕的重要性，以及微小的響應式調整如何讓 Demo 從「堪用」躍升為「好用」。
● 第五部分：以協定進行除錯，而非憑空猜測
將常見的氛圍式程式設計（Vibe Coding）錯誤轉化為具體檢核點：擷取失敗、遺失 JSON 檔案、答案不一致、無效的查詢字串，以及需要可預期退路（Fallback）的頁面狀態。
第一部分：圍繞 URL 狀態設計練習引擎
目標
打造一個可以分享、重新整理、加入書籤、除錯，且能直接從行銷網頁開啟的題目畫面。
Prompt
URL 查詢字串應包含測驗名稱、章節與題目，且網頁應直接跳轉至對應的題目。
結果
practice-room.html 會從 URLSearchParams 中讀取 exam、chapter 與 question。它會據此推導出 JSON 檔案名稱並進行擷取（fetch）、找出指定的章節與題目、渲染畫面，並在切換題目時動態更新 URL。
提示
● URL 是一種產品介面，而不僅僅是瀏覽器上的一段裝飾。
● 預設值應讓本機測試（Local Testing）更為輕鬆。
● 當導覽需在不離開網頁的情況下更新上下文時，請使用 replaceState。
● 保持查詢參數名稱易於人類閱讀。
● 確保每個卡片連結都能開啟一個有意義的第一題。
小結：URL 協定是最小型的路由系統。它能在沒有路由、伺服器、資料庫或驗證層的情況下，建立深層連結（Deep Links）。
第二部分：多個測驗共用單一 JSON 結構
目標
透過強制執行單一且穩定的內容結構（Shape），讓多種測驗主題共用同一個渲染器（Renderer）。
Prompt
在新增練習題庫時，應反覆強調以
aws_certified_data_exam_questions.json為模板。
結果
所有題庫均以一致的架構呈現章節、題目、選項、答案與解析。這讓同一個 UI 能夠支援資料分析（Data）、機器學習（ML）、網路（Networking）、雲端營運（Cloud Operations）、金融服務（FSI）交易、生成式 AI 以及 AI 開發等題庫。
提示
● 不要讓每次匯入的內容都自創一套 Schema。
● 將 answer（答案）欄位保持為陣列（Array），如此單選題與複選題就能共用同一套資料模型。
● 解釋（Explanations）應以選項字母作為鍵值（Key）。
● 將顯示標題（Display Titles）儲存在 JSON 中，讓 UI 能自動載入對應的標籤。
● 在宣稱系統規模之前，先用自動化工具統計題目總數。
資料夾中的題庫清單
● aws_ai_development_exam_questions.json: 共 1 章，含 20 題。
● aws_generative_ai_dev_organization_exam_questions.json: 共 4 章，含 80 題。
● aws_netowrking_core_exam_questions.json: 共 2 章，含 98 題。
● aws_fsi_trading_desk_design_exam_questions.json: 共 34 章，含 680 題。
● aws_certified_cloud_operations_exam_questions.json: 共 5 章，含 520 題。
● aws_fsi_macro_trading_exam_questions.json: 共 23 章，含 380 題。
● aws_certified_machine_learning_exam_questions.json: 共 4 章，含 460 題。
● aws_certified_data_exam_questions.json: 共 5 章，含 82 題。
● aws_certified_data_exam_questions_v1.json: 共 5 章，含 82 題。
第三部分：將送出反饋打造為學習迴圈
目標
藉由在送出答案後顯示每個選項對或錯的理由，將簡單的測驗轉化為深度學習體驗。
Prompt
送出時顯示正確與錯誤答案的解析，並明確指出不需要使用紅綠色的 UI 視覺效果。
結果
實作會先將使用者選取的答案與正確答案進行排序與比對，印出比對結果與標準答案，最後為每個選項渲染獨立的解析區塊。
提示
● 在最初的學習迴圈中，純文字反饋便已足夠。
● 在解析品質足夠扎實之前，避免使用花俏的對錯 UI 特效。
● 確保「已選取」與「正確答案」的狀態在結果中清晰可見。
● 單選題（Radio Input）與複選題（Checkbox）共用相同的送出判斷路徑。
● 為「無解析」的情況設計明顯的預設提示（Fallback），以便快速修正內容缺漏。
小結：這在「氛圍式程式設計（Vibe Coding）」中非常關鍵，因為它能防止 AI 進行過度設計。使用者所要求的並非遊戲化的計分板，而是一個安靜的自修室（Study Room）。UI 應全心服務於使用者的記憶檢索與複習。
第四部分：將行動裝置按鈕視為產品品質的體現
目標
讓模擬考場在手機上也能好用，因為許多開發者（Builders）會利用會議空檔、通勤途中或短暫的複習時間在手機上自學。
Prompt
行動版版面應將題目與答案選擇區置於上方，題目清單置於下方，並加大題目按鈕，以及送出和下一題按鈕。
結果
CSS 透過媒體查詢（Media Queries）來調整版面順序、加大按鈕點擊區域，並在螢幕變窄時，確保題目清單依舊好讀好按。
提示
● 行動版易用性不是最後的修飾（Polish Pass），而是核心行為。
● 當人們用手機學習時，按鈕大小本身就是一項重要的「學習功能」。
● 內容的編排順序遠比美化裝飾更重要。
● 保持當前題目處於高亮（Highlighted）狀態。
● 在動用複雜的元件之前，先嘗試使用簡單的 Grid 與 Flex 佈局。
小結：如果使用者常常在手機上點錯答案，這款練習產品就失敗了。按鈕變大並不只是為了解決美觀，更是為了守護使用者的專注力。
第五部分：以協定進行除錯，而非憑空猜測
目標
藉由驗證 HTML、URL 與 JSON 邊界之間的假設，讓程式在發生異常時能自己說明白原因。
Prompt
專案建置要求直接透過查詢字串（Query String）載入 JSON，後續又追加了許多測驗檔名。這代表拼字錯誤與檔案遺失是最常見的錯誤模式。
結果
播放器會擷取（catch）載入失敗的錯誤，並顯示清晰的訊息，提示使用者確認測驗查詢參數與 JSON 檔案是否存在。
提示
● 當 Fetch 失敗時，直接在 UI 顯示載入失敗的檔名，而不僅僅是印在主控台（Console）。
● 當缺少某個章節時，應有可預期的退路（Fallback）。
● 當缺少某個題目時，自動跳回第一題。
● 在新增卡片（Card）時，務必確認對應的 JSON 檔案存在。
● 新增題庫時，記得檢查答案陣列與解析鍵值。
小結：除錯的道理很簡單：如果 AI 建立了一個連結，下一道 Prompt 就應該去驗證該連結背後的檔案。在氛圍式程式設計（Vibe Coding）中，你需要養成這種「驗證反射」習慣。
1：URL 狀態
● 背景：此練習播放器需要可供分享的連結，以便在不需要伺服器端路由的情況下，直接開啟特定的測驗、章節與題目。
● 目標：讓每一個學習狀態都能透過 URL 定位。
● Prompt：使用 exam、chapter 與 question 等查詢參數導向至關聯題目。
● 結果：網頁讀取 URLSearchParams，解析出 JSON 檔案路徑，找出對應章節，並高亮顯示目前題目。
● 提示：使用穩定的參數名稱。預設導向已知的練習題庫。在切換題目時同步更新 URL。讓卡片連結到真實存在的狀態。測試複製貼上的 URL 連結。
● Demo 實證：網頁成功讀取 URLSearchParams、解析 JSON 檔案、定位章節，並突顯目前題目。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對 URL 狀態，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
2：JSON 載入
● 背景：應用程式直接從同一個資料夾載入靜態 JSON 檔案。這能大幅簡化部署作業，但檔名就變得極為關鍵。
● 目標：不需經過打包（Bundling）或撰寫後端程式碼，即可透過單一播放器載入多個題庫。
● Prompt：讓 HTML 網頁載入 URL 查詢字串對應的 JSON。
● 結果：播放器會從 exam 參數中推算出檔案名稱，並在進行渲染前擷取（fetch）該檔案。
● 提示：卡片上的測驗名稱需與實體檔名一致。顯示友善的擷取錯誤訊息。保持 JSON 架構（Schema）一致。避免隱藏的資料轉換。驗證第一題是否能正常渲染。
● Demo 實證：播放器從 exam 參數解析出檔名，並在渲染前擷取該檔案。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對 JSON 載入，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
3：答案判定
● 背景：AWS 風格的練習教材中，同時存在單選題與複選題。
● 目標：不論是單選按鈕（Radio Button）或核取方塊（Checkbox），都共用同一條答案判定路徑。
● Prompt：送出答案時應顯示正確與錯誤答案的解析。
● 結果：程式收集使用者選取的輸入、對其進行排序，接著與排序後的標準答案陣列比對，最後印出結果。
● 提示：將答案以陣列形式儲存。比對前先進行排序。不要預設只有單一答案。保持已選取狀態清晰易讀。測試包含「選兩個答案（Select Two）」的複選題。
● Demo 實證：程式收集已選取輸入、進行排序、比對排序後的標準答案陣列並印出結果。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對答案判定，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
4：多選邏輯
● 背景：多重答案（複選）題目的資料模型應與單一答案（單選）題目相同，無需拆分。
● 目標：由答案數量決定輸入控制項的類型（單選或複選），同時保留完全一致的渲染流程。
● Prompt：多選（單一答案）項目只有一個 Key；「選兩個答案（Select-Two）」的項目則有多個 Key。
● 結果：當答案陣列只有一個值時，渲染器會使用單選按鈕（Radio Inputs）；當有多個值時，則改用核取方塊（Checkboxes）。
● 提示：從資料中派生 UI 呈現。避免重複撰寫渲染器。保持輸入欄位名稱（Name）一致。進行完整答案集的比對。在題目文字中特別註明「選取兩項（Select-Two）」等提示。
● Demo 實證：當答案陣列僅有一個值時使用單選按鈕，大於一個值時則使用核取方塊。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對多選邏輯，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
5：解析渲染
● 背景：學習的價值在於解題脈絡（Rationale）與邏輯，而不只是最後得分。
● 目標：送出答案後，展示所有選項的對錯說明與解析。
● Prompt：當使用者點擊送出時，顯示正確與錯誤答案的解析，且不使用紅綠色 UI 視覺效果。
● 結果：結果區塊中會條列每個選項的已選狀態、答案狀態以及對應的解析文字。
● 提示：解釋干擾項為何錯誤。保持標準答案清晰可見。在考慮色彩特效前先使用文字說明。為沒有解析的內容提供預設回報機制。審查解析文字的品質。
● Demo 實證：結果框列出了各選項的已選狀態、答案狀態以及解析文字。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對解析渲染，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
6：章節導覽
● 背景：大型題庫包含多個章節與數百道題目，因此導覽介面必須保持簡潔易用。
● 目標：直接從 JSON 結構動態渲染出章節群組與題目按鈕。
● Prompt：左側區域橫向呈現所有章節與題目。
● 結果：題目清單會依章節將按鈕分組，並高亮標記當前題目。
● 提示：從資料動態生成導覽。保持章節標籤精簡。突顯當前狀態。在切換題目時重設（Reset）比對結果。避免手動寫死（hardcode）按鈕的 HTML 標記。
● Demo 實證：題目清單會按章節分組，並突顯當前題目。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對章節導覽，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
7：錯誤狀態處理
● 背景：靜態網頁播放器最常因為查詢字串指向不存在的 JSON 檔案，或是載入到格式錯誤的內容而故障。
● 目標：讓錯誤訊息對正在測試連結的人而言一目了然。
● Prompt：請確認 exam 查詢參數與 JSON 檔案。
● 結果：catch 區塊會變更網頁標題、顯示錯誤訊息，並呈現清晰的「空白狀態（Empty State）」操作指引。
● 提示：在 UI 上呈現失敗資訊，而非僅印在主控台（Console）。指明可能的修正方案。在出錯後仍能保持頁面可用。測試無效的 exam 參數值。不要隱藏 Fetch 錯誤。
● Demo 實證：catch 區塊修改標題、顯示錯誤訊息並呈現清晰的空白狀態指引。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對錯誤狀態處理，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
8：資料協定重複使用
● 背景：同一個渲染器能直接支援資料分析（Data）、機器學習（ML）、網路（Networking）、雲端營運（Cloud Operations）、金融服務（FSI）、生成式 AI 以及 AI 開發等練習題庫。
● 目標：藉由確保所有題庫都對齊相同的欄位結構，來維護重複使用性。
● Prompt：以 aws_certified_data_exam_questions.json 為模板。
● 結果：新增題庫變成了單純的「內容新增」，而不需要修改任何程式碼。
● 提示：使用黃金範本（Golden Sample）。檢查 answer 與 explanations 欄位。保持章節陣列結構一致。避免針對特定測驗裝飾分支 UI 邏輯。匯入完成後，統計題目數量。
● Demo 實證：新增題庫成了純粹的內容擴充，而非程式碼層面的修改。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對資料協定重複使用，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
9：結果重設
● 背景：若學習者在送出答案後切換至新題目，殘留的舊反饋可能會干擾新題目的作答。
● 目標：在導覽狀態（切換題目）改變時，即時清除作答結果狀態。
● Prompt：下一題應切換至下一道題目，並乾淨地呈現新題目。
● 結果：播放器會在切換題目時，隱藏並清空結果框（Result Box）。
● 提示：點擊下一題時重設。點擊題目按鈕時重設。渲染後保持答案未選取狀態。避免殘留舊的對錯文字。讓狀態轉換過程清晰直覺。
● Demo 實證：播放器在題目切換期間會隱藏並清空結果框。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對結果重設，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
10：下一題行為模式
● 背景：模擬考場需要一個流暢、快速切換題目的機制，而不需要強迫使用者退回清單重新點選。
● 目標：在當前章節中循序前進，並在章節結束時自動跳轉至下一章的第一題。
● Prompt：下一題：導向至下一題。
● 結果：goNext 函式會遞增題目索引值（Index）；當前章節結束時，則會推進章節索引值。
● 提示：在最後一題時停用「下一題」按鈕。同步更新查詢字串（Query String）。重設反饋狀態。在狀態改變後重新渲染。測試章節與章節之間的切換邊界。
● Demo 實證：當前章節結束時，goNext 函式會增加題目索引值或推進章節索引值。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對下一題行為模式，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
11：電腦版版面配置
● 背景：電腦版的 Prompt 將「導覽」與「作答」明確拆分：左側為題目列表，右側為當前作答區。
● 目標：善用寬螢幕寬度，降低電腦版學習者的認知切換成本。
● Prompt：電腦版網頁配置：左側為題目按鈕列表區；右側為題目與答案選擇區。
● 結果：網頁網格（Grid）配置提供了一個穩固的側邊欄（Sidebar）與較寬廣的主內容面板。
● 提示：使側邊欄支援滾動。確保主內容面板維持專注度。避免使用彈出式視窗（Modal）進行導覽。使用可預期的欄位排版。適度放大電腦版文字大小。
● Demo 實證：網頁網格提供一個穩定的側邊欄與較大的主內容區塊。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對電腦版版面配置，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
12：行動版版面配置
● 背景：在行動裝置上，若採用「側邊欄優先」的排版，會逼學習者必須先滑過整串導覽連結才能看到題目。
● 目標：重新調整頁面順序，讓當前題目置頂最先呈現。
● Prompt：行動版網頁配置：上方為題目與答案選擇區，下方為題目按鈕列表區。
● 結果：CSS 的 order 屬性規則在小螢幕上會將右側面板排在左側面板上方。
● 提示：將核心任務放在最前面。將導覽功能往下移。增加元件間距。保持按鈕大尺寸。使用長題目進行測試。
● Demo 實證：CSS 的 order 規則在小螢幕下會將右側面板移至左側面板上方。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對行動版版面配置，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
13：題目按鈕大小
● 背景：在手機螢幕上，微小的數字按鈕會令人非常沮喪，特別是題庫裡有大量題目時。
● 目標：提升行動版複習時的點擊準確度。
● Prompt：行動版：題目按鈕列表加大按鈕尺寸。
● 結果：行動版 media query 會調大題目按鈕的寬度、高度、內距（Padding）與字型大小。
● 提示：專為大拇指設計觸控區。避免過於擁擠的點擊目標。保持數字清晰易讀。使用自動折行的橫列排版。維持當前題目的高亮顯示。
● Demo 實證：行動版媒體查詢調大了題目按鈕的寬高、內距與字型大小。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對題目按鈕大小，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
14：送出與下一題按鈕加大
● 背景：「送出」與「下一題」是整個應用程式的核心互動按鈕。如果它們看起來或點起來太小，整個程式就會給人一種粗糙未完成的感覺。
● 目標：讓行動裝置上的主要操作（Primary Actions）更為舒適流暢。
● Prompt：行動版：加大「送出」與「下一題」按鈕的尺寸。
● 結果：行動版中，這些操作按鈕獲得了更大的最小高度（min-height）、內距與字型大小。
● 提示：優先處理核心操作按鈕。採用一致的高度。避免擁擠的橫向排版。確保「停用（Disabled）」狀態清晰可見。測試單手操作的便利性。
● Demo 實證：行動版中的核心操作按鈕擁有更大的最小高度、內距與字型。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對送出與下一題按鈕加大，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
15：選項渲染處理
● 背景：為了容納 AWS 風格多行且複雜的情境式答案，選項之間需要足夠的間距。
● 目標：將每個選項渲染為 <label> 元素，以便學習者點擊文字時即可直接選取該項目。
● Prompt：回應（Responses）是可能的解答；各選項的長度與複雜度應維持相仿。
● 結果：每個選項均使用 <label> 包裹 input 元素與文字內容，藉此提升無障礙性（Accessibility）與點擊體驗。
● 提示：將 input 與文字包裹在一起。使用選項字母。允許長文字自動換行。保持間距一致。避免微小、難以點選的單選框目標。
● Demo 實證：每個選項都採用包覆著 input 與文字的 label 外殼，改善了無障礙度與點選反應。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對選項渲染處理，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
16：網址狀態即時同步
● 背景：學習者在應用程式中反覆切換點選後，應能直接分享當下看到的特定題目連結。
● 目標：讓瀏覽器網址列（URL）隨時與應用程式當前狀態保持同步。
● Prompt：當使用者點擊某個題目時，跳轉至對應題目。
● 結果：updateQueryString 函式會將當前的 exam（測驗）、chapter（章節）與 question（題目）參數寫入 URL 中。
● 提示：在每次切換導覽後更新 URL。使用 replaceState 進行靜默更新（無感重新整理）。保持 exam 參數中不包含副檔名。避免觸發頁面完整重新載入。驗證分享連結的有效性。
● Demo 實證：updateQueryString 函式會將 exam、chapter 與 question 寫入網址列。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對網址狀態即時同步，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
17：捨棄框架的純粹決策
● 背景：此應用程式僅需要 Fetch API、DOM 動態產生、極簡狀態管理以及少數的事件接聽器（Event Listeners）。
● 目標：在互動模型真正需要之前，極力避免引入繁重的 JavaScript 框架。
● Prompt：建立一個不帶多餘裝飾的簡單深色模式網頁。
● 結果：模擬考場程式碼完美封裝在單一極具可讀性的 HTML 檔案中。
● 提示：小型 Demo 請直接採用原生 JavaScript（Vanilla JS）。保持狀態物件極小化。直接依資料動態建立 DOM。避開不必要的專案建置步驟（Build Steps）。只在程式碼真的變得難以維護（Pain Point）時才進行重構。
● Demo 實證：模擬考場在單一 HTML 檔案中保持良好可讀性。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對捨棄框架的純粹決策，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
18：內容品質閘門控制
● 背景：出題指南指出，干擾項（Distractors）必須具備高度誘答性，且解析必須能確實推論出標準答案。
● 目標：將內容審查無縫整合至工程開發的工作流程中。
● Prompt：遵循出題指南，並將練習題庫提升至專業水準。
● 結果：JSON 結構保留了選項層級的解析，方便日後進行獨立稽核與檢視。
● 提示：審查干擾項。確認標準答案 Key 的唯一性。避免過時的陳述。使用主動語態。保持解題邏輯符合最新版考試大綱。
● Demo 實證：JSON 結構保留了選項層級的詳細解析以利後續稽核。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對內容品質閘門控制，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
19：公開連結完整測試
● 背景：首頁（Landing Page）卡片上的每個入口，都與模擬考場對應的 URL 有著緊密的相依性。
● 目標：將每一張測驗卡片都視為播放器功能測試的獨立 Test Case。
● Prompt：新增測驗卡片，並附帶 exam_name&chapter=1&question=1 的連結。
● 結果：題庫資源庫（Library）成功轉化為一整套能直接深層連結（Deep Links）至應用程式內部的捷徑。
● 提示：實際點擊每一張新加入的卡片。仔細核對 JSON 檔名拼字。確認初始章節編號。確認第一題編號。確認標題是否能順利載入。
● Demo 實證：資源庫轉化為一系列可直接深層連結至應用程式內的完整入口。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對公開連結完整測試，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。
20：學習迴圈權責拆分
● 背景：模擬考場播放器負責實踐學習行為，而首頁（Landing Page）則負責內容的探索與分流。
● 目標：實施嚴格的權責拆分（Separation of Concerns），讓未來的修改保持單純與高維護性。
● Prompt：使用 index.html 呈現題庫目錄，並用 practice-room.html 進行題目練習。
● 結果：整個系統可以在完全不改動「答案判定邏輯」的情況下擴展目錄清單，亦能在完全不重寫「行銷文案」的前提下精進播放器的功能。
● 提示：將探索流程與實著作答分開。將所有內容完好存放在 JSON 中。以超連結作為系統邊界。避免跨檔案之間的過度耦合。明確記錄每項行為的權責歸屬。
● Demo 實證：本系統能完全獨立擴充目錄，而不必改動答案判定；同時也能精進播放器，而不用調整首頁文案。這是審查人員可以直接驗證的部分。實戰筆記應緊扣這項實證，而非流於泛泛的氛圍式程式設計空談。
● 審查檢查點：針對學習迴圈權責拆分，確認三件事：背景是否描述了真實的專案壓力、目標是否點出預期行為，以及結果是否指向檔案中或瀏覽器上清晰可見的具體實作。若三者缺一，發佈前請重新撰寫此筆記。