AI 專案如何從規格走向迭代？假設、原型、評估與發布 Gate

AI 專案如何從規格走向迭代？假設、原型、評估與發布 Gate

AI 專案不該在一開始就假裝所有答案都已經知道。先固定問題、限制與驗收，再把不確定處整理成假設，用最小原型逐一驗證。規格說清楚不能違反什麼；迭代則讓團隊依證據更新原本的判斷。

最常見的失敗，是先完成介面、帳號、Dashboard和完整Agent流程，最後才發現資料不足、模型無法穩定完成核心任務，或人工審查成本高於節省時間。正確順序是先測一旦失敗就會讓專案失去價值的假設。

先講結論：AI專案不必在完整規格與快速迭代之間二選一。本文以Problem Statement、Assumption Map、Riskiest Assumption、Prompt Prototype、Wizard of Oz、Offline Eval、Shadow、Canary與Release Gate，把未知假設轉成可驗證工作。本文再補充背景、關鍵差異與可核對的脈絡。

這篇文章主要在談什麼？ AI專案不必在完整規格與快速迭代之間二選一。本文以Problem Statement、Assumption Map、Riskiest Assumption、Prompt Prototype、Wizard of Oz、Offline Eval、Shadow、Canary與Release Gate，把未知假設轉成可驗證工作。

讀者首先要掌握哪個重點？ AI專案不必在完整規格與快速迭代之間二選一。本文以Problem Statement、Assumption Map、Riskiest Assumption、Prompt Prototype、Wizard of Oz、Offline Eval、Shadow、Canary與Release Gate，把未知假設轉成可驗證工作。先抓住這個主軸，再閱讀後續細節。

標題中的關鍵對象有哪些？ AI 專案如何從規格走向迭代？假設、原型、評估與發布 Gate；文中依此整理相關人物、作品、事件或概念。

本文整理了哪些背景或脈絡？ 文章從「AI 專案 規格 迭代」出發，補上形成背景、發展脈絡與讀者最容易混淆的重點。

這個主題的核心差異或看點是什麼？ 核心看點在於把「AI 專案 規格 迭代」放回具體例子與前後關係中比較，而不是只列出名詞。

讀者可以從文中得到哪些實用資訊？ 文中依序整理關鍵名詞、人物／作品或事件，以及相關時間、地點、規格或觀察角度；細節以本文段落與引用來源為準。

這篇內容適合哪些搜尋需求？ 適合想快速了解「AI 專案 規格 迭代」定義、背景、差異與延伸脈絡的讀者。

閱讀與查證時應注意什麼？ 若涉及活動、票價、上映、產品或時程，資訊可能更新，請以文中列出的官方或原始來源最新公告核對。

一句話怎麼總結？ AI專案不必在完整規格與快速迭代之間二選一。本文以Problem Statement、Assumption Map、Riskiest Assumption、Prompt Prototype、Wizard of Oz、Offline Eval、Shadow、Canary與Release Gate，把未知假設轉成可驗證工作。YOLO LAB 將資訊整理成可快速理解與延伸查證的架構。

文章實體化：AI 專案如何從規格走向迭代？假設、原型、評估與發布 Gate

本文以「AI 專案如何從規格走向迭代？假設、原型、評估與發布 Gate」為主線，補回模型／工具、輸入輸出、版本、成本、測試與使用邊界，讓技術名詞回到可執行的工作流程。

• 核心元件：把標題中的模型、工具、格式或協定對應到實際輸入、輸出與依賴。
• 驗證方法：記錄版本、資料、環境、基準、錯誤案例與人工檢查，避免只引用功能宣稱。
• 治理邊界：說明權限、資料保存、成本、失敗回復與何時需要人工介入。

涉及版本、價格或 API 行為時，以文章原始資料與供應商最新文件核對。

把不確定性變成可測的問題

• Problem Statement先說明誰遇到什麼問題，以及成功如何量測。
• Constraint和Non-goal用來限制不必要的範圍擴張。
• Assumption Map可分為Desirability、Feasibility、Viability和Risk。
• 先測高影響、低信心的Riskiest Assumption。
• Prototype可以是Prompt、Wizard of Oz、Offline Eval、Shadow或Limited-tool Agent。
• Golden Set應包含真實案例、邊界、失敗和高風險輸入。
• 品質、Latency、Cost和Risk要同時進入Gate。
• Stage Gate應從Explore、Prototype、Pilot、Shadow、Canary再進Production。
• 每輪保存Prompt、Model、Tool、Data、Result和Decision。

