Bun 1.4.3 加入 bun check：AI 寫完程式，先檢查型別再執行

AI 可以很快寫出一段 TypeScript，執行前的檢查卻常要另外安排。Bun 1.4.3 加入 bun check，把型別檢查放進執行、測試與建置的流程，讓不符合型別要求的程式先停下來。

這是一項程式開發工具更新，也適合觀察 AI 寫程式的工作流程。當程式產量增加，能不能及早找出明確錯誤，往往比單純讓生成速度更快，更能減少後續修正。

bun check 會檢查 TypeScript 型別

Bun 是 JavaScript 與 TypeScript 的執行及開發工具。TypeScript 型別則用來描述資料應該長什麼樣，例如函式需要數字、回傳文字，或物件必須包含哪些欄位。

bun check 會讀取專案的 TypeScript 設定，檢查程式是否符合型別規則。官方說明指出，這項功能移植自 TypeScript 的 Go 實作，並通過相應的 TypeScript 7.0.2 測試套件。

假設 AI 把「商品數量」寫成文字，卻傳入只接受數字的函式，型別檢查就可能在執行前指出問題。開發者可以把錯誤訊息交回代理修正，再繼續後面的工作。

先檢查再執行，讓錯誤更早被看見

這次更新提供 bun run --check、bun test --check 與 bun build --check，讓檢查在執行、測試或建置之前發生。若型別檢查失敗，後面的操作就會停止。

對使用程式代理的團隊來說，這可以成為一個具體的完成條件。例如，要求代理修改功能後先通過型別檢查，再跑受影響的測試，最後交代哪些行為已驗證。

這樣安排的好處是錯誤訊息比較接近剛完成的修改。若等到多個功能累積之後才檢查，代理與工程師都需要花更多時間判斷問題來自哪一段程式。

不過，bun check 的用途是檢查型別。它不會替專案產生 JavaScript 或型別宣告檔，也不應被當作編輯器語言服務的完整替代方案。需要這些輸出的人，要保留原有建置安排。

官方速度比較，不能直接套到每個專案

Bun 在公告中提供數個專案的速度比較，在指定的 16 核心 Apple Silicon 裝置上，相較於 TypeScript 的 tsc 7.0.2 檢查器，測得約 3 至 6.4 倍的加速。這些數字描述的是官方選定的測試環境。

自己的專案可能有不同檔案量、型別複雜度與套件組合，因此比較可靠的方法是保留同一份程式碼與裝置，分別跑既有檢查器和新工具，觀察耗時與錯誤結果。

如果檢查速度提高，團隊就比較有機會在每次修改後執行它。真正的收益應該包含等待時間與修正時間，而不只是把一次測試的倍數寫進工作報告。

升級前也可以選一個熟悉的專案做小範圍比較，確認設定能被正確讀取。若錯誤結果不同，先找出差異原因，再決定是否接進正式開發流程。

通過型別檢查，AI 寫的功能就正確了嗎？

型別檢查能找出資料形狀不一致等問題，業務邏輯仍需要其他檢查。例如，價格與折扣都使用數字型別，折扣公式算錯時，型別系統未必會發現。

因此，AI 代理完成工作時，可以把型別檢查和行為測試分開交代。前者回答「程式符合哪些結構規則」，後者回答「功能在指定情境下是否得到預期結果」。

Bun 1.4.3 讓第一道檢查更容易接進流程，這是它對 AI 開發工作的實際意義。接下來要看的是，團隊能否用更短的回饋循環，把代理生成的程式轉成可驗證的修改。

在 AI 開發流程裡，型別檢查應該放在哪裡

AI 代理能快速修改多個檔案，也可能把一個不一致的假設帶進不同地方。型別檢查提供了較早的回饋，讓資料結構的錯誤在執行前被看見，減少後續追查的範圍。

但工具要發揮作用，需要接進明確的完成流程。可以先說清楚代理改完哪些檔案後要檢查、失敗時如何修正，以及通過後還要做哪些行為驗證。

