# L21202 AI 導入規劃 — 模擬試題 30 題

> 題型：四選一單選題（iPAS AI 規劃師中級 標準題型）
> 教材來源：`chunks/L21202.txt`（每題解析末標 chunks 行號）
> 視覺輔助：`output4/L21202_AI導入規劃/images/` 投影片
> 命題原則：用易混淆概念設計干擾項（同類項換位、屬性錯配、定義 partial swap）

---

## 第一部分｜導入規劃定位與核心原則（Q1–Q4）

### Q1
下列關於 AI「導入規劃」階段角色的敘述，何者**正確**？
- (A) 完成初步評估後，將「可行性與價值潛力」轉化為「具體可執行的規劃行動」的承上啟下階段
- (B) 完全等同於概念驗證（POC）階段，無區別
- (C) 僅是行銷階段，與技術部署無關
- (D) AI 導入規劃應採用「一體適用」固定流程，不需依產業調整

**答案：(A)**
解析：教材定義「『導入規劃』扮演著承上啟下的核心角色 ⋯⋯ 將『可行性與價值潛力』轉化為『具體可執行的規劃行動』」；同時強調無法採用一體適用模式，需依組織條件調整，(D) 與此矛盾。（chunks line 9–11）

---

### Q2
下列關於不同產業 AI 導入優先聚焦項目的搭配，何者**正確**？
- (A) 製造業重視感測器資料的整合與即時性；金融業聚焦資料安全與法規遵循
- (B) 製造業聚焦法規遵循；金融業聚焦感測器整合
- (C) 兩產業都僅關注 GPU 採購
- (D) 兩產業優先項目完全相同，無差異

**答案：(A)**
解析：教材明示「製造業可能更重視感測器資料的整合與即時性，金融業則聚焦於資料安全與法規遵循」。(B) 屬常見干擾項，把產業焦點互換。（chunks line 11）

---

### Q3
下列何者**並非**教材列舉的導入規劃「核心原則」？
- (A) 情境／目的導向：根據企業產業特性與業務需求定義專案目標與範疇
- (B) 資源盤點：評估現有資料、技術人力與預算
- (C) 彈性調整：因應專案推進中的變動（如需求改變或技術瓶頸）動態調整
- (D) 不顧成本，照表操課，不可因現實調整

**答案：(D)**
解析：教材明示導入規劃核心原則 = 情境／目的導向 + 資源盤點 + 彈性調整，並指「導入規劃的重點不在於照表操課，而是靈活應對實際狀況」。(D) 直接反向。（chunks line 25–31）

---

### Q4
若企業原計畫三個月內導入 AI 產能預測，但發現感測器資料不完整，**最合理**的彈性調整為何？
- (A) 強行照原計畫上線，忽略資料品質問題
- (B) 先花時間優化資料收集流程，再進行模型開發
- (C) 立即放棄整個 AI 導入計畫
- (D) 不顧資料品質直接擴大導入範圍

**答案：(B)**
解析：教材案例「某企業原計畫三個月內導入 AI 產能預測，但發現感測器資料不完整，於是調整策略，先花一個月優化資料收集流程，最終專案成功上線並提升產能效率 15%」。(A)(C)(D) 與彈性調整原則矛盾。（chunks line 31）

---

## 第二部分｜資源盤點與人力角色（Q5–Q10）

### Q5
下列關於專案負責人（Project Manager）的職責敘述，何者**錯誤**？
- (A) 負責整體專案的協調與進度管理
- (B) 制定時程計畫、追蹤里程碑（如資料準備完成）
- (C) 與利害關係人溝通進度、解決跨部門衝突
- (D) 專注於模型設計、訓練與優化，撰寫 Python 程式碼

**答案：(D)**
解析：(D) 是 AI 模型開發者的職責；專案負責人專責整體協調、時程、跨部門衝突、利害關係人溝通。常見干擾項把 PM 與 AI 開發者職責對調。（chunks line 41、51–53）

---

