分享Claude Code團隊內部的5條工作原則，我覺得每一條都值得學習。

　　 今天看到了一個我覺得還挺有價值的東西。

　　 就是凌晨的時候，AIHOT上推了Claude Code的一篇blog。

　　 還是蠻少見的，很少見類似于Claude這種真正的AI公司，來分享一些組織上的一些想法和思考。

　　 特別這次分享的作者，還是當紅炸子雞Claude Code團隊的工程總監，Fiona Fung。

　　 聊得主題就是他們團隊作為AI原生組織，在工作方式和流程上的一些變化。

　　 我全部看完了，順帶也把那個半個小時演講的視頻給看完了，還是有很多共鳴的，因為很多思路和想法我們團隊也在這么做這么踐行的。

　　 尤其是她反復提到的一個習慣，就是他們團隊里，每遇到一個問題，都會再追問一句：

　　 能不能把這件事自動化。

　　 這跟我自己一直在說的理念、跟很多朋友提到的一個習慣是一樣的。

　　 就是如果一件事你需要重復3遍以上，請想盡一切辦法，用AI將其自動掉。

　　 今天看到Claude Code團隊居然在用幾乎一模一樣的邏輯來運轉整個工程組織，還是挺興奮的。

　　 所以想把這篇分享里的一些有價值的東西拎出來聊聊，希望能對大家有用。

　　 最最開始的時候，她其實有一個很有意思的判斷。

　　 就是她說過去這么多年，軟件工程的所有流程，不管是瀑布還是敏捷，所有那些規范啊方法論啊，本質上都是圍繞一個核心成本在轉，就是寫代碼太貴了這個事。

　　 工程師時間貴，所以你得花大量時間做規劃、寫需求文檔、做各種各樣的評審、開各種各樣的會，全是在管理這個最貴的資源。

　　 我相信過去在互聯網行業里面待過的小伙伴都能感同身受。

　　 但在AI時代，或者說，Agent時代。

　　 這個前提變了。

　　 在Claude Code團隊，寫代碼已經很少是那個拖慢速度的環節了。

　　 那問題就來了，如果寫代碼本身不再是瓶頸的話，那圍繞它的所有上下游的流程，就全部都得重新想了。

　　 Fiona Fung提到了一個非常核心的詞，也是她整個分享的最重要的詞：

　　 轉移。

　　 瓶頸沒有消失，只是轉移了。

　　 轉移到了驗證、代碼評審、安全。

　　 代碼生成太快了，新問題變成了，這些代碼對不對，怎么維護，人到底該如何跟得上review代碼的節奏。

　　 左邊灰色的就是是舊瓶頸，寫代碼和發布代碼的產能。右邊黑色的就是新瓶頸，驗證、評審、跨職能協作、安全。

　　 這個關于轉移的判斷，其實如果用AI來介入組織結構里面越深，大家的感觸可能就會越明顯。

　　 我們的組織結構、流程，其實都需要圍繞著這個大的變化來去重新設計。

　　 就像當年從馬車到汽車，不只是把馬換成發動機的事兒，我們的整個公路系統、交通規則、城市規劃，全都得重新設計。

　　 那具體哪些東西需要重新來呢，Fiona列了一張圖。

　　 列了五個舊流程正在悄悄失效的領域。

　　 1. 規劃方式，因為工程速度和產出量完全不同了。

　　 2. 代碼所有權，誰寫的這段代碼變成了一個很奇怪的問題。

　　 3. 代碼評審，新的規模、新的形態、新的工具。

　　 4. 團隊構成，角色在模糊化，到底什么技能組合才是你需要的。

　　 5. 知識共享，文檔不再是唯一的真相來源了。

　　 然后她對應地講了五個她們重建的新規范。

　　 包括要讓人類的判斷力，聚焦在真正需要的地方；新人入職的成本大大降低，甚至一周就可以直接開始產出代碼了；少做前期規劃，多做原型；招聘更看重創造力和判斷力，不看純產出速度；組織架構更扁平，每個管理者也都先從一線干活開始做起。

