引言

昨天我們認識了一些 AI 開發中常見的名詞，也稍微看了幾家模型供應商和它們旗下的產品。

但問題也跟著來了：這麼多 AI 產品，到底哪一種適合拿來開發？

有人直接在聊天視窗裡叫 AI 寫程式；有人用桌面版APP；有人整天待在編輯器裡；有人只開終端機，讓 Agent 自己跑；也有人乾脆進到一個網站，從描述需求一路做到上線。

看起來都叫「用 AI 寫程式」，但實際的工作方式差很多。

所以我們今天會先把 AI 開發工具常見的幾種型態攤開來看，再決定這 30 天要用什麼環境工作。今天不會選出「哪一種最好用」，因為真正適合的工具，還是取決於你的工作習慣、專案需求和使用方式。今天也會第一次真的安裝工具。

一、AI 開發工具常見的幾種型態

1.0 先看全貌

先把常見的幾種工作方式放在一起：

＊這篇文章裡，我把這類工具統稱為 AIO（All-in-One）AI 開發平台。指的是把需求、生成、預覽、資料、部署等流程高度整合在同一個平台裡的工具。也有些人稱為 AI App Builder或是 AI Website Builder

這五種不是完全互斥，也不是嚴格同一層級的分類。它們比較像是幾種常見的「工作入口」或「開發環境型態」。而且隨著產品持續迭代，不同型態也越來越常互相融合。像 Cursor 原本以 IDE 為主，後來也加入了更接近 Chat 的 Agent 使用介面。

所以這張表的目的，不是硬把每個產品塞進某一格，而是先建立一張地圖：現在常見的 AI 開發工作方式，大概有哪些？

1.1 Chat

簡單來說，就是大多數人最熟悉的那種：打開網頁，直接跟 AI 對話。

Chat 是大多數人的第一站：，輸入一句話就能開始。不需要先裝環境，也不用知道終端機怎麼用。你可以貼程式碼、上傳截圖、問錯誤原因，甚至直接叫它幫你規劃一個網站。

它也很適合我們前兩天做的那些事：討論需求、釐清概念、比較方案、理解錯誤訊息。

但如果拿它當主要開發環境，很快就會遇到一個問題：你的本機專案通常不是它工作的中心。

實際上會變成這樣：

AI 給你一段程式碼
  → 你貼進本機專案
    → 自己跑一次
      → 發現錯誤
        → 把錯誤訊息貼回 Chat
          → AI 再給你一版
            → 你再貼回去 ⟳

小專案還好。檔案一多，這個流程就會開始變得很痛苦。

常見的像是Open AI 旗下的 ChatGPT 、 Anthropic 的 Claude 、Google 的 Gemini 、SpaceXAI 的 Grok … 等等。

【圖1、ChatGPT 網頁版截圖】

Chat 很適合討論；但拿它當主要開發環境，人很容易變成 AI 和專案之間的搬運工。

1.2 Desktop App

簡單來說，就是把 AI 變成安裝在電腦上的應用程式，通常能和本機環境整合得更深。

桌面版看起來常常和網頁版很像，仍然是以對話為主；但因為它直接安裝在電腦上，通常可以取得更多本機能力。依產品和你給的權限不同，它可以讀取本機檔案、理解螢幕內容、呼叫其他應用程式，甚至直接建立、修改專案裡的檔案。所以 Desktop App 相對網頁版聊天界面更適合拿來開發。

它最大的優勢是：你還是用熟悉的聊天方式工作，但 AI 已經不只是待在網頁裡，而是真的能碰到你的電腦。

不過它和接下來要提到的 IDE 有一個很明顯的差別：

Desktop App 通常是「對話」當中心；IDE 則是「專案」當中心。

在 App 裡，你可能可以直接叫 AI 幫你改專案，但不一定能像 IDE 一樣，隨時在同一個畫面看到完整的檔案樹、程式碼、diff、Git 狀態和 Terminal。

專案規模小時差異不大；但當檔案開始變多，能不能快速掌握「現在專案裡到底發生了什麼」，體感就會很不一樣。

而這也帶出今天很值得記住的一個原則：

能不能碰到你的專案，不是看它叫 Chat、App 還是 Agent，而是看這個環境實際拿到了哪些工具與權限。

