Codeball

Codeball是什麼

Codeball是一種由Sturdy團隊所開發的GitHub Pull Request自動審查工具，它創建於2020年，並入選了Y Combinator 2021年的冬季批次。該工具運用機器學習模型來為程式碼貢獻度評分，得分範圍在0到1之間，再根據預設的閾值來決定是否批准、標記或拒絕該PR。

它的重點並非像聊天機器人那樣逐一解釋所有的程式碼，而是判斷某項修改是否足夠安全，能否快速通過人工審查。團隊也可以將信賴度較低的修改標記為需要審查或需謹慎審查。

當前運營狀態

截至2026年8月21日，Codeball已無法以正常的AI代碼審查服務形式運作。Y Combinator的網頁將其標記為「Inactive」狀態，而該產品的官方網站也變成了名為AI BallCode的網站，上面還出現了與賭博相關的文章。

開源Action預設連接的遠端API網域目前無法解析，因此無法建立正常的Codeball審查任務。GitHub Marketplace仍保留v2.6.0的條目以及已驗證發布者標識，這些只能證明該Action曾由官方合作夥伴所發布，但無法證明該模型服務仍處於運作狀態。

一句話介紹

Codeball曾透過GitHub Action分析Pull Request並自動批准高置信度安全變更，但其公司、官網和遠端模型後端目前均已失去正常產品狀態，只適合歷史研究與遷移清理。

歷史核心功能

Pull Request風險評分

Codeball會將每個PR的評分定在0到1之間，分數越高，表示模型越認為該貢獻可以通過。預設的批准門檻為0.935，若分數低於0.300，則會被標記為需要謹慎審查。

閾值可以在工作流程中進行修改，但降低批准閾值會增加錯誤放行的風險。分數僅能反映舊模型的統計判斷結果，無法取代測試、安全掃描、業務驗證以及代碼所有者的審批。

自動批准安全PR

當模型的分數達到核准門檻時，Action即可提交審核申請。而這項功能需要倉庫或組織允許 GitHub Actions 建立並核准 Pull Request。

• 自動批准模型認為安全的貢獻。
• 把高置信度PR標為codeball:approved。
• 移除與新判斷衝突的舊風險標籤。
• 支援使用專用機器人帳戶來符合 CODEOWNERS 流程。
• 可以關閉自動批准，只保留標籤觀察結果。

風險標籤

Action可以根據分數為PR添加三類標籤，讓維護者先處理高風險的變更。標籤功能比自動批准更適合用於試運行，因為它不會直接改變合併時所需的審查狀態。

• codeball:approved表示模型達到高置信度閾值。
• codeball:needs-review表示需要常規人工檢查。
• codeball:needs-careful-review表示需要重點核查。
• 每次運行可移除與當前分數不一致的舊標籤。
• 團隊可以分別啟用或關閉不同標籤。

CI阻斷

failJobsWhenReviewNeeded選項可以用來在模型未批准某個貢獻時，讓工作流程回到失敗狀態。其預設值為false，這意味著Codeball預設不會僅因模型評分低而直接阻斷CI流程。

將模型結果設為強制合併檢查會擴大服務故障的影響。目前遠端API已無法解析，仍保留強制檢查可能會導致所有新的PR無法通過。

路徑過濾與草稿跳過

GitHub Actions的原生路徑條件可用來限制 Codeball 只分析特定的服務或目錄，而工作流條件則可以用來跳過草稿 PR 的審核。如此一來，就能減少因不相關的變更而引發的審核流程。

評論轉代碼建議

codeSuggestionsFromComments曾作為測試功能，將PR評論轉換成代碼建議。該選項預設為關閉狀態，且現有文件也無法證明此項測試功能已進入穩定階段。

Codeball AI Writer應用

Codeball AI Writer是與GitHub App相搭配的工具，用於讓來自Fork的PR也能獲得批准及標籤設定的權限。它能為公開或私有的儲存庫提供寫入權限，但同樣需要依賴Codeball的遠端服務。

安裝 GitHub App會授予倉庫相關的權限，因此不能因為 Marketplace 頁面仍然存在就繼續信任它。舊用戶應檢查該應用程式是否仍安裝在設備上，並在停止使用該服務後，撤銷不再需要的存取權限。

Codeball歷史工作原理

1. GitHub在新的PR或PR更新時會觸發工作流。
2. Action會讀取Pull Request的地址以及GitHub令牌。
3. 用戶端將PR地址、訪問令牌和閾值發送給Codeball遠端API。
4. 伺服器使用令牌讀取相關貢獻資訊並創建異步審查任務。
5. 動作輪詢任務狀態，取得置信度、批准結果和建議狀態。
6. 根據配置添加或移除標籤，並決定是否提交批准審查。
7. 如果啟用強制失敗，未批准的結果會讓工作流返回非零狀態。

舊文件指出，該模型會考慮數百個參數，包括對程式碼差異的感知哈希值、作者對相關文件的近期經驗、文件變更頻率，以及歷史上的回滾或修復記錄等。該模型的後端代碼並未在 Action 儲存庫中公開，因此目前無法重新產生原有的評分結果。

