Hello，大家好，我是人月聊IT。今天接著AI和大模型方面的話題。即大模型廠商Anthropic最近剛推出的Claude Skills。為了更好地闡述我后面要描述的觀點(diǎn)，我們還是先看下對(duì)于Claude Skills的一些標(biāo)準(zhǔn)解釋和說明。

圖片

Claude Skill 是 Anthropic 推出的一種功能擴(kuò)展機(jī)制,允許用戶為 Claude 添加自定義的能力和工具。簡單來說,它讓 Claude 能夠:

• 連接外部服務(wù)和 API：如數(shù)據(jù)庫、第三方應(yīng)用等
• 執(zhí)行特定領(lǐng)域的任務(wù)：根據(jù)用戶需求定制專門功能
• 擴(kuò)展知識(shí)邊界：訪問實(shí)時(shí)數(shù)據(jù)和專有信息

Claude Skill 的推出主要解決了以下問題:

• 個(gè)性化定制：不同用戶有不同需求,Skill 讓 Claude 能適應(yīng)特定工作流程
• 實(shí)時(shí)數(shù)據(jù)訪問：突破知識(shí)截止日期限制,獲取最新信息
• 自動(dòng)化工作流：將 Claude 集成到現(xiàn)有業(yè)務(wù)系統(tǒng)中
• 提高效率：減少重復(fù)性手動(dòng)操作

對(duì)于一個(gè)完整的Skill技能定義通常包括了知識(shí)庫，工具，技術(shù)，方法步驟，約束等內(nèi)容。比如一個(gè)參考的目錄架構(gòu)如下：

圖片

當(dāng)然，我們可以也可以為互聯(lián)網(wǎng)架構(gòu)師定義一個(gè)叫軟件架構(gòu)師助手的Skill，具體如下：

# skill.yaml - Skill 主配置文件
name: "軟件架構(gòu)師助手"
version: "1.0.0"
description: "專業(yè)的互聯(lián)網(wǎng)軟件架構(gòu)設(shè)計(jì)和技術(shù)決策顧問"
# Skill 的觸發(fā)方式
triggers:
  - keywords: ["架構(gòu)設(shè)計(jì)", "技術(shù)選型", "系統(tǒng)設(shè)計(jì)", "架構(gòu)評(píng)審"]
  - commands: ["/architect", "/design-system"]
# Skill 的能力定義
capabilities:
  - name: "系統(tǒng)架構(gòu)設(shè)計(jì)"
    description: "設(shè)計(jì)可擴(kuò)展、高可用的系統(tǒng)架構(gòu)"
  - name: "技術(shù)選型建議"
    description: "根據(jù)業(yè)務(wù)需求推薦合適的技術(shù)棧"
  - name: "架構(gòu)評(píng)審"
    description: "評(píng)估現(xiàn)有架構(gòu)的問題并提出優(yōu)化方案"
# 知識(shí)庫配置
knowledge_base:
  - type: "documents"
    sources:
      - path: "./knowledge/design_patterns.md"
        description: "常用設(shè)計(jì)模式文檔"
      - path: "./knowledge/best_practices.md"
        description: "架構(gòu)最佳實(shí)踐"
  - type: "templates"
    sources:
      - path: "./templates/microservices.yaml"
      - path: "./templates/event_driven.yaml"
# 工具和 API 集成
tools:
  - name: "diagram_generator"
    type: "api"
    endpoint: "https://api.example.com/generate-diagram"
    description: "生成架構(gòu)圖"
    auth:
      type: "api_key"
      key_env: "DIAGRAM_API_KEY"
  - name: "tech_stack_analyzer"
    type: "function"
    description: "分析技術(shù)棧兼容性和成熟度"
# 輸出格式配置
output_formats:
  - type: "markdown"
    template: "./templates/architecture_doc.md"
  - type: "diagram"
    format: "mermaid"
# 約束和規(guī)則
constraints:
  - "始終考慮系統(tǒng)的可擴(kuò)展性和可維護(hù)性"
  - "技術(shù)選型需要考慮團(tuán)隊(duì)技術(shù)棧和學(xué)習(xí)成本"
  - "遵循 SOLID 原則和 12-Factor App 方法論"
  - "優(yōu)先推薦開源成熟的技術(shù)方案"