常見的像是Open AI 旗下的 ChatGPT APP版、 Anthropic 的 Claude APP版、Google 的 Antigravity 等等。

【圖2、Claude APP版（桌面版）截圖】

1.3 IDE

簡單來說，就是在你真正寫程式的工作區裡，讓 AI 直接和專案一起工作。

IDE 是 Integrated Development Environment 的縮寫，中文通常翻成「整合式開發環境」。 如果先用最直白的方式理解，可以把它想成：把寫程式常用的工具整合在同一個工作區。 而 IDE 本來就是一般工程師寫程式的地方。

傳統 IDE 會把程式碼編輯、檔案管理、除錯、版本控制、Terminal 等工具放在一起；到了 AI 開發時代，又多了一層 AI 助手或 Agent。

IDE 與 APP版本相比，最大的差別不是「多一個聊天框」，而是：專案本身就是工作畫面的中心。

在這類工具裡，你通常可以同時看到：

• 左邊的資料夾與檔案
• 中間的程式碼
• AI 修改前後的對照
• 版本變更紀錄
• 終端機（Terminal）
• AI 對話

這也是 IDE 很大的優勢：你可以一邊讓 AI 工作，一邊直接看它到底改了什麼。 但相對地，它也有學習成本。

第一次打開時，你可能會同時看到檔案樹、程式碼、Git、Terminal、Extensions、AI 面板，看起來比 Chat 或 App 複雜很多。你不一定一開始就知道每個東西在哪裡、什麼時候該用哪一個。

所以 IDE 的代價不是「比較難」，而是：

它給你更多可見性和控制權，也代表你要花一點時間認識這個工作區。

常見的例子像是 Cursor；也有人使用 VS Code，再搭配 GitHub Copilot 或其他 AI 外掛，達到類似的工作方式。

【圖3、Cursor 截圖】

1.4 CLI

簡單來說，就是在終端機裡跟 AI 工作，讓它直接讀檔、跑指令、改專案。

CLI 是 Command Line Interface 的縮寫，中文通常翻成「命令列介面」。和前面的 IDE 不同，它主要不是靠按鈕和視窗操作，而是透過 Terminal 輸入指令來完成工作。

很多人第一次看到那個黑色視窗會有點害怕，但先拆掉一個誤解：使用 CLI 不是因為看起來比較專業，而是因為很多開發工具本來就透過命令列操作。

例如下面這些事情，都是在終端機裡完成的（現在看不懂沒關係，後面幾天都會遇到）：

• Git
• 安裝套件
• 啟動開發伺服器
• build
• test
• lint
• deploy
• 執行 script

所以當 coding agent 直接工作在 CLI 裡，就很自然可以做到：

讀檔 → 改檔 → 跑指令 → 看結果 → 再修

也就是 Day 2 講過的 Agent Loop。

CLI 很大的優勢，是它直接貼著開發工具鏈工作，而且通常不綁定特定的編輯器。今天你用 Cursor，之後換成其他 Editor，CLI 還是可以留在原本的工作流程裡。

另外，CLI 本身通常也比 APP 版本或 IDE 輕量一些，因為少了大型圖形介面的負擔。不過實際執行 Agent 時，還是可能啟動瀏覽器、建置工具、測試程序等，所以整體資源消耗不一定永遠比較低。

但相對地，它缺少圖形介面提供的視覺線索，學習門檻也會高一些。在 IDE 裡，你可以直接看到資料夾、程式碼、按鈕、diff 和 Git 狀態；到了 CLI，很多資訊都變成文字輸出。

安裝、啟動、切換資料夾，甚至離開程式，都可能有自己的指令。對第一次接觸的人來說，你得慢慢熟悉「我現在在哪個資料夾」、「這個指令會做什麼」、「怎麼啟動或離開工具」。

而且 Coding Agent 可以直接執行指令、修改檔案，所以能力越直接，權限也越值得注意。你需要知道它準備做什麼，而不是看到確認視窗就一路按下去。

CLI 的優勢是輕量、直接，而且站在開發工具鏈裡；代價則是圖形介面少，你要更清楚自己在哪裡、它正在做什麼。

常見的一些 AI 工具也都有推出 CLI 版本， 例如：OpenAI 的 Codex CLI 、Anthropic 的 Claude Code 、Google 的 Antigravity CLI ，甚至連原本以 IDE 為主的 Cursor，也推出了自己的 CLI 工具。

