小編精選 - 技術文章翻譯 · 05月28日

零基礎用 AI 寫 App？兄弟😂 醒醒吧，那只是一個玩具罷了！

零基礎用 AI 寫 App？兄弟 😂 醒醒吧，那只是個玩具罷了！

> **本文重點：**

AI 會取代一部分初中階程式設計師，但取代不了真正有實力的工程師

零基礎用 AI 寫 App 只是玩具，真正的程式設計複雜度遠超想像

程式設計師要從「寫程式的人」升級為「駕馭 AI 的架構師」

附具體學習路線和我的 IM 專案真實案例

一、一個反直覺的現象

最近滑社群媒體，你一定看過這種型態的貼文或留言：

「不會寫程式，用 AI 一天做了一個 XX App，震驚！」

留言區一片「學程式沒用了」「會用 AI 就行了」「未來程式設計師要被淘汰了」。

2025 年初，OpenAI 的共同創辦人 Andrej Karpathy 提出了一個概念叫 「Vibe Coding」——不寫程式，靠感覺和自然語言指揮 AI 寫。這個詞迅速紅遍全網，成了 AI 程式設計的代名詞。不過連他自己後來都承認，AI 產生的程式碼「can still be gross」——還是可能很爛。

聽起來很美好，對吧？

但我想說一個可能讓你不太舒服的觀點：AI 越強，越需要扎實的技術基礎。不是不重要了，是比以往任何時候都重要！

AI 只是把瓶頸從「寫程式」轉移到了「審程式」，從「執行」轉移到了「決策」。以前你需要會寫，現在你需要會駕馭。而駕馭的前提，是你真的懂。

二、「AI 會取代程式設計師」——這句話對了一半

先說一個很多人不愛聽的真相：「AI 會取代程式設計師」這句話太籠統了。 準確地說是——AI 會取代一部分初中階程式設計師，但取代不了真正有實力的工程師。

什麼意思？

我們先看看 AI 現在能做什麼。一個 CRUD API、一個新增刪除修改查詢頁面、一個簡單的資料展示清單——這些過去是初級程式設計師每天在做的事。寫一個 Controller、配一個 MyBatis 的 XML、查一個資料庫、拼一個前端列表頁。這種工作，AI 現在做得比初級程式設計師更快、更準，還不用下班。

你說，如果一個程式設計師的核心價值就是「把需求翻譯成程式碼」，那他跟 AI 有什麼差別？差別只有一個——AI 更快，不要薪水，不請假。

所以這部分職位，確實危險了。

但你要是說「AI 要取代所有程式設計師」，那就是危言聳聽了。因為程式設計這件事，遠遠不止「把需求翻譯成程式碼」這麼簡單。

關於這個問題，業界其實早有共識（相關討論）：

「Strong engineers are not valuable because they can type syntax. They are valuable because they understand problems, constraints, and trade-offs.」

翻譯過來就是：強工程師的價值不在於會敲程式碼，而在於理解問題、約束和取捨。

這些東西，AI 目前做不到。

所以結論很清楚了：

只會寫 CRUD 的初級程式設計師——危險，AI 能幹你的活
只會照搬框架模板的中階程式設計師——危險，AI 也能幹你的活
能做架構決策、能權衡技術選型、能排查疑難雜症的高階工程師——安全，AI 是你的加速器

AI 不會取代程式設計師這個行業，但會重新定義「什麼樣的程式設計師有價值」。 而這個「有價值」的標準，比以前更高了。

三、AI 擅長 0→1，但 1→100 還得靠你

AI 確實厲害。給它一個 Prompt，10 分鐘它能搭出一個看起來像模像樣的應用。前端介面有了，後端 API 有了，資料能存能取，點兩下還真跑得起來。

但這只是0→1。

從「能跑的原型」到「能上線的真實產品」，中間的距離，比大多數人想像的要遠得多。

AI 做出來的東西，也許能跑，但「也許並不是你想要的」。它的理解跟你的意圖之間，永遠存在偏差——理解偏差、設計偏差、細節偏差。你以為它懂了，它其實只懂了個大概。

到了 1→100 的階段：訊息丟了怎麼補？並發上來怎麼扛？資料一致性怎麼保證？跨伺服器怎麼路由？

