The First Draft
為甚麼團隊應先用 agents 做內部準備,建立 AI 信任,然後才委派對外工作。
重點摘要
- AI 容易試用,但難以信任;最安全的 adoption 路徑,是先由內部準備開始,而不是對外行動。
- 把 AI 工作視為 first draft:它是供審閱的有用材料,不是已完成結果。
- 團隊透過審閱草稿、測試模式、改善背景,並只把狹窄工作由草稿推進到建議和行動,逐步累積 AI 成效。
AI 容易試用,難以信任。
這是大部分認真 AI adoption 背後的實際問題。團隊可以在幾分鐘內要求模型寫摘要、準備回覆、分類要求或建議下一步。但信任來得較慢,因為專業工作依賴背景、證據、權限和判斷。
"The first draft" 是一條用來收窄這個落差的原則。意思是先用 AI 做內部準備,而不是對外行動。Agent 準備 brief、source map、選項、checklist、draft response、meeting prep 或 test case。人在它到達客戶、顧客、病人、監管機構、供應商、員工或公共紀錄之前,審閱、修正、拒絕或使用那份工作。
重點不是 AI 輸出價值低。重點是 AI 第一個持久價值,很多時候不是最終答案,而是幫助專業人士更快、更清晰思考,同時仍然擁有結果的準備材料。
AI prepares
Draft
Human reviews
Judgment
Record notes
Corrections
Reusable checks
Evals + rules
5. Promote, then repeat
Draft -> recommend -> approve -> automate
這和 AI readiness 密切相關。系統可能準備好草擬,但未準備好發送。可能準備好準備建議,但未準備好執行。這個分別就是信任開始的地方。
First Draft 作為工作原則
First draft 原則說,AI 應由準備人的判斷開始。
實務上,這代表 agent 可以:
- 總結一組文件;
- 抽取未解問題;
- 把要求跟政策比較;
- 草擬客戶更新;
- 準備決策選項;
- 把筆記變成任務計劃;
- 識別缺失證據;
- 為 workflow 提出 test cases;
- 在會議前建立內部 brief。
人之後以專業責任審閱草稿。他們檢查缺了甚麼、甚麼沒有支持、甚麼聽起來合理但其實錯、甚麼需要升級,以及在其他人看到之前應改甚麼。
這不是表面的 review step。它是令早期 AI 使用有用,同時不假裝系統已準備好被委派的營運邊界。
這條原則在日常工作中很實際。團隊可以明確說:AI 版本不是客戶版本、不是正式意見、不是批准紀錄,而是審閱材料。這樣做會降低壓力,也提高透明度。審閱者知道自己不是在檢查一個已經被包裝成完成品的答案,而是在使用一份可以被拆開、改寫、拒絕和學習的草稿。
為甚麼信任很難
AI 系統可以在周邊 workflow 可信之前,先產生流暢輸出。
NIST 的 AI Risk Management Framework 在這裏有用,因為它把可信 AI 視為生命週期和情境問題,而不只是模型品質問題。它圍繞 governance、mapping、measurement 和 management 設計風險管理,並要求機構在情境中考慮 validity、reliability、safety、security、accountability、transparency、explainability、privacy 和 fairness(NIST AI RMF1)。
這很重要,因為一份看起來好的輸出,仍然可以因為文字以外的原因在專業工作中失敗:
- 模型沒有最新來源;
- workflow 權限不清楚;
- 政策例外藏在另一個系統;
- 語氣不適合該段關係;
- 建議一般而言正確,但在這個個案錯;
- 答案漏了不確定性;
- 審閱者無法檢查證據。
因此,信任不是問輸出聽起來好不好而建立。信任是透過反覆看見系統在真實限制下如何運作而建立。
這也是為甚麼一次性的 prompt training 不足以建立信任。培訓可以教人如何發問,但信任來自看見 AI 在本機構文件、本團隊例外、本客戶語氣、本工作節奏中如何失手和如何有用。每次審閱都提供一點證據:這類來源它找得到嗎?這類風險它會不會漏?這類語氣它會不會寫得太硬?這些證據累積起來,才會形成可管理的 delegation。
為甚麼太早做對外工作會有風險
對外 AI 工作有外部後果。它可能發送訊息、建立承諾、更新紀錄、批准一步、拒絕要求,或把機構判斷暴露給審閱圈外的人。
這不是建立信任的好起點。它要求團隊在學習系統的同時,讓系統製造後果。
內部準備改變風險輪廓。壞草稿可以被修正。薄弱 source map 可以被改善。缺失假設可以被發現。錯誤分類可以變成 test case。機構可以學習,而不用讓 AI 的第一次失敗對外可見。
這不代表 agents 永遠不應行動。意思是行動應該在團隊明白 agent 擅長甚麼、在哪裏失敗、需要甚麼背景,以及哪些行動低風險、可回復和可觀察之後才來。
對外行動亦會改變人的審閱心理。當系統已經把訊息送出、紀錄改了、承諾建立了,人再介入就是補救,不是審閱。First draft 把錯誤留在內部,讓團隊可以用較低成本修正模式。這對早期 adoption 特別重要,因為最有價值的學習往往來自第一批錯誤。
Anthropic 對 building effective agents 的建議提出相近營運觀點:由簡單、可組合的模式開始,只在需要時增加複雜度,並在系統更 agentic 時使用清楚 workflows、tool interfaces、checkpoints 和 evaluation(Anthropic3)。First draft 是這條原則在 adoption 上的應用:早期系統留在準備之內,直到團隊有證據證明更廣委派值得。
內部準備教團隊 agent 如何工作
First-draft work 的第一個好處是學習。
人們常把 AI adoption 說成機構在測試一個工具。實際上,機構是在測試工具、workflow、資料環境和專業判斷之間的關係。
內部準備讓團隊觀察 agent 行為,而不用躲在完成輸出後面。審閱者開始看見模式:
- 哪些 prompts 產生有用結構;
- agent 會過度重視哪些來源類型;
- 它何時會問澄清問題;
- 它何時用假設填補缺口;
- 它如何處理互相矛盾的證據;
- 它在哪裏需要例子;
- 哪些任務需要更窄指令;
- 哪些任務暫時不應用 AI。
這種知識很難從一次性 pilot 或通用 productivity metric 得到。它來自重複工作:agent 準備某些東西,專業人士把它跟工作的現實比較。
例如,一個客戶服務團隊可能發現 agent 很擅長整理交付日期,卻經常漏掉關係語氣;一個 finance team 可能發現它能抽取續約日期,但需要更好方法分辨最新發票和歷史發票;一個 legal team 可能發現它能找出相關條款,但會低估例外條款的重要性。這些不是泛泛而談的 AI 風險,而是可以被轉化成模板、資料連接、檢查和審閱指引的具體學習。
McKinsey 2025 State of AI 研究發現,很多機構使用生成式 AI,但較少報告成熟、規模化的影響;看到更多價值的公司,更可能重新設計 workflows,而不只是加入工具(McKinsey5)。這符合 first draft 模型。當團隊用 AI 理解和重塑工作,而不只是生成孤立輸出,adoption 會改善。
First Draft 保留專業判斷
第二個好處是判斷。
AI 可以減少 effort,但如果 workflow 把人變成被動批准者,它也會削弱注意力。一個專業人士如果只是在漂亮答案上按批准,可能會停止做令審閱有意義的工作:檢查證據、注意例外、閱讀語氣、衡量風險,並決定機構可以為甚麼負責。
First-draft workflows 令判斷保持活躍。AI 做那些通常緩慢、重複或混亂的準備工作。專業人士仍然決定甚麼準確、合適、完整和負責任。
這個分別對 agents 尤其重要。Chatbot 答案可能停留在對話中。Agent 可能使用工具、跨系統移動,並準備或採取行動。關於 agentic systems 人手監督的近期研究指出,監督不只是最後批准一步;它可以包括部署前控制、共同規劃、實時監察,以及 agent 生命週期中的事後審閱(Human oversight of agentic systems in practice6)。
First draft 位於這個監督模型的早段。它讓 agent 夠接近真實工作而有用,但又不至於自主到人失去對工作如何形成的可見度。
這種安排亦保護專業人士的技能。審閱不是只看結論是否順眼,而是看證據鏈、假設、例外和責任。當 AI 負責準備而不是直接完成工作,人仍然需要練習這些判斷。長遠而言,這比把人放在最後批准位置更健康,因為團隊會知道自己為甚麼接受或拒絕 AI 的輸出。
這如何改變測試
如果 AI 被視為 first draft,測試會改變。
團隊不再只問:「Agent 是否產生好答案?」它會問:
- Agent 有否使用正確來源?
- 它有否識別缺失資料?
- 它有否清楚展示假設?
- 它有否分開事實和解讀?
- 它有否保留用戶的決策權?
- 審閱者知道要檢查甚麼嗎?
- 修正有否變成可重用例子或 eval cases?
這令測試更具體。草稿可以跟 known-good brief 比較。Source map 可以檢查有否漏文件。建議可以對照政策審閱。審閱者修正可以變成未來 test case。
OpenAI 的 evals guidance 建議在量度模型表現時,使用具代表性的例子、清楚評分標準,以及 expert 或 human-labeled reference outputs(OpenAI evals4)。First-draft adoption 給團隊這種做法的原材料。每份被審閱的草稿,都可以教系統在機構真實背景中甚麼叫「好」。
實用迴圈很簡單:
1. 用 AI 準備內部草稿。 2. 由負責人審閱。 3. 記錄甚麼錯、缺失或有用。 4. 把重複修正變成 prompts、examples、checks 或 evals。 5. 只推進變得可靠的部分。
這個迴圈就是團隊由有趣 demo 走向 dependable workflows 的方法。
這個迴圈也讓 AI improvement 有記錄可循。每次修正不只是個別人改一份草稿,而是可以回答:是否需要新增來源?是否要改 prompt?是否要加入政策檢查?是否要把某類工作排除?是否要建立新的 eval case?當修正被保存和重用,first draft 就不只是節省時間,而是成為系統學習機制。
它如何累積
First-draft use 會累積,因為每份被審閱的草稿都改善 agent 周邊的營運環境。
團隊寫出更好的指令,因為它學到 agent 誤解甚麼。它改善 retrieval,因為審閱者看到哪些來源缺失。它建立更好的 templates,因為重複草稿揭示工作結構。它定義更清楚 tool boundaries,因為人們看到準備應該在哪裏停下、行動應該從哪裏開始。它建立 eval sets,因為真實審閱筆記變成 test cases。
隨時間,機構可以把某些 workflows 推進不同階段:
| 階段 | AI 角色 | 人的角色 |
|---|---|---|
| 草擬 | 準備材料給人審閱 | 檢查和修正 |
| 建議 | 連同證據提出下一步 | 決定和批准 |
| 經批准後行動 | 準備行動並等待 | 確認或拒絕 |
| 自動行動 | 執行狹窄、受監察工作 | 審閱例外和 audits |
重點是每個階段都由上一階段取得信任。團隊不應由「模型能寫一段好文字」跳到「agent 可以代表機構行動」。它應在證據支持下,由準備走向建議、經批准行動,再走向狹窄自動化。
每一次升級都應該有明確理由。由草擬升到建議,可能因為來源覆蓋穩定、審閱者修正少了、建議理由清楚。由建議升到經批准行動,可能因為權限和補救路徑已定義。由經批准行動升到自動行動,則應只限於低風險、可回復、受監察並有例外隊列的工作。這樣,信任不是感覺,而是工作證據。
這種累積方式亦令不同團隊可以用同一語言討論進度。不是「我們用了 AI」或「我們未敢用 AI」,而是「這個 workflow 已經可靠地草擬」、「這個 workflow 可以提出有證據建議」、「這個低風險步驟可以經批准後執行」。每個說法都對應不同審閱要求和不同風險。這比把 adoption 當成單一開關更準確。
當 first draft 做得好,AI 的價值會由個人捷徑變成機構學習。草稿、修正、來源缺口、審閱決定和 eval cases 會形成一個回饋系統。團隊不只是使用模型,而是在建立一套知道如何準備工作、如何保留判斷、如何逐步委派的 operating practice。
這不是甚麼
First draft 不是拒絕認真使用 AI。
它也不是說每個 AI 輸出都要永遠被人手重寫。有些任務會穩定到足以自動化。低風險、可回復、可觀察的行動,通常可以比高風險、含糊、對外的行動走得更快。
First draft 是一條排序原則。它說信任應該先在機構內建立,然後系統才代表機構到外面去。
它也不是允許含糊審閱。如果審閱者看不到來源、假設、不確定性和權限邊界,流程就是弱的。人不應被要求批准他們無法檢查的東西。
實務上會是怎樣
客戶服務
Agent 根據近期筆記、未完成任務、交付日期、決定和未解風險準備客戶更新。它不發送更新。Account owner 檢查語氣、關係背景、商業敏感度,以及證據是否支持訊息。
營運
Agent 審閱 incoming requests,並準備 triage notes:可能分類、急切程度、缺失資料、擁有人和建議下一步。Manager 審閱 edge cases,並把重複修正變成 routing rules。
法律和合規
Agent 把要求跟政策比較,並準備 memo,列出相關條款、缺失事實和開放問題。專業人士決定分析是否完整到足以依賴。
產品和工程
Agent 草擬 test cases、failure modes、release notes 或 migration checklists。工程師審閱草稿是否符合真實系統,並把漏掉的 edge cases 加入 test suite。
結論
AI 在專業工作中的第一個有用角色,往往不是最終結果,而是 first draft。
這份草稿幫助團隊準備、思考、測試和學習。它讓團隊看到 agent 如何表現,同時保留人對有後果工作的判斷。它降低早期 adoption 風險,因為錯誤仍然留在內部並可審閱。它創造更好 prompts、更好 retrieval、更好 evals、更好 tool boundaries,以及最終更好委派的原材料。
AI 信任不是在第一日就把對外責任交給 agents 而建立。它是透過反覆、被審閱的準備建立,直到機構知道 agent 能做甚麼、不能做甚麼,以及人的判斷仍然在哪裏重要。
這條路徑不一定慢。相反,它通常比直接追求自主更快到達可靠價值。因為團隊不用先解決所有權限和對外風險,已經可以在內部準備、審閱和測試中取得收益。當某些模式反覆可靠,再把它們升級到建議或經批准行動,就有真實 evidence 支持,而不是靠 demo 印象。
最終,first draft 不是降低 AI 的角色,而是讓 AI 的角色更清楚。它把 AI 放在準備、學習和改善工作的位置,讓人保留判斷和責任。這正是專業環境中信任可以累積的方式。
這也讓團隊可以更誠實地面對限制。某些草稿會很好,某些會漏來源,某些會暴露資料結構問題,某些會顯示 workflow 本身未定義清楚。這些發現不代表 AI 無用;它們正是 adoption 需要的材料。First draft 把這些限制放在可審閱的位置,讓團隊可以改善,而不是在對外行動後才補救。
對管理層而言,first draft 亦提供一條較低風險的投資路線。先量度準備時間、審閱修正、來源覆蓋和 reviewer confidence;當數據顯示穩定,再決定是否增加工具權限或自動化。這比一開始就承諾 autonomous agent 更可靠,也更容易向專業人士解釋。
這條路線也能幫助不同資深程度的人。初級同事得到更好的起點,不用由空白頁開始;資深同事得到更清楚的審閱材料,可以把時間放在判斷;管理者得到更明確的改進訊號,可以知道應該改善資料、流程還是訓練。First draft 因此不是單一 productivity trick,而是一種把 AI 放進專業學習和問責結構的方法。
當這種方法持續運作,AI adoption 就不再靠個別 champion。它會變成團隊共同的工作方式:準備、審閱、修正、學習,再逐步委派。
這亦令風險討論更成熟。團隊不需要在「完全不用」和「完全自動」之間選擇,而可以指出每個 workflow 現在處於哪個階段、下一個可靠升級需要甚麼證據、哪些邊界暫時不能越過。First draft 提供的是一條可走的路,而不是一次信仰跳躍。
資料來源
- NIST AI Risk Management Framework 1.0
- NIST AI Risk Management Framework overview
- Anthropic, "Building effective agents"
- OpenAI, "Evals"
- McKinsey, "The State of AI: How organizations are rewiring to capture value"
- Dhanush Kumar, Jenna Wiens, Michael Madaio, "Human oversight of agentic systems in practice"
/ 開始
先由一個營運範圍開始,再逐步擴展。
由一個清晰的審閱節奏、工作流程或團隊開始,找出更好的營運背景能即時改善準備和判斷質素的地方。