【圖4、Claude Code CLI版本截圖】

1.5 AIO Builder｜連環境都幫你包起來

簡單來說，就是連開發環境都不用自己準備，直接在平台裡從需求一路做到上線。

AIO（All-in-One）AI 開發平台最大的特色，就是很多原本要自己處理的事情，平台先幫你接好了。

你不一定要自己安裝開發環境、不一定要先搞懂部署，也可能連資料庫、登入、網域、預覽環境都已經幫你準備好。對第一次做產品的人來說，這是很大的優勢。

你可以把更多注意力放在「我要做什麼」，而不是先卡在「環境怎麼裝、資料庫怎麼接、要怎麼上線」。

所以 AIO 通常有幾個很明顯的優點：

• 上手速度快：打開網站就能開始
• 學習成本相對低：很多基礎設定被平台抽象掉
• 整合度高：開發、預覽、資料、部署常常在同一個地方完成
• 很適合快速驗證想法：尤其是 MVP、活動頁、簡單 Web App

但它的代價也正好來自同一件事。

平台替你處理得越多，你對底層的控制權通常就越少。

例如，你可能會比較依賴它提供的模型、資料庫、部署方式、Auth 或其他整合。當你想換模型、改架構、搬到別的平台，或做超出平台原本設計範圍的事情時，限制就會開始出現。

這也是所謂的 vendor lock-in（供應商綁定）：前期很省事，但專案越往後走，搬家的成本可能越高。

另外，成本也值得注意。

AIO 看起來像是「一句話就完成很多事」，但背後可能同時用了模型、Agent、建置、部署、資料庫等資源。有些原本你自己手動幾分鐘能完成的操作，平台可能會透過多輪 Agent 自動處理，所以使用量累積得比你想像中快。

因此它常常呈現一個很有趣的交換：

前期省時間，後期可能付在用量、客製與遷移成本上。

這不代表 AIO 不划算。相反地，如果你的目標就是快速驗證一個想法，它可能是最合理的選擇。

問題只是：你願意用多少控制權，去換多少速度？

常見的產品像是 Lovable、Manus、Bolt、Replit Agent 等。

1.6 綜合比較

看完五種型態，可以稍微整理一下各種型態工具的比較：

看完這張表，其實就會發現：選工具不是在找「最強」，而是在取捨不同維度。

有人最在意上手快，有人最在意控制權，有人不想碰終端機，有人則寧願多學一點，換取之後更大的自由度。

成本也是一樣。AIO 可能前期最省時間，但平台用量和遷移成本可能較高；CLI 本身輕量、自由度高，但學習成本和操作風險也比較直接。

所以真正該問的不是「哪一個最好？」，而是：「我現在最在意的是速度、成本、控制權、學習門檻，還是未來的自由度？」

二、這 30 天，我會怎麼選

這個系列，我會以 Cursor（IDE）+ Codex CLI 作為主要工作環境。

2.1 為什麼是 Cursor + Codex CLI

我會這樣選擇，不是因為這是唯一正解，也不是因為這兩個一定最強。我選它們，是因為它們剛好補彼此的缺點。

Cursor 提供一個很清楚的視覺化工作區：看得到資料夾架構、程式碼、終端機，改了哪幾行也一眼就看得到。對非工程背景的人來說，最重要的是——不會完全失去方向感。

Codex CLI 則適合把 Agent 真正放進專案裡工作。它可以直接在專案目錄裡讀檔、改檔、執行指令，再根據結果決定下一步。

所以對我來說：

Cursor 負責讓我看得清楚；Codex CLI 則讓 Agent 更直接地站進開發工具鏈裡。

老實說，幾種 CLI 我都會用。但今天只帶你裝一組，因為第一次就同時裝三個，卡住的機率是三倍。跑通一個之後，其他的邏輯其實是一樣的。

2.2 這套工具會花多少錢

這裡不做完整的方案比較，直接看我這 30 天實際會用哪些工具、每個月大概要花多少。

現在大多數 AI 產品都有不同等級的訂閱方案，差別通常在使用額度、可用模型、速度，或一些進階功能。如果只是剛開始學、偶爾做 side project，其實不用一開始就訂最高階；真的在開發過程中常常撞到額度，再往上升就好。

