AI Native 工程團隊的三個轉折點：Harness Engineering、非同步管理、AI 當老師

我昨天寫了一篇 如何打造 AI Native Org，拆解了 Anthropic 內部工程團隊的完整管理方法論。但寫完之後我一直在想一個問題：具體對 IT 團隊來說，要怎麼開始？

答案是三件事：Harness Engineering、非同步管理（AI 數位助手）、以及把 AI Coding 當成團隊最好的老師。

為什麼是這三件事，不是其他二十件？

先講選擇邏輯。

一個 IT 團隊想做 AI Native，能做的事情太多了——AI Code Review、AI 寫文件、AI 做 sprint planning、AI 做 incident response、AI 做 on-call 分析。每一個都很有道理，每一個都有文章在推。

但你回去看所有這些場景，會發現它們大致分成兩類：

第一類：加速人類現有動作。 人本來就在做這件事，AI 讓它快 30%-50%。例如 AI 幫你寫 boilerplate code、AI 幫你整理會議記錄。

第二類：改變誰是主詞。 這件事從「人做 AI 輔助」翻轉成「AI 做 人監督」。流程的主詞從 human 變成 agent。

第一類是 application 層的優化，做了有感，但不會改變結構。第二類才是 kernel 層的替換。

Harness Engineering 跟數位助手，恰好各自覆蓋了工程團隊最大的兩塊時間消耗，而且都屬於第二類：

實踐 舊模式（人是主詞） 新模式（AI 是主詞）
Harness Engineering 人寫測試 → 人寫程式碼 AI 寫測試 → AI 修復 → 人驗證架構
數位助手 人追頻道 → 人看 PR → 人盯 Bug 數位助手追蹤所有信號 → 人做深度對話

選這兩件事的另一個原因是：它們的導入門檻比你想像的低。 不需要自架 multi-agent 平台，不需要接 MCP，不需要搞向量資料庫。一個合適的數位助手加上你現有的內部頻道，就能開始。

Harness Engineering：把最痛苦的事交給最不怕痛的

附註： Anthropic 原文把這個實踐叫做「TDD 2.0」，但我覺得它更像是 Harness Engineering——重點不在測試驅動開發的迭代循環，而在於人類搭建驗證護欄（harness），AI 在護欄裡面自主執行。叫 TDD 2.0 容易讓人以為只是「AI 幫你寫 test」，但實際上整個工程流程的主詞已經翻轉了。

舊 TDD 為什麼失敗了

測試驅動開發（TDD）的原理依舊偉大——先定義預期行為，再實作。這個邏輯在工程上完全正確。

但過去二十年的現實是：大部分團隊不寫測試。

不是因為他們不知道測試重要，而是因為寫測試的沉沒成本太高。你花兩小時寫一個功能，再花三小時寫測試。測試寫完才發現需求改了，兩邊一起改。改完又多出三個 edge case 要補。

工程師的體感就是：寫測試比寫功能還累，但完全沒有成就感。 就像被逼著吃花椰菜——你知道營養，但每一口都在跟本能對抗。

結果就是大部分團隊只在 CI 要求的地方勉強寫一些 test，coverage 掛在 60% 上下，真正有用的 test 可能不到一半。

Harness Engineering 的翻轉

Harness Engineering 的核心不是「AI 幫你寫測試更快」，而是整個循環的主詞變了：

舊 TDD（人工吃苦）： 人寫測試 → 測試失敗 → 人寫程式碼 → 通過

Harness Engineering（護欄驅動）： AI 寫測試 → 測試失敗 → AI 生成修復 → 人類專注架構驗證

差別在哪？人類從「寫測試和寫代碼」的苦工中解放出來，專注在最高價值的環節：判斷這個架構對不對、這個行為是不是我們要的。

實際怎麼落地

落地實踐：從哪裡搭建護欄

