dontbesilent 的 21 個 Skills，藏着一套「消解」哲學

由 12,307 條推文到 21 個工具，將問題變成可以推進嘅方向

嗰篇 ljg 出咗之後，有人私信問我話，你提到仲有另外兩個倉庫，第二個呢，幾時安排？

我當時覆咗兩個字，安排。

因為講 dbskill 呢樣嘢，唔係隨口講得清楚嘅。

佢同 ljg-skills 喺同一個工具箱入面，但係佢哋做緊嘅嘢，方向完全唔同。

ljg-skills 做嘅係「讀、諗、寫、發佈」，係知識嘅處理流程。

dbskill 做嘅係「診斷」。

然後呢，唔係幫你回答問題，係幫你將問題消解咗。

呢兩件事嘅分別，比你想象中大好多。

先講作者。

dontbesilent ，網名「別沉默」。 X 帳號常年活躍，風格好直，少廢話，刀刀見血。佢唔寫教程，寫嘅係判斷，一條推文經常就係一個結論，然後配一句「諗清楚呢件事，我花咗好耐」。

dbskill 從邊度嚟？佢將自己 12,307 條推文全部拉出嚟，用結構化嘅方式提煉成知識原子（ Knowledge Atom ）， 4,176 條，每條都打咗標籤，標主題、標類型、標置信度，然後將高頻出現嘅判斷邏輯，做咗 21 個 Agent Skill 。

而家呢個倉庫有 6.5k 粒 star ， 841 個 fork 。

唔係教程帳號嘅搬運，係一個人長期思考嘅沉澱物整成嘅工具。

呢兩回事嚟。

我自己第一次用 /dbs-diagnosis 嘅時候，係卡喺一個選題方向，反覆做反覆覺得唔啱，但係講唔出邊度唔啱。

我將問題掟入去，期待佢畀我一個答案。

佢冇。

佢先將我個問題拆咗一次，話你描述嘅呢個問題，有三個前提假設，你確認呢三個假設都成立嗎？

我一睇，有一個假設明顯唔成立。

然後問題自己就冇咗。

嗰個唔叫解決，叫消解。感覺完全唔同，唔係揾到出口，係發現度牆根本唔使推。

好，而家我由頭帶大家行一次， 21 個 Skill ，按佢哋實際嘅作用邏輯分幾段講。

第一段，核心診斷工具

呢一段係整個倉庫嘅主軸，亦係 dontbesilent 思想密度最高嘅地方。

/dbs，主入口

唔需要記住所有工具名，入嚟講你遇到咩，佢自動判斷應該用邊個 Skill 接你。

呢個設計其實幾重要。好多工具箱死喺「用戶唔知用邊個」呢件事， dbs 嘅主入口係一個路由器，幫你做第一步判斷。你唔使預先做功課，直接描述處境，佢嚟分流。

/dbs-diagnosis，商業模式診斷

呢個係整個倉庫嘅核心。

佢嘅口號得七個字，消解問題，唔回答問題。

咩叫消解？你有個問題，佢唔直接畀方案，而係先審呢個問題本身成唔成立，將問題入面隱含嘅假設挖出嚟，逐個問你係咪真係成立。如果假設唔成立，問題就自然溶解咗，唔需要回答。

背後嘅知識框架叫「 6 公理 + 消解漏斗」，係從 dontbesilent 推文入面提煉出嚟嘅判斷模型。唔係 GPT 即場編嘅，係佢真係用呢套框架診斷過好多生意之後沉澱落嚟嘅。

我見過有人將一個卡咗三個月嘅營運問題掟入去，一輪對話落嚟發現，原來嘅問題根本唔係問題，係方向判斷未做就開始執行。

執行越勤力，走偏越遠。呢句說話刺耳，但係真嘅。

/dbs-benchmark，對標分析

五重過濾，排除噪音，揾到真正值得模仿嘅參照對象。

呢度要講一個好常見嘅困境。你知道要揾對標，搜咗一輪，揾到七八個，然後唔知學邊個，結果全部學咗啲皮毛，變成四不像。

原因通常係，你揾嚟嘅對標，表面睇好似，但底層邏輯同你嘅處境完全唔同。人哋做內容係靠社羣起嚟嘅，你想照住做，但你冇社羣基礎，方法根本唔適用。

佢嘅五重過濾做嘅就係呢件事，幫你將表面似但底層邏輯唔同嘅對標剔除，留低真正值得深挖嘅。

我自己用過一次之後，由原本準備參考嘅七八個帳號，過濾到兩個。效率提升唔止係數量減少，係清晰度變高咗。精力有限，對住兩個認真學，比起對住八個各學少少扎實得多。

/dbs-content，內容創作診斷

五維檢測，唔係教你寫咩，係掃你嘅內容邊度出咗問題。

呢個同市面上大部份「幫你優化文案」嘅工具本質上唔同。優化文案係美容，內容診斷係體檢。前者幫你將現有嘅嘢改好睇，後者話畀你聽呢篇嘢喺邊個維度出咗問題。

兩件事解決嘅唔係同一層嘅問題。

文章出咗冇人睇，可能係開頭冇鈎，可能係信息密度太低，可能係核心判斷被稀釋咗，可能係目標讀者根本對唔上。你唔知係邊個，優化文案冇用，因為你喺度優化症狀，唔係治病根。

我用佢檢測過自己嘅稿，佢畀咗一條反饋話，呢篇嘅核心判斷稀釋咗，你喺第三段將一個好有力嘅觀點用太多解釋稀釋咗，讀者讀到嗰度已經覺得你喺度退縮。

睇完當時就想拍大髀。因為我自己寫嘅時候完全冇意識到，我以為啲解釋係加分，佢話我知啲解釋係減分。

/dbs-hook，短視頻開頭優化

診斷加生成，兩步走。

先話畀你聽你而家嘅開頭邊度有問題，然後幫你生成幾個方向嘅改法。

你可能見過嗰種開頭，「大家好，今日同大家分享一個我最近發現嘅超級好用嘅工具」。

呢種開頭嘅問題唔係太囉嗦，係畀咗觀眾一個退出嘅理由，冇任何懸疑，冇任何緊張感，冇任何「我點解要繼續睇」嘅理由。

短視頻嘅前三秒係生死線，唔係齋講，平台嘅推薦算法會睇完播率，完播率低推流就停。