### Q6
下列職責搭配何者**正確**？
- (A) 資料工程師：負責資料收集、清理與整合，熟悉資料庫管理與 ETL 流程
- (B) 資料工程師：專責模型設計與訓練，熟悉 TensorFlow、PyTorch
- (C) UI/UX 設計師：負責伺服器架構與資料流設計
- (D) 業務顧問：專責壓力測試與系統穩定性驗證

**答案：(A)**
解析：(A) 是資料工程師正確職責；(B) 是 AI 模型開發者；(C) 是系統架構師；(D) 是測試工程師。常見干擾項跨角色職責對調。（chunks line 47–49、51–53、55–57、61、63–65）

---

### Q7
系統架構師（System Architect）在 AI 專案中**主要**負責下列何者？
- (A) 設計 AI 專案的技術架構與部署方案，規劃伺服器架構、資料流設計與 API 介接
- (B) 收集顧客評論並做情感分析
- (C) 撰寫財報與股東報告
- (D) 整理會議紀錄並寄送內部公告

**答案：(A)**
解析：教材明示「系統架構師：負責設計 AI 專案的技術架構與部署方案，確保模型能整合至現有系統 ⋯⋯ 規劃伺服器架構、資料流設計與 API 介接」。（chunks line 61）

---

### Q8
測試工程師（Test Engineer）在 AI 專案的**核心職責**為何？
- (A) 驗證模型效能與系統穩定性，執行壓力測試並檢查輸出是否符合預期
- (B) 制定預算與資金來源規劃
- (C) 招聘 AI 模型開發者
- (D) 設計 UI/UX 介面

**答案：(A)**
解析：教材明示測試工程師「負責驗證模型效能與系統穩定性，確保部署後無重大錯誤 ⋯⋯ 執行壓力測試，模擬高流量情境下的模型反應，並檢查輸出結果是否符合預期」。（chunks line 63–65）

---

### Q9
下列關於 AI 專案常見硬體資源的敘述，何者**錯誤**？
- (A) GPU 伺服器（如 NVIDIA A100）可加速模型訓練與推論，適合影像辨識或 NLP
- (B) 雲端平台（如 AWS、GCP、Azure）提供彈性擴展的儲存與運算
- (C) 本地運算設備適合小型試辦或資料敏感性高的場景，例如醫療專案本地處理病患資料
- (D) AI 專案完全不需任何硬體資源，僅靠紙筆即可訓練深度學習模型

**答案：(D)**
解析：教材明列三類硬體需求（GPU 伺服器／雲端平台／本地運算設備），且 AI「深度學習或大資料處理階段，硬體資源配置直接影響效能與時程」。(D) 違背現實。（chunks line 71–77）

---

### Q10
AI 開發**常見**的開發工具與框架搭配中，下列何者**最完整且正確**？
- (A) Python + TensorFlow / PyTorch + Spark/Hadoop（大數據處理）+ Git（版本控制）
- (B) 純 Excel + Word，不使用任何程式語言
- (C) 僅 Photoshop + Illustrator
- (D) 僅 MySQL + Apache，無深度學習框架

**答案：(A)**
解析：教材明列「Python 程式語言、TensorFlow、PyTorch 等深度學習框架，並可利用大數據處理框架如 Spark 或 Hadoop 進行資料處理與分析 ⋯⋯ 源代碼管理工具（如 Git）與版本控制機制」。（chunks line 81）

---

## 第三部分｜任務分解與時程設計（Q11–Q16）

### Q11
甘特圖（Gantt Chart）的**核心呈現方式**為何？
- (A) 以時間為橫軸、任務列表為縱軸，呈現各工作的時間安排、重疊區段與關鍵路徑（Critical Path）
- (B) 純粹的圓餅圖，呈現部門人數分布
- (C) 純文字清單，無視覺化
- (D) 以資料量為橫軸、模型準確率為縱軸的散點圖

**答案：(A)**
解析：教材定義甘特圖「以時間為橫軸、任務列表為縱軸的視覺化工具，能清楚呈現各項工作的時間安排、重疊區段與關鍵路徑（Critical Path）」。（chunks line 91）

---