歷史安裝教學

1. 在倉庫中建立GitHub Actions工作流目錄。
2. 新增用於Codeball的工作流配置檔案。
3. 將觸發事件設定為 Pull Request，並根據需求加入評論事件。
4. 在作業中引用sturdy-dev發布的codeball-action v2。
5. 先關閉自動批准和CI失敗，只啟用標籤做觀察。
6. 為工作流設定讀取內容、寫入Issue以及寫入Pull Request的權限。
7. 提交到測試分支，查看不同風險PR的標籤結果。
8. 在驗證準確率與誤判成本後，再決定是否擴大自動化。

以上是歷史上的配置方式，不建議現在新增該工作流。遠端API無法解析，原官方網站也已改變，新安裝不僅無法完成審查，還會引入過時的依賴項目以及不必要的令牌傳輸設計。

安全停用與遷移教學

1. 搜尋倉庫工作流程文件中對 sturdy-dev/codeball-action 的引用。
2. 檢查分支保護規則是否將Codeball設為必須狀態檢查。
3. 先移除必需檢查，避免刪除工作流後阻塞合併。
4. 刪除或停用Codeball工作流，並提交單獨的清理PR。
5. 在倉庫和組織設定中卸載Codeball AI Writer應用。
6. 刪除專用CODEBALL_BOT_TOKEN及其他相關Secrets。
7. 撤銷專用機器人帳戶不再需要的倉庫權限和Personal Access Token。
8. 檢查最近工作流日誌是否曾列印異常回應或敏感資訊。
9. 選擇仍在維護的替代審查流程，並先用只評論模式驗證。

歷史適用用戶

Codeball目前不適合新用戶部署。以下的用戶類型僅適用於了解其過往的產品定位，或執行現有倉庫的遷移與安全清理作業。

• 開源專案維護者：曾希望透過低風險的社群貢獻來快速推進。
• 高頻PR團隊：用標籤把人工精力集中到可疑變更。
• 平台工程團隊：將模型判斷加入GitHub Actions流水線。
• 多服務倉庫：按路徑只審查指定目錄的變更。
• 安全與DevOps人員：排查舊工作流、應用權限和令牌。
• AI代碼審查研究人員：分析早期基於統計特徵的PR評分方案。

歷史使用場景

• 自動批准文件、依賴更新或其他低風險PR。
• 給複雜變更添加需要謹慎審查的標籤。
• 將模型低分轉換為CI失敗，阻止未經核復的合併。
• 跳過草稿PR，等作者準備完成後再運行。
• 只在指定服務目錄變更時觸發模型。
• 使用機器人帳號為Fork貢獻提供批准身份。
• 收集模型分數與人工審查結果，用於評估自動化價值。

歷史優勢

• 透過一份GitHub Actions設定，即可加入現有的PR流程。
• 0到1分數和三檔標籤便於逐步採用。
• 自動批准、僅標籤和CI失敗三種策略可獨立組合。
• 支援路徑過濾、跳過草稿及自訂機器人身份。
• Action客戶端源碼公開，關鍵輸入和權限可以審查。
• 預設閾值偏向高精度，設計目標是減少錯誤自動批准。

這些優勢依賴遠端評分服務的正常運作。客戶端開源無法彌補模型、訓練數據、後端及運營狀態無法使用的問題，因此不應將過去的設計優勢視為現在可購買的優勢。

使用限制與風險

• 公司已標記為Inactive，缺乏持續維護和客戶支援的證據。
• 原官網已變為其他內容站，並出現賭博相關主題。
• 預設的遠端API域名無法解析，Action無法建立正常任務。
• Action倉庫最後的推送停留在2023年4月，依賴與運行時已經陳舊。
• GitHub Marketplace條目仍存在不代表服務在線。
• Action會把PR地址和GitHub訪問令牌發送給遠端API。
• 原隱私政策與服務條款目前無法從產品網站核驗。
• 模型和訓練後端不開源，無法本地重建評分服務。
• 自動批准錯誤的PR可能把缺陷、安全問題或惡意變更帶入主分支。
• 強制失敗配置會把外部服務故障轉化為合併阻塞。
• 專用機器人和GitHub App會擴大寫權限，需要及時撤銷。
• 舊宣傳中的準確率與訓練規模不能視為當前性能的保證。
• 公開倉庫代碼採用舊版Node Action運行環境，長期相容性不足。
• 請勿透過已經改變用途的原始網站登入，或安裝任何檔案。

價格與可用性

Codeball的歷史發布資料曾提供免費試用，部分第三方目錄也記錄過付費資訊，但目前並沒有可驗證的官方定價、結算或訂閱頁面。任何舊有價格都不應被視為現行套餐的價格。

開源Action可免費下載，但這並不代表Codeball服務也是免費的，更不代表可以自行運行完整產品。在缺乏後端模型與API實現的情況下，用戶端僅能作為歷史代碼和工作流示例使用。

支援平台與整合

