Claude Code氛圍編程經歷： 6周幹了三年的活

6周的Claude code編程經歷：一個程序員的狂喜、崩潰與深夜自拍式頓悟

如果我告訴你，過去一個半月裡，我一個人幹完了原本需要三年才能清完的技術債，你可能會覺得我在吹牛，或者嗑了什麼不得了的東西——但真相是，我既沒嗑藥，也沒變成時間管理大師，我只是擁有了一個叫“Claude Code”的AI編程搭檔，它讓我從“逐行敲代碼的苦力”升級成了“指揮交響樂的指揮家”，雖然我連五線譜都看不懂。

這六週，我彷彿穿越到了攝影剛被髮明的19世紀，畫家們突然發現：天啊，原來不用一筆一劃畫人臉，只要咔嚓一下，照片就出來了，然後你再拿畫筆修修光影、改改背景、加點濾鏡，一幅“藝術作品”就誕生了。編程也一樣，以前我要一行行寫React組件、一個個配TypeScript類型、手動改幾百個文件的樣式，現在？我只需要說一句：“嘿，Claude，把所有內聯樣式換成StyleX，順便讓動畫統一用遊戲那邊的方案。”然後我就去遛狗了，回來一看，代碼已經寫好，測試也跑通了，PR都快準備好了——這感覺，就像你點了個外賣，結果送餐員不僅把飯送來，還順手幫你把廚房收拾了，地板拖了，狗也洗了。

“我幹了這些事，但我其實啥也沒幹”：一個技術債清零者的凡爾賽實錄

在過去六週裡，我完成了以下這些項目——注意，是“我”一個人，不是團隊，不是外包，不是實習生，就是我這個平日還要開會、寫PPT、拉投資的“bizdev”程序員：

最離譜的是，這些都不是我的“本職工作”。我的本職是推動產品、拉合作、搞商業化，但因爲Claude能幫我處理技術瑣事，我就像多了兩個“數字分身”，一個在寫代碼，一個在開會，而我本人……其實在打《Apex英雄》。

“先寫再說，不行就刪”：我的AI實驗哲學

以前我總想着“完美主義”，一個功能沒想清楚，就絕不開始寫代碼。但現在？我學會了“先寫再說，不行就刪”。比如前端測試策略，這玩意兒複雜得像一團毛線，我糾結了兩年都沒動手。現在呢？我讓Claude給每個PR都生成測試，連寫兩週，然後——全刪了。

你可能會問：那不是白乾了？不，一點都不白乾。這就像你讓AI幫你寫10篇情書，然後一篇都不發，但你通過看這些情書，終於搞懂了“怎麼寫情書纔不肉麻”。我通過看AI生成的測試，明白了哪些是冗餘的，哪些是關鍵的，最後自己動手寫了一套簡潔高效的測試框架——而整個過程，只花了我額外十分鐘每天。

還有一次，我在Slack裡跟團隊說：“我想搞個GraphQL+Relay的CRUD抽象，讓非工程師也能搭應用。”大家回覆：“這太複雜了，別搞了。”但我偏要搞，於是讓Claude在後臺“vibe”了半天，生成了一堆代碼，跑起來發現……根本不能用。

但我不後悔。因爲這次“失敗”的實驗讓我看清了技術邊界，也讓我更有底氣說：“這個方向不行，我們換一個。”以前這種探索成本太高，現在？失敗的成本就是一杯咖啡的時間。

“兩個克隆人”的生活：我的VS Code雙開哲學

Anthropic官方推薦用“工作樹”（worktrees）來管理AI編程，但我選擇更粗暴的方式：兩個完全獨立的VS Code實例，兩個不同的主題，兩個不同的配置文件。

爲什麼？因爲這樣我能同時“扮演”兩個角色：一個是“瘋狂實驗者”，讓Claude隨便生成代碼，不管風格、不管規範、不管未來；另一個是“嚴謹審查者”，負責review、重構、合併。

這就像你有兩個大腦：一個負責天馬行空，一個負責冷靜剎車。我經常在一個窗口裡讓AI生成一堆“離譜代碼”，然後在另一個窗口裡慢慢收拾殘局。這種“雙我”模式讓我既能享受AI的創造力，又不至於把生產環境搞成代碼墳場。

而且，當我切換窗口時，視覺上的差異（比如一個深色主題，一個淺色）會提醒我：“你現在是實驗模式”或“你現在是發佈模式”——這比任何文檔都管用。