# 示例對(duì)話
examples:
  - user: "我需要設(shè)計(jì)一個(gè)電商系統(tǒng)的架構(gòu)"
    assistant: "我會(huì)幫您設(shè)計(jì)。首先確認(rèn)幾個(gè)關(guān)鍵需求：預(yù)期用戶規(guī)模、核心業(yè)務(wù)流程、性能要求..."
  - user: "應(yīng)該選擇單體架構(gòu)還是微服務(wù)？"
    assistant: "讓我分析您的場景：團(tuán)隊(duì)規(guī)模、業(yè)務(wù)復(fù)雜度、迭代速度要求..."

所以從上面定義也可以看到，一個(gè)Skill包括了方法流程，知識(shí)庫，操作規(guī)則和約束，工具技術(shù)，參考示例等各個(gè)方面的內(nèi)容。

當(dāng)你看了這個(gè)定義是不是感覺和提示詞工程，MCP上下文工程很類似，或者感覺這就是一個(gè)結(jié)構(gòu)化文字定義的AI Agent？那么我們究竟應(yīng)該如何去理解Skills呢？這里給出一個(gè)簡單公式：

Skills = 大模型+方法（worflow+規(guī)則)+工具(mcp call)+知識(shí)庫(rag或其他知識(shí)形態(tài)）

大家都知道對(duì)于大模型，它一直在想方設(shè)法的拓展它對(duì)外部的一些邊界和能力。從最早的Function Call到MCP上下文工程，再到A2A Agent協(xié)議，所有的這些都是為了更好的擴(kuò)展大模型的知識(shí)邊界，方便大模型和外部的協(xié)同。但是實(shí)際仍然很難達(dá)成滿足我們垂直業(yè)務(wù)場景的需求目標(biāo)。

也正是這個(gè)原因，我們?cè)诖竽Ｐ蜕厦鏄?gòu)建了大量的AI Agent智能體。大家不要把Agent理解為一個(gè)應(yīng)用，或者說具備了任務(wù)規(guī)劃分解執(zhí)行記憶能力的智能體。Agent更加重要的是沉淀了你面對(duì)業(yè)務(wù)場景和垂直域問題解決的業(yè)務(wù)經(jīng)驗(yàn)，這才是Agent真正的價(jià)值。

但是我們?cè)谇懊嬉矊ｉT強(qiáng)調(diào)過，隨著大量的Agent的開發(fā)，實(shí)際是造成了大量的AI應(yīng)用信息孤島，后續(xù)難以運(yùn)維和運(yùn)營管理。這個(gè)問題不是簡單的通過A2A協(xié)議就能解決的問題。也正是這個(gè)原因，我在前面也專門談到了應(yīng)該結(jié)合MCP去構(gòu)建一種更加通用的智能體來解決問題。

包括我當(dāng)時(shí)也提出了企業(yè)級(jí)AI應(yīng)用的新范式，即：

圖片

在大模型具備深度推理能力后，企業(yè)級(jí)AI應(yīng)用目標(biāo)是構(gòu)建一個(gè)通用性AI智能體，提供面向業(yè)務(wù)場景和問題的端到端輸出，在這個(gè)過程中需要進(jìn)行問題規(guī)劃理解，拆分，行動(dòng)，歸納總結(jié)，復(fù)盤，記憶能力。企業(yè)級(jí)AI應(yīng)用不應(yīng)該是再開發(fā)一個(gè)個(gè)獨(dú)立的AI Agent信息孤島。

MCP Sever能力接入可以窮舉，但是AI Agent定制化開發(fā)難以窮盡，一個(gè)個(gè)去開發(fā)Agent思路將被淘汰，這個(gè)本質(zhì)仍然是開發(fā)了大量上層的AI應(yīng)用信息孤島。

而對(duì)于Claude Skill的推出，也進(jìn)一步加強(qiáng)了我原來的一些觀點(diǎn)。對(duì)于里面的一些關(guān)鍵點(diǎn)，我準(zhǔn)備再展開進(jìn)行說明如下：

從知識(shí)到技能

為了更好的解釋上面的觀點(diǎn)，我仍然將Skill翻譯為技能，來探究下從知識(shí)到技能的過程。首先我們要有一個(gè)重要的觀點(diǎn)，就是：知識(shí)是結(jié)果，而技能是應(yīng)用知識(shí)達(dá)到結(jié)果的方法過程。同樣的知識(shí)不同的人用，那么最終的結(jié)果質(zhì)量可能千差萬別。

