我讓AI代寫30天PR描述，結果出乎意料

寫Pull Request描述是我最頭疼的事。花幾小時寫代碼、解邏輯、調競態，最后對著空白文本框發呆，試圖用一句話讓團隊明白我做了什么。通常我只能寫"修復bug"或"更新API"，技術負責人打回來要求補充上下文，來回拉扯浪費所有人時間。2026年1月，我決定不再手動寫PR描述。

我搭建了一個自動化代理，使用GitHub Copilot Workspace API。目標是讓AI讀取diff、分析提交歷史、起草PR描述，我只負責審閱和必要時修改。實驗持續整整30天，我追蹤了所有能想到的指標，結果和預期完全不同。

我沒有直接打開通用聊天機器人——那種做法會失敗，因為通用模型缺乏上下文，不懂我們的內部編碼規范和單體倉庫架構。我寫了一個Python腳本，接入GitHub webhook事件。PR創建時觸發本地LLM實例，通過Ollama運行Llama-3-405B。本地部署是為了避免把專有代碼發到外部API，公司安全合規要求很嚴。

提示詞工程花了三天調優。我得教模型忽略空格改動、聚焦邏輯變更，還要強制它遵循我們特定的markdown模板。核心提示詞結構是：讓AI扮演高級Staff工程師，審閱git diff和提交信息，按固定格式生成PR描述——包括一句話總結"為什么做"、變更列表、具體單元測試、以及潛在風險。腳本把草稿以評論形式發到PR，不自動填充描述字段，給我留了安全網。

30天內我追蹤了三項核心指標，與之前三個月的平均表現對比。時間節省很明顯，但"請求修改"次數下降才是意外收獲。我的技術負責人指出，AI在列出測試步驟方面比我強——我經常忘記提跑了哪些集成測試，AI會自動掃描測試文件并列出，顯著減少了代碼評審中的來回溝通。

但并非一帆風順。AI在diff之外的上下文上表現糟糕。第12天我重構了一個數據庫遷移腳本，diff看起來很小，影響卻很大。AI寫的總結是"更新SQL腳本"，完全沒提這會鎖定生產表兩小時。我手動重寫了整個描述，那次差點釀成事故。第19天更奇怪，AI把兩個無關的提交混成一個"修復認證流程"，實際上一個是認證修復，另一個是UI調整。這種錯誤如果漏過，會讓回滾變得極其困難。

我還發現了一個微妙問題：AI的描述太"完美"了。它總是用規范的markdown、完整的測試列表、標準的風險提示。這反而讓評審者產生虛假安全感——看到格式工整就快速通過，不再深究邏輯。我注意到自己的PR平均評審時間從47分鐘降到19分鐘，但這不是好事，意味著評審深度在下降。

第23天我做了調整：讓AI生成初稿后，我強制自己必須添加至少一句人工注釋，說明"為什么現在做這個變更"或"替代方案考慮過什么"。這恢復了必要的上下文，評審時間回升到35分鐘左右，但"請求修改"次數保持在低位。

30天結束時的數據很清晰：純寫描述時間從平均23分鐘降到4分鐘，但審閱AI草稿需要12分鐘，凈節省7分鐘。真正價值不在時間，而在一致性——每個PR都有完整的測試說明和風險提示，團隊溝通摩擦大幅減少。技術負責人反饋說，他現在能更快判斷哪些PR需要重點關注。

我最終保留了這套系統，但改了規則：AI生成草稿，我補充業務上下文，技術負責人負責驗證風險描述是否準確。三方協作比任何單方都更可靠。這個實驗讓我意識到，AI最適合處理格式化和信息提取，而戰略意圖和潛在影響評估仍需人類判斷。完全自動化很誘人，但混合模式才是目前的最優解。