非工程師的 Vibe Coding 入門:從 CLI 卻步到漸入佳境

前言

半年前,我第一次打開 Claude Code。

黑色的終端機畫面,閃爍的游標,等我打字它才會動。

我關掉了。

我不是工程師。沒寫過 C++、沒念過資工系,連 git pull 跟 git push 的差別都要 google。但我做了好幾個 side project:一個 LINE 貼圖商品、一個小說協作系統、一個會自動發週報的工具。全部都用 AI 一起寫。

過去半年我用的是 Claude 的桌面對話介面。打開應用程式、輸入文字、按 Enter,跟用 ChatGPT 沒什麼兩樣。然後有一次 Anthropic 升級了訂閱方案,把 Claude Code(一個跑在終端機裡的 agent)綁進同一個訂閱裡。對我來說那就是個白送的東西。我點開一次、嚇到、關掉。

直到三個月後,我發現我每天在 Claude 桌面版打的字裡,有一半其實是「請幫我跑這個 npm script」「請幫我看這個錯誤訊息」「請幫我把這段 code 改成⋯」然後手動把結果貼來貼去。那一刻我意識到,那個我以為很可怕的黑色終端機,才是我每天在做的事情的最短路徑。

我重新打開它。

這篇不是「怎麼用 Claude Code」的教學。是一個非工程師走過 CLI 卻步到漸入佳境的過程紀錄,加上我觀察到的工程師三類光譜,跟我自己被坑過的一個誤解。

四種跟 AI 一起寫程式的姿勢

先講一個概念。

「Vibe Coding」這個詞 2025 年 2 月被 Andrej Karpathy 在 Twitter 上 post 出來,半年內擴散整個科技圈,還被 Collins English Dictionary 選為 2025 年度詞。原本是工程師圈內自嘲式的說法:「不是真的在 code,是用聊天的氛圍在 code」。但這半年下來,這個詞已經滑出了工程師圈。對沒寫過程式的人來說,它其實是更精確的描述:你用人話跟 AI 一起把東西做出來。

所以挑工具的時候,問題不是「哪個 AI 比較強」,是「你想用什麼姿勢跟 AI 一起寫東西」。下面四種姿勢,各自有對應的代表工具。

姿勢一:終端機裡的 agent

我現在主用的是 Claude Code,Anthropic 出的終端機版 AI 編程 agent。它跑在 terminal 裡 — macOS、Linux、Windows 三家平台都原生支援(2026 年初 Anthropic 補上 native Windows installer,走 PowerShell 或 Git Bash 都行)。介面是純文字。你打中文跟它說「幫我把這個 Astro 專案的 RSS feed 加上 atom self link」,它會自己讀檔、改檔、跑測試、處理 git。

Claude Code 終端機介面(by aire 編輯室,2026-05)

CLI 的優點是控制感最強:你看得到每一步它在做什麼,可以隨時 Ctrl+C 停下,所有操作都會落在 git history 裡。缺點是初次打開的視覺衝擊大。沒有按鈕、沒有滑鼠、沒有 panel,只剩打字。但用熟之後會發現,這個「最少視覺隱喻」的介面,反而是干擾最少、最直接的對話。

定價結構是 $20/月 Pro 或 $100/月 Max。前者足夠中度使用,後者適合每天多 session、開大型 codebase 的人。

姿勢二:桌面工作空間

如果你完全不想碰終端機,Cowork 是同一家公司的對話介面版本。Anthropic 把它定位為「不需要懂程式碼的 Claude Code」,目標族群明確指向研究員、分析師、營運、法務、財務這類「跟文件、資料、檔案打交道但不寫程式」的知識工作者。

Cowork 桌面工作空間 + 本機資料夾整合(by aire 編輯室,2026-05)

它跑在 Claude 桌面 app 裡,介面跟你已經習慣的對話框一樣,但多了「連到本機資料夾」這個能力。你可以開一個專案、指定某個資料夾,Cowork 就能在那個資料夾裡讀檔、寫檔、跑指令。Claude Code 能做的事它幾乎都能做,差別只是介面從終端機換成對話框。

Anthropic 2026 年 1 月 announce 它為 research preview,4 月 9 日正式 GA(同日順帶發了 Managed Agents)。對「跟 AI 交辦事情」這個 mental model 最熟的人,Cowork 是最自然的入口。

姿勢三:編輯器加上 AI agent

Cursor 走另一條路:把熟悉的 VS Code 介面加上 AI agent。它仍然是個 IDE,有檔案樹、有編輯區、有終端機 panel,但中間多了一個 Composer 面板。你描述要改什麼,Composer 就跨多檔執行。

Cursor 編輯器 Composer panel(by aire 編輯室,2026-05)

對「能讀程式碼、會看 diff,但不想全部自己寫」的人,Cursor 的甜蜜點很明顯。Pro 是 $20/月,Auto mode 自動選 model 不會吃 credit pool 額度,手動點 premium frontier 模型才會扣。對完全沒寫過程式的人,IDE 介面本身仍是門檻:滿屏的 panel、檔案樹、設定,需要時間消化。Cursor 適合「半工程師」 — 有過 SQL、script、Excel macro 經驗,看得懂 diff 但不想從零寫起的人。

姿勢四:打開瀏覽器,輸入 prompt

Bolt.new 是 StackBlitz 出的瀏覽器全端開發環境。零本機安裝,打開網頁、輸入「我想做一個 XX 網站」,幾分鐘後就有一個可以跑的 demo + 即時 preview。