圖片

如上圖，張三有一個(gè)技能就是應(yīng)用知識(shí)解決問題。比如應(yīng)用架構(gòu)類的知識(shí)去進(jìn)行一個(gè)架構(gòu)設(shè)計(jì)。但是應(yīng)用架構(gòu)類知識(shí)實(shí)際就包括了兩個(gè)方面的關(guān)鍵內(nèi)容，即：

• 顯性化知識(shí)：架構(gòu)規(guī)范，模板，知識(shí)庫
• 隱性知識(shí)：個(gè)人私有經(jīng)驗(yàn)，最佳實(shí)踐

那么張三拿到一個(gè)需求后實(shí)際是如何做這個(gè)事情呢？一個(gè)方面就是要參考標(biāo)準(zhǔn)規(guī)范模板和約束，一個(gè)是應(yīng)用相關(guān)的架構(gòu)設(shè)計(jì)工具，然后就是自己的私有經(jīng)驗(yàn)發(fā)揮作用。這個(gè)私有經(jīng)驗(yàn)原來并沒有顯性化。或者說拿到需求到架構(gòu)設(shè)計(jì)完成都是張三一個(gè)人做這個(gè)事，張三甚至連需求的完整結(jié)構(gòu)化描述這個(gè)事情都不會(huì)做，因?yàn)闆]有必要。這也是我們經(jīng)常說到的，傳統(tǒng)問題解決模式下，由于問題定義和問題解決都是我自己，我甚至沒有做好關(guān)鍵的問題定義和問題解決兩個(gè)工作的分離，但是不影響我最終結(jié)果輸出。

好了，如果現(xiàn)在張三很忙，需要李四來幫助進(jìn)行架構(gòu)設(shè)計(jì)。這個(gè)時(shí)候僅僅提供給李四相關(guān)的架構(gòu)規(guī)劃和模板，李四就能夠輸出同樣質(zhì)量的架構(gòu)文檔嗎？

答案顯然不是，因?yàn)閺埲乃接蚪?jīng)驗(yàn)沒有顯性化。

那么為了讓李四輸出的文檔盡量達(dá)到我們的希望要求，我們經(jīng)常做的事情就是張三會(huì)單獨(dú)給李四交代，做這個(gè)事情的時(shí)候哪些地方是關(guān)鍵點(diǎn)你要注意，哪些歷史項(xiàng)目案例你可以參考，輸出的架構(gòu)哪些地方要注意檢查，哪些集成點(diǎn)不要疏漏？只有把這些交代清楚，李四可能才能夠很好的去做這件事情。

所以你把這個(gè)理解清楚后，就更加容易理解，為何當(dāng)前簡單的提示詞，RAG庫等實(shí)際很難讓大模型得出我們需要的結(jié)果。

知識(shí)固然重要，但是應(yīng)用知識(shí)通達(dá)目的地的路有千萬條，我需要大模型走符合我真實(shí)工作或業(yè)務(wù)場景的路，那么就得將我的私域經(jīng)驗(yàn)顯性化表達(dá)出來，類似原來的提示語工程，或者Agent開發(fā)的Workflow和規(guī)則定義。而現(xiàn)在Skills也是這個(gè)思路。方法，工具，技術(shù)，知識(shí)這些經(jīng)驗(yàn)都需要你提前定義好，給AI一個(gè)更加準(zhǔn)確的操作手冊(cè)，讓AI按你的既定軌道運(yùn)行。

所以Skills實(shí)際是隱性經(jīng)驗(yàn)的極大成者。知識(shí)可以解決通用場景問題，但是只有知識(shí)+技能才能夠更好的解決特定場景下的業(yè)務(wù)問題。這個(gè)和大模型可以解決通用問題，Agent可以解決特定問題是一個(gè)道理。

當(dāng)把這個(gè)理解清楚后，我們?cè)賮砜搓P(guān)系：

Skills和MCP的關(guān)系：實(shí)際技能模板納入了解決特定場景問題需要的工具和外部能力，這些能力可以是通過MCP的方式接入。或者你也可以理解為通過Skills定義對(duì)MCP能力進(jìn)行組裝和編排。