佢畀嘅係改法方向，唔係直接取代。因為開頭係最個人嘅嘢，你嘅帳號調性係你自己長期輸出積累出嚟嘅，工具冇辦法幫你注入，只能幫你睇清楚而家嘅問題喺邊，然後你跟住嗰個方向改。

/dbs-xhs-title，小紅書標題公式

75 個爆款公式匹配。

呢個係整個倉庫入面最「工具化」嘅一個，使用門檻最低，直接用就出結果，唔使太多背景瞭解。

佢將「爆款標題背後嘅模式」整成可查詢嘅形式，例如「痛點 + 解法 + 數字」、「反直覺判斷」、「身份代入」呢啲結構，全部有對應嘅模板同真實案例。

我唔敢話佢對所有人都有效，因為標題能唔能夠起作用，最終都係取決於內容本身值唔值得㩒入去。但係如果你喺標題上花嘅時間太長、經常卡住唔知點寫，呢個工具可以幫你先有個方向，而唔係對住空白框發吽哣。

/dbs-ai-check， AI 寫作特徵識別

22 條特徵掃描，只診斷唔改。

留意呢個設計，只診斷唔改，係一個好明確嘅界線。

好多 AI 寫作檢測工具係幫你「洗稿」嘅，檢測完自動幫你改成有人味嘅版本，咁做係錯嘅。 dbs-ai-check 唔做呢件事，佢只係話畀你聽自己辛苦編寫嘅呢篇命中咗邊幾條 AI 特徵，命中喺邊度，點樣改要你自己決定。有時自己用緊 AI 輔助查數據同蒐集材料嘅時候，本身來源可能就係 AI 創作嘅，佢要幫你過濾檢測，防止你編寫文章嗰陣引用數據出現明顯嘅 AI 味道。

點解咁設計？因為 AI 味嘅對立面唔係「句式更口語」，係「你真係有呢個判斷」。

AI 寫出嚟嘅文章，最大嘅問題唔係詞彙，係冇立場，觀點永遠係「 A 有呢個優勢， B 有嗰個優勢，具體要根據情況判斷」。呢種安全感係以犧牲所有判斷力為代價嘅。

自動洗稿工具改嘅係皮，改唔到呢層。真正要改，要靠你自己返去嗰個判斷，重新將你嘅立場打返入去。

第二段，橫向工具

呢啲工具唔係診斷主線，但如果你喺某個具體節點卡住咗，佢哋係最好用嘅。

/dbs-slowisfast，慢就係快

呢個名乍睇好似心靈雞湯，但佢做嘅唔係鼓勵你。

佢係幫你揾到你而家路徑入面值得「刻意慢落嚟」嘅環節，即係你喺度行捷徑但實際製造摩擦嘅地方。

舉個具體例子。你做內容，每次發佈前唔做選題驗證，直接寫，寫完發。呢個流程睇落快，慳咗選題驗證嘅步驟。但如果寫咗三十篇，二十五篇都冇自然流量，咁三十篇嘅時間成本比起認真做五次選題驗證高好多。

大部份人行捷徑嘅時候感受唔到自己行緊捷徑，因為感覺上係慳咗力。 dbs-slowisfast 做嘅係令嗰個隱性代價顯形，然後幫你判斷邊啲環節嘅「慢」係值得嘅投資，邊啲「快」係透支緊之後嘅時間。

/dbs-action，執行力診斷

呢個工具原本叫 dbs-unblock ，改名咗，但「 unblock 」呢兩個字其實更準確。

佢基於阿德勒心理框架，核心假設係，大部份「做唔到」嘅問題，唔係執行力唔夠，係有啲嘢喺暗處阻住你，而嗰樣嘢你自己通常睇唔到。

可能係你唔相信呢件事真係有結果。可能係你擔心做出嚟之後會俾人批評。可能係呢件事背後牽涉一個你唔想碰嘅關係問題。可能係你對「呢件事做好嘅標準」本身有恐懼。

阿德勒嘅框架唔講意志力，講嘅係目的。所有「唔做」都有原因，而且嗰個原因通常係服務緊某一個你冇意識到嘅目的。將嗰個目的顯形，先至可以決定下一步係改變目標定係移除障礙。

佢嘅對話方式唔係「你點解拖延」呢種審問式，而係一層一層咁往入面問。你而家喺呢件事上卡喺邊？如果開始做會發生咩？如果真係做咗之後呢？

成日問到第三輪，你自己就講咗出嚟，原來我一直喺度等一個條件，但個條件其實係我自己設嘅，唔係真實嘅門檻。

嗰啲時刻有啲奇怪，唔係俾人說服，係自己講出嚟之後發現講唔通。

/dbs-deconstruct，概念拆解

維特根斯坦式審查。

呢個名聽落好哲學，但佢做嘅嘢非常實用。

好多爭論、好多卡住、好多「我哋講緊同一件事嗎」嘅困惑，根源都係概念冇對齊。維特根斯坦有句話，哲學上嘅困惑，本質都係語言嘅困惑。

放喺日常工作入面，呢句話一啲都唔誇張。

你同拍檔爭「做唔做品牌」，爭咗一個鐘，最後發現你哋對「品牌」嘅定義根本唔同，一個人講緊視覺系統，一個人講緊用戶認知。呢個唔係觀點分歧，係概念冇對齊。

dbs-deconstruct 做嘅係將你用嚟描述問題嘅概念逐個檢查，呢個詞你用嘅方式同人哋用嘅一樣嗎？呢個詞喺你嘅上文下理入面指的到底係咩？界線喺邊？有冇內部矛盾？

行完之後你會發現，好多「問題」消解咗，因為問題入面嘅核心詞根本就冇穩定嘅意思。將概念講清楚，分歧自然少咗一半。

/dbs-goal，目標清晰化

你有冇遇過呢種情況，一個項目做咗兩個月，返轉頭睇，好似乜都做咗，但講唔出成唔成功。

問題好大機會唔係執行，係當初目標本身就係模糊嘅。

「做好內容」、「提升品牌知名度」、「將產品打磨得更好」，呢啲都唔係目標，係方向感，係情緒，係願景，但唔係可以檢查嘅嘢。

/dbs-goal 做嘅係一件好樸素嘅事，佢陪住你將一個模糊目標拆成「可檢查嘅交付物說明」。