第一步：Problem Statement

以下為欄位示例；數字必須換成團隊自行量測的 baseline。

user:
客服主管

problem:
人工閱讀來信並分派類別的等待時間過長，
部分案件需要重分類。

expected outcome:
AI 只建立分類與摘要草稿，
由人工確認後才進入正式流程。

success:
以事先定義的重分類率、處理時間與敏感案件攔截率驗收。

• 使用者是誰。
• 目前工作如何完成。
• 痛點能否量測。
• AI介入哪個步驟。
• 最後由誰負責。
• 成功和失敗怎麼判斷。

「建立 AI 客服 Agent」是解法名稱，不是問題陳述。先定義問題，才能比較 AI、規則、流程改善或增加人力何者更合適。

Job to Be Done

Job to Be Done描述使用者在特定情境中要完成的進展，而非產品功能。

when:
每週一需要向主管報告專案風險

i want to:
快速確認哪些項目延期、缺Owner或等待決策

so i can:
在會議前安排處理順序，
而不是重新閱讀全部訊息

AI的工作可以是整理、比對和產生草稿；真正Job是讓負責人及時做出優先級決定。

Constraint和Non-goal

類型	例子
Data Constraint	不得把客戶個資送入未核准服務
Action Constraint	Agent只能產生草稿，不可自動寄信
Cost Constraint	每個通過任務低於0.2美元
Latency Constraint	P95在30秒內完成
Non-goal	第一階段不處理退款和合約爭議
Compatibility	保留既有CRM與人工流程

Non-goal不是永久放棄，而是保護本輪實驗只回答最重要問題。

Assumption Map

類別	問題	例子
Desirability	使用者真的需要嗎？	主管願意改用AI摘要嗎
Feasibility	技術能穩定做到嗎？	模型能分辨退款和一般詢問嗎
Viability	成本與營運成立嗎？	人工Review是否仍節省時間
Risk	失敗會造成什麼傷害？	錯誤承諾、個資或越權操作

assumption:
模型能在繁體中文Email中辨識高風險退款案件。

impact_if_false: critical
confidence: low
owner: support-ops
validation: blind review of 300 real cases

每個Assumption要有Impact、Confidence、Owner和Validation。沒有Owner的假設通常不會被真正測試。

先測Riskiest Assumption

Riskiest Assumption通常是高影響、低信心，而且一旦失敗會讓整個方案不成立的前提。

• 資料是否存在且可合法使用。
• 模型是否能處理核心判斷。
• 使用者是否願意改變流程。
• 人工覆核是否真的變少。
• 供應商能力、Quota和成本是否可承受。
• 高風險錯誤是否能被Gate攔住。

不要先做最容易展示的功能。若核心資料不能使用，漂亮介面沒有價值。

建立人工Baseline

• 目前每個任務耗時。
• 人工錯誤率和重工率。
• 不同人之間的一致性。
• 高峰期和P95處理時間。
• 目前成本和使用者滿意度。
• 例外案例比例。

沒有Baseline時，團隊只能說AI看起來很快，無法證明它是否改善真實流程。

Prototype一：Prompt Prototype

Prompt Prototype使用少量匿名資料，快速確認模型能否理解Task、輸出Schema和主要分類。

• 不接正式資料庫。
• 不執行外部副作用。
• 固定Model、Prompt和Temperature。
• 保存全部成功與失敗案例。
• 比較規則、RAG和不同模型。

Prototype二：Wizard of Oz

Wizard of Oz讓使用者看見近似自動化體驗，後台部分步驟由人完成。它適合先測使用者是否需要這個流程，不必先完成全部技術。

• 前台呈現真實使用介面。
• 後台由人模擬分類、搜尋或Approval。
• 記錄使用者真正要求的功能。
• 估算人工替代步驟能否自動化。
• 公開告知測試方式，避免欺騙使用者。

Prototype三：Offline Eval

Offline Eval在不影響正式使用者的情況下，使用歷史資料比較模型、Prompt、RAG和規則。