你可能會說：「這些問題我告訴 AI，它也能處理啊。」

沒錯。但前提是——你得先知道有這些問題。

我拿一個具體的場景說明。假設你讓 AI 幫你寫一個「使用者下單」的功能。如果你只是簡單地說「幫我寫一個下單 API」，AI 很快給你產生程式碼——接收請求、檢查庫存、扣減庫存、建立訂單、回傳結果。看起來沒毛病，跑起來也沒問題。

但如果你懂行，你知道下單遠不止這些：

兩個人同時下單，庫存只有一件，會不會超賣？——並發問題
扣了庫存但訂單建立失敗了，庫存回不回滾？——交易一致性問題
訂單建立成功了但訊息通知發送失敗了怎麼辦？——分散式交易問題
10000 個人同時搶購，資料庫扛得住嗎？——效能問題
如果有惡意使用者用腳本刷單呢？——安全問題

你知道這些問題的存在，你就能跟 AI 說：「幫我寫下單 API，需要處理並發超賣、保證交易一致性、考慮分散式交易、做限流防刷。」AI 收到這個指令，大概率能給你一個不錯的方案。

但如果你不知道「並發超賣」這個概念的存在呢？ 如果你從來沒聽過「分散式交易」這個詞呢？你根本不會想到要跟 AI 提這些要求。AI 也不會主動提醒你——因為它不知道你不知道什麼。

這就是問題的核心：不是 AI 不會，而是你不知道該讓它做什麼。

AI 的能力沒有上限，但你的知識儲備決定了你能從 AI 那裡拿到什麼品質的輸出。你的 Prompt 寫得越精準、考慮得越全面，AI 給你的結果就越好。而精準的 Prompt，來自扎實的技術功底。

所以真正可怕的不是「AI 寫錯了」，而是——你連 AI 漏了什麼都看不出來，因為你自己就不知道那裡應該有什麼。

四、「我零基礎用 AI 寫了 3 個 App」——我想說兄弟 😂 別鬧了

現在社群媒體上到處是這種標題：「不會寫程式，用 AI 一天做了一個 XX」。

我直說：那只是玩具。

為什麼？看下面這張圖就明白了。零基礎的人只看到水面上那 10%——一個能跑的介面、幾個功能按鈕。而水面下真正的程式設計複雜度——並發安全、資料一致性、效能擴展、架構決策——他們根本看不到。

程式設計複雜度冰山模型

先說清楚，AI 對一般人確實很有用。幫你整理 Excel 資料、生成簡報、寫工作總結、處理圖片、翻譯文件、甚至做個簡單的網頁展示——這些場景 AI 表現得非常好。AI 對一般人的意義就是提升工作效率，這點無庸置疑。

但「提升工作效率」和「開發一個完整的商業化 App」，中間的差距是數量級的。

Stack Overflow 的官方部落格講過一個真實故事。他們的一位非技術編輯，用 Bolt 做了一款 App。表面上 10 分鐘搭出來了，介面還挺好看。但交給工程師一看——安全漏洞一堆、資料沒有任何保護、程式碼混亂到無法維護、沒有單元測試，甚至 Redis 是什麼都不知道就已經在用了。

66% 的開發者在使用 AI 工具時都遭遇過所謂的「生產力稅」——AI 產生的程式碼「幾乎對但又不完全對」，你反而要花更多時間去修它。

你零基礎用 AI 做的那個 App，上線試試？使用者資料要不要保護？並發扛不扛得住？支付接進去安不安全？做出來和能用是兩回事，能用和能上線又是兩回事。

所以別自嗨了。零基礎用 AI 做 App，發個朋友圈炫耀一下沒問題，但別真的以為自己會開發了。 因為前面說過的那些坑——並發安全、資料一致性、效能擴展、例外處理——你一個都不知道，AI 也不會替你操心。

外行人覺得「AI 程式設計很簡單」，因為他們根本看不到水面下的冰山。

五、真實案例：一個 IM 系統到底有多複雜

說這些可能還是太抽象。我拿我自己做的專案舉例。

我花了兩年業餘時間，一個人做了一個即時通訊系統——XZLL IM。Java 微服務後端 + Flutter 客戶端，從零開始。

