100 分鐘
定義最小範圍
原型的目的是產生可評估的證據,不是做出功能最完整的系統。最小範圍原型只需要涵蓋 Module 1 假設卡所指定的情境與案例類別,其餘功能留到後續階段。
最小範圍原型 checklist(沿用 SYN-CS-001)| 項目 | 說明 |
|---|
| 涵蓋案例類別 | 只涵蓋假設卡指定的類別(例如一般、缺漏資訊),其餘類別標記為超出範圍 |
|---|
| 輸入來源 | 固定使用 SYN-CS-001 的 documents/ 知識文件版本,不臨時混用未列版本的文件 |
|---|
| 輸出格式 | 回覆初稿+引用來源,供人工核對,而非直接發送給客戶 |
|---|
| 明確排除項目 | 列出本次原型「刻意不做」的功能,避免範圍蔓延 |
|---|
注意
常見錯誤:範圍蔓延(scope creep):為了讓 Demo 好看,逐步加入原本假設卡沒有涵蓋的案例類型或功能,結果評估結果無法對應到假設,Evidence Review 時說不清楚原型到底測了什麼。
重點: 原型的範圍必須和 Module 1 的假設卡一一對應,多做的部分不算「加分」,反而讓評估失去焦點。
100 分鐘
可重現的執行紀錄
Evidence Review 需要能回答「這個結果是在什麼版本、什麼設定下產生的」。沒有執行紀錄的結果無法被複查,也無法在下一階段重現。
Run log 最低欄位| 欄位 | 說明 |
|---|
| run_id | 每次執行的唯一識別碼 |
|---|
| prototype_version | 原型版本(例如 v0.3),對應程式碼或提示詞版本 |
|---|
| run_timestamp | 執行時間 |
|---|
| model_or_tool | 使用的模型/工具名稱與版本 |
|---|
| config | 關鍵設定(例如提示詞版本、溫度、檢索文件數量上限) |
|---|
| input_version | 輸入資料(documents/ 知識庫)版本 |
|---|
| human_rater | 人工判定者代碼(不使用真實姓名) |
|---|
範例 run log 一列(合成資料)run_id=RUN-014, prototype_version=v0.3, run_timestamp=2026-02-10T09:20, model_or_tool=demo-llm-v2, config=prompt_v3/top_k=5, input_version=docs_2026-02, human_rater=RATER-B
注意
常見錯誤:多次調整提示詞或設定卻只保留最後一版的結果,導致無法解釋「為什麼這次分數比上次高」;每次有意義的變更都應該留下對應的 run_id。
重點: 沒有版本、設定與輸入紀錄的評估結果,在 Evidence Review 時無法被追問,也無法被信任。
100 分鐘
人工接手路徑
原型必須明確定義「AI 不確定或超出範圍時怎麼辦」,而不是讓 AI 硬答一個看似合理但沒有根據的答案。人工接手路徑是 Human-AI-Human 原則在原型層級的具體實作。
人工接手路徑範例(客服知識問答)- AI 嘗試在知識庫中找到相關文件
- 找不到足夠證據支持的答案 → 標記「無法回答」並附上已搜尋但不足的文件清單
- 轉交客服人員人工處理,附上 AI 已完成的搜尋紀錄(避免重工)
- 客服人員判斷後回覆客戶,並記錄此案例屬於「無答案」類別供後續分析
資訊
人工接手不是失敗,而是設計良好的原型的正常路徑之一;驗收集裡刻意包含「無答案」與「權限限制」類別案例,就是要驗證這條路徑是否真的被正確觸發,而不是被 AI 硬答掩蓋。
- 1練習
為你的原型畫出人工接手路徑,至少涵蓋「找不到足夠證據」與「超出既定案例類別」兩種觸發情境。 - 2自我檢核
確認你至少完整記錄了 3-5 次執行的 run log,並能對照假設卡說明本次原型「刻意不做」哪些事。
重點: 一個原型如果永遠不會觸發人工接手,通常代表它在不確定時仍然硬答,這對後續 Evidence Review 是警訊,不是優點。