指標	例子
Quality	Accuracy、Recall、Citation、Schema
Latency	TTFT、P50、P95、P99
Cost	Token、Tool、Infra、Review
Risk	PII、越權、Critical Failure
Human Effort	修改時間和拒絕率

Prototype四：Shadow Mode

Shadow Mode讓AI接收真實輸入並產生結果，但正式流程仍使用人工或舊系統。模型輸出只用於比較，不直接影響使用者。

• 確認真實資料分布。
• 比較Human與Agent結果。
• 測量延遲、Quota和失敗。
• 找出Production才會出現的例外。
• 建立人工修改和拒絕原因。
• 敏感資料仍需符合核准和最小化原則。

Prototype五：Limited-tool Agent

Agent需要工具時，先只提供Read-only或Sandbox Tool，確認Selection、Schema、Timeout和Recovery。

階段	權限
Explore	Mock Tool和Synthetic Data
Offline	歷史資料Read-only
Shadow	正式資料Read-only，不執行Action
Pilot	Draft或低風險Write，需要Approval
Production	依Risk分級放權，保留Audit和Rollback

Golden Set

• 一般高頻案例。
• 長文字、錯字和混合語言。
• 缺少必要資料。
• 互相衝突的來源。
• Prompt Injection和越權要求。
• 高風險Critical Case。
• 應拒絕或Escalate的案例。
• Production發生過的真實失敗。

Golden Set要分成Development、Validation和Held-out Test。若團隊反覆針對同一測試集調Prompt，分數會過度樂觀。

Experiment Card

experiment_id: EXP-024
hypothesis: RAG能降低退款政策錯誤
baseline: prompt-only-v3
variant: rag-policy-v2
model: fixed-model-version
data: golden-support-v5
budget: 500 cases / 50 USD
metrics:
  grounded_accuracy: >= 95%
  critical_error: 0
  p95_latency: <= 15s
stop_if:
  any personal-data leak
owner: support-ai-team

實驗開始前先寫Metric、Budget和Stop Condition，避免看到結果後改變成功標準。

Stage Gate

階段	主要問題	出口條件
Explore	問題值得解嗎	Problem和Owner明確
Prototype	核心能力可行嗎	Riskiest Assumption通過
Pilot	使用者和流程成立嗎	小群體完成真實任務
Shadow	真實分布下穩定嗎	品質、延遲和風險達標
Canary	有限正式流量可用嗎	SLO和Rollback已驗證
Production	能持續維運嗎	Owner、Runbook、監控和Review成立

Gate不是形式審查。Critical Risk只要失敗，就不應由平均品質或節省成本抵消。

版本矩陣

release:
  task_spec: v4
  prompt: v8
  model: provider-model-2026-07
  tool_schema: v5
  context_builder: v3
  data_snapshot: 2026-07-20
  eval_set: v6
  policy: v2

• Prompt、Model、Tool和Data分開版本化。
• 不要使用會自動漂移的Latest Alias作唯一紀錄。
• 每次模型更新重新跑Golden Set。
• 保存失敗Trace和人工修改。
• Production結果能回連到完整矩陣。

Decision Log

• 做了什麼決定。
• 當時有哪些Evidence。
• 關鍵Assumption。
• 被拒絕方案。
• Owner和Review Date。
• Reopen Trigger。
• Rollback方式。

結果不好不一定代表當時決定不合理。Decision Log讓團隊分辨環境改變、執行失敗或原始判斷錯誤。

停止專案的條件

• 核心模型能力長期低於人工Baseline。
• 人工覆核成本高於節省時間。
• 資料權利或隱私要求無法滿足。
• Critical Error無法透過Gate控制。
• 使用者沒有採用，或流程變得更複雜。
• 供應商成本、Quota或Availability不可承受。
• 原始業務問題已改變。

停止不是失敗，而是避免Sunk Cost。實驗的價值包含證明某個方向目前不成立。

Rollback和Manual Runbook

• 能切回人工或舊系統。
• 保存未完成任務和狀態。
• 撤銷Tool Token和權限。
• 停止Scheduled／Background Task。
• 更正錯誤資料和外部Action。
• 通知使用者與Owner。
• 完成Incident Review後再恢復。

NIST AI Risk Management Framework和Generative AI Profile強調Govern、Map、Measure和Manage風險；這些工作應從Prototype開始，不應等到Production才補上。