### Q12
工作分解結構（Work Breakdown Structure, WBS）的**核心拆解方式**為何？
- (A) 由上而下，將複雜任務分割為可控的子任務，明確每一單元的執行細節
- (B) 由下而上，僅由基層員工自由命名任務
- (C) 隨機順序，無結構性
- (D) 完全不拆解，整個專案視為單一任務

**答案：(A)**
解析：教材明示「工作分解結構（WBS）採用由上而下的拆解方式，將複雜任務分割為可控的子任務，明確每一單元的執行細節」。（chunks line 107）

---

### Q13
WBS 中每一子任務**通常**需定義下列哪些要素？
- (A) 責任角色、預期成果、所需資源與預估時長
- (B) 僅需列出任務名稱即可，無需角色或時長
- (C) 僅定義預算金額
- (D) 僅定義最終客戶滿意度

**答案：(A)**
解析：教材明示「每一子任務需定義責任角色（如資料工程師）、預期成果（如清理後資料集）、所需資源（如運算設備）與預估時長（如兩週），以利後續進度追蹤與資源分配」。（chunks line 119）

---

### Q14
下列關於 Scrum「主要角色」的搭配何者**正確**？
- (A) Product Owner 負責定義產品需求與優先順序、維護 Product Backlog
- (B) Scrum Master 負責定義產品需求與優先順序
- (C) Development Team 僅負責產品需求定義，不寫程式
- (D) Product Owner 負責移除開發障礙與主持每日站會

**答案：(A)**
解析：教材定義 Product Owner =「負責定義產品需求與優先順序，維護 Product Backlog，確保團隊開發內容符合業務價值」；(D) 是 Scrum Master 的職責。常見干擾項把 PO 與 SM 互換。（chunks line 127–131）

---

### Q15
下列關於 Scrum 三大核心產出（Artifacts）的搭配，何者**錯誤**？
- (A) Product Backlog：產品開發待辦清單
- (B) Sprint Backlog：本次 Sprint 要完成的任務清單
- (C) Increment：每次 Sprint 結束時的完整、可運作的產品版本
- (D) Stakeholder Audit：每月由外部稽核員填寫的隨機評分

**答案：(D)**
解析：Scrum 三大核心產出 = Product Backlog／Sprint Backlog／Increment；(D) 不屬於 Scrum 定義的 Artifacts。（chunks line 145–151）

---

### Q16
Sprint（短衝）的**典型週期**為何？
- (A) 固定週期，一般為 1–4 週，常見 2 週
- (B) 必須超過 6 個月才稱為 Sprint
- (C) 隨機，無固定週期
- (D) 必須長達 12 個月

**答案：(A)**
解析：教材明示「Sprint 是 Scrum 的節奏核心。每次 Sprint 為一個固定週期（一般為 1-4 週、常見 2 週）」。（chunks line 153）

---

## 第四部分｜Scrum 活動與跨部門協作（Q17–Q20）

### Q17
下列關於 Daily Scrum（每日站會）的敘述，何者**正確**？
- (A) 快速同步團隊進度與阻礙，通常 15 分鐘
- (B) 每日 8 小時的全員馬拉松會議
- (C) 僅由產品負責人單獨進行
- (D) 用於決定下一個 Sprint 的整體目標

**答案：(A)**
解析：教材定義「Daily Scrum（每日站會）：快速同步團隊進度與阻礙（通常 15 分鐘）」；(D) 是 Sprint Planning 的職責。（chunks line 137、162）

---

### Q18
Sprint Review 與 Sprint Retrospective 的**主要差異**為何？
- (A) Review = 向利害關係人展示成果並收集回饋；Retrospective = 團隊內部自我反思、檢討問題與改進方案
- (B) Review = 內部反思；Retrospective = 對外展示
- (C) 兩者完全相同，只是名稱不同
- (D) Review 是每日站會；Retrospective 是規劃下一輪 Sprint

**答案：(A)**
解析：教材明示「Sprint Review（展示成果）：團隊向產品負責人與利害關係人展示本次 Sprint 完成的工作」；「Sprint Retrospective（回顧檢討）：內部進行自我反思，檢討執行過程中的問題與瓶頸」。(B) 常見干擾項把兩者對調。（chunks line 158–160）