我們的做法很簡單：專注在 PRD 跟 Testing Plan 上。 但這其實是擇一專注——你不需要兩個都從頭寫，因為 AI 可以幫你從一個轉出另一個。

關鍵是看你面對的是什麼系統：

老系統 → Testing Plan 優先。 老系統已經在跑了，你的目標不是重寫，是確保改動不會炸掉現有功能。這時候 Testing Plan 的效益最高——先把「系統現在應該有的行為」用測試計畫釘死，AI 就有護欄可以在裡面安全作業。而且 Testing Plan 寫好之後，AI 一鍵就能轉成 PRD，因為測試計畫本身就在描述「系統應該做什麼」，那就是 PRD 的核心內容。

新系統 → PRD 優先。 新系統還沒有東西在跑，你需要的是先定義「我要蓋什麼」。這時候 PRD 的效益最高——把需求寫清楚，AI Coding 的產出品質會直接拉上來。PRD 轉 Testing Plan 的保真度也很高，因為需求描述得夠精確的話，AI 幾乎可以直接從 PRD 生成對應的測試案例。

不管走哪條路，最後人類做的事情都一樣：判斷這些測試最後的表現行為，是不是合乎我們的需求。 人類做的是判斷，不是實作。

至於測試代碼本身的生成和執行，用 Codex 來做 Automation 即可。寫測試、跑測試、根據測試結果修復代碼——這些重複性的苦工，AI 做得比人快，而且不會抱怨。

實戰案例：三層護欄防護網

舉我自己的例子。我現在用 Claude Code 寫 code，整個流程是這樣的：寫完之後，我會先用 Codex 透過 PRD 做第一層 source code review——它會對照 PRD 的需求規格，檢查實作有沒有漏掉什麼、有沒有偏離原始需求。然後再請 Claude Code 利用 Automation 來跑 testing，自動生成測試、自動執行、自動修復。最後人還是會介入進行 code review，但這時候我看的不是語法對不對，而是架構合不合理、有沒有安全疑慮、效能會不會有問題。三層護欄：AI review PRD 合規 → AI 跑測試 → 人審架構。

非同步管理：數據追蹤交給 AI 數位助手，人去做該做的事

非同步管理：AI 數位助手信號流

管理者的時間都花在哪

我自己帶過團隊，也輔導過十幾個 IT 主管。我可以很確定地說：大部分工程主管 60% 以上的時間，花在資訊收集和狀態追蹤上。

每天早上打開內部頻道——不管是 Teams、Google Chat、LINE 還是什麼都好——先看有沒有客戶反饋、有沒有 P0 incident、有沒有 deploy 出問題。然後看 GitHub，昨天的 PR 合了幾個、哪些卡住了、code review 有沒有人拖太久。再看 Jira 或 Linear，sprint 進度怎樣、哪些 ticket 過期了。

這些資訊收集完，一個早上過去了。然後開始開會。會議上大部分時間也在「同步資訊」——你做到哪了、那個 bug 修了嗎、客戶那邊回什麼了。

真正有價值的管理行為——深度 1-on-1 對話、架構決策、團隊發展規劃——被擠到行事曆上找不到空隙的角落。

數位助手怎麼改變這件事

你可以把它想成一個永遠不下班的管理數位助手——像 OpenAI 內部用的 Open Claw 那樣的東西。不需要自己從零蓋，現在很多工具已經能做到類似的效果。核心概念是：把「資訊收集→整理→摘要」這整條鏈交給一個數位助手，管理者直接從「已整理好的信號」開始工作。

具體的信號流：

內部頻道顧客反饋（Teams / Google Chat / LINE 都行）→ 數位助手自動掃描、分類、標記情緒、抓出 actionable items → 管理者每天看一份 3 分鐘摘要

PR（程式碼合併）總結 → 數位助手統計合併速度、標記長期未 review 的 PR、摘要重大架構變更 → 管理者只看標記出來的異常

