方法

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 第一個持久價值,很多時候不是最終答案,而是幫助專業人士更快、更清晰思考,同時仍然擁有結果的準備材料。

Trust compounds through reviewed preparation
1

AI prepares

Draft

2

Human reviews

Judgment

3

Record notes

Corrections

4

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 提供的是一條可走的路,而不是一次信仰跳躍。

資料來源

  1. NIST AI Risk Management Framework 1.0
  2. NIST AI Risk Management Framework overview
  3. Anthropic, "Building effective agents"
  4. OpenAI, "Evals"
  5. McKinsey, "The State of AI: How organizations are rewiring to capture value"
  6. Dhanush Kumar, Jenna Wiens, Michael Madaio, "Human oversight of agentic systems in practice"

/ 開始

先由一個營運範圍開始,再逐步擴展。

由一個清晰的審閱節奏、工作流程或團隊開始,找出更好的營運背景能即時改善準備和判斷質素的地方。

預約示範
© 2026 Interfacing Research Laboratory
版權所有。