拆完之後嘅結果係咁嘅，唔係「提升內容質量」，而係「六月底前，至少三篇文章喺發佈後 48 小時內自然閲讀破 1000 ，而且保留到第 7 日嘅閲讀比例大過 20%」。

前者係願望，後者係標準。

有咗標準，你先至可以喺執行到一半嘅時候返嚟問，而家離目標仲有幾遠？接下來應該優先做咩？冇標準，呢兩個問題永遠係一團模糊嘅焦慮。

我自己用佢整理過一個季度計劃，整理完之後發現原來列嘅七件事入面，有三件根本冇辦法用嚟衡量「做咗未」，於是將佢哋刪咗，專注喺剩低嗰四件。

後來嗰個季度係我執行完成度最高嘅一次，唔係因為我更努力，係因為我知道咩叫「完成」。

/dbs-good-question 或 /好問題，好問題生成器

將模糊問題改成 Agent 可以推理、可以批評、可以驗證嘅問題說明書。

呢個工具嘅存在本身就說明咗一個問題，大部份人俾 AI 嘅提問， Agent 係冇辦法真正處理嘅。

唔係因為 AI 唔聰明，係因為問題本身嘅信息密度太低， Agent 冇足夠嘅抓手。

「幫我優化嚇我嘅商業模式」，呢個問題 AI 接得到，但輸出質量天花板好低，因為佢唔知你嘅處境、你嘅限制條件、你認為「優化」代表咩、咩叫做做到。

換成「我而家做 B 端 SaaS ，月收入 3 萬，主要靠舊客續費，新客獲取成本過高，請診斷呢個增長瓶頸背後嘅核心假設，同埋列出最值得先驗證嘅兩個方向」，出嚟嘅嘢就完全唔同。

dbs-good-question 做嘅係將前者變成後者，佢問你幾個問題，然後將你嘅模糊提問重構成高信息密度嘅問題說明書，再拎去餵其他工具，輸出質量換咗一個量級。

/dbs-decision 或 /決策系統，個人決策系統

呢個係 dontbesilent 最近版本入面最大嘅模塊。

四層結構，事實、規律、定格、待解。

每一層嘅寫入規則唔同。規律層有門檻，要滿足三條標準入面嘅兩條先寫得入去，防止你將臨時感受當成長期規律，防止你將好運歸因成方法論。

佢嘅設計哲學係，重大決策應該有記錄，記錄本身係資產，唔係流水帳，係一個長期演化嘅知識體系。

你喺某個領域做咗三年決策之後，呢個系統入面嘅積累，會比任何外部顧問都更瞭解你呢個具體情況。因為外部顧問瞭解嘅係普遍規律，但呢個系統記錄嘅係你踩過嘅坑、你喺乜嘢條件下判斷準確、你喺乜嘢條件下容易誤判。

呢啲嘢只能靠時間積累，但冇記錄系統，時間過咗乜都唔剩。

/dbs-learning 或 /dbs-learn，交互式學習

將課題拆成連續文章，根據上一篇嘅反饋生成下一篇。

同普通 AI 教學工具嘅分別係，佢唔係一次過將知識點全部掟曬畀你，而係每次淨係生成一篇，然後等你嘅反饋，根據你真實嘅理解程度同卡點，決定下一篇從邊個角度切入。

例如你喺度學 RAG 呢套技術棧，你話我對向量檢索理解咗，但 rerank 嗰部分未搞清楚，佢下一篇就專門由 rerank 切入，唔會因為你上一篇「睇完」就默認你全部識。

大部份線上課程嘅問題係單向傳輸，佢唔知你邊度唔明，只能按固定順序播。呢個工具係雙向嘅，難度自適應，每次都從你真實嘅理解邊界出發。

學習難度自適應，係真係同你呢個具體嘅人對話，唔係播預先錄好嘅課程。

第三段，狀態管理三件套

呢三個工具放喺成個倉庫入面，乍睇最唔起眼。佢哋冇「診斷」兩個字，亦冇型格嘅框架名。

但如果你真係用過 dbs-diagnosis 超過三次，你就知呢三件套有幾關鍵。

因為有件事係客觀存在嘅，一次診斷唔夠。

你今日將一個商業問題帶入去，分析咗四十分鐘，得出咗幾個方向，有兩個被否決咗，有一個值得繼續推進。然後你閂咗個視窗，三日後返嚟，乜都冇曬。

下一次對話， AI 唔記得你。你唔記得自己上次講到邊度。然後你重新講背景，重新舖一次來龍去脈，然後兜兜轉轉，返到差唔多嘅位置。

呢個唔係 AI 嘅問題，係上下文視窗本來就唔係無限嘅，而診斷呢件事，本來就需要時間先積累到密度。

/dbs-save、/dbs-restore、/dbs-report 呢三件套，做嘅係同一件事，將「跨對話嘅連續性」變成一件可操作嘅事。

/dbs-save，存檔

每次診斷結束，或者進行到關鍵節點，行一次 /dbs-save。

佢會將當前嘅關鍵結論、被否決嘅方向、推薦嘅下一步，整理成一份結構化嘅記錄寫到本地。

留意兩個字，新增，唔覆蓋。

呢個設計非常刻意。大部份工具嘅「保存」係覆寫，上次嘅嘢俾新嘅取代。 dbs-save 嘅每一次都係追加，你每一輪診斷都係一個獨立嘅時間戳條目，可以回溯，可以睇清楚你嘅判斷係點樣演化嘅。

我用過之後有一個好直接嘅感受，當我返轉頭睇上個月存嘅嗰份記錄，發現我否決嘅一個方向，當時嘅理由其實唔係好充分，只係因為嗰個禮拜做咗另一件事就擱置咗。

嗰個信息喺我個腦入面根本冇可能留到，但喺文件入面仲喺度。

/dbs-restore，讀檔

呢個係存檔嘅閉環另一半。

你返嚟，講句「繼續上次」，或者直接 /dbs-restore，佢將上次嘅存檔內容拉返當前上下文，重新錨定狀態，然後繼續行落去。

唔使由頭講背景，唔使重新解釋上次點解否決咗嗰個方案，唔使再舖一次公司情況同目標。

直接由「下一步」出發。

聽落好似係個小功能，但佢解決嘅係一個隱性嘅消耗，每次都要重新舖背景，會磨蝕好大一部分你繼續推進嘅意欲。摩擦夠低，先至會真係用存檔，先至會真係保持到診斷嘅連續性。