很多人覺得「做個聊天軟體能有多難？不就是一個發送按鈕一個訊息列表嗎？」

來，我列一下一個 IM 系統真正要解決的問題：

1. 訊息可靠性

你發出的訊息，對方一定要收到。不能丟，不能重複。聽起來簡單？這需要你理解 TCP 的三向交握、ACK 確認機制、訊息去重策略。訊息發出去但網路斷了怎麼辦？重試幾次？重試期間對方收到了怎麼辦？冪等性怎麼保證？

如果這些問題你回答不了，那你用 AI 寫的聊天功能，大概率在弱網環境下就會出 bug——而你連為什麼出 bug 都不知道。

2. 高並發長連線

幾萬人同時在線，每人一個 WebSocket 長連線。作業系統告訴你：一個行程能開的檔案描述元是有限的。怎麼突破？需要理解 Netty 的 Reactor 執行緒模型，理解 Boss Group 和 Worker Group 怎麼分工，理解 Epoll 和 NIO 的差別。

AI 可以幫你產生 Netty 的啟動程式碼，但它不會告訴你「你的執行緒模型在高並發下可能會阻塞」。只有你自己懂，才能提前避開。

3. 資料儲存分層

使用者和好友關係存 MySQL，聊天記錄存 MongoDB，快取和未讀計數存 Redis，訊息搜尋用 Elasticsearch。為什麼不用一個資料庫搞定？因為每種資料庫的特性和適用場景完全不同——這需要對儲存引擎、索引原理、CAP 理論有理解。

這個技術選型決策，AI 做不了。它不了解你的讀寫比例、資料量級、查詢模式。選型是架構師的事，不是 AI 的事。

4. 離線訊息

使用者離線了，發給他的訊息怎麼辦？存哪？上線後怎麼拉取？拉取的時候怎麼保證不漏不重？我用 Redis 的 ZSet 按時間戳儲存離線訊息，上線後按時間範圍拉取——這個設計決策，AI 能幫你想出來嗎？也許能，但前提是你得知道 ZSet 是什麼、為什麼用它、它有什麼限制。

5. 跨伺服器訊息路由

使用者 A 連在伺服器 131 上，使用者 B 連在伺服器 132 上，A 給 B 發訊息怎麼送達？需要一個 gRPC 的跨伺服器轉發機制。如果 B 同時登入了手機和電腦呢？多端同步怎麼辦？這些架構決策，不是 AI 幫你寫幾行程式碼就能解決的。

6. 群訊息廣播

一個群 500 人，一條訊息要推給 500 個裝置。500 個人裡有的在線有的離線，有的在一台伺服器上有的分散在十台伺服器上。不能一個人一個人地推，需要透過 RocketMQ 做訊息廣播，需要設計訊息扇出策略——這背後是對訊息佇列、發布/訂閱模型的理解。

這還只是冰山一角。 還有 Protobuf 協議設計、JWT 驗證、API Gateway 路由、MongoDB 到 Elasticsearch 的資料同步、音視訊通話的訊號設計……

你說，這些是 AI 能幫你從 0→1 搞出來的嗎？

也許它能幫你寫出一些框架程式碼、產生一些 CRUD API。但每一個環節的設計決策、效能權衡、例外處理，都需要人有足夠的知識儲備。我在開發過程中也大量使用了 AI 工具（Claude Code、Cursor 等）來加速編碼，但核心的架構設計、訊息流轉路徑、協議定義，全部基於我對底層技術的理解。

AI 幫我寫得更快，但不會幫我設計得更好。 設計，只能靠我自己。

六、程式設計師的角色轉變：從「開發者」到「架構師」

所以結論來了：AI 時代程式設計師不是要被淘汰，而是要升級。

什麼意思？不是所有人都會失業，但所有人的角色都會改變。以前的程式設計師和未來的程式設計師，做的是不一樣的事。

來看看前後的對比：

以前一個程式設計師的工作流：需求 → 設計 → 編碼 → 測試 → 部署，大部分時間花在「編碼」上。

現在呢？需求 → 架構設計 → 指揮 AI 編碼 → 審查驗證 → 調優。

編碼的部分被 AI 加速了，但你的核心能力變成了三樣東西：

