Foundation Lab：把 Foundation Models 的提示、工具與執行紀錄放進同一個工作台

它填補的是 Foundation Models 開發過程中的觀察缺口

Apple 的 Foundation Models framework 把模型呼叫包成 Swift API，但調整的過程往往散落在各處：instructions 寫在一個檔案、sampling 參數寫在另一個、工具宣告又是第三份，跑完之後想看實際的 token 用量與時間，只能自己加 log。Foundation Lab 針對的就是這個缺口。它是一個原生 iOS 與 macOS 的 workbench，README 描述它的定位是把 prompt、configuration、tools、transcript 與 run evidence 留在同一個地方。

目標讀者是正在寫 Foundation Models 程式的人，不是只想試玩生成式 AI 的一般使用者。理由很直接：這個專案要求 iOS 26.0+ 或 macOS 26.0+、Apple Silicon、以及啟用 Apple Intelligence，門檻本身就篩掉了大部分人。它假設你已經知道 @Generable 是什麼，只是不想每次改一個參數就重新編譯整個 app。

Library、Playground、Runs 三個介面各自負責什麼

App 分成三個主要目的地，分工相當清楚。Library 是入口，裡面有 18 個可編輯 recipe、14 個 guided lab、三個 workshop、saved experiments 與一個 workspace。Playground 是編輯與執行的地方，可以改 prompt 與 instructions、設定模型與工具、串流回應、用語音輸入、存下實驗、以及匯出 Swift 程式碼。Runs 則是事後檢視，看的是 persisted run status、configuration、transcript events、tool calls、timing 與 token usage。

Library 的條目用開啟方式來分類，這一點值得注意。Recipe 會在 Playground 開啟，可以編輯、執行、儲存。Guided Lab 用的是針對特定 Foundation Models API 設計的專屬介面，也就是說它不能像 recipe 那樣自由改參數。Workshop 把相關的 schema、language 或 Xcode 27 範例群組在一起，不另外增加頂層目的地。Workspace 則開出專用工具，目前文件提到的是 Adapter Comparison。

這個分類法透露了設計者的取捨：他們不願意為了每一個示範再加一個 tab，所以用開啟行為來區分條目，而不是用功能類別。好處是頂層維持三個目的地，代價是第一次打開 Library 的人需要先讀懂這套規則，才知道哪些東西可以改。

建置與執行的實際指令，以及模擬器的硬邊界

取得專案的方式很標準：

git clone https://github.com/rudrankriyam/Foundation-Models-Framework-Lab.git cd Foundation-Models-Framework-Lab open FoundationLab.xcodeproj

命令列建置在 README 給了兩條，分別對 macOS 與 iOS Simulator：

xcodebuild -project FoundationLab.xcodeproj -scheme 'Foundation Lab' -destination 'generic/platform=macOS' CODE_SIGNING_ALLOWED=NO build

xcodebuild -project FoundationLab.xcodeproj -scheme 'Foundation Lab' -destination 'generic/platform=iOS Simulator' CODE_SIGNING_ALLOWED=NO build

這裡有個必須先講清楚的限制。README 明確寫著 live model execution 需要相容的實體裝置，模擬器建置只對編譯與介面驗證有用。換句話說，你可以用 CI 驗證這個專案編得過，但沒辦法在 CI 上跑任何一次真正的模型推論。這對想把它當成自動化評估管線的人是個硬牆。

Xcode 版本方面，專案同時支援 Xcode 26.6 與 Xcode 27。隨 OS 27 SDK 推出的 API 有編譯期與可用性的雙重 gating，所以核心 app 在 Xcode 26 下仍然可用，只是最新的 labs 要等 Xcode 27 才會出現。如果你現在還在 Xcode 26，這個專案不會逼你升級。

九個內建工具與需要確認的寫入行為

內建工具有九個 recipe，共用 FoundationModelsTools 這個 package：Open-Meteo 的天氣、Keyless Search1 網頁搜尋、Contacts、Calendar、Reminders、位置與地點搜尋、經授權的 HealthKit 資料、Apple Music、以及網頁 metadata。這些工具 recipe 會在 Playground 開啟，可以組合也可以移除。

README 提到一個重要的設計細節：會更動使用者資料的工具，必須透過 app 自己擁有的 workflow 進行確認。這不是模型層的權限控管，而是 app 層的確認流程。對於要評估 tool calling 的人來說，這個差別值得留意，因為它代表工具的安全性邊界畫在應用程式這一側，而不是模型這一側。

HealthKit 的部分另外有兩個應用範例：一個 HealthKit dashboard，以及一個只根據已授權 Health 資料來回答的 chat。後者的敘述用了 grounded only in authorized Health data 這個說法，範圍講得很死，這在處理健康資料時是合理的保守做法。

結構化輸出、RAG 與 Xcode 27 才看得到的實驗

在結構化輸出這一塊，文件列出 @Generable 模型與 @Guide 約束、動態 schema、巢狀物件、union、表單，以及 invoice extraction。多語言方面有多語言 session 與支援語言檢查。檢索方面則有 RAG 文件索引與語意檢索，用到的套件是 LumoKit 與 VecturaKit。