Bolt.new 瀏覽器全端開發環境(by aire 編輯室,2026-05)

這是四種姿勢裡門檻最低的。你不需要裝 node、不需要懂 git、不需要設 API key。代價是控制感最弱:所有 code 跑在 StackBlitz 自家的 WebContainers 裡,你看得到但不容易拉下來自己改。Pro 是 $25/月、按 token 計費,免費 tier 也有每日跟每月額度。對想驗證一個 idea 能不能成立、需要快速 prototype 的人,Bolt 是最直覺的入口。

---

四種姿勢沒有對錯。差別只在你日常工作的型態、你想要多少控制感、你能接受多少設定門檻。我自己最後落在 Claude Code,但那只是我的路徑,不是答案。

工程師三類光譜

我是非工程師,但我有個小型公司,裡面有工程師同事。觀察了一段時間之後,我發現他們對 AI 寫程式工具的反應分得很清楚,大致是三類。

要先說:這是我自己公司、三五個樣本的觀察,不是統計,沒有要當通則用。但這個 framing 對我自己理解事情有用,所以也分享出來。

第一類是大量使用組。他們每天開、每天用,已經把工具納入工作流。他們會在 Slack 裡丟「我這段讓 Claude 寫完五分鐘搞定」,會討論今天 Sonnet 4.6 跟 Opus 4.7 在某個 refactor 上的差別。對他們來說,AI 不是要不要用的問題,是怎麼用得更好的問題。

第二類是還在覺得 bug 多組。他們試過、被坑過、停下來、回到舊工具。我問過幾個,得到的答案類似:「上次它把我的 file 改錯」「產生的 code 有時候 hallucinate function」「調 prompt 比自己寫還久」。這些都是真的,不是抱怨。差別只是他們把這些經驗解讀成「工具還不能用」,而不是「工具需要適應方式」。

第三類是還在用純人力評估組。他們沒試過,看別人試覺得不可信。原因通常是「AI 寫出來的 code 我看不懂沒法 review」「我們的東西太重要不能讓 AI 改」。這些都是合理立場,法律、醫療、金融、合規敏感的工作本來就該謹慎。但也有一些人是純粹「還沒上車」,把「慢慢評估」當成穩健,其實是另一種風險偏好。

哪一類人最像半年前的我?答案是第二類。我也試過、也被坑過、也覺得「調 prompt 比自己寫還久」。差別只是後來我發現一件事:差別不在工具,差別在能不能接受「工具會出錯」這個前提。

接受了,工作流就會繞著「會出錯」設計:小步驟、多 review、可逆操作、commit 頻繁。不接受,就會永遠在等一個「穩定到可以用」的版本。但工具不會穩定到那個程度,因為它的本質就是隨機性的。

順帶說一句:我不是要說大量使用組就比較聰明。他們只是更早接受了那個前提而已。

我以為的最大誤解:規劃可以省掉執行的問題

接著說我自己被坑過的一個誤解。

剛開始用 AI 寫程式的時候,我以為只要 prompt 寫得夠清楚、context 給得夠完整、需求列得夠細,AI 就會給我我想要的。

不是這樣。

具體說:我會花兩個小時寫一份 6,000 字的 brief,把「要做什麼、為什麼、邊界在哪、預期產出、失敗條件」全部列清楚。然後丟給 Claude、按 Enter、等。等出來的東西,跟我想像的還是不一樣。

一開始我以為是 brief 不夠清楚,回去再加 1,000 字。再 Enter、再不一樣。

後來才意識到,問題不在 brief。是我對「規劃」這件事的理解錯了。

過去的工作經驗讓我相信:規劃做得夠細,執行就是按表操課。這在做設計工作、做行銷企劃、做客戶提案都成立。但在跟 AI 寫程式的場景裡,這個邏輯失效。

原因是 AI 給出的第一版,不只是「執行你的規劃」,它同時也是「根據你的規劃,產生一個可以推翻的初稿」。它真正的功能是把你的想法快速 externalize 成一個你可以指著說「這裡不對、那裡再多一點」的具體東西。

規劃的真正價值,從來不是給你「規劃完就可以閉眼執行的東西」。是給你「有東西可以推翻的第一版」。

意識到這件事之後我的工作流變了:brief 從 6,000 字砍到 1,500 字,先把方向講清楚就好。剩下的留給互動。第一版產出 → 我反饋 → AI 改 → 我反饋 → 再改。可能來回 5-8 次,但每一次都離我想要的近一點。

過度規劃不等於規劃太多。是把規劃放在錯的位置。

半年後,我重新打開那個 CLI

回到開頭那個畫面。

半年前我打開 Claude Code,看到黑色終端機、閃爍的游標,把它關掉。半年後我每天的工作幾乎都在這個介面裡。

中間沒有什麼戲劇性的轉折。我只是慢慢理解了三件事:CLI 不是工程師的特權,是一種對話的姿勢;AI 寫程式不是「工具會自己幫你做完」,是「工具陪你一起邊做邊調」;規劃不是執行的替代品,是給自己一個能推翻的起點。

如果你跟半年前的我一樣,被 CLI、被介面、被設定門檻嚇到,接下來這個系列的後續文章會回答的問題:

• 怎麼用 Cowork 把日常工作交給對話介面(系列下一篇)
• Claude Code 終端機其實沒那麼可怕(系列第三篇)
• 瀏覽器版 vibe coding 三巨頭:Bolt、Lovable、Replit Agent 各自的位置(系列第四篇)

姿勢不只一種。挑一個跟你日常最近的開始就好。