--- title: "GitHub接上ChatGPT後：不只是幫你寫程式，而是讓你直接改造自己的產品" description: "接上GitHub與專案環境之後，值得做的不只是寫程式：拿現有產品試新的使用方式、讓幾個方向各自長出可操作版本、把手動雜事做成固定功能，甚至替自己的系統加一個MCP介面。" canonical_url: https://www.datum.page/zh-tw/docs/agents/github-mcp-chatgpt site: "Datum" author: "CJ Mario" author_url: https://x.com/cjmario89 language: zh-TW published: 2026-09-18 last_updated: 2026-09-18 topic: "Agent 與 Tool Use" kind: concept # 概念 level: intermediate # 中級 tags: [mcp, github, chatgpt, codex, agents, workflow] cite_as: https://www.datum.page/zh-tw/docs/agents/github-mcp-chatgpt --- # GitHub接上ChatGPT後：不只是幫你寫程式，而是讓你直接改造自己的產品 > 接上GitHub與專案環境之後，值得做的不只是寫程式：拿現有產品試新的使用方式、讓幾個方向各自長出可操作版本、把手動雜事做成固定功能，甚至替自己的系統加一個MCP介面。 假設你有一套影片製作系統，已經可以產生腳本、配音和畫面，但每次只想修改其中一個鏡頭，都得重新執行一大段流程。 你打開ChatGPT說： > 「我想把它改成逐鏡頭編輯。哪個畫面不喜歡，就只重做那個畫面；配音沒問題的部分，不要跟著重跑。」 這句話可以不只是討論的開頭，也可以成為一項實際改版工作的起點。 當ChatGPT能取得你的專案內容，並具備相應的寫入工具，就能把討論接到現有程式的修改，而不只是交付一份通用做法。GitHub官方MCP提供的工具裡，`get_file_contents`與`search_code`負責讀，`create_branch`、`create_or_update_file`、`push_files`與`create_pull_request`負責寫（[GitHub MCP Server](https://github.com/github/github-mcp-server)，擷取2026-09-18）；ChatGPT的developer mode則提供完整的MCP client支援，讀與寫的工具都能用，實際可用範圍由你開放的工具與授權決定（[ChatGPT Developer mode](https://developers.openai.com/api/docs/guides/developer-mode)，擷取2026-09-18）。 這和「請AI從零做一個網站」有個很大的不同： **你不必把已經完成的東西丟掉重來，而是可以直接對正在使用的產品提出新的要求。** 先釐清一個界線：ChatGPT內建的GitHub連接目前只能讀。官方FAQ的說法是「ChatGPT裡的GitHub app只讓你讀取儲存庫來分析與搜尋程式碼。要直接產生、修改並推送程式碼到GitHub，請使用Codex」（[Connecting GitHub to ChatGPT](https://help.openai.com/en/articles/11145903)，擷取2026-09-18）。要實際修改，得有可寫入的連接或相應開發工具；要把修改後的產品執行起來，還需要專案環境。連上GitHub不會自動具備這三件事。 在這些能力到位後，值得展開的，就不只是「寫程式比較快」，而是下面這些原本容易停在想法階段的事。 > **說明：適用範圍** > > 依2026-09-18可查得的官方文件整理。這篇談的是接上之後值得拿來做什麼，不是設定教學；每一種用法需要的權限與環境不同，實際可用的工具與方案以你帳號裡看到的為準。 ## 把正在使用的產品，直接變成新想法的試驗場 假設你正在經營一個內容網站，原本文章全部按照發布時間排列。你想試試看：如果改成依照讀者想解決的問題分類，會是什麼樣子？ 以前，你可能先畫草圖、列功能，或者另外做一個與原網站沒有關係的展示頁。 現在，你可以提出更具體的要求： > 「保留現有文章和網址，另外做一個以使用情境為入口的版本。讓讀者先選自己遇到的問題，再看到相關內容。」 這次的產物，可以不是幾張畫面，而是**沿用既有文章、分類與搜尋能力的可操作版本**。有執行或預覽環境時，你能實際走過流程，看到原本的內容放進新結構後會發生什麼事。 Codex的雲端環境就是為這種循環準備的：它建立容器、checkout你指定的分支或commit SHA、跑setup script，然後在迴圈裡跑終端指令、改程式、跑檢查、嘗試驗證自己的工作，最後給出答案與修改差異（[Cloud environments](https://learn.chatgpt.com/docs/environments/cloud-environment)，擷取2026-09-18）。構想要變成可試版本，需要的就是這段「改完能跑起來」的執行基礎。 同樣的用法，也可以放在其他產品上。 一個原本只能填表單的後台，可以多一個引導式入口；一套只能整批執行的內容流程，可以改成逐段編輯；一個只有自己看得懂的資料工具，可以增加讓客戶使用的簡化介面。 **你不只是在問「這個想法可不可行」，而是可以要求「讓我用用看這個想法」。** ## 不必先選定方向，可以做出幾個真正不同的版本 假設你正在做影片製作工具，對操作方式有三種想法。 第一種是「輸入主題，依照引導一步步完成」，適合第一次使用的人。 第二種是「所有鏡頭攤開來編輯」，讓使用者控制每段文字、畫面和配音。 第三種是「團隊工作看板」，重點不是生成內容，而是誰正在處理、哪一段等待審核、哪些素材已經完成。 這不是同一個畫面換三種顏色，而是三種不同的產品形態。 你可以讓它們從同一個專案出發，各自形成獨立的實驗版本。Codex在ChatGPT桌面版支援worktree：它用Git worktree開出儲存庫的第二份checkout，每份worktree有自己的檔案、共用同一個`.git`，所以多個對話可以在同一個專案裡平行進行而不互相干擾（[Worktrees](https://learn.chatgpt.com/docs/environments/git-worktrees)，擷取2026-09-18）。 於是，討論可以從： 「初學者應該比較喜歡引導式介面吧？」 變成： 「這裡有一個引導版、一個進階編輯版，拿同一個任務實際操作看看。」 > **注意：平行歸平行，分支還是只能在一個地方被checkout** > > 官方文件特別點出這個限制：**Git只允許一個分支同時在一處被checkout**。worktree上checkout了某個分支，本機的checkout就不能同時用它。Codex預設讓worktree停在detached HEAD，避免污染你的分支；要留下成果才用「Create branch here」。另外，`.gitignore`擋掉的檔案不會跟著chat搬家——`.env`這類本機設定要靠儲存庫根目錄的`.worktreeinclude`列出來才會被複製進去（同上）。做三個版本之前先確認這件事，否則其中兩個版本會因為缺設定跑不起來。 你甚至可以把同一個底層系統，做成面向不同使用者的版本：自己使用的版本保留所有控制項，給客戶的版本只留下必要步驟，給協作者的版本則聚焦審核與交接。 **原本必須先在腦中選一條路，現在可以讓幾條路先各自長出一小段。** 這不代表每個版本都要變成正式產品，而是讓你有機會看到原本只能靠文字想像的差異。 ## 那些小到不想開專案的麻煩，也可以有自己的工具 假設你每週都要整理幾種不同格式的資料。 一份來自訂單系統，一份來自合作夥伴，另一份是自己維護的表格。每次都要重新對欄位、改日期格式、排除重複資料，再放回後台。 你當然可以每次都請ChatGPT幫忙整理。 但接上專案之後，還有另一種用法： > 「把這個整理流程做進我現有的後台。之後上傳檔案，就能看到欄位對應、異常資料和整理結果。」 這時，你得到的不只是這一次整理好的檔案，而是一個以後可以反覆使用的功能。 類似的需求還包括：替素材自動套用自己的命名規則、把多份報價整理成固定格式、找出文章中缺少的圖片，或把散落各處的製作狀態集中到一個頁面。 這些工具不必有完整的品牌、漂亮的首頁，也不必服務成千上萬的人。它可以只服務你自己，或一個小團隊。 更重要的是，它不一定要獨立成為另一套軟體。它可以直接長在你已經使用的系統裡，沿用現有登入、資料和操作方式。 **你不只能請AI替你完成一次工作，也可以請它把這件工作，變成你的系統以後本來就會做的事。** 這會讓「做一個工具」的想像變得很不一樣。工具不必先是一門生意，也可以只是把你每天繞路的地方，補上一條直接通過的路。 ## 把舊專案重新組合，長出下一個產品 假設你手上已經有幾個專案。 一個有會員與登入，一個有檔案處理，一個有排程，另一個可以產生報表。 你想做的新服務，可能不是缺少所有能力，而是這些能力分散在不同地方，還沒有被組成同一個使用流程。 這時，可以提出的需求就不只是「從零幫我做一個新產品」，而是： > 「看看這幾個我有權使用的專案，能不能把現有報表功能做成客戶可以登入、查詢和下載的服務。」 GitHub MCP的`search_code`、`search_repositories`與`get_file_contents`正好支援這種跨專案的翻找：先找到實作在哪裡，再讀完整檔案理解結構與依賴（[GitHub MCP Server](https://github.com/github/github-mcp-server)，擷取2026-09-18）。至於能重用多少，仍要依實際程式整合，不是把幾個資料夾接起來就算完成。 但從產品的角度，這開啟了一種很有意思的可能性： 原本只給自己用的內容產生器，可以加上專案管理與審核，變成團隊內容工作台。 原本替單一客戶做的資料整理工具，可以整理出共用流程，變成另一批客戶也能使用的服務。 一個沒有繼續經營的網站，也可能留下搜尋、會員或上傳能力，成為下一個產品的起點。 **舊專案不只是一段結束的工作，也可以是尚未重新組合的產品材料。** 對持續做作品、接案或嘗試創業的人來說，這意味著下一次開始，不一定又是空白頁。你可以帶著過去累積的能力，換一個入口、服務另一種需求。 ## 讓使用者的一句抱怨，直接長出可體驗的修改 假設使用者反映： 「我每次回來，都不知道上次做到哪裡。」 這句話還不是完整規格，但它已經指出一個具體的使用困難。 當你把回饋提供給ChatGPT，再讓它取得專案內容，就可以把它延伸成一項實際的產品修改：顯示上次操作的位置、保留尚未完成的內容，或增加「接著上次繼續」的入口。 另一句抱怨可能是： 「我不知道按下去之後，會不會把已經做好的東西蓋掉。」 對應的版本，可以加入修改前後預覽、明確顯示哪些內容會保留，以及把「重新生成」拆成更細的操作。 這些都是可以委託開發的具體場景，不是GitHub MCP自動附送的功能。但它們展示了一種不同的起點：**不必先把問題翻譯成資料表、API和元件名稱，才能開始讓產品改變。** 熟悉使用者的人，可以直接拿真實情境參與修改。客服、營運、設計師或創作者提出的，不再只能是一張等待別人翻譯的需求單，也可以是一個可試版本的起點。 如果再提供相關操作紀錄或產品數據，還可以把修改連到更具體的情境。不過，那些資料必須另外提供或授權連接，不能因為讀得到程式碼，就假設也讀得到使用者實際的行為。 最後，你能拿回去討論的，不只是「我們打算改善」，而是： **「這裡有一個修改後的版本，你遇到的問題，在這個版本裡還會不會發生？」** ## 用自己的專案，把抽象技術變成看得見的實驗 這套連接也不只適合做產品，可以用來學習。 假設你一直想弄懂背景任務、快取或失敗重試，但每次看教學，都得先理解另一個與自己工作無關的範例。 現在，可以直接拿自己的專案當教材。 例如，你的影片產生流程偶爾會中斷。你可以要求做一個實驗版本，讓其中一段刻意失敗，再觀察任務停在哪裡、哪些結果被保留，以及重新執行時會從哪裡開始。 接著，再做一個能從中斷位置繼續的版本。 你看到的就不只是「斷點續作」這個名詞，而是同一個任務在兩種實作下，實際會產生什麼差異。這種「改一版、跑一次、比一次」的循環，靠的就是agent能在環境裡執行指令與檢查，而不只是產生程式碼（[Cloud environments](https://learn.chatgpt.com/docs/environments/cloud-environment)，擷取2026-09-18）。 同樣地，想理解快取，可以拿自己的查詢流程比較有無快取的結果；想理解即時進度，可以把原本等待到最後才回傳的流程，做成逐步顯示狀態的版本。 這裡的用途，不是再取得一篇比較容易懂的解釋。 **你可以讓自己的系統，直接演出那個概念。** 而且，實驗不必全部留下來。它可以只是讓你親眼看過某個機制如何運作，再回到原本的產品繼續工作。 ## 再往前一步，讓ChatGPT成為你自己產品的操作入口 前面的用法，是透過ChatGPT修改產品。 還有一個更進一步的方向：**替自己的產品增加MCP介面，讓ChatGPT不只參與開發，也能操作已經做好的功能。** 官方的建議寫得很具體：當使用情境需要即時資料、驗證、受控的動作，或需要跑在你自己維運的基礎設施上，就該做一個MCP server；工具要按使用者目標切細——`list_projects`、`get_project`、`update_project`這種形狀，勝過一個帶很多模式的萬用工具（[Build an MCP server](https://developers.openai.com/plugins/build/mcp-server)，擷取2026-09-18）。 代價也在同一份文件裡：要公開提交的plugin，得把MCP server部署在穩定、公開可達的HTTPS端點上；服務必須留在內網的話，得另外架一個公開的HTTPS代理轉進去；只要工具會讀私有資料或替使用者做事，就要自己實作OAuth 2.1的驗證與授權（同上）。**這是一個要開發、部署與維護的東西，不是GitHub連接附帶的功能。** 以內容製作系統為例，當你已經把「查詢專案」「讀取鏡頭狀態」「重新產生字幕」做成可授權呼叫的工具，未來的操作就可以是： > 「找出這三個專案裡還沒有字幕的片段，列出來，並替我補齊指定的部分。」 或者： > 「把這支影片目前的腳本、配音和素材狀態整理在一起，告訴我還缺哪些東西。」 這裡改變的不只是輸入方式。 原本你可能要進三個頁面，分別查狀態、找檔案、執行操作。現在，可以讓對話把這些既有能力組成一次完整的工作。 也就是說，你可以先透過GitHub與開發環境，替系統做出需要的功能；再把適合的功能開放成工具，讓ChatGPT成為另一個使用入口。 **你不只是在打造一個網站，也可以替自己的工作打造一套能用對話操作的系統。** ## 從「請它回答」，走向「讓自己的工具真的改變」 把這些場景放在一起，GitHub接上ChatGPT的用途就不只是閱讀程式、修正錯誤或產生功能。 你可以拿現有產品試新的使用方式，讓幾個產品方向各自長出可操作版本；可以把一直手動處理的小事做成固定功能，也可以把過去的專案重新組合成新服務。 使用者的回饋，可以變成看得見的改版；想學的技術，可以變成自己專案裡的實驗；做好的系統，也可以再增加一個對話式操作入口。 這些事情不代表任何構想都能一次完成，也不代表所有功能只靠GitHub就足夠。但它們讓「我可以做什麼」不必只停在從零開發一個新網站。 **你已經擁有的程式、流程和工具，都可以成為下一次創作的起點。** 原本遇到不順手的地方，你可能只能想：「這個系統就是這樣用。」 現在，你可以接著問： *那就把它改成我真正需要的樣子，會是什麼樣子？* --- ## 本文引用來源 - [GitHub MCP Server](https://github.com/github/github-mcp-server) - [ChatGPT Developer mode](https://developers.openai.com/api/docs/guides/developer-mode) - [Connecting GitHub to ChatGPT](https://help.openai.com/en/articles/11145903) - [Cloud environments](https://learn.chatgpt.com/docs/environments/cloud-environment) - [Worktrees](https://learn.chatgpt.com/docs/environments/git-worktrees) - [Build an MCP server](https://developers.openai.com/plugins/build/mcp-server)