1. 架構能力——系統怎麼拆？模組怎麼分？技術怎麼選？用 MySQL 還是 MongoDB？用 HTTP 還是 gRPC？訊息同步用推模式還是拉模式？這些決策 AI 做不了，因為它不理解你的業務、你的使用者量、你的約束條件。

2. 驗證能力——AI 寫的對不對？有沒有安全隱患？效能能不能扛住？並發下會不會出問題？程式碼結構合不合理？你如果連 TCP 三向交握都說不清楚，怎麼驗證 AI 給你的網路方案？

3. 駕馭能力——怎麼給 AI 精確的指令？怎麼把一個複雜任務拆解成 AI 能處理的小任務？怎麼在 AI 跑偏時及時糾正？這就像一個導演指揮演員——你不懂表演，你就導不了戲。

Google 的資深工程師 Addy Osmani說過一句話：「Vibe Coding 不等於 AI 輔助工程。前者是盲信 AI 的輸出，後者是駕馭 AI 的能力。」

而這三種能力——架構能力、驗證能力、駕馭能力——全部建立在扎實的技術基礎之上。 沒有基礎，你就是個只會說「幫我寫個 App」的外行，而不是能駕馭 AI 的工程師。

打個比方：以前你是駕駛員，自己開車。現在你是車隊策略師，AI 是你的車手。車手負責執行，但你得比車手更懂賽道——才能制定正確的策略，才能在車手跑偏的時候把他拉回來。

你不需要親手換每一個檔，但你必須知道什麼時候該換檔。

七、哪些程式設計師會被淘汰？哪些不會？

說到這裡，我想更直白地回答一個很多人關心的問題：到底誰會被淘汰？

畫了一張分界圖，一目了然：

先說會被淘汰的

1. 只會 CRUD 的「增刪改查工程師」

如果你的日常工作就是：接到需求 → 打開 IDE → 寫一個 Controller → 寫一個 Service → 寫一個 Mapper → 測試通過 → 提交程式碼。這種工作模式，AI 現在就能取代 80%。不是未來，是現在。

2. 不理解原理只會用框架的「調參俠」

會用 Spring Boot，但不知道 Spring 的 IoC 容器是怎麼工作的；會用 Redis，但說不清 Redis 為什麼快、什麼場景該用什麼資料結構；會用 MQ，但不知道訊息丟了怎麼辦。這種人，AI 產生的程式碼跟他寫的差不多，但 AI 快 100 倍。

3. 缺乏系統思維的「單點程式設計師」

只會寫自己那一塊程式碼，不理解上下游，不理解整個系統怎麼運轉。出了問題只能靠 log 猜，猜不到就找大佬。這種人，AI 也取代不了大佬，但能取代他。

再說不會被淘汰的

1. 能做架構決策的人

知道一個系統該怎麼拆、技術該怎麼做選型、效能瓶頸在哪、怎麼水平擴展。這種能力不是 AI 能給的——它需要對業務的深刻理解和對技術的全局掌控。

2. 能排查疑難雜症的人

線上 CPU 飆到 100% 怎麼排查？訊息佇列積壓了 100 萬條訊息怎麼辦？資料庫死鎖了怎麼分析？這些問題，AI 給你一段排查指令容易，但判斷問題出在哪、該怎麼做決策，需要經驗和對底層原理的理解。

3. 能駕馭 AI 的人

知道怎麼把一個複雜需求拆解成 AI 能理解的任務，知道 AI 產生的程式碼哪裡可能有坑，知道什麼時候該讓 AI 幹活、什麼時候該自己動手。這種人，AI 是他的倍增器。

看清這個分界線，就知道自己該往哪個方向努力了。

八、那到底該怎麼做？程式設計師的學習路線

不是讓你不用 AI 工具，而是：先用基礎武裝自己，再用 AI 放大能力。

那具體該學什麼？我結合自己做 IM 專案的經歷，按優先順序列一條路線：

我畫了一個學習路線金字塔：

第一層：計算機基礎（最重要，別跳過）

這是所有程式能力的根基。沒有這一層，上面蓋什麼都是空中樓閣。

