DAO-Code 安裝教學：5 分鐘跑通 macOS（2026）

這篇文章面向第一次在 macOS 安裝 DAO-Code 的開發者，將安裝流程拆成檢查、安裝、首次啟動與驗收四個階段。文中比較官方腳本、npx 與源码安裝，並說明 Apple Silicon、Intel Mac、DeepSeek API 及遠端 Mac 的選擇條件。

判斷框｜適合先用官方一鍵腳本，不適合一開始就研究 Docker 或 Xcode。 官方 README 列出原生二進位、npx、npm 與源碼安裝路線；對首次安裝者，我們建議先用官方腳本取得原生版本，臨時試用再用 npx，只有要修改 DAO-Code 源碼時才走源碼路線。DAO-Code 是呼叫 DeepSeek API 的跨平台終端編碼 Agent，不是 Web3 智能合約工具，也沒有官方證據要求 Docker、Xcode 或 Metal 本地推理。官方 README

這篇文章適合第一次安裝 DAO-Code、希望快速跑通首個任務的 macOS 使用者，也適合要在乾淨 Mac 上重現 AI Agent 環境的測試人員。若後續要長時間處理 iOS 或 macOS 專案，本文最後也會說明何時應改用遠端 Mac。

最後更新於 2026 年 9 月 3 日；版本與安裝方式核對自 DAO-Code Releases、master 分支 package.json、官方 README、install.sh 及 DeepSeek API 官方文件。

安裝前先分清 DAO-Code macOS 路線

先不要把前文流傳的 Web3、Docker、Xcode、Metal 說法當成安裝條件。以官方資料可確認的範圍來看，DAO-Code 的工作方式是由終端程式呼叫 DeepSeek API，再依照權限與審批流程執行編碼任務。它本身是跨平台工具；macOS 的必要性主要來自後續專案，而不是 DAO-Code 核心程式。

官方文件目前可辨識出三條路線：

• 官方一鍵腳本／原生二進位：首次安裝的首選。安裝步驟短，並可取得與作業系統架構相符的執行檔。
• npx：適合只想快速試用，不想立即把執行檔固定寫入安裝目錄的情況。
• npm 或源碼安裝：適合需要檢視、修改或除錯 DAO-Code 源碼的人，不是一般使用者的最短路徑。

這三條路線來自官方 README，而不是社群自行拼湊的安裝方案。若我們只想確認終端指令能否啟動，先選 npx；若要每天使用，選官方原生安裝；若要改程式碼，才建立源碼工作區。

Apple Silicon 與 Intel Mac 該怎樣選檔案？

先確認 macOS、Shell 與 CPU 架構

在終端機依次執行：

sw_vers
echo "$SHELL"
uname -m
echo "$PATH"

uname -m 顯示 arm64，代表 Apple Silicon Mac；顯示 x86_64，代表 Intel Mac。Apple 的通用 macOS 二進位文件也以 arm64 與 x86_64 區分 Apple Silicon 和 Intel 架構，下載時不能只看「Mac」字樣。Apple Silicon 架構說明

如果使用者在 Apple Silicon Mac 上透過相容層執行終端機，uname -m 可能回報 x86_64。這時先確認目前終端機是否以相容模式開啟，再決定下載檔案。不要因為機身是 M 系列，就跳過這一步。

Node.js 版本不要靠猜

若選 npx、npm 或源碼路線，再檢查：

node --version
npm --version

Node.js 的可用版本與安裝方式應以 DAO-Code 當日 README 為準；不要把網路文章中的舊版要求直接套用。Node.js 官方下載頁只負責提供 Node.js 發行版本，不能取代 DAO-Code 專案本身的相容性說明。Node.js 官方下載頁

截至本次核對，DAO-Code 正式 Releases 頁面標示 v0.4.7 為最新正式 Release，而 master 分支 package.json 顯示 0.4.17。這兩個數字不是同一個發行通道：正式使用應優先看 Releases 資產，測試 master 才接受開發分支可能變動的風險。這項區分可在 DAO-Code 的正式 Release 清單與 master 分支版本資料中交叉確認。

五分鐘按時間線完成官方安裝

第 0 分鐘：先讀腳本，再執行

官方 README 與 install.sh 是命令依據。不要把「管道執行遠端腳本」描述成零風險操作。我們建議先下載、閱讀，再執行：

curl -fsSLO https://raw.githubusercontent.com/tigicion/dao-code/master/install.sh
sed -n '1,240p' install.sh
chmod +x install.sh

逐行看清楚腳本會下載什麼、寫入哪個安裝目錄，以及是否會修改 Shell 設定檔。腳本內容應與官方 install.sh 原始檔一致；若本機看到的內容與官方版本不符，先停止，不要繼續。

第 1 分鐘：處理 macOS 隔離標記

若檔案由瀏覽器或其他來源下載，macOS 可能附加隔離標記。確認腳本來源後，再依官方流程處理：

xattr -d com.apple.quarantine ./install.sh 2>/dev/null || true
./install.sh

若系統要求輸入管理員密碼，先確認終端機目前目錄和腳本內容，再決定是否授權。權限提示不是可以無條件略過的錯誤；尤其在公司 Mac 或共用測試機上，應先確認使用者是否有權寫入安裝目錄。

第 2 至 3 分鐘：確認命令已進入 PATH

安裝完成後，重新開啟一個終端機視窗，或依腳本提示重新載入 Shell 設定，接著執行：

command -v dao
dao --version

