AI 補完 issue，我只審兩次

我把想法記錄在 GitHub issues，AI 先確認 codebase，再把 issue 的內容補完；我透過 issue 的留言跟 AI 來回，而且強力要求每個 issue 一定要有 mermaid flowchart 與 mockup UI。三個狀態 label 分工：ai-enhanced 是 AI 負責，我負責監督最後的 approved。進入 approve 就代表我已經認可 issue 裡的 plan，可以交給新的 Claude Code session 完成，接著發 PR 搭配驗證。

想法先記成 issue

我開的 issue 常常只有一句話，例如「希望 tag 少於1 的不要顯示」「想加入文章的 share」。新開的 issue 會自動掛上 status: raw（一個 GitHub Action 負責），表示 AI 還沒碰過。

第一次跑這個流程時，我請 AI 先檢查 issue 是不是都做完了，沒做完的就把描述補完整，而且要附上驗證與測試。當時有 10 個 open issue：4 個只有一行標題，另外 6 個是做 PageSpeed 和資安檢測時開的，有數據但沒有完成條件。AI 逐一對照 code 與 PR，結果 10 個都還沒完成，沒有一個能直接關。

AI 看過 codebase 再補完

AI 補 issue 時先讀 code，確認現在是怎麼做的，再照同一個骨架補完，我原本寫的字保留不動：

mermaid 流程圖和 mockup 是過程中我追加的要求，後來每個 issue 都要有。mockup 圖放在 repo 裡一個不合併的 issue-assets 分支，不放公開的 CDN；repo 是 private，只有我看得到。

補完之後 AI 把 label 換成 status: ai-enhanced。

在 issue 上來回

我的規則是：只要是 UI，或還沒決定的地方，AI 都要先問我，而且要附圖。AI 先畫幾個選項的 mockup，用選擇題問我，我選完才寫進 issue；我透過 issue 留言回覆，像 LCP 那個 issue，我就把自己重測的 PageSpeed 截圖貼在留言裡，AI 再拿它更新基準數字（Performance 75 → 82）。

實際上，圖改變了我的決定：

• 分享列：一開始三種我都要。看到排在一起的圖之後，才發現放在文章底部沒問題，是 icon 太多太亂，所以改成桌機 LINE、Threads、Facebook、複製連結，手機只有「分享這篇」和「複製連結」。
• footer：原本是三欄（探索／關於／聯繫）。我丟了一張 Medium 底部的截圖給 AI，人家的 footer 就是這麼乾淨，所以改成一行英文連結當快速跳轉，GitHub 和 Email 用圖示。
• 熱度圖：深淺依當天篇數，我改成 1／2／3+；說明文字拿掉，最後連「少到多」的圖例也拿掉。
• 一個 issue 塞三個點子（看到別人部落格的三個功能）：拆成三個 issue，原本那個留做總覽。

approve 是交棒

三個狀態 label，一個 issue 只掛一個：

審的時候，AI 一次列一個 issue 的重點，我回 approve 或要改。進入 approve，這個 issue 就可以交給新的 Claude Code session 去做。

PR 帶著驗證回來

我也卡過一個問題：Claude 做出來的東西，我該看 issue 還是看 PR 才知道合不合理？又要怎麼驗證？結論是兩個都看，但回答的問題不同：

• 審 issue（ai-enhanced → approved），看 issue 頁：這是不是對的東西？範圍、選項、mockup，以及完成條件和驗證能不能證明它做對。
• 審 PR，看 PR 頁和 Cloudflare Pages 的 preview：有沒有照 approve 的做、證據在不在。

PR 不用逐行讀 code，讀證據、點 preview。為此加了一份 PR 模板：

• Closes #N
• 從 issue 複製過來的完成條件，逐條附證據：指令輸出、改前改後截圖、要點開的 preview 頁
• 沒驗到的直接寫出來；和 issue 不一樣的地方說為什麼

merge 之後再看正式站一次：Cloudflare Web Analytics 和 HSTS 只在 kiwi-walk.com 上，preview 測不到。

一次三個 session

流程定下來之後，我 approve 了 11 個 issue，然後只交代一句：把 approved 的 issue 各自開一個 worktree 去做，一次三個。

主 session 自己不寫 code，只做三件事：排順序、交代工作、收報告。每個 issue 開一個新的 Claude Code session，各自一份獨立的工作目錄（git worktree），互相不會踩到對方改到一半的檔案。

