前幾天，我們已經完成：
接下來要開始真正製作網站。
對沒有資訊背景的同學來說，最困難的地方通常不是「不會使用 AI」，而是：
今天要介紹的 Vibe Coding，不是把所有程式交給 AI 後完全不檢查，而是：
使用 AI 加速產生程式，再用規格、測試與人工驗收控制品質。
Vibe Coding 通常指使用自然語言告訴 AI 想做什麼，再由 AI 產生程式，接著執行、觀察結果並要求 AI 修改。
最簡單的流程是：
描述需求
-> AI 產生程式
-> 執行程式
-> 發現問題
-> 回報錯誤
-> AI 修改
這種方式很適合：
但如果完全不看程式，也不進行測試，可能產生：
因此，今天採用的是「可驗收的 Vibe Coding」。
請在下方位置插入今天的流程圖。
圖 1：Vibe Coding 的五個階段。先定義需求與驗收條件，再請 AI 產生小範圍修改，執行測試並保存證據，最後決定接受或重新修改。
圖片替代文字：
Vibe Coding 從需求規格開始，經過提示、程式產生、執行測試與證據記錄，最後進入接受或修改的循環。
製作方式：自行繪製 SVG 並輸出為 1800 × 1100 PNG，未使用來源不明的網路圖片。
流程可以整理成：
定義規格
-> 撰寫提示
-> 產生小範圍修改
-> 執行與測試
-> 接受或重新修改
AI 不知道你的專案規則，除非你主動告訴它。
開始寫程式前，先準備以下資料：
| 資料 | 用途 |
|---|---|
| 專題目標 | 說明要解決的問題 |
| 目標使用者 | 避免 AI 做出不適合的介面 |
| 使用者流程 | 說明使用者會怎麼操作 |
| 資料字典 | 固定欄位名稱與型態 |
| API 契約 | 固定前後端交換格式 |
| 技術限制 | 說明使用的框架與工具 |
| 驗收條件 | 定義什麼叫做完成 |
| 不可做的事情 | 避免 AI 擴大範圍 |
以我們的餐點推薦專題為例：
專題目標：
協助學生根據預算、地點、時間與飲食限制尋找餐點。
目標使用者：
沒有資訊背景的一般大學生。
目前技術：
React 網站、後端 API、JSON 資料、RAG 查詢。
本次只做：
建立查詢表單與結果卡片。
本次不做：
登入、付款、推播、地圖導航與管理員後台。
完成條件：
使用者可以輸入條件，送出查詢，看到推薦項目、推薦理由與來源。
這段內容可以放在每次對話的開頭，讓 AI 保持相同方向。
初學者常直接輸入：
幫我做一個 AI 餐點推薦網站。
這個要求太模糊，AI 可能自行決定：
比較好的方式是先要求 AI 產生實作計畫：
你是專題開發助教。
請根據以下資料，規劃一個最小可行版本。
專題目標：
協助學生依照預算、地點、時間與飲食限制尋找餐點。
目前已有：
- React 前端
- 後端查詢 API
- places_v1.0 JSON 資料
- API 回應包含 status、answer、recommendations、sources
本次只做：
1. 查詢表單
2. 載入狀態
3. 成功結果卡片
4. 沒有結果畫面
5. 錯誤訊息畫面
請先不要寫程式。
請輸出：
- 建議修改的檔案
- 每個檔案的責任
- 元件之間的資料流
- API 請求格式
- API 回應如何顯示
- 可能的錯誤
- 驗收條件
如果資訊不足，請列出需要確認的項目。
先取得計畫，再決定是否讓 AI 寫程式。
不要一次要求：
幫我建立網站、串 API、加登入、做 RAG、加入地圖、製作管理後台，還要部署。
這樣很難知道錯誤來自哪裡。
建議按照以下順序：
每次只修改一個主要功能，才能知道哪一次變更造成問題。
可以使用以下提示詞模板：
【任務】
請在目前專案中新增查詢表單。
【檔案範圍】
只允許修改：
- src/components/SearchForm.jsx
- src/styles/search-form.css
【輸入欄位】
- question：文字
- budget：數字
- location：選單
- diet_tags：多選
【限制】
- 不修改 API 契約。
- 不新增套件。
- 不修改其他頁面。
- 不處理登入功能。
- 不將 API 金鑰放在前端。
【使用者行為】
1. 使用者填寫問題。
2. 使用者選擇預算與地點。
3. 欄位不完整時顯示提示。
4. 欄位完整時呼叫父元件提供的 onSubmit。
【驗收條件】
- 空白問題不能送出。
- 預算欄位只能接受合理數字。
- 送出時會呼叫 onSubmit。
- 表單在手機寬度仍可使用。
- 不影響其他頁面。
【輸出方式】
1. 先說明修改計畫。
2. 再列出修改的檔案。
3. 最後提供測試方式。
這種提示詞的重點是指定：
AI 產生程式後，不要只問：
可以嗎？
改成：
請說明這次修改：
1. 修改了哪些檔案？
2. 每個檔案增加了什麼？
3. 哪些程式負責欄位驗證？
4. 哪些程式負責送出查詢？
5. 哪些地方可能失敗？
6. 如何手動測試？
7. 哪些部分仍然需要人工確認？
如果 AI 無法清楚說明修改內容，代表團隊也可能還不了解這段程式。
一個按鈕看起來能使用，不代表功能完成。
以查詢表單為例，要確認：
輸入問題
-> 前端取得值
-> 前端檢查格式
-> 建立 API 請求
-> 後端接收資料
-> 執行資料檢索
-> AI 產生回答
-> 回傳固定格式
-> 前端解析結果
-> 顯示回答與來源
每一個階段都可能出錯。
可以請 AI 產生資料流檢查表：
請根據目前專案，建立一份資料流檢查表。
欄位包含：
- 階段
- 輸入資料
- 輸出資料
- 負責檔案
- 可能錯誤
- 測試方式
- 目前狀態
請不要假設沒有提供的功能已經完成。
AI 很適合協助建立測試案例，但測試結果仍要由人執行。
提示詞範例：
請根據以下驗收條件建立測試案例。
功能：
使用者輸入預算與飲食限制，取得餐點推薦。
驗收條件：
- 預算欄位不可為空白。
- 飲食限制可以複選。
- 送出後會顯示載入狀態。
- 成功時顯示推薦理由與來源。
- 沒有結果時顯示調整條件的建議。
- API 失敗時顯示可理解的錯誤訊息。
請輸出：
- 測試編號
- 前置條件
- 操作步驟
- 預期結果
- 實際結果
- 是否通過
- 證據截圖或紀錄
測試表可以長這樣：
| 測試編號 | 情境 | 預期結果 | 實際結果 | 狀態 |
|---|---|---|---|---|
| T01 | 正常輸入 | 顯示推薦結果 | 待測試 | 待測試 |
| T02 | 問題空白 | 顯示欄位提示 | 待測試 | 待測試 |
| T03 | 沒有符合項目 | 顯示調整條件建議 | 待測試 | 待測試 |
| T04 | API 暫時失效 | 顯示錯誤訊息 | 待測試 | 待測試 |
| T05 | 手機畫面 | 表單與結果可操作 | 待測試 | 待測試 |
AI 可能一次修改很多內容。
在讓 AI 修改前，建議：
即使不熟悉 Git，也可以至少保留：
before_day10/
after_day10/
更好的做法是每次只完成一個小功能：
feature-search-form
feature-loading-state
feature-result-card
feature-source-card
feature-error-state
如果修改後網站壞掉，就能回到上一個可用版本。
只說「幫我修網站」時，AI 不知道：
應該提供：
如果 AI 修改十幾個檔案，最後出錯時很難追蹤。
請明確限制：
本次只允許修改兩個檔案。
如果需要修改其他檔案，請先列出原因並等待下一步指示。
AI 說「已完成」不代表真的完成。
必須自己確認：
漂亮的介面可能只是靜態假資料。
請打開瀏覽器開發者工具或後端紀錄，確認：
如果沒有明確限制，AI 可能不斷新增：
這些功能不一定不好，但可能讓八週專題失去焦點。
可以明確告訴 AI：
目前只完成核心流程。
任何額外功能請放入「未來可擴充」，不要在本次修改中實作。
| 驗收項目 | 合格標準 |
|---|---|
| 範圍清楚 | 本次只完成一個小功能 |
| 上下文完整 | AI 已取得必要的需求與檔案 |
| 修改可追蹤 | 知道哪些檔案被修改 |
| API 一致 | 沒有任意改變資料契約 |
| 可實際執行 | 網站能啟動並完成主要流程 |
| 錯誤可理解 | 使用者看得懂錯誤訊息 |
| 測試存在 | 至少有正常與失敗案例 |
| 個資安全 | 沒有把敏感資料送給不必要的服務 |
| 金鑰安全 | 秘密金鑰只放在後端 |
| 版本可回復 | 修改前後都有保存 |
| 人工確認 | 團隊看過主要修改內容 |
| Demo 可展示 | 五分鐘內能完成一次完整流程 |
選擇一個小功能，例如：
完成以下內容：
功能名稱：
目標使用者：
使用情境：
輸入資料：
輸出結果：
不包含的功能：
驗收條件：
不要直接要求 AI 寫完整網站。
先取得：
限制 AI：
至少包含：
保存：
Vibe Coding 的價值是加速開發，不是取消工程思考。
可靠的流程是：
需求規格
-> 小範圍提示
-> AI 產生修改
-> 查看差異
-> 執行測試
-> 保存證據
-> 接受或重新修改
AI 可以幫忙：
但團隊仍然要負責：
好的 AI 專題不是「AI 寫了多少程式」，而是：
團隊能不能證明程式解決了正確問題，而且每個主要功能都可以被驗收。
Day 11，我們將進入自動化流程，學習如何讓資料整理、測試、報告產生與通知工作減少重複操作。
GitHub Docs｜Prompt engineering for GitHub Copilot Chat
https://docs.github.com/en/copilot/concepts/prompting/prompt-engineering
GitHub Docs｜Best practices for using GitHub Copilot
https://docs.github.com/en/copilot/get-started/best-practices
GitHub Docs｜Prompt files
https://docs.github.com/en/copilot/tutorials/customization-library/prompt-files
GitHub Docs｜Research, plan, and iterate on code changes
https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/research-plan-iterate
Martin Fowler｜Vibe Coding
https://martinfowler.com/bliki/VibeCoding.html
以上資料於 2026 年 9 月 23 日查閱。各 AI 工具的功能、方案、免費額度與價格可能變動，使用前請查看官方最新文件。
狀態：等待審核。
審核通過後，請上傳 Day 10 PNG、插入指定位置、預覽版面，再發布文章。
今天是 Day 11，以下為完整審核稿。
標題欄：
Day 11｜讓專題每天自己跑：用 Apps Script 建立資料、測試與通知流程
專業流程圖：
:chatgpt-content-reference{index="3"}下載 Day 11 高解析度流程圖
圖片已輸出為 1800 × 1100 PNG，並以原始尺寸完成視覺檢查，標題、節點、箭頭與邊界沒有截斷或重疊。
前幾天，我們已經完成：
- 釐清使用者問題
- 設計 MVP
- 建立資料契約
- 整理 CSV 與 JSON
- 讓 AI 根據專題資料回答
- 使用 Vibe Coding 產生網站與功能
但是，專題進入實作後，團隊通常會遇到另一個問題：
每天都要重複做同樣的事情。
例如：
1. 開啟 Google Sheet。
2. 檢查今天有沒有新資料。
3. 找出缺少來源的列。
4. 檢查價格與距離格式。
5. 匯出 CSV 和 JSON。
6. 執行網站測試。
7. 整理錯誤數量。
8. 通知其他組員。
9. 人工確認後才更新展示網站。
第一次做可能只需要 20 分鐘，但連續做兩週後，很容易發生：
- 忘記執行檢查
- 不小心使用舊版本資料
- 錯誤資料直接進入網站
- 測試失敗卻沒有人知道
- 不同組員各自整理出不同結果
今天要建立的是一條簡單、免費優先，而且可以被團隊理解的自動化流程：
```text
資料輸入
→ 自動觸發
→ 格式與邏輯檢查
→ 匯出版本資料
→ 執行測試
→ 產生報告
→ 人工審核
→ 再發布
重點不是讓系統完全不需要人，而是把重複工作交給工具，把重要決策留給人。
自動化適合處理：
自動化不適合直接決定：
因此，專題應採用以下原則：
機器自動處理
人類審核結果
不要一開始就設計成：
資料進來
→ AI 判斷
→ 自動發布
比較安全的流程是：
資料進來
→ 自動檢查
→ 產生錯誤報告
→ 人工確認
→ 手動發布
今天使用兩個主要工具：
| 工具 | 在專題中負責的工作 | 適合原因 |
|---|---|---|
| Google Sheets | 保存和檢查團隊資料 | 大一生容易上手 |
| Google Apps Script | 執行自動化檢查與通知 | 可直接連接 Sheets |
| GitHub Actions | 執行網站測試與產生報告 | 適合保存程式碼與測試紀錄 |
Google Apps Script 支援編輯觸發、表單提交觸發及時間觸發。簡易觸發器有權限與執行時間限制；需要寄信或讀取其他檔案時，通常應使用可安裝觸發器。詳細限制應以官方文件為準。
GitHub Actions 可以依照程式碼變更或排程執行工作流程。免費額度、公開與私人儲存庫的限制可能調整，使用前要查看官方方案說明。
如果不想寫程式，也可以考慮：
但免費方案通常會有限制，例如每月執行次數、可使用的步驟數或連接器數量。初學者先用 Google Sheets 加 Apps Script，通常已經足夠完成第一版 MVP。
請將下載的 day11-automation-pipeline.png 上傳至 iThome，並插入在本段之後。
圖片說明：
AI 專題自動化流程。資料先由表單、試算表或開放資料進入系統，再由 Apps Script 觸發驗證，輸出具有版本的 CSV 與 JSON，接著執行測試並產生報告，最後經過人工審核才發布；發生錯誤時回到修正階段，不直接公開。
圖片替代文字：
從資料輸入、Apps Script 觸發、資料驗證、版本化匯出、測試報告到人工審核的 AI 專題自動化流程圖。
製作方式：
依據 Google Apps Script 觸發器、資料驗證與 GitHub Actions 工作流程概念，自行繪製 SVG 後輸出為 1800 × 1100 PNG。未使用來源不明的網路圖片。
在建立自動化前，先寫清楚以下內容：
| 欄位 | 要回答的問題 |
|---|---|
| 觸發條件 | 什麼時候開始執行？ |
| 輸入資料 | 要讀取哪些資料？ |
| 處理規則 | 系統要做哪些檢查？ |
| 輸出結果 | 產生什麼檔案或報告？ |
| 失敗處理 | 發生錯誤時要怎麼辦？ |
以校園餐點推薦專題為例：
觸發條件：
每天晚上 8 點執行，或有人提交新資料時執行。
輸入資料：
Google Sheet 中的餐廳、價格、飲食標籤與來源欄位。
處理規則：
檢查必填欄位、價格範圍、分類值、來源網址及查證日期。
輸出結果：
有效資料、待修正資料、錯誤摘要及資料版本。
失敗處理：
保留錯誤資料，不刪除；產生報告並通知負責人。
人工審核：
確認錯誤是否已修正，再決定是否更新網站。
如果這五個欄位說不清楚，就不應該急著寫自動化程式。
建立一個名為 places 的工作表，第一列是固定欄位：
place_id
name
category
price_min
price_max
currency
diet_tags
source_url
verified_at
verification_status
範例資料：
| place_id | name | category | price_min | price_max | currency | diet_tags | source_url | verified_at | verification_status |
|---|---|---|---|---|---|---|---|---|---|
| P0001 | 校園素食坊 | restaurant | 70 | 110 | TWD | vegetarian | https://example.edu.tw/food | 2026-09-24 | verified |
| P0002 | 夜間便利店 | convenience_store | 45 | 120 | TWD | none | https://example.edu.tw/store | 2026-09-24 | verified |
建議另外建立兩個工作表：
places
quarantine
run_log
用途如下：
| 工作表 | 用途 |
|---|---|
| places | 正式資料 |
| quarantine | 驗證失敗或等待人工確認的資料 |
| run_log | 每次執行時間、有效筆數與錯誤數量 |
不要直接把錯誤資料刪掉，否則團隊無法知道問題是什麼，也無法追蹤清理過程。
在 Google Sheet 中選擇：
擴充功能
→ Apps Script
建立以下範例程式：
function validatePlaces() {
const workbook = SpreadsheetApp.getActiveSpreadsheet();
const sourceSheet = workbook.getSheetByName("places");
const quarantineSheet = workbook.getSheetByName("quarantine");
const values = sourceSheet.getDataRange().getValues();
const headers = values.shift();
const columnIndex = {};
headers.forEach((header, index) => {
columnIndex[header] = index;
});
const errors = [];
values.forEach((row, index) => {
const sheetRow = index + 2;
const placeId = row[columnIndex.place_id];
const name = row[columnIndex.name];
const category = row[columnIndex.category];
const priceMin = row[columnIndex.price_min];
const priceMax = row[columnIndex.price_max];
const sourceUrl = row[columnIndex.source_url];
if (!placeId) {
errors.push([sheetRow, "place_id", "缺少資料 ID"]);
}
if (!name) {
errors.push([sheetRow, "name", "缺少名稱"]);
}
if (!["restaurant", "convenience_store", "campus_cafeteria"].includes(category)) {
errors.push([sheetRow, "category", "分類不在允許清單"]);
}
if (typeof priceMin !== "number" || typeof priceMax !== "number") {
errors.push([sheetRow, "price", "價格必須是數字"]);
}
if (priceMin < 0 || priceMax < priceMin) {
errors.push([sheetRow, "price", "價格範圍不合理"]);
}
if (!sourceUrl) {
errors.push([sheetRow, "source_url", "缺少來源網址"]);
}
});
if (quarantineSheet.getLastRow() > 1) {
quarantineSheet
.getRange(2, 1, quarantineSheet.getLastRow() - 1, 3)
.clearContent();
}
if (errors.length > 0) {
quarantineSheet
.getRange(2, 1, errors.length, 3)
.setValues(errors);
}
const logSheet = workbook.getSheetByName("run_log");
logSheet.appendRow([
new Date(),
values.length,
errors.length,
errors.length === 0 ? "PASS" : "REVIEW"
]);
}
這段程式做了幾件事：
places 工作表。quarantine。run_log。這不是完整的資料工程系統，但已經足以讓團隊理解自動化的基本概念。
在 Apps Script 編輯器中：
validatePlaces。quarantine。run_log 是否新增紀錄。先用手動方式測試的原因是：
請先準備幾筆刻意錯誤的資料：
P0010，缺少名稱
P0011，價格文字不是數字
P0012，分類寫成 food
P0013，缺少來源網址
P0014，最高價格小於最低價格
執行後，這些資料應該出現在 quarantine，而不是被刪除。
確認手動執行正確後，再設定排程：
validatePlaces。時間觸發器不一定會在指定分鐘精準執行，而是在設定的時間區間內執行。重要的是團隊知道：
這份資料每天會被檢查一次
而不是假設：
每天 20:00:00 一定完成
如果需要寄送通知，不能只使用沒有授權的簡易觸發器。Google 官方文件說明，寄送郵件等服務通常需要授權，因此應使用可安裝觸發器。
通知不要只寫：
資料檢查完成。
這樣組員不知道是否需要處理。
比較好的通知內容：
AI 專題資料檢查報告
執行時間：2026-09-24 20:05
資料版本：places_v1.2
總筆數：128
通過筆數：121
待確認筆數：7
狀態：需要人工處理
主要問題：
1. 缺少來源網址：3 筆
2. 價格格式錯誤：2 筆
3. 分類不在允許清單：1 筆
4. 價格範圍不合理：1 筆
下一步：
請先處理 quarantine 工作表，確認後再更新網站。
通知的目的不是讓訊息看起來自動化，而是讓組員能立即採取行動。
每次產生資料時，都應記錄：
dataset_version
schema_version
generated_at
record_count
valid_count
quarantine_count
例如：
{
"dataset_version": "places_v1.2",
"schema_version": "schema_v1.0",
"generated_at": "2026-09-24T20:05:00+08:00",
"record_count": 128,
"valid_count": 121,
"quarantine_count": 7
}
網站、AI 與簡報都應知道自己使用的是哪一版資料。
如果評審問：
你們網站上的餐點資料是哪一天整理的？
團隊就能回答：
網站使用 places_v1.2，產生時間是 2026 年 9 月 24 日，
共有 121 筆通過驗證的資料。
這會比回答「我們大概有整理過」專業很多。
如果網站程式碼放在 GitHub，可以讓每次更新程式碼時自動執行測試。
基本流程：
組員提交程式碼
→ GitHub Actions 啟動
→ 安裝必要套件
→ 執行測試
→ 產生結果
→ 顯示成功或失敗
適合測試的內容包括：
第一版不需要測試所有情況，先建立五個核心測試：
測試一：輸入預算 100 元，結果不可出現最高價格超過 100 的項目。
測試二：選擇 vegetarian，結果不可缺少 vegetarian 標籤。
測試三：輸入不存在的條件時，畫面必須顯示沒有符合結果。
測試四：每筆推薦結果都必須顯示來源。
測試五：資料檔案格式錯誤時，網站不可直接顯示空白畫面。
GitHub Actions 的工作流程檔案通常放在：
.github/workflows/
不必一開始就設計複雜流程。先做到：
程式碼更新後，自動執行五個測試
就已經能降低整合風險。
AI 適合協助：
可以使用以下提示詞：
你是一位協助大學生建立資料自動化流程的助教。
【專題流程】
使用者輸入預算、距離與飲食限制，
系統從標準化餐點資料中篩選候選項目，
再由 AI 比較候選項目並顯示推薦理由。
【資料規則】
- place_id 必須唯一
- category 只能使用 restaurant、convenience_store、campus_cafeteria
- price_min 與 price_max 必須是非負數
- price_max 不可小於 price_min
- source_url 必須存在
- verified_at 必須記錄查證日期
- verification_status 必須標示 verified、unknown 或 simulated
【任務】
請產生一份自動化驗證規格。
每一條規則請包含：
1. 規則編號
2. 檢查欄位
3. 條件
4. 錯誤訊息
5. 是否可以自動修正
6. 是否需要人工確認
7. 測試資料範例
規則：
- 不可猜測缺少的值。
- 不可把 unknown 改成 0。
- 不可直接刪除錯誤資料。
- 無法判斷時標記為需要人工確認。
另外可以要求 AI 產生測試案例：
請根據以下資料字典產生 12 筆測試資料。
要求：
- 6 筆必須通過驗證
- 6 筆必須失敗
- 失敗案例分別涵蓋缺少欄位、錯誤型態、錯誤分類、價格矛盾、缺少來源與日期格式錯誤
- 不要使用真實個人資料
- 請列出每筆資料預期的驗證結果與原因
AI 產生的規則仍要由團隊人工確認，不能直接當成正式資料標準。
如果四位組員都設定相同的時間觸發器，可能造成：
建議指定一位資料流程負責人建立正式觸發器，其他組員只查看結果。
最危險的流程是：
新資料進來
→ AI 整理
→ 自動更新公開網站
只要資料錯誤、來源過期或 AI 判斷失誤，錯誤內容就會直接公開。
建議保留人工關卡：
自動檢查
→ 產生報告
→ 人工審核
→ 更新正式資料
如果同一個排程重複執行，可能造成：
每次執行前可以檢查：
本次資料版本是否已經處理過？
本次輸入資料是否有唯一 ID？
本次通知是否已經發送？
這種設計稱為冪等性。初學者可以先理解成：
同一份資料重跑一次，不應該產生兩份結果。
Apps Script、GitHub Actions、Make 和 Zapier 都可能有執行次數、執行時間或儲存限制。
如果每天只檢查一次小型資料，通常不會遇到問題。但如果：
就可能快速消耗額度。
因此，排程設計要先問：
這個工作真的需要每分鐘執行嗎？
很多專題每天執行一次，或有人提交資料時執行一次，就已經足夠。
不要在程式碼中直接放入：
API_KEY
密碼
私人網址
服務帳號內容
也不要把含有密鑰的檔案提交到公開 GitHub 儲存庫。
應使用：
今天的流程若只使用 Google Sheet 內部資料，可以先不串接付費 API，降低資安風險與成本。
| 驗收項目 | 合格標準 |
|---|---|
| 觸發條件清楚 | 團隊知道何時會執行 |
| 輸入固定 | 使用明確的工作表與欄位 |
| 規則可重複 | 同一份資料重跑得到相同判斷 |
| 錯誤不遺失 | 錯誤資料進入 quarantine |
| 原始資料保留 | 沒有直接覆蓋 raw 資料 |
| 有執行紀錄 | run_log 記錄時間與結果 |
| 有版本資訊 | 資料集與 Schema 版本清楚 |
| 有測試案例 | 至少五個核心情境通過 |
| 有通知內容 | 通知包含數量、問題與下一步 |
| 有人工關卡 | 未經確認不會直接發布 |
| 沒有洩漏密鑰 | 程式碼中沒有 API Key 或密碼 |
| 額度可控 | 沒有不必要的高頻執行 |
請寫出：
輸入資料：
觸發條件：
驗證規則：
輸出結果：
錯誤處理：
人工審核：
places
quarantine
run_log
至少包含：
確認：
每個測試案例都要寫：
輸入：
預期結果：
實際結果：
是否通過：
今天的完成條件是：
團隊可以用同一份資料，重複執行自動化流程，得到一致結果；遇到錯誤時，系統會通知團隊，但不會自行發布。
AI 專題的自動化不是追求「完全不用人」，而是讓團隊把時間用在真正需要判斷的事情上。
一條可靠的自動化流程應包含：
固定輸入
→ 明確觸發
→ 可重複驗證
→ 保留錯誤資料
→ 記錄版本
→ 執行測試
→ 產生通知
→ 人工審核
Apps Script 適合處理：
GitHub Actions 適合處理：
AI 適合協助設計規則與整理結果，但不應該在沒有驗證的情況下，自行決定哪些資料可以公開。
真正成熟的專題，不是按一下按鈕就完成，而是即使流程失敗，團隊也能知道：
哪裡失敗
為什麼失敗
誰要處理
如何確認已修正
Day 12，我們將進一步認識 Agent：了解一般聊天、固定自動化流程與可使用工具的 AI Agent 有什麼差異，並設計一個不會任意操作的專題助理。
以上資料於 2026 年 9 月 24 日查閱。工具功能、執行額度、免費方案與介面可能更新，實際使用時請以官方最新文件為準。
iThome鐵人賽
看影片追技術