呢個設計思路喺成個 dbskill 入面出現過唔止一次，將阻礙用戶行動嘅摩擦消咗，而唔係叫用戶應該行動。

/dbs-report，合併報告

儲咗三次、五次、十次存檔之後，呢啲碎片化嘅記錄可以用 /dbs-report 合併。

佢將所有存檔按時間順序整理成一份帶時間索引嘅 Markdown 文件，每個階段嘅關鍵結論、轉捩點、被否決嘅方向、當時嘅判斷理由，全部保留，全部可以跳轉定位。

用途有幾種。

可以用嚟自己覆盤，睇一個決策由模糊到清晰嘅完整路徑係點樣嘅。可以話畀拍檔睇，唔使你再用口頭解釋來龍去脈，份報告就係所有背景。可以用嚟做季度總結，你呢三個月喺邊啲事上嚟回打轉，卡喺邊度，有冇真正推進，報告入面有時間證據。

好多人的項目死喺「缺乏覆盤」，但缺乏覆盤嘅真正原因唔係懶，係冇嘢可以覆盤，因為過程冇留低記錄。

dbs-report 令呢件事有咗原材料。

第四段，進階模塊

呢兩個工具定位比較特別，面向嘅係有一定基礎之後嘅用法。

/dbs-content-system，內容結構化系統

將你本地大量嘅內容材料，砌成一個可以持續生長嘅內容資產工程。

好多做內容嘅人有一個共同困境，做咗兩三年， Notion 入面、本地文件夾入面、語雀入面，周圍都係碎片，有啲係寫到一半嘅草稿，有啲係當時記低嘅諗法，有啲係做過嘅調研記錄。

你知道嗰度有嘢，但每次要用嘅時候揾唔到，每次揾到嘅時候已經過期咗，每次想盤點又覺得太亂唔知從邊度入手。

/dbs-content-system 嘅流程係先審計你嘅內容規模同邊界，再建立新工程，複製原始材料，然後按主題同類型抽取內容單元，最後生成主題地圖同選題裝配稿。

行完之後，你嗰堆亂七八糟嘅嘢變成咗一個有結構嘅資產庫，每個單元都有標籤，每個主題都有覆蓋情況，揀選題嘅時候唔係對住空白框諗，係對住地圖睇邊度仲空咗。

/dbs-agent-migration， Agent 工作台遷移

將任何項目整理成 Claude Code 、 Codex 、 Grok 三端一致嘅 Agent 工作台。

而家愈嚟愈多人用多個 AI 工具，然後每個工具有自己嘅規則文件，時間一長， AGENTS.md 同 CLAUDE.md 各自講各自嘅，規則互相打交，你改咗呢邊嗰邊仲用緊舊嘅，最後唔知邊個係真正嘅源頭。

呢種混亂係隱性損耗，你感受唔到佢有幾影響效率，直到某次 AI 畀你一個完全相反方向嘅建議，你去查先知兩個規則文件入面嘅指令係矛盾嘅。

/dbs-agent-migration 做嘅就係將呢堆亂七八糟嘅嘢理清楚，審計所有規則文件，識別真源，統一命名，打通 Bridge ，令三端用同一套規則運作。

第五段， chatroom 系列

呢兩個工具係成個倉庫入面氣氛最特別嘅。

/dbs-chatroom-austrian 或 /奧派，奧派經濟聊天室

哈耶克、米塞斯、 Claude ，三個角色同時在線，對話一個經濟學問題。

我第一次用佢討論「平台抽傭係咪合理」呢個問題，哈耶克同米塞斯由唔同角度同時輸出，中間仲互相補充同修正。哈耶克由分散知識嘅角度話，平台嘅抽傭比例唔係計劃出嚟嘅，係喺無數次交易中自發演化到嘅均衡；米塞斯由行動學（ praxeology ）嘅角度話，抽傭係咪合理呢個問題本身就設錯咗，合理唔合理係價值判斷，真正嘅問題係邊個喺度執行呢個判斷。

嗰二十分鐘嘅閲讀體驗，比起我自己去揭兩本書有效率得多。

唔係因為佢更全面，係因為對話形式令兩個立場之間嘅張力變得具體，你睇得見分歧喺邊，而唔係兩段各自完整嘅論述擺喺度冇交叉。

/dbs-chatroom 或 /定向聊天室，定向聊天室

v2.14.2 入面更新嘅呢個版本，改咗一個好有意思嘅問題。

之前推薦專家靠嘅係固定名單，容易推出一堆泛財經、靠表達出名嘅人，但判斷密度低。睇落係一場多元對話，實際上大家都係講緊差唔多嘅嘢，只係措辭唔同。

新版本係先判斷話題欠咗咩視角，再選擇真正能夠推進討論嘅人。

例如你喺度討論「 AI 會唔會取代創意工作者」，佢判斷呢個話題欠嘅唔係 AI 專家，係一個研究過工業革命時期手工藝者處境嘅歷史學家，仲有一個喺第一線做創意工作嘅人，然後先至去匹配角色。

呢個改動背後嘅判斷係，多角色對話嘅價值唔在於知名度，在於視角密度。

安裝方式。

Claude Code 直接插件市場安裝。

claude plugin marketplace add dontbesilent2025/dbskill claude plugin install dbs@dontbesilent-skills

通用方式，適用於 Codex 或者 Claude Code 。

npx -y skills add dontbesilent2025/dbskill -g --all

Trae/Vscode/Cursor/Antigravity 嘅用戶去 GitHub Releases 下載最新嘅 dbskill-版本號.zip，入面有 21 個獨立 Skill zip ，逐個拖入去就得。

最後講知識庫呢件事。

dbskill 有一個完全開放嘅知識庫，知識庫/原子庫/atoms.jsonl， 4,176 條結構化知識原子，全量開放。

可以直接導入自己嘅向量數據庫做 RAG （ Retrieval-Augmented Generation ），可以只用入面嘅案例部分，可以將方法論文檔直接貼入自己嘅 system prompt 。

唔安裝 Skill 都用得。呢個係 dontbesilent 喺設計上嘅一個明確立場，所有內容開放，可以成套裝，亦可以只拎一部分。

講完呢 21 個工具，我返轉頭想講一件事。