---

### Q19
下列關於 AI 專案跨部門協作機制的敘述，何者**錯誤**？
- (A) 明確各部門的責任與任務範圍，特別是資料提供、模型驗收、系統整合
- (B) 設立定期的專案會議和進度報告會（如每週例會）
- (C) 使用任務看板工具（Jira / Trello）與文件平台（Notion / Confluence）
- (D) 各部門完全獨立運作，不需任何溝通機制

**答案：(D)**
解析：教材列舉跨部門協作機制 = ① 協作流程設計 ② 例行同步節奏 ③ 共用工具平台；(D) 與整節精神相反。（chunks line 172–176）

---

### Q20
下列關於 AI 專案常用即時通訊協作工具的敘述，何者**正確**？
- (A) Slack 或 Microsoft Teams 用於促進快速溝通
- (B) Jira 與 Trello 是即時通訊工具
- (C) Notion 與 Confluence 是即時通訊工具
- (D) Excel 是即時通訊工具的標準選項

**答案：(A)**
解析：教材明示「設立即時通訊協作群組（如 Slack 或 Microsoft Teams）來促進快速溝通」；Jira/Trello 是任務看板，Notion/Confluence 是文件平台，常見干擾項把三類工具功能混淆。（chunks line 176）

---

## 第五部分｜任務追蹤工具與導入模式（Q21–Q26）

### Q21
下列關於 Trello 任務追蹤工具的特性敘述，何者**正確**？
- (A) 輕量級任務管理工具，以看板（Kanban）形式呈現任務流程
- (B) 專為技術團隊設計，主打問題追蹤（Issue Tracking）與工作流自訂
- (C) 結合看板視圖與結構化功能，並可整合 Google Drive 等外部工具
- (D) 提供時間軸檢視，最適合跨部門大型協作

**答案：(A)**
解析：(A) 是 Trello 正確描述；(B) 是 JIRA；(C) 是 ClickUp；(D) 是 Asana。常見干擾項四工具特性對調。（chunks line 183–189）

---

### Q22
下列關於 JIRA 的特性敘述，何者**正確**？
- (A) 專為技術團隊設計，支援問題追蹤（Issue Tracking）、工作流自訂與敏捷開發（Scrum 與 Kanban）
- (B) 是輕量級的看板工具，不適合 Scrum
- (C) 是純文件儲存平台，無任務追蹤功能
- (D) JIRA 為非技術人員設計，學習曲線極低

**答案：(A)**
解析：教材定義 JIRA「專為技術團隊設計的任務追蹤工具 ⋯⋯ 功能包括問題追蹤（Issue Tracking）、工作流自訂與敏捷開發支援（如 Scrum 與 Kanban）」；對非技術人員具學習曲線，(D) 與此相反。（chunks line 197–203）

---

### Q23
下列關於 ClickUp 的特性敘述，何者**正確**？
- (A) 結合 Trello 的看板視圖與 Asana 的結構化功能，提供任務狀態追蹤、目標設定與即時協作，可整合 Google Drive
- (B) 是純語音通訊工具
- (C) 是 GPU 雲端訓練平台
- (D) 是會計報表工具

**答案：(A)**
解析：教材定義 ClickUp「結合 Trello 的看板視圖與 Asana 的結構化功能 ⋯⋯ 整合外部工具（如 Google Drive）」。優勢為功能全面與彈性，但過多選項可能增加設定複雜度。（chunks line 205–209）

---

### Q24
下列關於 AI 導入模式「選用現有商業服務」的敘述，何者**錯誤**？
- (A) 快速部署：無需企業深入開發，降低時間成本
- (B) 技術門檻低：不需深厚的程式設計或數據科學基礎
- (C) 彈性極大、自定義選項充足，可深層調整模型結構
- (D) 資料隱私風險：資料需經雲端服務處理，敏感資料可能引發隱私安全問題

**答案：(C)**
解析：教材列舉「選用現有商業服務」挑戰之一 =「彈性有限：儘管這些工具便捷，但其功能的自定義選項和靈活性往往有限。例如，Google AutoML 難以調整深層模型結構」。(C) 與教材矛盾。（chunks line 217–235）

