引言

昨天，我們把一個生活中的小麻煩慢慢整理成了 idea.md。

現在方向有了，也知道第一版想先做什麼。接下來，AI 就不只是陪我們討論，而是真的會開始碰專案裡的檔案、改內容、跑指令，甚至一次動到很多地方，所以今天要分享的就是兩件事：

第一件是安全感。 如果它一次改了十個檔案，其中有幾個改壞了，我要怎麼回到現在這個狀態？

第二件是溝通。 同樣一句需求，講法不一樣，做出來的東西可能差很多。這幾年我自己累積了一些習慣——不一定適合每個人，但至少能省下不少來回。

一、先把安全繩綁上：Git 最小入門

Git 很容易一講就講很多。Branch、Merge、Rebase、Conflict、Reset、Revert……光名詞就可以塞滿一整篇。但今天先暫時不提，只先處理接下來幾天真的會用到的部分，之後真的開始大量改程式碼時，我們會再專門回來談 Git。

1.1 Git 跟 GitHub 是同一個東西嗎？

很多人會搞混，但不是。如果你玩過遊戲，可以先這樣想：

Git 就是存檔機制。
只是跟大部分遊戲不太一樣—— 存檔點是你自己決定的。 你覺得現在這個狀態不錯，就存一次；覺得剛剛那段改壞了，就回到上一個存檔點。而且它不會只留最新的那一份。每一個存檔點都還在，你想回到哪一個都可以。

GitHub 是放這些存檔的地方。
沒有它也不是不能玩，只是你的存檔會全部留在自己的電腦裡，很像單機遊戲——電腦壞掉，或是想換一台繼續，就麻煩了。

正式一點的說法是：Git 是版本控制工具，GitHub 是可以存放 Git Repository 的遠端平台之一（同類型的還有 GitLab、Bitbucket 等）。

今天會先把專案初始化成 Git Repository，留下第一個存檔點，再把它推到 GitHub。

1.2 先了解四個詞就好

其中 Stage 可能是容易讓人疑惑的一個——為什麼存檔之前還要多一個步驟？因為你不一定想把「目前改過的所有東西」都存進去。有時候你同時動了三個檔案，但只有兩個是這次真正想記錄的。Stage 就是讓你先挑：這一次的存檔，要包含哪些。

1.3 用 Cursor 留下第一個 Commit

昨天我們已經有了一份：

idea.md

所以現在很適合把它當成這個專案的第一個版本紀錄。

如果你使用 Cursor，可以直接打開左側的 Source Control 版本控制面板，點選初始化 Git Repository。

接著把目前的檔案加入 Stage，輸入 Commit Message（Cursor 有提供 AI 一鍵撰寫 Commit 的功能），例如：

初始檔案想法

點選 Commit 後，即可建立第一個 Commit。（這時候，這個存檔紀錄仍然在你的電腦中）
如果 Cursor 已經登入過 GitHub，接下來按 Publish Branch 或類似的發布按鈕時，通常可以直接使用目前登入的 GitHub 帳號。

如果還沒登入，則會需要先完成 GitHub 的登入或授權流程，再把目前的 Repository 發布到遠端。

Publish 時，可以選擇要 Public（公開） 還是 Private（私人），取決於你是否希望別人可以看得到你的專案內容。

這也是我喜歡從 IDE 開始的原因之一：第一次碰 Git 時，可以直接看到有哪些檔案被修改、哪些準備 Commit，可以不用記那麼多指令。

1.4 如果想用指令，也可以

同一件事情也可以在終端機 Terminal 裡完成。

最基本的流程大概是：

git init
git add .
git commit -m "Initial project idea"

如果你第一次在這台電腦上使用 Git，可能還需要先設定 Commit 使用的名稱與 Email：

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

如果想從命令列登入 GitHub，也可以使用 GitHub CLI：

gh auth login

接著依照畫面指示完成瀏覽器授權。

GitHub CLI 也可以用來建立 Repository，例如：

gh repo create

GitHub CLI 會一步一步詢問 Repository 名稱、要設成 Public 還是 Private，以及是否要把目前的專案推上去。

如果想直接一次完成，也可以寫成：

gh repo create albumdex --private --source=. --remote=origin --push

這行會一次完成：建立 GitHub Repository → 設定遠端 origin → Push 目前的 Commit
之後有新的 Commit 時，通常就只需要：

git push

不過今天不打算把 Git 的所有設定一次講完。目前只要知道：