Xcode 27 之下另外展示了一批東西：PrivateCloudComputeLanguageModel、共用的 LanguageModel 執行、圖片附件與參照、顯式的 tool-calling 模式、動態 profile 與 reasoning 控制、transcript 檢視與 history transform、context-budget 視覺化，以及包含影片能力的 custom model executor provider bridge。

這份清單裡最容易被忽略的是 Tools/ImageInputProbe。README 說它可以量測當前 SDK 的實際 decoded-buffer 邊界。這是一個探針，不是功能，它的存在本身就說明圖片輸入的容量上限會隨 SDK 版本變動，而且官方數字不一定等於實測邊界。如果你打算做圖片附件相關的功能，這個探針比任何文件敘述都值得先跑一次。

Adapter Comparison 與 fmas CLI 的分工

在 macOS 上，Adapter Comparison 工作區可以匯入 .fmadapter 套件，把同一個 prompt 分別送進全新的 base-model session 與 adapter session，同時顯示兩邊的串流，並給出 time-to-first-token 與 total-duration 的診斷量測。這是這個專案裡少數直接給出比較數字的介面，而且它量的是延遲，不是品質。

訓練與匯出不在 app 裡，而在 companion 的 fmas CLI：

python3.11 -m venv .venv-fmas source .venv-fmas/bin/activate python -m pip install -e Tools/AdapterStudio fmas init fmas setup fmas train-adapter --help fmas export --help

完整的流程要看 Tools/AdapterStudio。這裡的架構選擇很明確：app 負責跑與看，Python 工具鏈負責訓練與打包，兩邊用 .fmadapter 這個格式當介面。好處是訓練環境可以獨立更新，代價是你得同時維護 Swift 與 Python 兩套環境。

另外要注意，afm CLI 已經搬到獨立的 Foundation-Models-Framework-CLI 儲存庫，使用公開的 FoundationModelsKit package，CLI 的發版節奏與 app 分開。安裝方式是 brew tap rudrankriyam/tap 之後 brew install afm。如果你的工作流是腳本化的，你要去的是那個儲存庫，不是這個 app。

什麼情況下這個工具不適合你

第一個明確的排除條件是硬體與系統。沒有 Apple Silicon、沒有啟用 Apple Intelligence、系統低於 iOS 26 或 macOS 26，live model run 就跑不起來，剩下的只有介面可以看。

第二個是自動化。這個專案是 GUI app，run history 存在 app 內，export 出來的是 Playground 的 Swift 設定，不是可程式化的評估報告。README 另外提到 FoundationModelsBench 是外部的品質、安全、工具使用與 on-device 評估專案。如果你要的是可重複、可進 CI 的評分，那個方向才對，Foundation Lab 的角色是人工探索。

第三個是 API 覆蓋的版本落差。Xcode 27 才有的那批實驗，包括 PrivateCloudComputeLanguageModel 與 custom model executor，在 Xcode 26 下根本看不到。若你的團隊短期內不會升到 Xcode 27，這個專案對你的價值就只剩下一半。

最後一點關於相依性。這個 app 依賴外部的 FoundationModelsKit，CLI 也依賴同一個 package。這代表上游的變動會同時影響 app 與 CLI，而這兩個儲存庫的發版是分開的。採用之前值得先確認這個 package 的更新節奏是否跟得上你預期的 OS 版本。

授權、維護成本與升級前該確認的事

授權是 MIT，這是寬鬆的條款，允許修改與再散布，通常只要求保留著作權聲明。實際的條款文字與適用範圍要看儲存庫裡的 LICENSE 檔案，這不是法律意見。

維護成本主要來自三個地方。第一是 Xcode 與 OS 版本的推進：專案同時支援 Xcode 26.6 與 27，靠 availability gating 維持相容，這意味著每次 SDK 更新都可能需要調整這些 gating。第二是外部相依：FoundationModelsKit 與 FoundationModelsTools 都是獨立演進的 package。第三是雙語言工具鏈：Swift 的 app 加上 Python 的 fmas，環境要各自維護。

升級前最該先確認的具體事項，是你要用的那批 API 落在哪個 Xcode 版本。README 把 Xcode 27 labs 單獨列成一節，這個分節方式本身就是答案：先看你的 Xcode 版本能不能看到那一節，再決定要不要投入時間。

編輯結論

如果你正在為 iOS 26 或 macOS 26 開發 Foundation Models 相關功能，而且需要反覆調整 instructions、sampling、reasoning 與工具組合，Foundation Lab 值得先 clone 下來當成對照組：它把 recipe、run history 與 transcript 事件放在同一個 app 裡，省去自己搭測試殼的工作。若你的目標是 CI 上自動化評估，這個 app 幫不上忙，因為 README 明講 live model execution 需要相容的實體裝置，模擬器只能用來驗證編譯與介面。動手前先確認三件事：你的機器是否為 Apple Silicon、Apple Intelligence 是否已啟用、以及你打算用的 API 屬於 Xcode 26 還是 Xcode 27 的 availability 範圍，因為 OS 27 SDK 的 API 是編譯期與可用性雙重 gated。

官方來源

1. Issues
2. License: MIT
3. README
4. Releases
5. rudrankriyam/Foundation-Models-Framework-Lab on GitHub