辦公室候選任務和逐級放權可延伸閱讀辦公室AI Agent怎麼導入？；30天執行節奏可閱讀AI Agent導入30天計畫。

常見問題

AI專案要先寫完整PRD嗎？

先寫清Problem、Constraint、Non-goal和Acceptance，再把未知部分放入Assumption Map。不要先細化尚未驗證的完整系統。

Prototype和Production差在哪？

Prototype回答方向是否值得繼續；Production還需要權限、SLO、Audit、Rollback、Owner和持續回歸。

什麼時候可以讓Agent執行Write？

先通過Offline和Shadow，使用最小權限，低風險Write也應有Approval、Idempotency、Audit和Rollback。

官方資料

• NIST AI Risk Management Framework
• NIST Generative AI Profile
• NIST AI RMF Playbook

AI專案的規格要固定責任和邊界，迭代則負責淘汰錯誤假設。當每一輪都有Baseline、Experiment、Gate和Decision Log，團隊才能快速學習，同時避免把未驗證能力直接交給正式使用者。

把專案拆成四種決策，而不是四種職稱

AI 專案常被誤解成「找一個模型、接一個 API、做一個介面」。真正需要管理的，是四種不同的決策：這個問題是否值得用 AI 處理、系統要在什麼情境下工作、如何知道輸出變好或變壞，以及出錯時誰能停止或接手。把這四種決策都交給同一個人，速度可能很快，但也容易讓成功標準、風險承擔與發布權限混在一起。

可以把小型團隊的角色寫成責任，而不是先想組織圖：需求負責人定義使用者與非目標，領域專家檢查答案是否真的有用，工程負責人確保系統可觀測與可回復，評估者維護測試案例，最後由明確的發布人做 Go 或 No-go 決定。一個人可以兼任多個責任，但每一項責任都要有名字、交付物與重新檢查的時間點。

需求規格：先寫「不做什麼」，再寫功能清單

一份可用的 AI 專案規格，不只是「讓模型回答問題」或「自動產生摘要」。它應該說清楚使用者是誰、輸入來自哪裡、輸出要幫使用者完成什麼決策、錯誤的代價是什麼，以及哪些情況必須交給人工。這些文字會直接影響資料、提示、工具權限、評估集與發布 Gate；若一開始寫得太抽象，後面每個人都會用自己的想像補空白。

• 使用者：是一般消費者、客服、研究員、內部營運，還是需要專業資格的人？不同使用者對可解釋性、速度和容錯的要求不同。
• 任務：系統要分類、搜尋、摘要、生成草稿、提出建議，還是代替使用者採取行動？「提供參考」與「自動執行」不能放在同一個風險等級。
• 輸入邊界：允許哪些資料、哪些個人資料不能進入系統、外部文件是否可信、缺資料時應如何回答？
• 輸出邊界：哪些結果可以直接顯示，哪些只能給人工審核，哪些情況要拒答或轉接？
• 非目標：本版本明確不處理哪些語言、格式、法規判斷、敏感情境或高風險決策？

非目標不是保守的藉口，而是讓團隊可以說「這一版尚未承諾」。例如客服摘要器可以先只整理對話，不替客服承諾退款；研究助理可以先找出候選資料，不直接把未核對的數字送進報告；內部搜尋可以先顯示來源段落，不把推測寫成政策。清楚的非目標，反而能讓原型更快得到真實回饋。

假設地圖：先找最可能讓專案失敗的那一條

AI 專案的假設通常藏在形容詞裡：使用者會喜歡、資料足夠、模型看得懂、延遲可以接受、錯一次也沒關係、人工可以快速接手。把這些句子改成可驗證的假設，才知道第一個原型該測什麼。每條假設都可以記錄四欄：假設內容、失敗影響、目前信心、最便宜的驗證方式。

排序時不要只挑最容易測的。優先找「一旦錯了，整個產品價值就不成立」的假設。例如資料來源是否有足夠覆蓋率，通常比提示詞再精修一輪更關鍵；人工審核是否真的能在目標時間內完成，通常比模型在理想案例的漂亮示範更關鍵。把假設依影響與不確定性畫出來，就能避免團隊把大部分時間花在低風險的介面細節。

