🔧 阿川の電商水電行
AI 能幫你寫程式碼，但把程式碼變成軟體，還是得靠人
AI 能寫程式碼，但它造不出軟體
最近，我收到越來越多的消息：陌生人發來一坨 AI 生成的程式碼，配上一句“能幫我把它變成產品嗎？”。
發信人往往是律師、銷售、醫生，甚至是咖啡店老闆。他們沒有寫過一行生產程式碼，卻用最新的 AI 工具在週末拼出了能跑的 demo。介面亮眼、互動順暢、功能看似齊全——至少在本地機器上點兩下是這樣。然後，他們卡住了。卡在“上線”兩個字上。於是他們開始滿世界找技術合夥人、CTO、外包團隊，願意用股權、現金、分成換取一個承諾：把這個玩具變成生意。
這讓我反覆問自己一個問題—— 如果 AI 真的能取代軟體工程師，為什麼這些人還需要我們？
這種感覺非常有共鳴，是我看到安仔的推文進而寫下這篇，原文是Claude ceo 的一篇介紹bytesauna.com/post/coding…
AI 會“寫程式碼”，但它不會“做軟體”
作者：Matias Heikkilä
你有沒有發現，最近有相當多的人在到處尋找技術合夥人或者 CTO？
反正我吧，收到了多得驚人的這類諮詢；他們的話術大同小異：“嘿，我這兒有個‘憑感覺編程 (Vibe Coding)’搞出來的 App，你願意幫我把它做成‘生產就緒’（也就是能正式上線、穩定運行）的版本嗎？”
我大概能給這些人畫個像。想像一下：他們非常懂自己的業務，但一直以來都缺乏技術能力，沒法把好點子變成現實——他們可能是個法律顧問，或者客戶經理。
這些人幹嘛要找我呢？
我也琢磨了一下，我覺得這釋放了一個重要信號：到底有什麼事是他們靠生成式 AI (GenAI) 沒法獨立完成的？
這不正是現在人人都想搞明白的問題嗎？大家都想知道這些模型的能力邊界。或者，說得再直白點：大家都想知道哪些工作很快要被淘汰了。
我收到這些求助，這個事實本身就說明了“軟體工程”這個行業的一些問題。我的意思是，如果軟體工程真的已經被 AI 自動化了，那根本不會有人來找技術合夥人。
嗯，我想我明白為什麼我們會收到這些請求了。關鍵在於：AI 會寫程式碼，但它不會構建軟體。
這是我在花了大量時間用 AI 輔助編程、並且看了無數別人的演示之後，得出的結論。
圈內有句老話：寫程式碼容易，軟體工程難。
現在看來，說大語言模型 (LLM) 已經能自動化“大量寫程式碼”的工作，這挺公允的。像 GPT-5 這樣的模型（這裡作者指代的是未來更強的模型），在解決那些定義清晰、孤立的小問題時，成功率相當高。
但是，“寫程式碼”本身並不是大多數程式設計師拿工資的真正原因。構建一個能正式上線的 App，那不叫“寫程式碼”，那叫“軟體工程”。
在我看來，當你試圖把一個“演示版 (demo)”變成一個“真正的產品”時，“寫程式碼”就升級成了“軟體工程”——而這，恰恰就是前面提到的那些人帶著他們的專案來找你的時候。
我其實也不太清楚為什麼 AI 至少目前還無法“構建軟體”。
也許這和工作的本質有關。當你以寫軟體為生時，你的核心任務是處理“複雜性”。一個普通的線上產品，它做的可能只是一堆簡單的事情。真正的挑戰是，如何讓“成百上千件”簡單的事情同時不出錯地運行，並且讓整個系統保持“可維護性”。
換到我們今天討論的 AI 話題下，這句話可以這麼說：演示一個“功能”是一回事；而用一種支持“整合、擴展和長期可維護性”的方式來“構建”這個功能，則完全是另一回事，難度天差地別。
當你點開那些人發來的程式碼時，你會發現，所謂的“讓 App 生產就緒”，真正的意思其實是“把這些程式碼全刪了，從頭重寫”。
我覺得，這非常清楚地說明了我們在 AI 發展上目前所處的階段。
下面是我的個人認知和理解
程式碼 ≠ 軟體
寫程式碼從來不是軟體工程裡最難的部分。把一個明確定義的小任務拆成函數、補全語法、跑通單元測試——今天的 AI 已經爐火純青。你給它一個 user story，它能吐出結構清晰、類型標註、測試覆蓋的程式碼，速度比大多數 junior 快十倍。
但軟體不是程式碼的堆疊。
軟體是一座城市：
- 有下水道（錯誤處理、日誌、監控）
- 有供電系統（部署、擴容、降級）
- 有消防通道（安全、合規、審計）
- 有城市規劃（架構、分層、演進路徑）
AI 能給你蓋一棟漂亮的別墅模型，3D 渲染、燈光效果、VR 漫遊一應俱全。
可它不會告訴你：
- 這棟樓的地基能不能扛颱風？
- 消防通道夠不夠寬？
- 十年後要加裝電梯，牆體要不要留洞？
那些找上門的人，拿來的正是這種“模型房”。
運行在 localhost:3000，依賴本地 SQLite，硬編碼 API key，錯誤直接 console.log。它能演示，卻經不起風吹雨打。
複雜度的管理是人的專屬 軟體工程的核心不是“寫”，而是“管”。
管理的是複雜度。
一個生產系統往往由幾百個“簡單”模組組成。單獨看，每個模組都平平無奇：
- 使用者登入
- 訂單支付
- 庫存扣減
- 訊息推送
但要把它們同時跑起來，還要滿足：
- 99.99% 可用性
- 峰值 10 萬 QPS
- 數據最終一致
- 支持多地區部署
- 能平滑升級不掉單
- 出錯能秒級回滾
- 成本控制在預算內
這就是幾百個“簡單”同時成立的約束條件。
AI 能解決其中一個，卻無法同時滿足全部——因為它沒有“整體觀”。
它不知道：
- 這個快取失效策略在雙十一會雪崩
- 這個資料庫索引在數據傾斜時會鎖表
- 這個第三方 SDK 在 iOS 18 上會閃退
這些知識不在訓練數據裡，而在無數次深夜排障的肌肉記憶裡。
AI 是超級實習生，不是建築師
把 AI 想像成一個頂尖的實習生：
- 學得快、碼得快、文檔寫得漂亮
- 但沒有 product sense
- 沒有 cost awareness
- 沒有 risk radar
你讓它實現“使用者上傳頭像”，它會給你一個完美封裝的函數。但它不會問：
圖片要不要壓縮？存儲用 S3 還是 CDN？ 熱點怎麼做？ 违规内容怎麼審核？ GDPR 合規怎麼落地？
這些問題不是“程式碼問題”，而是“系統問題”。
它們分布在產品、運維、安全、財務、法務的交界處。AI 沒有跨部門的上下文，也沒有權衡利弊的動機。
門檻沒有降低，只是前移了
AI 把“寫程式碼”的門檻拉低到幾乎為零，但把“定義問題”的門檻拉高了十倍。
過去，想法 → 程式碼 的鏈路被技術能力卡住。
現在，想法 → demo 只需一個週末。但 demo → 產品 的鏈路，依然被複雜度管理卡住。
那些非技術創始人用 AI 跳過了第一道關卡，卻撞上了第二道更高、更硬的牆。他們需要的不是“會寫程式碼的人”，而是“能把複雜度翻譯成可持續系統的人”。
未來的分水嶺
AI 不會取代軟體工程師，但會重新定義軟體工程師。
未來的頂尖工程師不是寫最多程式碼的人，而是：
- 最懂業務，能把模糊需求翻譯成可驗證的約束
- 最懂系統，能在數百個維度上做最優權衡
- 最懂演進，能設計出“十年不重寫”的架構
AI 會成為他們的超級槓桿：
- 自動生成 boilerplate -
- 智能重構 legacy 程式 -
- 實時建議最佳實踐
但槓桿再長，方向盤還是握在人手裡。
工具在進化，護城河在升級
AI 能寫程式碼，卻造不出軟體。
AI 能寫程式碼，
但軟體是人馴服複雜度的藝術。
這條鴻溝，短期無解。
這條護城河，正在加固。
所以，下次有人拿著 AI demo 找你說“就差上線了”，
你可以微笑點頭：“這屎山，老子改不動，找你的 AI 去呀！”要幹也不是就可以，加錢我重寫！
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
