經營一個 AI-native 的工程組織（第 2/2 段） ☕ Buy me a coffee

🧑‍🏫 這是 Claude Code 團隊主管分享「AI 原生團隊」怎麼運作的後半段，內容包括哪些事交給 Claude、哪些事還是要靠人、組織怎麼調整、流程怎麼砍，以及用什麼指標看 AI 導入有沒有效。講的是團隊實際在用的做法，就算妳不是工程師，也能拿來重新檢視自己團隊的分工和流程。

• 14:20 團隊大量交給 Claude 處理的工作：程式風格、lint、PR 回饋，在正式 commit 前抓 bug 並修好，還有補測試
  ↳ 規則明確的雜事交給 Claude，像程式排版、lint（自動檢查程式寫法的工具）、PR（把修改送給同事審核的申請）上的意見、補測試。在 commit（正式存進專案）之前就先把 bug 抓出來修好。
• 14:20 需要專業判斷的地方仍然要有人：原則是 trust but verify，例如法務審查一定找法務夥伴
  ↳ trust but verify 就是「放手讓它做，但要檢查」。需要專業判斷的事，最後一定要有懂的人把關。例如法律相關內容，還是要給法務夥伴看，不能只信 AI。
• 14:20 牽涉風險承受度的地方也要找專家，例如 trust boundaries 和跟資安有關的程式碼
  ↳ 出錯代價很大的地方也要找專家。trust boundaries 指系統裡「可信」和「不可信」資料的交界，像使用者輸入進入系統的地方。這類和資安有關的程式，都要找專家看。
• 14:52 產品感和品味仍然需要人：講者過節想請 Claude Code 把終端機裡的 Claude 變成雪人，但當時 Claude 的 ASCII art 還不太行
  ↳ product sense（產品感）是判斷東西好不好用、好不好看的能力。講者過節想把終端機（打指令的文字視窗）裡的 Claude 變成雪人，但當時 Claude 用字元拼圖（ASCII art）還不太行。
• 15:23 設計夥伴看了說 Claude 被改得像 Mr. Peanut，講者就改成比較簡單的版本：冰藍色加雪花，這就是產品感發揮作用的地方
  ↳ 設計同事一看，說 Claude 被改得像花生品牌吉祥物 Mr. Peanut，講者就改成冰藍色加雪花的簡單版。AI 能把東西做出來，但好不好看、合不合適，還是要靠人判斷。
• 15:23 角色界線越來越模糊，Claude 在增強每個角色的能力。Claude Code 招工程師時最看重兩種人
  ↳ 以前工程、設計、PM 各做各的，現在 Claude 讓每個人都能做到原本做不到的事，角色界線變得模糊。所以他們招工程師時，最看重兩類人。
• 15:54 第一種是有產品感的 creative builder：愛做夢、好奇心強，看到問題就想做產品解決，也會一直迭代，把體驗做到令人愉悅
  ↳ 第一類是 creative builder（有創意、愛動手做的人）：看到問題就想做個產品來解決，做出來後還會一直修改，直到用起來順手、讓人開心。
• 15:54 第二種是有深厚系統功力的人：講者剛加入時，團隊不缺產品通才和創意人才，缺的是 distributed systems 專家
  ↳ 第二類是系統底子很深的人。講者剛加入時，團隊不缺點子多的通才，缺的是 distributed systems（讓很多台電腦分工合作的系統）專家。
• 15:54 像打造 Claude Code remote、讓 Claude 在各處都能跑，還是很需要這類專業；建議各團隊想想哪些困難的部分值得繼續加碼
  ↳ 例如做 Claude Code remote，讓 Claude 不只在自己電腦上、在各種地方都能跑，就很需要這種專業。講者建議各團隊找出自己最難的技術，在那裡繼續投資人才。
• 16:24 比較不看重的是 raw throughput（單純產出量），因為有了模型，效率已經高很多
  ↳ raw throughput 就是一個人單純能產出多少東西。有了模型，大家的產出量都拉高很多，所以這不再是挑人的重點。
• 16:24 跨職能的缺口：講者想改問卷回覆的做法卻沒有專屬 content designer，自己文筆不好、很難寫得簡短
  ↳ AI 也能補上缺的人手。content designer 是專門寫介面文字的人，像按鈕和提示語。講者想改問卷回覆的文字，團隊卻沒有這個角色，講者自己又不擅長寫得簡短。