呢套工具箱嘅核心哲學就係「消解」，但我發現好多人拎到佢嘅第一反應係，好用，可以幫我更快咁解決問題。

呢個理解同設計者嘅意圖剛好相反。

dontbesilent 嘅框架入面有一條好重要嘅判斷，大部份你以為需要解決嘅問題，其實係假問題，嚟自錯誤嘅假設，嚟自模糊嘅概念，嚟自將目標同手段混淆咗。

將呢啲假問題解決咗，會製造另一批假問題。

但係將佢哋消解咗，你就有精力去揾嗰個真正值得推進嘅事。

中世紀有個出名嘅迷信，叫「生命之石」。

據講有塊石頭，食咗可以長生不老，無數人傾家蕩產去揾，有人死喺路上，有人將全副身家押曬，換嚟塊石頭咬咗一啖發現係礦石。

後來有個醫生講咗一句話，長生不老嘅石頭唔存在，但你揾佢嘅過程入面學識分辨咗一百種礦物，知道邊啲有毒邊啲冇害，呢件事係真實嘅。

我覺得 dbs-diagnosis 呢個「消解」嘅設計，背後係一樣嘅邏輯。

你以為你喺度揾答案，但係一輪一輪問落嚟之後，你獲得嘅係辨別「邊啲問題值得問」嘅能力。

嗰個能力，比任何具體答案都更值錢。

從 12,307 條推文到 21 個工具，把問題變成可以推進的方向

那篇 ljg 發出去之後，有人私信我說，你提到還有另外兩個倉庫，第二個呢，啥時候安排？

我當時回覆了兩個字，安排。

因為說 dbskill 這件事，不是隨手就能說清楚的。

它和 ljg-skills 在同一個工具箱裏，但它們在做的事情，方向完全不同。

ljg-skills 做的是「讀、思、寫、發佈」，是知識的處理流。

dbskill 做的是「診斷」。

然後呢，不是幫你回答問題，是幫你把問題消解掉。

這兩件事的區別，比你想象的大得多。

先說作者。

dontbesilent ，網名「別沉默」。 X 賬號常年活躍，風格很直，少廢話，刀刀見血。他不寫教程，寫的是判斷，一條推文經常就是一個結論，然後配一句「想清楚這件事，我花了很久」。

dbskill 從哪來的？他把自己 12,307 條推文全部拉出來，用結構化的方式提煉成知識原子（ Knowledge Atom ）， 4,176 條，每條都打了標籤，標主題、標類型、標置信度，然後把高頻出現的判斷邏輯，做成了 21 個 Agent Skill 。

現在這個倉庫有 6.5k 顆 star ， 841 個 fork 。

不是教程賬號的搬運，是一個人長期思考的沉澱物做成了工具。

這是兩回事。

我自己第一次用 /dbs-diagnosis 的時候，是卡在一個選題方向上，反覆做反覆覺得不對，但說不清楚哪裏不對。

我把問題扔進去，期待它給我一個答案。

它沒有。

它先把我的問題拆了一遍，說你描述的這個問題，有三個前提假設，你確認這三個假設都成立嗎？

我一看，有一個假設明顯不成立。

然後問題自己就沒了。

那不叫解決了，叫消解了。感覺完全不一樣，不是找到了出口，是發現那道牆根本不需要推。

好，現在我從頭帶大家走一遍， 21 個 Skill ，按它們實際的作用邏輯分幾段說。

第一段，核心診斷工具

這一段是整個倉庫的主軸，也是 dontbesilent 思想密度最高的地方。

/dbs，主入口

不需要記住所有工具名，進來說你遇到什麼，它自動判斷該用哪個 Skill 接你。

這個設計其實挺重要。很多工具箱死在「用戶不知道該用哪個」這件事上， dbs 的主入口是一個路由器，幫你做第一步判斷。你不用提前做功課，直接描述處境，它來分流。

/dbs-diagnosis，商業模式診斷

這是整個倉庫的核心。

它的口號只有七個字，消解問題，不回答問題。

什麼叫消解？你有個問題，它不直接給你方案，而是先審這個問題本身成不成立，把問題裏隱含的假設挖出來，一個個問你是不是真的成立。如果假設不成立，問題就自然溶解了，不需要回答。

背後的知識框架叫「 6 公理 + 消解漏斗」，是從 dontbesilent 推文裏提煉出來的判斷模型。不是 GPT 現編的，是他真的用這套框架診斷過很多生意之後沉澱下來的。

我見過有人把一個卡了三個月的運營問題扔進去，一輪對話下來發現，原來的問題根本不是問題，是方向判斷沒做就開始執行了。

執行越勤快，跑偏越遠。這話刺耳，但是真的。

/dbs-benchmark，對標分析

五重過濾，排除噪音，找到真正值得模仿的參照對象。

這裏要說一個很常見的困境。你知道要找對標，搜了一圈，找來七八個，然後不知道該學哪個，結果全部學了一點皮毛，變成四不像。

原因通常是，你找來的對標，表面看起來像，但底層邏輯和你的處境完全不同。別人做內容是靠社羣起來的，你想照着做，但你沒有社羣基礎，方法根本不適用。

它的五重過濾乾的就是這件事，幫你把那些表面像但底層邏輯不同的對標剔掉，留下真正值得深挖的。

我自己用過一次之後，從原本準備參考的七八個賬號，過濾到兩個。效率提升不只是數量減少，是清晰度變高了。精力有限，能對着兩個認真學，比對着八個各學一點扎實得多。

/dbs-content，內容創作診斷

五維檢測，不是教你寫什麼，是掃你的內容哪裏出了問題。

這個和市面上大部分「幫你優化文案」的工具有本質區別。優化文案是美容，內容診斷是體檢。前者幫你把現有的東西改好看，後者告訴你這篇東西在哪個維度出了問題。

兩件事解決的不是同一層的問題。

文章發出去沒人看，可能是開頭沒鈎子，可能是信息密度太低，可能是核心判斷被稀釋了，可能是目標讀者根本對不上。你不知道是哪個，優化文案沒用，因為你在優化症狀，不是在治病根。

我用它檢測過自己的稿子，它給了一條反饋說，這篇的核心判斷稀釋了，你在第三段把一個很有力的觀點用太多解釋稀釋掉了，讀者讀到那裏已經感覺到你在退縮。