　　 這里面每一趴，她又都展開來做了一些分享。

　　 一. 規劃的變化

　　 以前因為coding時間貴，你得花大量時間提前規劃。

　　 Fiona說她剛加入Claude Code團隊的時候，他們寫了一個挺漂亮的六個月路線圖。

　　 結果呢，因為Claude Code本身迭代太快，三個月左右這個路線圖就過時了。。。

　　 所以他們現在的做法叫JIT規劃，Just-In-Time，像JIT編譯一樣，在對的時間做恰好足夠的規劃。

　　 不再寫長篇大論的設計文檔了，直接在PR或者原型里面討論，不再做冗長的產品評審了，先做原型，讓內部用戶去用，然后根據反饋快速迭代。

　　 左邊是她們砍掉的東西，就是那個寫代碼之前必須先寫設計文檔的儀式。Fiona說對大部分工作來說這就是theater，做戲。現在換成原型先行，文檔如果需要存在，寫完代碼之后感覺可以的話，再補需求文檔。

　　 右邊是她們加碼的東西，驗證。因為在AI原生的工作流里，東西出bug的方式跟以前不一樣了，唯一能保證質量的方式就是不斷把驗證流程往前推。

　　 她還講了一個觀點我覺得特別好。

　　 在技術討論中，代碼贏才牛逼。

　　 就是如果兩個人對一個方案有分歧，最快的解決方式不是繼續吵，是讓Claude把兩個方案都做成原型，看實際的東西來判斷。

　　 Building is cheap，做東西很便宜。

　　 Arguing is expensive，爭吵才昂貴。

　　 想起了當年，互相爭某個方案，然后各自PK可能要各寫一份PPT，開兩輪會來討論，現在十分鐘兩個原型都出來了，看著實物聊比對著PPT吵高效一萬倍。。。

　　 我自己也是類似的路徑。以前做AIHOT的時候還試過寫比較詳細的PRD，結果發現寫PRD的時間比我直接用Claude Code把東西做出來還長。。。

　　 后來就改了，有想法先做原型，能用了再說。

　　 很多功能都是在用的過程中發現不對，當場就改，極速迭代。。。

　　 坦率的講，在AI時代，我覺得過度規劃就是浪費。

　　 二. 自動化的變化

　　 Fiona說的，在Claude Code團隊里，他們每遇到一個這樣的問題，都會追問一句，能不能把這件事自動化。

　　 她舉了一個她自己的例子，她以前每天早上端著咖啡，手動去總結各個客戶反饋渠道的內容，這是她的每天固定的工作。

　　 后來她把這件事變成了一個后臺自動運行的任務，咖啡還是那杯咖啡，但她不再需要邊喝邊刷了。

　　 這個例子聽起來很小對吧，就一個總結客戶反饋的事兒，能有多大工作量。

　　 但重點不在這一件事，重點在這個習慣。

　　 Claude Code團隊里每個人，每次遇到一個重復性工作，都會條件反射地問自己，能不能自動化，她說，已經快形成了一種肌肉記憶。

　　 這就是我一直在說的東西。如果一件事你需要重復3遍以上，請想盡一切辦法用AI將其自動掉。在公司里面我反復跟團隊講，這甚至不是建議，是要求。

　　 但坦率的講，要真正把這個變成團隊的肌肉記憶，比說出來難太多了。

　　 因為大多數人對自動化的理解還停留在一個很粗的層面，覺得自動化就是寫個腳本嘛，搞個定時任務嘛，這我知道，但AI時代的自動化跟以前完全不是一個量級的東西。

　　 現在你用Claude Code，很多自動化的事情十分鐘就搞定了，甚至不用十分鐘。

　　 比如我為了同步家里電腦和公司，我就跟Claude說了一句“幫我寫一個hook，每次打開我的XX項目之前都去github拉取最新的代碼”，幾分鐘就能跑起來。