• 16:55 終端機裡每一行空間都很寶貴，這時 Claude 就成了很好的 content design 夥伴，幫忙把文字寫得精準簡潔
  ↳ 終端機畫面小，每一行字都很珍貴，文字必須又短又準。這時 Claude 就成了講者的文字夥伴，幫忙把句子修得精準簡潔。
• 17:27 反過來，他們的 PM 也寫很多程式；非傳統工程背景的人能做更多工程，工程師也能跨到內容、設計領域，AI 讓各種角色都被增強
  ↳ 反過來也成立：他們的 PM（產品經理，負責決定做什麼）也寫很多程式。不是工程背景的人能做工程，工程師也能碰文字和設計，AI 讓每個角色能做的事都變多。
• 17:57 組織規模：招募人員還在用傳統的 10 個 IC 配 1 個 manager 來規劃，講者則堅持讓團隊保持精實（scrappy）
  ↳ IC 是自己動手做事、不帶人的成員。招募人員習慣照「10 個 IC 配 1 個主管」來規劃人力，講者則堅持團隊保持精實、靈活（scrappy）。
• 17:57 講者待過 Anthropic、Meta、Microsoft（Visual Studio、Facebook Marketplace、AR/VR 裝置、Claude），發現做出好產品的關鍵是大量 dogfooding
  ↳ 講者在 Microsoft、Meta、Anthropic 做過 Visual Studio、Facebook Marketplace、AR/VR 裝置和 Claude，發現做出好產品的關鍵是 dogfooding：自己天天用自己做的產品。
• 18:27 主管碰不到程式碼的時候，也要撥時間每天親自用自己的產品
  ↳ 主管就算已經很少碰程式，也要每天撥時間親自用自己的產品。自己用過才知道哪裡卡、哪裡難用，不能只聽報告。
• 18:27 Claude Code 每位 manager 都要先從 IC 做起，在團隊裡建立信任（street cred），也真正學會當個有效率的工程師
  ↳ Claude Code 的每位 manager 都要先當一陣子 IC、自己寫程式。一來做出成績讓團隊信服（street cred），二來真正學會當個有效率的工程師。
• 18:27 組織盡量扁平，好讓團隊非常敏捷
  ↳ 組織層級盡量少，事情不用層層上報，團隊就能很快決定、很快轉向。
• 18:58 招募人員擔心沒有 manager 願意先當 IC；講者認為這就是團隊的 dogfooding 精神，沒興趣的人早點分開比較好
  ↳ 招募人員擔心沒有主管願意先回去寫程式。講者認為這正是團隊「親自用、親自做」的精神，沒興趣的人一開始就不適合，早點分開對雙方都好。
• 18:58 講者說如果沒有 Claude，主管要切換的情境太多，自己不可能跟上進度或寫程式
  ↳ 主管一天要在很多事之間切換。講者坦言，要是沒有 Claude，自己根本不可能跟上進度，更別說寫程式。
• 19:29 在 Meta 時講者每年至少試著發一個 PR，但內部工具和流程一直變；現在連 git 指令都不記，直接請 Claude 幫忙
  ↳ 在 Meta 時，講者每年至少想發一個 PR，但內部工具和流程一直變，每次都要重學。現在連 git（管理程式版本的工具）指令都不背了，直接請 Claude 幫忙。
• 19:29 在 Claude Code 團隊，程式碼就是 source of truth
  ↳ source of truth 就是「有疑問時以什麼為準」。在 Claude Code 團隊，答案是程式碼本身，不是文件，也不是誰的記憶。
• 20:00 講者回答客戶問題時，就是用桌面版 Claude Code 加上本機 repository；以程式碼為準，也免去文件跟不上程式碼的落差
  ↳ 客戶有問題時，講者就開桌面版 Claude Code，連上電腦裡的 repository（存放專案程式碼的地方）直接問。答案以程式碼為準，就不怕文件沒更新。
• 20:00 依團隊狀況調整：如果有好的 spec，就放進 repository，請 Claude 檢查程式的執行結果是否符合 spec
  ↳ 這要看團隊狀況調整。如果有寫好的 spec（規格書，說明功能該怎麼運作），就放進 repository，請 Claude 檢查程式實際跑出來的結果符不符合規格。
