從 1 人到 80 人：用 Claude Code 擴張高速成長的工程組織（第 2/2 段）

🧑‍🏫 這段是 Base44 團隊分享他們怎麼用 Claude Code 處理三件本來很花人力的事：定實驗規則、自動測 AI 的表現、做品質檢查（QA）。值得看的地方是，他們的做法不是一開始就把系統做到完美，而是從過去的紀錄反推規則、先做出能用的版本，再慢慢改好。就算不是工程師，也可以借用這套思路。

• 12:01 希望 agent 也能在 PostDog 上開實驗；做出外殼很簡單，難的是「我們怎麼運作」的準則
  ↳ 他們想讓 AI agent（能自己動手完成任務的 AI）也能在 PostDog 開實驗。把工具接上去很簡單，難的是讓它懂團隊判斷要不要測、要怎麼測的規矩。
• 12:01 團隊從未把準則整理寫下來，也沒有準則委員會，靠的是好的產品直覺
  ↳ 這些規矩從來沒寫下來，也沒有專人負責，全靠成員的產品直覺。直覺只存在人腦裡，AI 當然學不到。
• 12:01 一個選項是組跨部門委員會開很多會，但團隊非常討厭開會
  ↳ 最傳統的做法是找各部門組委員會、開會訂規則，但這個團隊非常討厭開會，所以得換一條路。
• 12:31 想法：過去的行動最能表達準則，於是拿 PostDog 上最近 100 個實驗和對應的 pull request 來提煉準則
  ↳ 關鍵的轉念是：一個人怎麼做，比他怎麼說更準。所以他們拿最近 100 個實驗和對應的 pull request（工程師送出程式修改、請人審核的申請）來反推規則。
• 12:31 啟動 Claude Code、接上 PostDog MCP（PostDog 是 A/B testing 實驗工具），讓 Claude 提出第一版準則
  ↳ 他們用 MCP（讓 AI 連上外部工具的接法）把 Claude Code 接上 PostDog。A/B testing 就是把使用者分兩組，比較新舊版哪個好。接好後讓 Claude 寫出初版準則。
• 13:03 第一版不完美、很粗糙，但有了可迭代的文件，幾小時後就有能用的版本
  ↳ 初版很粗糙沒關係，重點是從「什麼都沒有」變成一份可以修改的文件。有東西能改，幾小時就修到能用。
• 13:03 每個開啟的 pull request 都有明確判定：直接上線、漸進式上線（gradual rollout），或做 A/B test 以及要測多久
  ↳ 準則上路後，每個 PR 都會被判定成三種之一：直接上線、gradual rollout（先開放給一小群人再慢慢擴大），或做 A/B test 並定好要測多久。
• 13:03 以他們的規模，有些功能測 7 天就夠；有些要測整整一個月，因為可能只小幅影響轉換率和 premium 比率
  ↳ 要測多久，看影響有多大。有些 7 天就看得出差別；有些只會稍微影響轉換率或升級付費的比例，就得測滿一個月才分得清。
• 13:36 用自家產品 Base44（dogfood）做中央儀表板，串接 BigQuery（資料倉儲）、PostDog、GitHub 等
  ↳ 他們用自家的 Base44 做內部儀表板，這叫 dogfood（自家產品自己先用）。資料來源有 BigQuery（存放公司大量資料的資料倉儲）、PostDog 和 GitHub。
• 13:36 儀表板讓大家看到哪些實驗在跑、效果如何、是否增加 AI 成本、是否降低發布 app 的比率
  ↳ 打開儀表板就能看到：哪些實驗正在跑、成效如何、有沒有讓 AI 的花費變高，以及會不會讓使用者比較少把 app 發布出去。
• 14:07 第二部分是 evals；他們的挑戰是短期的，需要馬上有實際價值
  ↳ 第二塊是 evals（自動檢查 AI 產出好不好的測驗）。他們當時不追求完美，要的是馬上就能派上用場。
• 14:38 不想做成三個月的專案，也不能占用頂尖 AI 工程師，他們要做功能、改善產品
  ↳ 他們不想把它搞成三個月的大工程，也不能讓最強的 AI 工程師卡在這裡，因為這些人得忙著做功能、改善產品。
• 14:38 思考要評估模型輸出，還是檢查使用者做出的 app 是否正確，最後決定打造 user simulator
  ↳ 他們考慮過直接評分 AI 的輸出，也考慮過檢查使用者做出來的 app 對不對，最後選擇做 user simulator：讓程式假扮使用者，實際去操作。
• 15:10 頓悟：使用者要的 app 有一小部分不能用，不代表 eval 失敗；eval 套件應把問題回傳，請 agent 修好缺少的部分
  ↳ 他們想通一件事：app 有一小塊不能用，不等於測驗失敗。應該像真人一樣把問題回報給 agent、請它補好，這樣才貼近真實的使用情況。