---

### Q25
下列關於「內部技術團隊開發」AI 導入模式的敘述，何者**正確**？
- (A) 掌控力強與適應性高，可根據業務需求調整模型結構與部署方式，並保留技術自主性
- (B) 完全沒有任何初期成本與時間投入
- (C) 適合缺乏 AI 人才且不打算培養的小公司
- (D) 不需任何 GPU 設備、不需建立開發流程

**答案：(A)**
解析：教材明示內部開發優勢「在於掌控力強與適應性高，企業可根據業務需求調整模型結構與部署方式，並保留技術自主性」，但需投入大量時間與資源；(C)(D) 與其前提矛盾。（chunks line 239–241）

---

### Q26
下列關於「委外開發」AI 導入模式的敘述，何者**錯誤**？
- (A) 適合缺乏內部技術能力但有預算支持的企業
- (B) 能借助外部專業知識加速導入，縮短開發時程
- (C) 完全沒有合約管理與資料安全的風險，可隨意簽訂協議
- (D) 需注意合約管理（如交付範圍與時程約定）與資料安全風險（如敏感資料外流）

**答案：(C)**
解析：教材警告委外開發「需注意合約管理（如交付範圍與時程約定）與資料安全風險（如敏感資料外流）」，並舉某電商案例因合約條款不明確導致延誤。(C) 與此精神矛盾。（chunks line 243–247）

---

## 第六部分｜POC 驗證與規劃成果整合（Q27–Q30）

### Q27
下列關於 AI 導入規劃中 POC 的設計目標敘述，何者**正確**？
- (A) 設定明確、可量化的驗證目標（如「測試推薦模型是否能提升銷售 5%」），確保測試專注於可衡量成果
- (B) POC 目標越模糊越好，無需量化
- (C) POC 必須涵蓋全公司所有系統與部門
- (D) POC 應從一開始就採用最複雜的客製模型，避免使用現成工具

**答案：(A)**
解析：教材舉例「一個零售企業的 POC 目標可能是『測試推薦模型是否能提升銷售 5%』」，並建議技術選型不必過於複雜，可使用現成工具（如 Google AutoML）快速建置原型。(D) 與此相反。（chunks line 257–259）

---

### Q28
下列關於 POC「小範圍測試與快速迭代（Rapid Iteration）」的敘述，何者**錯誤**？
- (A) 採用小範圍測試與快速迭代來不斷調整與優化模型
- (B) 每次迭代設定具體目標，確保技術解決方案逐步對齊業務需求
- (C) 每次迭代後評估與調整，幫助快速發現問題並改進
- (D) POC 應一次完成、絕不允許多次迭代

**答案：(D)**
解析：教材明示「POC 測試並非一次完成，而是採用小範圍測試與快速迭代（Rapid Iteration）的方式來不斷調整與優化模型」；(D) 與此核心精神相反。建議每次迭代 1–2 週。（chunks line 263–273）

---

### Q29
下列關於 POC 驗證指標的搭配，何者**正確**？
- (A) 技術效能（準確率、延遲時間）+ 商業價值（成本節省、效能提升、業務增長）+ 使用者回饋（問卷、訪談）
- (B) 僅看 GPU 溫度
- (C) 僅看股價漲跌
- (D) 僅看員工出勤率

**答案：(A)**
解析：教材明列 POC 驗證指標三類：技術效能、商業價值、使用者回饋。（chunks line 267–272）

---

### Q30
下列關於 AI 導入規劃成果**整合**項目的敘述，何者**錯誤**？
- (A) 導入規劃文件（Implementation Plan Document）彙整整體導入策略與規劃邏輯
- (B) 利害關係人審查紀錄（Stakeholder Review）紀錄關鍵部門或管理層的意見回饋與決議事項
- (C) 甘特圖與時程規劃（Gantt Chart and Timeline）視覺化專案階段、任務排程、里程碑
- (D) 規劃成果完全不需經過任何利害關係人審查，可直接進入實作階段