Commit 是本機的版本紀錄；Push 才是把這些紀錄同步到遠端。

後面真的開始需要比較版本、還原、分支或處理衝突時，我們再把這條安全繩學完整一點。

1.5 也可以叫 AI 幫忙 Commit 嗎？

可以。

Coding Agent 本身就可以執行各種指令，所以也能幫你 git add、git commit，甚至在有相應權限的情況下完成更多操作。

但如果你才剛開始接觸 Git，我還是比較建議先自己做幾次。

至少要先知道：現在在哪個 Repository、哪些檔案準備被 Commit、這次 Commit 到底記錄了什麼…等等，等這些概念比較熟，再把其中一部分交給 AI 會比較安心。

二、你說的那句話，AI 真的會照你想的理解嗎？

接下來回到跟 AI 溝通的技巧上。有一個很老的笑話，大致上是：

老婆叫工程師老公去超市買一條麵包，她說：「如果有雞蛋，就買六個。」

結果老公最後帶回六條麵包。

因為有賣雞蛋。

這當然是笑話，但它其實很適合拿來想一件事：

文字本身不一定有你以為的那麼明確。

我自己也遇過很像的事情。

有一次，我在調整一個某一個專案的 Slogan，當時畫面上有兩行文字，第一行最後多了一個逗點。於是我跟 AI 說：「把第一行後面的逗點刪掉。」它確實把逗點刪掉了，但我發現第二行也一起不見了。

從我的角度來看，我原本想表達的是：「只刪那個逗點，其他不要動。」

但問題是，我沒有把後半句講出來。Day 2 講 Context 時，我們提過：模型看到的是目前提供給它的內容，再根據這些 Context 往下生成。它看不到我腦袋裡那個「這應該很 obvious 吧」。

所以有時候不是 AI 聽不懂中文，而是「你腦中知道的事情，不代表它也知道。」

三、少讓 AI 猜一點/同一句話，可能有很多種理解

有時候，AI 做出來的東西跟我想的不一樣，第一反應很容易是：怎麼又做錯了？但後來我慢慢發現，有些情況其實不太能直接說它錯。因為我腦中想的版本，從來沒有真的講給它聽。

3.1 我腦中有答案，但 AI 不知道

以 Day 2 的範例為例，我曾經拿「幫我做一個網站」來做測試。我腦中其實想的是：「幫我直接產生一份可以執行的網頁程式碼。」但第一次，我只說：「幫我做一個網站。」結果 AI 先幫我整理了需求和頁面規劃。第二次，我補了更具體的畫面描述，它又幫我產生了一張設計結果。直到第三次，我明確補上：「直接給我網頁程式碼。」它才真的給出我一開始腦中想的東西。

回頭看，其實前兩次不能說他答錯了。

因為「幫我做一個網站」本來就可以有很多種合理的理解：幫我規劃網站、幫我設計介面、幫我產生畫面圖片、幫我寫程式碼、幫我把網站部署起來…等等。只是我自己心裡早就默默選好了其中一個，卻沒有說出口。

這其實也能呼應到 Day 2 講到模型時，在 2.6 的部分我們提過：輸入的文字會被切成 Token，模型會根據目前拿到的 Context，一個 Token 一個 Token 往下產生。它可以使用的是：我真的提供給它的內容。 並不是我腦袋裡那一份「完整版需求」。所以很多時候，真正需要處理的不是「怎麼讓 AI 更聰明」，而是：怎麼少留一些重要的空白讓它自己猜。

3.2 很容易自動補上那些沒說出口的條件

再分享另一個笑話：

面試時，有個人跟面試官說：「我數學算得很快。」面試官馬上出了一題很難的乘法。他幾乎沒有思考就回答了一個數字。結果是錯的。

嚴格來說，他一開始只說自己：「算得很快」。 並沒有說：「算得又快又對。」 當然，這些都是故意鑽語意漏洞的笑話。

但它們剛好點出一件很有趣的事：

人類平常在溝通時，會自動補上很多沒有寫出來的條件。

「算數學」通常默認要算對、「刪掉逗點」通常默認其他東西不要動、「做一個網站」如果是在開發情境裡，我可能默認最後想拿到程式碼。但這些默認，未必真的存在於文字裡。

這是一個與 AI 協作很常遇到的一種落差：

我們以為自己已經講清楚，有時候可能只是自己腦中很清楚。

3.3 把已經確定的想法一起說出來