• 15:10 之後也看延遲、花了幾輪（turns）、公司成本，以及用掉使用者多少 credits
  ↳ 除了看做不做得出來，他們也記錄花了多久、跟 AI 來回幾輪、公司付出多少成本，以及扣了使用者多少 credits（使用額度點數）。
• 15:40 建立 CI-CD pipeline：AI 程式碼一有變更就啟動真實的 Base44 app 實例，用 StageHand 模擬真實使用者操作
  ↳ CI-CD pipeline 是程式一改動就自動跑檢查的流水線。只要 AI 相關的程式有變更，就開一個真的 Base44 app，用 StageHand 這個工具模擬真人操作。
• 15:40 他們把它看成一個在小盒子裡啟動的自動化 QA 工程師
  ↳ 他們把這套系統看成一個關在小盒子裡、隨叫隨到的自動 QA（品質檢查）工程師，每次有改動就幫忙試一輪。
• 15:40 支援 evals 的內部 app 同樣是用 Base44 自己打造（dogfood）
  ↳ 用來管理這些 evals 的內部 app，也是用 Base44 自己做的，又是一次 dogfood。
• 16:11 最典型的 eval 是 Hello World app，屬於 smoke test，只確認沒有東西壞掉
  ↳ 最基本的 eval 是做一個 Hello World（最簡單的入門範例）app，屬於 smoke test：就像新電器插上電看會不會冒煙，只確認沒有東西壞掉。
• 16:11 流程：請 Base44 做 Hello World app，確認文字正確顯示且好看（很主觀，但信任 AI），再要求小改文字、再加小功能
  ↳ 流程是：請 Base44 做 Hello World，檢查文字有顯示、畫面好看（這很主觀，就交給 AI 判斷），接著要它改字，再加一個小功能。
• 16:43 大多數都通過；而且這些 eval 用你想得到最小的模型也能通過
  ↳ 這類測驗大多會通過，連最小的模型都過得了。所以它的用處是抓出有沒有東西壞掉，不是拿來比較哪個模型比較強。
• 16:43 還有更複雜的 eval：從既有 app 開始做很多修改、檢查非常複雜的 compaction 機制，以及 user messages
  ↳ 也有比較難的測驗，例如從現有的 app 開始連續改很多次、檢查 compaction（對話太長時壓縮舊內容的機制），以及處理使用者訊息的情境。
• 17:13 evals 還不完美、持續改進中，但當時是建這套系統的正確時機
  ↳ 這套 evals 還不完美，一直在改進，但講者認為當時正是該把它建起來的時機。
• 17:13 第三部分是精簡 QA；他們相信 shift left 品質，unit test、end-to-end test 是基本，每個人要完全負責自己做的東西
  ↳ 第三塊是精簡 QA。shift left 是把品質把關提前到開發的當下：unit test（測單一小零件）和 end-to-end test（整段流程走一遍）是基本，自己做的東西自己負責到底。
• 17:43 深度功能有很多 edge case，例如只影響特定訂閱方案、且 credit 用到某個程度的使用者，手動測非常繁瑣
  ↳ 難的是深度功能的 edge case（少見的特殊情況），例如只有特定訂閱方案、額度又用到某個程度的人才會遇到，用手動重現非常麻煩。
• 18:14 交給 QA 工程師會拉長回饋循環、要等人有空，不理想
  ↳ 交給專職的 QA 工程師？那就得等對方有空，從改完到知道有沒有問題的時間會拉長，不理想。
• 18:14 Claude Code 能操作瀏覽器（Playwright、MCP、browser use 等），但缺關鍵：每次都要重新學平台、selectors、流程，以及要找資料庫和 Mixpanel 裡哪些事件
  ↳ Claude Code 本來就能操作瀏覽器，但每次都要重新摸索平台、selectors（在網頁上找到按鈕或欄位的定位方式）和操作流程，還得找資料庫和 Mixpanel 裡的事件紀錄。
• 18:49 把常用流程包成 skills，例如一個 skill 教 Claude Code 搭配瀏覽器走過多數功能會碰到的主要使用者流程
  ↳ 他們的解法是 skills：把常用的做法寫成說明包，讓 Claude Code 載入。例如有一份專門教它開著瀏覽器，走過大多數功能都會碰到的主要流程。
• 18:49 新功能讓 Claude Code 自己理解；skill 不必涵蓋 100%，把 80% 做好、給足 context 即可
  ↳ 遇到新功能就讓 Claude Code 自己去看懂。說明包不用包山包海，把 80% 寫好、給足背景資訊就夠了。
• 19:20 這是在「正確抽象層級」與「直接信任 Claude Code」之間的細微取捨
  ↳ 難拿捏的是要寫多細：寫太細會累死人、也很死板；寫太少它又會亂猜。要在兩者之間找到平衡，剩下的就信任 Claude。