網路原理（TCP/IP、HTTP、WebSocket）——我設計 IM 的訊息傳輸方案時，如果不懂 TCP 的可靠性機制和 WebSocket 的全雙工通訊，根本無法做出合理的選擇。AI 可以幫你寫 Netty 程式碼，但它不會告訴你「這個場景應該用 WebSocket 而不是 HTTP 輪詢」。學了網路原理，你才能判斷 AI 給你的網路方案對不對。

作業系統（行程/執行緒、記憶體管理、IO 模型、Epoll）——高並發程式的本質是在跟作業系統打交道。你不懂 IO 多路複用，就理解不了 Netty 為什麼快；不懂執行緒排程，就不知道執行緒池參數該怎麼配；不懂記憶體模型，就排查不了記憶體洩漏。這些是 AI 寫程式時的「隱形假設」，你不懂就發現不了。

資料結構與演算法——不是讓你去刷 LeetCode 應付面試，而是真正理解。知道 B+ 樹怎麼工作的，才能理解 MySQL 索引為什麼高效；知道雜湊表的衝突處理，才能理解 Redis 的漸進式 Rehash；知道圖的遍歷演算法，才能設計訊息路由策略。AI 能幫你實作演算法，但只有你理解了，才知道該讓 AI 實作哪個演算法。

第二層：資料庫與儲存（吃飯的傢伙）

幾乎所有程式都繞不開資料儲存。

關聯式資料庫（索引原理、交易 ACID、鎖機制、隔離等級、慢查詢優化）——IM 系統裡使用者、好友、群組、會話全部存在 MySQL。如果你不理解索引的 B+ 樹結構、交易的隔離等級、行鎖和表鎖的差別，你連 AI 產生的 SQL 有沒有問題都看不出來。SQL 寫錯了 AI 不會提醒你，但你線上資料出問題了那可是真金白銀。

NoSQL（Redis 資料結構與適用場景、MongoDB 的文件模型、Elasticsearch 的倒排索引）——IM 系統用了 MongoDB 存訊息、Redis 做快取和未讀計數、Elasticsearch 做搜尋。每種儲存用在哪裡、為什麼用它、它有什麼限制——這些選型決策全是架構層面的，AI 做不了。

第三層：並發與分散式（進階必備）

這一層是區分「會寫程式」和「會做工程」的分水嶺。

並發程式設計（執行緒模型、鎖機制、CAS、執行緒池、volatile）——萬人在線的訊息推送，如果不懂執行緒池的參數配置和鎖的粒度控制，AI 寫出來的程式碼在並發場景下分分鐘出 bug——而你根本看不出問題在哪。並發 bug 是最難除錯的 bug，因為它不是每次都能重現。

分散式系統（訊息佇列、RPC、服務發現、CAP 理論、分散式交易）——IM 系統涉及 gRPC 跨伺服器通訊、RocketMQ 訊息廣播、Nacos 服務註冊發現。這些架構決策，AI 能幫你寫實作程式碼，但選型決策必須你自己做。

第四層：架構思維（高階方向）

這一層不是學出來的，是在前三層的基礎上，透過實戰專案練出來的。

怎麼從需求推導出技術架構？
怎麼評估一個方案的效能瓶頸？
怎麼在多種技術方案之間做權衡取捨？
怎麼設計一個可擴展、可維護的系統？

這些能力的培養沒有捷徑，只有一個辦法：做真實專案。 不是做一個 Todo List，而是做一個真正有複雜度的系統。比如一個 IM 系統、一個電商系統、一個推薦引擎——任何能讓你面對「真實複雜度」的東西。

同時：學會駕馭 AI 工具

以上四層是基礎，同時你要學會使用 AI 工具（Claude Code、Cursor、Copilot 等），它們確實能極大提升效率。但永遠保持對程式碼的理解和掌控——你不是在「讓 AI 幫你寫程式碼」，你是在「用 AI 加速你的想法落地」。

一句話：不懂程式碼，就無法真正駕馭 AI。懂程式碼，AI 就是你的倍增器。

九、一個新概念：Harness Engineering

說到這裡，我想引出一個 2026 年正在快速升溫的概念——Harness Engineering。

Google 的資深工程師 Addy Osmani 在O'Reilly 上發表過一篇文章，標題就叫《Agent Harness Engineering》。他還專門做了一個AI 輔助工程的實踐指南。他說了一句很關鍵的話：

