GitHub接上ChatGPT後：不只是幫你寫程式，而是讓你直接改造自己的產品

假設你有一套影片製作系統，已經可以產生腳本、配音和畫面，但每次只想修改其中一個鏡頭，都得重新執行一大段流程。

你打開ChatGPT說：

「我想把它改成逐鏡頭編輯。哪個畫面不喜歡，就只重做那個畫面；配音沒問題的部分，不要跟著重跑。」

這句話可以不只是討論的開頭，也可以成為一項實際改版工作的起點。

當ChatGPT能取得你的專案內容，並具備相應的寫入工具，就能把討論接到現有程式的修改，而不只是交付一份通用做法。GitHub官方MCP提供的工具裡，get_file_contents與search_code負責讀，create_branch、create_or_update_file、push_files與create_pull_request負責寫（GitHub MCP Server（於新分頁開啟），擷取2026-09-18）；ChatGPT的developer mode則提供完整的MCP client支援，讀與寫的工具都能用，實際可用範圍由你開放的工具與授權決定（ChatGPT Developer mode（於新分頁開啟），擷取2026-09-18）。

這和「請AI從零做一個網站」有個很大的不同：

你不必把已經完成的東西丟掉重來，而是可以直接對正在使用的產品提出新的要求。

先釐清一個界線：ChatGPT內建的GitHub連接目前只能讀。官方FAQ的說法是「ChatGPT裡的GitHub app只讓你讀取儲存庫來分析與搜尋程式碼。要直接產生、修改並推送程式碼到GitHub，請使用Codex」（Connecting GitHub to ChatGPT（於新分頁開啟），擷取2026-09-18）。要實際修改，得有可寫入的連接或相應開發工具；要把修改後的產品執行起來，還需要專案環境。連上GitHub不會自動具備這三件事。

在這些能力到位後，值得展開的，就不只是「寫程式比較快」，而是下面這些原本容易停在想法階段的事。

把正在使用的產品，直接變成新想法的試驗場#

假設你正在經營一個內容網站，原本文章全部按照發布時間排列。你想試試看：如果改成依照讀者想解決的問題分類，會是什麼樣子？

以前，你可能先畫草圖、列功能，或者另外做一個與原網站沒有關係的展示頁。

現在，你可以提出更具體的要求：

「保留現有文章和網址，另外做一個以使用情境為入口的版本。讓讀者先選自己遇到的問題，再看到相關內容。」

這次的產物，可以不是幾張畫面，而是沿用既有文章、分類與搜尋能力的可操作版本。有執行或預覽環境時，你能實際走過流程，看到原本的內容放進新結構後會發生什麼事。

Codex的雲端環境就是為這種循環準備的：它建立容器、checkout你指定的分支或commit SHA、跑setup script，然後在迴圈裡跑終端指令、改程式、跑檢查、嘗試驗證自己的工作，最後給出答案與修改差異（Cloud environments（於新分頁開啟），擷取2026-09-18）。構想要變成可試版本，需要的就是這段「改完能跑起來」的執行基礎。

同樣的用法，也可以放在其他產品上。

一個原本只能填表單的後台，可以多一個引導式入口；一套只能整批執行的內容流程，可以改成逐段編輯；一個只有自己看得懂的資料工具，可以增加讓客戶使用的簡化介面。

你不只是在問「這個想法可不可行」，而是可以要求「讓我用用看這個想法」。

不必先選定方向，可以做出幾個真正不同的版本#

假設你正在做影片製作工具，對操作方式有三種想法。

第一種是「輸入主題，依照引導一步步完成」，適合第一次使用的人。

第二種是「所有鏡頭攤開來編輯」，讓使用者控制每段文字、畫面和配音。

第三種是「團隊工作看板」，重點不是生成內容，而是誰正在處理、哪一段等待審核、哪些素材已經完成。

這不是同一個畫面換三種顏色，而是三種不同的產品形態。

你可以讓它們從同一個專案出發，各自形成獨立的實驗版本。Codex在ChatGPT桌面版支援worktree：它用Git worktree開出儲存庫的第二份checkout，每份worktree有自己的檔案、共用同一個.git，所以多個對話可以在同一個專案裡平行進行而不互相干擾（Worktrees（於新分頁開啟），擷取2026-09-18）。

於是，討論可以從：

「初學者應該比較喜歡引導式介面吧？」

變成：