把檢查結果變成下一輪修改的輸入

型別錯誤通常會指出檔案位置與不符合要求的資料。把完整錯誤訊息保留下來，代理才容易回到具體位置修正，而不只是收到「檢查失敗」這種模糊回覆。

例如，函式需要一個含有識別碼的物件，AI 卻只傳入名稱，檢查結果就能讓修改回到資料結構。這比開始執行後，才從另一段錯誤推測來源更直接。

修正之後，仍應重新執行受影響的檢查。不能只看代理回覆說已修改，因為它可能補錯欄位，或在修正一個地方時讓另一個函式不再符合型別。

這種回饋循環適合局部工作。當錯誤範圍很大時，可以先讓工程師釐清共同原因，再讓代理處理，避免反覆修補表面訊息卻沒有解決結構問題。

檢查失敗時，先確認錯誤是不是新增的

既有專案可能原本就有型別問題。要求 AI 修一個功能之前，可以先跑一次原有檢查，記錄已知錯誤，修改後才能分辨哪些問題與這次工作有關。

這樣做也能控制需求範圍。如果代理為了消除全部舊錯誤，開始改動許多無關模組，原本的小修改就可能變成難以審查的大型變更。

工作指令可以要求先處理本次新增或受影響的問題，再交代既有錯誤。這有助於讓型別檢查提供回饋，同時保留工程師對修改範圍的判斷。

評估 bun check，先做同一份專案的對照

官方速度比較以特定裝置與專案為基準。自己的程式結構與型別複雜度不同，最直接的評估方式，是用同一份程式碼比較既有檢查器與新工具。

比較之前，可以記錄工具版本、設定與檔案範圍。若一個檢查器包含測試檔，另一個沒有，耗時差就很難當作相同工作的速度比較。

速度之外，先核對檢查結果

兩個工具都執行完後，先比對錯誤種類與位置。速度快很有吸引力，但如果實際檢查範圍不同，或設定沒有被同樣讀取，結果就需要進一步查明。

可以選一個小型、熟悉的錯誤作為測試，例如把數字改成文字，觀察兩個工具是否都能指出同一問題。這是一個對照方法，並非對所有語言特性的完整測試。

確認結果接近後，再觀察耗時。把第一次執行與後續執行分開記錄，會比較容易理解等待時間，也能避免拿不同狀態的測試直接比較。

執行、測試與建置，應有一致的失敗處理

--check 讓型別檢查在後續操作前發生，團隊仍要確認自己的指令鏈如何回報失敗。若外層腳本忽略錯誤狀態，後面的流程可能仍被其他指令啟動。

這裡需要觀察的是實際執行結果：型別錯誤出現後，指定的測試或建置是否真的停止，以及工作紀錄是否清楚顯示原因。工具說明與專案整合，都要接得起來。

如果正在導入新流程，可以先在測試分支確認這些行為，再接進日常工作。這樣能讓代理與工程師知道哪個指令代表完成，而不需要每次臨時猜測。

TypeScript 的型別能檢查什麼，不能替你決定什麼

型別描述資料應該符合的結構，對函式參數、回傳值與物件欄位特別有用。它能幫助開發者在修改時看見不一致，但資料的業務意義仍需要另外定義。

例如，「價格」與「折扣」都可以是數字。程式把兩者相加，可能完全符合型別，卻與正確的付款計算不同，這就是型別規則與功能規則的差別。

外部輸入還需要執行時檢查

資料來自表單、網路或其他系統時，真正收到的內容可能與型別描述不同。專案仍需要在適當位置驗證輸入，再交給後面的程式處理。

例如，使用者送來的年齡欄位可能是文字，或根本沒有欄位。型別宣告不能替遠端來源保證資料正確，開發流程需要同時考慮這些執行時情境。

因此，代理修改介面時，可以要求它保留既有資料驗證，並補上受影響的行為測試。這讓程式結構與實際輸入都有相應檢查，減少只看一種工具結果的盲點。

