第一次團隊 AI 試行不要從全面導入開始。選一個低風險場景、一小組實際使用者與短週期，先記錄原本做法，再比較品質、時間、人工修正與例外；事先寫好停止條件，最後做 go、revise 或 stop 決定。
「大家先用看看」沒有共同場景、基準與紀錄，最後只會得到喜歡與不喜歡。工具使用量增加，也不代表工作結果改善。
NIST AI RMF 建議明確定義使用範圍、人類監督與角色，在接近實際使用的條件下測量，持續收集回饋，再決定是否繼續。NIST：AI RMF Core
先把邊界說清楚：NIST 支持限定使用情境、明確監督與持續測量；下面五個試行邊界及 go、revise、stop 三種結論，是我為第一次團隊試行整理的設計，不是 NIST 官方固定格式。
把試行縮到五個邊界
- 一個場景：例如把公開會議紀錄整理成待辦草稿。
- 一小組人：包含實際操作者與成果審閱者。
- 短週期：足以重複幾次，不以單次展示判斷。
- 限定資料與權限：使用公開、合成或已批准材料。
- 不自動對外：所有成果先人工審閱。
先記原本怎麼做
沒有基準，就無法分辨 AI 是否改善工作。試行前記錄幾次原流程的完成時間、錯誤、修正量與使用者負擔。
指標不要只看速度。至少包含：成果是否符合標準、人工修正多少、失敗是否被正確停止，以及使用者能否理解責任。
事先寫 stop，不要試完才辯論
停止條件可以是：使用未授權資料、重大錯誤未被檢查發現、需要擴張權限、人工修正高於原流程，或責任人無法持續審閱。
結束時只允許三種結論：
- go：證據支持在同一範圍繼續。
- revise：修正流程後重測，不擴大使用。
- stop：風險或負擔不值得繼續。
練習：完成團隊 AI 試行設計卡
要驗證的假設：
唯一場景與不在範圍內的工作：
參與者與責任：
資料、帳號與權限：
原流程基準：
試行週期與次數：
品質、時間、修正與失敗指標：
每次執行紀錄：
停止條件：
最後決策人：
結論：go／revise／stop完成這張卡，不代表團隊已導入 AI。它只代表你有一個能被實際執行、比較與停止的學習設計。真正擴大前，仍要用試行證據重新評估資料、流程、工具與責任。
參考資料
新消息進來後，哪些 AI 工作要重做？何時該停止自動化？
第一次拿到一份合格的交接文件，很容易以為流程已經成立：材料放進去，整理完成，人工看過，下次照做就好。
真正考驗流程的，往往是下一次。
可能是日期改了，也可能是原本有權批准的人換了；材料多了一份，卻與前一份互相衝突。文件還是能順利產生，格式也沒有壞，但原本成立的判斷，已經不一定適用。
新消息進來後，先看它改變了哪個條件，再決定要改文件、改流程，還是停止讓這段工作自動往下走。 不是每次更新都要整套重做，也不是第一次成功之後，後面每次都應該繼續。
第一單元討論成果能不能交付。這一篇要回答另一個問題：維持這種做法，現在還值不值得？
新資料改了什麼，比「又多了多少內容」重要
以下是自編的專案情境，用來說明判斷差異，不是真實團隊成效。
假設你每週整理一份活動交接。上一版列出待辦、時程與未決問題，審閱者確認後交給同事。這週可能收到三種不同消息。
第一種，是場地編號補齊了。原本的場地與活動安排都沒變，只是缺少一個能直接核對的欄位。這通常屬於文件更新：補入新資訊，確認相關段落沒有矛盾即可。
第二種，是活動日期已改，但提醒信與簡報仍寫著舊日期。這不只是一格資料的問題；原本根據日期安排的工作，也可能需要調整。你要追查被它影響的通知、期限與待辦。
第三種，是新消息說活動還沒獲准，前一版卻已經把它當作確定執行。這時不能只把日期標成待定。原來能往下發送、排程或承諾的前提消失了，流程本身需要暫停。
三種消息都可能只有一句話，對工作的影響卻不同。因此，不要用「內容很少」判斷風險，也不要用「成功生成新版本」判斷更新完成。
可以先問一個簡單問題：如果早一週就知道這則消息，原本還會做出同樣決定嗎？
如果答案是會，通常先處理局部更新。如果答案是不會，就要找出哪些決定依賴了舊條件。如果答案是不知道，先保留不確定性，不讓新版本替你掩蓋它。
更新文件，也要保留被取代的理由
版本保留的目的，不是堆出很多檔案，而是讓接手的人知道：哪一項已經改變、根據什麼改變、目前仍能使用哪些部分。
如果只是請 AI「根據新消息重新整理」，它可能交出更通順的全文，卻讓舊版與新版的差異消失。你讀到的是現在的結論，看不到上一個結論為什麼被取代，也不知道已經收到舊版的人需不需要被告知。
比較有用的更新，是把變更及其影響一起留下。
例如，文件中的目標日期改變了，除了更新那一欄，還應該說明以它為前提的提醒安排是否仍成立。若修改尚未批准，這份新文件就應維持待確認狀態，而不是因為檔名多了「final」便成為可執行版本。
現有會議交接 v0.2提供初始材料、首輪與更新指令，以及示例與核對材料，可以練習保留第一版，再依新增消息做第二版。這是一份合成練習，不能拿完成它的結果直接當作團隊日常使用的證據。
具體看包內 U02：Ray 已收到設計主管的品牌色確認，但版面尚未完成，也還沒有交給工程。它改變了兩列交接資訊。T02 不應再把等待品牌色確認列為目前阻塞；T03 則應解除這項依賴，但保留版面未完成、未交工程與製作人未知。若只更新「品牌色已確認」，沒有檢查依賴它的版面列，交接就會同時出現已解除與仍在等待的矛盾。
再看沒被改變的部分。U04 再次說明上線仍以下週為目標，沒有承諾日期，所以 T05 不能因為品牌色確認了，就被升級成確定上線。U05 指定小安接手彙整狀態，也只改變彙整安排；它沒有新增批准權，而小安原本是否已有批准權仍未知。這裡不能偷換成「小安現在能批准」，也不能反過來斷言「小安沒有任何批准權」。
以上是 v0.2 合成來源與修訂示例的對照，不是新跑出的測試結果。它展示的是如何控制更新的範圍：解除有證據支持的舊阻塞，保留仍未完成的工作，讓未被新消息解答的問題繼續保持未知。
更新指令還要求：遇到互相矛盾、卻沒有明確取代或批准依據的消息，應並列來源並標待確認，不能一律採信較新的說法。但教材的測試範圍也明說，這組消息沒有專門涵蓋所有衝突型態。因此，有這條規則不等於衝突處理已經全面驗證。
留版本的另一個好處，是能辨認修正的原因。這次是來源真的變了，還是上一版原本就整理錯？前者需要管理變更，後者需要修正方法。如果兩種都叫「小更新」，反覆出現的錯誤很容易被藏在日常維護裡。
維持：條件沒變，讓流程繼續做它擅長的部分
維持不是什麼都不看，而是有理由相信，原本的適用條件仍然成立。
材料的種類沒變，任務範圍沒變，負責審閱的人仍能完成核對；這次新資訊只是原先就預期會更新的內容。此時，沿用原流程可能比重新設計更合理。
回到活動交接的自編情境，如果新增的是已確認的場地編號，而且其他安排不受影響，就不必因此改掉整套交接方式。把新資訊與來源連起來，確認沒有殘留矛盾，繼續原本工作即可。
不過，「繼續」應該只涵蓋已經驗證的範圍。能整理內部待審稿，不等於可以開始自動寄信；一份合成資料練習通過，也不等於可以直接處理真實個資。擴大用途，是新的判斷，不是維持原流程的自然附贈。
維持的代價是仍然要審閱與保存必要紀錄。若把這些工作拿掉才顯得省時，那比較的其實是不同品質與風險的流程。
修訂：方法還有用，但某個前提需要重設
修訂適合這種情況：問題可以定位，也能在不擴大風險的範圍內修正，但舊方法已不能照搬。
例如，過去每次只給一份紀錄，現在會同時收到會議摘要與事後補充。AI 沒有明確規則判斷兩份資料衝突時怎麼處理，就可能把它們混成一個看似一致的答案。
這時值得修改的，不一定是提示詞措辭。更重要的可能是資料流程：補充消息是否帶有日期？誰能確認它是新決定？有衝突時應列出兩種說法，還是已有明確的優先順序？
如果團隊尚未建立這些條件，讓模型「更仔細一點」沒有解決問題。要先讓規則成為人也說得清楚的事，再要求工具依規則處理。
修訂之後，也不能立刻把它當成恢復成功。用原本會出錯的情境重測，確認錯誤被處理；再用一個本來就正確的情境檢查，避免新規則為了修一處而弄壞另一處。
修訂的代價包括重新整理材料、改方法、重新驗證，以及讓接手者理解新規則。這些成本可以值得付出，但應該算進去。若每次使用都需要重新發明規則，當前工作可能仍適合人工判斷，而不是持續追加自動化。
停止：不要讓已投入的時間替下一次風險作決定
停止最難的地方，常常不是不知道有問題，而是已經花了很多時間把它做出來。
不過，設定與教材已經完成，不能保證下一次操作的風險仍可接受。下一次還要付出的檢查時間、出錯代價與接手負擔，才是現在需要判斷的部分。
如果來源沒有使用授權，就停止把它送進工具；如果關鍵錯誤可能漏過驗收，就停止讓結果自動往下走；如果每次都要由同一個人花更多時間救回來，就不要只看產出速度，忽略修復工作。
停止也不必等於刪掉所有成果。可以保留合用的模板，改回人工填寫；可以留下只讀整理，停止對外發送；也可以將範圍縮回有能力驗收的部分。停止的是目前不成立的那段流程，而不是否定先前所有學習。
有些問題則不是縮小範圍就能解決。例如，沒有任何人有權確認一個重要承諾，就不能用更多模型投票補足批准。這時應該把問題交回組織決策，而不是繼續調整生成方式。
停止的代價是回到原流程、處理已產生的檔案，以及讓相關的人知道目前採用哪個版本。它可能令人失望，但若能避免重複返工與錯誤承諾，就有實際價值。
沒有原流程，就很容易把「有產出」誤認成改善
想知道該維持、修訂還是停止，不能只問使用者喜不喜歡，也不能只看產出份數。
既有小型 AI 試行方法要求先限定場景、參與者、週期與資料範圍，保留原流程基準，再比較品質、時間、修正與失敗，最後做 go、revise 或 stop 的決定。這是可比較的設計，不是導入成效證明。
實際比較時，最容易漏掉的，是工作從一個人身上搬到另一個人身上。
原本由承辦人整理紀錄，改成 AI 先產出後，承辦人可能覺得快了；但若主管得花更久找錯、同事要回頭問來源，整段交接未必改善。因此，計算時間至少要涵蓋準備、產出、檢查、修正與交接，不只計算工具回覆的速度。
以下是自編的比較方式，不是實測數據：如果兩種方法都要交付同樣範圍的待審文件，就用相同完成條件記錄它們。不要拿「人工已核對、已寄出」的時間，去比「AI剛生成草稿」的時間。
品質也要具體。重要日期是否被錯誤確認、責任是否被指派給錯的人、衝突是否有被標出，比「讀起來專業」更接近交接工作的用途。
一個小型試行不一定有足夠樣本證明整體效率，也未必能估計罕見風險。它能先回答較小的問題：在限定範圍裡，這套做法是否反覆達到相同標準？哪些例外讓負擔增加？下一輪要維持的條件是什麼？
把繼續使用寫成有條件的決定
一次試行結束，不必交出一份「AI 導入成功」的宣告。更有用的結論，通常可以說明適用範圍與下一次要重看的理由。
例如，以下三句都是自編的決策寫法：
- 維持：目前只用於已批准材料的內部交接草稿；原審閱方式保留，尚不擴大為自動通知
- 修訂：兩份來源衝突時的處理還不穩定；先調整來源標示與確認規則，再以相同範圍重測
- 停止：審閱者無法持續檢查關鍵日期與批准狀態；正式交接暫時回到人工，保留模板與已確認材料
這三句讓接手的人知道下一步能做什麼，以及目前不能擴大的範圍。
如果需要更細的推論核對，可以回到事實、推論、建議與決策。尤其不要把「這次修正很多」直接等同工具永遠不適合，也不要把「這次很順」寫成可以全面導入。先辨認原因，再決定這個結論能適用多大範圍。
結論：能持續修正，也能停止，流程才有保留的價值
第一版完成後，留下下一次判斷會用到的紀錄：當時根據什麼資料、哪些條件成立、誰確認過，以及什麼改變會讓原決定失效。
新消息進來時，先找受到影響的判斷。條件仍成立，就維持已驗證的範圍；問題可以定位與修正，就改方法後重測；授權、品質或維護負擔已不成立，就停止那段流程，保留可用成果。
是否繼續自動化，應由下一次工作的條件決定，而不是由已投入多少設定時間決定。
下一次打開交接文件時，可以先看上一版留下的未決問題。它們是否有了答案？新答案改變了哪些原先成立的安排？能把這一段說清楚，才有理由讓下一輪工作繼續往前。