Vibe Coding 實戰課 — Stage 1 · 用 AI
你的第一個對外服務 — 有網頁、有 AI、有通知
按 → 或空白鍵開始
M1-4 ・ 3 小時
從收意見的網頁,串成 AI 自動分析 + 多通道即時通知
純資料流,還沒 AI
AI 自動分類,email 通知到位
並行雙推,實戰通道
完成 Stage 1,你會做事件驅動的完整服務 — 從收資料到 AI 分析到多通道通知
M1-1 只能自己看 → M1-3 背景自動跑 → 今天：任何人都能用的服務
你是開飲料店的小老闆 — M1-3 做了飲料點餐系統
今天再做第二套：意見收集系統，最後兩套都裝上通知
10 分鐘搞定，註冊比 Line@ 簡單，課程中會直接用
沒有 Telegram 帳號的話，先註冊（手機號碼即可）
依指示命名你的 Bot（例：vibe-coding-test）→ 拿到 Bot Token
隨便傳什麼都行（例：hi）— 讓 Telegram 留下一筆訊息紀錄
開 api.telegram.org/bot<你的TOKEN>/getUpdates
回傳的 JSON 裡找 "chat":{"id": 一串數字} — 那串數字就是 Chat ID（M1-4 R5 會用）
把 Bot Token 跟 Chat ID 兩個記下來。M1-4 上課時直接用
如果你日常用 Line 而非 TG，可以選 Line@ — 但門檻較高
註冊 5 分鐘
不需審核
Bot Token + Chat ID
課程現場用這個
需軟體審核 1-3 天
需電信簡訊驗證
Channel Token + User ID
適合 Line 重度使用者，請提前申請
不需要兩個都學。課堂預設用 TG Bot 走完整流程，Line@ 提供額外講解但不深入
ROUND 1 · 0:00–0:25
從「自己電腦看得到」到「全世界看得到」
M1-3 的對話可能在不同視窗或斷掉了
新任務從零開始，順便複習怎麼跟 AI 講清楚
幫我寫一個 Google Apps Script 做一個網頁，顯示 Google Sheet 裡的飲料訂購資料 我的 Sheet 裡有這些欄位（自己貼上 Sheet 的欄位） [姓名 / 飲料 / 冰塊 / 甜度 / 數量] 請用 doGet 和 HtmlService 寫 做成讓任何人都能打開的公開網址
關鍵：把你 Sheet 的欄位貼給 AI
AI 才知道要讀哪些資料
記得換成你自己 Sheet 的欄位
部署 → 新增部署 → 網頁應用程式 → 存取權選「任何人」
部署完跳出的網址先複製起來
手機打開你的網址，看得到飲料訂單資料 = 完成
卡住了 — 舉手，或把錯誤訊息整段貼給 AI
只能在自己電腦看
分享要傳檔案
沒有公開網址
有公開網址
任何人都能打開
手機也能看
關鍵差異：部署（Deploy）= 上架
從「本機檔案」跳到「公開服務」
部署完跳出的網址沒複製到，回頭找的方法
每次都能回來找 — 不用怕網址不見
互相打開同學的網頁
版面設計、資料呈現方式、手機版面是否正常
這個網頁只能「看」— 訪客能不能「填資料」進來
下一輪：做第二套系統 — 意見收集頁，讓訪客填資料進來
ROUND 2 · 0:25–0:50
做第二套系統：意見收集頁，讓訪客填資料進來
接著做第二套系統：意見收集頁 訪客可以填姓名和意見 送出後寫入意見收集的 Sheet（跟飲料訂單分開） 網頁下方顯示已提交的意見列表
AI 會在原本的 doGet 加 doPost
觀察 doPost 怎麼接收表單、怎麼 appendRow 寫入 Sheet
完成這一步的同學請舉手，等大家都到位再繼續
把 AI 更新後的程式碼貼回 GAS 存檔
不要點成「新增部署」，網址會變掉
確認資料真的寫進去了
意見送出後意見 Sheet 多一筆，網址跟 R1 相同 = 完成
卡住了 — 舉手，或先檢查是不是點成了「新增部署」
在自己手機上填寫表單，送出
看到 A 的意見出現在列表中
只有前端（用餐區）
資料存在瀏覽器裡
關掉就沒了
前端（網頁）+ 後端（GAS + Sheet）
資料存在雲端
不同裝置都能存取
前端 = 用餐區（訪客看到的畫面）
後端 = 廚房 + 倉庫（GAS 處理邏輯 + Sheet 存資料）
客人（訪客）在用餐區（網頁）點菜（填表單）
廚房（GAS）接單處理 → 存進倉庫（Sheet）
加上輸入驗證 姓名和意見都不能空白 送出後顯示「已提交」確認訊息 按鈕送出後變灰避免重複送
對外服務一定會遇到空白提交和重複送，會留下垃圾資料
現在的網頁：能看、能填、能存、有驗證
但資料進來之後，要靠人去看 — 能不能讓 AI 自動分析
下一輪：串接 AI API，讓收到的意見自動被分析
ROUND 3 · 0:50–1:15
Groq + Llama — 免費、不需信用卡、速度快
用 Google
帳號登入
免綁卡 / 免付費
專門做
推理的硬體
回應快數倍
以 console limits 為準
課堂選當天
額度足夠的模型
console.groq.com → 用 Google 登入 → API Keys → Create Key
用 Python / Node.js / 自己的伺服器
免費額度可用
不用綁卡也能跑
GAS 屬於 Google Workspace 服務
從 Workspace 呼叫外部 API
必須啟用 GCP Billing 才能跑
Google 給「綁卡送 $300 試用額度」聽起來划算
但 $300 用完會自動扣款，新手很容易忘了關掉
課堂用 Groq 完全免費不用綁卡，沒有這個風險
console.groq.com →
Google 登入
取個名字（例如 vibe-coding-class）
視窗關掉就看不到了，先存到記事本
完成這一步的同學請舉手，等大家都到位再繼續
升級系統：新意見送出時呼叫 Groq API 優先用當天 console 顯示可用且額度足夠的模型 讓 AI 自動分類成正面 / 中性 / 負面 分類結果寫回 Sheet 同一列的下一欄
有主動提醒「放 Script Properties」= 好 AI
直接寫死在程式碼 = 你要會自己看出問題
視窗關掉就看不到了，先存到記事本
順便觀察 AI 把你的 Key 放在哪裡
管理部署 → 新版本 → 部署
Sheet 的分類欄自動出現 正面 / 中性 / 負面 = 完成
卡住了 — 舉手，或把 GAS 執行記錄的錯誤整段貼給 AI
觸發 → 處理 → 儲存 → 展示
四元素已經到齊三個，只差「通知」
三個元素到齊 — 最後一個「通知」在下一輪補上
客戶留言進來
→ AI 自動分類
退款 / 技術 / 建議
→ 分到不同頁籤
外國客戶留言
→ AI 翻譯成中文
→ 寫回 Sheet
→ 團隊即時處理
同樣的架構（表單 + AI + Sheet），套到不同場景
差異只在 AI 的指令和 Sheet 的欄位設計
ROUND 4 · 通知層 · 第一部分
為飲料點餐系統加上「事件 → 行動」
M1-3 你做出了能收資料的系統，但⋯
學員填了表單 → 寫進 Sheet
你不知道有新資料
要主動去開 Sheet 才看得到
學員填了表單 → 寫進 Sheet
系統主動推訊息給你
email / TG / Line 即時收到
事件驅動是系統的基本架構：有事情發生 → 觸發行動
三個理由為什麼從 email 入手
GAS 內建 MailApp
不用申請帳號
不用 Bot Token
免費帳號 100 封
付費帳號 1500 封
學習用足夠
不像 TG / Line
需要安裝特定 app
email 跨平台
先掌握 email 通知 → R5 再升級到 TG / Line 即時通知
什麼時候該寄信？兩種主流做法
每筆資料進來都寄
即時
適合：低頻、緊急
例：預約、客訴
固定時間彙整寄
不打擾
適合：高頻彙整
例：飲料訂單統計
每日報名統計
飲料點餐系統用定時觸發合理（不會每杯飲料都響你手機）
但學會兩種，未來其他需求可以選用
請幫我加上「每次有新訂單就寄 email 給我」的功能 需求： - 表單送出後（doPost）觸發 - 寄到我的 email：[email protected] - 內容：包含時間、姓名、品項、所有欄位 - 主旨：[新訂單] 姓名 - 品項
不用看程式碼，AI 會說明「在資料寫進 Sheet 之後，呼叫 MailApp 寄信」。
重新部署 → 自己填一筆測試 → 看 email 收到沒
請幫我加上「每天下午 5 點寄訂單彙整 email」 需求： - 讀 Sheet 今天所有訂單 - 統計品項數量、總金額 - 寄到我的 email - 用 GAS 觸發器設定每天 17:00 執行
1. 寫一個 sendDailySummary() 函式（讀 Sheet、彙整、寄信）
2. 引導你在 GAS Editor 設定時間驅動觸發器（左側鬧鐘 icon）
在 GAS Editor 左側鬧鐘 icon → 新增觸發器
設定完成後，每天 17:00 自動跑 sendDailySummary
重新部署後自己填一筆，看信箱收到沒
AI 會寫出 sendDailySummary 函式
左側鬧鐘圖示 → 新增觸發器 → 日計時器
信箱收到第一封通知信 + 觸發器清單多一筆 = 完成
卡住了 — 舉手，或看 GAS 左側「執行記錄」找紅字貼給 AI
學員填單 → 你立刻收到 email
優點：第一時間知道
缺點：訂單多時 email 爆量
每天 17:00 收到彙整 email
優點：不打擾
缺點：不適合即時性需求
建議用每日彙整。每杯飲料都寄 email 太擾人，下班前一次彙整剛好決定明天訂貨量
email 是最低門檻的通知方式
不用申請外部服務、跨平台、額度夠用
觸發條件兩種：每次（即時）vs 定時（彙整）
下一輪：TG 即時通知裝上意見收集系統 + Token 保護
ROUND 5 · 通知層 · 第二部分
把即時推送裝上意見收集系統
在串 TG Bot 之前，先建立 Token 安全的觀念
const TOKEN = "8434:AAH...";
→ 程式碼分享給別人就洩漏
→ git push 到 GitHub 也洩漏
→ 別人能用你的 Bot
PropertiesService
.getScriptProperties()
.getProperty('TG_TOKEN')
→ Token 跟程式碼分離
→ 程式碼可分享，Token 不洩漏
→ 不同環境用不同 Token
這個觀念是所有 API Key 的基本紀律——任何服務的 Token 都用同一套方法保護
捲到最下面「指令碼屬性」section
屬性名稱：TG_TOKEN / 值：你的 Bot Token
再新增一個：TG_CHAT_ID / 值：課前準備用 getUpdates 拿到的那串數字
儲存後關掉設定頁，回到程式碼編輯器
儲存後 Token 在 Google 後台加密保存，不會出現在程式碼裡
請幫我加上「每筆新意見即時推送到 Telegram」的功能 需求： - 用 Script Properties 讀 TG_TOKEN 跟 TG_CHAT_ID - 意見送出後（doPost）觸發 - 訊息格式：[新意見] 姓名 - AI 分類 - 時間 - 不要把 Token 寫死在程式碼裡
關鍵點：所有 Token 透過 PropertiesService 讀取，程式碼裡看不到 Token。
重新部署 → 自己測一筆 → 看 Telegram 是否收到推送
課前準備拿到的兩個值，這時候派上用場
存檔後管理部署 → 新版本 → 部署
順便打開程式碼確認裡面找不到 Token
TG 收到推播，且程式碼裡看不到 Token = 完成
卡住了 — 舉手，或對照後面「R5 常見問題」那頁逐項檢查
課前準備有申請 Line@ 的同學適用
API endpoint:api.telegram.org/bot{TOKEN}/sendMessage
參數：chat_id + text
API endpoint:api.line.me/v2/bot/message/push
參數：to (User ID) + messages 陣列
兩個 API 都用 UrlFetchApp 呼叫
Token 都用 Script Properties 存
跟 AI 對話時把需求改成 Line@ 即可，邏輯相同
意見收集系統端到端驗證：從填意見到 TG 收到推播
1. Sheet 有新一筆資料
2. AI 分類欄位有寫入
3. 手機 TG 收到通知（且訊息格式正確）
4. 程式碼裡看不到 Token（去 Script Properties 才看得到）
這是工業界叫 webhook / event-driven 的架構雛形
這個架構是所有「即時自動化」系統的骨架。
從電商出貨通知、IoT 設備警報、銀行轉帳提醒，到你公司內部的審核流程 — 都是這個骨架
| 狀況 | 原因 / 解法 |
|---|---|
| TG 沒收到通知 | 檢查 Script Properties 的 TG_TOKEN / TG_CHAT_ID 是否正確、有沒有 typo |
| Sheet 有寫入但 TG 沒推 | 看 GAS 執行記錄（左側）→ UrlFetchApp 是否報錯 |
| Token 換新不生效 | Script Properties 改了不用重新部署，但 doPost 改了要重新部署 |
| Chat ID 忘了存 | 跟 Bot 再傳一句話 → 重開 getUpdates 找 "chat":{"id"}（課前準備的做法） |
| 想多人接收通知 | 把 TG_CHAT_ID 改成群組 ID 建 group → 加 Bot 進群 → 群裡發一句話 getUpdates 找群組 id（通常是負數） |
email 適合彙整，TG / Line 適合即時 — 從工作場景選用
Script Properties 是這堂課最重要的安全觀念之一 — 任何 Token / API Key / 密碼都該用同樣方式保護
ROUND 6 · DEMO 互測
技術相同 差異在「你解決了什麼問題」
大家有彼此的意見收集頁網址
每個人去填其他同學的網頁
系統自動在跑 — 你寫的服務真的有人在用
收到至少 3 筆通知的同學請舉手
留言 → AI 分類 → TG 通知客服
掃庫存 → AI 判斷不足 → TG 推採購
18:00 觸發 → AI 摘要 → TG 推主管
回覆累積 → AI 歸納主題 → TG 推給你
技術都一樣（網頁 + AI + Sheet + 通知），差別只在「你解決什麼問題」
從一張飲料菜單開始
到點餐 + 意見收集兩套自動化服務
這就是 Stage 1 的終點
用這六個維度評估自己和同學的作品
差距來自哪裡 — 指令品質、架構理解、還是除錯速度
收尾 · STAGE 1 回顧
四堂課的升級線，和下一階段的方向
從「完全不會寫程式」到「有一個公開的自動化服務」
中間只靠 AI 聊天 + 正確的操作流程
Stage 1 用到的四種「記住設定」的方式
ChatGPT 的
自定義指令
每次自動帶入
Gemini 的
系統指令
角色+限制+格式
GAS 的安全儲存
API Key / Token
Claude.ai 的
專案設定
跨對話知識
| # | 常見問題 | 學到什麼 |
|---|---|---|
| 1 | 部署權限選錯 | 權限管理 |
| 2 | 新增部署 vs 管理部署搞混 | 網址不變要選「管理部署」 |
| 3 | 沒驗證收到空白提交 | 對外服務要防呆 |
| 4 | API Key 寫在程式碼裡 | Script Properties |
| 5 | TG Token 貼錯 | 整段執行記錄貼給 AI |
不只學了什麼，是想法怎麼變了
從「我是服務的使用者」→ 我能組裝自己的服務
從「零基礎」到「有公開服務」
Stage 1 的核心：用 AI 做事，不用自己寫程式
別人的 AI
別人的伺服器
別人的通訊管道
平台規則改了，你就被影響
能不能有「自己的地盤」
不再依賴 GAS 的超長網址
.env / Secrets — API Key 的正式管理方式
從瀏覽器操作進入開發環境
Stage 1 = 用 AI → Stage 2 = 串 AI → Stage 3 = 造 AI
把今天的意見收集系統改成你工作中的實際場景
例如：客戶回饋收集 / 內部建議箱 / 日報通知
記錄你改了什麼、遇到什麼問題、怎麼解決
這些素材在 Stage 2 會用到
下一階段 — Stage 2
Stage 2：用 GitHub 建你自己的網站
學會安全管理，用 IDE 做更強的工具
M1-4 / Stage 1 完成