　　 以前自動化成本高，所以只有高頻、高重復度、高價值的事情才值得自動化，但現在自動化成本幾乎為零，邏輯就反過來了，幾乎所有重復超過3次的事情都應該自動化。

　　 除了工作流之外，觸發器hook是一個非常好用的東西，這個我感覺以后我可以單獨給大家寫一篇Agent+hook搞自動化的一些小玩法，還是挺有意思的。

　　 一個一個小的自動化攢起來，你會發現，最后這些東西，會在你可能都沒反應過來的時候，一起長成了一顆蒼天大樹。

　　 所以如果你現在還在猶豫要不要開始，我的建議是別想太大。

　　 別一上來就想著我要搭建一個完整的自動化體系這種東西，那太嚇人了，也沒必要。

　　 就從今天開始，找一件你今天重復做了的事情，花十分鐘讓Claude Code或者Codex幫你自動化掉。

　　 明天再找一件，后天再找一件，一個月以后你回頭看，你的工作方式已經完全不一樣了。

　　 三. 代碼評審的變化

　　 代碼評審這塊，Fiona說她過去六個月跟其他工程leader聊天，被問到最多的一個問題就是，你們人怎么跟得上代碼review的速度。

　　 她的做法叫Trust but verify，信任但驗證。

　　 Claude Code團隊大量使用Code Review功能。

　　 Claude負責處理所有的風格檢查、linting、PR反饋、bug捕捉和修復、補充測試，這些以前可能占了review工作量60-70%的部分，現在Claude全接了。

　　 但人類review仍然不可替代，在那些真正需要專業判斷的地方。

　　 法律合規的東西，Fiona說她永遠需要她的法務伙伴參與風險評估，信任邊界和安全敏感代碼，需要領域專家，產品方向和品味的判斷，需要PM和設計師。

　　 而且她特別強調了，這個trust和verify之間的平衡是動態的。今天需要人來做的事情，下一個模型可能就能做了，所以你必須得不斷重新評估這條線。

　　 這就跟打游戲一樣嘛，每個版本的版本答案都不一樣，你不能拿上個版本的攻略打新版本，那只會被人干死。

　　 四. 團隊角色的變化

　　 Fiona說在Claude Code團隊，角色界限已經變得很模糊了。

　　 PM在大量寫代碼，工程師也在做內容和設計的事情，以前涇渭分明的邊界正在消融。

　　 比如以前一個工程師修了個bug，要等內容設計師排期來寫用戶端的文案，排期這個破事大家懂的都懂，結果要么等好幾天，要么趕進度發一個湊合的文案出去。

　　 現在的流程是工程師修完bug，Claude來起草文案初稿，人類來做最終判斷，當天就能發。

　　 跨職能的gap不再是瓶頸了，開始變成了協作者，人類還是做最終決策的那個人，只是不再是寫初稿的那個人了。

　　 然后她說了一個我非常認同的觀點，她現在招人主要看兩種特質。

　　 一種是有產品sense的創意builder，能識別出該做什么，能快速做出原型。

　　 她還特意在描述里強調了一句：

　　 Taste is scarce, typing is not.

　　 品味是稀缺的，打字不是。

　　 另一種是有深厚系統背景的工程師，負責那些「trust but verify」里最需要人的部分，因為subtly wrong is still wrong，微妙的錯誤仍然是錯誤。

　　 她說我根本不在乎你一個小時能寫多少行代碼，我在乎的是你選擇去做什么，以及你怎么知道它是對的。

　　當AI能把執行速度提升10倍的時候，決定性的因素變成了你知不知道應該做什么，以及什么樣的結果叫真正的優秀。

　　這，就是品味。

　　 五. 如何推動團隊變化

　　 Fiona她們團隊有一些有意思的核心原則。

　　 她把團隊原則分成了兩類。左邊灰色是必須做的硬性要求，右邊黑色就是大家自己摸索的空間。