看完當時就想拍大腿。因為我自己寫的時候完全沒意識到，我以為那些解釋在加分，它在告訴我那些解釋在減分。

/dbs-hook，短視頻開頭優化

診斷加生成，兩步走。

先告訴你你現在的開頭哪裏有問題，然後給你生成幾個方向的改法。

你可能見過那種開頭，「大家好，今天給大家分享一下我最近發現的一個超級好用的工具」。

這種開頭的問題不是太囉嗦，是給了觀眾一個退出的理由，沒有任何懸念，沒有任何緊張感，沒有任何「我為什麼要繼續看」的理由。

短視頻的前三秒是生死線，不是說說而已，平台的推薦算法會看完播率，完播率低推流就停。

它給的是改法方向，不是直接替換。因為開頭是最個人的東西，你的賬號調性是你自己長期輸出積累出來的，工具沒法替你注入，只能幫你看清楚現在的問題在哪，然後你順着那個方向改。

/dbs-xhs-title，小紅書標題公式

75 個爆款公式匹配。

這個是整個倉庫裏最「工具化」的一個，使用門檻最低，直接用就出結果，不需要太多背景瞭解。

它把「爆款標題背後的模式」做成了可查詢的形式，比如「痛點 + 解法 + 數字」、「反常識判斷」、「身份代入」這些結構，全部有對應的模板和真實案例。

我沒敢說它對所有人都有效，因為標題能不能起作用，最終還是取決於內容本身值不值得點進去。但如果你在標題上花的時間太長、經常卡着不知道怎麼寫，這個工具能幫你先有個方向，而不是對着空白框發呆。

/dbs-ai-check， AI 寫作特徵識別

22 條特徵掃描，只診斷不改。

注意這個設計，只診斷不改，是一個很明確的邊界。

很多 AI 寫作檢測工具是幫你「洗稿」的，檢測完自動幫你改成人味版本，這是不對的。 dbs-ai-check 不幹這件事，它只告訴你自己辛苦編寫的這篇命中了哪幾條 AI 特徵，命中在哪裏，怎麼改要你自己決定。有時候自己在使用AI輔助查詢數據和蒐集素材的時候，本身來源可能就是AI創作的，它需要幫你過濾檢測，防止你編寫文章的時候引用數據出現明顯的AI味道。

為什麼這麼設計？因為 AI 味的對立面不是「句式更口語」，是「你真的有這個判斷」。

AI 寫出來的文章，最大的問題不是詞彙，是沒有立場，觀點永遠是「 A 有這樣的優勢， B 有那樣的優勢，具體要根據情況判斷」。這種安全感是以去掉所有判斷力為代價的。

自動洗稿工具改的是皮，改不了這層。真正要改，要靠你自己回到那個判斷，重新把你的立場打進去。

第二段，橫向工具

這些工具不是診斷主線，但如果你在某個具體節點卡住了，它們是最好用的。

/dbs-slowisfast，慢就是快

這個名字乍一看像心靈雞湯，但它做的不是鼓勵你。

它是幫你找到你當前路徑裏值得「刻意慢下來」的環節，也就是那些你在走捷徑但實際在製造摩擦的地方。

舉個具體的例子。你做內容，每次發佈前不做選題驗證，直接寫，寫完發。這個流程看起來快，省了選題驗證的步驟。但如果寫了三十篇，二十五篇都沒有自然流量，那三十篇的時間成本比認認真真做五次選題驗證高多了。

大部分人走捷徑的時候感受不到自己在走捷徑，因為感受上是省力了。 dbs-slowisfast 做的是讓那個隱性代價顯形，然後幫你判斷哪些環節的「慢」是值得的投資，哪些「快」是在透支後續的時間。

/dbs-action，執行力診斷

這個工具原來叫 dbs-unblock ，改名了，但「 unblock 」這兩個字其實更準確。

它基於阿德勒心理框架，核心假設是，大部分「做不動」的問題，不是執行力不夠，是有什麼東西在暗處把你擋着，而那個東西你自己通常看不見。

可能是你不相信這件事真的有結果。可能是你擔心做出來之後會被評判。可能是這件事背後牽扯一個你不想碰的關係問題。可能是你對「這件事做好的標準」本身有恐懼。

阿德勒的框架不談意志力，談的是目的。所有「不做」都是有原因的，而且那個原因通常在服務某一個你沒意識到的目的。把那個目的顯形，才能決定下一步是改變目標還是移除阻礙。

它的對話方式不是「你為什麼拖延」這種審問式，而是一層一層地往裏問。你現在在這件事上卡在哪？如果開始做會發生什麼？如果真的做成了之後呢？

經常問到第三輪，你自己就說出來了，原來我一直在等一個條件，但那個條件其實是我自己設的，不是真實的門檻。

那種時刻有點奇怪，不是被說服了，是自己說出來了之後發現說不通。

/dbs-deconstruct，概念拆解

維特根斯坦式審查。

這個名字聽起來很哲學，但它乾的事情非常實用。

很多爭論、很多卡殼、很多「我們說的是同一件事嗎」的困惑，根源都是概念沒有對齊。維特根斯坦有句話，哲學上的困惑，本質都是語言的困惑。

放到日常工作裏，這句話一點都不誇張。

你跟合夥人爭「要不要做品牌」，爭了一個小時，最後發現你們對「品牌」的定義根本不一樣，一個人說的是視覺體系，一個人說的是用戶認知。這不是觀點分歧，是概念沒對齊。

dbs-deconstruct 做的是把你用來描述問題的概念逐一檢查，這個詞你用的方式和別人用的一樣嗎？這個詞在你的上下文裏指的到底是什麼？邊界在哪裏？有沒有內部矛盾？

跑完之後你會發現，很多「問題」消解了，因為問題裏的核心詞壓根就沒有穩定的意思。把概念說清楚，分歧自然就少了一半。

/dbs-goal，目標清晰化

你有沒有遇到過這種情況，一個項目做了兩個月，回頭看，好像什麼都做了，但說不清楚成沒成。

問題大概率不是執行，是當初目標本身就是模糊的。

「做好內容」、「提升品牌知名度」、「把產品打磨得更好」，這些都不是目標，是方向感，是情緒，是願景，但不是可以檢查的東西。

/dbs-goal 做的是一件很樸素的事，它陪你把一個模糊目標拆成「可檢查的交付物說明」。

