TL;DR
- 很多 AI Coding 新手會卡住，通常不是因為不夠聰明，而是還沒理解工程流程
- AI Coding 的核心，不是叫 AI 幫你多寫 code，而是先把需求與完成條件想清楚
- 現在很多基礎功能其實早就商品化，不需要每次都自己重寫
- 真正值得花力氣的，通常不是基礎設施，而是產品核心邏輯
- 對零技術背景的人來說，先理解觀念，再進入流程，會比一開始硬做更有效率
適合閱讀的人
- 想用 AI 開發產品，但沒有工程背景的人
- 剛開始使用 AI Coding / Vibe Coding 工具（Codex、Claude Code、Cursor 等）的人
- 想理解軟體工程到底在做什麼的創業者
不適合閱讀的人
- 已經有多年工程架構經驗的工程師
- 想深入研究底層系統設計的人
很多人以為 AI Coding 的門檻在寫程式。
但老喬最近越來越覺得，真正卡住新手的，通常不是 code。
而是你還不知道：
- 需求要怎麼整理
- 完成條件要怎麼定義
- 哪些東西該自己做
- 哪些東西其實早就有現成方案
這篇文章，老喬想先把這個最基本的誤會講清楚
老喬為什麼開始研究 AI Coding
其實老喬從去年年底開始，就一直看到網路上很多人在分享 AI Coding。
很多大神會分享自己用 AI 寫程式
或是用 AI 建一個網站、做一個產品。
老喬當然也很好奇。
但問題是，老喬真的沒有工程背景。
每次打開這些工具
其實都有一種感覺：
「它好像什麼都能做」
但又好像「什麼都做不起來」。
超級挫折的 XDDD
例如我自己也買過 Replit
一開始覺得很酷
但實際用幾次之後就卡住了。
因為你會發現
工具裡面有很多東西：
- Agent
- 資料庫
- 部署
- 後端
- API
- Github
但如果你沒有工程背景
其實很難理解它們在幹嘛。
結果就會變成一種狀況：
工具很多
功能很多
但整個流程其實沒有跑起來。
老喬後來反而是透過 GPT
一直在討論一個問題：
這整個系統到底應該怎麼被設計？
很多人會提到一個東西：
PRD
(Product Requirements Document)
也就是產品需求文件。
但老實說
對一個沒有工程背景的人來說
「寫 PRD」本身就已經是一件很困難的事情。
因為你連系統怎麼運作都不知道。
這兩天老喬去參加小龍的開源聚會
再加上最近觀察一些工程師整理資料夾的方式
好像突然理解了一件事情。
AI Coding 的關鍵
其實不是寫程式。
而是先把整個系統的結構想清楚。
例如：
- 哪些東西是產品核心
- 哪些東西是現成模組
- 哪些東西可以直接用 SaaS
當這些東西被整理出來之後
AI 才會真的開始變得好用。
這次老喬開始用 OpenAI 的 Codex / Claude Code
來幫我整理需求。
我也不知道是不是習慣的問題
但我現在反而覺得
Codex 的使用門檻
好像沒有 Claude Code那麼高。
用 Claude Code的時候
常常會有一種感覺：
「它到底在幹嘛？」
雖然邏輯上看起來差不多
但使用起來總覺得比較不順。
這可能只是老喬自己的感覺
不一定是工具本身的問題。
但這幾次實驗之後
我開始慢慢理解一件事情：
AI Coding 的重點
不是讓 AI 自己寫完所有東西。
而是先把系統拆解清楚
讓 AI 知道：
哪些地方要寫
哪些地方不用寫。
為什麼老喬習慣說 AI Coding
業界其實很常講一個詞：
Vibe Coding
但老喬身邊很多朋友
其實都不是工程背景。
每次提到 Vibe Coding
大家其實都不知道那是在講什麼
所以在這篇文章裡
老喬比較習慣用一個比較直白的說法：
AI Coding
意思其實很簡單：
用 AI 來協助寫程式
或建立產品。
對一般人來說
這個說法會更容易理解。
有時老喬會開玩笑的說
Vibe Coding 就是讓 AI 用魔法變出你想像的東西
專業詞也沒有那麼複雜
就是 AI 幫你用 Coding 魔法就對了
所以在這篇文章裡
老喬會用 AI Coding 這個詞
來描述這整個開發方式。
本文關鍵字
- AI Coding
- AI Coding 新手
- AI 寫程式流程
- AI Coding 新手指南
- Vibe Coding
延伸性關鍵字
- Backend as a Service
一、AI Coding 新手最常見的三個誤解
很多人第一次接觸 AI Coding 時
會有幾個很常見的誤解。
第一個誤解是：AI 可以自己把整個系統設計好。
但實際上，AI 很擅長寫程式
卻不一定知道你的產品到底要長什麼樣。
第二個誤解是：只要描述功能，AI 就會自動把產品做完。
但實際操作後
很多人會遇到另一個問題：
AI agent 開了一堆
- 前端 agent
- 後端 agent
- 資料庫 agent
- 網路 agent
結果整個專案變成一直貼來貼去的對話。
第三個誤解是：很多功能都要自己寫。
事實上，現在很多基礎功能
早就已經有成熟的解決方案。
所以 AI Coding 並不是取代軟體工程的方法
而是加速原本的工程流程。
二、軟體開發的核心其實不是寫程式
很多沒有工程背景的人會以為
軟體開發的主要工作是寫程式。
但實際上，在很多工程團隊裡：
寫 code 的時間
可能只占 20% 到 30%。
更多時間其實花在：
- 需求定義
- 架構設計
- 資料模型
- 流程設計
- 測試
- 整合
所以在 AI Coding 的時代
最重要的能力其實不是寫 code。
而是把需求定義清楚。
在工程裡，這通常叫做：
Specification（Spec）
也就是說
你真正要先學的
不是怎麼讓 AI 幫你多寫一點 code。
而是：
- 你到底要做什麼
- 這一版不做什麼
- 做完之後長什麼樣子
- 怎樣才算真的完成
很多新手卡住
其實不是工具不夠強
而是這一層還沒有想清楚。
對很多零技術背景的人來說
這其實是一個很重要的轉折。
你不需要一開始就學會寫程式。
但你需要先學會一件事：
怎麼把模糊的想法
整理成可以被理解、被執行、被驗收的需求。
三、AI Coding 真正難的地方，不在工具
後來老喬慢慢發現
問題其實不是工具。
而是軟體工程本來就有一套基本工法。
如果沒有先理解這套基本工法
你就很容易出現一種狀況：
工具很多
功能很多
名詞很多
但整個專案就是動不起來。
所以 AI Coding 最重要的
不是一開始就選哪個模型最強
也不是一開始就開很多 agent。
而是先理解一個更基本的問題：
你到底在解什麼問題
哪些東西應該自己做
哪些東西其實可以直接用現成模組。
這也是老喬後來慢慢理解的事：
AI Coding 不是「AI 幫你寫程式」這麼簡單
它其實是一種新的產品開發方式。
四、很多基礎功能，其實早就不用自己重寫
這也是老喬後來比較有感的一個地方。
在工程思維裡
有一類東西其實可以理解成：
商品化功能
也就是已經很成熟
到處都有供應商
不值得每次都從零開始重做的功能。
很多新手一開始都會以為：
登入系統要自己做
寄信系統要自己做
資料儲存要自己做
付款也要自己做
但後來會發現
這些東西很多都已經有成熟方案。
例如：
- Login
- Storage
- Payment
所以真正要思考的
不是「怎麼從零開始寫」
而是：
哪些東西是商品化功能
哪些東西才是你的產品核心
當這個邏輯一清楚
AI Coding 就會突然變得比較合理。
因為你不再是叫 AI 從零造輪子
而是讓 AI 幫你整理、串接、實作真正重要的部分。
五、這個系列接下來會寫什麼
如果你看到這裡
大概已經會理解一件事：
AI Coding 真正的難
不是工具本身
而是工程流程。
所以這個系列接下來
不會急著講哪個模型最強
也不會急著講哪個工具最好用。
老喬會往下拆三件更實際的事：
第一
新手到底該怎麼整理需求
第二
AI Coding 的最小工程流程應該怎麼跑
第三
Planner、Integrator、Builder
這三個 Agent 到底該怎麼分工
第一篇，也就是這篇
先回答一個最基本的問題：
為什麼很多沒有工程背景的人
一開始做 AI Coding 會卡住
第二篇
會開始拆 AI Coding 的最小工程流程
例如：
需求怎麼整理
為什麼一開始不要開太多 Agent
什麼叫最小可行流程
哪些功能應該自己寫
哪些功能應該直接買
第三篇
再往下拆三個 Agent 的實際工作方式
也就是：
Planner
Integrator
Builder
它們各自應該負責什麼
要怎麼分工
又要怎麼避免一直貼來貼去
這樣整個系列
就會從：
概念
流程
實作
一步一步往下走。
結論
所以老喬現在越來越覺得：
AI Coding 最容易讓人誤會的地方
不是它太難。
而是它會讓人以為
只要會講需求
產品就會自己長出來。
但真實世界不是這樣。
需求沒有被整理
完成條件沒有被定義
哪些東西該自己做
哪些東西可以直接用
如果這些事情沒有先想清楚
再強的工具
也只是把混亂放大。
AI Coding 的真正價值
不是讓每個人都變成工程師。
而是讓更多人可以
把想法變成產品。
但前提是
先理解軟體工程的基本工法。
很多人以為 AI Coding 的重點是寫程式。
但老喬現在的理解是：
AI Coding 真正困難的地方
其實不是 code
而是把系統想清楚。
Key Takeaways
- AI Coding 最大的困難，通常不是寫程式，而是需求定義與工程流程
- 很多新手卡住，不是因為不夠聰明，而是還沒理解軟體工程的基本工法
- 多數基礎功能早就有成熟 SaaS，不需要每次都自己重寫
- AI Coding 最值得花力氣的，通常不是登入、寄信、付款這些基礎功能，而是產品真正的核心邏輯
- 對零技術背景的人來說，先把觀念想清楚，再進入流程與實作，通常會比一開始硬做更有效率