排順序看檔案，不看重要性

一次三個怎麼挑？主 session 看的是這個 issue 會改到哪些檔案：

• 第一批是 about 頁、tag 列表、專案頁導覽，三個改的檔案完全不重疊。
• 五個效能和無障礙的 issue（LCP、沒用到的 JS、色彩對比、圖片尺寸、圖片大小）很可能都動到同一批 layout 和 CSS，所以往後排，而且拆開。
• 「圖片補上寬高」和「圖片依螢幕給不同尺寸」改的是同一組圖片模板，後者等前者合併後才開，不跟它平行。

平行跑的 session 之間不會講話，所以每份交代裡都寫了「現在還有誰在跑、他們改哪些檔，避開」。

交代的內容

給每個 session 的交代是同一個骨架：

• 用 gh issue view 讀 issue，照 approve 過的現況、做法、完成條件做，不要自己改計畫
• 照 CLAUDE.md（不能有 inline script、手機寬度不能橫向捲動之類的規則）
• 自己跑 issue 裡的驗證與測試，再照 PR 模板發 PR，每個完成條件附上證據
• 跟 issue 不一樣的地方寫在 PR 裡，不要默默改
• 不改 label、不合併

最後兩條就是上一段的分工：approve 和合併都是我的事。

做不到的事，寫成「需要作者操作」

有兩個 issue 的關鍵一步不在 repo 裡：preview 部署要改 Cloudflare Pages 的 build command，CAA 紀錄要在 Cloudflare 的 DNS 設定裡加。這些 session 不能碰，所以交代裡要求它們把確切要改的值寫進 PR 的「需要作者操作」，依賴那一步的完成條件不打勾。

報告要照實講

收回來的報告裡，最有用的反而是「沒做到」的那幾句：

• 「沒用到的 JS」那個 issue：Google Analytics 改成頁面載完才載入，load 提早了 1 秒多、FCP 小幅改善，但 LCP 沒變，Lighthouse 的 unused JS 也還是 72 KiB。session 一開始回報 LCP 有進步，後來自己發現那是拿兩個不同 host 比出來的，主動在 PR 裡更正。
• 「圖片補上寬高」只處理了固定尺寸的 logo，文章頁剩下的 CLS 來自封面圖，session 判斷不在這個 issue 的範圍。
• about 頁的「現在在做什麼」是 AI 的草稿，要換成我自己的話。
• 分享列沒有在實體手機上測過。

這些都寫在 PR 裡，審 PR 時我知道該去哪裡多看一眼，而不是以為全部都好了。

下一批要我開口

第一批三個都做完時，主 session 想直接開第二批，結果開不起來：Claude Code 只在我自己下指令的時候開新 session，「前一批做完了」的通知不算。所以下一批先變成三張卡片放著，我點了才開始。

所以每一批開始前，都會先停在我這裡，我可以先看上一批的 PR。中間有一個 session 先做完、空出一個名額時，主 session 也是等我下一句話才補上下一個 issue。

做完寫成文章

PR 發完，我再請主 session 用 daily-devlog 這個 skill，把適合的 issue 寫成每日筆記，也說了可以開新的 session，或是沿用底下那些 child session。

沿用的理由是：一個 issue 為什麼這樣做、中途放棄了什麼，都只在做它的那個 session 的對話裡，主 session 只看過報告。所以主 session 不自己寫，而是把寫文章的工作交回給原本那幾個 session，同時先做兩個決定：

• 挑哪幾個：有取捨或卡關的才寫，像分享列、preview 的網址、tag 的門檻、延後載入 GA、色彩對比。只改文案、只補屬性、只寫文件的跳過，硬寫只會編東西。
• Day 怎麼排：Day 由日期決定，主 session 先查過已經用到哪一天，再依序分給每個 session，免得五個 session 同時寫出同一個 Day。

每篇文章從主線另開一個分支，不跟功能本身混在同一個 PR。

設定與決定

落地的設定有三個：

• .github/workflows/issue-status.yml：新 issue 沒有狀態 label 就自動加 status: raw
• .github/pull_request_template.md：上面那份 PR 模板
• CLAUDE.md 的 Issues 段：三個 label 的分工、AI 補 issue 的格式、UI 與未定案先問並出圖、兩次 review

寫這篇的時候，第一輪的 11 個 approved issue 都已經上線。