驗證中…
AI 打字很快，但它不會替你確認需求、不會替你驗收，也不會提醒你「其實還沒上線」。這四步就是補上這三件事。整份手冊的每一條規則，背後都有一次真實的翻車。
就記這四句。剩下的都是它們的展開。
你沒講的，它會自己補一個版本，而且講得很有自信。所以要逼它「先查再答」。
程式碼躺在檔案裡，不代表你打開網址就會動。中間還有存檔、部署、權限三關。
「應該可以」不算驗收。要拿得出實際跑出來的畫面或數字。
寫程式的 AI 有盲點。要另外開一個乾淨的 AI 來挑毛病。
用 Gemini、Claude 網頁版寫好，再複製貼到 Apps Script——這條路完全可行，但有五個坑是你這邊獨有的。四個步驟對你一樣適用，只是操作方式不同。
它不知道你現在的程式碼長什麼樣。要改哪個函式，把那整段貼給它。不貼，它就用猜的補一個。
上一輪講好的規則，新對話它完全不知道。把重要前提（要做什麼、欄位叫什麼）存成一段固定開場白，每次先貼。
網頁版沒有版本控制。覆蓋掉就真的沒了。貼之前全選複製，先存到記事本。
公司配的企業版（像 Workspace 的 Gemini）預設不會拿你的對話去訓練，貼公司資料沒問題。個人版的 ChatGPT、Claude 要自己進設定關掉「用我的對話改進模型」。不確定自己算哪種就問 IT。金鑰則是哪一種都不要貼。
它說「完成了」只代表程式碼寫好了。存檔、部署、更新版本，這三步都要你自己動手。
卡關幾乎不是因為 AI 寫不出來，是你自己還沒想清楚要什麼。它不會問你「這個真的需要做嗎」，你說什麼它就做什麼，而且做得很快。
不要先講技術，先用白話寫一段「人怎麼用它」。寫得出來，AI 就做得出來；寫不出來，代表你還沒想清楚，這時候開始寫程式一定白做。
「我早上打開網頁，看到昨天各遊戲的營收。如果比前一天掉超過一成就標紅色。我點紅色那筆，可以看到是哪個品項掉的。」
不用學怎麼寫提示詞。這五塊填一填就好——順序不重要，想不到的可以跳過，但「目標」一定要有。
為什麼要講到這麼細？同一句模糊的話丟給 AI 跑三次，會拿到三個完全不同的東西；五塊都填好的那段跑三次，結果會很接近。差異縮小，你才有辦法一步一步往下改。這五塊出自 Andrew Ng 的《Build with Andrew》，照著走一遍的版本在動手做導覽。
| 還沒想清楚 | 想清楚了 |
|---|---|
幫我做一個數據儀表板 |
我每天早上要看昨天各遊戲的營收和前一天的變化。資料在 BigQuery 的 X 表。第一版只要一頁、只要總數。 |
幫我做個工具自動化流程 |
我每週手動把五個 Excel 合成一份報表，要花兩小時。我要一個網頁，上傳五個檔就吐出合併好的檔。 |
幫我做個 AI 客服 |
（先回答：誰會問？大概問哪幾種問題？答錯了誰負責？三個都答不出來就先不要做。） |
你腦中的完整版有二十個功能，AI 會很開心地全部答應，然後你會得到一個每個功能都半殘的東西。先做一個功能、真的用一週，再決定第二個功能——通常跟你原本想的不一樣。
這份手冊自己就踩過。先挑了一個部署方式、做完上線，才想到內部工具應該限公司帳號登入——而選的那個平台根本沒有登入機制，整個部署方式要重來。「誰會用、要不要登入」如果在第一天就問，就沒有這件事。
從零開始最容易死的方式，是讓它一口氣把二十個功能都生出來。你會拿到一大坨看起來很完整、但沒有一個真的能用的程式碼，而且你不知道該從哪裡開始查。
不會看程式碼完全不影響你 debug。你只要描述「我做了什麼、我看到什麼、我以為會看到什麼」，那是 AI 唯一需要的線索。它回一大串術語解釋原因時，你不用管它在講什麼——看它給的新版本有沒有好就好。
# 這樣講就夠了 我按下送出按鈕，整頁變成空白， 本來應該要出現一張表。 # 不用這樣講 是不是 async 的 race condition？（你不用知道那是什麼）
這份手冊的插圖來回退了五次：「不要 icon」「我不要 AI 圖是 emoji」「我要的是素材」——每次 AI 都以為聽懂了，做出來還是不對。視覺、語氣這種講感覺的需求，用形容詞永遠講不清楚，直接找一個現成的範例丟給它看。
AI 為了標記段落，自己發明了一個罕見符號當分隔線，宣稱「理論上模型會原樣保留」。實際上模型沒看過那個符號，整批輸出全毀。沒先拿一筆試，就直接上了主流程。
一句寫壞的查詢讓資料庫產生約 220 億筆中間資料，跑了 42 分鐘還沒停，整個 AI 卡死不回話。要它先估算「這句會掃多少資料」，再決定送不送出去。
全新做出來的東西沒有人用過，壞了也沒有人會通知你。AI 說「完成了」通常是「我寫完了」，不是「我確認它會動」。
把「用起來的樣子」一步一步實際走一遍。走得完才叫完成，走不完就是還沒好。
# 先把標準給它，再叫它測 這是驗收標準，一條一條跑過， 每一條都要貼出實際跑出來的結果： 1. 打開網址 → 看得到上傳按鈕 2. 上傳一個正常的檔案 → 三秒內出現結果 3. 什麼都不上傳就按送出 → 出現提示，不能整頁壞掉 4. 上傳一個空檔案 → 不能當掉 # 沒給標準的話它會怎麼做 你只說「測一下」， 它就會寫一個永遠會過的測試給你。
它可以自己測自己，前提是標準由你來寫。真的很重要的東西，再換一個 AI 重看一次。
debug 時拿了另一個產品的檔案來測，格式對、也跑得過，但對照表整份都不一樣，一小時的測試結果全部作廢。測試資料要拿真的會進來的那種，不是你手邊剛好有的那種。
批次寫入資料時日期格式錯了，系統設定成「錯的就跳過」，於是安靜地一筆都沒寫進去。兩小時的 AI 呼叫全部白費。要跑一千筆之前，先跑一筆看看。
開一個新對話、只給需求和檔案，當場抓到兩個原作者完全沒想到的漏洞，包含「警報信寄失敗時，系統還以為寄成功了」。寫的人看不到自己的盲點。
在你的畫面上跑得起來，跟別人打開網址就能用，是兩件事。最常見的誤會是以為「推上去」就等於「上線」。
多數平台有兩個動作：push（把檔案傳上去）和 deploy（把使用者的網址切到新版）。 只做前者，你自己測的是新版、使用者看到的是舊版，所以你以為好了。
這份手冊先放在一個平台上，後來換到另一個，舊的忘了關。兩個網址內容不一樣，發出去的還是舊那個。換地方上線，記得把舊的關掉，或至少寫下來哪個才是真的。
# 不用裝任何東西。貼完程式碼之後： # 1. 先按存檔（磁片圖示 / Ctrl+S） # 沒存檔，後面每一步做的都是舊的 # 2. 右上角「部署」→「管理部署作業」 # 選現有那筆 → 鉛筆圖示 → 版本改成「新版本」→ 部署 # ← 少了這步，使用者看到的還是舊版 # 3. 順便看一眼「有權存取的使用者」 任何人 # 全世界都打得開 僅限組織內的使用者 # 只有公司帳號 ← 內部工具選這個 # 4. 複製網址，開無痕視窗貼上，親自看一次 # 看得到新改的東西 = 真的上線了
# 1. 第一次要先登入（會開瀏覽器） gcloud auth login # 2. 指定要放在哪個專案 gcloud config set project 你的專案名稱 # 3. 上線（--source . 代表用目前資料夾） gcloud run deploy 服務名稱 \ --source . \ --region asia-east1 \ --allow-unauthenticated # ← 這行代表全世界都能開 # 內部工具請拿掉，改開 IAP # 4. 查網址，然後親自打開看一眼 gcloud run services describe 服務名稱 \ --region asia-east1 --format="value(status.url)"
# 1. 第一次要先登入 clasp login # 2. 把檔案傳上去（此時使用者還看不到） clasp push # 3. 建一個版本 clasp version "這次改了什麼" # 4. 把使用者的網址切到新版 ← 少了這步就白做 clasp deploy -i 固定的部署ID -V 版本號 # 5. 確認線上真的是新版 clasp deployments
不用背。把「我要上線，帶我一步一步做」丟給 AI，它會問你缺哪些資訊。只用網頁版的人看第一個分頁就夠。
AI 很會寫「能跑」的程式，但「能跑」跟「安全」是兩件事，而且它不會主動提醒你。下面四件事沒做，你的工具就是敞著門。
程式碼會被複製、被貼給同事、被上傳到 GitHub。金鑰寫在裡面就會跟著跑到你想不到的地方，而且撤不回來。正確做法是把金鑰放在「程式外面」，程式跑的時候才去拿。
.js、.py、.gs 檔裡。PropertiesService 讀。.env 檔，然後一定要把 .env 寫進 .gitignore。照抄給 AI：「把這段裡的金鑰改成從環境變數讀，並告訴我要去哪裡設定。」
使用者按一下 F12 就能看到你前端的全部程式碼跟它抓回來的所有資料。所以「前後端分離」不是工程師的潔癖——是拿金鑰、查資料、驗身分這些事必須在後端做，前端只負責把後端願意給的東西畫出來。
| 不能放在前端 | 要放在後端 |
|---|---|
| API 金鑰、資料庫密碼 | 後端讀環境變數，前端跟後端要結果就好 |
| 整張表撈回來、前端再篩選 | 後端篩完，只回傳畫面上要顯示的那幾筆 |
if (isAdmin) 才顯示按鈕 | 後端驗身分，沒權限直接不給資料 |
| 「這個網址別人不知道」 | 當作全世界都知道，再決定要不要擋 |
把按鈕藏起來不是權限，那只是把按鈕藏起來。資料還是抓得到。
預設答案幾乎都是「全世界」。Firebase Hosting、Cloud Run、GAS 的「任何人」選項，都是真的任何人。內部工具如果放了公司資料，這一步沒做就等於外流。
沒有要你登入就直接打得開 → 它是全公開的。內部工具請改成限公司帳號：GAS 在部署設定選「僅限組織內的使用者」；Cloud Run 開 IAP；Firebase Hosting 沒有登入機制，不要拿它放內部資料。
AI 建服務帳號時很愛直接給 Owner，因為那樣一定不會失敗。但那把鑰匙開的是全公司的門，出事就不是一個工具的事。要它列出「最少需要哪些權限」，先給最少的，跑不動再加。
同一個道理：使用者輸入的文字不要直接接進查詢語句。叫 AI 用參數化查詢，不然人家在搜尋框裡打幾個字就能把你整張表撈走。
不管是 AI 寫給你的程式碼，還是你從網路上抓來的工具，出現下面這些字就先停。不是有就一定是壞的，正當用途都存在——但你要知道它在那裡，而且要能講出它為什麼需要。
直接複製貼上，看它怎麼回。
這段程式碼裡有沒有寫死的金鑰或密碼？改成環境變數，並告訴我要去哪裡設定。
它應該要能指出第幾行。指不出來就叫它重看一次。
使用者按 F12 打開我的網頁，能看到哪些不該看到的東西？
答案裡出現金鑰、完整資料表、別人的資料 → 那些要搬到後端。
這個服務最少需要哪些權限？現在給的是不是超過了？
上線前問一次。多給的權限平常看不出來，出事才知道。
上面講了一堆要小心的。但該用的地方不用，也是一種浪費——這三件事幾乎沒有風險，而且你自己做會慢很多。
做到一半沒靈感，就問「這個東西還可以加什麼功能」。它一次給你十個，你挑一個來做，不喜歡就全部不要。
還沒想好就先跟它聊。叫它反問你問題、叫它把你的需求覆述一次——這一輪來回常常比你自己空想半天有用。
「這段有什麼會壞掉的地方？」「這樣寫有什麼風險？」它挑毛病的能力比你想像中好，只是你不問它不會主動講。
每一條背後都有一次真實的翻車。帶走這一頁就夠。
可以。你的角色不是寫程式，是「決定要做什麼 + 驗收」。這兩件事不需要會寫程式，需要的是清楚知道自己要什麼，以及不輕易相信「應該可以」。
問一句：「你是實際查過，還是推測的？查過的話貼出你查的東西。」貼不出來的一律當推測。它被質疑時通常會自己改口。
同一個問題修到第三次還沒好，就不要讓它再試第四種寫法了。改成問：「你認為根本原因是什麼？有沒有可能整個方向就錯了？」多數時候是前提錯，不是寫法錯。
四種情況：要刪東西、要動正式版、兩條路各有代價要選一條、還有它講的跟你知道的不一樣。這四種都先停。
自己開一次網頁，找一個「新版才有、舊版沒有」的地方看。不要用「AI 說部署成功」當證據。
可以，但標準要你來寫。把驗收條件和要測的狀況一條一條列給它，它跑得比你仔細；只說「測一下」，它會寫一個永遠會過的測試。很重要的東西，再換一個 AI 重看一次。
AI 很會寫，但不會替你確認、不會替你驗收，也不會告訴你「其實還沒上線」。這三件事留給你。