Measure 被改變嘅決定同 cycle time，唔好 measure 產出量。一旦 model 令 production 變平，產出量就係一個虛榮 metric：一個團隊可以將 asset 數翻三倍而咩都學唔到，或者交付同樣數量嘅 asset 而學到好多。真正指示 AI 喺度起作用嘅訊號係：一個決定推進幾快、需要幾多 review、AI 輔助嘅版本幾常勝過舊嗰個、以及隨之而嚟咩業務結果。
我見過團隊慶祝內容產出跳升，當作佢哋個 AI 項目喺度起作用嘅證據，而個產出係嗰個變化入面最冇意思嘅部分。Measurement 係一個 AI 項目一係變誠實、一係迷失嘅地方，所以喺你擴展任何嘢之前將佢做啱係值得嘅。
陷阱：measure 變容易咗嘅嘢
默認嘅直覺係 measure 吞吐。我哋產出咗幾多 asset、上市咗幾多市場、交付咗幾多 report。呢啲數字喺 AI 之下會上升，喺 slide 度令人滿意，但佢哋 measure 嘅係 AI 變平嘅嘢，而唔係你想改進嘅嘢。
吞吐可以因為同價值無關嘅原因上升。更多 variant，如果咩都唔測，可能意味住更多雜訊。更多 report 可能意味住更多冇人需要嘅會議。更多市場可能意味住更多你係平庸嘅地方。一個好嘅 measurement 框架答嘅問題唔係「我哋產出咗更多咩？」，而係「更多嘅產出變成咗更好嘅決定同更好嘅結果咩？」。噉係兩條唔同嘅問題，而只有第二條重要。
改而 measure 咩
Measure 個 operating model，唔好 measure 生產線。四類訊號覆蓋咗大部分。速度：由 brief 到上線嘅 cycle time，以及到一個決定嘅時間。投入：每份產出嘅 senior review 時間，嗰個係 AI 原生 workflow 嘅真實成本。質素：錯誤率、返修率、以及 AI 輔助嘅工作幾常需要返工。結果：每個結果嘅成本，以及份工作本該推動嘅業務 metric。
呢啲都唔稀奇，冇一個需要新工具。令佢哋唔同於舊 metric 嘅係，佢哋 measure 判斷同流動，而唔係量。一個縮短咗 cycle time、守得住錯誤率、將 review 時間保持喺合理水平嘅團隊，確實改進咗佢個 operating model，即便 asset 數冇變。
領先訊號同滯後訊號
按時間將訊號分開。滯後訊號係業務結果——收入、pipeline、brand lift，無論呢場 campaign 係為咗咩——佢係重要嗰個，但佢嚟得遲，且受好多嘢影響。領先訊號係營運嗰啲：cycle time、review 時間、返修率、每週決定數。佢哋先郁，且喺你控制之內。
兩者你都需要，而且你需要對歸因誠實。當市場郁咗嗰陣，將滯後數字歸俾 AI 係誘人嘅。誠實嘅框架係用領先訊號證明個營運改變，用帶恰當歸因嘅滯後訊號——incrementality、control group、一個 test design——去論證個業務效果。Reporting 紀律係防止呢兩者俾人撈埋嘅嘢。
質素反指標
每一個速度 metric 都需要一個質素反指標，否則團隊會靠交付更差嘅工作嚟優化速度。如果 cycle time 係頭條，錯誤率同返修率就係護欄。如果 review 時間係效率故事，反指標係逃逸嘅缺陷——客戶或消費者發現嘅問題——係升咗定跌咗。
呢個係 AI 工作 measurement 入面最重要嘅一條紀律，因為 AI 令速度容易、令質素難。一個報咗更快 cycle、卻冇質素反指標嘅團隊，唔係喺度 measure 佢個 operating model；佢係喺度 measure 佢將工作推出門嘅能力，而嗰個恰恰係產出 review 債嘅行為。
一個簡單嘅 measurement 框架
揀一個主要營運 metric——我會由你重建過嗰條 workflow 嘅 cycle time 開始——同兩個反指標，錯誤率同 review 時間。加上一個呢條 workflow 本該影響嘅業務結果，用一個歸因得到佢嘅設計嚟 measure。四個一齊報，每月一次，並將主要指標任何一個、伴隨更差反指標嘅移動，當成一次失敗嘅改進，唔係一次勝利。
呢個框架俾刻意做薄，因為薄嘅框架會俾人用。一個有二十個 metric 嘅 dashboard 會俾人無視。四個數字，逼出速度同質素之間嘅取捨，就夠跑個 operating model，亦都夠用證據而非熱情嚟論證擴展。
擴展之前先裝儀錶
Measurement 最難嘅部分係喺你需要之前就有數字。大部分團隊先擴展一條 AI workflow，再試圖事後重建佢嘅影響，噉係一個可信嘅項目最後落得一個無法證明嘅宣稱嘅方式。紀律係喺你砌佢嗰一刻就俾條 workflow 裝儀錶：記錄 cycle time、標明 review 步驟、由開始就捕捉錯誤率。
呢個聽落似 overhead，早期確實係。但替代方案係一年之後冇 baseline、冇辦法區分條 workflow 係改進咗定只係變咗。一個簡單嘅 log——brief 幾時入嚟、幾時上線、幾次 review、邊度錯咗——就夠。你唔需要一個 platform 先開始；你需要嘅係喺擴展嗰個產出數字嘅嘢之前、記錄嗰四個數字嘅習慣。
一個演練過嘅例子
想像一個 paid social creative 循環。舊 cycle time 以日計：brief、design、review、返修、launch。轉向 model-first workflow 之後，你預期佢跌。但如果 review 時間翻倍、返修冇郁，你就冇改進個 operating model；你移咗個樽頸。
誠實嘅讀數嚟自四個數字一齊睇。Cycle time 跌、review 時間持平或略升、錯誤率持平、test 讀數質素升——噉係一次真實嘅改進。Cycle time 跌、review 時間大幅上升、返修上升——噉係一個交付得更快、更差嘅團隊，而啲反指標捉到咗佢。冇佢哋，淨係睇 cycle time 嗰張圖會顯得似一場勝利。
常見嘅 measurement 錯誤
三個錯誤反覆出現。Measure 量、並叫佢做影響，噉會奉承個項目、咩都教唔到。丟掉質素反指標，噉會俾速度遮掩份工作嘅下滑。以及將一次市場移動歸俾 AI、卻冇一個支撐嗰個宣稱嘅設計，噉管用到有人問你點知。
三個嘅修法係同一條紀律：揀個營運 metric，保持反指標附着，並明確你歸因得到咩、歸因唔到咩。一個適度、站得住嘅宣稱勝過一個大而不可證偽嘅，因為站得住嘅捱得過下一季，大嗰個唔得。
星期一應該做咩
攞你已經轉到 AI 嗰條 workflow，寫低佢上個月嘅 cycle time、review 時間同錯誤率。如果你寫唔出，噉就係第一個發現：你喺度跑一條 AI 原生 workflow，卻冇能話你知佢係咪更好嘅儀錶。然後揀一個業務結果，決定你會點樣可信咁歸因佢嘅變化。喺下一場 campaign 之前做呢件事，令 measurement 因設計而存在，而唔係作為一次重建。
FAQ
我哋該唔該算慳到嘅工時？
慳到嘅工時係一個有用嘅內部訊號，卻係一個危險嘅對外訊號，因為佢取決於關於啲人攞嗰啲時間做咗咩嘅假設。算 cycle time 同 review 時間，嗰啲係可觀察嘅，並俾工時由佢哋度掉落嚟，而唔係以佢哋領跑。
我哋點樣證明係 AI 導致咗個結果？
用一個喺份工作之前砌好嘅設計：一個 holdout、一個 matched control、或者一個 test，其中一種條件由 AI 輔助、另一種冇。冇嗰個，你可以顯示相關同改進，但宣稱唔到因果。提前砌好個設計，或接受更弱嘅宣稱。
如果業務結果因為無關原因移動呢？
講出嚟。用營運 metric 證明個 workflow 改變，並坦率承認個業務移動同市場共享。過度宣稱係一個 AI 項目喺下一季持平時就失去可信度嘅方式。
我哋該幾耐 review 一次呢啲 metric？
對一個穩定嘅 workflow，每月就夠；當你主動調佢嗰陣，每週。要點係對話嘅節奏，唔係 dashboard。一次每月固定 review 嗰四個數字，就係成個系統。
短版
Measure 被改變嘅決定同 cycle time，唔好 measure 產出量。用速度、投入、質素同結果訊號，將每個速度 metric 配一個質素反指標，並誠實咁歸因業務結果。Execution 指南覆蓋條 lane 其餘部分，面向 team lead 嘅 lane將 measurement 貫穿 operating model 嚟做。
如果你喺度 measure 你個 AI 項目，我好想聽下邊個數字最難辯護——嗰個通常係誠實嗰個。
Cheers, Chandler
本文提供繁體中文（香港）版本。課程材料（影片、模板和配套指南）以英文、日文、簡體中文和韓文提供。本網站提供 13 種語言版本。