對，我其實同時訂了三家。不是因為財力雄厚，是因為我很容易手癢。再加上 Google 爸爸送福利，有學生優惠方案。（其實 Cursor 在去年也有學生免費一年Pro 的優惠，我也有拿，也算是繼續用Cursor的其中一個原因）

如果你還是學生，也可以先看看各家有沒有教育優惠、學生方案或免費額度。這類方案通常會比一般訂閱便宜很多，很適合拿來學習或做 side project。

這裡先記一個起始成本。後面如果因為開發需要新增方案、API、部署或其他服務，我會再一路往上加。到 Day 30 再回頭看看：這個網站到底花了我多少錢。

三、開始之前：它等一下就碰得到你的電腦了

這一節不長，但我覺得放在安裝前比較重要。

從接下來的步驟開始，AI 不再只是隔著聊天視窗給你建議。只要環境和權限允許，它可能真的可以讀你的檔案、改你的檔案，甚至在你的電腦上執行指令。

所以先養成幾個習慣：

1. 永遠知道它在哪個資料夾工作。 之後我們會用 pwd 確認目前位置。
2. 第一次不要直接拿重要專案測試。 先用一個乾淨的練習資料夾。
3. 權限要求不要無腦按同意。 不同工具對權限處理方式不同，不要假設所有危險操作一定都會被擋下來。
4. 特別注意安裝套件、刪除檔案、執行 script 這類動作。 看清楚它準備做什麼，再決定要不要允許。
5. 很快，我們會需要一條安全繩。 當 AI 可以一次改很多東西之後，就必須有辦法回到修改之前的狀態。這就是 Git 之後會出場的原因。

工具越靠近你的真實開發環境，你能交給它的事情越多，也越需要看清楚它的權限和修改範圍。

四、動手：把工作環境裝起來

這部分我會刻意從最簡單的開始，順序是：

1. 安裝 Cursor
2. 建立測試檔案
3. 認識 Cursor 裡的終端機
4. 安裝 Codex CLI

對第一次碰這些的人來說，這個順序有一個好處：你不需要一開始就打開一個完全陌生的終端機視窗。你可以一直待在 Cursor 裡，左邊看得到資料夾，下面才是指令。

以下，我的截圖會以 Mac 系統為例，並附上官網相關教學連結，若為Windows 系統，可以參考各個工具的官方網站，寫的都蠻詳細的。

4.1 安裝 Cursor

到官方網站下載安裝。下載下來應該會是一個 dmg 檔，雙擊後直接將 Cursor 拖曳到應用程式的資料夾中，接著再應用程式的地方就可以看到了。

安裝完成後打開，你可能會看到兩種畫面，一種是類似 Chat 版本的 Agent 頁面，如果你遇到這個畫面，點擊右上方「IDE」按鈕，或是 左上角「檔案」→ 「Open IDE」，應該就可以看到 IDE 頁面的入口了。

【圖5、Cursor Agent 模式】

【圖6、Cursor IDE 畫面入口】

接著，在電腦裡（可以自己決定要創在哪裡）建立一個新資料夾：

Day3TEST (可以隨意命名)

然後用 Cursor 打開它。

可以直接從 IDE 的首頁點選「Open Project」，選擇剛剛創立的資料夾
或是點選左上角「檔案」→ 「開啟資料夾」也可以。

這一步看起來很小，但很重要：這就是等一下 AI 會工作的地方。今天不會先拿重要專案測試。先給它一個乾淨、就算玩壞也沒關係的空間。

【圖7、Cursor IDE 介面佈局】

你現在不用認識全部功能，只要先知道幾個區域：

4.2 建立測試檔案

在剛剛的資料夾中，新增一個簡單的檔案：

day03-playground/
└── notes.md

可以直接在資料夾內操作，或是直接在 Cursor 左邊檔案欄點選新增檔案，輸入完檔名後，雙擊檔案，隨便打一些字，接著按儲存。

【圖8、Cursor 新增檔案方式】

儲存檔案的快捷鍵為：Command + S （Mac）或是 Ctrl + S（Windows）。記得存檔！

notes.md 裡面隨便寫幾行字就好，等一下會用到。

4.3 打開終端機：先知道自己在哪裡

頂部工具列點選「終端機」→ 「新增終端」把 Cursor 內建的終端機打開，你會看到一個可以輸入指令的區域。