拆完之後的結果是這樣的，不是「提升內容質量」，而是「六月底前，至少三篇文章在發佈後 48 小時內自然閲讀破 1000 ，且留存到第 7 天的閲讀比例大於 20%」。

前者是願望，後者是標準。

有了標準，你才能在執行到一半的時候回來問，現在離目標還有多遠？接下來該優先做什麼？沒有標準，這兩個問題永遠是一團模糊的焦慮。

我自己用它整理過一個季度計劃，整理完之後發現原來列的七件事裏，有三件根本沒法用來衡量「做沒做到」，於是把它們刪掉了，專注在剩下四件。

後來那個季度是我執行完成度最高的一次，不是因為我更努力了，是因為我知道什麼叫「完成」。

/dbs-good-question 或 /好問題，好問題生成器

把模糊問題改成 Agent 可推理、可批評、可驗證的問題說明書。

這個工具的存在本身就說明了一個問題，大部分人給 AI 的提問， Agent 是沒法真正處理的。

不是因為 AI 不聰明，是因為問題本身的信息密度太低， Agent 沒有足夠的抓手。

「幫我優化一下我的商業模式」，這個問題 AI 能接，但輸出質量天花板很低，因為它不知道你的處境、你的約束條件、你認為「優化」意味着什麼、什麼叫做到了。

換成「我現在做 B 端 SaaS ，月收入 3 萬，主要靠老客戶續費，新客獲取成本過高，請診斷這個增長瓶頸背後的核心假設，並列出最值得先驗證的兩個方向」，出來的東西就完全不一樣了。

dbs-good-question 乾的是把前者變成後者，它問你幾個問題，然後把你的模糊提問重構成高信息密度的問題說明書，再去餵給其他工具，輸出質量換了一個量級。

/dbs-decision 或 /決策系統，個人決策系統

這個是 dontbesilent 最近版本里規模最大的模塊。

四層結構，事實、規律、定格、待解。

每一層的寫入規則不同。規律層有門檻，要滿足三條標準裏的兩條才能寫進去，防止你把臨時感受當成長期規律，防止你把運氣好歸因成方法論。

它的設計哲學是，重大決策應該是有記錄的，記錄本身就是資產，不是流水賬，是一個長期演化的知識體系。

你在某個領域做了三年決策之後，這個系統裏的積累，會比任何外部顧問都更瞭解你這個具體的情況。因為外部顧問了解的是普遍規律，但這個系統記錄的是你踩過的坑、你在什麼條件下判斷準確、你在什麼條件下容易誤判。

這些東西只能靠時間積累，但沒有記錄系統，時間過去了什麼都不剩。

/dbs-learning 或 /dbs-learn，交互式學習

把課題拆成連續文章，根據上一篇的反饋生成下一篇。

和普通 AI 教學工具的區別是，它不是一次性把知識點全丟給你，而是每次只生成一篇，然後等你的反饋，根據你真實的理解程度和卡點，決定下一篇從哪個角度切入。

比如你在學 RAG 這套技術棧，你說我對向量檢索理解了，但 rerank 那部分沒搞清楚，它下一篇就專門從 rerank 切入，不會因為你上一篇「看完了」就默認你全懂了。

大部分在線課程的問題是單向傳輸，它不知道你哪裏沒懂，只能按固定順序播。這個工具是雙向的，難度自適應，每次都從你真實的理解邊界出發。

學習難度自適應，是真的在跟你這個具體的人對話，不是在播放錄好的課程。

第三段，狀態管理三件套

這三個工具放在整個倉庫裏，乍一看最不起眼。它們沒有「診斷」二字，也沒有酷炫的框架名字。

但如果你真的用過 dbs-diagnosis 超過三次，你就知道這三件套有多關鍵。

因為有個事情是客觀存在的，一次診斷不夠。

你今天把一個商業問題帶進去，分析了四十分鐘，得出了幾個方向，有兩個被否決了，有一個值得繼續推進。然後你關掉窗口，三天後回來，什麼都沒了。

下一次對話， AI 不記得你。你不記得自己上次說到哪裏。然後你重新講背景，重新鋪一遍來龍去脈，然後兜兜轉轉，回到差不多的位置。

這不是 AI 的問題，是上下文窗口天然不是無限的，而診斷這件事，天然需要時間才能積累出密度。

/dbs-save、/dbs-restore、/dbs-report 這三件套，乾的是同一件事，把「跨對話的連續性」變成一件可操作的事。

/dbs-save，存檔

每次診斷結束，或者進行到關鍵節點，跑一次 /dbs-save。

它會把當前的關鍵結論、被否決的方向、推薦的下一步，整理成一份結構化的記錄寫到本地。

注意兩個字，新增，不覆蓋。

這個設計非常刻意。大部分工具的「保存」是覆寫，上次的東西被新的替換掉。 dbs-save 的每一次都是追加，你的每一輪診斷都是一個獨立的時間戳條目，可以回溯，可以看清楚你的判斷是怎麼演化的。

我用過之後有一個很直接的感受，當我回頭翻上個月存的那份記錄，發現我否決的一個方向，當時的理由其實並不充分，只是因為那周做了另一件事就擱置了。

那個信息在我腦子裏根本不可能留着，但在文件裏還在。

/dbs-restore，讀檔

這是存檔的閉環另一半。

你回來，說一句「接着上次」，或者直接 /dbs-restore，它把上次的存檔內容拉回當前上下文，重新錨定狀態，然後繼續往下走。

不需要從頭講背景，不需要重新解釋上次為什麼否決了那個方案，不需要再鋪一遍公司情況和目標。

直接從「下一步」出發。

聽起來好像是個小功能，但它解決的是一個隱性的消耗，每次都要重新鋪背景，會磨掉很大一部分你繼續推進的意願。摩擦夠低，才會真的去用存檔，才會真的維持住診斷的連續性。

這個設計思路在整個 dbskill 裏出現過不止一次，把阻礙用戶行動的摩擦消掉，而不是告訴用戶應該行動。

/dbs-report，合併報告

攢了三次、五次、十次存檔之後，這些碎片化的記錄可以用 /dbs-report 合併。

它把所有存檔按時間順序整理成一份帶時間索引的 Markdown 文檔，每個階段的關鍵結論、轉折點、被否決的方向、當時的判斷理由，全部保留，全部可以跳轉定位。

