一日Claude 操作員心得
從昨天那篇 https://paulfun.net/wordpress/?p=4363 的Claude Max訂閱衝下去後，我開始思考這麼大的使用量，到底能用在開發的哪邊。
一開始Cli 開始請他做好多個skills，整理組內的PR流程，甚至可以依 執行PR的角度 做Level1, Level2的PR Process，既然要AI開發，那我們就要用AI思維跟流程，再對AI做PR，解決Code Level的問題，而AI + MCP +Skill讓 這整個體驗真的可以在幾句話間無縫感的完成了所有的事情，甚至 其他人類回的PR Comment再請他拉下一起評估要怎麼修改，這個都可以變成是一站式的在Cli完成。不過 這當 中 我發現，人類 可以切入的點是Spec PR，因為我請他做A, 做B，做C，但我”有可能”沒想到D，但這其實是人類 Spec一開始也沒有被Review的問題，這個未來在AI Spec也開始被”外包”的時候 ，我想也一樣是可以有機會AI就自已可以循環解決掉的問題了。總而言之，AI思維下，大家Mindset要開始轉換，我們RD在2028年的時候，可能有一部分都是Claude AI 的操作員了 XD。當然 AI基礎建設跟權限開放管理就也會是合理想象的公司組織的管理議題。
接著我又想到，適逢要績效考核，既然有Jira跟Azure Devops MCP，我請他試著用我的名字跟帳號，整理2025年的整個工作摘要跟統計。同時我趁這個AI研究拉資料的過程中，順便跟他Pair一份 公司部門級別的YearReview Skills
成果如下:
DevOps Commit 貢獻分析
1. XXXX-Fxxm 專案
1.1 XXXX-Api (後端 API 開發)
| 月份 | Commits 數量 | 新增檔案 | 編輯檔案 | 刪除檔案 |
|---|---|---|---|---|
| 2025-01 | 8 | 0 | 111 | 0 |
| 2025-02 | 40 | 29 | 667 | 0 |
| 2025-03 | 120 | 134 | 834 | 4 |
| 2025-04 | 100 | 122 | 953 | 0 |
| 2025-05 | 51 | 44 | 602 | 0 |
| 2025-06 | 181 | 109 | 1,154 | 11 |
| 2025-08 | 16 | 0 | 27 | 0 |
| 2025-09 | 111 | 247 | 631 | 4 |
| 2025-10 | 162 | 159 | 864 | 0 |
| 2025-11 | 211 | 160 | 1,477 | 0 |
| 2025-12 | 200+ | 300 | 836 | 0 |
| 年度總計 | 1,200+ | 1,304+ | 8,156+ | 19 |
分析說明:
- 全年度在 BackendApi 專案貢獻超過 1,200 次 commits
- 編輯檔案變更超過 8,000 次，顯示大量的功能開發與維護工作
- 3月、6月、10月、11月、12月為高產出月份，顯示專案交付週期的節奏
- 持續穩定的貢獻，無明顯的工作中斷期
1.2 XXXX-WebAdmin (後台管理系統)
| 月份 | Commits 數量 | 新增檔案 | 編輯檔案 | 刪除檔案 |
|---|---|---|---|---|
| 2025-09 | 35 | 212 | 315 | 18 |
| 2025-10 | 23 | 24 | 58 | 2 |
| 2025-11 | 29 | 15 | 73 | 3 |
| 2025-12 | 13 | 10 | 23 | 0 |
| 總計 | 100 | 261 | 469 | 23 |
分析說明:
- 9月份開始投入 WebAdmin 開發，顯示新功能模組的開發
- 新增檔案數量較多，表示建立新的功能架構
- ….略
Jira的部分也示意一下
整份報告洋洋灑灑8大區塊就不說了，但確實都可以請AI做到位了。他還同時針對重要的git message去做分類分析，太Rough的請他要統一分類到別的地方，JIRA也一樣。看到這邊，我想雖然這個commit或單子的數量不一定能代表一個人完整的工作表現，但是卻是真實數據對齊的一種方式。人在哪裡，管理就要到哪裡 ~
第3的部分，就是AI我昨天比諭是FSD自動架駛，但我現在更抽象的想象是我們執行了”外包”。而且這個外包感受跟之前常聽到的，美國工程師用多少美元，把自己年薪20w美元的工作用3w美元把開發外包到印度去，然自己只要開會跟在夏威夷度假跟遠端確認 工作結果的故事一樣。現在我們不就是站在這個風口浪尖嗎？現在來說就是100美元，就可以外包掉 50%以上的日常工作，那為什麼人們會覺得這個100美元花不起？我現在想象，只要公司的環境/資安允許，那麼這些都將會讓 人們開始變成價值提供者，專業以人分工會變的極端不重要，昨天也講到 前端後端都會變成產品端，產品端，銷售 端，可能會變成直面市場挑戰，這個是可以預見的改變，所以我也試著在新專案中，準備開始訂好Spec-Kit的Skills，接著直接請他開始 針對舊專案好的部分，我想保留的部分，簡單陳述一下，需要測試，要有目錄結構，專案名稱要怎麼命名等，一行的prompt在彈指之間，他就幫我創立好了一個完整的專案目錄架構，還幫你編譯檢查過，新專案一鍵生成如下圖。
最後，講一個有趣的撞牆後才慢慢打破的想法。我自已是IDE時代出身的，所以對於 Visual Studio跟Rider還有 後來出的Cursor其實都是有其熟悉性(慣性)的，後來雖然對不同的技術科目，有開始學習像是VIM，Bash, Docker , Linux等Command line，但往往 在不同的Context 下我會需要記憶跟切換 context反而造成”不舒適”區，而Cli在我發現他”仍然”可以用Bash跟Vim的時候，一開始覺得是狂喜。過不久就發現，Cli上的Bash跟Vim雖然是讓你可以操作作業系統跟編輯長prompt更方便 ，但我發現，在Cli上，你其實更要直覺得直接請他做什麼事，而一直在怎麼做上面，去做思考成本。舉例來說，一開始我們啟動Cli的時候，通常你都會在”家目錄”(~/{user}/)。你的DEV目錄可能在~/DEV/xxxxxx-API，下面可能有好多個repo，往往 在這個只有一兩層的時候，我慣性的會想用 cli去切cd跟切 目錄，而在bash上，切換這個對我們的直覺來說，是快的，而且目錄名稱太長的話，也可以用上下切換跟tab來提示，這麼自然不過的場景，在Claude Cli的Bash(!)模式，竟然沒有，雖然不確定是刻意拿掉還是怎樣，導致我在前期時，常常在prompt模式下，打 ls，然後我又想下 bash，所以又切去bash想要切到開發目錄做事，這種日常的切換 超級鎖碎，後來想打破這個慣性，我突然發現，其實我們只要跟他好好講，拋棄那些什麼os/bash/目錄結構的記憶框架。就跟他說 切換到 xxx yyy api的專案，他就會去幫你達成。這個小小的慣性突破，雖然小，但總覺得對我來說也是一個有趣的發現。
就這樣，一天過了，token還用不完，一樣的有新的idea跟感受的話，再分享吧~或許哪一天這些過程也變的不重要了，就跟水龍頭一樣來的自然~那時我就真的是個操作員了