【圖9、Cursor 新增終端】

今天只需要先認兩個指令：

先輸入 pwd，確認顯示的路徑最後是 Day3TEST。
再輸入 ls，應該會看到剛才建立的檔案。

【圖10、終端機指令測試結果】

我很建議養成這個習慣：在叫 Agent 動手以前，先知道確認自己在哪裡。
這也是我喜歡從編輯器裡打開終端機的原因之一 —— 它通常一打開就直接落在目前的專案資料夾裡，比較不容易跑錯地方。

4.4 安裝 Codex CLI

依官方文件的方式安裝，完成後啟動。（指令有可能會更新，以官方最新文件為主）

curl -fsSL https://chatgpt.com/codex/install.sh | sh

可以直接在剛剛啟動的終端機輸入上述安裝指令，也可以透過 Mac 應用程式列表搜尋「終端機」，開啟後輸入。

安裝後，在終端機輸入 codex 基本上就可以啟動 Codex CLI 了，在真正進入之前，他會要求你登入，並請你你確認給予他讀取資料夾的權限。

【圖 11、登入】

若出現登入畫面，選擇「Sign in with ChatGPT」（按Enter），會開啟登入網頁，登入後會顯示可關閉視窗，接著回到 Codex 畫面，應該就會到下一步了。（可以依照畫面提示 按 Enter 繼續）

【圖 12、確認資料夾權限】

【圖 13、Codex 啟動結果】

如果它進入一個可以輸入任務的狀態，代表今天最重要的環境已經搭好了。

「CLI 安裝在哪裡」和「CLI 現在在哪裡工作」，是兩件不同的事。
安裝完成後，你通常可以在不同的專案裡使用它。真正影響這次工作的，是你在哪個資料夾裡啟動 codex。
所以我們前面才會先用 pwd 確認目前的位置。

第一次啟動通常需要登入或設定，跟著畫面指示走就好。

五、第一次讓 AI 進到你的專案

工具裝好之後，我們不先急著叫它做網站。我們先用兩句話，來熟悉一下怎麼操作。

5.1 第一次：確認它讀得到

在 Codex 的文字輸入框內輸入：

請讀取目前資料夾裡的 notes.md，告訴我裡面寫了什麼。

如果前面都設定正確，它應該能直接讀到 notes.md 的內容。

【圖14、Codex 讀取檔案結果】

這和前面單純使用網頁 Chat 最大的差別，就開始出現了。

你不需要把 notes.md 手動上傳給它。Agent 現在已經直接工作在這個專案資料夾裡。

5.2 第二次：讓它真的改一次

接著給一個非常明確、而且改壞也沒關係的小任務，例如：

請把 notes.md 後方新增一個你覺得很好笑的笑話

執行完之後，不要只看它回你「完成了」。

【圖15、Codex 修改檔案結果】

在 Cursor 裡打開 notes.md（可以直接雙擊），確認那一行是不是真的出現。
這一步其實很重要，因為我們從第一天就一直在講同一件事：

AI 說完成了，不代表事情真的完成了，要記得確認。
當然，現在的 AI 越來越聰明，犯錯的機率會越來越少。

【圖16、確認是否真的有修改檔案】

今天的驗證很簡單：直接看檔案。之後專案越來越複雜，驗證方式也會跟著變成畫面、測試、資料庫、權限、部署狀態等等。但基本原則不會變。

到這裡，我們已經確認三件事：

1. CLI 確實在正確的專案資料夾裡
2. Agent 讀得到專案內的檔案
3. Agent 也能真的修改檔案，而不是只在聊天視窗裡告訴你怎麼改

環境正式準備好了。

結語與明日預告

今天，我們先把幾種常見的 AI 開發環境攤開來看，也真的選了一套環境，把它裝了起來。到這裡，Cursor 看得到我們的專案，Codex CLI 也已經可以讀取、修改裡面的檔案。工具準備好了。但現在還有一個更重要的問題：我們到底要開發什麼？

明天，我們會第一次真正把產品本身攤開來談。從一個模糊的想法開始，一路整理成：
問題 → 使用者 → 第一版做什麼 → 刻意不做什麼 → SPEC.md
最後再用 Git 留下第一個正式的版本紀錄。今天把甲板搭好。明天，我們決定要往哪裡走。

明天見。