command -v 沒有輸出，通常表示安裝目錄尚未加入 PATH，而不一定是 DAO-Code 沒有安裝成功。此時檢查 ~/.zshrc、~/.bashrc 或腳本提示的設定檔，避免把不同 Shell 的設定混在一起。加入 PATH 後，重新載入對應檔案，再重試上述兩個命令。

提醒： 不要只看到安裝程式結束就算完成。至少要同時記錄 command -v dao 的路徑與 dao --version 的版本；如果顯示的是 master 分支版本，便不能把它當成正式 v0.4.7 使用。

首次啟動怎樣設定 DeepSeek API？

第一次執行：

dao

按照首次引導輸入 DeepSeek API Key。API Key 應從 DeepSeek 官方 API Key 頁面取得，切勿把真實密鑰放進文章、截圖、Git 儲存庫或 Shell 歷史紀錄。若終端機顯示模型選擇或設定項目，請以當日 README 和 DeepSeek API 文件為準，不要硬填網路文章中的舊模型名稱。

設定完成後，DAO-Code 應將認證資料保存到它在首次引導中提示的設定檔位置。不同版本可能改變檔案名稱或目錄，因此我們不把未經官方文件確認的固定路徑寫死。若畫面沒有清楚顯示位置，可先執行：

dao --help

再按說明查看設定或診斷選項。若要檢查環境變數，不要直接輸出完整密鑰；只確認變數是否存在，並遮蔽值的中段。DeepSeek API 的請求格式、認證方式與錯誤處理，應以官方 API 文件為準。

三個遞進任務完成安裝驗收

我們不建議第一次啟動就讓 Agent 修改整個專案。按以下順序驗收，任何一層失敗都先回到上一層：

1. 只讀掃描

建立一個不含機密資料的測試目錄，要求 DAO-Code 列出檔案結構與讀取指定檔案。這一步只測試命令可呼叫、API 可連線及基本讀取權限。

1. 生成專案說明

要求它根據測試目錄產生 README 草稿或模組說明，但先不要覆寫既有檔案。檢查輸出是否指向正確目錄，並確認編碼、檔案名稱和內容都符合預期。

1. 受控命令執行

最後才測試一個無破壞性的命令，例如列出目前目錄或顯示 Git 狀態。當 DAO-Code 提示審批時，逐項確認命令、工作目錄與可能影響，再選擇允許或拒絕。

每次驗收都記錄四項資料：DAO-Code 版本、目標目錄、權限提示、任務輸出。只有 dao 可以正常呼叫、DeepSeek API 回應成功，而且審批流程按預期運作，才算安裝完成。API 能連線但命令權限失控，不能算通過。

常見限制與替代路線

DAO-Code 安裝失敗時，問題通常不在「是否安裝 Docker」。我們在排查時會先看以下限制：

• PATH 狀態不一致：安裝腳本寫入 zsh 設定，但目前 Shell 仍讀取 bash 設定，會造成命令找不到。
• 架構選錯：Apple Silicon 使用 x64 資產，或 Intel Mac 誤用 arm64 資產，可能在啟動階段就失敗。
• 權限範圍過大：直接允許 Agent 修改整個家目錄，會讓驗收難以追蹤，也增加誤改檔案的風險。
• 正式版與開發版混用：Release 的 v0.4.7 與 master 的 0.4.17 不能混作同一個版本判斷。
• 把後續 Xcode 工作誤當成核心依賴：DAO-Code 本身跨平台；只有當任務需要建置 iOS 或 macOS 專案時，才必須進入具備 Xcode 的 Mac 環境。

若只是短暫測試，決策條件很簡單：

• 若只需確認 Agent 能否啟動，選 npx，完成最小任務後移除測試痕跡。
• 若要每日使用且不改源碼，選官方原生安裝，並固定記錄正式 Release 版本。
• 若要修改 DAO-Code 本身，選源碼安裝，把開發分支與日常工作環境分開。
• 若需要 Xcode 建置、長時間執行，或本地 Mac 不便保持在線，把同一套驗收流程複現在遠端 Mac，不要強行把核心工具說成依賴 Docker 或 Metal。

本地 Mac 與遠端 Mac 怎樣作選擇？

DAO-Code 本身不要求 Docker、Xcode 或本地模型環境。可是，當工作從「跑一個終端 Agent」變成「持續處理 iOS、macOS 倉庫」，決策就不只看安裝是否成功。

如果您想先了解遠端環境的操作邊界，可參考我們的Mac 遠端使用與支援說明。若後續需要 iOS 或 macOS 建置，再查看遠端 Mac 開發環境方案，並把版本、目標目錄和驗收輸出一併保存。

本地方案的缺點是硬碟、記憶體、權限與在線時間都由開發者自行承擔；npx 方案則不利於長期版本固定；若使用一般雲端主機，又無法直接提供完整的 macOS 工具鏈。當任務需要 Xcode、長時間執行或反覆重置乾淨環境時，租用 ZekVPS 的遠端 Mac 通常比臨時改造本地設備更省排查時間。若只是偶爾跑一次只讀任務，留在本地或使用 npx 反而更合理；若要持續開發，再評估可重置的遠端 Mac 環境。

完成首次驗收後，建議把上述四項記錄整理成一份 DAO-Code Mac 環境驗收清單：架構、版本、PATH、API 設定位置、目標目錄與審批結果缺一不可。這份清單能讓您日後在另一台 Mac 或遠端環境重現相同流程，而不必重新猜測哪個檔案、哪個版本或哪項權限出了問題。