🔧 阿川の電商水電行
2025 年終醒悟，AI 讓我誤以為自己很強，未來程式設計師的轉型之路
2025 可以說只要是開發者都繞不過 AI，時至今日你說你不用 AI 寫程式我是不信的，但是直到最近我才發現，我似乎已經把 AI 的能力當做自己的能力，這種錯覺體現在，昨天我用 AI 五分鐘做出這下方這個動畫效果：
不知道有沒有人體會到這個動畫裡的梗。。。
自從有了 AI 之後，有問題可以讓 AI 解讀，有需求可以讓 AI 分解，比如我想做上面那個動畫的時候，只需要讓 AI 先根據我的表述給出數學公式，然後根據公式再讓 AI 實現和組合程式碼，而這個過程我只需要點一點運行，預覽下效果符不符合我的要求，然後我就覺得自己強的可怕。
這種錯覺經常讓我陷入以為自己“無所不能”，在提高效率的同時，心態似乎也在慢慢地走偏，比如這段時間以來，我透過 AI 複刻和嘗試了許多特效，雖然偶爾需要我介入修改問題，但是大多數時候都是在 Vibe Coding，而看著這些充滿想像力的炫酷動畫，那種自以為是的心理就會被 AI 無限放大。
但是現在想來，你真的理解過這些動畫嗎？真的有去了解它們的實現原理和實現邏輯嗎？就算事後看過，不是你寫的東西，過後還有印象嗎？也讓我想起了 Anthropic 在 《How AI Is Transforming Work at Anthropic》 文章裡提到過的：
“我以為我喜歡寫程式，其實我只是喜歡程式跑通的結果”。
這也讓我開始懷疑，我究竟是喜歡寫程式，還是只是單純喜歡跑通產品？在這個過程中，AI 帶來的短期能力提升，很容易就讓人對自己的定位產生誤差，實際上這個過程有沒有發現你的能力可能正在倒退？
這種職業認同的危機不只是外部開發者有，Claude 內部開發者也有這個焦慮，所以未來 AI 對於開發者的影響，還可能會帶來新的職業價值觀的重構，所以有人感到迷茫：如果寫程式這個動作本身不再重要，那麼未來作為軟體工程師的身份認同建立在哪裡？
而在這個過程裡，AI 能顯著增加產量並擴展個人可承擔任務的範圍，但同時帶來技能退化風險。
如今 AI 越來越強已經是時代必然的浪潮，而 AI 現在的缺陷也會很快被時代所修復，就像 Google 的 Nested Learning 論文介紹的，現在大模型的問題在於大模型無法在訓練後繼續學習，因為目前的大模型只有極快且短暫的記憶（In-Context Learning）和凍結的長期記憶（Pre-trained Weights），這個問題在於：
當前模型缺乏將“即時對話”轉化為“長期參數”的機制，也就是它們缺乏中間的頻譜：那些應該從短期逐漸變為長期的記憶。
但是這個問題已經被他們透過全新的 HOPE 架構攻克，未來能“吃一堑長一智”的 AI 也許離我們就不遠了，所以編程能力對於程式設計師來說，未來是一個什麼地位？這個職業的核心競爭力又在哪裡？
在開發實現過程中 AI 很強，但是我們需要清晰地知道，AI 的強大的編程能力並不是你的能力，而作為程式設計師，你的競爭力也不再是：
- 熟練掌握某些框架和 API
- 精通某個語言和語法
在這些方面，人是跑不過機器的，就像 《 OpenAI 使用 Codex 在 28 天內構建 Android 版 Sora》 裡介紹的：
在使用 GPT-5.1-Codex 之後，在短短 28 天內，不僅完成了繁重的開發任務，還創造了上線 24 小時生成 100 萬視頻、99.9% 無崩潰率的應用，在這個過程裡 AI 可以 24 小時無間斷編寫代碼和自我修復，28 天透過 50 億 token 完成了正常需要幾個月的產品上線。
所以從這裡可以看到，你如果想和 AI 拼編碼能力肯定是拼不過的，就像 OpenAI 最後總結的：未來的開發工程師的能力不再是打字速度或語法 API 記憶，而是對系統的深刻洞察力。
直到看到 OpenAI 和 Anthropic 等模型公司對於程式設計師未來的思考時，我才明白不能再沉迷於 AI 編程給自己帶來的“成就感”，因為那是 AI 的能力而不是你的，你用 AI 可以做到，那別人用 AI 是不是也能做到，那你的職業競爭力在哪裡？
未來的開發者，強的可能不是程式能力，而是專案管理和 AI 馴化能力。
所以未來程式設計師的職業能力肯定會有所變化，比如 2026 對於開發者來說，短期的價值會體現在如何馴化 AI，因為現在的 AI 還是一批脫韁的野馬，他的保證就像是“事前”的承諾，各種言之鑿鑿讓你相信它：
而事後提起褲子，出問題了它可半點不認，所以如何馴化 AI，同時如何管理和做好大模型善後工程師，這將是程式設計師短期內的職業變化。
而如何馴化 AI，其實也很簡單，那就是不要上來就讓 AI 執行需求，而是給 AI 規劃好需求和規則，把 AI 看作是一個“高能力但缺乏背景的資深新員工”，而你負責架構設計、用戶體驗和最終決策，而 AI 負責寫程式、單元測試和需求落地。
因為 AI 的短板在於目前對於需求的理解還不夠，也不擅長深層的架構權衡（經常為了實現功能而把程式碼寫亂），因為它的 Context 有限，所以經常都會比較片面去理解專案，所以作為程式設計師，你需要做的是：
- 先規劃後程式：先讓 AI 理解系統並編寫“設計文檔”，糾偏後再執行
- 背景信息驅動：透過各種文件文檔為 AI 提供規範和上下文，比如各種 rule 和模組描述
- 增加技能支持 : 透過各種技能描述讓 AI 能力增加，比如 CC 可以透過 skills 加載各種插件來輔助能力提升
舉個例子，比如你要用 Flutter 做一個 Wallet App，而任務是開發一個 TransactionDetail 模組，需求是：
- 必須遵循 Clean Architecture (Domain -> Data -> Presentation)
- 資料敏感，金額精度（Decimal）、哈希脫敏顯示有嚴格規範
- 狀態管理，強制使用
riverpod_generator+freezed
那麼在 Claude Code 場景，首先接下來你需要做的會是：
一、增加 Skill
這裡的核心是教 AI “在這個團隊裡，如何標準化地生產一個 Feature”，例如創建一個 skills/flutter-clean-feature/：
-
SKILL.md--- name: flutter-clean-feature description: 能夠按 Clean Architecture 標準生成全套 Flutter 功能模組 usage: "當用戶想開發新頁面或功能模組時使用" --- # 標準工作流 (SOP) AI 在執行此 Skill 時，必須嚴格遵守以下順序： 1. **Phase 1: 領域建模 (Domain First)** - 讀取 `references/domain_rules.md`。 - 優先定義 Entity 和 Repository 接口。 - *Check*: 所有的金額字段必須使用 `Decimal` 類型，禁止使用 `double`。 2. **Phase 2: 架構腳手架 (Scaffolding)** - 調用 `scripts/scaffold_module.py` 自動生成文件夾和空文件。 - 路徑結構必須是 `lib/features/<name>/{data,domain,presentation}`。 3. **Phase 3: 實現與綁定** - 實現 Repository 時，必須使用 `fpdart` 處理 `Either<Failure, T>`。 - UI 層必須使用 `AsyncValue` 處理加載狀態。 -
references/domain_rules.md(知識庫)- 包含團隊約定的 Clean Architecture 分層圖
- 包含 JSON 解析的通用錯誤處理模版
-
assets/repo_template.dart(模版)- 預置了帶有
Either返回值的 Repository 接口模版
- 預置了帶有
-
scripts/scaffold_module.py(自動化工具)- 一個 Python 腳本，接受模組名參數，自動在
lib/features/下創建標準的文件夾結構和基礎文件（解決 AI 有時候懶得創建文件的毛病）
- 一個 Python 腳本，接受模組名參數，自動在
二、增加上下文信息
核心思想就是告訴 AI “這個專案現有的基礎設施是什麼”，比如專案維護一個 CLAUDE.md，提供專案級上下文：
# CryptoWallet Project Context
## 技術堆疊
- Flutter 3.24
- Riverpod (Annotation mode only)
- Dio (已封裝在 `lib/core/network/dio_client.dart`)
- UI Kit (所有按鈕必須使用 `lib/core/widgets/app_button.dart`)
## 現有能力
- 格式化工具：`lib/core/utils/formatters.dart` (包含 hash 截斷、貨幣格式化)
- 路由：GoRouter，路由定義在 `lib/routes.dart`三、先規劃後程式 (Plan)
可以利用 Claude Code 的互動能力，先加載 Skill 進行規劃，審核無誤後再由 Skill 中的 Script 自動執行，例如：
1. 啟動與規劃
"使用 skill: flutter-clean-feature，我要開發一個 TransactionDetail 模組，輸入是 txHash，需要展示交易金額、時間、發送方和接收方。"
Claude (加載 Skill): 讀取 skills/flutter-clean-feature/SKILL.md... 讀取 CLAUDE.md 獲取專案上下文...
Claude (輸出規劃): 根據 Flutter Clean Feature SOP，我制定了以下計劃：
- Domain: 定義
TransactionEntity(包含Decimal amount) 和ITransactionRepo。 - Scaffold: 運行腳本創建
lib/features/transaction_detail/...目錄。 - Data: 實現 Repo，調用 Context 中提到的
DioClient。 - Presentation: 使用
riverpod_generator創建transactionDetailProvider。
請確認：是否需要支持“交易狀態（成功/失敗）”的枚舉？
2. Review 優化
User: "需要。另外，UI 上金額顯示需要調用
formatters.dart裡的方法，不要自己寫格式化邏輯。"
3. 執行
Claude: 收到。開始執行。
(Claude 內部觸發 Skill 中的 Script) Run script: python skills/flutter-clean-feature/scripts/scaffold_module.py transaction_detail：
Terminal Output:
✅ Created lib/features/transaction_detail/domain
✅ Created lib/features/transaction_detail/data
✅ Created lib/features/transaction_detail/presentation(Claude 繼續編寫程式) Claude 根據 assets/repo_template.dart 填充 transaction_repository.dart，並根據 CLAUDE.md 裡的規則，引入了 dio_client.dart。
······
是不是覺得很繁瑣？是不是覺得一輪整下來我需求都寫完了？但是這就是使用 AI 的趨勢，只有這樣才能控制和管理好 AI 的程式碼，不至於讓 AI 寫出一坨屎山，而隨著你對工程文檔和技能補充的完善，你的開發速度就會越來越快，AI 也能像是你多年的老哥們一樣懂你需求，比如：
CLAUDE.md確保了 AI 不會引入http庫（因為它知道有Dio），也不會手寫醜陋的按鈕（因為它知道有AppButton），它理解了專案的現狀，知道有什麼技能可用，然後透過規劃幫你完成確認，這些寫出來的程式碼和專案才是可持續維護的。
最後，這一年裡我除了用 AI 寫程式之外，也開始嘗試用 AI 去解決和嘗試程式之外的事情，因為 AI 所以我敢於嘗試一些以前不敢接觸的領域，因為過程學習成本太高，而現在 AI 提供了另外一種思路：
我不需要真的懂，我只需要讓 AI 去做就好了，而我只需要提供想法和驗證結果。
2025 即將結束，而 2026 也會如期而至，而 AI 的浪潮從未停歇，願你我都能在新的浪潮下找到自己的位置~
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