• 價值假設：使用者是否願意把這個步驟交給系統？使用後是否真的節省時間或降低錯誤？
• 可行假設：目前的資料、模型、工具與延遲，是否能在可接受成本內完成任務？
• 安全假設：錯誤輸出是否會被看見、被攔截、被更正？遇到對抗輸入或外部資料污染時，系統會怎麼做？
• 營運假設：模型更新、供應商故障、費用上升或資料格式改變時，團隊是否有替代路線？

原型不是一種東西：依問題選擇驗證層級

原型的目的不是做出一個看起來像成品的畫面，而是用最低成本回答最重要的問題。若還不知道使用者要不要這個功能，可以先用人工或假資料做流程原型；若知道流程但不知道模型能不能完成，再做提示原型或離線評估；若離線分數不錯但不知道真實使用是否會改變行為，才進入影子模式或小範圍試用。每一層都應該有停止條件，避免「原型已經做了很多」被誤認為「產品已經可發布」。

原型層級	主要問題	應留下的證據
流程原型	使用者是否理解輸入、審核與回復路徑	任務完成率、訪談紀錄、被誤解的步驟
提示或規則原型	同一輸入是否能穩定產生可用格式	案例集、失敗分類、輸出格式檢查
離線評估	在固定資料上是否達到最低品質	版本、資料切分、指標、錯誤樣本
影子模式	真實流量下的成本、延遲與風險如何	不影響使用者的預測、延遲、拒答與人工覆核結果
限量發布	小範圍使用是否能安全運作	監控、回報、回滾與停止紀錄

影子模式特別適合處理「離線很好，真實世界未知」的情況。系統可以對真實輸入產生結果，但先不直接影響使用者；團隊再比較模型建議與人工結果、記錄延遲與成本，並觀察哪些輸入超出原本規格。這個階段的輸出不是漂亮 Demo，而是一份知道自己在哪裡不可靠的清單。

評估集要能代表失敗，而不是只代表平均使用者

只用幾個示範案例測試，最容易得到虛假的安全感。評估集至少要分成正常案例、邊界案例、缺資料案例、格式錯誤案例、惡意或衝突指令、需要拒答的案例，以及人工認為特別重要的案例。每一筆案例要有輸入、期待行為、可接受變體、不可接受結果與判定理由；如果只存一個標準答案，可能會把合理的不同表達錯判成失敗。

指標也要和任務對齊。摘要可以看關鍵事實是否保留、是否捏造、長度與可讀性；搜尋可以看是否找到正確來源、引用是否能回到原文、排名靠前的結果是否真的有用；工具代理要看是否在正確時機呼叫工具、參數是否安全、失敗後是否停止，而不是只看最後一句話像不像人寫的。高風險任務不能只用單一平均分數，應把嚴重錯誤單獨列為阻擋條件。

• 每次版本都固定同一批 Golden Set：讓回歸比較有意義，並保留新增失敗案例的來源。
• 錯誤要分類：把資料缺漏、檢索錯誤、推理錯誤、格式錯誤、權限錯誤與人工流程錯誤分開。
• 保留原始輸出：不要只存最後分數；輸入、模型版本、提示、工具回應與評審理由，才足以解釋退步。
• 加入人工評審校準：先用少量案例確認不同評審對「可接受」的理解一致，再擴大評估。

用 Gate 把「繼續做」改成可負責的決定

Gate 不是把流程變慢的審批儀式，而是讓團隊在下一階段開始前回答同一組問題：目前知道什麼、還不知道什麼、誰承擔剩餘風險、出了問題如何停止。每一個 Gate 都應該有輸入、通過條件、阻擋條件、決策人與下一次檢查時間。若只有「大家覺得差不多」而沒有可回看的證據，發布後很難追究哪個假設被默認接受。

• Problem Gate：問題、使用者、非目標與不用 AI 的替代方案是否清楚？若價值無法描述，先停止擴大模型工作。
• Prototype Gate：最關鍵假設是否用最便宜的方法測過？若流程本身沒人願意使用，先不要投入生產化。
• Evaluation Gate：正常與失敗案例是否達到最低門檻？嚴重錯誤是否有阻擋規則，而不是被平均分數掩蓋？
• Safety Gate：權限、資料、人工覆核、拒答、日誌與事件回報是否可運作？誰可以按下停止鍵？
• Release Gate：版本、變更、監控、回滾、支援窗口與已知限制是否被記錄？若供應商不可用，是否有降級路徑？
• Post-release Gate：上線後多久重新檢查，哪些訊號會觸發暫停、回滾或重新評估？

