2026年，程序員不寫代碼了，那還能幹什麼？
整理版優先睇
AI寫曬代碼，程序員嘅新工係規劃同審查
呢篇文章係由一班前線程序員同科技公司高層（包括Claude Code創造者同Linear CEO）嘅經驗同觀察整理出嚟。佢哋發現AI已經開始大量取代寫代碼嘅工作——Claude Code創造者過去一個月100%嘅代碼貢獻係由AI寫嘅，微軟CEO都承認AI生成咗20%-30%嘅集成代碼。作者嘅問題係：如果AI寫曬代碼，程序員仲有咩用？
透過Linear CEO嘅文章，作者得出結論：軟件開發嘅重心正由「中間」嘅編碼階段移向「兩端」——開頭嘅規劃同結尾嘅審查。以前程序員嘅主戰場係寫代碼，而家就要花時間諗清楚「要造啲咩」，然後確保AI輸出嘅嘢符合要求。呢個轉變唔係慢慢嚟，而係進行緊。作者自己都話，佢而家打開編輯器90%嘅時間係審查同加註釋，幾乎唔自己打code。
成篇文嘅核心係：程序員要學嘅新技能唔係提示工程，而係上下文工程（Context Engineering），同埋要建立一套完整嘅測試流程（TDD、黑盒、白盒）。未來屬於嗰啲識得規劃、識得管理AI上下文人。佢最後仲畀咗三個即時可行動：花30分鐘做規劃、建立claude.md、嘗試TDD。
- AI寫代碼已成主流，程序員嘅核心價值由寫code轉向規劃意圖嘅清晰度
- 規劃唔係一份文檔，而係多份風險評估、技術規格同約束條件，畀AI容易導航
- 上下文工程比提示工程更重要：claude.md、變更日誌、slash commands、skill.md同MCP組成結構化工作流
- AI寫得越快，審查同測試就要越慢：TDD、黑盒測試、白盒測試三管齊下
- 即時行動：下次寫code前先規劃30分鐘，建立claude.md，試下先寫測試再畀AI實現
中間層消失：寫代碼已唔係主戰場
Claude Code創造者講過，佢過去一個月100%嘅代碼貢獻都係AI寫嘅。微軟CEO都承認AI生成咗兩到三成集成代碼。呢個唔係未來，係而家發生緊嘅事。
過去軟件開發分三階段：開頭（需求規劃）、中間（寫代碼）、結尾（測試審查）。中間最長，但而家畀AI接管咗。
規劃，先係你嘅新主業
既然AI可以寫code，程序員就要諗清楚「要造啲咩」。呢個聽落簡單，但係最難嘅部分——AI唔會估你意圖，佢只會字面解讀你講嘅嘢。
人類同事可以從模糊需求入面「腦補」，但AI唔會。
- 風險評估單獨一份文檔
- 技術規格單獨一份文檔
- 約束條件同權衡單獨一份文檔
- 令AI可以輕鬆喺唔同文檔之間導航
作者而家嘅工作流係花大量時間做呢類規劃，唔係一份文檔，而係多份獨立文檔。佢話：「好的計劃決定好的實現」，用咩AI工具唔重要，規劃先係成敗關鍵。
下一個必學技能：上下文工程
你可能聽過提示工程（Prompt Engineering），但2026年真正重要嘅係上下文工程（Context Engineering）。意思係：要令AI「懂你」，唔係靠一句提示詞，而係靠一整套上下文管理系統。
- 1 claude.md 檔案 —— 項目整體指導
- 2 變更日誌 —— 追蹤所有改動
- 3 可複用嘅斜槓指令（/commands）
- 4 專門嘅技能檔案（skill.md）
- 5 MCP插件擴展能力
上下文工程係要建立一個系統，而唔係一條咒語。
測試，變成質量生命線
既然AI寫code，審查同測試就變得前所未有咁重要。唔審查嘅code等於埋下定時炸彈。作者而家用三種測試方法，全部都係圍繞AI輸出嚟設計。
- 1 測試驅動開發（TDD）：先畀AI寫測試用例，唔寫code，清空上下文再開新視窗。畀AI跑測試（實會失敗），確認測試邏輯冇問題後再畀AI實現功能，但唔準改測試。
- 2 黑盒測試：寫用戶故事，模擬用戶點用系統，用Claude瀏覽器插件逐個場景測試，淨係睇功能啱唔啱。
- 3 白盒測試：睇code。用一個XML文檔記錄詳細測試檢查點，配合自定義斜槓指令一鍵執行，自動生成測試報告。
未來屬於規劃者同審查者
由「中間」移向「兩端」——開頭嘅規劃同結尾嘅審查。掌握呢兩點嘅開發者，會引領未來。舊時代寫code係核心，新時代規劃意圖係核心；舊時代IDE係編碼工具，新時代IDE係代碼審查工具；舊時代測試係最後一步，新時代測試係質量生命線；舊時代學技術棧，新時代學上下文工程。
即刻行動：下次寫code前先花30分鐘做規劃文檔
為你嘅項目創建一個claude.md檔案
嘗試一次TDD：先寫測試，再畀AI實現
時代變咗，我哋嘅工作方式都應該變。如果呢篇文章令你有所啟發，歡迎轉發畀你嘅程序員朋友。
💥 一個令到我成晚瞓唔着嘅真相
前幾日，我睇到一個數據，成個人即刻呆咗。
Claude Code嘅創造者話，過去一個月，佢100%嘅代碼貢獻，都係AI寫嘅。
唔係50%，唔係80%，係100%。
微軟CEO都承認，AI而家已經生成咗微軟20%-30%嘅集成代碼。
你可能會諗：咁程序員仲有咩用？
呢個問題，我都問咗自己好耐。
直到我睇到Linear CEO嘅一篇文章，先至恍然大悟——
程序員冇消失，只係「工作重心」徹底變咗。
🔍 軟件開發嘅「中間層」正在消失
以前，軟件開發分三個階段：
| 開頭 | ||
| 中間 | 最長 | |
| 結尾 |
「中間」以前係程序員嘅主戰場。
但係而家？AI接管咗。
💡 以前我哋開VS Code係為咗寫代碼，而家開佢只係為咗睇AI寫嘅代碼啱唔啱。
呢個唔係誇張。
我自己就係咁——而家打開編輯器，90%嘅時間都係睇code、加註釋，叫AI去實現我標註嘅功能。
真正自己打code嘅時間？幾乎係零。
🎯 規劃，先至係你嘅新「正職」
既然AI識寫代碼，咁我哋應該做啲咩？
答案係：諗清楚「要整啲咩出嚟」。
聽落好簡單，但其實係最難嘅部分。
點解？
因為AI唔會「估」你嘅意圖。
人類同事可以從模糊嘅需求入面「腦補」你想要啲咩。AI唔會。你講咩，佢就做咩——字面意義上嘅。
所以，你嘅規劃一定要夠清晰。
我而家嘅工作流程係咁嘅：
花大量時間做規劃——唔係一份文檔，而係多份 風險評估單獨一份文檔 技術規格單獨一份文檔 約束條件同取捨單獨一份文檔 令到AI可以輕鬆喺唔同文檔之間導航
💡 好嘅計劃決定好嘅實現。用咩AI工具唔重要，規劃先係決定成敗嘅關鍵。
三個月前，我仲唔敢開「跳過權限確認」模式。
而家？計劃做得夠好，我直接叫AI一口氣行曬，全程唔使手動確認。
呢個就係規劃嘅力量。
🧠 下一個必學技能——上下文工程
你可能聽過「提示工程」（Prompt Engineering）。
但2026年，真正重要嘅係上下文工程（Context Engineering）。
咩意思？
簡單講：AI只有喺「明你」嘅時候，先至做到你想要嘅嘢。
而要令AI「明你」，唔係靠一句提示詞，係靠一成套上下文管理系統：
📄 claude.md文件——項目整體指導📝 變更日誌——追蹤所有改動 ⚡ 可重用嘅 slash 指令（/commands） 🔧 專門嘅技能檔案（skill.md） 🔌 MCP插件擴展能力
💡 冇結構化工作流程嘅AI使用，只係浪費AI 90%嘅潛力。
每個項目需要嘅組合都唔同。
你要根據自己嘅項目，搭建專屬嘅上下文環境。
AI嘅表現，取決於你畀佢創造嘅環境。
✅ 測試，唔再係「最後是但行一下」
既然AI喺度寫代碼，審查同測試就變得前所未有咁重要。
唔審查嘅代碼 = 埋落嘅計時炸彈。
我而家用三種測試方法：
1️⃣ 測試驅動開發（TDD）
先叫AI寫測試用例，唔寫任何代碼。
然後清空上下文，開新視窗。
叫AI行測試——梗係會失敗，因為未寫代碼。
確認測試邏輯冇問題之後，再叫AI實現功能，但係唔準改測試。
咁樣AI就有咗明確嘅「通關目標」。
2️⃣ 黑盒測試
我會寫用戶故事，模擬用戶實際點樣用呢個系統。
然後用Claude瀏覽器插件，逐個場景測試。
淨係睇功能啱唔啱，唔睇代碼點寫。
3️⃣ 白盒測試
呢個時候就要睇代碼喇。
我用一個XML文檔，入面有詳細嘅測試檢查點。
配合自訂嘅 slash 指令，一鍵執行，自動生成測試報告。
💡 AI寫得越快，你就越要慢落嚟審查。速度同質量，從來唔會自動兼得。
🌟 未來屬於邊個？
等我哋返去開頭嘅問題：
程序員唔寫代碼，仲可以做啲咩？
答案好清楚：
| 規劃意圖 | |
軟件開發嘅重心，正喺度從「中間」移向「兩端」——
開頭嘅規劃，同尾尾嘅審查。
掌握呢兩點嘅開發者，將會引領未來。
📣 行動呼籲
睇完呢篇文章，你可以即刻做三件事：
下次寫代碼之前，先花30分鐘做規劃文檔 為你嘅項目創建一個 claude.md文件嘗試一次TDD：先寫測試，再叫AI實現
時代變咗，我哋嘅工作方式都應該變。
如果呢篇文章令你有啲啟發，歡迎轉發畀你嘅程序員朋友。
我哋下篇見。 👋
本文核心洞察嚟自Linear CEO關於AI驅動開發嘅深度文章，以及Claude Code創造者嘅實踐分享。
💥 一個讓我徹夜難眠的真相
前幾天，我看到一個數據，整個人都愣住了。
Claude Code的創造者說，過去一個月，他100%的代碼貢獻，都是AI寫的。
不是50%，不是80%，是100%。
微軟CEO也承認，AI現在已經生成了微軟20%-30%的集成代碼。
你可能會想：那程序員還有什麼用？
這個問題，我也問了自己很久。
直到我看到Linear CEO的一篇文章，才恍然大悟——
程序員沒有消失，只是"工作重心"徹底變了。
🔍 軟件開發的"中間層"正在消失
過去，軟件開發分三個階段：
| 開頭 | ||
| 中間 | 最長 | |
| 結尾 |
"中間"曾經是程序員的主戰場。
但現在？AI接管了。
💡 以前我們打開VS Code是為了寫代碼，現在打開它只是為了看AI寫的代碼對不對。
這不是誇張。
我自己就是這樣——現在打開編輯器，90%的時間都在審查、加註釋，讓AI去實現我標註的功能。
真正自己敲代碼的時間？幾乎為零。
🎯 規劃，才是你的新"主業"
既然AI能寫代碼，那我們該幹什麼？
答案是：想清楚"要造什麼"。
這聽起來很簡單，但其實是最難的部分。
為什麼？
因為AI不會"猜"你的意圖。
人類同事可以從模糊的需求裏"腦補"你想要什麼。 AI不會。你說什麼，它就做什麼——字面意義上的。
所以，你的規劃必須足夠清晰。
我現在的工作流是這樣的：
花大量時間做規劃——不是一份文檔，而是多份 風險評估單獨一份文檔 技術規格單獨一份文檔 約束條件和權衡單獨一份文檔 讓AI能輕鬆在不同文檔間導航
💡 好的計劃決定好的實現。用什麼AI工具不重要，規劃才是決定成敗的關鍵。
三個月前，我還不敢開"跳過權限確認"模式。
現在？計劃做得夠好，我直接讓AI一口氣跑完，全程不用手動確認。
這就是規劃的力量。
🧠 下一個必學技能——上下文工程
你可能聽說過"提示工程"（Prompt Engineering）。
但2026年，真正重要的是上下文工程（Context Engineering）。
什麼意思？
簡單說：AI只有在"懂你"的時候，才能做出你想要的東西。
而讓AI"懂你"，不是靠一句提示詞，而是靠一整套上下文管理系統：
📄 claude.md文件——項目整體指導📝 變更日誌——追蹤所有改動 ⚡ 可複用的斜槓命令（/commands） 🔧 專門的技能文件（skill.md） 🔌 MCP插件擴展能力
💡 沒有結構化工作流的AI使用，只是在浪費AI 90%的潛力。
每個項目需要的組合都不一樣。
你要根據自己的項目，搭建專屬的上下文環境。
AI的表現，取決於你給它創造的環境。
✅ 測試，不再是"最後隨便跑一下"
既然AI在寫代碼，審查和測試就變得前所未有地重要。
不審查的代碼 = 埋下的定時炸彈。
我現在用三種測試方法：
1️⃣ 測試驅動開發（TDD）
先讓AI寫測試用例，不寫任何代碼。
然後清空上下文，開新窗口。
讓AI跑測試——當然會失敗，因為還沒寫代碼。
確認測試邏輯沒問題後，再讓AI實現功能，但不許改測試。
這樣AI有了明確的"通關目標"。
2️⃣ 黑盒測試
我會寫用戶故事，模擬用戶實際怎麼用這個系統。
然後用Claude瀏覽器插件，逐個場景測試。
只看功能對不對，不看代碼怎麼寫的。
3️⃣ 白盒測試
這時候要看代碼了。
我用一個XML文檔，裏面有詳細的測試檢查點。
配合自定義斜槓命令，一鍵執行，自動生成測試報告。
💡 AI寫得越快，你就越要慢下來審查。速度和質量，從來不是自動兼得的。
🌟 未來屬於誰？
讓我們回到開頭的問題：
程序員不寫代碼了，還能幹什麼？
答案很清楚：
| 規劃意圖 | |
軟件開發的重心，正在從"中間"移向"兩端"——
開頭的規劃，和結尾的審查。
掌握這兩點的開發者，將引領未來。
📣 行動召喚
看完這篇文章，你可以立刻做三件事：
下次寫代碼前，先花30分鐘做規劃文檔 為你的項目創建一個 claude.md文件嘗試一次TDD：先寫測試，再讓AI實現
時代變了，我們的工作方式也該變了。
如果這篇文章讓你有所啓發，歡迎轉發給你的程序員朋友。
我們下篇見。 👋
本文核心洞察來源於Linear CEO關於AI驅動開發的深度文章，以及Claude Code創造者的實踐分享。