一行指令把說明書塞給 AI：Dart Skills CLI 1.0，把套件交付重新定義了一次

先把背景補上。9 月 9 日，戀貓de小郭在掘金發布了一篇關於 Dart Skills CLI 1.0 的長文，這個最近由 Dart 官方正式推出的命令列工具，很快在中文技術社羣裡被反覆轉發。這個工具最早由後端框架 Serverpod 團隊開發，後來移交給 Dart 團隊維護與發布，1.0 版本代表它從社羣實驗品，變成了官方交付流程的一部分。

表面上看，這個 CLI 做的事情很簡單：Dart 與 Flutter 的套件可以在根目錄加一個 skills/ 資料夾，套件發布到 pub.dev 時，這些 Agent Skills 會跟著一起帶出去。使用者的專案只要執行一次 dart run skills@ get，Claude Code、Cursor、Codex、Cline、Copilot 這類程式開發代理工具，就能載入這個套件提供的使用說明。

一行指令的背後，其實是「套件要交付什麼」這件事的定義被改寫了。

以前發套件，現在發「給 AI 的知識」

過去發布一個套件，交付內容大概是這幾樣：原始碼、型別定義、README、API 文件、範例程式。作者的假設是，讀這些東西的是一個人類開發者，他會查文件、看範例、踩到坑再去搜尋。

現在多了一層。作者可以在套件裡放入面向代理的結構化知識，包括什麼情境下該採用哪個 API、推薦的工程結構、容易踩坑的組合、錯誤處理方式、可執行的輔助腳本，以及複雜任務該按什麼流程完成。這些內容以 Skill 的格式存在：一個目錄、一份 SKILL.md，再視需要加入 scripts/、references/、assets/。

換句話說，套件作者現在多了一種讀者。這個讀者不喫 README 的敘事，不喫範例的暗示，它要的是明確、可執行、版本對得上的操作說明。

版本對不上，才是真正的痛點

有人會問，過去不也能在套件裡放 Skills 嗎？確實可以，而且 Dart 和 Flutter 官方早就各自維護了 Skills 倉庫，透過類似 npx skills add dart-lang/skills 這樣的指令安裝。

問題在於這種方式只適合「怎麼開發 Flutter」「怎麼寫 Dart 單元測試」這類通用技能。一旦放進套件生態，麻煩就來了：Git 倉庫裡的 Skill，和專案正在用的套件版本，沒有天然的對應關係。

戀貓de小郭在文中給了一個很具體的情境。假設專案依賴某個套件的 3.2.1 版，AI 模型本身可能見過 2.x 時代的程式碼，網路上的文件可能已經更新到 4.x，GitHub 上獨立維護的 Skill 又是照 main 分支寫的。三個時代的不同資訊同時塞給代理工具，它難免寫出一些奇怪的組合，程式碼看起來都對，湊在一起卻不會動。

這裡的兩個缺口，一個是可發現性，另一個是版本支援。就算開發者裝好了 Node.js、能順利跑 npx skills，也沒有機制保證代理工具拿到的 Skill，和專案實際解析到的套件版本是一致的。

把 Skill 綁進版本號，是最直接的那個答案

Dart Skills CLI 1.0 給出的解法是：把 Skill 直接放進套件發行物。套件作者升級 API 時，同步修改對應的 Skill；執行 dart pub publish 時，skills/ 會跟著套件一起進入發布封存。專案解析到哪個版本，本地拿到的就是那個版本附帶的 Skill。

這帶來一個有意思的變化。以前套件的版本號約束的是程式碼和 API，現在同一個版本號，開始間接約束 AI 應該怎麼理解和操作這套 API。版本管理這個老概念，多管了一件事。

實際流程也不複雜。執行 dart run skills@ get 之後，CLI 會先確認專案依賴已經解析完成，接著讀取每個依賴套件內附的 Skill，整理到本地，讓各種代理工具能直接取用。使用者不需要知道某個 Skill 是誰維護的、寫於哪個分支，版本解析的結果就是唯一的真相來源。

別人生態還在補文件，Dart 直接改了交付定義

把這件事和整個開發工具圈的動向並排放在一起看，味道就出來了。多數語言生態目前對 AI 工具的支援，還停留在「把文件寫得更好讀」或「提供 MCP 伺服器查詢 API」的層次，知識和套件本體之間始終隔著一層。Dart 這一步是直接把面向代理的知識，塞進了套件的交付清單裡，讓它跟著版本走。

這不能說是所有生態的標準答案。Skill 的撰寫對套件作者來說是一份額外的維護成本，API 改了、Skill 忘了改，反而可能製造新的錯誤資訊。這個工具最終能不能形成「作者願意寫、用戶願意裝」的正向循環，還要看 pub.dev 上實際採用的套件數量。

但方向本身值得注意。當程式開發代理工具成為越來越多人的預設工作方式，「AI 怎麼正確使用這個套件」就從文件品質問題，升級成交付架構問題。Dart 和 Flutter 又一次走在了比較激進的位置上，這次賭的是，未來每個套件都需要一份寫給機器看的說明書，而這份說明書，理應和程式碼同一個版本、同一份封存、一起發布。