• 19:20 第二個挑戰是測試的前置設定：像人一樣手動點到特定 edge case 會非常慢
  ↳ 第二個卡關點是測試前的準備：如果要像真人一樣一路點下去，才能把帳號弄到某個特殊狀態，會非常慢。
• 19:51 好的 QA 工程師會直接改資料庫設定來測該情境，他們需要 Claude 也能這樣做
  ↳ 厲害的 QA 會直接改資料庫，把帳號設成要測的狀態，省掉一路點過去的時間。他們希望 Claude 也會這招。
• 19:51 做了抽象化 API 和資料庫的 CLI 工具，專門用於測試前置設定，並用 skills 教 Claude 正確使用
  ↳ 所以他們做了 CLI tools（打指令就能操作的小工具），把 API 和資料庫包成簡單的指令，專門用來布置測試情境，再用 skills 教 Claude 正確使用。
• 20:22 最後整合成一個如何做好 QA 的 meta skill
  ↳ 最後把這些 skills 整合成一個 meta skill（統整其他 skills 的總綱），教 Claude 整套 QA 該怎麼做。
• 20:22 流程：pull request 開啟→觸發 agent→產生測試計畫→送到 Base44 app 開始測試→回報結果
  ↳ 實際流程是：有人開 PR，就自動叫出 agent。它先寫測試計畫，再到 Base44 app 上實際測試，最後回報結果。
• 20:22 單次測試報告有截圖，並說明測了什麼、沒測什麼
  ↳ 每份測試報告都附截圖，並清楚寫出測了哪些、沒測哪些，讓人知道還有哪些地方要自己看。
• 20:52 超出能力範圍時，它會寫「無法測試」並指出缺少的能力
  ↳ 碰到做不到的事，它會老實寫「無法測試」，並說明缺了什麼能力，團隊就知道下一步該補哪個工具。
• 20:52 約 80% 的情況有效，讓深度與 edge case 的 QA 得以 shift left、加快速度
  ↳ 大約八成的情況行得通。原本最費工的深度測試和特殊情境測試，現在也能在開發當下就完成，速度快了很多。
• 21:25 共通心得一：重視簡單，大膽又簡單；時機不對時努力不去做複雜的東西
  ↳ 心得一：做事大膽，但保持簡單。時機還沒到的時候，刻意忍住不去做複雜的版本。
• 21:25 evals 就是例子：一直延後到正確時機才做，然後全力投入
  ↳ evals 就是一個例子：他們一直延後到真正需要的時候才做，一旦決定要做，就全力投入。
• 21:58 心得二：大家說 taste 是人類對機器最後的護城河，講者也相信，但可以從過去的行動把團隊的 taste 大部分編碼下來
  ↳ 心得二：大家常說 taste（品味，也就是判斷好壞的眼光）是人類贏過機器的最後護城河。講者也相信，但他認為從過去的行動可以把團隊的品味大部分寫下來。
• 21:58 呼應上一場 memory 演講：看你上週實際做了什麼，就能理解你的準則，例如 code review、A/B testing
  ↳ 這呼應上一場談 memory 的演講：看你上週實際做了什麼，就能讀出你的標準，例如你怎麼 code review（審核別人的程式碼）、怎麼決定 A/B 測試。
• 22:30 心得三：如果能做自己也會用的產品是很大的優勢；提到 Anthropic 團隊常說做 Claude Code、Cowork 等產品時回饋循環很神奇
  ↳ 心得三：做自己也會用的產品是很大的優勢。講者提到，Anthropic 團隊常說他們做 Claude Code、Cowork 時，自己用自己改的回饋循環很神奇。
• 22:30 即使做的是例如財務 app，也要想辦法自己用（dogfood），會有價值
  ↳ 就算你做的是財務 app 這類自己平常不太會用的產品，也要想辦法在內部用它，一樣會有收穫。
• 23:01 心得四：瓶頸會一直移動；目前挑戰是持續擴展上述流程，以及做好上線後驗證（post-validation）
  ↳ 心得四：瓶頸會一直換地方。現在的挑戰是把上面這些流程繼續擴大，並做好 post-validation：上線後回頭確認有沒有真的達到效果。
• 23:01 例如修 bug 是否真的減少客服工單、功能是否真的有人用；不想靠人一直記在腦中
  ↳ 例如修完一個 bug，客服工單有沒有真的變少？新功能到底有沒有人用？他們不想靠人一直記在腦子裡追蹤。
• 23:32 業務指標不一定很快反映出來，所以他們想把這件事自動化
  ↳ 業務數字往往要過一段時間才看得出變化，靠人記得回頭檢查並不可靠，所以他們想讓這件事也自動化。

Base44 如何產生實驗準則的第一版？