Bug 趨勢追蹤 → 數位助手分析 Bug 分佈（哪個模組、哪個 severity、回歸還是新增）→ 管理者看趨勢圖和建議優先級

專案 Issue 指標 → 數位助手統計目前 open issue 數量、已解決數量、未解決清單、平均解決時間（MTTR），當某個模組的未解決 issue 堆積超過閾值或平均解決時間異常拉長時，即時預警推播 → 管理者不用等週會才發現專案卡住了

管理者消化完這些信號之後，可以再透過數位助手發起後續行動——自動排會議、自動建 ticket、自動 ping 相關人員。

管理者的核心任務變了：數據追蹤交給 AI，省下的時間用來引發有意義的 1-on-1 深度對話。

舉我自己的例子。我現在跑四隻 Open Claw（雲端跟地端各兩隻），讓它們大量 review 團隊目前的 status——程式碼變更、Issue 進度、部署狀態、頻道裡的異常訊號。我給它們的指令很簡單：平常不用煩我，但一有狀況，期待在一小時內通知我。這樣我就不用每天花兩小時自己去翻各個系統，只在真正需要介入的時候才出手。

不是不管事，是管對的事

我知道有些主管聽到這裡會很焦慮：「那我的存在價值是什麼？如果 AI 都幫我追了。」

這個焦慮的根源是：很多主管的 identity 跟「掌握資訊」綁在一起。「我知道每個人在做什麼」是他們的安全感來源。把這個交給 AI，等於交出了安全感。

但你冷靜想一下——你真的需要親自看內部頻道每一條訊息嗎？你真的需要知道每一個 PR 的內容嗎？還是你需要知道「哪些事情偏離了預期」？

管理者真正無法被 AI 取代的能力是：

  1. 察覺人的狀態。 某個工程師最近 PR 品質下降，不是因為技術問題，是因為他跟另一個組的合作有摩擦。這件事 AI 看不出來，要在 1-on-1 裡聊才會浮出來。

  2. 做模糊判斷。 兩個技術方案都可行，選哪個取決於團隊未來六個月的方向、客戶的隱性需求、組織政治。這些 context AI 沒有。

數位助手釋放出來的時間，應該全部灌進這兩件事。

你是這個 Harness 的最後一層

前面講 Harness Engineering 是用測試護欄讓 AI 在裡面安全作業。其實管理者在組織裡扮演的角色也是一樣的——你就是專案交付物的最後一道護欄。

數位助手幫你追蹤數據、掃描異常、生成摘要，這些都是自動化的護欄層。但最後一層永遠是你：對重要的專案交付物，適時阻擋那些不該出去的東西。

一個功能做完了但測試覆蓋不夠——你擋。一個 PR 改動了核心架構但沒有足夠的 review——你擋。客戶催著上線但你知道這版有風險——你擋。

團隊信不信任你，不是因為你追蹤得多仔細，是因為你在關鍵時刻擋了什麼。 數位助手讓你有餘裕去看見那些該擋的時刻，而不是被日常瑣事淹沒到根本沒注意到問題已經出去了。

坦白講：導入的阻力

阻力一：主管覺得「沒在追蹤就等於失控」。 這是最大的心理障礙。解法是先讓他們跑一週——AI 的摘要跟你自己追蹤的結果對照一下。如果 AI 的摘要涵蓋了 90% 你會注意到的事情，那你手動追蹤的那些時間就是浪費。

阻力二：數位助手設定初期需要調校。 第一版的摘要通常太囉唆或太簡略。你需要大概兩到三週的迭代才能找到「剛好」的粒度。這段時間主管會覺得 AI 不好用，會想回去手動追。要撐過去。

阻力三：有些資訊確實需要人類直接介入。 P0 incident、客戶投訴升級、人員離職——這些事情摘要不夠，你需要即時反應。所以數位助手不是取代所有管理行為，而是取代日常的、重複的、低判斷門檻的追蹤工作。

AI Coding 不是替代，是你團隊最好的老師

