AI 知識
AI 會寫 code 之後，誰准它送出？
AI 寫程式的討論，常常停在速度。
它能不能補完一個函式、看懂一個舊專案、一次改掉十個檔案，當然重要。但當改動開始不是一行一行產生，而是一整串提交、分支與 pull request 接連出現時，真正的問題會往後移一格：這些改動要怎麼被放進真正的程式碼倉庫？
最近出現的新型程式碼託管服務，把 repository、pull request、程式碼瀏覽、搜尋與同步放進同一個入口。它們的吸引力不只在「多一個放 code 的地方」，而在於 repository 開始能承接 AI 工作時需要的脈絡。
程式碼倉庫不只是在存檔案
以前說 Git，大多數人想到的是版本紀錄：誰改了什麼、哪一次提交出了問題、要不要回到上一版。
這些能力在 AI 時代沒有變小，反而變得更重要。因為 AI 能把改動產生得很快，也能同時在多個檔案、分支與任務之間切換。若所有變化只留在聊天視窗或本機資料夾，團隊很快會失去三件事：改動的來由、可以審查的範圍，以及能回復的落點。
repository 因此開始像一個控制台。它不是替 AI 下結論，而是把 AI 做過的事放回可看見、可討論、可回退的位置。
速度不是唯一的風險
當 AI 協助寫 code，人很容易先問它準不準。但還有四個更靠近實際工作的問題：
- 它能看到哪些程式碼與設定？
- 它可以改哪些檔案，哪些地方必須停下來？
- 誰負責看過改動再合併？
- 發現方向錯了時，要怎麼找到並撤回那一次改動？
這些問題不會因為模型更聰明而自動消失。反過來說，模型越能做長任務，權限、審查與回復就越不能只是事後補上的流程。
同步，不等於全部搬家
新工具支援把既有 repository 同步過來，但同步範圍往往刻意保留邊界。例如程式碼歷史、分支、標籤與 pull request 可以跟著走，Issues、CI 設定與 secrets 則仍留在原本的系統。
這不是缺陷，而是一個很實際的提醒：程式碼、工作追蹤、執行管線與敏感憑證，本來就不該被當成同一種東西。把它們放進同一個介面很方便，卻不代表它們該有同一套權限、更不代表 AI 應該同時碰到全部。GitHub 仍是 source of truth。
下一個成熟度，不是「讓 AI 自己 merge」
真正成熟的 AI 協作，未必是讓它一路從需求走到部署。更可能是每一段都清楚：它在哪裡提出改動、由誰檢查、哪些資料不能碰、什麼時候必須退回人工決定。
AI 可以把工程節奏推快，但程式碼倉庫仍要扮演煞車、儀表板與回轉道。當改動越來越容易產生，最有價值的能力不是把每一個步驟自動化，而是讓每一次送出都還能被理解、被審查，也被撤回。
所以，AI 會寫 code 之後，最重要的問題可能不是它寫得多快。
而是：誰准它送出？
參考資料
- Cursor Changelog：Origin Code Hosting
- Cursor Docs：Mirror a GitHub repository
- Cursor Docs：Clone, Push & Pull