在 GitHub 找到喜歡的 Repo，怎樣交給 AI 修改？新手從看懂到下載的 5 個步驟
在 GitHub 找到喜歡的 Repo 後，不要只看截圖便叫 AI 開始修改。先用五個步驟確認它採用甚麼技術、是否符合你的專案、提供完整產品還是單一功能、授權是否合適，以及目前是否仍能使用。確認值得繼續後，再選擇正確的方法把它交給 AI。
上一篇先讀：GitHub 上找到的程式可以直接拿來用嗎？小白也能看懂的 Open Source 入門
之前介紹了 Repo、Open Source、README 和 License，也留下了一個最實際的問題：
我已經找到一個看起來很適合的 Repo，現在可以直接把連結交給 AI，叫它改成我的產品嗎？
答案是可以，但不要只說「幫我下載，再換成我的品牌」。
假設你想製作預約網站，在 GitHub 找到一個畫面非常完整的專案。
首頁、日曆和登入頁都已經做好，看起來只欠你的 Logo。
你把連結交給 AI，半小時後才發現它其實是一個手機 App，而你原本想做的是網頁；又或者它只有日曆畫面，根本沒有保存預約的功能。
AI 看得懂程式碼，不代表眼前的程式碼適合你的產品。真正節省時間的方法，是先讓 AI 幫你認清這是甚麼，再決定是否接手。
以下五個步驟，不需要你親自閱讀程式碼。你只需要知道 AI 的答案是否符合自己的目標。
第一步：先弄清楚這個 Codebase 是用甚麼做的
Codebase 可以理解為組成整個專案的程式碼和設定。
兩個網站的畫面可以非常相似，背後卻可能使用完全不同的程式語言和工具。
例如，同一個預約畫面可以用以下方式製作：
TypeScript配合React或Next.js製作網頁。Dart配合Flutter製作手機 App。Swift製作 iPhone App。Kotlin製作 Android App。Python配合Django製作包含後台的網站。
你不需要學會分辨每個檔案。要知道的是：這個 Repo 的技術，是否適合你要製作的產品，以及是否能與現有專案接在一起。
如果你已經有一個 Next.js 網站，找到另一個 Next.js Template，AI 通常比較容易把兩者結合。假如你找到的是 Flutter App，便不是把幾個檔案複製過去那麼簡單，很可能需要重新製作同一項功能。
如果你還沒有任何專案，程式語言未必是第一個淘汰條件，但仍要確認三件事：它是網頁還是手機 App、你的電腦能否運行，以及你準備使用的上線服務是否支援。
最理想的 AI 回覆，不是一串套件名稱，而是這種普通人也能作決定的結論：
這是一個使用 TypeScript 和 Next.js 製作的網頁專案，可以在瀏覽器運行。它與你現有的 Next.js 網站採用相近技術，可以考慮整合；如果你的目標是原生 iPhone App，便不適合直接使用。
看完這一句，你已經知道應該繼續，還是回到 GitHub 尋找另一個選擇。
第二步：確認它是完整專案，還是其中一項功能
技術相符之後，下一個問題才是：這箱材料究竟有多完整？
GitHub 上的 Repo 大致可以分成以下幾類：
| 類型 | 你實際得到甚麼 |
|---|---|
| 完整專案 | 前台、後台和主要功能已經連接，但通常仍需設定帳號、資料庫和服務。 |
| Template 或 Starter | 已經做好基本結構，預期讓你改成自己的產品，但部分功能可能只是示範。 |
| Component 或 Library | 只提供一項功能，例如日曆、登入畫面或圖表，需要放進另一個專案才能使用。 |
| Demo 或教學作品 | 用來示範某種效果或做法，不一定準備好讓人長期使用。 |
判斷時，不要只問「有沒有預約頁面」，而要問那個頁面後面是否真的有功能。
客人選擇時間後，預約會不會保存？店主有沒有地方查看？重新開啟網站後，剛才的資料是否仍然存在？
如果答案都是沒有，它便可能只是一套漂亮介面。這不代表 Repo 沒有價值，只代表你得到的是設計起點，而不是已經可以營運的預約系統。
對 Vibe Coding 新手而言，這個分別比程式碼寫得是否漂亮更重要。完整專案是接手和修改；單一功能是整合；介面範例則可能需要由功能層重新開始。三者所需時間完全不同。
四個真實 Repo，畫面相似但性質不同
把分類放回真實畫面，差別會更容易理解。以下四個 Repo 都可以在瀏覽器看到完整畫面，但你實際得到的東西完全不同。
完整專案：Memos
usememos/memos 是可以自行託管的完整筆記產品。它有前端介面、後端、資料儲存、登入、標籤和搜尋等功能。Demo 中看到的時間軸和日曆不是一張靜態設計圖，但要把它改成自己的產品，仍要接手完整的開發和部署環境。
Template 或 Starter：TailAdmin
TailAdmin/free-nextjs-admin-dashboard 提供已經設計好的 Next.js 後台介面，包括圖表、表格、表單和登入頁。畫面看起來很完整，但這些內容主要是讓你建立自己產品的起點，不代表會員、訂單和收入資料已經接上真正的後台。
這個 Repo 的名稱包含 Template，但 GitHub 頁面沒有啟用 Use this template，所以分類和下載方法仍要分開判斷；實際使用時會選擇 Clone。
Component 或 Library：FullCalendar
fullcalendar/fullcalendar 提供可放進網站的日曆功能，例如月曆、拖放活動和不同檢視模式。它不會自動替你建立預約資料庫、會員登入或店主管理頁面。正確做法通常是把套件安裝到現有專案，而不是把整個 Repo 當成新的預約產品。
Demo 或教學作品：Next.js Learn
vercel/next-learn 保存 Next.js 官方課程使用的練習程式。它的 Demo 有登入頁和 Dashboard，看起來也很像真正產品，但頁面已清楚寫明這是課程範例。它適合學習某種做法或參考程式結構，不應只憑畫面便當成可以直接營運的 SaaS。
四個例子說明了同一件事：**能夠打開 Demo，只代表你看得到結果，不代表你已經知道 Repo 提供多少功能。**仍要回到 README、資料夾結構和設定檔確認它是完整產品、起點、單一功能，還是教學材料。
第三步：用最簡單的方法看 License
上一篇已經解釋過，Public 只代表任何人都看得到，不代表可以任意修改和重新發布。這次只需要把 License 變成一個可以立即作決定的答案。
常見情況可以先這樣理解：
- MIT、Apache 2.0： 通常容許修改和商業使用，但需要保留指定的版權及授權聲明。
- GPL： 可以修改和使用，但發布修改版本時，通常需要按照同一類開源方式提供程式碼。
- 沒有 License： 不要當作可以直接複製、修改和推出自己的版本。
你不用親自閱讀整份法律文字。讓 AI 告訴你三件事便足夠：可不可以修改、可不可以商業使用、需要保留或公開甚麼。
假如答案仍然只有「應該可以」，便要求它指出 License 的原文依據。這不是要把自己訓練成法律專家，只是不要花幾天完成產品後，才發現一開始便選錯材料。
第四步：確認它是否仍然有人使用和維護
一個 Repo 五年前很受歡迎，不代表今天仍能順利安裝。
你可以先看 Repo 首頁有沒有 Archived 標示。Archived 代表作者已把專案封存，通常不會再繼續更新。
接着再看最近一次 Commit 或 Release、README 是否仍提及目前可用的安裝方法，以及近期 Issues 有沒有大量相同的安裝失敗回報。
最後更新日期不是唯一標準。一個簡單的小工具可能多年不用修改，仍然可以正常使用；
但如果它依賴 Next.js、React Native 或其他快速更新的工具，幾年沒有維護便可能代表 AI 要先花大量時間修理，才能開始做你的功能。
所以，這一步不是要找「昨天才更新」的 Repo，而是確認：
- 作者是否已明確放棄專案。
- 文件和程式是否仍然對得上。
- 最近的使用者是否普遍能夠安裝。
- 主要套件是否已經落後太多。
兩個過期 Repo：一個明示，一個靜默
最容易辨認的是作者已經主動封存的 Repo。
angular/angular-seed 的頁面頂部清楚顯示 Archived，並寫明自 2024 年 2 月 26 日起變成唯讀；
主要 Branch 的最後一次 Commit 更停留在 2018 年。即使它有超過一萬個 Stars 和 MIT License，也不適合作為今天的新 Angular 專案起點。
更容易令人誤判的是沒有 Archived 標示的「靜默停滯」。react-boilerplate/react-boilerplate 仍顯示為 Public template，累積接近三萬個 Stars，首頁介紹亦仍然十分完整；
可是主要 Branch 的最後一次 Commit 停留在 2019 年，檔案列表幾乎全部顯示約七年前更新。
它的設定亦仍使用 Node.js 8、React 16 和 Webpack 4，Issues 中可以找到新版本 Node.js 或 npm 無法正常安裝的回報。
前者直接告訴你「不要再把它當成新專案」，後者則需要你主動查看 Commit、Release、主要套件版本和 Issues 才能發現。
沒有 Archived，不等於仍然有人維護。
Stars 可以告訴你很多人對它有興趣，維護紀錄才比較接近「現在是否值得接手」。
第五步：選擇正確的方法把 Repo 抓回來
確認前四步都沒有問題，才需要把 Repo 放進自己的電腦。
GitHub 提供幾種看起來相似、用途卻不同的方法：
如果它本身是 Template
看到 Use this template，可以用它建立一個屬於自己的新 Repo。這適合把範本當作新產品起點，不需要連作者以前每一次修改也一起帶走。
如果你準備長期修改
使用 Clone。Clone 會把專案檔案和 Git 版本紀錄一起複製到電腦，日後比較修改、建立 Branch 和接收原專案更新都比較方便。
你不需要自己輸入 Git 指令。按 Repo 頁面的綠色 Code 按鈕，複製 HTTPS 連結，再把連結交給正在使用的程式開發 AI，請它將專案 Clone 到一個新的獨立資料夾便可以。
如果只想快速看看
Download ZIP （點擊綠色的Code按鍵）會下載一份檔案快照。它適合臨時查看，但不包含完整 Git 版本紀錄。假如你已經決定要讓 AI 長期修改，通常直接 Clone 會更合適。
無論選哪一種方法，都不要把新 Repo 的所有檔案直接倒進現有專案。先在獨立資料夾啟動，確認它本身可以運行，再決定要整個採用，還是只取其中一項功能。
把 Repo 連結貼給 AI 時，直接使用這段提示詞
以下提示詞把前面的五個步驟放在一起。括號內的內容按實際情況填寫；如果不知道目前專案使用甚麼技術，直接寫「不知道」便可以。
我正在考慮使用這個 GitHub Repo：
（貼上 Repo 連結）
我想製作：
（用普通人的語言描述產品、使用者和必要功能）
我目前的專案：
（貼上專案連結、提供資料夾位置，或寫「還沒有現有專案」）
請先閱讀這個 Repo 的 README、主要設定檔、資料夾結構、License、最近的 Commit／Release 和近期 Issues，然後用非工程師能理解的方式告訴我：
1. 這是甚麼類型的 Codebase？它使用甚麼程式語言、Framework 和平台？與我目前的專案是否相容？
2. 它是完整專案、Template、單一功能、Library，還是 Demo？哪些部分已經可以運作，哪些仍需要另外製作？
3. License 是否容許修改、公開發布和商業使用？我需要保留、註明或公開甚麼？
4. 這個 Repo 是否仍在維護？有沒有 Archived、文件過時、套件太舊或大量使用者無法安裝的跡象？
5. 如果值得使用，我應該選擇 Use this template、Clone 還是 Download ZIP？請列出在我的電腦啟動它所需的工具和步驟。
最後請給我一個明確結論：適合直接作為新專案起點、適合抽取其中一項功能、只適合作為參考，或不建議使用。每個結論都要指出依據，不要只根據截圖或 Stars 猜測。
現在先完成分析和操作計劃，不要開始修改程式碼。如果 AI 的結論是值得使用，下一句可以簡單得多：
按照剛才的分析，先判斷這個 Repo 應該作為完整專案的起點，還是作為 Library、套件、外掛或單一功能加入我現有的專案。
如果它是完整專案或 Template，請把它複製到一個新的獨立資料夾，依照 README 安裝並在本機啟動，確認原本版本可以正常運行，再告訴我下一步應該修改哪裡。
如果它是 Library、套件、外掛或單一功能，請不要直接把整個 Repo 的原始碼複製進我的專案。先檢查它與現有專案的技術和版本是否相容，列出正確的安裝方式、需要修改的設定檔和可能風險。確認方法可行後，建立新的 Git Branch，再進行安裝或整合，並驗證現有功能仍然正常。
如果你無法確定應該採用哪一種方法，先停下來向我說明，不要自行把兩個專案混在一起。整個過程都不要把真實密碼或 API key 加入 Git。這時 AI 才真正開始下載、安裝或整合。因為前面已經確認過專案類型、技術、完整度、授權和維護狀態，它不再只是對着一箱未知材料盲目開工。
寫在最後
在 GitHub 找到一個漂亮 Repo，最令人興奮的時刻通常是：「這個好像可以直接改成我的產品。」
有時真的可以。AI 的確能替你閱讀陌生的 Codebase、安裝套件、修改畫面，甚至把其中一項功能接到自己的專案。
但它不能替你省略最前面的判斷：這是甚麼、是否相容、完整到甚麼程度、能否使用，以及是否仍然值得接手。
整個流程其實只有五步：
- 認出 Codebase 和使用的技術。
- 分清完整專案、範本和單一功能。
- 看懂 License 允許你做甚麼。
- 確認專案仍然可以使用。
- 選擇 Template、Clone 或 ZIP，把它放進獨立資料夾。
先判斷，再下載，最後才修改。這樣做不是為了令流程變得更專業，而是避免 AI 花一整晚替你修理一個根本不適合的專案。
作者：
