醫院行政表單 AI 化應選哪種技術組合？
某醫療院所希望改善行政效率，規劃讓各科室人員可自行建立行政回報與內部申請表單，並導入 AI 功能以自動判讀與分類填寫內容（如問題類型或需求性質），同時需兼顧流程調整彈性與降低系統開發維護負擔。下列哪一種技術組合最適合？
一家醫療院所希望讓各科室人員自行建立行政回報與內部申請表單，並導入 AI 功能自動判讀、分類填寫內容（例如問題類型或需求性質），同時要兼顧流程調整的彈性，也要降低系統開發和維護的負擔。
問你：這種需求（自建表單、AI 自動分類、低維護負擔）最適合哪種技術組合？
一句話總結
「讓非技術人員建表單 + AI 自動分類內容 + 維護成本低」這三個需求，最對口的是Low-Code 平台（讓各科室自建表單流程）搭配預訓練語言模型 API（呼叫現成 AI 能力做分類，不需要自己訓練模型）。
先感受問題：醫院行政人員怎麼自建智慧表單？
「仁愛醫療院所」的資訊組長振宇面對一個難題：各科室（急診、門診、護理部、藥劑科）各有不同的行政表單需求，例如急診要填「設備故障回報」、護理部要填「耗材申請」，目前每個表單都要請 IT 部門開發，排程要等兩個月。
振宇想要：一、各科室護理師、行政員能自己拉出新表單，不等 IT；二、員工填完表單後，AI 能自動讀懂「這是設備問題還是耗材問題」，自動轉發給對的部門；三、整套系統上線後維護量要低，不要每次小改動就要工程師介入。
這三個需求對應三個技術決策：低門檻建表單（Low-Code）、語言理解分類（預訓練語言模型 API）、低維護成本（用 API 不自建模型）。
沒有這個組合，醫院行政 AI 化會卡在哪裡？
- 全部靠 IT 開發：每個表單都要排 IT 開發時間，等待週期長，科室的需求都是臨時性的，等到上線需求已經變了
- 規則式自動化（Rule-based）：把所有分類規則寫死（如「含『設備』關鍵字就分到設備組」），醫療場景詞彙複雜，漏判、誤判率高，規則越寫越多越難維護
- 自己訓練深度學習模型：需要大量標注資料、GPU 算力、ML 工程師，對醫院資訊部門來說資源投入太重，且每次有新類型都要重新訓練
- 用 Excel 手動整理：人工分類、手動彙整，填表量一大就出錯，也無法即時處理
- Pure No-Code（完全不能客製化）：有些需求（如特定科室流程邏輯）No-Code 做不到，需要 Low-Code 加少量程式邏輯
Low-Code + 預訓練語言模型 API 怎麼解
Low-Code 平台負責表單建立部分：護理師或行政員在 Low-Code 平台（類似 Microsoft Power Apps、AppSheet）上，用視覺化方式拖拉出表單欄位、設定流程路由，不需要工程師寫程式。少量的邏輯（如「急診的表單自動附帶科室代碼」）可以用 Low-Code 平台支援的簡單腳本設定。
預訓練語言模型 API 負責 AI 分類部分：員工填完表單提交後，系統自動把填寫內容傳送給語言模型 API（如 OpenAI API、Azure OpenAI），請模型判斷「這個需求屬於哪個類型」，API 回傳分類結果，系統根據結果自動轉發。不需要自己訓練模型，呼叫現成 API 即可，維護成本低。
這套組合恰好滿足三個需求：彈性建表單（Low-Code）、智慧分類（語言模型 API）、低維護成本（API 呼叫不自建）。
這就是選項 A 描述的：Low-Code 平台 × 預訓練語言模型 API。
技術版：這個組合在企業 AI 架構中的位置
「Low-Code + 預訓練語言模型 API」是目前企業導入 AI 的主流輕量架構，特別適合以下情境：
- 業務流程多樣、需要頻繁調整表單或流程設計
- AI 任務是通用型語言理解（分類、摘要、抽取），不需要領域專屬模型
- IT 資源有限，希望用 API as a Service 降低維運負擔
預訓練語言模型 API 的典型用法：把使用者輸入的文字作為提示詞（Prompt）傳給 API，在提示詞中描述「分類任務」，模型回傳分類標籤或結構化 JSON。例如：「以下是一份醫院內部申請表填寫內容，請判斷屬於哪個類別：設備故障、耗材申請、人力支援、其他。填寫內容：『護理站二的血壓計數值不準，疑似需要校正』」
Rule-based vs. 語言模型 API 的取捨：規則式（Rule-based）維護成本高、無法處理語意歧義；語言模型 API 能理解語意，但有使用成本（按 token 計費）且需要網路連線。對醫療場景（涉及個資）的企業，需評估資料是否能外傳至 API。
為什麼出題者要考這題：AI 應用規劃師的核心能力之一是「選型」：根據場景的需求（彈性、成本、AI 能力）選對技術組合。這題考的是能否識別 Low-Code 的適用場景，以及能否區分「呼叫 API」和「自建模型」兩種 AI 整合方式的差異。
為什麼其他選項是錯的
BNo-Code 平台 × 規則式自動化（Rule-based Automation）
用 No-Code 平台讓大家建表單，用預先設定好的規則（如關鍵字比對）自動分類。
規則式自動化無法應對醫療場景語意的複雜性。「血壓計數值不準」和「血壓計電池沒電」都是設備問題，但用關鍵字規則要列出所有可能的說法幾乎不可能。而且題目說需要 AI 功能「自動判讀與分類」，規則式不算 AI，功能上達不到要求。
以為 Rule-based 等於 AI 的人，或不清楚語言模型 API 可以直接呼叫解決分類問題的人。
C傳統程式開發 × 自建深度學習模型
工程師用傳統方式開發系統，同時自己從頭訓練一個深度學習分類模型。
題目明確說要「降低系統開發維護負擔」，傳統程式開發 + 自建深度學習模型是最重的技術路線，需要大量工程人力、標注資料、訓練算力，完全違背需求。且醫院的表單需求多樣且會變動，每次需求變更都要改程式，維護成本極高。
認為「自己建模型才最準」的人。在很多應用場景，呼叫預訓練模型 API 就夠用，不需要自建，且維護成本遠低。
D試算表工具 × 手動資料標記分析
用 Excel 之類的試算表工具收集表單，再靠人工看資料、手動分類和分析。
這根本不是 AI，是純人工作業。題目明確要求「AI 功能以自動判讀與分類」，D 完全沒有自動化，也沒有 AI。而且手動標記分析在量大時效率極低，完全不符合「改善行政效率」的目標。
沒有仔細讀題，或認為只要有工具就算符合需求的人。D 連題目的基本要求（AI 自動分類）都沒達到。
同個考點下次怎麼變形
什麼情況下應選「呼叫預訓練模型 API」，而不是「自建 Fine-tuning 模型」？
既然 Fine-tuning 更精準，為什麼不直接 Fine-tuning？
當任務是通用型語言理解（分類、摘要、抽取）、標注資料量有限、資源有限、需要快速上線時，呼叫 API 更合適。Fine-tuning 適合任務非常特定（如醫療術語專用模型）、需要更高準確率且有大量標注資料的場景。
Low-Code 和 No-Code 在這個場景的差別是什麼？為什麼選 Low-Code 而不是 No-Code？
No-Code 門檻更低，為什麼不選？
醫院的流程有特定邏輯（如根據科室自動帶入欄位、呼叫外部 API）需要少量程式腳本設定，純 No-Code 可能無法支援這些客製化需求。Low-Code 在保留低門檻的同時，允許少量程式碼做複雜邏輯，符合「兼顧流程調整彈性」的要求。
企業使用預訓練語言模型 API 做文字分類時，主要的風險是什麼？
直接呼叫 API 最方便，有什麼要注意的？
主要有三個風險：資料隱私（敏感資料傳至第三方 API 服務商）、依賴外部服務（API 停用或調漲費用）、結果一致性（不同次呼叫可能回傳不同答案）。對於醫院這類有個資顧慮的場景，需評估是否使用有資料處理協議的企業級 API，或考慮本地部署方案。
如果這家醫院的分類需求非常特殊（如專用醫療術語），Low-Code + API 的組合還適用嗎？
通用語言模型能理解醫療術語嗎？
通用預訓練語言模型對常見醫療術語有基本理解，但對高度專業的術語可能準確率下降。此時可考慮：在提示詞中補充術語說明（Prompt Engineering）、使用醫療垂直領域模型（如 Med-PaLM）、或對高頻特殊術語做 Fine-tuning。Low-Code 架構不變，AI 元件從通用 API 換成更精準的即可。
AI 應用規劃師在評估技術組合時，應優先考量哪幾個維度？
技術選型的判斷框架是什麼？
四個核心維度：使用者技術能力（誰在用、能接受多高技術門檻）、功能彈性需求（需不需要客製化）、維護成本（上線後誰維護、需要多少技術人員）、資料敏感性（資料能否送到外部服務）。這四個維度一對，最合適的技術組合就能浮現。
想再往下看，這 5 個
- 低程式碼（Low Code）允許少量程式碼客製化的開發平台，保留非技術人員的低門檻同時支援複雜業務邏輯，是本題正解的技術基礎
- 大型語言模型（Large Language Model）預訓練後可透過 API 呼叫完成分類、摘要、生成等任務，不需自行訓練，是本題推薦技術組合的 AI 元件
- 提示工程（Prompt Engineering）設計有效提示詞讓語言模型執行分類任務的核心技能，搭配 API 呼叫時用於描述分類規則給模型
- 微調（Fine-tuning）與呼叫 API 相對的另一種 AI 整合方式，需自行標注資料和訓練，維護成本高，本題刻意不選此路線
- 文本分類（Text Classification）自動將文字內容歸入預定類別的 NLP 任務，本題的 AI 自動判讀填寫內容屬於典型的文本分類應用