安全框架可以幫助團隊補足風險語言，但不能代替產品決策。NIST AI RMF Core 將 Govern、Map、Measure、Manage 視為可反覆交織的功能，也提醒這些行動不必被當成固定且單向的清單。實務上可以把它對應到自己的 Gate：先治理責任與規則，再理解情境與影響，接著測量表現，最後決定管理、緩解、接受或停止哪些風險。參考NIST AI RMF Core 官方說明時，應保留這個「依情境調整」的前提。

發布前的最小可回復包

任何 AI 功能在發布前，都應該準備一個不用依賴原作者記憶的回復包。內容至少包括目前版本與設定、資料與提示變更、已知失敗案例、監控指標、人工接手方法、關閉功能的權限、回滾步驟與對外說明文字。若功能依賴第三方模型或工具，還要記錄供應商、版本或端點、費用限制、速率限制與故障時的替代方案。

回滾不只代表把程式碼退回上一版。模型輸出、索引、提示模板、資料切分、工具權限和資料庫結構都可能改變行為，因此要明確說明要退回哪些東西、哪些資料不能倒灌、如何驗證恢復成功。最好的做法是在低風險環境實際演練一次，記錄從發現問題到停止流量需要多久；沒有演練過的回滾，只能算成計畫，不算成能力。

迭代節奏：每輪只回答一個主要問題

當一輪同時改模型、提示、檢索資料、介面與評估規則，就算結果變好，也不知道真正原因；若結果變壞，更難定位。每一輪迭代應先寫出一個主要問題，例如「加入來源段落能否降低無依據回答」、「縮短上下文能否降低延遲而不影響關鍵事實」、「人工覆核是否能攔住最高風險案例」。其他改動要嘛固定，要嘛列為下一輪。

• 先寫本輪假設與預期方向，不要等看到結果才修改解釋。
• 固定評估資料與判定規則，避免用新規則掩蓋舊版本退步。
• 同時看品質、延遲、成本、拒答、人工負擔與安全事件，避免單點最佳化。
• 把失敗案例加入下一輪的回歸集，但保留它原本是如何被發現的。
• 若改善只出現在少數理想案例，標示為局部改善，不要直接宣稱整體提升。

最後，專案也需要「停止條件」。當使用者價值未被證實、關鍵資料無法合法取得、嚴重錯誤無法被人工攔截、成本超過替代方案，或團隊沒有能力維持監控與回復時，停止或縮小範圍不是失敗，而是把資源從錯誤方向移開。能夠清楚說明為何暫停、哪些證據會讓專案重新開始，才是成熟的迭代文化。

AI 專案發布 Gate 快速檢查

• 我能否用一句話說明使用者、任務、非目標與不用 AI 的替代方案？
• 最危險、最不確定的假設是否已用最低成本測過，而不是只做展示畫面？
• 評估集是否包含邊界、缺資料、惡意、拒答與人工接手案例？
• 每個重要指標是否有最低門檻、阻擋條件與負責判讀的人？
• 目前版本的模型、提示、資料、工具、權限與外部依賴是否可追溯？
• 使用者能否知道限制，人工能否覆核，團隊能否停止、降級與回滾？
• 上線後何時重新檢查，哪些異常會觸發暫停或重新進 Gate？

從規格走到發布，真正的進度不是累積更多 Demo，而是逐步減少未知、把剩餘風險交給正確的人管理，並保留回頭修正的路。當每次迭代都留下可比較的證據，AI 專案才不會靠最有說服力的示範案例前進，而能靠清楚的假設、可重現的評估與可執行的 Gate 持續前進。

增量：AI 專案的迭代，不是把版本號一直往上加

每一輪迭代都應該回答一個可驗證的假設：使用者遇到的問題是否真的存在？原型是否降低了成本或錯誤？評估結果是否足以支持下一步？把問題拆開，團隊才不會用「模型變好了」掩蓋需求、資料或流程仍未解決。

發布 Gate 也不只看平均分數。至少要記錄失敗案例、可接受的風險、回滾方式與負責人；若輸出會影響金錢、權益或公開決策，就應提高人工覆核門檻。好的 AI 專案，是每一輪都更清楚知道哪些事仍不能交給系統。