**答案：(D)**
解析：教材明示「導入規劃成果須經關鍵部門或管理層審查，包括技術部門、業務單位、法務 / 資安單位與高階管理層 ⋯⋯ 以作為專案進入實作階段的條件」。(D) 與此精神直接相反。（chunks line 298–300）

---

## 答案速查表

| Q | 答 | Q | 答 | Q | 答 |
|---|---|---|---|---|---|
| 1 | A | 11 | A | 21 | A |
| 2 | A | 12 | A | 22 | A |
| 3 | D | 13 | A | 23 | A |
| 4 | B | 14 | A | 24 | C |
| 5 | D | 15 | D | 25 | A |
| 6 | A | 16 | A | 26 | C |
| 7 | A | 17 | A | 27 | A |
| 8 | A | 18 | A | 28 | D |
| 9 | D | 19 | D | 29 | A |
| 10 | A | 20 | A | 30 | D |

## 命題分布統計

| 章節 | 題號 | 題數 | 重點 |
|---|---|---:|---|
| 導入規劃定位與核心原則 | Q1–Q4 | 4 | 承上啟下角色／產業差異／三原則／彈性調整案例 |
| 資源盤點與人力角色 | Q5–Q10 | 6 | PM／資料工程師／模型開發者／架構師／測試工程師／硬體與工具 |
| 任務分解與時程設計 | Q11–Q16 | 6 | 甘特圖／WBS／Scrum 三角色 / 三產出／Sprint 週期 |
| Scrum 活動與跨部門協作 | Q17–Q20 | 4 | Daily Scrum／Review vs Retrospective／跨部門協作三機制／通訊工具 |
| 任務追蹤工具與導入模式 | Q21–Q26 | 6 | Trello／Asana／JIRA／ClickUp 四工具特性／三大導入模式優劣 |
| POC 驗證與規劃成果整合 | Q27–Q30 | 4 | POC 目標設定／快速迭代／三類驗證指標／規劃成果整合與利害關係人審查 |
| **合計** | — | **30** | — |

## 易混淆考點清單（找混淆提示詞輸出）

| # | 易混淆對 | 差異 |
|---|---|---|
| 1 | 專案負責人 vs AI 模型開發者 | PM 負責協調進度溝通；AI 開發者寫 Python/TF/PyTorch（Q5/Q6） |
| 2 | 資料工程師 vs 系統架構師 vs 測試工程師 | 資料工程師=ETL/清理；架構師=部署與 API；測試=壓力測試（Q6/Q7/Q8） |
| 3 | Product Owner vs Scrum Master | PO 定義需求/維護 Backlog；SM 移除障礙/促進流程（Q14） |
| 4 | Sprint Review vs Sprint Retrospective | Review=對外展示成果；Retrospective=內部自我反思（Q18） |
| 5 | 甘特圖 vs WBS | 甘特圖=時間軸視覺化（橫軸時間）；WBS=由上而下任務拆解（Q11/Q12） |
| 6 | Trello vs Asana vs JIRA vs ClickUp | Trello 輕量看板/小團隊；Asana 結構化跨部門/時間軸；JIRA 技術團隊/Issue Tracking/Scrum；ClickUp 看板+結構化/Google Drive 整合（Q21/Q22/Q23） |
| 7 | 三大導入模式 | 商業服務（快/低門檻/彈性有限）vs 內部開發（掌控力強/初期成本高）vs 委外（專業/合約與資料外流風險）（Q24/Q25/Q26） |
| 8 | 任務看板（Jira/Trello）vs 文件平台（Notion/Confluence）vs 即時通訊（Slack/Teams） | 三類工具功能定位易混淆（Q20） |
| 9 | POC 應快速迭代 1–2 週 vs 一次完成 | POC 核心 = Rapid Iteration，絕非一次完成（Q28） |
| 10 | 製造業（感測器整合 / 即時性）vs 金融業（資料安全 / 法規遵循） | 兩產業優先聚焦項目常見對調干擾（Q2） |

---

— 命題：Heiter（2026-05-12）
— 對應投影片版本：L21202 AI 導入規劃（共 13 頁 / 教材 4-15 ~ 4-29）