這個系列本身，就是三輪提問的產物

九月十一日晚上，我打開一個對話，說：「我想報鐵人賽，寫 30 篇教新同事用 AI coding，標題想叫『轉生到 AI 世界開始獨自進化』。」

AI 接著問了幾個問題：

• 這個系列怎樣才算成功？
• 讀者開始前已經會什麼？讀完後要能完成哪個具體任務？
• 公司案例能公開到什麼程度？
• 標題強調「獨自進化」，內容卻在教協作，兩者如何對應？

三輪提問、十八個決策，加上查資料與整理，整個過程花了一個多小時。AI 查了報名期限、盤點現成素材，也查看載體專案的 Git 狀態。結束時，我手上除了 30 篇標題，還有報名敘述和存稿時程。

如果直接請它列標題，我大概也能很快拿到一份清單。但哪些篇有素材、哪些要先做實驗、讀者最後要學會什麼，仍然沒有答案。

這就是動手前先釐清的價值：讓後面的工作有方向，也有邊界。

動手前，先準備三件事

在 Day 2 的工作流裡，AI 產生程式碼之前，還有需求分析、切 ticket 和規劃 PR。這些步驟不會增加功能，卻會決定接下來的功能是否值得做、要做到哪裡，以及怎麼審查。

今天把它整理成三步：釐清需求 → 用 ticket 寫出完成條件 → 規劃 PR 拆分。 這裡的「計畫」先處理交付範圍；詳細的實作步驟，會在範圍確定後再展開。

第一步：釐清需求，讓 AI 把缺口問出來

我會用 grill，也就是讓 AI 針對需求持續追問的方式。你先提供想法，AI 找出還沒決定的地方，每題附上推薦答案和理由；你回答後，它再往下一層問。

為了避免越問越不敢動手，我給這個流程三個限制：

• 同一個功能做一輪完整釐清，結論要保存。 後續有新資訊時，只重開受影響的決策，不必每次從頭討論。
• 以三輪提問或約三十分鐘為收斂目標。 時間到了，就整理剩下的問題。查資料與撰寫文件可以另計；開頭那次企劃，連同這些工作花了一個多小時。
• 讓 AI 查事實，由你確認取捨。 Repo 裡有沒有某個檔案，可以請 AI 查；系列要以新人教材還是個人品牌為主，則需要你決定。

我也用「七日法則」提醒自己：一個想法出現後，七天內至少整理成一份設計文件，寫下問題、對象和範圍。否則很容易一直停在「有空再做」。

收斂不代表所有問題都已有答案。剩下的問題要區分：哪些可以延後，哪些會影響核心方向、必須先解決。

第二步：把需求寫成 ticket，定義什麼算完成

釐清後，用一張 ticket 記錄這次要交付的工作。最重要的是讓人看得出來：做完後，使用者能多做到什麼？如何驗收？

如果只寫「在 Service 加一個 method、在 ViewModel 呼叫、在 View 顯示」，雖然有了操作順序，仍然不知道顯示結果怎樣才算正確。

以 Day 4 的倒數文字為例：

## 目標

使用者能在下一場任務卡片上，看見距離開始還有多久。

## 完成條件

- [ ] 不足 60 分鐘顯示「還有 N 分鐘」；60 分鐘以上顯示「還有 N 小時 M 分鐘」。
- [ ] 任務已開始時不顯示。
- [ ] 有對應的單元測試，能抓到刻意引入的相關邏輯錯誤。
- [ ] 在真機上確認字級與措辭，掏出手機後能在三秒內讀懂。

## 不在範圍

- 通知內容不改。
- Widget 不改；需要時另開 ticket。

## 開放問題

- 跨日任務是否要改用「天」顯示？本次先沿用小時，留待後續評估。

「不在範圍」和完成條件一樣重要。倒數文字可能也適合出現在 Widget，但這次是否一起做，應該在開始前講清楚，避免 AI 順手擴大修改。

Ticket 可以記錄必要的技術限制；細部怎麼實作，則留到實作計畫再安排。

第三步：先決定 PR 怎麼拆，再交給 AI 動手