前面兩件事講的是流程改造。第三件事講的是人。

很多主管導入 AI Coding 之後，最擔心的事情是：「團隊會不會因為 AI 寫 code 就不學了？」

我的觀察剛好相反。AI Coding 是幫助團隊成員走向 Full Stack 的極佳助手。 它不是替代你的工程師，而是給每個人配了一個 24 小時不下班的老師。

為什麼說它是老師？因為它同時具備三件傳統教育做不到的事：

一、24 小時隨時回答 debug 和觀念問題

以前一個前端工程師遇到後端的問題，要嘛等資深同事有空，要嘛自己 Google 半天。現在他可以直接問 AI：「這段 SQL query 為什麼跑得慢？」「Kubernetes 的 pod 一直 restart，log 長這樣，是什麼問題？」

不用等人、不用不好意思問、不用擔心問了笨問題被唸。學習的摩擦力降到接近零。 這對團隊裡那些想學但不敢問的人來說，是巨大的解放。

二、先做 Demo 再學，效率最高

傳統學習路徑是：看教學 → 理解概念 → 動手做 → 犯錯 → 修正。這條路很長，大部分人卡在第一步就放棄了。

AI Coding 把這條路翻過來：先讓 AI 做一個 Demo 出來，你看到成品之後，再回頭學它怎麼做的。 這就是「先有結果，再理解過程」的學習法，效率比傳統路徑高太多了。

一個只會寫 React 的前端工程師，讓 AI 幫他生成一個完整的 Python API，跑起來看到結果之後，他會開始問：「這個 FastAPI 的 decorator 是什麼意思？」「為什麼要用 async？」好奇心是從看到成品那一刻開始的，不是從讀文件那一刻。

三、對未知領域快速給出分析和 Roadmap

團隊要導入一個從沒碰過的技術——比如 Terraform、比如 Kafka、比如 GraphQL——以前的做法是指派一個人去研究兩週，回來報告。

現在你可以讓 AI 先給你一份完整的分析：這個技術解決什麼問題、適合什麼場景、跟我們現有架構怎麼整合、導入的 roadmap 建議是什麼、常見的坑有哪些。兩小時就有一份 70% 準確度的技術評估， 剩下的 30% 才需要人去深入驗證。

這不是偷懶，這是把「從零到有」的探索成本壓到最低，讓人的時間花在「從有到精」的判斷上。

對團隊的一句話：拼了老命要跟上

我跟團隊講這件事的時候，最強調的一點是：千萬不要因為有了 AI 就放棄學習。

AI 是老師，不是替身。它可以幫你寫 code、幫你 debug、幫你做 Demo，但如果你不去理解它為什麼這樣寫，你就永遠只是一個按按鈕的人。按按鈕的人最容易被取代。

真正不會被取代的是：理解 AI 產出的原理，能判斷它對不對，能在它出錯的時候知道怎麼修。 這些能力只有透過持續學習才會有。

舉我自己的例子。我其實不熟 GEO 和 SEO，但我在寫 blog 的過程中，不斷地問 GPT：這篇文章怎麼寫更有傳播性？要下哪些 tag？開頭的 hook 怎麼設計才能留住人？CTA 要放在哪裡、怎麼寫才不會讓人反感？每寫一篇我就學一點，現在我對 SEO 的理解已經比半年前好太多了——不是因為我去上了什麼課，而是因為我每次實作的時候都有一個老師在旁邊即時回答我的問題。

AI 把學習的門檻降到史上最低。以前你想學一個新技術要花兩週，現在可能兩天就能上手。門檻低不代表不用學，代表你沒有任何藉口不學。

三件事的交會點：釋放的是同一種資源

三件事的交會點：釋放人類注意力

回過頭看，Harness Engineering 釋放的是工程師的注意力——從「寫語法」轉移到「審架構」。非同步管理釋放的是主管的注意力——從「追進度」轉移到「帶人」。AI 當老師釋放的是團隊的學習瓶頸——從「等人教」轉移到「自己探索」。

