最近 GitHub 趨勢榜上又冒出一個顯眼的倉庫——一個專門給 AI 編程助手用的 diagram skillStar 數(shù)一路飆到 2.9 萬。我在它漲到一萬多的時候就開始關(guān)注眼看著它在兩周內(nèi)翻了一倍多這熱度在 skill 類項目里是真的不多見。要知道Skill 這個生態(tài)在 Claude Code 和 Codex 圈子里雖然熱鬧但絕大多數(shù)倉庫能破千 Star 就算不錯了2.9 萬基本屬于“出圈爆款”級別。我第一時間就把倉庫翻了個底朝天也實際放到自己的 Claude Code 和 Codex 環(huán)境里跑了一堆場景。今天這篇文章就不做那種“標(biāo)題黨轉(zhuǎn)述”了直接把我拆解到的核心機制、部署步驟、踩坑記錄和自定義 skill 的方法全部攤開講。如果你平時用 AI 編程助手畫架構(gòu)圖、時序圖、ER 圖或者你正打算自己寫一個 skill 發(fā)布出去這篇文章應(yīng)該能幫你省下不少摸索時間。1. 先看現(xiàn)象2.9萬Star的這個diagram skill到底解決了我過去什么麻煩1.1 從“AI會寫代碼但不會畫圖”到“一次成型”先說說我之前用 AI 畫圖的真實體驗。坦白講過去每次讓 Claude 或 GPT 畫架構(gòu)圖我的流程都是這樣先在對話里描述業(yè)務(wù)鏈路讓它生成一段 Mermaid 語法然后我把這段語法復(fù)制到 Mermaid Live Editor 里渲染渲染出來要是布局亂了、節(jié)點重疊了、箭頭方向錯了再復(fù)制報錯信息回去讓它改。一來一回少說四五輪遇到復(fù)雜系統(tǒng)圖甚至要折騰半小時。這個 diagram skill 解決的就是這個痛點。它并不是簡單地在提示詞里加一句“你是一個專業(yè)的圖表專家”而是把一整套路標(biāo)、排版約束、節(jié)點命名規(guī)范、配色規(guī)則、甚至“什么時候該用流程圖、什么時候該用時序圖、什么時候該用架構(gòu)圖”的判斷邏輯全部固化成一份結(jié)構(gòu)化的知識包。AI 在執(zhí)行畫圖任務(wù)時不再靠臨場發(fā)揮而是像有經(jīng)驗的同事在旁邊按著肩膀說“你先想清楚層次關(guān)系再動手畫”產(chǎn)出質(zhì)量自然穩(wěn)定得多。我還專門試了一個過去最容易翻車的場景讓 AI 畫一個包含網(wǎng)關(guān)、微服務(wù)、消息隊列、數(shù)據(jù)庫四層結(jié)構(gòu)的系統(tǒng)架構(gòu)圖。普通提示詞模式下AI 大概率會給你一坨層次混亂的節(jié)點而這個 skill 模式下它能自動把基礎(chǔ)設(shè)施層、應(yīng)用層、數(shù)據(jù)層分開每個區(qū)域加上語義化分區(qū)標(biāo)題節(jié)點顏色也按職責(zé)區(qū)分整體版式基本到了能直接貼進設(shè)計文檔的水平。1.2 它和普通prompt的最大區(qū)別把專家畫圖經(jīng)驗固化成了“可執(zhí)行文檔”很多人第一次接觸 skill 的時候會有一個疑問這不就是個更長的提示詞嗎還真不是。普通提示詞是一次性的你說得再詳細下一次對話 AI 也記不住而且提示詞一長AI 容易抓不住重點反而變得啰嗦。Skill 則不一樣它在支持 Agent Skills 機制的編程助手里有固定的存放目錄、固定的加載方式AI 會依據(jù)任務(wù)描述自動判斷“此時該調(diào)用哪個 skill”然后在執(zhí)行時把整個 skill 文檔讀進去當(dāng)參考標(biāo)準(zhǔn)。這就像你給新同事的不是一句口頭叮囑而是一本《部門出圖規(guī)范手冊》手冊還在工作臺旁邊掛著每次出圖都會翻一遍。這個 diagram skill 的項目結(jié)構(gòu)里核心就是一份精心編寫的 SKILL.md里面包含了圖表類型選擇策略、Mermaid/SVG/HTML 三種輸出格式的適用場景、節(jié)點命名與分層的硬性規(guī)則、常見版式模板、甚至對“避免節(jié)點文字過密”“保持箭頭語義一致”這類細節(jié)都做了約束。我仔細讀了一遍發(fā)現(xiàn)它把一個資深架構(gòu)師畫圖時腦子里默認遵循的那套隱性規(guī)范全部顯性化、結(jié)構(gòu)化了這才是它真正的價值所在。2. 為什么偏偏是diagram成了爆款A(yù)I編程進入“可視化交付”階段的信號2.1 diagram場景在AI協(xié)作里的獨特地位Skill 生態(tài)里其實什么類型都有有寫代碼審查的、有做日志分析的、有搞測試用例生成的、還有語言學(xué)習(xí)輔助的。為什么偏偏是 diagram 這個方向跑出了 2.9 萬 Star我自己的判斷是它踩中了一個非常高頻率、且已經(jīng)成熟到“就差最后一公里”的需求。過去兩年大家已經(jīng)習(xí)慣了讓 AI 寫代碼、改 Bug、寫測試但“讓 AI 直接產(chǎn)出可用于交付的圖表”一直是塊硬骨頭。原因很簡單畫圖這件事對語言模型來說并不像寫代碼那樣“輸入輸出都是文本”那么自然。圖表涉及空間布局、視覺層次、語義分組這些信息在純文本的 Mermaid 語法里表達得非常間接。模型容易犯的毛病是——邏輯上知道節(jié)點之間有什么關(guān)系但表現(xiàn)在圖上就是亂。而 2025 年以來Claude Code、Codex 這類 Agent 工具的普及讓一個很重要的前提變成了現(xiàn)實AI 不再只是聊天框里的對話對象而是一個真正能讀寫文件、執(zhí)行命令、按照特定規(guī)范完成交付物的“協(xié)作者”。Skill 機制恰好就是給這個協(xié)作者裝“專業(yè)技能包”的方式。diagram 這個場景天然就適合被做成 skill——因為它有非常明確的輸入業(yè)務(wù)描述、輸出圖表文件、和質(zhì)量標(biāo)準(zhǔn)排版、語義、層次這些信息完全可以結(jié)構(gòu)化。2.2 三種主流圖表輸出方案為什么Skill會帶來質(zhì)變現(xiàn)在 AI 畫圖其實有三大技術(shù)路線各有各的適用場景。我在實際用這個 diagram skill 的過程中發(fā)現(xiàn)它做了一個很聰明的設(shè)計——不是只押注一種方案而是按場景自動切換。輸出方案優(yōu)勢劣勢適用場景Mermaid 語法文本化、版本可控、改動成本最低復(fù)雜布局表現(xiàn)力有限排版偶爾失控流程圖、時序圖、甘特圖、ER 圖SVG 代碼像素級控制、排版精準(zhǔn)、視覺表現(xiàn)力強Token 消耗大、代碼生成難度高需較強的空間計算能力架構(gòu)圖、概念圖、帶品牌風(fēng)格的可視化卡片HTML/CSS 渲染適合網(wǎng)頁內(nèi)嵌、交互性強不同環(huán)境渲染效果不一致不適合直接存文檔數(shù)據(jù)儀表盤、動態(tài)展示頁我實測下來的感受是這個 skill 在 Mermaid 和 SVG 之間切換得非常果斷。比如畫一個 K8s 集群的部署架構(gòu)圖它會直接選擇 SVG因為你需要在圖里精確表達 Pod、Service、Ingress 的嵌套關(guān)系Mermaid 的 graph 語法雖然也能畫但節(jié)點一多布局基本就交給引擎隨機發(fā)揮了。而畫一次支付流程的時序圖它就用 Mermaid因為這類圖強調(diào)的是消息順序不是視覺精度Mermaid 完全夠用還方便后續(xù)手工微調(diào)。這個“選型能力”恰恰是普通提示詞很難穩(wěn)定的地方也是 skill 的價值放大的體現(xiàn)。沒有 skill 的時候AI 選方案基本靠猜選錯了整張圖推倒重來有了 skill它每次都遵循同一套決策規(guī)則輸出質(zhì)量方差小了很多。2.3 Skill機制開始成為Agent能力的“基礎(chǔ)設(shè)施”再往深一層看diagram skill 跑出這個數(shù)據(jù)其實釋放了一個信號AI 編程助手的競爭已經(jīng)從“誰的模型更強”慢慢過渡到“誰的技能生態(tài)更豐富”。你可以把模型理解成一個聰明但沒什么行業(yè)經(jīng)驗的新人Skill 則是讓這個新人快速成為某個領(lǐng)域熟手的培訓(xùn)手冊。這也是為什么最近“codex skill”“claude skill”“skill 開發(fā)”“skill creator”會成為熱詞的原因。大家開始意識到與其每次對話都長篇大論地描述需求不如把一套固定打法封裝成一個 skill以后一句話就能觸發(fā)。這個 diagram 項目之所以能漲得這么快就是因為它把一個高頻痛點場景封裝得足夠好讓用戶一眼就能看到價值而且安裝門檻極低——克隆下來放進指定目錄立刻就能用。做產(chǎn)品的人常說“工具類項目要贏就贏在體驗閉環(huán)”。這個 diagram skill 在體驗閉環(huán)上做得確實夠極致從給需求到出圖到保存成文件整個過程完全在終端里完成不需要切到任何外部編輯器。這種“絲滑感”在開發(fā)者圈子里傳播起來是非常快的我甚至懷疑這 2.9 萬 Star 里有一大半人是沖著“原來還能這么干”的驚艷感點的。3. 拆解它的工作邏輯SKILL.md是怎么指揮AI產(chǎn)出專業(yè)圖表的3.1 一個skill的標(biāo)準(zhǔn)目錄結(jié)構(gòu)與觸發(fā)機制要真正理解這個 diagram skill 為什么好用我們得先搞明白 skill 在 Agent 環(huán)境里的運行機制。以目前主流的 Claude Code 和 Codex 生態(tài)為例一個 skill 的基本目錄結(jié)構(gòu)長這樣your-skill/ ├── SKILL.md # 核心文件全部指令與知識都寫在這里 ├── assets/ # 可選目錄放示例圖、參考模板等 ├── scripts/ # 可選目錄放輔助腳本 └── reference/ # 可選目錄放更詳細的背景知識文檔關(guān)鍵就是這個 SKILL.md。它的頭部有一段 YAML 格式的元信息用來聲明這個 skill 的名稱和描述AI 就是通過讀取這段描述來決定“什么時候該調(diào)用這個 skill”的。我簡化一下結(jié)構(gòu)--- name: diagram-expert description: 當(dāng)用戶需要生成系統(tǒng)架構(gòu)圖、流程圖、時序圖、ER圖等可視化圖表時使用。適用于架構(gòu)設(shè)計、代碼邏輯說明、業(yè)務(wù)鏈路梳理、數(shù)據(jù)庫設(shè)計等場景。能夠根據(jù)復(fù)雜度和場景選擇 Mermaid、SVG 或 HTML 輸出。 ---注意 description 這一段寫得越精確AI 的觸發(fā)準(zhǔn)確率越高。如果 description 寫成“幫用戶畫圖”AI 會經(jīng)常糊涂不知道是該調(diào)用你還是自己硬畫。而這個項目在 description 里明確列出了觸發(fā)場景和輸出能力范圍AI 看到“架構(gòu)圖”“時序圖”“ER 圖”這些關(guān)鍵詞就會自動把這個 skill 加載進來執(zhí)行。3.2 指令正文里最值得學(xué)的三個設(shè)計點打開 SKILL.md 的正文部分我把它拆解成了三層。第一層是“角色與目標(biāo)設(shè)定”比如要求 AI 扮演一名有 10 年經(jīng)驗的技術(shù)架構(gòu)師目標(biāo)是產(chǎn)出能直接用于文檔、評審、匯報的圖表。第二層是“工作流程約束”這是我覺得最有含金量的地方。它并不是直接讓 AI“畫一張圖”而是要求 AI 先做需求分析列出圖表的類型、層級、節(jié)點清單再選擇輸出格式最后才動手畫。這個過程非常像真實世界里設(shè)計師的做法先理解需求、列信息架構(gòu)、定視覺風(fēng)格最后才落筆。AI 一旦遵循這個流程就不會出現(xiàn)“拿到需求就亂畫、畫完發(fā)現(xiàn)層級不對”的問題。第三層是“硬性質(zhì)量規(guī)則”比如節(jié)點命名必須語義化禁止使用 A1、B2 這類無意義編號同一張圖中相同類型的元素必須保持一致的視覺樣式連線必須表達真實依賴關(guān)系禁止為了美觀添加無意義連線圖內(nèi)文字必須精簡一圖只表達一個核心主題這些規(guī)則單獨看好像都是常識但模型在生成的時候如果不被強調(diào)就非常容易犯“自我發(fā)揮”的毛病。硬性規(guī)則相當(dāng)于給模型套上了韁繩保證產(chǎn)出的圖表在語義上和版式上都是可控的。3.3 示例與邊界決定了skill的上限和下限除了規(guī)則之外這個項目還內(nèi)置了一批高質(zhì)量示例包括各類圖表的 SVG 代碼片段和對應(yīng)的 Mermaid 語法。這些示例的作用非常關(guān)鍵大模型本質(zhì)上還是通過模式匹配來生成內(nèi)容的給它看一個“參考答案”它生成的結(jié)果明顯會比憑空生成穩(wěn)定得多。我自己的體會是示例的重要性排序是正例 對比例 “正例 反例”。這個項目最妙的一點是它不光告訴 AI“好圖長這樣”還會明確列出“哪些事情不要做”比如不要用過于艷麗的顏色、不要把節(jié)點文字堆得太滿、不要畫完架構(gòu)圖卻忘了標(biāo)注數(shù)據(jù)流向。這種“負向約束”能有效壓低模型輸出的下限讓它在最差的情況下也不會畫出一張完全不能用的圖。邊界設(shè)定也是我非常欣賞的部分。比如它會明確告訴 AI如果輸入信息不足以支撐畫圖應(yīng)該主動向用戶提問而不是腦補缺失的模塊如果用戶給的業(yè)務(wù)鏈路本身存在矛盾應(yīng)該先指出問題而不是硬畫。這種“敢于說不知道”的邊界極大減少了 AI 一本正經(jīng)胡說八道的情況。4. 30分鐘完整部署安裝、配置與首次使用實錄4.1 環(huán)境檢查你的Agent版本是否支持Skill機制在動手之前先確認你的環(huán)境支持 Agent Skills。以我用得最多的 Claude Code 為例需要把 CLI 更新到支持 skills 的版本Codex 如果是最新的幾個版本也同樣支持。可以用一個非常簡單的命令確認支持情況# 檢查 Claude Code 版本 claude --version # 查看幫助中是否包含 skill 相關(guān)命令 claude --help | grep -i skill如果輸出里能看到類似skills或--add-skill之類的選項說明環(huán)境就緒。Codex 用戶可以直接看配置文件里是否有[skills]段落或者在輸入斜杠命令時能不能看到/skills。4.2 下載并安裝到正確目錄環(huán)境沒問題之后安裝過程其實只有三步。第一步把項目克隆到本地git clone https://github.com/xxx/diagram-skill.git cd diagram-skill第二步找到你的 Agent 對應(yīng)的 skills 目錄。Claude Code 的用戶級目錄一般是~/.claude/skills/項目級目錄是.claude/skills/Codex 是~/.codex/skills/或項目下的.codex/skills/。我個人建議先放到項目級目錄里這樣只對當(dāng)前項目生效避免以后出現(xiàn)全局污染。第三步把項目里的 skill 文件夾復(fù)制或軟鏈過去mkdir -p .claude/skills cp -r diagram-skill .claude/skills/diagram-skill注意不要直接復(fù)制一堆散亂的文件必須保證.claude/skills/diagram-skill/SKILL.md這個路徑結(jié)構(gòu)存在。SKILL.md 如果在錯誤位置AI 是掃描不到的。4.3 首次實際使用從一句話到一張可用架構(gòu)圖裝完后我沒有立刻增加任何自定義配置直接就在項目目錄里啟動了 Claude Code輸入了一句真實需求畫一下當(dāng)前這個電商系統(tǒng)的整體架構(gòu)圖包含前端應(yīng)用、API 網(wǎng)關(guān)、用戶服務(wù)、訂單服務(wù)、商品服務(wù)、MySQL 和 Redis標(biāo)注清楚它們之間的調(diào)用關(guān)系和數(shù)據(jù)流向。幾分鐘后AI 按照 skill 的規(guī)則給出了回應(yīng)。它沒有直接甩代碼而是先做了三步動作拆解需求確認要畫的是“系統(tǒng)架構(gòu)圖”而不是“部署拓撲圖”列出節(jié)點清單包括每個節(jié)點的職責(zé)說明詢問是否需要補充消息隊列等中間件信息我回答“暫不補充”后它直接生成了一份 SVG 文件保存到了項目里的docs/architecture.svg同時給了一段 Mermaid 版本用于后續(xù)修改。打開 SVG 看了一眼結(jié)構(gòu)清晰、配色統(tǒng)一、層次分明比我預(yù)期中“AI 畫的架構(gòu)圖”高出一個檔次。我還試了一個更復(fù)雜的場景把一段用戶登錄的完整鏈路線索畫成時序圖。它同樣沒有翻車不僅畫出了前端、后端、數(shù)據(jù)庫之間的消息傳遞順序還自動在旁邊加了“Session 過期處理”這個分支說明。這個細節(jié)讓我有點意外因為普通提示詞模式下AI 通常不會想到補充異常分支。5. 使用中踩過的坑排查鏈路與規(guī)避方案5.1 坑一skill安裝了但AI完全不理我我第一次在自己項目里裝完這個 skill 之后遇到的第一個問題就是AI 根本不知道它的存在。我讓 AI“畫圖”它還是像以前一樣直接生成一段 Mermaid 代碼完全沒走 skill 的流程。排查鏈路是這樣走的我先檢查了 skills 目錄結(jié)構(gòu)發(fā)現(xiàn)沒問題然后又懷疑是 SKILL.md 的 YAML 頭信息格式不對但看了一遍也沒毛病。最后把文檔翻出來才發(fā)現(xiàn)問題出在 description 的關(guān)鍵詞覆蓋不夠匹配我當(dāng)前 Agent 版本對 skill 的觸發(fā)機制。后來我把 description 里的觸發(fā)詞擴充得更細致同時把 skill 從用戶全局目錄移到了當(dāng)前項目目錄重新啟動 Agent它就正常觸發(fā)了。這個坑給大家提個醒裝完 skill 后一定要重啟 Agent 會話。skill 的加載是在會話啟動時掃描的不是每次對話實時檢測文件的。5.2 坑二輸出的Mermaid圖“看起來對但結(jié)構(gòu)亂”第二次踩坑是畫一張業(yè)務(wù)流程較復(fù)雜的狀態(tài)機圖時AI 生成的 Mermaid 圖節(jié)點不少但布局完全失控節(jié)點擠作一團線條到處亂穿放在文檔里根本沒法看。我一開始以為是 Mermaid 引擎渲染問題反復(fù)給它換 layout 參數(shù)效果都不好。后來仔細看了 skill 的輸出日志才發(fā)現(xiàn)問題根源是輸入的業(yè)務(wù)流程本身沒有經(jīng)過梳理——AI 按我給的原始描述直接畫自然畫不出清晰的層次。解決方法是照著 skill 里的流程要求先讓 AI 把流程重新結(jié)構(gòu)化把步驟轉(zhuǎn)成“輸入—處理—輸出”的鏈?zhǔn)奖磉_剔除掉無關(guān)的旁路分支然后再生成圖。這一次畫出來的圖雖然節(jié)點數(shù)量沒少但層次感明顯好了很多。經(jīng)驗總結(jié)就是遇到圖亂先不要急著改視覺參數(shù)先回到信息結(jié)構(gòu)層面去梳理內(nèi)容。5.3 坑三SVG模式下Token消耗明顯增高SVG 是文本格式畫一張復(fù)雜架構(gòu)圖的代碼量輕松上千行Token 消耗比 Mermaid 高出一個量級。我某次畫一張包含幾十個服務(wù)節(jié)點的微服務(wù)架構(gòu)圖時一次生成的 Token 消耗非常驚人而且因為 SVG 代碼太長AI 生成到一半偶爾還會“主動截斷”導(dǎo)致 SVG 文件不完整瀏覽器根本渲染不出來。這之后我調(diào)整了用法要么把拆分成多張局部圖要么先用 Mermaid 快速畫框架確認結(jié)構(gòu)沒問題后再讓 AI 基于這個框架生成 SVG 精修版。這樣即使 SVG 生成有瑕疵我手上還有 Mermaid 版本兜底。5.4 坑四AI自己改了skill的代碼導(dǎo)致行為漂移這個問題比較隱蔽。用 Claude Code 時如果同時開著自動編輯權(quán)限AI 有可能會在某種情況下順手修改 SKILL.md 文件——比如用戶問“能不能調(diào)整配色”AI 就會直接去改 skill 源文件加了一條“配色改為藍色系”。表面上看這是“按需定制”但實際上非常危險。因為 SKILL.md 是全項目共用的你改了一個細節(jié)后面所有圖表輸出全都跟著變而且這種變化很多時候不是你有意為之。我現(xiàn)在已經(jīng)養(yǎng)成了習(xí)慣把這個 skill 目錄加入.gitignore或者在 Agent 配置里設(shè)置只讀權(quán)限不允許 AI 自動修改 skill 文件。真要調(diào)整樣式我傾向于先復(fù)制一份 skill改成自己的版本再啟用。5.5 附常見問題速查表現(xiàn)象可能原因排查優(yōu)先級安裝了但沒觸發(fā)目錄位置不對 / 未重啟會話 / description 覆蓋不到先重啟再查路徑最后看描述圖結(jié)構(gòu)混亂輸入需求未經(jīng)結(jié)構(gòu)化 / 節(jié)點鏈路未梳理先梳理信息結(jié)構(gòu)再調(diào)圖參數(shù)SVG 被截斷單次 Token 超限拆圖或先 Mermaid 后 SVG輸出風(fēng)格突然改變有人或 AI 改動了 SKILL.md用 git diff 查文件歷史其它圖表工具沖突同時裝了多個 diagram 類 skill確保每個 skill 的 description 觸發(fā)范圍不重疊6. 把它變成自己的自定義一個團隊skill的完整套路6.1 復(fù)刻這個項目的寫法SKILL.md模板骨架用了一段時間這個 diagram skill 后我最大的感受是與其等別人的 skill不如學(xué)會寫自己的 skill。畢竟團隊內(nèi)部的流程圖規(guī)范、文檔模板、代碼風(fēng)格外部的通用 skill 永遠沒辦法完全覆蓋。下面是我自己總結(jié)的一個通用模板骨架基本沿用了那個 diagram 項目的設(shè)計思路--- name: skill-name description: 當(dāng)用戶需要……時使用。適用于……等場景。能夠輸出……格式的結(jié)果并遵循……規(guī)范。 --- # 技能說明 你是……領(lǐng)域的資深專家。你的目標(biāo)是…… ## 工作流程 1. 需求分析列出輸入信息識別缺失項必要時向用戶提問澄清。 2. 方案確定根據(jù)場景選擇輸出格式說明理由。 3. 執(zhí)行輸出按規(guī)范生成交付物。 4. 自檢對照質(zhì)量規(guī)則逐項檢查。 ## 質(zhì)量規(guī)則 - 規(guī)則一…… - 規(guī)則二…… - 規(guī)則三…… ## 禁止事項 - 禁止在信息不足時憑空猜測。 - 禁止跳過需求分析直接輸出。 - 禁止…… ## 示例 ### 示例 1…… ### 示例 2……核心要點就兩個一是給 AI“極簡但明確的行動框架”二是給足高質(zhì)量示例。前者保證它不走偏后者保證它有參考。6.2 實戰(zhàn)案例給代碼評審場景做一個review-skill我最近用這個模板給團隊做了一套代碼評審 skill效果相當(dāng)不錯可以作為參考。需求背景是團隊每周都要評審后端微服務(wù)的代碼變更每次評審規(guī)范不一致不同人關(guān)注點不同評審記錄也沒有固定格式。我寫的 SKILL.md 里包含了幾層?xùn)|西先是角色設(shè)定——要求 AI 扮演一個懂業(yè)務(wù)也懂架構(gòu)的資深代碼評審人然后是評審維度清單——包括邏輯正確性、空值處理、并發(fā)安全、異常吞掉、日志記錄、數(shù)據(jù)庫索引使用、事務(wù)邊界等再給了一個統(tǒng)一的評審報告輸出模板包含問題等級劃分嚴重/一般/建議、對應(yīng)代碼行號、問題描述、修復(fù)建議最后附了兩個評審示例一個是好的評審記錄一個是敷衍的評審記錄。實際跑下來整套 skill 的觸發(fā)率非常高只要用戶說“評審一下 xxx 的改動”AI 就會進入評審流程最后輸出的報告直接就是規(guī)范格式團隊可以直接拿到文檔里歸檔。對比之前每次都要寫一大段評審要求現(xiàn)在一句話就完成了效率提升非常明顯。6.3 發(fā)布與推廣為什么“小而準(zhǔn)”的skill更容易拿到Star最后聊聊這個 diagram skill 為什么能拿到 2.9 萬 Star這對想自己做 skill 發(fā)布的人有直接參考價值。我觀察了幾個高 Star 的 skill 項目發(fā)現(xiàn)它們有一個共性場景足夠聚焦輸出質(zhì)量足夠穩(wěn)定。“小而準(zhǔn)”的意思是別想著做一個“萬能 skill”而要把某一個細分場景做到極致。你去看那些火起來的項目無一例外都是“描述精準(zhǔn)、開箱即用、效果驚艷”這三個特質(zhì)的結(jié)合。diagram skill 就是典型——它不試圖幫用戶寫代碼、不回答通用問題只專注把圖表這一件事做好反而因為專注而被人記住了。另外還有一點這個項目在 README 里放了很多 before/after 的對比圖用戶一眼就能看到裝了 skill 前后效果的差異。這種“直觀的視覺沖擊”在傳播上的價值遠比寫幾百行功能介紹有效得多。我自己在給團隊做內(nèi)部工具時也沿用了這個策略效果出奇地好。現(xiàn)在回看這個項目的走紅最值得琢磨的不是“又一個 skill 火了”而是“為什么是 diagram 這種看似不起眼的場景先火了”。它背后其實是 Agent 能力從“能聊”到“能交付”的轉(zhuǎn)變——用戶不再滿足于 AI 給出一堆建議而是要它直接產(chǎn)出可用的東西。而圖表恰恰是“可交付物”里最容易讓用戶直觀感知質(zhì)量的形態(tài)。按照這個趨勢接下來大概率還會有一批垂直場景的 skill 冒出來比如更專業(yè)的架構(gòu)評審類 skill、數(shù)據(jù)分析報告類 skill甚至是面向特定行業(yè)的文檔規(guī)范類 skill。這種“把專家經(jīng)驗結(jié)構(gòu)化讓 Agent 按標(biāo)準(zhǔn)執(zhí)行”的思路可能才是未來一年 AI 工具鏈里真正值得關(guān)注的方向。