本文章用 Claude 協助產生,當然都是我個人故事
下方數據是來自我開發 5 年的 SideProject - Minecraft 5v5 PvP 專案: CastleWars
AI 輔助開發從根本上改變了軟體工程師的工作模式——從「寫程式的人」變成「指揮開發的人」。
以下用真實數據和開發案例證明這個論點。

2025 年 12 月 26 日,我在一天內完成了 34 個 commits,橫跨 6 個不同專案:
| 專案 | Commits | 完成內容 |
|---|---|---|
| CastleWars | 8 | 賽事團隊頻道建立、等級系統擴展至 1000 級、HUD 修復 |
| k3s-castlewars | 11 | Redis 頻道重構、Loki 外部端點、SSH 安全監控 Dashboard |
| VelocityWhitelist | 7 | 整個插件用 Clean Architecture 完整重寫 |
| cw-cloud | 6 | ItemsAdder CLI 工具、LiteBans 模板化、Plugin Hider 整合 |
| PluginHider | 2 | 資源洩漏與執行緒安全修復 |
一天內同時推進 6 個專案的實際功能交付。
傳統開發模式下,光是 context switch 的成本就讓這件事不可能發生。當 AI 處理實作細節,我只需要專注在「每個專案現在需要什麼」——PM 的思維模式。
CastleWars 的賽事系統包含:
一個完整的後端系統,涉及資料庫設計、API 設計、Discord Bot 整合、遊戲內指令、事件驅動架構。
2025-12-07: feat(tournament): add admin commands, registration toggle, tests
2025-12-08: feat(tournament): add team self-registration, attendance-based winner
2025-12-08: feat(tournament): complete tournament system with ID-based relations
2025-12-08: feat(tournament): implement tournament management system
2025-12-09: feat(tournament): add team modification restriction
2025-12-09: refactor(tournament): organize files by feature
2025-12-10: feat(tournament): add batch team registration and per-match countdown
核心功能在 12/7-12/10 四天內完成,其中 12/8 一天就完成了系統的主體架構。
從 commit message 可以看到,這些是有結構的開發:feature-based 組織、ID-based relations、完整的測試。

CastleWars 需要一套引導新玩家的教學系統:
這涉及遊戲設計、UI/UX 流程、事件系統整合、渲染邏輯。
2025-12-12: feat(tutorial): implement phase 2 with decorator pattern, event listeners, and rewards
2025-12-12: docs(tutorial): add tutorial flow design document
2025-12-12: refactor(tutorial): replace hardcoded messages with i18n keys
2025-12-12: feat(game): add interactive tutorial system with chapter-based progression
2025-12-13: feat(tutorial): add path rendering system and bank withdrawal tutorial
兩天內完成整套教學系統,包含設計文件、架構實作、多語系支援、路徑渲染。
傳統估時這樣的系統需要 4-5 天。
12 月 20 日之前,CastleWars 的伺服器沒有任何現代化基礎設施。沒有 GitOps,沒有監控,沒有集中式日誌。
第一天 (12/20) - 6 commits
第二天 (12/21) - 13 commits
第三天 (12/22) - 9 commits
| 元件 | 狀態 |
|---|---|
| ArgoCD (GitOps) | App-of-Apps 架構運作中 |
| Kustomize | base/overlay 多環境配置完成 |
| Prometheus | 指標收集運作中 |
| Grafana | 視覺化 + 自動 reload |
| Loki | 日誌收集 + 外部推送端點 |
| PushGateway | 遊戲指標推送 |
| Dashboard | UnifiedMetrics + SSH 安全監控 |
傳統估時:2-3 週(含學習曲線、試錯、除錯)。實際花費:3 天。

