AI全棧開發的實踐心得流傳：寫程式這件事，技能重心正在搬家

2026年9月2日，掘金平臺上一位署名「前端小張同學」的開發者，分享了自己用AI從零搭建一套「數字分身系統」的完整思路。文章原本只是個人經驗整理，卻在開發者社羣裡被反覆轉發，原因是它碰到了一個正在發生的轉變：AI在程式開發裡的位置，已經從「幫你改bug的助手」移到了「從零到一搭系統的隊友」。

這件事聽起來技術味很重，但它影響的是很日常的東西，也就是寫程式的人在職場上靠什麼喫飯。

先看這篇文章實際主張了什麼

作者的流程可以整理成一條清楚的線：確認系統方向、與AI多輪討論功能、輸出需求文件、生成設計稿、做架構設計、最後才是讓AI寫程式。

用一個貼近生活的比喻，這比較像裝修房子。過去工程師是泥水師傅，一磚一瓦自己砌；現在AI成了施工隊，力氣大、速度快，但你不給圖紙、不劃水平線，它會把廚房瓷磚貼到客廳去。作者整篇的核心主張其實就一句話：施工隊越強，畫圖的人越關鍵。

值得注意的是他把「產品思維」這一關也交給了AI。他坦言多數工程師寫程式能力很強，但不知道系統該長什麼樣，於是讓AI扮演產品經理，多輪對話之後，腦子裡才慢慢有畫面。這個細節值得停下來看：AI在這裡承擔的已經是需求釐清的角色，也就是工程師過去最常被詬病「只會接單不問為什麼」的那一環。

規範為什麼成了新的瓶頸

文章裡最有實務價值的一段，是作者對AI寫碼行為的觀察。他發現AI不會主動管理工具類，不會在乎方法有沒有被封裝復用，遇到需要抽象的地方，它的傾向是直接再造一個輪子。前端程式碼如果你不規定要放在哪個目錄、遵守什麼分層，它會一路寫下去，寫到最後連你自己都看不懂。

這不是AI笨，是它的目標函數和你不同。它的任務是把眼前這一個功能完成，你的任務是讓整個系統三年後還有人敢動。就像請了一位記憶力極好但只簽短期約的員工，每件事都做得又快又像樣，卻沒有義務替整間公司著想。

因此作者的解法是建立所謂的skill規範，一套前端、一套後端，把目錄結構、介面契約、品質下限寫成AI必須遵守的文件。這件事的意義在於，工程師的產出物正在從「程式碼」變成「規範加審查」。程式碼變便宜了，決定程式碼長什麼樣子的規則變貴了。

這與我們先前分析的GPT-6 Astra的AGI宣言該怎麼檢驗是同一枚硬幣的兩面：模型能力敘事越強，越需要回到實際工作流程裡檢驗它到底改變了什麼環節、沒改變什麼環節。

簡單系統與複雜系統的分界線

作者把系統分成兩種。簡單系統要考慮的是資料庫設計、是否需要Redis、MQ、搜尋引擎等中介軟體、前後端的工程化體系、鑑權方式、分頁實作。複雜系統則涉及支付回呼時伺服器宕機怎麼處理、訊息佇列重複消費、快取一致性這類分散式難題。

他也很誠實：自己還不具備獨立架構企業級複雜系統的能力。這句坦白反而是整篇文章可信的地方。它劃出了目前AI輔助開發的真實邊界，也就是AI能大幅壓縮「把想清楚的東西做出來」的成本，但「想清楚」本身，特別是牽涉交易、金流、容錯的判斷，仍然高度依賴人的經驗。

換句話說，AI全棧開發讓一人做出一個能用的產品變得前所未有的容易，但一人做出一個不會出事的系統，難度沒有下降多少。這條線對新創團隊和企業內部工具開發尤其關鍵：前者可以放心衝，後者的每一步都要留人把關。

對一般開發者的「所以呢」

回到讀者的處境。如果你是前端或後端工程師，這篇文章值得當作流程參考，而不是工具推薦。具體可以帶走幾個調整。

第一，練習把需求講清楚。與AI多輪對話、逼自己輸出需求文件的過程，本質上是在訓練過去只有產品經理和架構師才需要的能力，而這種能力在AI時代是每一個寫程式的人的輸入介面。

第二，把維護成本放進判斷。AI生成的程式碼交付速度很快，但沒有規範約束的產出，後期維護成本會以另一種形式討回來。替團隊寫好一份skill規範，未來可能比多寫幾個功能更有價值。

第三，誠實面對自己的邊界。作者敢說自己還駕馭不了複雜系統，這種自我評估能力，在人人都能「看起來很會」的環境裡，反而成了稀缺的專業素養。

手寫能力下降，是危險還是轉型

作者在開頭自陳，天天用AI寫程式之後，自己手寫程式碼的能力下降很多。這句話在社羣裡引起的討論，某種程度上比文章本身的技術內容更熱。

歷史上這種情況出現過。計算機普及之後，心算能力普遍下降，但沒有人因此主張回到紙筆記帳；關鍵在於下降的是哪一種能力。如果下降的是語法記憶、樣板程式碼的書寫速度，這種能力像注音輸入取代了手寫字的流利度，社會成本低。但如果下降的是讀懂程式碼、判斷架構優劣的能力，那就像飛行員過度依賴自動駕駛之後失去手動降落的能力，平時看不出來，出事的那一刻才會知道代價。

目前多數開發者的實際狀況介於兩者之間。閱讀和審查能力因為天天在看AI產出而維持甚至提升，從零敲出完整功能的能力在退化。真正的功課，是確保自己始終保有判斷力，即便生產力已經外包。

這也是為什麼這篇樸實的個人實踐文章值得被認真對待。它沒有宣告什麼時代來臨，只是把一個普通開發者的新工作流攤開來：方向自己定，產品靠對話，架構自己扛，程式碼交出去，規範寫在前面。這套流程會不會成為主流，值得每一個寫程式的人在下一個專案裡自己驗證一次。