症狀： Claude Code 說發布步驟已完成，但你還沒有證據證明交付檔真的簽署、公證並可驗證。
最快解法： 把 Claude Code 當作工具操作助手；在權限受控、可清理的 macOS 執行環境中完成任務，並以簽署、公證及產物驗證的實際輸出作為放行依據。
這篇適合需要在沒有常駐 Mac 的情況下準備發布的獨立開發者、維護 Claude Code 發布流程的工程師，以及管理簽署憑據和遠端執行環境的平台管理員。若你只想了解如何從頭設定 Xcode 雲端建置，本文不會展開成建置教學。
先按發行渠道選擇驗收路徑
Mac App Store 發布與透過 Apple Developer ID 直接分發，是兩條不同的路徑。前者需按 App Store Connect 的上傳及審核流程處理；後者才是本文所說的 Developer ID 簽署與 macOS 公證流程。Apple 對 Mac 分發簽署和 App Store Connect 上傳分別提供了簽署說明與構建上傳指引，不要把兩種渠道的憑據、產物或放行條件混在同一套工作流裡。
| 發布選項 | 適用方式 | 主要驗收內容 | 你要先確認的事 |
|---|---|---|---|
| Mac App Store | 透過 App Store Connect 提交發行 | 上傳的構建、帳戶權限及審核狀態 | 使用的分發簽署方式與上傳帳戶是否符合團隊規範 |
| Developer ID 直接分發 | 將應用程式交付給 App Store 以外的使用者 | Developer ID 簽章、公證結果、票據及最終發行檔 | 憑據如何提供、公證工具與產物格式如何安排 |
Claude Code 可以依你的任務呼叫命令或協助整理結果，但不能替責任人決定採用哪個證書、核准憑據存取或承擔最後放行責任。Anthropic 的 Claude Code CLI 權限說明可供你核對核准模式與命令權限；實際設定仍應依團隊安全政策決定。
構建場景：先固定可重現的輸入
簽署之前，先確認發布任務真正要處理的應用程式產物。至少記下專案使用的構建入口、Xcode 或外部構建系統、依賴來源、目標架構，以及輸出位置。這些項目不是形式上的文件：如果 Claude Code 建置了不同分支、不同版本或不同架構的產物，後續即使簽署成功，也不代表你準備好的版本可以發布。
請讓流水線保存實際命令與輸出檔案位置。例如使用 Xcode 工具構建時，可在任務紀錄中保留呼叫的 xcodebuild 命令、結束狀態及產物路徑；若由其他構建系統產生 .app，也要記下對應版本識別資訊及檔案雜湊。命令形式應按照專案的 scheme、目的地及簽署設定調整，不能只因 Agent 回覆「build succeeded」就當作完成。
你可以把構建階段的交付證據分成三項：構建命令與退出狀態、可定位的 .app 或封裝產物、與發布版本相符的識別資料。缺少任何一項，就先查明產物來源，再交給簽署流程。
簽署場景：把憑據與工作目錄分開
Apple Developer ID 簽署需要由有權限的人確認簽署身分與使用範圍。私鑰、憑據密碼或 API 金鑰不應寫進程式碼庫、Claude Code 提示內容、建置日誌，或會被保留供下次任務重用的普通工作目錄。採用團隊核准的密鑰管理方式，在任務執行時提供必要憑據，並限制執行環境與任務的存取權。
注意：不要把「環境變數沒有顯示在畫面上」當作秘密已受妥善保護的證明。也要檢查除錯輸出、命令列參數、暫存檔與任務日誌，確認沒有意外留下憑據。
簽署後，應檢查應用程式本身及其內含的可執行檔、框架或其他需簽署元件。可使用 codesign --verify --deep --strict --verbose=2 /path/to/App.app 驗證簽章結構，並以 codesign -dv --verbose=4 /path/to/App.app 查看簽署資訊；對直接分發的應用程式，也要核對 Hardened Runtime 等所需設定。Apple 說明了分發簽署要求及 Hardened Runtime的用途。保留命令、輸出與產物版本對應關係，方便日後追查簽署身分或元件錯誤。
公證場景：把提交、接受與裝訂分開記錄
Developer ID 公證不是只看一個「成功」訊息。Apple 的公證流程包含提交待公證項目、取得處理結果，以及對適用的發行產物裝訂票據等環節；Apple 的公證說明與自訂公證工作流文件可用來核對目前工具與流程。
| 發布階段 | 可執行的核驗 | 應保留的證據 | 未通過時的處理 |
|---|---|---|---|
| 提交公證 | 以 xcrun notarytool submit 提交預定檔案；依團隊憑據政策選擇認證方式 |
提交識別資料、輸入檔案名稱及工具輸出 | 確認憑據、檔案格式與網路存取，再重新提交 |
| 查看結果 | 取得並檢查公證處理狀態；必要時用 xcrun notarytool log 讀取該次日誌 |
接受或拒絕結果、日誌內容與產物關聯 | 根據日誌定位簽署、執行檔或政策問題，不以摘要訊息代替 |
| 裝訂與驗證 | 對支援的最終發行檔使用 xcrun stapler staple，再以 xcrun stapler validate 驗證 |
裝訂輸出、驗證結果及發行檔識別資料 | 若裝訂或驗證失敗，暫停放行並確認操作對象與流程 |
實際使用時，憑據設定方式、命令參數與可裝訂的檔案類型，應依 Apple 當前文件和你的發行格式核對。不要把暫存提交檔、最終磁碟映像檔與安裝套件當成同一個驗收對象。Apple 另有Mac 軟體封裝說明，可協助你核對封裝產物與分發方式。
公證被接受之後，仍須檢查對應日誌、票據裝訂狀態及最終發行檔。若最後交付的是 .dmg 或 .pkg，請針對該交付檔確認驗證結果，不要只驗收較早階段的 .app。失敗時保存提交識別資料與完整日誌；這些內容比單獨截取 Claude Code 的文字回覆更能幫助你定位問題。
發布複核場景：以證據完成放行
在發布責任人批准前，平台或工程團隊應把驗收紀錄與實際交付檔逐項對照。以下項目若有一項無法確認，就暫停發布，而不是要求 Agent 再說一次「已完成」。
- 來源一致： 構建分支、版本識別資料及待發布檔案可相互對應。
- 簽署可驗： 應用程式和需簽署的內含元件已通過工具驗證，簽署身分符合發布渠道。
- 公證可追： 有對應的提交結果及日誌，且接受狀態屬於本次發行產物。
- 最終檔可驗： 票據裝訂與驗證針對真正交付給使用者的檔案完成。
- 權限已收回： 任務結束後檢查憑據是否已清理或撤銷，並確認日誌沒有洩漏秘密。
- 人工已批准： 有責任人記錄放行決定；Claude Code 的文字描述不構成批准紀錄。
這套驗收做法也方便你逐項辨認失敗發生在哪個場景：構建來源錯誤、簽署物件遺漏、公證拒絕，或最終封裝與已驗證產物不一致。把每一階段的輸入、輸出和責任人留在同一筆發布紀錄中，日後重建問題才有依據。
常見疑問
Claude Code 能自動替 macOS 應用程式簽署嗎？
它可以依任務設定呼叫簽署工具，但實際可做的動作取決於執行環境的權限與核准設定。證書選擇、憑據授權與最終驗收仍由責任人決定；請以 codesign 等工具對實際產物的輸出確認結果，而不是採信 Agent 的敘述。
雲端 Mac 上如何安全保存簽署憑據？
透過受控密鑰管理方式在任務期間提供憑據，將權限限制在必要的執行工作，並避免把秘密寫入提示詞、版本庫或持久工作目錄。任務完成後檢查清理或撤銷狀態，也要確認日誌與暫存檔沒有保留憑據。
macOS 公證成功後還要檢查什麼？
確認本次提交的結果與日誌，並檢查票據是否裝訂至正確的發行產物。再對實際交付檔執行相應驗證；若驗收對象由 .app 換成 .dmg 或 .pkg，不能沿用先前對另一個檔案的檢查結果。
簽署、公證和最後封裝應如何安排？
先建置並確認產物來源，再簽署應用程式與必要元件，之後依分發格式封裝並提交公證。取得接受結果後，對支援的最終發行檔裝訂票據並驗證。Apple 文件若因發行格式或工作流指定不同做法，應以適用的官方流程為準。
放行與雲端 Mac 選擇
如果你用一般 Linux 執行環境處理 macOS 發布，會缺少 macOS 原生簽署與公證工具鏈；若改用個人 Mac，則要自行維護系統、處理機器可用性，並確保任務憑據不與日常工作混用。既有遠端環境若缺乏清楚的存取與清理紀錄，也會增加稽核成本。需要短期完成發布測試或一次性上線時，租用雲端 Mac 可以作為受控執行環境的選項；長期固定重負載、必須連接實體裝置的工作，則應先比較自購設備是否更合適。
若你正準備遠端發布環境，可先查看 Kvmkit 的 Mac mini 租用資訊及服務說明，再依你的憑據政策與產物驗收方式評估環境。已有 Mac 的團隊，先用不含真實密鑰的測試專案跑完整個建置、簽署、公證與驗證流程；只有當每個階段都留下可核對證據，才把正式憑據與發布批准納入流水線。
常見問題
Claude Code 可以直接替應用程式完成簽署嗎？
Claude Code 可以依照指示協助呼叫建置、簽署或公證工具，但是否能執行會受本機權限與核准設定影響。你仍須確認使用哪個簽署身分、授權哪些憑據，並檢查工具輸出；Agent 回報成功不能取代對實際產物的驗證。
雲端 Mac 上的簽署憑據應放在哪裡？
不要把私鑰或密碼放進版本庫、Claude Code 提示詞或會長期保留的工作目錄。應透過受控的密鑰管理方式注入執行環境，並把存取權限限於必要任務；任務結束後確認憑據已移除或撤銷，再保存不含秘密的稽核紀錄。
公證狀態顯示成功後，還要驗收什麼？
先查看公證提交結果及對應日誌，再檢查票據是否成功裝訂到預定發行產物，並以 Apple 提供的驗證工具確認簽章與公證狀態。若你最後交付的是磁碟映像檔或安裝套件，驗收對象應是該發行檔，而非只看提交時使用的暫存壓縮檔。
應用程式簽署、公證與打包應按什麼順序進行？
先完成建置並確認產物，再為應用程式及需要簽署的元件簽署，接著按發行格式封裝並提交公證。取得接受結果後，對可裝訂的最終發行產物裝訂票據並再次驗證；若包裝方式或 Apple 當前文件要求不同，依該工作流調整，不要把提交成功當作發布完成。
把 CI/CD 放在 M4 Mac mini 上，才算真正省心
Xcode, Fastlane, CocoaPods, and SPM are first-class on macOS. Mac mini M4 unified memory keeps signing and archiving smooth; ~4W standby power suits 24/7 build nodes.