　　 其實本質上，就是給團隊設計了一個harness，核心就是大的方向統一，具體怎么落地各團隊自己定。

　　 Fiona總結了三條她最看重的事情。

　　 1. 保持團隊盡可能扁平，管理者支持各個小組的工作，但保持靈活讓人能流動到工作需要的地方。

　　 2. 如果Claude能做的事情，就讓Claude做，這能讓我們騰出手來做更難的工作。

　　 3. 人不會主動去刪除流程，只會在舊流程上面繼續疊新流程，所以你得主動站出來，指名道姓地說出哪些流程可以走了。

　　 這三條說起來都沒啥特別的，但難在執行，特別是第三條。

　　 Fiona說，她之前在一個團隊里，有一個每周的review會議，一大堆人坐在會議室里，但她發現所有人都在看電腦，只有輪到自己匯報的時候才抬頭說兩句status，說完又低頭繼續看電腦（我相信我們很多時候的會議也都是這樣的）。

　　然后她問了一句，我們為什么還在開這個會。

　　 這時候，所有人才意識到，好像，這個會根本不需要。

　　 于是，從此，這個會就取消了。

　　 這種事太常見了，國內的公司里其實到處都是。

　　 無數的流程和會議，當初設立的時候都有道理，但環境變了、工具變了，它們早就失去了存在的意義，只是因為慣性還在那里被迫轉著。

　　 沒有人覺得它有用。

　　 但，好像很多時候，也沒有人站出來說一句這破逼會太浪費時間了，能不能別開了。

　　 AI在你的組織里介入的越深，你會發現，很多過去的步驟和流程，其實液晶可以自動化了，如果我們不主動去審視，那這些步驟就會一直在那里，最后，變成純粹的形式主義。

　　 最后， Fiona還放了三個她在思考的問題，她沒有答案。

　　 但是很有意思。

　　 第一，你還需要單獨的iOS和Android團隊嗎？因為現在工程師已經可以更靈活地跨平臺工作了。

　　 第二，全自動化的review到底能推到多遠，在「夠快了」和「我們漏掉了什么重要的東西」之間那條線在哪里？

　　 第三，當角色越來越模糊的時候，怎么確保所有角色都對自己的產出有信心？

　　 我覺得她把這三個問題放出來這個動作本身就很有價值。

　　 因為你會發現，即使是Claude Code的親爹團隊，也沒有把所有事情都想明白。他們也在摸索，很多時候，這就不是一個有標準答案的事情。

　　 每一次的大型技術的到來，其實都不只是工具升級，整個組織的運作方式很多時候，都要推倒重來。

　　 所謂的AI原生，AI Native，其實也并不是買幾個Claude會員或者包個API Key啥的，給大家用就算AI轉型了，我一直覺得真正的AI原生組織，從規劃方式到知識管理到評審流程到人才結構，每一層都是重新設計過的。

　　 我們也沒有做到，但是還是在不斷的朝這個方向努力，最近加入的一些新的小伙伴，他們的好奇心和自驅力，且沒有被過去一些傳統且飽受詬病的工作方式所污染，已經感覺讓我看到了一些雛形了。

　　而貫穿所有這些變化的，我覺得其實就是開頭說的那個最樸素的思維習慣。

　　遇到重復的事情，自動化掉。遇到沒用的流程，干掉。遇到不需要人做的判斷，交給AI。

　　一個一個來，不著急，但不能停。

　　 最后，用Fiona的最后一段話作為結尾吧。

　　 Pick your noisiest workflow. Ask if it still earns its place.

　　 找到你最繁瑣的那個工作流，問問它。

　　 是不是還配占著這個位置。

　　以上，既然看到這里了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標?～謝謝你看我的文章，我們，下次再見。

　　>/ 作者：卡茲克

　　>/ 投稿或爆料，請聯系郵箱：wzglyay@virxact.com