Skills和Agent的關(guān)系：在我們談云計(jì)算的三層分層模型就一直在強(qiáng)調(diào)，底層是資源層，中間是能力和服務(wù)層，上層是應(yīng)用層。那么對(duì)應(yīng)到過來也是一樣的道理，底層大模型是資源層；中間Skills是能力和服務(wù)層；上層Agent是應(yīng)用層。原來編寫在Agent里面的規(guī)則和Workflow等定義實(shí)際是應(yīng)用和能力高度緊耦合。我們現(xiàn)在需要的是將Agent里面能復(fù)用的能力解耦出來，沉淀到Skills技能層，這是后續(xù)實(shí)現(xiàn)Agentic AI能力的基礎(chǔ)。

Skills和RAG的關(guān)系：在Skills定義中會(huì)更加清楚的說明具體知識(shí)庫的應(yīng)用規(guī)則，給出更加準(zhǔn)確的知識(shí)庫知識(shí)的應(yīng)用規(guī)則約束。讓AI查找知識(shí)有的放矢，而不是漫無目的的檢索。類似我們說的Agentic RAG能力。

圖片

所以昨天剛好在群里面看到一篇文章，就是有一個(gè)企業(yè)架構(gòu)的顧問，他就讓ClaudeSkill幫他生成了一個(gè)作為資深的企業(yè)架構(gòu)顧問需要的這么一個(gè)Skill的技能庫，然后基于這個(gè)技能庫讓他去做了一個(gè)行業(yè)的企業(yè)架構(gòu)規(guī)劃分析，這個(gè)事情看起來挺不錯(cuò)，但是實(shí)際上沒有任何的意義。

原因就是什么？

這個(gè)知識(shí)本來就是大模型已有的知識(shí)，這個(gè)技能庫大模型本來就有，你只是把這個(gè)東西顯性化了，你即使不做這個(gè)事情，你讓大模型幫你做一個(gè)行業(yè)的企業(yè)架構(gòu)分析，它基本上也能輸出這個(gè)結(jié)果。

所以技能庫的核心是你個(gè)人結(jié)合行業(yè)，結(jié)合你自己的工作崗位，你特有的一些私域經(jīng)驗(yàn)的顯性化表達(dá)，這個(gè)才是技能的重點(diǎn)。

這個(gè)東西在原有的AI大模型知識(shí)庫里面它是沒有的。

舉一個(gè)最最簡單的例子，我們一個(gè)軟件開發(fā)團(tuán)隊(duì)，我架構(gòu)師就有這么一個(gè)你核心的代碼審查的經(jīng)驗(yàn)，或者是問題排查的經(jīng)驗(yàn)，他把他的這些經(jīng)驗(yàn)把它顯性化為一個(gè)技能，好了，有了這個(gè)技能以后，他相關(guān)的開發(fā)人員你要去做問題分析，代碼的審查你不用找我了，你直接把我的技能庫拷過去，你運(yùn)行這個(gè)技能庫去做代碼分析，你得出的結(jié)果跟我?guī)湍阕鲞@件事情基本上是一樣的，這個(gè)才是真正的價(jià)值。

所以我一直強(qiáng)調(diào)技能這個(gè)東西它一定是私有經(jīng)驗(yàn)的顯性化的表達(dá)，它更強(qiáng)調(diào)了方法過程，而不是最終的知識(shí)庫這么一個(gè)結(jié)果。

復(fù)雜問題求解-問題分解+技能組合

這個(gè)是我今天要強(qiáng)調(diào)的第二個(gè)重要內(nèi)容。通過前面分析大家可以看到，實(shí)際Skills的很多東西在原來的提示詞定義，MCP上下文工程或者Agent開發(fā)里面都有。那么為何我這次給Skills這么高的一個(gè)評(píng)價(jià)？

因?yàn)镾kills技能模式真正解決了知識(shí)的模塊化或者叫知識(shí)的可復(fù)用問題。我們所有復(fù)雜問題的解決，都是底層技能組件的能力組合。定義單個(gè)Skill技能的時(shí)候你可能還無法看到作用，但是上升到企業(yè)或組織級(jí)別，如果能夠定義整個(gè)組織的可復(fù)用技能庫，那么價(jià)值巨大。

所以這里先回顧下我原來講的復(fù)雜問題解決：

圖片

