• 菜雞行為：把做過很多次與會用工具當成已經累積經驗
• STAR 階段：A+R (Action + Result)
• 本篇定位：交代如何記錄選擇、驗證 AI 產出，並把結果轉成下一次可使用的判斷。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

Day 26｜我要累積的不是工具熟練，而是判斷與選擇理由，把任務定成建立判斷規則。本篇交代做法與結果，也收束九組故事。

先把三個候選比完，再寫成一頁契約

虛構案例最後一次登場。第一件事不是把需求丟給 AI，而是照 Day 26 的條件把三個候選比完：同步匯出撐不住目標資料量，先出局；離峰排程批次維運最省，但使用者要等到隔天；背景工作佇列導入成本最高，卻是唯一同時滿足資料量與等待時間的選項，退出成本也還付得起——要拆掉它，影響範圍就是那層佇列。落選理由連同當時的資料量假設一起寫進紀錄：資料量掉一個級距，結論可能反過來。選定之後才寫契約：輸入輸出格式、逾時上限、只成功一半要回報什麼、什麼算驗收通過。

生成之後：檢查、測試、Review，再決定收或退

接著讓 AI 依契約生成候選實作。順序固定：先對照契約找假設——它預設一次讀入全部資料、外部儲存一定成功；再把假設寫進驗收表，補大資料量與中途失敗的測試；最後逐段 Review。收或退的理由同步記進決策回顧。

[契約] --> [AI 生成] --> [檢查假設]
                             |
                             v
[接受或退回] <-- [Review] <-- [測試]

重點只有一個：產出進來是候選，出去才算交付。

留下來的是驗收紀錄，不是速度數字

結果都是質性的：第一版因忽略部分成功被退回，理由留在表上；第二版通過測試後，接受依據不再是「看起來沒問題」，而是逐項對過的契約。開發有沒有變快，我沒有量測。限制同樣要說：契約寫錯，AI 會把錯誤實作得很完整；驗收表擋不住沒想到的項目；安全與授權仍要人工檢查。

粉鳥工程筆記：AI 放大的是原本的工作方法

• 契約先於生成；沒有基準就沒有驗收。
• 收或退都要留下理由。
• 表格擋常見假設，擋不住沒想到的；責任在人。

今天可以帶走的練習

挑一段近期 AI 生成程式，花一小時，用《AI生成程式驗收表》找出至少三項未驗證假設，逐項補上驗證方式並實際執行。驗收方式：每項假設都有對應測試或檢查結果。用完即丟的腳本不必填表。

對應工具：《AI生成程式驗收表》。

# AI 生成程式驗收表

用途：檢查 AI 產出是否符合契約、錯誤處理與測試要求。
使用時機：AI 生成的程式要進正式程式庫、影響資料或使用者時。

| 項目 | 要求 | AI 輸出 | 驗證方式 | 結果 | 未解決風險 |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

提醒：只填會影響驗收的資訊；不放機密、個資與可辨識人物。

下一篇

九組菜雞行為走完一輪。Day 28｜九種學生味：我從哪裡開始變得比較可靠，回顧這二十七篇留下的能力邊界與證據。