不要為了消除錯誤而放棄檢查能力

遇到型別錯誤時，最省事的修法可能是使用過度寬鬆的型別，或忽略檢查。這能讓工具不再報錯，卻可能把原本應被發現的問題留到執行時。

審查 AI 修改時，可以觀察它是否保留了資料結構的描述。如果原本清楚的參數突然變成任何內容都可接受，應確認這個改動是否真的符合需求。

修正的目標應是讓程式與資料規則一致。當規則本身需要變更，也要說清楚理由與影響，而不是只把「沒有錯誤訊息」當成任務完成。

團隊怎麼讓更快的檢查帶來實際收益

檢查工具變快，最直接的作用是讓開發者比較願意在每次修改後執行。短回饋循環能讓錯誤更接近修改時刻，也比較容易知道問題來自哪一段程式。

可以先選一條常用指令作為起點，確認型別檢查與原有測試能順利配合，再逐步整理其他工作。這比同時改動所有指令，更容易找出相容性問題。

導入之後，觀察的是等待時間、錯誤發現時間與人工修正工時。如果檢查快很多，但工作描述仍不清楚，代理可能還是反覆改錯方向，整體效率就不一定改善。

這也是 Bun 更新對 AI 工作流程的啟發。工具提供更快的回饋，團隊則負責把回饋安排在真正會改變結果的位置，讓每次修改更容易被驗證。

bun check 常見問題

bun check 可以取代所有測試嗎？

不能。型別檢查與行為測試回答不同問題，前者檢查結構，後者核對指定情境的結果。登入、計費或資料處理等功能，仍需要相應的行為驗證。

最實用的安排，是先讓型別檢查找出明確結構問題，再跑受影響的測試。這樣可以減少測試前就能發現的錯誤，也保留功能層面的確認。

官方加速倍數適用所有電腦嗎？

官方數據來自指定專案與十六核心 Apple Silicon 裝置，不能保證其他硬體與程式庫得到相同倍數。自己的環境應保留相同條件做比較。

比較結果若與官方不同，先看檔案範圍與設定，再看硬體差異。速度數字只有對應到實際工作，才容易幫助團隊選擇。

可以用它產生 JavaScript 檔嗎？

官方把這項功能定位為型別檢查，不產生 JavaScript 或型別宣告檔。需要輸出成品的專案，仍應使用相應建置工具與流程。

把檢查與輸出分開安排，也比較容易理解失敗發生在哪個階段。檢查通過只是其中一步，最後檔案仍需要符合部署需求。

AI 改完後，最少應交代什麼？

可以要求它交代修改目的、受影響範圍、型別檢查結果與必要測試結果。若有未解決的既有問題，也應分開說明，讓工程師知道接手時還需要處理什麼。

一份可核對的工作紀錄，會讓 Bun 的快速檢查真正接進交付流程。程式生成再快，最後仍需要有人能看懂修改並確認結果。

先把一條常用指令接上型別檢查

導入時可以從一個熟悉專案開始，保存原本檢查結果，再比較 bun check 的錯誤與耗時。確認設定與範圍一致後，才把檢查放進日常執行指令。

代理修改程式時，也可以要求它保留檢查輸出與受影響測試的結果。這會讓工程師知道哪些部分已驗證，以及哪些問題仍需要接手。

Bun 的更新讓回饋更容易接近每次修改。把這個便利用在清楚的工作流程裡，才比較容易減少修正時間，而不是只得到一個新的速度數字。

想持續追蹤 AI 科技新聞與實用工具，可以免費註冊 AI 郵報會員，閱讀更多新功能的用途與實作解讀。

延伸閱讀：ThePrimeagen 改用終端機 AI 代理寫程式：AI 寫一半程式碼後，工程師的工作剩什麼？。

延伸閱讀：@poteto 引爆軟體工程論戰：AI 代理寫的程式碼，品質與資安該怎麼看？。

資料來源

Bun 一手資料、X 原始貼文。