三個月，63 萬行程式碼。

這數字說出來可能有人會覺得誇張，但讓我先講清楚這 63 萬行的組成：

  • 約 5-10%：Production Code（對外產品程式碼）
  • 約 90-95%：一次性程式碼、內部數據分析、Daily Routine 的 Batch 程式

（因為這台是新公司的電腦，裡面的資料夾只有 9 月中到職後到現在的產量，所以我還蠻確定是三個月的。）

這篇文章不是要炫耀產量，而是想分享：當程式碼變得「廉價」之後，真正重要的東西是什麼。

我怎麼開始用 Claude Code 的

階段一：AI Coding 審核者

一開始在永聯物流，團隊大多用 Cursor，我是拿 Claude Code 來做 AI Coding 的審核工作。

具體怎麼做？

  1. 翻 Git 看大家寫的怎麼樣：讓 Claude Code 掃過 commit，highlight 可能有問題的地方，我再深入看
  2. 審核 Jira 流程：看 QA 夥伴們是不是按照相關流程作業
  3. 數據分析：用 MCP 和 BigQuery 連接，做運營優化相關的分析

那時候就覺得 Claude Code 非常好用。

階段二：FDE 數據分析（世界級電商物流優化）

後來 FDE 團隊在某個世界級電商做物流優化的時候，大量使用 Claude Code 做數據分析，提供了上百個 index 和 metrics 給團隊做快速驗證。

這個階段讓我意識到：Claude Code 不只是寫程式的工具，它是一個數據探索的加速器。

階段三：跨國團隊管理（創智動能時期）

進到創智動能之後，因為帶的是跨國團隊，又回到 IT 老本行。IT 產業本身數位化程度高，不像傳統產業一開始入門要著重在數位化需求上，有了大量營運數據，用 Claude Code 做團隊管理工作就變得如魚得水。

舉幾個實際例子：

績效審核 當我想要審核某個人的績效時，我會用 Claude Code 先翻出他的程式碼，看他這幾個月寫的東西是不是有所進展。然後請 Claude Code 提供一些 insight，我再用自己的判斷去驗證這些建議是不是對的。

Utilization 計算 想計算團隊的 utilization，我也會用 Claude Code 來做相關計算。

Code Review 每天中間有任何要交付給客戶的程式，我都會用 Claude Code 來做 code review。

生活 當然每天早上的超慢跑+Claude Code 也讓我多出很多時間一邊顧健康一邊做事情。

階段四：AI 部落格博主

當然，身為一個 AI 部落格博主，這三個月我也不斷使用 Claude Code 來幫我做文案發想、收集資料。

我用的是一個「Storm 模式 Agent」——丟大量的 Subagent 出去，讓它們從不同方面、不同角度幫我做審核和收集。最後，我以一個總編輯的角色，去灑上我最專屬的鹽：我的語氣，以及我靈光乍現的一兩句 punchline。

這一百天的時間，我大概寫了 65 篇文章。這就是為什麼這個部落格能維持接近日更，同時又盡可能不失去我的個人風格的主要原因。

63 萬行之後的反思

63 萬行其實可能只是一個開始。

隨著大家在 Agent 使用越來越多，程式碼是真的會越來越廉價。這時候，程式碼的使用方式會分成兩種：

第一種：一次性 / Daily Routine 程式

這是我比較常寫的類型。特點是：

  • 面對內部使用
  • 目標只要確認它正確，而且可管理即可
  • 不需要考慮長期維護

第二種：對外產品程式

這種程式的要求完全不同：

  • 別人要能看得懂
  • 要好維護
  • 要能長期運營

這時候程式碼「誕生」已經不是重點了，重點是你怎麼把 PRD 寫好，以及相關的 QA Test Case 寫好。

我對 Vibe Coding 社群的疑惑

老實說，我現在大大小小的 Vibe Coding 討論聽下來，大家講那麼多東西，但很少人著重於如何把 QA 這件事情做好，我感到非常疑惑。我在 ATPM 不斷強調 QA 的重要性 , 並且其實實務上我花了 70%時間在驗收

原因是：到最後，正如同我們在今年的生成式AI演講聽到李幕約的總結一樣——

人類最後的價值是「甲方的價值」。

什麼是甲方的價值？

  1. 開案：把規格寫好、寫清楚
  2. 驗收：把 AI 產生出來這麼多的東西，進行快速審核

如果你只會讓 AI 生成程式碼，但不會定義規格、不會驗收品質，那你只是在「玩」AI，不是在「用」AI。

在 AI Coding 時代，工程師還有價值嗎？

這是我最常被問到的問題。答案是：有，但價值的定義已經改變了。

以前工程師的價值在於「能寫出程式碼」，現在這個門檻已經被 AI 大幅降低。但工程師的價值並沒有消失，只是轉移到了更高層次：

  • 理解業務需求：AI 不懂你的客戶要什麼
  • 架構決策：選擇什麼技術棧、如何設計系統邊界
  • 品質把關：AI 產出的東西對不對、好不好、能不能用

說白了，工程師從「生產者」變成了「品管者」和「架構師」。

AI Agent 會取代工程師嗎？

短期內不會，但長期來看，某些類型的工程師會被取代。

會被取代的是：

  • 只會按照規格寫 code 的人
  • 不願意學習如何與 AI 協作的人
  • 把「寫程式」當作唯一技能的人

不會被取代的是：

  • 能定義問題的人
  • 能驗收品質的人
  • 能做架構決策的人
  • 能與利害關係人溝通的人

這就是為什麼我一直強調：程式碼本身已經不值錢了，值錢的是你能不能當一個好的「甲方」。

工程師該如何在 AI 時代不被淘汰？

根據我這三個月的實戰經驗，給幾個具體建議：

1. 學會寫好 PRD（產品需求文件）

AI 的產出品質，80% 取決於你給它的 input: PRD。如果你連需求都寫不清楚，AI 再強也幫不了你。

2. 培養驗收能力

當 AI 一天可以產出幾千行程式碼時，你的瓶頸不是產出，而是驗收。學會快速判斷程式碼品質、找出潛在問題，這才是稀缺能力。

3. 擁抱 AI 工具，但不要依賴

把 AI 當作副駕駛，不是自動駕駛。你還是要知道車子往哪開、路況怎麼樣。

4. 往上游走

越靠近業務端、越靠近決策端的工作，越不容易被取代。寫 code 是下游，定義需求是上游。

結語

63 萬行程式碼聽起來很多，但說真的，這個數字會越來越不稀奇。

當程式碼變得廉價，真正稀缺的是：

  • 能定義好問題的人
  • 能驗收好結果的人
  • 能在大量產出中快速判斷品質的人

這就是為什麼我一直強調 ATPM 框架中的 A（Assessment）和 T（Testing）——開案和驗收才是人類最後的核心價值。

Claude Code 已經不只是一個工具了。老實說，它已經很像是我的編程夥伴，或者是我管理工作中一個很好的副手。它就是有一點點呆板，不像以前(5.2以前) 的 ChatGPT 那麼會「Chatty」，但是它真的能做好我賦予它 70% 到 80% 的工作。老實說，就算換一個人來，也不見得那麼靠譜。

超慢跑配 Claude Code：健康與生產力兼得

親愛的 Claude Code，新的一年也請你多多指教。

=====

PS. 照片拍攝於今早香港沙田酒店，我跟 Claude Code 的一個年末總結後的合影

一般外商開完 Annual Review ，不是都要大合照一下 XD