自架 k3s, grafana, argocd 並且支援多環境且都已經部署,https、cloudflare 全數都包辦
2025-11-02: 6 commits
2025-11-04: 1 commit
2025-11-05: 4 commits
2025-11-14: 3 commits
2025-11-16: 3 commits
2025-11-19: 4 commits
2025-11-20: 5 commits
2025-11-22: 3 commits
2025-11-23: 16 commits ← 開始加速
2025-11-29: 9 commits
整個月:61 commits,日均 2.0 個 commit。
已經比傳統模式快,但還在摸索階段。
2025-12-20: 6 commits (k3s 初始化)
2025-12-21: 19 commits (k3s + godcat-cloud)
2025-12-22: 27 commits (k3s + UnifiedMetrics + KotlinLib)
2025-12-25: 10 commits (CastleWars 功能)
2025-12-26: 34 commits (6 個專案同時推進)
2025-12-28: 15 commits (CastleWars + logging)
整個月:161 commits,日均 5.8 個 commit。
Commit 的質:
| 日期 | 專案數 | 代表性 Commit |
|---|---|---|
| 12/21 | 3 | 「Add prod environment support with multi-environment structure」 |
| 12/22 | 4 | 「feat: restructure to multi-module project with Velocity and Spigot support」 |
| 12/26 | 6 | 「refactor!: rewrite plugin with Clean Architecture and new package structure」 |
| 12/28 | 3 | 「feat: integrate mcwonderland logging library」 |
都是架構級的改動,一天內在多個專案同時發生。
| 指標 | 11 月 | 12 月 | 成長 |
|---|---|---|---|
| 月 commits | 61 | 161 | 2.6x |
| 日均 commits | 2.0 | 5.8 | 2.9x |
| 單日最高 | 16 | 34 | 2.1x |
| 10+ commits 天數 | 1 | 8 | 8x |
| 指標 | 傳統模式 | AI 輔助模式 |
|---|---|---|
| 同時活躍專案 | 1-2 個 | 10+ 個 |
| Context switch 成本 | 高 | 低 |
| 每日可推進專案數 | 1 個 | 3-6 個 |
| 功能 | 傳統估時 | 實際耗時 | 節省 |
|---|---|---|---|
| K8s 完整基礎設施 | 14 天 | 3 天 | 79% |
| Tournament 系統 | 10 天 | 4 天 | 60% |
| 新手教學系統 | 5 天 | 2 天 | 60% |
| VelocityWhitelist 重寫 | 3 天 | 1 天 | 67% |
| logging 函式庫 + CI/CD | 4 天 | 1 天 | 75% |
傳統模式:深度優先,單線程
開發一個功能的流程:理解需求 → 查文件 → 寫 code → 遇到問題 → 查 Stack Overflow → 繼續寫 → Debug → 發現設計有問題 → 重構 → 終於 work。
70% 的時間花在「實作細節」——怎麼呼叫這個 API、這個 library 的用法、這個 bug 怎麼修。大腦的頻寬被細節佔滿,很難同時思考其他專案。
AI 輔助模式:廣度優先,多線程
同樣開發一個功能:定義清楚要什麼 → 讓 AI 實作 → Review 產出 → 調整方向 → 完成。
「實作細節」這一層被 AI 接管。我的大腦只需要處理「這個功能要解決什麼問題」和「AI 的產出是否符合預期」。
釋放出來的認知頻寬,讓我可以在等待 AI 產出的同時思考另一個專案的需求。這就是為什麼 12/26 能同時推進 6 個專案——我不再需要親自處理每一行 code。

同時開 3~5 個 claude code,橫跨多個專案並同時規劃、實作已經成為常態
| 面向 | 傳統工程師 | AI 輔助工程師 |
|---|---|---|
| 核心技能 | 寫 code 的能力 | 定義需求的能力 |
| 瓶頸 | 打字速度、API 熟悉度 | 想清楚要什麼 |
| 時間花在 | 實作細節 | 決策與 Review |
| 更像 | 執行者 | PM + Tech Lead |
| 指標 | 11 月 | 12 月 | 成長 |
|---|---|---|---|
| 月 commits | 61 | 161 | 2.6x |
| 日均 commits | 2.0 | 5.8 | 2.9x |
| 單日最高 | 16 | 34 | 2.1x |
| 10+ commits 天數 | 1 | 8 | 8x |
AI 讓工程師變成 PM——工作內容從「執行」變成「決策」。

最後附上 Claude Code Usage
About Me
我是 Jerry,軟體工程師,在街口支付工作,同時 SideProject 開發 Minecraft 遊戲系統。
文章中提到的 CastleWars 是我正在開發的 Minecraft 競技遊戲伺服器,預計 2026 年初上線。
LinkedIn: https://www.linkedin.com/in/jerry-lin-725a9b227/
GitHub: https://github.com/lulu2002/
CastleWars: https://www.castlewars.net/
分析期間:2025-11 至 2025-12
資料來源:GitHub API (lulu2002 + MCWonderland)