IB CS SL：HL 論文完全沒有的內容

大多數 IB 資訊科學複習指南把 SL 看作「HL 減去幾個主題」，就此打住。這對內容是對的，但對考試結構、IA 期望或個案研究的測試方式來說都不對。如果你只考 SL，有一些東西絕對不會出現在你研讀 HL 重點教材的時候，因為那些教材假設你會參加第 3 論文並深入 HL 專用主題。本指南涵蓋 SL 考試和評審中真正重要的部分，而非所有人都已複習的共同課綱內容。

第 1 論文與第 2 論文的權重配置無人說清楚

SL 學生參加第 1 論文（選擇題，45 分鐘，所有主題加上預發布個案研究）和第 2 論文（結構化題目，1 小時 15 分鐘，涵蓋主題 1-4 加個案研究）。SL 沒有第 3 論文——那是 HL 專用的，涵蓋額外 HL 主題（抽象資料結構、資源管理、控制和擴展個案研究教材）。很多困惑來自學生研習 HL 專用試題樣本，納悶為何題目與課堂上看過的不符。如果你是 SL，完全忽視第 3 論文評分方案；它們測試你不必負責的內容。

個案研究應受更多關注，但多數學生沒給。它在考試前數個月發布（通常五月考季前後三月），佔第 1 論文大約 25%，也是第 2 論文的完全必考部分。在考試前至少讀三次個案研究文件：第一次為了理解，第二次標註技術詞彙（特定系統名稱、利害關係人、提及的硬體/軟體），第三次純粹記憶名稱和角色，因為第 2 論文的個案研究部分期望你精確參照情節，而非籠統帶過。

IA 的評分方式與人們的假設不同

SL 和 HL 的內部評核使用相同準則（A 至 E：規劃、解決方案概覽、開發、功能性和評估），但 SL 學生預期產出複雜度較低的作品。評審不在找功能數量少了多少——他們在看複雜度是否符合你在課堂作業中展示的實際技能水準。常見錯誤：SL 學生企圖做過度野心勃勃的應用程式，配有資料庫後端和多個使用者角色，然後無法在必要錄屏中解釋自己的程式碼，摧毀第 C 準則（開發，6 分）和 D 準則（功能性，4 分）。

SL 的更好策略：選擇一個你能在寫作 2000 字以內完整解釋的客戶端問題，解決方案有 3-5 個清晰、可測試的功能。影片和音訊證據（第 C 準則）需要實際展示 IDE、運行中的程式碼和你講述決策的語音——不是事後做簡報。評審者立即能看出差別。

第 4 主題（計算思維和程式設計）在複習中遭低估

主題 1-3（系統基礎、網路和電腦組織）獲得大部分學習時間，因為感覺更「教科書」。第 4 主題涵蓋演算法、虛擬碼和程式設計——乾行表、流程圖、遞迴與迭代思維、Big-O 式效率推理（儘管 IB 在 SL 不要求正式 Big-O 記號，只要相對效率比較）。這個主題在第 2 論文的結構化題目中不斷出現，因為圍繞它編寫情境題很容易。

在時間壓力下手寫虛擬碼練習。IB 虛擬碼慣例（使用 loop、end loop、if、then、else、end if）很具體，評審者即使邏輯正確也會為不一致的語法扣分。練習至少五題 N19、M19、N18 和 N17 考季的過去試題第 4 主題題目（如果你的課綱改變，請避免 2020 後的論文，因為本指南源自 2014 課綱首次在 2016 考試，目前版本於 2024 考季前檢查，之後新課綱接手）。

網路（主題 2）題目偏好特定詞彙勝於一般理解

SL 學生通常在概念上理解網路，但因第 2 論文要求具名術語而失分：電路交換對封包交換、特定協議層或 MAC 位址與 IP 位址的區別需精確陳述。製作一份一頁的主題 2 詞彙表，每個詞彙配 IB 措辭的一句定義，直接從課綱的詞彙表部分提取，與概念筆記分開自我測驗。

若需更結構化的課綱內容分解、演算法逐步說明或 IA 規劃支援，請查閱 Korra Studio 上的其他資訊科學和輔導區段。