所以我現在如果心裡已經有一個方向，通常會盡量把那些已經確定的部分一起講給 AI。不一定要寫成很正式的格式，也不用每次都變成一大串 Prompt。只是如果我已經知道：我真正想達成什麼、哪裡可以改、哪裡不要動、有哪些限制、我腦中大概期待什麼結果。那就沒有太大理由故意藏著，讓 AI 自己猜。例如原本一句：「幫我調整首頁。」

如果我其實已經知道問題在哪，也可以直接說：

我想讓手機版首頁第一屏可以多看到一點內容，目前 Hero 區塊太高。請先調整 Hero 的高度、間距和標題尺寸，文字內容和下方搜尋區塊先不要動。

這樣做不一定會讓 AI 百分之百做對，但至少它需要自己補的空白少很多。我個人覺得 Prompt 很多時候不是要寫得多厲害，也不是越長越好。

比較像是：

把你已經知道的東西說出來，縮小 AI 需要自己猜的範圍。

如果你自己都還不知道答案，那當然是另一回事。這時候，我反而會故意留一些空間，讓 AI 幫我一起想。這也是下一節要講的事情。

四、我常用的幾種對話方式

除了把需求講清楚，我還有幾種滿常用的對話習慣。它們不是固定公式，也不一定每次都需要。比較像是看目前處在什麼狀態，再決定要讓 AI 多做一點，還是少做一點。

4.1 不確定的地方，先問我

例如，如果需求裡有一些我不希望 AI 自己猜的東西，我會直接說：

如果你發現需求資訊不足，先問我，不要自行決定。

這在資料結構、產品邏輯或大範圍修改時特別有用。因為 AI 很容易在資訊不完整時，自己補出一套「合理答案」。有時候猜對了。有時候沒有。

4.2 還沒想好時，先給我幾個方案

如果我自己也還沒確定答案，我反而不會立刻叫 AI 實作，會先請他給我方案，我再去決定。

例如：

請先給我三種可行方案，說明各自的差異、優缺點與取捨，先不要實作。

重點不是那「三種」方案，而是可以先把選擇攤開，再決定要走哪一條。

AI 在這種情境下有時候很好用，因為它常常會順便提醒一些我原本沒想到的 trade-off。

4.3 改動比較大時，先講計畫

如果我覺得這次修改可能會動到很多地方，我會先要求他給我他的做法，而不是直接動手，例如：

先說明你預計修改哪些檔案、每個檔案要改什麼，以及可能影響哪些功能。

這對 Coding Agent 特別實用。因為有時候它的做法本身沒有錯，只是比我原本預期的範圍大很多。先看一眼計畫，通常會比較安心。

4.4 發散時給空間，收斂時給邊界

這是我自己很常用的一個區分，因為AI 這種會去猜的特質，有時候也很適合去產生一些我們沒想過的想法。
如果我還不知道答案，我可能就會說：

這個功能可以怎麼設計？

我會少給一點限制，讓 AI 幫我發散。但如果我心裡已經很清楚：

我就是要把這個按鈕移到右邊，其他不要動。

那我反而會把範圍講得很明確。

簡單來說：

想不出方向時給空間；心裡有答案時給邊界。

當然，也不是每一次對話都要照這些方式走。如果只是改一個小地方，一句話就能說清楚，那就不用硬套流程。但如果你常常遇到「AI 做的跟我想的不一樣」，或花很多時間重新修改 AI 剛剛做的東西，可以試著回頭看，是不是有些歧義、選項或修改範圍，其實可以更早講清楚？

很多時候，前面多花一點時間說明，可以少來回好幾輪。

如果發現自己有一些很常在 Prompt 中提到的開發習慣，也很適合寫進 AGENTS.md 或是 CLAUDE.md 之中，這部分之後有機會會提到

結語與明日預告

今天做了兩件事：首先，用 Git 留下第一個版本，讓後面的修改至少有地方可以回去；再來，整理了一下我平常跟 AI 溝通時會注意的事：容易誤解的地方講清楚、還沒決定時先看方案、大改之前先看計畫。

這些不一定每次都要照做，但如果 AI 常常做得跟你想的不一樣，也許可以先回頭看看：是不是有些重要資訊，只存在自己的腦袋裡。

接下來，我們將進入進入第二幕，開始談網站本身了。一個網站是如何組成的？在寫下第一行程式碼之前，我想先花一天先簡單整理一下——前端、後端、資料庫各自在做什麼，一次點擊之後到底發生了哪些事？前端、後端、API、資料庫，到底是怎麼接在一起的？

我們明天見。