三件事都在做同一件事：把人類的注意力從低價值的機械性工作中解放出來，重新投入到高價值的判斷性工作中。

這才是「AI Native」的真正定義——不是用了多少 AI 工具，而是人類的注意力被配置在哪裡。

傳統組織的注意力配置大概是這樣的：

  • 60% 資訊收集與狀態同步（低價值，機械性）
  • 25% 執行與產出（中價值，但日益可自動化）
  • 15% 判斷、決策、人際（高價值，不可自動化）

AI Native 組織的目標配置：

  • 10% 資訊收集（AI 做完人看摘要）
  • 30% 驗證與監督（確保 AI 的產出正確）
  • 60% 判斷、決策、人際（高價值工作佔主導）

你不需要一口氣做到這個比例。但 Harness Engineering、非同步管理、AI 當老師是最先能推動的三個槓桿——前兩個覆蓋「60% 低價值時間」裡最大的兩塊，第三個則是確保團隊有能力承接那 60% 高價值工作。

如果你是團隊 Team Lead，怎麼從下週一開始

如果你被說服了，這是我建議的最小可行路徑：

第一週：Harness Engineering 試點

  1. 選一個模組，不要選最核心的，選一個邊界清楚、變更頻繁、目前測試覆蓋率低的模組。
  2. 在這個模組的 PR 流程裡加一步：提交程式碼後，用 Claude Code 或 Cursor 自動生成 unit test。
  3. 工程師只 review 兩件事：測試描述的行為對不對（spec）、修復有沒有壞架構（architecture）。
  4. 跑兩週，量三個數字：測試覆蓋率變化、bug 逃逸率變化、工程師花在寫測試的時間變化。

第一週：數位助手試點

  1. 盤點你每天追蹤的信號來源：內部頻道幾個群組、GitHub 幾個 repo、Jira 幾個 board。列出來。
  2. 選最吵的一個頻道（通常是客戶反饋或 incident 頻道），設定一個數位助手每天早上跑一次摘要。
  3. 第一週自己也照舊追蹤，拿數位助手的摘要跟你自己的筆記對照。看它漏了什麼、多了什麼。
  4. 第二週開始只看摘要，把多出來的時間全部拿來加長 1-on-1。

兩週後

你會知道這兩件事對你的團隊有沒有用。如果有用，擴大範圍。如果沒有用，至少你花的成本很低——兩週、一個模組、一個內部頻道。

如果你是一人公司，怎麼從下週一開始

上面講的是帶團隊的情境。但如果你是自己一個人扛所有事——接案、寫 code、回客戶、追帳務——這兩個趨勢對你更重要，因為你的注意力是最稀缺的資源，而且沒有人可以幫你分攤。

Harness Engineering：一人公司更要專注測試計畫

一人公司最容易犯的錯就是「寫完就上線，出事再修」。因為沒有 QA 團隊，測試永遠被排在最後面，然後永遠沒做。

前面講團隊要專注測試計畫，一人公司其實更需要。因為你沒有人幫你 review、沒有人幫你抓漏、出了事只有你自己要扛。測試計畫就是你唯一的安全網。

但一人公司的測試計畫不需要寫成文件——你只需要在寫完功能之後，花三分鐘想清楚：這個功能最重要的三個行為是什麼？什麼情況下它應該要報錯？邊界在哪裡？

想清楚之後，剩下的交給 AI。

具體做法：

  1. 寫完功能後，把你想到的行為預期告訴 AI：「這個 API 應該要做到 X、Y、Z，空值要報錯，超過上限要截斷」。讓 Claude Code 或 Codex 根據你的測試計畫生成完整的 test。
  2. 花五分鐘看測試描述，不是看 code，是看每個 test case 的名字——「should return error when input is empty」這種。判斷它有沒有覆蓋你在意的場景。
  3. 讓 AI 跑測試、修 bug，你只看最後結果。
  4. 累積下來的測試就是你的護欄，下次改 code 的時候，跑一次就知道有沒有改壞東西。

