零基礎，我用 AI 寫了一個機器人
以前要兩個月的學習時間，直接縮短到十天。
重點不是「使用語言可以達成什麼」，而是「使用語言可以看到什麼」。
最近剛好工作上有需求，我想做一個機器人幫我處理一些瑣碎任務。
我研究了一些自動化工具，像是 Make、Zapier，然後很快地遇上了卡關，也找不到教學可以解決。
卡關完全是我的問題，繼續往下找一定可以解決。但心中一直有種「就算搞懂了，功能終究受限於別人的產品吧？」的感覺，很提不起勁往下繼續找。
卡關到一半，腦袋忽然出現這句話：
「修但幾壘，大家不是都說可以用 AI 寫程式？我為何不自己寫一個 Python 腳本？」
兩年前我試過學 Python，大概學了一個月後放棄。我的程度就停留在 print(‘hello world’) ，跟知道什麼是 Command Line，就這樣。
現在有這個想法，心中第一個疑問是：
「真的可以嗎？我連機器人要 host 在哪裡都不知道。總不會放在我自己的電腦吧？」
我不知道這個問題的答案，
但直覺告訴我，可以去哪裡找答案：問 AI。
於是我開始跟 ChatGPT 描述我要做的事情，一來一往十分鐘之後，我已經在「寫 code」了。時間快轉十天，我完成了一個部署在雲端伺服器上，有簡單功能的機器人，並且實際交付給案主使用。
我被嚇到了。
依照兩年前的學習經驗，如果要從零架設出這個機器人，從頭開始讀文件、學伺服器架構、知道怎樣串起來、搞懂工作細節....至少，兩個月以上（包含偷懶時間）。
因為 AI ，這件事縮短到了十天，至少加速了五倍的程式學習時間。
AI 寫程式不只可行，還真的有點厲害。
不過實際操作下來，一切並不是真的那麼輕鬆寫意。有簡單的地方，但也有很多困難的，甚至反直覺的地方。
所以這篇文，我想記錄一下我踩過的坑，跟你分享。如果你跟我一樣是想寫一些自動化腳本的小白，也許會對你有幫助。
目錄
（本文 5000 字，建議留 15 分鐘慢慢讀。）
工具
▋ 0. 我使用的工具：Cursor AI ＋ Claude
核心概念
▋ 1. 「步步為營」是最佳解。
▋ 2. 反身性
▋ 3. 還是要跟著「讀」
▋ 4. 學習程式語言最快的方式
實作方法
▋ 一：除了寫腳本以外，也寫一份文檔紀錄思考。
▋ 二：Git 版本控制很重要。
▋ 三：必要時借助第三方意見（另一個 AI）。
▋ 四：用頭去撞牆。
結論
▋ AI 就能寫程式了，學程式語言還有價值嗎？
工具
▋ 0. 我使用的工具：Cursor AI ＋ Claude
當然，你可以直接用 ChatGPT 寫程式。但是這樣做你得一直複製貼上，我覺很沒有效率，最好還是找 AI 寫 Code 的專門工具。
我使用的工具是「 Cursor AI 」，整體成熟度很高，在聊天介面中許願就可以直接針對文檔修改，使用者體驗真的是絲滑。
你可以選擇要串 GPT-4o 或者 Claude 3.5 來寫，GPT 喜歡用列點的，Claude 則比較偏人性。意外地我發現，Claude 在讀懂我的意思跟產出品質上都比 GPT 好一點，不時還會跟你說：「你說得對！我們應該採取這個方式比較好。讓我來修改...」。
我沒有認真比較過兩者，應該能力都差不多。我單純喜歡跟 Claude 寫程式那種對話感，很有風見跟阿斯拉對話的感覺。（有年代了，我知道）
核心概念
▋ 1. 「步步為營」是最佳解。
AI 寫程式的過程，最反直覺的事情是這個：
「當我越想要描述清楚，就越容易出錯。」
這真的，非常弔詭。
畢竟任何人直覺，任何提詞教學都是「清晰描述我想要的東西」，對吧？
我一開始也是這樣想。
可是問題是「怎樣算是清晰」？我應該一次描述多少？
例如，假設我要做一個氣象機器人，我們可以從「抽象」推到「清晰」：
「我想做一個氣象機器人」
「我想做一個氣象機器人，我問了會告訴我天氣預報。」
「我想做一個氣象機器人，部署在 LINE 上，結合 Railway.app、WeatherAPI 和 GPT-3.5 語言模型，當用戶發問時會傳送日期、天氣預報、建議穿著」
到最詳細：
「我想做一個機器人，它的工作流如下：
1. 用戶對機器人傳送訊息：「招喚氣象先生」
2. 機器人收到訊息，確認明天日期是幾月幾號。
3. 機器人使用天氣 API 查詢明天天氣
4. 機器人回傳明天天氣。
5. 機器人從圖庫傳送一張圖片給予今天的穿搭建議
...（下略）」
基本上，如果你把「清晰」做到最徹底，你已經把程式寫完了。
一開始我以為要做到這樣的程度，用自然語言一次寫完整個工作流程，AI 才能寫成可以用的程式。反覆失敗撞牆，重來幾次之後，我意識到：
「不對啊，這個程式處在我的知識邊界之外。
我注定無法一開始就做到『有效的清晰』這件事。」
因此，真正的問題是：
當你完全不懂一件事的時候，要怎樣憑空做出「這件事」？
這個過程很像攀岩。
沒有人可以一次從地面跳到 300 公尺高的懸崖頂端，沒有人可以一次寫完整個程式。
你需要先從離你最近的「攀點」開始，一次確保三個點踩穩抓穩，然後只移動一個點。
在完全不懂的情況下使用 AI 寫程式，最好的策略就是「步步為營」。
每一步驟都跟 AI 一起搞清楚：一邊讓 AI 更了解「我要什麼」，一邊讓我更了解這個程式「究竟是什麼」。
這跟寫作很像——你不是有了清晰後才寫作，而是寫作之後才有了清晰。
不要貪心一次做出整個「氣象機器人」。
先做一個「部署在 LINE 上可以跟你說嗨的機器人」。
成功之後，加上 GPT-3.5？
再加上天氣 API。
再加上細節提詞。
再加上傳送圖片功能。
這已經不是「最小可行產品」（MVP）了，是更小的「最小單位部分」，一次只專注做一個最簡單的功能。反覆迭代，過沒多久你就有一個完整的氣象先生。
這個方法有用，主要原因是「Token 限制」。
AI 有 Token 限制，你一次給它越多資訊，它就越容易犯錯。
人也有 Token 限制，你一次想要描述越多東西，你也越容易犯錯。
回頭看，每次我失敗的時候，都是躁進想一次做完的時候；
成功推進的時候，都是一次只做一個小功能，最不貪心的時候。
實際操作上，我認為最好的方法是「聊天」。像是跟朋友聊到這件事一樣跟 AI 一起開發：
我：「我想要做一個氣象先生機器人，串接語言模型回答我的天氣問題。你怎樣看？」
GPT：「（回答）」
我：「你說得不錯，可是我想要它做到Ｘ功能...」
GPT：「（回答）」
這樣的一來一往，一陣子之後我就可以開始做第一個功能了。
（你完全也可以請 AI 幫你把大概念拆解成小功能）
▋ 2. 反身性
你有沒有搭過一種電梯，除了門以外三面牆都是鏡子，因為無數次影像反射，產生出無限的鏡像層次？
跟 AI 一起開發的感覺，很像是那樣。
我稱之為「反身性」：我把雛形拿給 AI，AI 丟回應給我，我修正後再丟回去，它再丟給我...每一次反射，都是把 AI 當成槓桿，放大碰撞且迭代我的想法。
就是在這種一來一往之下，我做完了整個開發的過程：
- 先有一個「想法」（雛形）
- 餵給 AI 請他寫成 Python（AI 加強）
- 我看程式哪裡不合理＋實際部署後將錯誤訊息丟給 AI （我加強）
- AI 修正錯誤，寫出更好的版本（AI 加強）
- 反覆迴圈。
這個「反身性」不只用來寫程式，也可以用在任何 AI 協作領域。
例如快速學習的場景。假設我不會西班牙文，怎樣在最短的時間內學到基本會話程度？
我只需要知道一個核心概念：「學會 100 個單字，就可以掌握 50% 語境」，
然後直接告訴 ChatGPT：
語言專家 Gabriel Wyner 說，「你只要專注在 1000 個最常用的單字，既可以掌握平均 70% 的文本。當你掌握 2000 的單字，你可以掌握 80% 。」
我現在想學西班牙文。請從語言學家 Wyner 的概念出發，幫我設計西班牙文中最精要、最高頻率使用的 100 個單字，每個單字都要附上一個例句。
你不用一次給我 100 個，先給我 20 個就好，我學習完了會跟你要下一個部分。
這些高頻率使用單字中，一定有大量的連接詞、主詞、受詞等，請也介紹基本的文法，並且附上使用情境與範例。
範例可以來些幽默點的，輕鬆些，不要都沉悶的。你可以看看結果，這個西文單字表可能是我看過最好玩的。
而記完這些單字例句，你可以用同樣的概念，請 AI 抓出最重要的發音、文法、介系詞、語助詞、20 個最常用的日常口語例句...
不用幾天，你就有 A1 西班牙文的程度了。
領悟到這點，我想起這個畫面：
搜尋引擎問世之後，「知道答案」變得不重要，「知道怎樣搜尋答案」變得很重要。
AI 問世之後，「會不會」變得不重要，「知道怎樣可以會」變得很重要。
▋ 3. 還是要跟著「讀」
我記得大約是在腳本長度超過 600 行之後，Claude 開始出現問題。
例如，在一個區塊裡 AI 沒有讀到它認為該有的物件，就跟你說要重新編輯，可實際上那東西只是放在腳本的一開頭。
或者，我發現 import 的部分有報錯，AI 就說這是版本問題，重新安裝 LINE SDK、Python 版本、重新跑虛擬環境....然後重來，再重來，再重來...直到第五個循環我受不了，手動殺掉這個迴圈才終止。
這些問題一定都超簡單，是工程師一眼就能看得出來那種。
但問題我是小白。
所以這個過程就是在跟 AI 比賽你的「程式直覺」：常識上來說，這個元件放在這裡合理嗎？這個流程合理嗎？為什麼寫這個步驟？
因此你不能只是躺平許願，你還是要跟著一起「讀 code」。
至少要知道整個架構怎樣運作，能判斷模型什麼時候在出錯，否則很快就會遇上瓶頸（我的話是 600 行）。
▋ 4. 學習程式語言最快的方式
單從「開發」的目的來說，因為還是要跟著讀，AI 目前還沒有完全取代「寫程式」這件事，操作者還是要會基本的程式概念。
但如果從「學習寫程式」來說，這個方法絕對是最光速的方式。
這次開發過程，我從連「函數怎樣寫」都忘了，到讀懂了大量 Python 語法、搞懂伺服器怎樣運作、實際部署 Git 、Control Flow、OOP...只花了十天。
因為直接處理「實際應用場景」，所以你學的一切都是「最需要用到的核心技巧」。
如果是傳統的線上課或互動軟體，十天我可能都還沒開始「用 python 寫計算機」之類的練習。這個練習沒有不好，只是真實世界裡，你通常不需要自己寫一台計算機。
不過，這種學習方式還是有限制的。我確實快速學會了 Python 的核心概念，但僅限於「讀」。真的要寫，還是只能靠 AI。
可是回頭來想：「會不會，只要這樣就夠用了？」
如果我維持「只會讀 code」的狀態，究竟到哪裡我才會開始撞牆，必須要手動寫 code？
這非常有趣。
我目前正在寫下一個腳本，這次用的語言是 JavaScript。也許我很快就會撞到這堵牆，再跟你回報。
但假設沒有這堵牆，那是很可怕的一件事：只要你想，你可以快速學習各種程式語言：JS、C++、Go、php、Rust...甚至 Lisp，如果你想不開的話。
當語言學習成本減少到五分之一時，我們怎樣重新看待「寫程式」這件事？
一個單獨工程師的能力邊界，可以被增強放大到哪裡？
實作方法
▋ 方法一：除了寫腳本以外，也寫一份文檔紀錄思考。
你需要一個地方先把概念思考清楚，而要清晰思考，你必須寫下來。
我發現，另外開一個文件（例如「devlog.md」之類），單純用來記錄每一天開發過程中遇到的狀況、目標完成進度、針對程式的思考、整體工作流設計...這個非常有幫助。
尤其是工作流。
如前面說的「步步為營」，我會先大概構想一次整個程式的完整工作流，寫在這份文件上，然後在文件上把工作流拆成小項目，每天完成一個。
（我在開發過程犯的最大錯誤，就是把整包工作流一次丟給 AI，然後寫出來的東西完全不能用。）
▋ 方法二：Git 版本控制很重要。
就跟玩 RPG 一樣，永遠預設自己隨時會被血條歸零。
寫程式的過程，要嘛 AI 要嘛自己 ，一定會有一方走錯路，錯到一個無以復加的程度，看著那爛成一攤的程式碼只能重來。
所以如果你從零開始，在你做任何事情之前，先學好基本的 Git ，註冊一個 Github，超級重要。（任何不懂的都可以直接問 AI）
小心設定遊戲「破關」到哪裡了，好好命名自己看得懂的格式。這樣至少當你不小心毀了一切的時候，還有能力「大俠重新來過」。
▋ 方法三：必要時借助第三方意見（另一個 AI）。
這個很酷。
我發現，有時把報錯訊息、有問題的代碼片段、看不懂的概念拿去問另一個 AI，你會馬上得到一個「第三方意見」，幫助你把問題釐清，加速流程。
所以除了 Cursor AI 以外，我也會開一個 ChatGPT 視窗，什麼不懂的、覺得怪怪的，馬上就丟那邊問它
我覺得這不是 Claude 或 GPT 哪個比較好的問題。我猜是因為 Token 限制，當 AI 處理一個特定工作太久了也會有「盲點」，會需要另一個模型來釐清。
分開兩個視窗，等於是分散 Token 壓力，兩邊分開記憶不同的事情：一邊 Cursor AI 裡的模型專注在開發，ChatGPT 則專注在解惑。
當然還是老話：問法會決定答案品質。盡量提供上下文，盡量說明清楚自己的狀況，得到的答案會更好一點。
▋ 方法四：用頭去撞牆。
兩年前自學程式那陣子，我看過一個老師這樣說：
「學習寫程式無他，就是一直『拿你的頭去撞牆』。（Banging your head to the wall）
當你遇到問題，你就不斷地去撞牆，去找答案，想方法，測試可能性....等到你撞得夠多次了，那面牆自然就會被你撞破。」
身為曾經自修學程式的人，我可以說：不管有沒有 AI，過程中的挫折感是一樣的。
一樣要 debug ，一樣要絞盡腦汁，一樣用頭撞牆 。
差別只是以前撞一百次會走一步，現在撞一百次就是走一百步：你能做到的層級不一樣。
寫程式有很多小工具、套件、資料庫...但這些都是枝微末節的表層。
最有用的核心工具，還是這個「用頭撞牆的意志力」。
「媽的，憑什麼這個問題我解不了？」
這句話罵個三四次，問題通常就會解決。
結論
▋ AI 就能寫程式了，學程式語言還有價值嗎？
這是我在開發的過程中，一直在思考的問題。
大學時代，我曾經在西班牙交換半年學西班牙文。
學一門外語最特殊的一點是：你必須用全新的方式來「訴說」這個世界。
例如，在西文中，
形容詞置於名詞之後。「黑貓」在西文裡會變成「貓黑」。
受詞會放在最前面。「我愛你」的西文是「你，我愛」。
再比如，單是「存在」這個概念，就可以用「Estoy,Esta, Estaba, Esté...」等多種形式，來表達不同的「存在狀態」，種類比英文還多很多。（我聽說最複雜的是德文）
甚至在道歉的時候，有時不是說「我很對不起」，會說「這，很對不起」（”Se siente”）。
這些完全不同的語法，讓我在說西文的時候，基本上是完全不同的一個人，有不同的個性。
當時我乾脆直接給自己取一個西文名字 Juan，因為我已經打造了一個全新的語義上的自我，原本的名字已經不是我了。
語言，就是工具。
我們使用這個工具，來把物理世界「煮熟」，轉換成「意義世界」。
使用不同的語言，你就會打造出完全不同的世界。
這次用 AI 寫程式，最強烈的感受是：忽然間，整個程式語言的世界在我面前快速開展，我看見什麼叫做「用程式語言思考」。
在學科上，這其實有個術語：「運算式思考」（Computational Thinking），關於如何拆解一個流程，轉換成電腦看得懂的表達方式。
因為 AI 寫程式，我快速碰到了運算思考的實際應用過程。即便只是跟著讀，也會逼自己要用程式語言來思考怎樣部署，只是你在思考的是大方向，不是實際的語法。
我覺得，鍛鍊思考這一塊是最珍貴的。
「當 AI 就能寫程式了，學程式語言還有價值嗎？」
當然有。
就像魚看不見水，大部分的人都低估了「學習語言」的價值。
重點不是「使用語言可以達成什麼」，而是「使用語言可以看到什麼」。
學一門外語，你跳脫中英文的限制；
學程式語言，你跳脫自然語言的限制。
你可以用純粹的運算邏輯反過來看自己的思考。即便只是架設簡單的機器人，你都會發現自己的思考有多少盲點。
在這個意義上，寫作和程式設計是一樣的：你能掌握的語言工具越熟練且多樣，你打造出來的意義世界就更精準且廣大。
學習程式語言，終極意義不是為了跟機器溝通，而是看見另一種世界——人類和機器一同生活的運算世界。
希望這篇文章對你有幫助。