權限、隱私與安全

歷史記錄中，Action所建議的權限包括讀取倉庫內容、撰寫Issue以及撰寫Pull Request。如果需要自動批准，則還必須允許GitHub Actions創建及批准PR；而使用專用機器人時，則需要儲存具有寫入權限的Personal Access Token。

開源客戶端顯示，建立任務時會將PR或評論的連結、GitHub的訪問令牌，以及批准門檻等資訊傳送給遠端API。由於API已無法使用，且現行的隱私政策也無法再被依循，因此無法再假定舊服務在資料存取、保留及刪除方面的承諾仍然有效。

• 移除Codeball工作流前先調整分支保護的必需檢查。
• 刪除倉庫和組織中的CODEBALL_BOT_TOKEN。
• 撤銷專用機器人帳戶的舊Personal Access Token。
• 卸載Codeball AI Writer並檢查其倉庫授權範圍。
• 審查工作流歷史日誌，確認沒有令牌或敏感回應洩漏。
• 不要把遠端AI批准作為唯一代碼品質門檻。
• 替代工具應先以只評論或只標籤模式運行。
• 對私有倉庫要求可驗證的數據處理、刪除和模型訓練政策。

API、GitHub與開源狀態

Codeball確實有官方的GitHub儲存庫sturdy-dev/codeball-action，其中包含了GitHub Action用戶端、多個子Action，以及相關的測試與設定檔案。該儲存庫的授權方式為Apache 2.0，截至目前，已有約324個人給予了Star評分，另有35人進行了Fork操作。

但倉庫僅包含工作流客戶端和GitHub操作邏輯，評分模型、訓練管線和雲端API後端並未公開。產品無法標記為完整開源，只能寫成「Action客戶端開源，模型與服務後端非開源且已不可用」。

基本資訊

推薦指數

推薦指數為1.3分，滿分5分。Codeball的得分、標籤、自動批准以及CI阻斷設計，對於研究早期的AI代碼審查流程仍具有價值，而Action的源代碼則有助於了解其GitHub權限與遠端呼叫的相關規則。

但公司已Inactive，原官網用途改變，預設API域名無法解析，倉庫也多年沒有實質維護。它不適合新部署，更不應繼續接觸私有代碼或保留倉庫寫權限。

常見問題

Codeball現在還能用嗎？

無法將其視為可用的服務。Action條目仍存在於GitHub Marketplace上，但用於建立任務的遠端API網域目前無法被解析。

Codeball官網為什麼不是代碼審查工具？

原域名現在顯示AI BallCode內容站，並出現賭博相關文章，說明域名內容和控制狀態已經改變。不要透過該網站登入、下載或授權倉庫。

Codeball免費嗎？

目前沒有可驗證的官方價格或購買入口。Action的原始碼可依照Apache 2.0協議免費取得，但遠端模型後端並不可用，因此不能認為有可用的免費雲服務。

它會自動批准PR嗎？

歷史上是可以的，當數值高於預設的0.935閾值時，即可提交以進行審核。現在遠端評分服務已無法使用，因此不應再依賴此自動批准流程。

Action需要哪些權限？

歷史設定需要讀取倉庫的內容，並將其寫入 Issue 和 Pull Request 中。而自動批准功能則要求倉庫允許 GitHub Actions 建立及批准 PR。

為什麼要刪除舊Token？

用戶端會將 GitHub 存取令牌傳送給遠端的 Codeball API，而專用的機器人方案還可能儲存長期的令牌。一旦服務停止運作，這些憑證就不再需要被保留了。

Codeball是開源的嗎？

只有GitHub Action客戶端是開源的，它採用Apache 2.0許可證。至於評分模型、訓練流程以及服務後端則並非開源，因此整個產品並不屬於開源方案。

可以自行部署Codeball嗎？

不能僅憑公開倉庫部署完整服務。倉庫不包含原評分模型和API後端，客戶端仍需要遠程任務接口。

舊工作流如何移除？

先從分支保護中取消Codeball的必要檢查，再刪除工作流、應用程式以及Secrets。最後撤銷機器人Token，並確認新的PR不再等待舊狀態。

GitHub的Verified標識代表什麼？

它表示GitHub曾人工驗證Action創建者為官方合作組織，不代表GitHub認證其AI結果，也不保證目前遠端服務仍在上線。

可以把Codeball源碼改造成新工具嗎？

可以在Apache 2.0條件下研究或修改客戶端代碼，但需要自行實現新的評分後端、權限設計和數據政策。不能繼續假設原API協議或模型可用。

總結

Codeball曾提供一種清晰的AI代碼審查思路：為PR計算置信度，再透過標籤、批准或CI狀態將模型的判斷結果納入團隊流程中。公開的Action仍保留了這套用戶端設計與配置的範例。

目前真正重要的是停運後的安全處理，而非繼續安裝。團隊應移除必要的檢查、工作流程、GitHub App以及舊版Token，並轉而使用那些仍處於維護中、資料條款清晰，且可以先以評論模式進行驗證的審核方案。