• 20:30 推行方式是兩者兼顧：一部分訂成大家都要遵守的團隊規範，一部分讓 Claude Code 內各個 pod 自己決定怎麼做最合適
  ↳ 推行新做法時兩者兼顧：有些是全團隊都要遵守的規範，有些交給各個 pod（內部小組）自己決定，因為每組最清楚自己的狀況。
• 21:01 核心團隊原則每隔幾個月重新檢視一次，確認它們是否仍發揮原本想要的效果（呼應成長型思維）
  ↳ 團隊核心原則不是訂了就不動，每隔幾個月會重新檢查一次，看它們是否還發揮當初想要的效果。這呼應成長型思維：規則也可以跟著調整。
• 21:01 原則一：不只工程師，每位 Claude Code 團隊成員（包括跨職能夥伴）都用 Claude Code，大家也很常用 Cowork
  ↳ 原則一：不只工程師，連跨職能夥伴也都用 Claude Code；大家也常用 Cowork（Anthropic 讓 Claude 幫忙處理一般辦公工作的產品）。
• 21:31 原則二：Claudify everything you can。做任何事都先想 Claude 能不能幫忙，例如自動化驗證、更 shift left
  ↳ 原則二：Claudify 一切，做任何事都先想 Claude 能不能幫忙，例如自動化驗證，或 shift left，也就是把檢查提早到流程前段，越早抓到問題越省事。
• 21:31 原則三（講者最愛）：明確授權大家砍掉舊流程，並持續幫團隊取得快速回饋
  ↳ 原則三是講者最愛的：明確告訴大家「可以砍掉舊流程」。有正式許可，大家才敢動手。同時持續幫團隊縮短拿到回饋的時間。
• 22:03 例子：本來開 stand-up，團隊變大後改用試算表填每週進度，後來再改成一個 skill（stand-up script），跑 Claude 就能掌握每個人在做什麼
  ↳ stand-up 是快速同步進度的短會。團隊變大後改成每週填試算表，後來又做成 skill（寫好一套步驟讓 Claude 照著做），跑一下 Claude 就知道每個人在忙什麼。
• 22:33 要常常質疑現有流程、清掉零碎，把舊流程砍掉
  ↳ 流程很容易越疊越多、沒人敢拿掉。要常常問「這還需要嗎？」，把零碎多餘的步驟清掉。
• 22:33 各 pod 自主權很高：triage 怎麼做（或交給 Claude 做）、規劃儀式或 stand-up、on-call，以及先 Claudify 哪些工作流程
  ↳ 各 pod 自主權很大：triage（排定問題先後）自己做或交給 Claude、規劃會和 stand-up 怎麼開、on-call（輪流待命處理突發狀況）怎麼排，還有先 Claudify 哪些工作。
• 22:33 不會硬性規定「一定要自動化這個」，只提供建議和經驗，因為各團隊處理的問題領域可能不同
  ↳ 上面不會下令「一定要自動化這個」，只分享建議和經驗。因為每組處理的問題不同，這組好用的做法，換一組未必適合。
• 23:03 講者最重視的三件事之一：團隊盡量扁平。manager 帶 pod，但 Claude Code 和 Cowork 共用一個整體團隊使命
  ↳ 講者最重視的第一件事是扁平。每個 pod 有 manager 帶，但 Claude Code 和 Cowork 共用同一個團隊使命，大家朝同一個方向走。
• 23:03 如果每個 pod 各訂自己的使命，之後要轉向就得花很多時間一一溝通
  ↳ 如果每組各訂自己的使命，哪天要轉向，就得一組一組溝通、對齊，非常花時間。共用一個使命，轉向就快得多。
• 23:33 第二件事：Claudify 一切，讓人有空去做更難的工作。第三件事：流程會越堆越多，要和團隊一起找出可以放掉的流程
  ↳ 第二件是能交給 Claude 的都交出去，把人的時間留給更難的工作。第三件是流程會不知不覺越堆越多，要和團隊一起找出可以放掉的。