一張 ticket 可以對應一個或多個 PR（Pull Request，也就是供團隊審查、合併的變更）。如果做完才拆，邏輯、畫面與測試往往已經交錯在一起，整理起來更費工。

拆分時，把完成條件分組，逐組檢查：按照預定順序合併後，即使後面的工作還沒完成，主線是否仍能正常運作？

倒數文字可以拆成：

• PR 1：在 MissionTimeline 加入時間計算邏輯與測試。尚未接上畫面，既有功能仍可運作。
• PR 2：讓 TaskTimelineView 使用這段邏輯，顯示倒數文字。這個 PR 依賴 PR 1，必須在它之後合併。

如果整個修改本來就很小，也可以合成一個 PR。我的習慣是把每個 PR 控制在約 5–8 個檔案內；這是提醒自己檢查範圍的門檻，不是必須湊足的數量。真正的目標是讓每份變更有清楚的目的，能被獨立檢查。

今天要做的一件事：完成一張可以開工的 ticket

挑一個你真的想做的小功能，先完成這三步，暫時不寫程式碼。

第一步：請 AI 釐清需求。

我想做：<一句話>。

請用提問幫我釐清：
- 每輪問目前能回答、不依賴其他未定事項的關鍵問題。
- 每題編號，附推薦答案和理由；我回答後再問下一層。
- 可從專案或文件查到的事實，先查再問。查不到的請明確標示。
- 三輪內整理結論；未解問題分成「阻擋開工」和「可以延後」。

第二步：將結論整理成 ticket。 使用上面的目標、完成條件、範圍與開放問題格式。逐條檢查完成條件是否能驗證，例如「畫面好看」太模糊，「真機上三秒內能讀懂任務時間」就比較具體。

第三步：請 AI 提出 PR 拆分。 每個 PR 列出預計修改的檔案、依賴關係，以及合併後為什麼不會破壞既有功能。範圍超過預定門檻，就先討論是否需要拆小。

把決策、ticket 和拆分結果存進 docs/，可以分檔，也可以放在同一份文件。若你已經做完釐清，後續練習直接沿用這份成果，補缺口即可。

新人最常在這一步犯的錯

跳過釐清，覺得做錯再改就好。 AI 改得快，仍需要你重新閱讀、審查與驗證。先問清楚，能減少不必要的來回。

一直釐清，卻不保存結論。 每次開新對話又從頭問，決策也跟著反覆。記下結論，有新資訊再局部調整。

只有實作步驟，沒有完成條件。 「加一個 method」描述了動作，卻沒有定義使用者會得到什麼結果。

沒有寫不做什麼。 相鄰的功能很容易一起被改動。明確寫出本次範圍，才能判斷哪些改動多做了。

所有開放問題都留到實作時再解。 不影響本次交付的細節可以延後；會改變資料來源、使用者或核心流程的問題，應先處理。

本篇可帶走的檔案

第一份是 grill-prompt.md：

我想做：<一句話>。

請協助釐清：
- 每輪只問目前前提足夠的關鍵問題。
- 每題編號，附推薦答案與理由。
- 先查能取得的事實；查不到就標示未知，不自行推定。
- 三輪內收斂；未解問題分成「阻擋開工」與「可以延後」。
- 輸出決策清單、開放問題，以及一段 50 字內的需求描述。

第二份是 ticket-template.md：

## 目標

<使用者能做到什麼，一句話>

## 完成條件

- [ ] <可驗證的行為>
- [ ] <相關測試與驗證方式>
- [ ] <需要在真機或實際環境確認的事>

## 不在範圍

- <本次不處理的相鄰功能>

## 開放問題

- 阻擋開工：
- 可以延後：<原因與暫定處理方式>

## PR 拆分

- PR 1：<範圍、預計檔案、驗證方式>
- PR 2：<範圍、預計檔案、驗證方式、依賴哪個 PR>
- 各 PR 合併後，主線仍可正常運作的理由：

第一幕到這裡，你手上應該有專案規則、可重複使用的 SOP，以及一張範圍清楚的 ticket。這些準備會讓 AI 動手時有依據，也讓你知道該怎麼驗收。