遊戲設計師的春天：從“畫餅”到“上線”只要兩小時

以前在Puzzmo，做一個新遊戲的流程是這樣的：

1. 遊戲設計師畫原型（用Figma、Unity、甚至紙筆）；2. 團隊開會評審，吵三天；3. 如果通過，工程團隊重寫代碼，接入系統，耗時數週；4. 最後上線，用戶說：“這遊戲不錯，但爲什麼沒保存進度？”——因爲設計師忘了提這需求。

現在？我們建了個“原型倉”，遊戲設計師只要會寫點JS，就能把原型直接跑在puzzmo.com上，後臺自動接入用戶系統、數據埋點、CMS配置——整個過程，兩小時搞定。

我們最近上線的“Missing Link”遊戲就是這麼來的。設計師自己寫的代碼，AI幫忙修了bug，我點了幾個按鈕就發佈了。結果這遊戲火了，用戶天天玩，還問：“能不能加個排行榜？”

問題來了：這代碼是“實驗品”，質量不行，不能長期維護。但用戶愛它，我們能刪嗎？不能。能重寫嗎？太費勁。能就這麼放着？技術債爆炸。

我們陷入了“AI時代的幸福煩惱”：以前是“做不出來”，現在是“做出來太多，管不過來”。

“讓AI先上，我們圍觀”：我的週會新玩法

每週三，我們開GitHub issue triage會，以前是大家討論“這bug怎麼修”“那需求怎麼做”，現在？我直接說：“Claude，你先搞個PR試試。”

然後我們一邊開會，一邊看着AI在後臺生成代碼、跑測試、提PR。小問題，AI一槍斃命；大問題，AI給出草案，我們在此基礎上討論。

這就像打仗，以前是將軍帶着士兵一步步推進，現在是無人機先偵察、開路、甚至開火，將軍再決定是否全面進攻。效率高了不說，團隊士氣也高了——因爲大家不再被瑣事淹沒，而是聚焦在“真正重要”的決策上。

有一次，一個bug卡了三天，各種方案都試過。我讓Claude看了一下，它說：“你們忘了重啓緩存服務。”——全屋寂靜，然後爆笑。AI不僅會寫代碼，還會“讀空氣”。

“我不是AI，我是AI的老闆”：我的權限哲學

我知道很多人擔心AI失控，代碼亂改，生產炸庫。所以我一開始也小心翼翼，每次AI要改文件，都彈窗確認。

結果？一天彈一百個確認框，煩死了。於是我乾脆運行

，也就是“Claude，放飛自我吧！”（我叫它“claude yolo”）。

最壞的情況是什麼？有一次它自作主張提交了代碼，還提了個PR——我把它關了，笑了兩分鐘。還有一次它清了開發數據庫，但我有備份，恢復就行。

我的原則是：AI可以“幹活”，但不能“決策”。PR描述、發佈說明、架構設計，必須人寫。AI生成的代碼，我必須看得懂、改得了、背得起鍋。

這就像你僱了個超級實習生：他能寫90%的代碼，但最後簽字的，還得是你。

“和AI對練”：新人程序員的升級外掛

我對剛入行的程序員說：別怕AI搶你飯碗，把它當“陪練”。你先自己寫個功能，然後再讓AI寫一遍，對比一下。

你會發現：AI可能用了你沒見過的庫，寫了更優雅的類型定義，甚至自動加了測試和文檔。這不是羞恥，這是學習。

以前你得看十篇博客、問三個同事才能學會的東西，現在AI一次給你演示了。你不是被取代了，你是有了個“無限耐心的導師”，而且還不用付工資。

結語：AI沒讓我變強，它讓我變“懶”了

Claude Code沒讓我變成天才程序員，它只是讓我變得“懶”了。我不再爲瑣事操心，不再爲技術債失眠，不再因爲“這功能太麻煩”而放棄想法。

我現在的生活是：想到一個點子，讓AI搞半天，我去看劇；回來修修bug，發個PR，繼續打遊戲。

這世界變化太快，AI已經來了，擋不住，也沒必要擋。你唯一能做的，就是學會和它一起“偷懶”，然後用省下來的時間，去做真正有趣的事——比如，寫一篇用AI生成的博客，再讓AI把它翻譯成帶煙火氣的中文。

Claude Code氛圍編程經歷： 6周幹了三年的活 - 極道