• 24:07 評估成效：講者不能透露具體數字，但提供三個通用指標。第一，onboarding 上手時間大幅縮短（工程師、設計師、PM 多快能發揮）
  ↳ 怎麼看 AI 導入的成效？講者不能給數字，但提供三個指標。第一是 onboarding 上手時間：新來的工程師、設計師、PM 多快能發揮，應該大幅縮短。
• 24:07 第二，PR cycle time 縮短。這項值得深入看，可能會找出 AI 導入以外的缺口，例如 pipeline 其他環節跟不上
  ↳ 第二是 PR cycle time：從送出修改到完成合併要多久。細看常會發現卡關的不是 AI，而是 pipeline（程式從寫好到上線的整串步驟）其他環節跟不上。
• 24:38 程式碼產量大增後，build、CI 等基礎設施可能跟不上工程師提交的量
  ↳ 程式碼產量暴增後，build（把程式碼組建成能跑的版本）和 CI（每次提交都自動組建、跑測試的系統）等基礎設施，可能消化不了工程師提交的量。
• 24:38 前兩項應該下降；第三項 Claude-assisted commit 應該上升。他們預設每個 commit 都有 Claude 協助，約 4 個月沒看過沒 Claude 參與的 commit
  ↳ 前兩項要下降，第三項 Claude-assisted commit（有 Claude 參與的提交）要上升。他們預設每個 commit 都有 Claude 協助，大約 4 個月沒看過例外。
• 25:09 不要只看 commit 數量，要想最終目標：想讓使用者覺得哪個產品更好用？要解決什麼問題？
  ↳ 別只數 commit 有幾個，要回到最終目的：你希望使用者覺得哪個產品更好用？你到底想解決什麼問題？
• 25:09 新聞常說某公司 X% 程式碼是 AI 產生的；產出量固然好，但要衡量你真正想解決的事
  ↳ 新聞常說「某公司 X% 的程式碼是 AI 寫的」。產出多當然好，但這個數字不等於成功，要衡量的是你真正想解決的那件事。
• 25:40 他們更關注品質和可靠性
  ↳ 所以他們更在意品質和可靠性：產品好不好用、穩不穩定，而不是 AI 寫了多少。
• 25:40 最後一節：檢視自己的做法。講者還在思考的問題一：工程師能更有效率地跨行動平台，分開的 iOS 和 Android 團隊還合理嗎？
  ↳ 最後是檢視自己的做法。講者還在想的問題一：工程師現在更容易同時做手機兩大平台，那 iOS、Android 分成兩個團隊還合理嗎？
• 26:11 問題二：全自動 review 要推到什麼程度？要在「夠快」和「漏掉重要的東西」之間取得平衡，回到 trust but verify
  ↳ 問題二：程式審查要全自動化到什麼程度？全自動很快，但可能漏掉重要問題。要在速度和把關之間取得平衡，回到「放手但要檢查」。
• 26:11 模型能力持續進步，某類工作現在需要多驗證、少信任，下一代模型出來後可能就不同，所以要不斷重新評估
  ↳ 模型一直在進步。某類工作現在可能要多檢查、少放手，下一代模型出來後可能就不同了，所以要不斷重新評估。
• 26:42 問題三：角色界線模糊之後，怎麼讓每個人都覺得自己一樣有生產力
  ↳ 問題三：角色界線模糊之後，怎麼讓每個人都覺得自己一樣有生產力？
• 26:42 帶回去的一件事：挑出你最「吵」的工作流程（最花錢、你自己或團隊最怕做的），問它是否還發揮原本的用途
  ↳ 講者給的功課：挑出你最「吵」的流程，也就是最花錢、或你和團隊最怕做的那件事，問問它現在還有沒有發揮原本的用途。
• 27:13 故事：以前有個每週 review 會議有約 50 人，大家都在用筆電，只有輪到報告時才抬頭。講者問「為什麼要開這個會」，大家同意後就取消了
  ↳ 講者以前參加過一個約 50 人的每週審查會，大家都在用筆電，輪到自己報告才抬頭。講者問「為什麼要開這個會？」大家都同意沒必要，會就取消了。
• 27:44 回去找一個工作流程，想想能不能自動化，或它是否還發揮原本的用途
  ↳ 回去找一個工作流程想兩件事：它能不能自動化？它還有發揮原本的用途嗎？

講者對 Claude Code 團隊的 manager 有什麼要求？