用途有好幾種。

可以用來自己覆盤，看一個決策從模糊到清晰的完整路徑是什麼樣的。可以發給合夥人看，不需要你再口頭解釋來龍去脈，那份報告就是所有背景。可以拿來做季度總結，你這三個月在哪些事情上來回打轉，卡在哪裏，有沒有真正推進，報告裏都有時間證據。

很多人的項目死在「缺乏覆盤」，但缺乏覆盤的真正原因不是懶，是沒有什麼東西可以覆盤，因為過程沒有留下記錄。

dbs-report 讓這件事有了原材料。

第四段，進階模塊

這兩個工具定位比較特殊，面向的是有一定基礎之後的用法。

/dbs-content-system，內容結構化系統

把你本地大量的內容素材，搭成一個可以持續生長的內容資產工程。

很多做內容的人有一個共同困境，做了兩三年， Notion 裏、本地文件夾裏、語雀裏，到處都是碎片，有的是寫到一半的草稿，有的是當時記下來的想法，有的是做過的調研記錄。

你知道那裏面有東西，但每次要用的時候找不到，每次找到的時候已經過期了，每次想盤點又覺得太亂不知道從哪下手。

/dbs-content-system 的流程是先審計你的內容規模與邊界，再建立新工程，複製原始素材，然後按主題和類型抽取內容單元，最後生成主題地圖與選題裝配稿。

跑完之後，你那堆亂麻變成了一個有結構的資產庫，每個單元都有標籤，每個主題都有覆蓋情況，選題的時候不是對着空白框想，是對着地圖看哪塊還空着。

/dbs-agent-migration， Agent 工作台遷移

把任意項目整理成 Claude Code 、 Codex 、 Grok 三端一致的 Agent 工作台。

現在用多個 AI 工具的人越來越多，然後每個工具有自己的規則文件，時間一長， AGENTS.md 和 CLAUDE.md 各說各話，規則互相打架，你改了這邊那邊還在用舊的，最後不知道哪個是真源。

這種混亂是隱性損耗，你感受不到它有多影響效率，直到某次 AI 給你一個完全反方向的建議，你去查才發現兩個規則文件裏的指令是矛盾的。

/dbs-agent-migration 乾的就是把這堆亂麻理清楚，審計所有規則文件，識別真源，統一命名，打通 Bridge ，讓三端用同一套規則運作。

第五段， chatroom 系列

這兩個工具是整個倉庫裏氛圍最特別的。

/dbs-chatroom-austrian 或 /奧派，奧派經濟聊天室

哈耶克、米塞斯、 Claude ，三個角色同時在線，對話一個經濟學問題。

我第一次用它討論「平台抽傭是否合理」這個問題，哈耶克和米塞斯從不同角度同時輸出，中間還互相補充和修正。哈耶克從分散知識的角度說，平台的抽傭比例不是計劃出來的，是在無數次交易中自發演化到的均衡；米塞斯從行動學（ praxeology ）的角度說，抽傭是否合理這個問題本身就設錯了，合理不合理是價值判斷，真正的問題是誰在執行這個判斷。

那二十分鐘的閲讀體驗，比我自己去翻兩本書有效率得多。

不是因為它更全面，是因為對話形式讓兩個立場之間的張力變得具體，你看得見分歧在哪，而不是兩段各自完整的論述放在那裏沒有交叉。

/dbs-chatroom 或 /定向聊天室，定向聊天室

v2.14.2 裏更新的這個版本，改掉了一個很有意思的問題。

之前推薦專家靠的是固定名單，容易推出一堆泛財經、靠表達出名的人，但判斷密度低。看起來是一場多元對話，實際上大家都在說差不多的話，只是措辭不同。

新版本是先判斷話題缺什麼視角，再選擇真正能推進討論的人。

比如你在討論「 AI 會不會替代創意工作者」，它判斷這個話題缺的不是 AI 專家，是一個研究過工業革命時期手工藝者處境的歷史學家，還有一個在第一線做創意工作的人，然後才去匹配角色。

這個改動背後的判斷是，多角色對話的價值不在於知名度，在於視角密度。

安裝方式。

Claude Code 直接插件市場安裝。

claude plugin marketplace add dontbesilent2025/dbskill claude plugin install dbs@dontbesilent-skills

通用方式，適用於 Codex 或者 Claude Code 。

npx -y skills add dontbesilent2025/dbskill -g --all

Trae/Vscode/Cursor/Antigravity 的用戶去 GitHub Releases 下最新的 dbskill-版本號.zip，裏面 21 個獨立 Skill zip ，逐個拖進去就行。

最後說知識庫這件事。

dbskill 有一個完全開放的知識庫，知識庫/原子庫/atoms.jsonl， 4,176 條結構化知識原子，全量開放。

可以直接導入自己的向量數據庫做 RAG （ Retrieval-Augmented Generation ），可以只用其中的案例部分，可以把方法論文檔直接貼進自己的 system prompt 。

不安裝 Skill 也能用。這是 dontbesilent 在設計上的一個明確立場，所有內容開放，可以整套裝，也可以只拿一部分。

說完這 21 個工具，我回頭想說一件事。

這套工具箱的核心哲學就是「消解」，但我發現很多人拿到它的第一反應是，好用，可以幫我更快地解決問題了。

這個理解和設計者的意圖剛好相反。

dontbesilent 的框架裏有一條很重要的判斷，大部分你以為需要解決的問題，其實是假問題，來自錯誤的假設，來自模糊的概念，來自把目標和手段混淆了。

把這些假問題解決掉，會製造另一批假問題。

但把它們消解掉，你就有精力去找那個真正值得推進的事情。

中世紀有個著名的迷信，叫「生命之石」。

據說有一塊石頭，吃下去能長生不老，無數人傾家蕩產去尋找，有人死在路上，有人把家底全押上，換來一塊石頭咬了一口發現是礦石。

後來有個醫生說了一句話，長生不老的石頭不存在，但你尋找它的過程裏學會分辨了一百種礦物，知道哪些有毒哪些無害，這件事是真實的。

我覺得 dbs-diagnosis 這個「消解」的設計，背後是一樣的邏輯。

你以為你在找答案，但一輪一輪問下來之後，你獲得的是辨別「哪些問題值得問」的能力。

那個能力，比任何具體答案都更值錢。