一人公司沒有 QA，但你有測試計畫加上一個永遠不睡覺的測試 Agent，效果比很多五人團隊的測試覆蓋率還好。

數位助手：你就是自己的 PM

一人公司的另一個痛點是：你同時是 PM、工程師、客服、會計。每天打開電腦，光是搞清楚「今天最重要的事是什麼」就要花半小時翻 Email、翻對話紀錄、翻 Notion。

數位助手在這裡的用法不一樣——不是追蹤團隊，而是追蹤你自己的所有輸入源。

具體做法：

  1. 每天早上讓數位助手掃一遍你的輸入源——Email、LINE 對話、專案管理工具、行事曆。生成一份「今天需要你注意的事」摘要。
  2. 按照摘要的優先級做事，而不是按照「誰最後一個傳訊息給你」的順序做事。
  3. 每週五讓數位助手生成一份週報——這週完成了什麼、什麼拖延了、下週最重要的三件事。你不是寫給老闆看的，是寫給下週一的自己看的。

一人公司最大的敵人不是能力不足，是注意力碎片化。數位助手的價值不是幫你做更多事，而是幫你在對的時間看到對的事情。

寫在最後：AI Native 不是目的地，是方向

我不喜歡「AI Native」被當成一個 binary 的標籤——你是或不是。實際上它是一個 spectrum，每個團隊都在上面某個位置，往某個方向移動。

這三件事不會讓你一夜之間變成 Anthropic 或 OpenAI。但它們會讓你的工程團隊跨過一個關鍵的門檻：從「AI 是工具」到「AI 是流程的一部分」。

跨過這個門檻之後，後面的事情會自然發生。工程師開始問「這件事為什麼不是 AI 先做」，主管開始問「這個會議還有必要嗎」，整個團隊的思維模式會慢慢從「人 + AI 工具」翻轉成「AI + 人類監督」。

這個翻轉不需要大預算、不需要 AI 平台、不需要外部顧問。需要的是三個具體的流程改變，和一個願意跨出去的 IT 主管。

最後一件事：組織會變扁，但別急著砍主管

AI Native 的組織一定會越來越扁平，這是結構性的趨勢。但我強烈建議：保留有深度技術能力的 People Manager。

原因很簡單。Working level 的工程師在 AI 時代轉型過程中，需要大量的情緒支持——「我會不會被取代」「我現在學的東西三個月後還有用嗎」「我跟不上怎麼辦」。這些焦慮是真實的，而且只會越來越多。一個懂技術的主管可以用「我自己也在學，我理解你的處境」來回應，而不是用空洞的「公司很重視你」來敷衍。

同時，技術主管還要扮演技術兜底的角色。AI 產出的 code 大部分時候是對的，但在它出錯的時候，你需要一個人能看出問題在哪、判斷風險有多大、決定要不要擋下來。這個人就是有技術深度的 People Manager。

但如果你打算招一個新主管來帶 AI Native 團隊，我的建議是：先讓他做一段時間的 IC（Individual Contributor）。

這跟 Anthropic 的做法一致。外聘的主管最大的風險不是能力不足，是他會把舊框架帶進來——舊的 code review 流程、舊的 sprint planning 方式、舊的「我要看每一行 code」的管理習慣。這些在傳統團隊是好習慣，在 AI Native 團隊是拖累。

讓他先用三個月時間當 IC，親身體驗 AI Coding 的工作流、用數位助手追蹤專案、用 AI 寫測試。等他自己踩過坑、建立了直覺之後，再讓他帶人。這樣他帶出來的流程才是 AI Native 的，而不是把舊世界的 Best Practice 硬套上去。

先改測試。再改追蹤。再讓團隊用 AI 學習。剩下的，你自己會知道下一步是什麼。