程式完成後，團隊仍需要知道為什麼改、改了什麼、怎麼驗證，以及有哪些風險。若 Pull Request 只寫「完成重構」，Reviewer 必須重新猜一次背景。今天讓 ChatGPT 或 Codex 根據實際 diff 產生 PR 說明，再由人類核對。

PR 描述要對得上 Diff

第一段說明具體問題：新增與編輯有兩套標題驗證，規則可能分歧。第二段說明完成後的行為：共用同一驗證入口，外部 API 和錯誤文字不變。接著列出實際修改、測試指令與結果，以及 Reviewer 應特別確認的地方。所有敘述都必須能從 diff、Issue 或測試找到來源。

AI 常見的風險是把計畫寫成已完成，或根據檔名推測不存在的效果。例如只改共用函式，PR 卻寫「提升所有表單效能」，就超出證據。另一個問題是漏掉非預期變動，因此產生說明前要先看完整 diff 和 commit，而不是只讀任務 Prompt。

可重複使用的 PR Prompt

「根據 Issue、commit 與完整 diff 撰寫 PR 描述。先說明觸發問題和修改後行為，再列出主要變更、實際執行的驗證、風險與 Reviewer 注意事項。不要把未執行的測試寫成通過，不要推測 diff 無法支持的效能或安全改善；若資訊不足請標示待補。」

人工版本怎麼比較

我會另外寫一份短版 PR 說明，再比較 AI 是否遺漏真正重要的邊界、是否加入無證據的宣稱，以及 Reviewer 能否只看描述就知道如何驗證。好描述不必長，但要讓第一次看到專案的人理解問題和行為差異。

最終採用的內容仍由人類對照 diff 校正。若測試只跑了標題驗證單元測試，就不能寫成「所有測試通過」；若 Repository 原本已有失敗，也要明確區分本次新增失敗與既有問題。

今天的結果與限制

目前建立 PR 描述模板與比較方式，尚無真實 commit 或 PR，因此不會虛構測試、連結或 Reviewer 回饋。待 Repository 建立後，再用 Day 16–17 的實際修改完成本篇實驗。

今天學到什麼？

AI 可以幫忙把修改整理成文字，但 PR 描述也是一份技術承諾，必須逐句對照證據。明天進入安全主題，先處理 Secret、權限與外部指令的信任邊界。