簡單解釋下上面這個(gè)圖，對(duì)于任何問題的解決后，我們需要對(duì)解決方案進(jìn)行拆分，拆分為可以復(fù)用的知識(shí)點(diǎn)或經(jīng)驗(yàn)點(diǎn)。對(duì)于復(fù)雜問題你很難找到完全1對(duì)1匹配的現(xiàn)成解決方案，那么我們對(duì)復(fù)雜問題的解決，本質(zhì)是首先要對(duì)復(fù)雜問題進(jìn)行拆解，將其變成一個(gè)個(gè)子問題，然后在細(xì)粒度上面，我們就容易從知識(shí)技能庫找到對(duì)應(yīng)的解決方案進(jìn)行匹配，最終再將子問題的解決糅合成一個(gè)完整的解決方案。

這個(gè)思想實(shí)際和我經(jīng)常談到的SOA架構(gòu)里面的找到可復(fù)用服務(wù)，然后基于目標(biāo)場景和目標(biāo)快速的組裝和編排服務(wù)一樣的道理。

因此任何復(fù)雜場景復(fù)雜問題的解決，它更多的都是應(yīng)該是底層可復(fù)用的技能組件的組合。你定義可復(fù)用的單個(gè)技能組件不是重點(diǎn)，你企業(yè)去沉淀這么一種可復(fù)用的技能組件庫才是真正的重點(diǎn)。因?yàn)槿魏螐?fù)雜的問題它都可以拆解，拆解完以后，它就是底層各個(gè)經(jīng)驗(yàn)，各個(gè)組件庫的一個(gè)組合。

圖片

舉個(gè)簡單例子。

我現(xiàn)在想要寫一個(gè)應(yīng)標(biāo)的PPT演示文檔，但是這個(gè)事情我把它拆解以后可以看到，第一個(gè)它是首先是要去寫word的文案，接著我要找一個(gè)PPT的高手幫我來做PPT。第三個(gè)步驟我可能還要找一個(gè)美工UI人員對(duì)這個(gè) PPT進(jìn)行美化。

那做完這個(gè)事情其實(shí)就涉及到三個(gè)Skill技能，如果你企業(yè)大模型已有的技能庫里面剛好有這么三種的技能組件，那么你就可以快速的去組裝編排，達(dá)成你最終的一個(gè)目標(biāo)。

在大模型沒有Skill技能這個(gè)概念之前，我們?cè)趺礃幼鲞@個(gè)事情呢？

我們往往是去做了一個(gè)做應(yīng)標(biāo)PPT的一個(gè) AI Agent智能體，來達(dá)到同樣的目的。但是大家要注意，企業(yè)面對(duì)的問題場景層出不窮，千差萬別，如果應(yīng)對(duì)不同的問題，你都要去做這么一種AI智能體的話，那你可能要做成千上萬個(gè)智能體，你才能夠真正滿足企業(yè)的需求，而且這對(duì)智能體就是一堆的信息孤島難以維護(hù)。

真正的做法應(yīng)該是去識(shí)別企業(yè)里面可復(fù)用的各種技能，把它變成一個(gè)個(gè)技能的定義或者叫技能組件。場景沒法從窮舉，但是結(jié)合企業(yè)實(shí)際的行業(yè)垂直的情況，我們的技能庫它是可以窮舉的，這種技能庫就帶來了在企業(yè)里面資深的有經(jīng)驗(yàn)的人，他真正的經(jīng)驗(yàn)做了顯性化的沉淀，這種知識(shí)這種經(jīng)驗(yàn)是可以在企業(yè)內(nèi)部遷移的，而且這種知識(shí)經(jīng)驗(yàn)由于有大量私域經(jīng)驗(yàn)的沉淀，它是通用的互聯(lián)網(wǎng)的大模型沒有的能力，這個(gè)才是我們真正需要的東西。

所以我一直在強(qiáng)調(diào)隨著技能這個(gè)概念的拓展，大模型在企業(yè)內(nèi)部在行業(yè)內(nèi)部垂類的個(gè)性化的應(yīng)用一定會(huì)加速。有了這個(gè)技能庫，等于是我們每個(gè)人都配了一個(gè)AI的一個(gè)外掛或者是AI數(shù)字分身，發(fā)展到后面就是每個(gè)組織都配置了符合企業(yè)要求的滿足特定技能的數(shù)字員工。這才是大模型向企業(yè)端進(jìn)化的關(guān)鍵模式和方法。