「這裡有一個引導版、一個進階編輯版，拿同一個任務實際操作看看。」

你甚至可以把同一個底層系統，做成面向不同使用者的版本：自己使用的版本保留所有控制項，給客戶的版本只留下必要步驟，給協作者的版本則聚焦審核與交接。

原本必須先在腦中選一條路，現在可以讓幾條路先各自長出一小段。

這不代表每個版本都要變成正式產品，而是讓你有機會看到原本只能靠文字想像的差異。

那些小到不想開專案的麻煩，也可以有自己的工具#

假設你每週都要整理幾種不同格式的資料。

一份來自訂單系統，一份來自合作夥伴，另一份是自己維護的表格。每次都要重新對欄位、改日期格式、排除重複資料，再放回後台。

你當然可以每次都請ChatGPT幫忙整理。

但接上專案之後，還有另一種用法：

「把這個整理流程做進我現有的後台。之後上傳檔案，就能看到欄位對應、異常資料和整理結果。」

這時，你得到的不只是這一次整理好的檔案，而是一個以後可以反覆使用的功能。

類似的需求還包括：替素材自動套用自己的命名規則、把多份報價整理成固定格式、找出文章中缺少的圖片，或把散落各處的製作狀態集中到一個頁面。

這些工具不必有完整的品牌、漂亮的首頁，也不必服務成千上萬的人。它可以只服務你自己，或一個小團隊。

更重要的是，它不一定要獨立成為另一套軟體。它可以直接長在你已經使用的系統裡，沿用現有登入、資料和操作方式。

你不只能請AI替你完成一次工作，也可以請它把這件工作，變成你的系統以後本來就會做的事。

這會讓「做一個工具」的想像變得很不一樣。工具不必先是一門生意，也可以只是把你每天繞路的地方，補上一條直接通過的路。

把舊專案重新組合，長出下一個產品#

假設你手上已經有幾個專案。

一個有會員與登入，一個有檔案處理，一個有排程，另一個可以產生報表。

你想做的新服務，可能不是缺少所有能力，而是這些能力分散在不同地方，還沒有被組成同一個使用流程。

這時，可以提出的需求就不只是「從零幫我做一個新產品」，而是：

「看看這幾個我有權使用的專案，能不能把現有報表功能做成客戶可以登入、查詢和下載的服務。」

GitHub MCP的search_code、search_repositories與get_file_contents正好支援這種跨專案的翻找：先找到實作在哪裡，再讀完整檔案理解結構與依賴（GitHub MCP Server（於新分頁開啟），擷取2026-09-18）。至於能重用多少，仍要依實際程式整合，不是把幾個資料夾接起來就算完成。

但從產品的角度，這開啟了一種很有意思的可能性：

原本只給自己用的內容產生器，可以加上專案管理與審核，變成團隊內容工作台。

原本替單一客戶做的資料整理工具，可以整理出共用流程，變成另一批客戶也能使用的服務。

一個沒有繼續經營的網站，也可能留下搜尋、會員或上傳能力，成為下一個產品的起點。

舊專案不只是一段結束的工作，也可以是尚未重新組合的產品材料。

對持續做作品、接案或嘗試創業的人來說，這意味著下一次開始，不一定又是空白頁。你可以帶著過去累積的能力，換一個入口、服務另一種需求。

讓使用者的一句抱怨，直接長出可體驗的修改#

假設使用者反映：

「我每次回來，都不知道上次做到哪裡。」

這句話還不是完整規格，但它已經指出一個具體的使用困難。

當你把回饋提供給ChatGPT，再讓它取得專案內容，就可以把它延伸成一項實際的產品修改：顯示上次操作的位置、保留尚未完成的內容，或增加「接著上次繼續」的入口。

另一句抱怨可能是：

「我不知道按下去之後，會不會把已經做好的東西蓋掉。」

對應的版本，可以加入修改前後預覽、明確顯示哪些內容會保留，以及把「重新生成」拆成更細的操作。

這些都是可以委託開發的具體場景，不是GitHub MCP自動附送的功能。但它們展示了一種不同的起點：不必先把問題翻譯成資料表、API和元件名稱，才能開始讓產品改變。

熟悉使用者的人，可以直接拿真實情境參與修改。客服、營運、設計師或創作者提出的，不再只能是一張等待別人翻譯的需求單，也可以是一個可試版本的起點。

