by Rain Chu | 9 月 20, 2026 | Agent, AI
本機 AI 的價值，不能只用「回答有沒有雲端模型聰明」判斷。當工作需要反覆讀取私人文件、呼叫工具，或同時執行多個任務，模型之外的資料流向、硬體安排與執行框架，也會影響實際成果。
DSH Privacy Router、NVIDIA PAIR、EXO 與 Perplexity Portable Computer，分別處理隱私分流、區網排程、模型分散運算與完整 Agent 工作流程。它們可以放進同一張架構圖理解，卻不是可以直接互換的產品。
本機 AI 先看三件事：資料、容量與工作流程
第一件事是資料能不能外傳。即使雲端模型能力更強，有些內容仍應留在自己的設備或信任的內部網路。第二件事是硬體能不能容納模型，以及能否在可接受的時間內完成工作。第三件事是模型以外的操作，像讀檔、搜尋、驗證與產出文件，有沒有完整流程。
這些問題需要分別處理。推論引擎負責執行模型，Agent 框架負責組織工具與任務，路由器則決定請求送到哪裡。還不熟悉這些層次，可以先看 本地大模型推論框架比較，再判斷自己缺的是哪一層。
DSH Privacy Router：先判斷哪些內容能送雲端
DSH Privacy Router 是 DeepSeek Harness 的 Host 端插件。它先用本機規則與模型檢查文字，分類為 public、sensitive 或 unknown。只有通過公開分類的請求才送雲端，敏感或不確定的內容留在本機。這是隱私導向的分流，不是單純把困難問題全部轉給大模型。
預設雲端上下文只包含本輪通過檢查的純文字、固定系統提示與空工具清單。專案文件說明，私有對話與本機工具結果不會直接附帶過去，雲端回答則直接串流回目前對話，不由本機模型再次改寫。開啟特定相容事件功能後，才可納入先前已核准的雲端對話。
公開程式可看到兩個關鍵控制：雲端分支只在分類結果為 public 時啟用，真正送出時會重新組合訊息，並把工具列表設為空。這比只在提示詞寫「不要洩漏資料」多了程式層的限制。不過，這仍不代表整個應用的所有網路流量都受到同一個插件管理。核對版本見 DSH 路由程式。
導入前要知道，這個公開儲存庫不包含展示用 Web UI 或 DSH 原始碼補丁。README 的介面展示屬於構想，不能把安裝插件理解成會立即得到完整視覺介面。先依文件設定可信任的本機 Provider，再確認實際連到的服務確實位於可信任環境。
自動發現本機算力，不等於自動信任任何設備
配套的 Local AI Discovery Server 用 mDNS／DNS-SD 宣告區域網路中的 OpenAI 相容 API，提供主機、連接埠、模型清單位置與認證需求等資訊。它負責讓服務被找到，本身不執行模型，也不是 API 代理。DSH 端仍需要對應的發現整合。
發現服務與信任服務是不同步驟。在家中看得到的端點，不代表公司文件就適合送過去，更不用說共享空間的陌生設備。評估時應確認設備由誰管理、是否使用認證，以及請求最後送往哪個端點。服務名稱帶有「local」，不能取代這些確認。
NVIDIA PAIR：把獨立請求分配給區網內的電腦
NVIDIA Personal AI Router，也就是 PAIR 目前以測試版提供本機推論路由，支援相容的 Windows、Linux、macOS 系統，搭配 Ollama 與 LM Studio。它的目標是讓應用使用單一入口，把多個推論請求分配給可用設備。實際平台與硬體組合，應以當前官方支援清單為準。
PAIR 不會把多台電腦的顯示記憶體合成一個大空間，也不會把同一個推論請求拆到多台執行。每個請求會交給一個符合條件的節點，該節點負責執行到結束。當多個 Agent 同時提出獨立請求時，其他設備才有機會分擔排隊壓力。
官方技術文件說明，排程會考慮節點是否在線、推論引擎是否可用、是否有指定模型，以及目前負載。節點經過配對後，通訊使用相互 TLS 驗證與加密。這解決的是信任節點之間的推論傳輸，不能延伸成 Agent 使用任何搜尋或外部工具都不會外傳資料。詳見 NVIDIA PAIR 技術說明。
若工作主要是一個接著一個的長推論，或只有一台設備裝了需要的模型，多加節點的效益可能有限。評估時要看整個任務完成時間，以及 Jobs 紀錄是否真的顯示不同節點處理請求，而不只看畫面上出現幾個 Agent。
EXO：把模型拆到多台設備，與 PAIR 的用途不同
EXO 的核心包含模型分片與分散推論，會考慮裝置資源及網路拓樸，讓單一設備放不下的模型有機會跨設備執行。README 介紹了 MLX、張量平行與 Thunderbolt RDMA 等能力，這和 PAIR 分派完整請求的做法不同。
分散推論需要設備交換資料，速度取決於模型、切分方式與實際互連。能容納更大模型，不代表每次回答一定更快，也不能直接把各台硬體的標示效能相加。想理解雙機部署的取捨，可延伸閱讀 雙機本地模型部署與實測整理，並分開看容量與速度。
截至 2026 年 9 月 14 日核對，EXO 的 平台支援文件 把 Apple Silicon macOS 列為已測試與維護的主要平台，Linux CUDA 與 DGX Spark 則仍列在規劃區。這不等於所有相關實驗都不存在，但不足以把 DGX Spark 支援寫成已成熟可用的標準路徑。
Portable Computer：把本機模型接成完整 Agent
Perplexity Portable Computer 的定位是本機優先的 Agent 軟體，不是一款 Perplexity 品牌硬體。官方發表資料以 DGX Spark 為首波設備，將模型、執行框架與工作紀錄放在本機，必要時再經授權使用搜尋、連接器或雲端模型。平台支援與訂閱資格會更新，安裝前應重新確認產品入口。
比起單純啟動模型，它更重視框架如何配合本機模型的能力：縮小核心工具集合、按需載入 Skills、整理過長上下文，以及加入結果驗證。官方研究也說明，工具執行受作業系統層的沙箱限制，沙箱不可用時不退回無隔離執行。參考 Perplexity 的本機優先 Agent 研究。
雲端顧問只接收核准的上下文並回傳文字建議，沒有直接操作本機檔案與工具的權限。是否開啟顧問，以及採手動或自動核准，由使用者設定。因此，「本機優先」仍須搭配實際的連外與核准政策來理解。
中文導讀也可參考 AI 郵報 Portable Computer 整理。其中的硬體需求、測試分數與上市資訊，應回到對應官方文件與測試條件核對，不宜直接推論成所有任務的表現。
四個方案怎麼分？先對照自己要解的問題
| 方案 | 主要處理的問題 | 不能直接推論的能力 |
|---|
| DSH Privacy Router | 判斷文字是否可送雲端並限制上下文 | 不能保證分類永遠正確或涵蓋所有資料出口 |
| NVIDIA PAIR | 把獨立推論請求分配到可用的區網節點 | 不合併顯示記憶體，也不切分單一推論請求 |
| EXO | 跨設備切分模型與分散推論 | 不代表任意平台組合都已支援或一定加速 |
| Portable Computer | 整合本機模型、工具、沙箱與授權連外 | 本機優先不代表開啟外部服務後仍完全離線 |
這張表依前述官方文件整理的是功能範圍，不是效能排名。若想組合使用，還要核對 API、模型格式、端點與執行框架是否相容，不能假設名稱都和本機 AI 有關就能直接串接。
隱私真正難的地方，是內容看起來不敏感
沒有姓名、電話或金鑰，不代表內容可以公開。例如尚未發表的產品構想、內部定價方法或獨特研究策略，就算去掉身分資訊，仍可能包含不應外傳的價值。這是自動隱私分類需要面對的限制，不能只用是否偵測到個資判斷。
DSH 用規則加模型檢查，Portable Computer 也描述了分類器與核准機制，但分類器仍可能漏判。對不可外傳的工作，應有明確的本機限定設定，以及實際阻止連外的權限或網路政策。對允許求助雲端的工作，則要看清楚送出的片段、歷史上下文與工具結果。
驗收可以從幾種情境開始：一般公開問題、含機密的文件、依賴前文的「繼續」、分類失敗，以及雲端要求呼叫工具。確認它們分別送去哪裡、留下什麼紀錄，並能追查答案由哪個模型產生。不要為了觀察系統又把完整機密複製進不受控的日誌。
開始之前，先用現有設備跑完一個真實任務
先挑一個可驗證的小工作，例如整理不含機密的測試文件，用現有設備與合適模型完成一次。若問題是模型服務與應用怎麼接，可以先參考 LibreChat 與 Ollama 的串接方式。等單機流程穩定，再處理分流與多機。
接著辨認瓶頸。獨立請求很多、都擠在同一台，才評估 PAIR。模型放不下，才研究 EXO 等分散推論路線。需要選擇哪些內容送雲端，再檢查 DSH 的分流設計。想降低工具、沙箱與任務流程的整合工作，則可評估 Portable Computer。
本機推論能減少按量 API 費用，但仍有硬體、電力、維護與等待時間。選擇性使用雲端，也可能產生額外用量。先量出自己的任務品質與完成時間，再決定是否擴充設備，會比從硬體規格開始更容易做出合適選擇。
本機 AI 路由常見問題
DSH Privacy Router 會把困難問題自動交給雲端嗎？
它主要依隱私分類分流，只有判定為 public 的請求才走雲端。敏感、不確定或無法分類的內容留在本機，不能視為單純依難度切換模型。
NVIDIA PAIR 能把多台電腦合成一張大顯卡嗎？
不能。PAIR 將獨立推論請求分派給符合條件的單一節點，不合併顯示記憶體，也不把一個請求切到多台電腦執行。
EXO 和 PAIR 差在哪裡？
EXO 包含跨設備模型分片與分散推論能力，PAIR 則分派完整的獨立請求。選擇前要先分清楚瓶頸是模型容量，還是同時有太多請求排隊。
Portable Computer 等於完全離線嗎？
不一定。核心工作預設在本機，搜尋、連接器與雲端顧問則可能連外。是否外傳資料，取決於開啟的功能、授權設定與實際送出的上下文。
本機 AI 一定能避免機密外洩嗎？
不能只靠模型位置保證。還要檢查服務端點、工具、搜尋、日誌與雲端升級路徑，自動分類也可能漏判不含個資的商業機密。
by Rain Chu | 9 月 19, 2026 | AI, 程式開發
用 AI 做網站或小工具，最讓人緊張的時刻，往往是原本正常的功能突然壞掉，請它修一下，又改出更多問題，最後連哪個版本能用都說不清楚。
Vibe Coding 想要改得放心，先要有能確認的版本紀錄，Git 負責保存程式變更，GitHub 提供遠端儲存庫與協作流程。你不必先背熟指令，但要能回答改動存在哪裡、是否進入主分支，以及復原會影響哪些內容。
這篇 GitHub 入門指南以能讀寫專案檔案的 AI 開發工具為情境，若使用 Lovable 這類 AI App Builder，也要先確認平台的版本紀錄、GitHub 同步與部署各由誰管理，避免把不同系統的「已儲存」當成同一件事。
Git 和 GitHub 差在哪？先分清楚存檔與提交
Git 是版本控制工具，可以在自己的電腦上運作，GitHub 則是託管 Git 儲存庫的平台，讓程式可以放到遠端、比較修改內容，再透過 Pull Request 討論與合併，使用 Git 不一定要使用 GitHub，也可以搭配其他託管平台。
按下編輯器的儲存，只代表檔案寫入磁碟，commit 才是建立一筆 Git 提交紀錄，通常記錄的是放入暫存區的內容，也就是這次選定要提交的變更，尚未加入版本控制、被忽略，或還沒選入暫存區的修改，不會因為做了一次 commit 就全部被保存，細節可參考 Git 官方的變更記錄說明。
因此，第一次請 AI 接手專案，可以先讓它檢查是否已有 Git 紀錄、目前在哪個分支，以及有哪些未提交的檔案，接著在功能確認正常後建立一筆容易辨識的提交，例如「完成登入表單驗證」，再開始下一輪修改。
先檢查這個專案的 Git 狀態，列出目前分支、最新提交，以及已修改和未追蹤的檔案。說明這次應保存哪些內容，排除密碼與無關檔案，再建立一筆清楚描述功能狀態的提交。
Commit、push、PR、merge，是不同的完成狀態
commit 留在本機，不代表遠端已有相同內容，push 把提交送到指定的遠端分支，也不代表改動已進入主分支，PR 是提出合併變更的請求，merge 才會把變更整合到目標分支。
採用 PR 流程時，要檢查 PR 指向哪個目標分支、狀態是 Open、Closed 還是 Merged，Closed 只表示請求關閉，不能直接理解成已合併，部分專案允許直接推送主分支，因此 PR 是一種協作與審查流程，不是所有 Git 專案的必經步驟，可參考 GitHub 的 Pull Request 說明。
還有一個容易漏掉的狀況：PR 已合併後，又把新提交推到原來的功能分支，push 可能成功，但後來的提交不會自動補進那次已完成的合併，要另外確認是否需要新 PR，或依專案流程再次整合。
儲存庫更新與網站上線也要分開驗收，GitHub 上看得到程式，不代表正式網站正在執行那一版，部署平台可能使用另一個分支，也可能建置失敗。像 用 Claude Code 製作網站的完整工作流，最後仍要回到實際網址確認功能與畫面。
上傳前檢查機密，補上 .gitignore 不會抹掉歷史
API 金鑰、資料庫密碼、含憑證的設定檔，不應直接放進提交，請 AI 同時檢查檔案清單與即將提交的內容，並依專案需要設定 .gitignore。私有儲存庫也應避免存放這些機密。
.gitignore 主要處理尚未追蹤的檔案，已經被 Git 追蹤的檔案，不會因為新增忽略規則就自動停止追蹤，既有提交中的內容也仍然存在，這是 Git 官方文件 明確區分的行為。
如果金鑰已經外洩，第一步是到服務提供者那裡撤銷或更換金鑰，再處理儲存庫內容與歷史，只把目前檔案刪掉，不能讓舊金鑰失效。歷史清理還可能影響協作者，應依 GitHub 的機密資料處理指引 安排。
換電腦與同步協作，clone 和 pull 各做什麼？
從 GitHub 下載 ZIP，取得的是某個版本的檔案快照，要延續既有 Git 開發流程，通常會用 clone 取得儲存庫與版本歷史，讓本機能追蹤遠端。只拿到 ZIP，不能直接假設原來的 Git 設定和提交紀錄也都在。
已有本機儲存庫後，pull 會抓取遠端變更，再依設定整合到目前分支，例如使用 merge 或 rebase，它不只是把遠端檔案下載覆蓋過來，同步前先確認分支、遠端，以及本機尚未提交的內容是否妥善保存，操作語意可查 git pull 官方文件。
發生衝突時，讓 AI 說明兩邊原本要保留的行為，再決定如何整合，即使沒有出現文字衝突，也可能發生功能上的衝突。例如一邊調整登入流程，另一邊改了權限判斷，合併成功後仍要把兩個情境都測過。
兩個 AI 同時改專案，先分開實際工作目錄
同時開兩個 AI 視窗，不等於它們各有一份檔案。如果都在同一個工作目錄，一方存檔、切換分支或整理暫存內容，仍可能干擾另一方。只有不同任務名稱或分支名稱，也不足以證明工作檔案已隔離。
Git worktree 可以讓同一個儲存庫擁有多個工作目錄，分別檢出不同分支。
例如一份處理登入，一份調整版面，完成後再逐一審查與合併。它們有各自的工作檔案與部分狀態，但仍共享儲存庫資料及部分參照，不能把它當成完全獨立的安全沙箱。詳見 Git worktree 官方文件。
要確認的，是每個 AI 實際使用的 worktree 根目錄與分支，若測試會共用資料庫、輸出位置或服務連接埠，也要另外安排。想把這套分工放進操作介面，可以延伸閱讀 Orca ADE 的多 Agent 與 worktree 工作方式。
開始平行開發前，請列出每個任務的實際 worktree 根目錄、分支及修改範圍，確認彼此不會寫入同一份工作檔案，並檢查測試資料庫、輸出資料夾與連接埠是否共用。完成後逐一提交、驗證與合併。
AI 改壞了怎麼復原？先辨認改動在哪個階段
先暫停繼續修改，保留目前差異，再確認錯誤改動是否已提交、推送或合併。直接對 AI 說「全部還原」，容易連原本想保留的工作也一起丟掉。
restore 用來恢復指定檔案的內容，但來源要說清楚，未指定來源時，一般工作目錄還原預設取自暫存區，不一定是最後一次提交，使用 --staged 則是調整暫存區，預設來源為 HEAD，並不等於刪除工作檔案，會覆蓋工作目錄的還原操作可能丟失未提交修改，執行前要確認路徑、來源與備份。參考 git restore 官方文件。
revert 則是用新的提交，抵銷指定舊提交帶來的變更，它保留既有歷史，常用在已分享的提交，但可能遇到衝突，也不代表整個專案必然回到某個舊時間點，若要修正遠端主分支，新的復原提交仍需依流程推送、合併與部署。參考 git revert 官方文件。
檔案突然不見，也不能立刻認定永久刪除，可以先查是否切到別的分支、內容是否被放進 stash，或是否有提交紀錄與編輯器備份，不過，從未提交也沒有其他備份的內容，Git 並不保證能救回。
先不要執行會丟棄修改的操作，請查明問題改動是否已提交、推送與合併，保留目前差異，列出建議復原的檔案、來源版本及會失去的內容，再說明應使用檔案還原、復原提交或其他方法，並列出復原後的驗證項目。
Diff 要看什麼？先問比較的是哪兩個版本
看到大量新增或刪除行數，先確認比較範圍，GitHub PR 採用三點差異比較，從共同祖先到功能分支目前版本，重點是這個分支引入了什麼，直接比較兩個分支的最新狀態，得到的內容可能不同，尤其主分支已經往前更新時，參考 GitHub 的分支差異說明。
行數只是定位問題的線索，格式調整、自動產生的檔案或重新命名，都可能讓變動看起來很大。
更實際的檢查是：改動是否符合這次需求、是否碰到無關檔案，以及重要功能有沒有測過。
把「完成了嗎」改成一份可查證的交付回報
對非工程背景的人來說，最有用的習慣，是要求 AI 在每次交付時附上可以追查的狀態。下
面這段可以直接加入日常任務：
請用非工程師看得懂的方式回報這次交付，列出本機分支與最新提交、遠端分支是否已包含這次變更、PR 連結與合併狀態．若有多個 AI，列出各自的實際工作目錄。說明差異比較的基準、改了哪些檔案，以及哪些測試或操作情境已通過。若涉及網站上線，另附部署結果與實際驗證網址。沒有完成的步驟請明確標出。
從下一次小修改開始，先保存已確認正常的狀態，再讓 AI 動手。完成後看差異、驗證功能，最後確認遠端與部署狀態。這套習慣建立起來，才能在出錯時知道從哪裡查，而不必每次都靠重做。
GitHub 與 Vibe Coding 常見問題
不會寫程式，也需要學 Git 嗎？
使用 AI 修改專案時，至少應理解提交、分支、遠端與復原的差別，指令可以交給工具執行，但仍要能確認保存了什麼，以及哪些步驟尚未完成。
Commit 成功就代表已上傳 GitHub 嗎？
不代表。commit 建立本機提交，push 才會把提交送到指定遠端分支，是否合併到主分支，以及是否部署成功，都要另外確認。
PR 已合併後，再 push 就會更新主分支嗎？
不會自動更新。推到原功能分支的新提交，不會追加到先前已完成的合併，應依專案流程建立新 PR 或再次整合，確認新變更已進入目標分支。
Restore 和 revert 有什麼不同？
restore 恢復指定位置的檔案內容，必須確認來源與是否覆蓋未提交修改。revert 以新提交抵銷舊提交的變更，保留歷史，但可能需要處理衝突。
Worktree 可以完全避免兩個 AI 互相干擾嗎？
不能保證。不同 worktree 可分開工作檔案，但仍共享部分 Git 資料，外部資料庫、服務與輸出位置也可能共用，應確認目錄、分支與執行環境的分工。
by Rain Chu | 9 月 18, 2026 | AI, 模型
模型蒸餾，是用教師模型提供的學習訊號訓練學生模型，讓學生在指定任務上學會更好的判斷與回應。常見目標是把能力轉移到較容易部署的小模型，降低使用時的資源需求。它需要新的訓練過程，效果取決於教師、學生本身的能力，以及準備了什麼資料。
理解這件事，最有用的起點是分清楚兩種做法：讓學生學教師的機率分布，以及讓學生學教師產生的完整答案。這也能解釋為什麼同樣叫蒸餾，有的需要取得模型內部輸出，有的只靠生成文字就能進行。
模型蒸餾是什麼？教師提供訊號，學生更新參數
Hinton、Vinyals 與 Dean 的知識蒸餾論文提出用大型模型或模型集成的預測分布，訓練另一個容易部署的模型。學生學習的是教師在不同輸入下的行為，不必照抄教師的架構，也不是把教師權重直接截取一部分。
一般離線蒸餾會先準備好教師，再固定教師的參數，由學生反覆預測、計算差距、更新自己的參數。完成訓練後，學生可以獨立推論。若產品另外設計了雲端備援，那是部署流程的選擇，並非蒸餾必然要求。
軟標籤：除了正確答案，還學選項之間的關係
以辨識貓、狗與汽車為例，人工標籤可能只寫「貓」。教師除了選出貓，還會對其他類別給出機率。狗的可能性高於汽車，透露出這張照片在模型眼中更接近哪類事物。這種帶有相對關係的訊號，就是軟標籤的價值。這裡是概念示例，並非實測數據。
經典做法會調整 softmax 的溫度，讓機率分布更平滑，使原本很小的機率差異更容易參與學習。溫度過高也會讓分布過於平均，因此仍需驗證。它不是「溫度越高，學生就越聰明」的設定。
PyTorch 官方教學示範把兩種訓練目標加權：一種要求學生接近教師分布，另一種要求學生符合真實標籤。分布差距可透過 KL divergence 等目標衡量。訓練時仍應保留正確答案的約束，教師的自信不等於答案一定正確。
實作時，直接比對逐 Token 分布通常還需要處理詞彙表、Tokenizer 與序列位置的對齊。光是教師和學生都能生成中文，並不足以保證它們的機率陣列可以直接相減。
回答蒸餾：把教師輸出變成學生的訓練資料
另一條路徑是先讓教師回答問題，整理成「輸入與目標回答」的資料集，再用監督式微調訓練學生。學生逐步學習如何產生這些答案，不需要拿到教師的全部權重。若服務只提供文字輸出，也可能採用這種方式，前提是取得與使用資料的條件允許。
Sequence-Level Knowledge Distillation在機器翻譯研究中，探討把整段生成序列作為蒸餾訊號。放到語言模型的應用裡，資料可以包含回答格式、分類結果、解題步驟與工具使用範例，但具體要教什麼，仍由資料與訓練目標決定。
例如，希望學生整理客服工單，就應準備真實會遇到的問法，要求教師產生正確分類、摘要與缺漏欄位，再經規則或人工檢查。只收集漂亮、流暢的回答，未必能教會學生處理錯字、矛盾敘述與資訊不足。這是本文用來說明資料設計的應用示例。
DeepSeek-R1 的蒸餾模型，為什麼會叫 Qwen 或 Llama？
DeepSeek-R1 官方模型卡說明，Distill 系列以 Qwen 與 Llama 的既有模型為基礎，使用 DeepSeek-R1 生成的樣本進行微調。名稱同時反映了提供訓練訊號的來源，以及學生採用的基礎模型。
因此，DeepSeek-R1-Distill-Qwen 不是把完整 R1 的參數切小，也不能直接當成 R1 的量化版。挑選時應確認學生模型、適用任務、Tokenizer 設定與部署需求。官方基準測試能提供參考，但不能推論小模型在所有領域都等同教師。
蒸餾、微調、量化與剪枝，各自在改什麼？
微調著重於用資料更新既有模型。蒸餾著重於知識訊號來自教師，兩者可以同時成立。用教師生成的答案微調學生，就是常見的交集。LoRA則是透過低秩更新降低需要訓練的參數量，是微調方法之一，本身不代表模型已完成蒸餾，也不等於把基礎模型縮成更少參數。
量化著重於數值表示的精度。Hugging Face 量化文件說明，較低精度的權重表示能降低記憶體需求，並盡量保留準確度。參數量可以不變，但每個權重佔用的空間減少。量化後是否更快，還要看硬體、運算支援與實際負載。
剪枝著重於移除或遮蔽部分權重與結構。PyTorch 剪枝教學展示了不同剪枝方式。權重變成零，不保證一般推論程式就會自動跳過運算。要換成實際加速，仍需相應的結構或稀疏運算支援。
這些方法可以組合，例如先訓練出合用的學生，再評估量化部署。想把概念接到本機環境，可延伸閱讀Qwen 本地部署與 GGUF 設定，但不同模型與硬體的需求要分別核對。
API 已經夠方便，什麼情況還值得蒸餾？
判斷方式是先看工作量與限制。若需求經常改變、使用量不大，直接使用現成模型可能更省事。若每天反覆處理相近任務，而且對回應時間、併發量、離線使用有明確要求，才值得把學生模型列入比較。這是部署規劃上的判斷，並非固定的成本結論。
比較時要把整段使用週期算進去，包括教師生成資料、資料審查、訓練、評估、硬體、維運，以及學生失敗後的重試或轉接。單次推論便宜，不能代表整個專案一定便宜。反過來，網路速度很好，也不會消除資料處理範圍與服務可用性的需求。
開始訓練前，先測未蒸餾的小模型是否已經夠用。如果簡單提示詞或現成模型就能完成工作，便沒有必要為了使用蒸餾而建立訓練管線。需要測試不同本地與雲端模型時，可參考LibreChat 與 Ollama 的整合方式，用同一批任務比較實際結果。
本地蒸餾模型的隱私，要沿著資料流檢查
學生在本機推論，確實可以減少把使用者輸入送往外部服務的需要。不過，隱私取決於整個系統如何傳遞與保存資料，不能只看模型檔案放在哪裡。
先看訓練前的資料準備。如果把內部文件送給雲端教師生成範例，資料在這一步就已經離開本機。再看實際使用時，是否另有雲端搜尋、遠端 Embedding、外部工具、遙測或日誌服務。最後看備援路徑，學生答不好時若自動轉給雲端大模型，轉交的問題、文件與歷史對話仍可能外傳。
有資料不外傳的要求時，應設計為本地處理、明確拒答或交由內部人員處理。允許混合部署時，則應先定義可外傳的資料範圍，並告知使用者何時轉交。把「本地模型」當作隱私保證，容易漏掉真正的資料出口。
實作蒸餾，先定義任務，再決定要不要訓練
以下是依前述方法整理的實務流程，適合用來規劃第一個小型試驗，不代表所有專案都需要同一套訓練參數。
先建立基準與驗收題目
選一個邊界清楚的任務，例如工單分類或固定欄位擷取。先測現成學生模型和教師各自的表現，定義正確率、格式完整性、回應時間與可接受的失敗方式。測試題目應與訓練資料分開，也要包含少見與資訊不足的情況。
生成範例後，先檢查品質
教師輸出需要去重、檢查事實、移除敏感內容，並確認符合任務規格。對答案可直接驗證的題目，優先使用程式規則或單元檢查。若蒸餾的是解題步驟，也不能只檢查最後答案正確，就認定中間推導全部可靠。
選擇訓練訊號，保留比較組
只有教師文字輸出時，可從回答資料微調開始。能取得分布且處理好對齊時，再評估軟標籤蒸餾。進一步的GKD 方法會讓學生在自己生成的序列上取得教師回饋，處理訓練資料與學生實際生成行為之間的差異。方法更複雜，並不代表每個任務都需要採用。
驗證泛化能力，再測實際部署
The False Promise of Imitating Proprietary LLMs在其研究設定下發現，模仿模型可以學到很像教師的回答風格，卻未必同步取得相同的事實能力。這項結果提醒我們，應檢查資料覆蓋之外的任務，不能只以流暢程度驗收，也不宜把該研究解讀成所有蒸餾都無效。
完成離線評估後，還要用目標硬體測記憶體、延遲與同時請求的表現。如果任務需要查詢經常更新的內部資料，可考慮讓模型搭配檢索，而非每次更新文件都重新蒸餾。站內的CrewAI 與 RAG 概念整理可作為理解工具與檢索分工的延伸閱讀。
模型蒸餾常見問題
模型蒸餾就是把大模型壓縮成小檔案嗎？
蒸餾是用教師訊號訓練學生，模型檔案大小取決於學生架構與數值精度。若只改變權重精度以縮小檔案，通常是在做量化。
只有教師模型的 API，也能做蒸餾嗎？
若 API 提供的輸出及使用條件允許，可以收集教師回答來微調學生。這與取得完整機率分布後進行的軟標籤蒸餾不同。
蒸餾後的小模型一定和大模型一樣強嗎？
不一定。效果受學生原本能力、資料覆蓋與任務影響，必須使用獨立題目評估，不能只看回答是否流暢。
Token 成本低，還需要自己蒸餾嗎？
未必。先比較現成模型是否夠用，再看使用量、延遲與離線需求。成本需要包含資料準備、訓練和維運，不能只看單次推論。
把小模型用在能驗收的任務上
蒸餾最值得關注的成果，是學生能否在你的任務上穩定達到要求，同時讓部署更容易。先建立現成模型的基準，找出缺口，再決定要準備什麼教師資料。當品質、速度與整體成本都有實際驗證，才能判斷這次訓練是否值得。
by Rain Chu | 9 月 17, 2026 | AI, 模型
Ornith 1.5 把本地 AI 的一個老問題攤得很清楚：每秒吐出多少 token，和最後有沒有把工作做完，是兩回事，35B-A3B 版本靠 MoE 架構降低每個 token 的運算量，在公開實測中展現速度優勢，也出現思考太久、額度用完卻沒交出程式碼的案例。
如果你想找一顆接在本地程式代理後面的模型，Ornith 1.5 35B 值得列入測試，評估時要一起看量化格式、記憶體餘裕、工具相容性與任務完成率，下面先拆開「自我改進」的意思，再看官方評分、兩組不同硬體的實測，以及實際上手順序。
Ornith 1.5 更新了什麼？先分清楚三種模型
Ornith 1.5 家族包含 9B Dense、35B MoE 與 397B MoE。手機部署的主角是 9B-Mobile 量化版本，與旗艦商用模型比較的宣傳則主要圍繞 397B。本文聚焦中間的 35B-A3B，不能把另外兩款的部署條件或成績直接套過來。版本資訊可從 官方模型集合查看。
如果你看過 Ornith 1.0 的自我拆解任務方式，這次最主要的延伸是把「生成訓練任務」也納入改善流程。
自我改進發生在訓練期間，下載後不會自動改寫權重
依照 Ornith 官方技術說明，模型在訓練中依序扮演三個角色：先根據程式庫與過去解題紀錄出題，再安排工具、指令與拆解方法，最後嘗試解題。結果回饋到強化學習流程，讓題目、執行安排與解法一起改善。
出題也有條件：題目要能驗證、難度合適，而且不能一直重複，官方把目標成功率設在約 20%，讓模型練習有挑戰但仍可能解出的題目。這個百分比是訓練課程的設計目標，不是產品的答題正確率。
可以把它想成練習寫程式時，不只修答案，也回頭調整練習題與測試方式。
下載回來的則是訓練後的模型權重，日常對話、保存記憶或反覆提示，不代表權重正在持續更新。
AlphaLab 對自我改進邊界的分析也提醒，環境與評分規則仍由人設計，分數上升還要確認是否真的學會解題。
35B-A3B 的 A3B，不是記憶體只要放下 3B
MoE 每次只選部分專家參與計算，但其他專家的權重仍要有地方存放。活躍參數主要影響每一步的運算量，總權重與快取才是估算記憶體的起點。官方 35B 模型頁列出約 3B 活躍參數，BF16 權重約 70GB，原生上下文為 262,144 token，模型規格與啟動範例可作為設定依據。
以目前 官方 GGUF 檔案清單為例，Q4_K_M 單一模型檔約 21.71GB，換算約 20.22GiB，這還沒加上推論引擎、上下文快取或視覺投影檔，因此「有 24GB 顯示記憶體」只能作為測試起點，不能直接承諾長上下文與多個並行任務都放得下。
12GB 或 16GB 顯示卡若想跑這個 Q4 檔，通常還得規劃部分權重放在系統記憶體，或改用其他量化版本，能載入模型、能順利對話、能在長任務中維持速度，應分開驗收。Mac 使用統一記憶體，也要預留系統空間，可搭配 本地 AI 的記憶體與頻寬選擇理解這個差別。
官方評分顯示程式能力進步，但要連測試框架一起看
以下是官方模型卡中同尺寸模型的部分成績。
Ornith 1.5 的結果為團隊自報的五次執行平均，並非本文重跑，也不等於所有電腦都會得到相同結果。
| 測試 | Ornith 1.5 35B | Ornith 1.0 35B | Qwen3.6 35B |
|---|
| Terminal-Bench 2.1／Terminus-2 | 67.8 | 64.2 | 52.5 |
| SWE-bench Verified | 79.0 | 75.6 | 73.4 |
| SWE-bench Pro | 59.6 | 50.4 | 49.5 |
資料來源：Ornith 35B 官方模型卡。各項測試使用各自的評測設定，不能相加成通用能力分數。
Terminal-Bench 的上述結果使用 Terminus-2，SWE-bench 使用 OpenHands。工具、提示、可用時間與上下文都會影響代理表現。「追平 Claude Opus」應限於官方列出的特定 397B 比較，無法據此宣稱 35B 全面取代商用模型。
對上 Qwen3.8 27B：生成得快，整個任務卻可能更慢
DIY Smart Code 的 Benchy 本地測試使用 RX 7900 XTX 24GB、Ryzen 9、64GB 系統記憶體與 Ollama，比較兩款 Q4 模型。Ornith 測試標示 32K 上下文。這是作者自建測試集的一組案例，量化檔案與測試工具的細節限制了外部重現，不能當成通用排名。
| 同一組 Benchy 案例 | Ornith 1.5 35B | Qwen3.8 27B |
|---|
| 通過項目 | 18／21 | 20／21 |
| 生成速度 | 約 74 tok/s | 約 58 tok/s |
| 提示處理速度 | 約 850 tok/s | 約 240 tok/s |
| 整組耗時 | 約 26 分鐘 | 約 17 分鐘 |
資料來源：DIY Smart Code，2026 年 8 月 22 日公開案例。數值依逐字稿約數整理，並非本文實測。
最有參考價值的是 DAG 非同步任務排程題：Ornith 花了約 18,000 個思考 token，耗盡輸出額度後沒有交出最終 Python 程式，Qwen 則完成程式並通過該題檢查。所以每秒輸出較快，仍可能因為思考與重試較多，拖長整個工作的時間。
這也不能反推成所有 MoE 都不擅長推理，或 Qwen 永遠比較穩，模型、量化、引擎與題型都不同，架構本身不能單獨解釋全部差異，要比較自己的程式任務，可參考 Qwen3.8 27B 本地部署教學，固定測試條件再重跑。
雙 GB10 的 NVFP4 實測：減少搬運，也能讓解碼加速
CyberQ 的雙 GB10 實測是在另一套硬體與 vLLM 環境中比較 BF16 與 NVFP4。它固定解碼 800 token，暖機後取三次量測中位數，因此較適合觀察格式差異，不適合直接和前面的 Ollama 成績排高低。
| 雙 GB10／TP=2 | BF16 | NVFP4 |
|---|
| 解碼吞吐量 | 48.41 tok/s | 101.86 tok/s |
| 12,001 token 提示處理 | 2,767 tok/s | 4,141 tok/s |
解碼約為 2.10 倍。這是特定硬體與引擎的量測結果。
該測試的 NVFP4 路徑先以低位元格式搬運權重，再反量化計算。當瓶頸是記憶體頻寬，減少搬運量就可能抵銷反量化成本。這是推論效率改善，不能解讀成硬體原生算力增加。
品質抽查中，兩種格式在 AIME 2026 都完成並答對 23／30 題，各有 7 題被輸出上限截斷。兩邊共同完成的 22 題答案一致，但答案一致不代表逐 token 的思考過程相同，也不能延伸成量化完全不損失品質。
本地部署怎麼開始？先讓短任務與工具呼叫跑通
先選權重格式與執行工具。桌面試用可從 GGUF 與 Ollama、llama.cpp 相容工具開始，伺服器則參考官方 vLLM 或 SGLang 範例。還不確定差別，可先看 本地大模型推論框架比較。
下載時認明 原始模型庫、官方 GGUF與 官方 NVFP4。另有 AtomicChat 的 GGUF 轉換版本可比較，請記錄實際檔名與量化等級，同樣寫 Q4 不表示所有檔案與執行結果完全相同。
測試時先縮短上下文、一次處理一個請求，確認記憶體與基本輸出正常，再逐步拉長。官方雖提供延伸到約 1M token 的設定，卻也提醒長上下文縮放可能影響一般長度的品質，不必第一次啟動就把視窗開到最大。
接代理前，再測試工具名稱、參數、工具結果回傳，以及模型能否繼續下一步。模型能輸出 tool_calls，只代表這段格式可用，MCP 伺服器還需要由代理程式接上。純聊天成功，不能代替完整工具流程驗收。
最後設定整個任務的時間、輸出與重試上限，並檢查所用引擎是否支援獨立思考額度。只縮小總輸出上限，可能更早截斷最終答案。日常試用可先用幾個有明確驗收條件的小任務，比較完成時間、人工修正量與失敗原因，再決定是否放入長時間自動化工作。
授權與手機部署，哪些說法還要保留？
T客邦的發布報導有助於了解系列定位，但授權敘述與官方 metadata 不一致。
本文以官方模型頁標示的 MIT 為準。
同樣地，9B-Mobile 支援行動裝置的宣稱，不能保證每一款手機都有足夠可用記憶體、支援對應模型格式，或能維持長上下文。先確認使用的 App、量化檔與裝置條件，比直接照搬桌面版的速度數字有用。
常見問題
Ornith 1.5 35B-A3B 是只有 3B 參數嗎？
不是。它是 35B 級 MoE 模型，每個 token 約啟用 3B 參數。儲存與載入仍需考慮完整權重，以及快取和引擎額外用量。
Ornith 1.5 放在本地使用會自己越來越聰明嗎？
官方的自我改進是訓練流程。下載後一般執行推論，不會因為聊天次數增加就自動更新模型權重。
24GB 顯示卡一定能跑 35B 的完整上下文嗎？
不能保證。官方 Q4_K_M 檔約 20.22GiB，還需預留引擎與快取空間。應從短上下文實測，再逐步調整。
Ornith 1.5 和 Qwen3.8 27B 該選哪個？
先用自己的任務比較。公開 Benchy 案例中 Ornith 生成較快，Qwen 通過較多項目。這組結果只適用於該測試條件。
這是美國團隊所推出的模型
Ornith 支援工具呼叫，就能直接連 MCP 嗎？
還需要代理程式與 MCP 連接層。應測試參數格式、工具執行與結果回傳的整個流程。
先看能否完成你的工作，再看分數有多高
Ornith 1.5 值得研究的地方，是它把練習題、工具安排與解法放進同一條訓練流程。而對本地使用者來說，35B-A3B 的實際價值仍要靠任務驗收：能不能在現有記憶體內跑穩、工具是否接得上，以及等待之後有沒有拿到可用成果。
先挑幾個你每週真的會做的工作，讓 Ornith 與現有模型各跑一次。保留設定、耗時與失敗紀錄，往往比看一張總排名更容易做出選擇。若想了解前述測試工具的設計，可再看 Benchy 測試工具建置說明。
by Rain Chu | 9 月 16, 2026 | Docker, MIS
學 Docker 時，很容易先記住一串指令，等到遇上「明明 build 成功，服務卻沒有更新」，才發現還有一些觀念需要釐清。
這篇從一條常見的建置指令出發，記錄映像、標籤、建置範圍與快取的關係，再整理部署時值得注意的七件事。範例使用通用的 Python API 專案名稱，方便套用到自己的環境。
一、先看懂這條指令
假設專案根目錄叫做 my-project，在該目錄執行：
docker build -t demo-api:1 -f api/Dockerfile .
| 指令片段 | 意義 |
|---|
docker build | 依照 Dockerfile 建立映像 |
-t demo-api:1 | 將映像命名為 demo-api，標籤設為 1 |
-f api/Dockerfile | 指定要使用的 Dockerfile |
. | 以目前目錄作為建置範圍，也就是 build context |
docker build：依照配方製作映像
Dockerfile 描述建置步驟；image（映像）是產物；container（容器）則是由映像建立、可以啟動的執行個體。
常見指令包括：
FROM：選擇基礎映像，開始一個建置階段。RUN：在建置過程執行命令，例如安裝套件。COPY：將檔案複製到映像內。CMD：設定容器啟動時預設執行的命令。
映像由多個檔案系統層組成，但不能把「每條 Dockerfile 指令」都當成「新增一層檔案」。例如 CMD、ENV 主要記錄設定；FROM 則引入基礎映像。可參考 Dockerfile 官方說明。
-t demo-api:1：給映像一個容易引用的名稱
demo-api 是映像名稱，1 是 tag（標籤）。標籤由使用者自行命名，Docker 不會因為寫了 1，就自動幫你維護版本歷史。
如果再次使用同一標籤建出不同映像，demo-api:1 會改為指向新映像。舊映像若沒有其他標籤，可能顯示為 <none>；若仍被容器引用，就不能直接當作可清除的垃圾。
已存在的容器不會因為 tag 改指向新映像，就自動換版本。
實際發布時，可以改用 demo-api:1.0.1 這類明確標籤，並約定不覆寫已發布版本，讓追蹤與回復更容易。標籤本身是可變的引用，詳見 Docker image tag。
-f api/Dockerfile：選擇配方的位置
在本文這種本機目錄建置方式中，未指定 -f 時，Docker 預設使用 context 根目錄下的 Dockerfile。
-f api/Dockerfile 表示使用子目錄內的檔案，不代表把 build context 改成 api/。
.：決定 COPY 能從哪裡拿檔案
假設專案包含以下內容：
| 路徑 | 用途 |
|---|
api/Dockerfile | 建置配方 |
api/main.py | API 程式 |
api/requirements.txt | Python 套件清單 |
shared/ | 共用模組 |
compose.yaml | 服務設定 |
.dockerignore | 建置時要排除的檔案 |
Dockerfile 可以寫：
COPY api/main.py /app/main.py
COPY shared/ /app/shared/
這裡一般 COPY 的來源路徑，是從 build context 根目錄算起，不是從 Dockerfile 所在的目錄算起。COPY --from 則是另一種情境，可從其他階段或指定來源複製。
因此，在專案根目錄執行：
docker build -t demo-api:1 -f api/Dockerfile .
如果已經進入 api/，也可以明確把 context 指回上一層：
docker build -t demo-api:1 -f Dockerfile ..
重點是最後的路徑包含哪些檔案。詳見 Build context。
二、建置與部署時要注意的七件事
1. 控制 context 大小，避免帶入不需要的檔案
專案裡可能放著資料集、備份、套件目錄與環境設定。這些東西通常不需要拿來建置。
可以在 context 根目錄放入 .dockerignore：
.git/
.env
.env.*
!.env.example
.venv/
node_modules/
**/__pycache__/
**/*.pyc
data/
backups/
*.tar
*.tar.gz
請依專案調整：如果建置真的需要 data/ 中的檔案，就不能整個排除。
現代 Docker 常使用 BuildKit，能跳過未使用的檔案，並減少重複傳輸。因此，「整個目錄一定會先全部打包送出」並不是通用的描述。但明確排除無關檔案，仍能減少負擔，也避免 COPY . . 把環境設定或備份帶進映像。參考 BuildKit 與 .dockerignore 說明。
2. 安裝套件可能需要網路，離線部署要事先準備
以下建置步驟通常需要連到套件來源：
RUN apt-get update \
&& apt-get install -y --no-install-recommends curl \
&& rm -rf /var/lib/apt/lists/*
RUN pip install --no-cache-dir -r requirements.txt基礎映像若尚未存在，也可能需要下載。使用內部套件庫或已備妥的離線套件時，做法則會不同。
若部署環境無法上網，一種常見方式是在可上網、且目標平台相容的準備機建好映像，再匯出：
docker image save -o demo-api_1.tar demo-api:1
把檔案搬到目標主機後載入：
docker image load -i demo-api_1.tar
save 和 load 處理的是映像；Compose 設定、環境變數、掛載檔案與資料庫資料，需要另外準備。若有多個服務，也要備齊各服務使用的映像。參考 docker image save 與 docker image load。
此外，同一份 Dockerfile 在不同日期重新建置，不一定得到完全相同的套件。需要可重現的版本時，應管理套件鎖定檔、基礎映像 digest 與建置來源。參考 Docker 建置最佳實務。
3. Cache 能加速建置，但不會主動檢查套件是否更新
Docker 會依指令、前面的建置狀態與相關輸入，判斷是否能重用快取。
以常見的單階段 Dockerfile 為例，調整順序可以減少重做的工作：
WORKDIR /app
COPY api/requirements.txt ./requirements.txt
RUN pip install --no-cache-dir -r requirements.txt
COPY api/main.py ./main.py
COPY shared/ ./shared/
這樣只修改程式碼時，前面的套件安裝步驟通常仍能使用快取；修改套件清單時，才需要重新安裝。參考 快取最佳化。
但 RUN apt-get update ... 或 RUN pip install ... 若命中快取，就不會實際執行，也不會上網確認是否有新版。一般 COPY 的內容或相關檔案中繼資料改變，則可能讓快取失效；只改檔案修改時間並不足以觸發。參考 快取失效規則。
需要停用建置快取時：
docker build --no-cache -t demo-api:1 -f api/Dockerfile .
如果也要嘗試更新基礎映像，可加上 --pull：
docker build --pull --no-cache -t demo-api:1 -f api/Dockerfile .
--no-cache 與 --pull 用途不同。另外，Dockerfile 裡的 pip --no-cache-dir 只控制 pip 的下載快取，不會關閉 Docker 的建置快取。Docker 旗標可參考 Buildx build 說明。
4. 定期看磁碟使用量，再決定清理範圍
多次建置後，可能累積舊映像與 build cache。因為映像之間可以共享層，磁碟占用不一定是每建一次就增加一份完整映像大小。
先查看：
docker system df
docker image ls
若要清除未被容器引用的 dangling 映像，可以執行：
這個命令會先要求確認；加上 -f 才會省略確認。-a 會把清理範圍擴大到所有未被容器引用的映像，包含有標籤、可能留作回復用途的版本。
映像清理也不等於清空 build cache，不必把兩者混為一談。參考 docker image prune 與 Build cache 管理。
5. Build 成功後，還要讓服務使用新映像
假設 compose.yaml 中有以下服務：
services:
api:
image: demo-api:1
ports:
- "127.0.0.1:8000:8000"此設定假設應用程式在容器內監聽 0.0.0.0:8000，並將主機端連線限制在本機。api 是 Compose 服務名稱，demo-api:1 是映像名稱，兩者用途不同。
建置完成後，在 Compose 檔案所在目錄執行：
Compose 偵測到映像或設定變更時，通常會重建容器。如果希望明確要求重建，即使沒有偵測到變更，也可以用：
docker compose up -d --force-recreate api
所以，--force-recreate 是強制重建的選項，不是更新映像唯一的方法。參考 docker compose up。
docker compose restart api 則是重新啟動既有容器，不能用來切換到剛建好的映像。參考 docker compose restart。
重建之前，也要知道資料放在哪裡：
| 資料位置 | 重建容器時要注意的事 |
|---|
| 容器可寫層 | 刪除舊容器時，裡面的資料會一併失去 |
| 具名 volume | 重新掛載相同 volume 可沿用資料；刪除 volume 另當別論 |
| 主機 bind mount | 資料保留在主機路徑，需確保仍掛載相同位置 |
| 外部資料庫或儲存服務 | 需確認連線設定及新版程式的資料相容性 |
沒有掛載 volume，不代表重建一定安全。 上傳檔案、SQLite 或日誌若只存在容器內，就可能遺失。參考 Docker 儲存說明。
更新後可查看：
docker compose ps
docker compose logs --tail=100 api
接著實際呼叫 API 或檢查健康狀態。容器正在執行，與應用程式已正常提供服務，是兩件需要分別確認的事。
6. 搬映像之前，確認 CPU 架構
常見平台包括 linux/amd64（一般 x86-64 主機）與 linux/arm64（ARM64 主機）。
未特別指定時，建置平台通常跟隨 builder 的預設平台。不同架構的單一平台映像，不能假設能在另一台主機原生執行。
可以先檢查映像：
docker image inspect demo-api:1 --format '{{.Os}}/{{.Architecture}}'若 builder 已具備跨平台建置能力，可明確指定目標：
docker buildx build --platform linux/amd64 --load -t demo-api:1 -f api/Dockerfile .
這裡 --load 會將單一平台建置結果載入本機映像儲存區。跨平台的 RUN 步驟可能需要模擬器、原生節點或其他支援，基礎映像與套件也必須支援目標平台。
遇到 exec format error 時，架構不符是排查方向之一，也要檢查執行檔與腳本格式。跨平台原理與前提可參考 Multi-platform builds。
7. 建置時做基本自檢，讓問題早點出現
假設程式需要 requests 套件與 curl 指令，可以在安裝完成後加入：
RUN python -c "import requests" && command -v curl
這種自檢可以提早發現套件漏裝或命令不存在。命令回傳非零狀態時，該次建置會失敗。
但自檢只能涵蓋實際檢查的項目，不能保證部署環境中的資料庫、網路、權限或完整功能都正常。建置時也應避免匯入會立刻連線正式服務的模組。
還有一個容易忽略的地方：這次 build 失敗，之前的同名映像可能仍然存在。 不要只看 docker image ls 有沒有該 tag，就認為這次建置成功。
三、把日常更新整理成固定步驟
以下假設位於專案根目錄，使用前面的 Compose 設定，而且既有容器也是由同一個 Compose 專案建立。
先建置：
docker build -t demo-api:1 -f api/Dockerfile .
確認成功後，再更新服務：
查看狀態與日誌，再驗證實際功能：
docker compose ps
docker compose logs --tail=100 api
如果使用 Bash 自動串接建置與更新，可以使用 &&，確保前一步成功才繼續：
docker build -t demo-api:1 -f api/Dockerfile . && docker compose up -d api
若原本使用 docker compose -p demo ... 指定專案名稱，後續操作也要維持相同的 -p demo，避免操作到另一組服務。
這次學習後，我會在每次更新時依序確認：建置用了哪些檔案、產出了哪個映像、服務是否已使用新映像，以及資料是否放在能持續保存的位置。把這幾件事分開檢查，就比較容易找出更新流程卡在哪一步。
近期留言