「一個裸的 AI 模型不是 Agent，Harness（駕馭裝置）讓它成為了 Agent。」

什麼意思？

就好比一匹千里馬，它跑得再快，沒有韁繩、馬鞍、方向指引，你也騎不了。Harness Engineering 就是這個韁繩和馬鞍——它指的是圍繞 AI Agent 設計的那套約束、回饋迴圈、驗證機制和上下文管理。

具體來說，一個 Harness 包括：

約束設計：AI 能做什麼、不能做什麼、邊界在哪
上下文管理：給 AI 提供正確的專案背景、程式碼規範、架構約定
驗證機制：AI 產生的程式碼怎麼驗證對不對、跑測試、過 Review
回饋迴圈：AI 做錯了怎麼糾正、怎麼讓它從錯誤中學習
工具介面：AI 能用哪些工具、怎麼呼叫、權限怎麼控制

你看出來了嗎？這恰好就是這篇文章一直在說的「駕馭 AI」的具體實踐。

前面我說了，AI 時代程式設計師的核心能力是架構能力、驗證能力、駕馭能力。Harness Engineering 就是這三種能力的工程化落地。它不是一句口號，而是一套可操作的方法論。

拿我自己做 IM 專案來說，我並不是簡單地跟 AI 說「幫我寫個 IM 系統」就結束了。我會先告訴它整個系統的架構分層——閘道層負責驗證路由，長連線層用 Netty 做 WebSocket，業務層處理訊息儲存和好友關係，資料同步層消費 MQ 寫 ES。我會規定訊息的 Protobuf 協議格式，約定 Chat ID 的生成規則，說明離線訊息用 Redis ZSet 儲存的策略。我會把一個複雜功能拆成十幾步，讓 AI 一步一步來，每一步都驗證結果。

這個過程，本質上就是在給 AI 搭建一個 Harness——告訴它約束是什麼、上下文是什麼、怎麼驗證做得對不對。

而這一切的前提是：我自己先搞懂了 Netty 的執行緒模型、Redis 的資料結構、訊息佇列的投遞語義、Protobuf 的序列化原理。如果我不懂這些，我連 Harness 該約束什麼都不知道。

你的基礎越扎實，你的 Harness 就越精密，AI 的輸出就越可靠。

關於我是怎麼在 IM 專案中從零搭建 Harness、有哪些具體實踐和踩過的坑，我會在下一篇文章中詳細展開。

十、最後說幾句掏心窩的話

這篇文章寫到這裡，我想回到一個最根本的問題：基礎技術到底有多重要？

我用整篇文章在說這件事，但讓我再總結一次：

AI 能幫你寫程式碼，但不能幫你理解程式碼。AI 能幫你搭框架，但不能幫你做架構決策。AI 能幫你快速出原型，但不能幫你把原型變成生產級產品。這些能力的背後，全部是基礎——網路原理、作業系統、資料庫、並發、分散式。沒有這些，你跟 AI 之間的對話就只能是「幫我寫個 XX」，而不是「幫我實現這個架構方案，注意處理並發和交易」。

基礎決定了你能從 AI 那裡拿到什麼品質的輸出。 這就是為什麼 AI 越強，越要學基礎。

那程式設計師到底怎麼避免被 AI 淘汰？

說難聽點，路就兩條：

第一條：死磕技術，往上走。 把基礎打牢，從「寫程式的人」升級為「做架構決策的人」。學會駕馭 AI，讓 AI 成為你的倍增器。這條路不難理解，但需要時間和汗水——沒有捷徑。

第二條：認清現實，趁早轉行。 如果你既不想補基礎，又不想升級能力，只想靠 AI 混日子——那說實話，趁早轉行可能是更理性的選擇。不是每個人都要當程式設計師，但如果你想留在這個行業，就必須提供 AI 提供不了的價值。溫水煮青蛙，煮到最後是最慘的。

沒有第三條路。 指望「AI 取代不了我」是自欺欺人，指望「我會用 AI 就行了」是掩耳盜鈴。

AI 是一個放大器——放大高手的能力，也放大菜鳥的無知。基礎扎實的人用 AI，效率提升 10 倍；基礎不牢的人用 AI，只是把錯誤放大了 10 倍。