如果再提供相關操作紀錄或產品數據，還可以把修改連到更具體的情境。不過，那些資料必須另外提供或授權連接，不能因為讀得到程式碼，就假設也讀得到使用者實際的行為。

最後，你能拿回去討論的，不只是「我們打算改善」，而是：

「這裡有一個修改後的版本，你遇到的問題，在這個版本裡還會不會發生？」

用自己的專案，把抽象技術變成看得見的實驗#

這套連接也不只適合做產品，可以用來學習。

假設你一直想弄懂背景任務、快取或失敗重試，但每次看教學，都得先理解另一個與自己工作無關的範例。

現在，可以直接拿自己的專案當教材。

例如，你的影片產生流程偶爾會中斷。你可以要求做一個實驗版本，讓其中一段刻意失敗，再觀察任務停在哪裡、哪些結果被保留，以及重新執行時會從哪裡開始。

接著，再做一個能從中斷位置繼續的版本。

你看到的就不只是「斷點續作」這個名詞，而是同一個任務在兩種實作下，實際會產生什麼差異。這種「改一版、跑一次、比一次」的循環，靠的就是agent能在環境裡執行指令與檢查，而不只是產生程式碼（Cloud environments（於新分頁開啟），擷取2026-09-18）。

同樣地，想理解快取，可以拿自己的查詢流程比較有無快取的結果；想理解即時進度，可以把原本等待到最後才回傳的流程，做成逐步顯示狀態的版本。

這裡的用途，不是再取得一篇比較容易懂的解釋。

你可以讓自己的系統，直接演出那個概念。

而且，實驗不必全部留下來。它可以只是讓你親眼看過某個機制如何運作，再回到原本的產品繼續工作。

再往前一步，讓ChatGPT成為你自己產品的操作入口#

前面的用法，是透過ChatGPT修改產品。

還有一個更進一步的方向：替自己的產品增加MCP介面，讓ChatGPT不只參與開發，也能操作已經做好的功能。

官方的建議寫得很具體：當使用情境需要即時資料、驗證、受控的動作，或需要跑在你自己維運的基礎設施上，就該做一個MCP server；工具要按使用者目標切細——list_projects、get_project、update_project這種形狀，勝過一個帶很多模式的萬用工具（Build an MCP server（於新分頁開啟），擷取2026-09-18）。

代價也在同一份文件裡：要公開提交的plugin，得把MCP server部署在穩定、公開可達的HTTPS端點上；服務必須留在內網的話，得另外架一個公開的HTTPS代理轉進去；只要工具會讀私有資料或替使用者做事，就要自己實作OAuth 2.1的驗證與授權（同上）。這是一個要開發、部署與維護的東西，不是GitHub連接附帶的功能。

以內容製作系統為例，當你已經把「查詢專案」「讀取鏡頭狀態」「重新產生字幕」做成可授權呼叫的工具，未來的操作就可以是：

「找出這三個專案裡還沒有字幕的片段，列出來，並替我補齊指定的部分。」

或者：

「把這支影片目前的腳本、配音和素材狀態整理在一起，告訴我還缺哪些東西。」

這裡改變的不只是輸入方式。

原本你可能要進三個頁面，分別查狀態、找檔案、執行操作。現在，可以讓對話把這些既有能力組成一次完整的工作。

也就是說，你可以先透過GitHub與開發環境，替系統做出需要的功能；再把適合的功能開放成工具，讓ChatGPT成為另一個使用入口。

你不只是在打造一個網站，也可以替自己的工作打造一套能用對話操作的系統。

從「請它回答」，走向「讓自己的工具真的改變」#

把這些場景放在一起，GitHub接上ChatGPT的用途就不只是閱讀程式、修正錯誤或產生功能。

你可以拿現有產品試新的使用方式，讓幾個產品方向各自長出可操作版本；可以把一直手動處理的小事做成固定功能，也可以把過去的專案重新組合成新服務。

使用者的回饋，可以變成看得見的改版；想學的技術，可以變成自己專案裡的實驗；做好的系統，也可以再增加一個對話式操作入口。

這些事情不代表任何構想都能一次完成，也不代表所有功能只靠GitHub就足夠。但它們讓「我可以做什麼」不必只停在從零開發一個新網站。

你已經擁有的程式、流程和工具，都可以成為下一次創作的起點。

原本遇到不順手的地方，你可能只能想：「這個系統就是這樣用。」

現在，你可以接著問：

那就把它改成我真正需要的樣子，會是什麼樣子？