銷技能包：SEO場(chǎng)景下的AI代理實(shí)戰(zhàn))
1. 從“marketingskills”這個(gè)標(biāo)題說(shuō)起它到底想解決什么問(wèn)題第一次看到“marketingskills”這個(gè)詞我腦子里蹦出來(lái)的不是某個(gè)具體工具而是一類很實(shí)際的需求做營(yíng)銷的人尤其是做獨(dú)立站、做SEO、做內(nèi)容增長(zhǎng)的人手里有一堆重復(fù)性高、但又必須做得足夠?qū)I(yè)的活兒——關(guān)鍵詞調(diào)研、競(jìng)品頁(yè)面拆解、FAQ結(jié)構(gòu)化數(shù)據(jù)生成、落地頁(yè)文案打磨、內(nèi)鏈規(guī)劃、元描述批量?jī)?yōu)化。這些活兒?jiǎn)瘟喑鰜?lái)都不算難但架不住量大、瑣碎、還要求一致性。一個(gè)人一天能認(rèn)真寫幾條高質(zhì)量元描述能拆幾個(gè)競(jìng)品頁(yè)面能維護(hù)多少條內(nèi)鏈邏輯答案往往很扎心。“marketingskills”這個(gè)標(biāo)題本質(zhì)上指向的是把營(yíng)銷領(lǐng)域的這些“手藝”沉淀成可復(fù)用、可被AI代理調(diào)用的技能模塊。它不是一個(gè)孤立的腳本而是一套圍繞營(yíng)銷場(chǎng)景組織起來(lái)的技能集合。關(guān)鍵詞里出現(xiàn)了Claude Code、AI agents、Agent Skills spec、SEO這幾個(gè)詞放在一起指向就很清楚了用Claude Code這類支持Agent Skills規(guī)范的AI編程代理把營(yíng)銷工作流拆成一個(gè)個(gè)可被代理識(shí)別、加載、執(zhí)行的技能單元讓代理在真實(shí)項(xiàng)目里按需調(diào)用而不是每次都從零寫提示詞。我為什么對(duì)這個(gè)方向感興趣因?yàn)檫^(guò)去一年我?guī)秃脦讉€(gè)做獨(dú)立站的朋友處理過(guò)SEO相關(guān)的批量工作最深的體會(huì)是提示詞工程的天花板很低。你寫一個(gè)“幫我生成FAQ結(jié)構(gòu)化數(shù)據(jù)”的提示詞第一次效果不錯(cuò)第二次換個(gè)頁(yè)面就崩了第三次代理忘了輸出格式。問(wèn)題不在于模型不行而在于提示詞是“一次性”的沒有結(jié)構(gòu)化的技能定義、沒有明確的輸入輸出契約、沒有可復(fù)用的邊界。Agent Skills spec這類規(guī)范要解決的恰恰是這個(gè)——把“怎么做一件事”固化成代理能穩(wěn)定加載的技能包。所以這篇博文我不打算泛泛談“AI做營(yíng)銷”而是圍繞marketingskills這個(gè)主題把技能包的結(jié)構(gòu)、營(yíng)銷技能該怎么拆、在Claude Code里怎么落地、SEO場(chǎng)景下哪些技能最值得先做、以及我踩過(guò)的那些坑一條條講清楚。適合誰(shuí)看如果你已經(jīng)在用Claude Code或者類似的AI編程代理想把它用到營(yíng)銷和SEO的實(shí)際工作里這篇能幫你少走彎路如果你還沒上手但手里有大量重復(fù)的營(yíng)銷執(zhí)行工作也能從技能拆分的思路里拿到可復(fù)用的方法。2. Agent Skills spec到底規(guī)定了什么為什么營(yíng)銷場(chǎng)景特別需要它2.1 技能包不是提示詞模板它是一份“可被代理加載的契約”很多人第一次接觸Agent Skills會(huì)把它理解成“高級(jí)一點(diǎn)的提示詞模板”。這個(gè)理解偏差會(huì)直接導(dǎo)致你做出來(lái)的技能包沒法被代理穩(wěn)定調(diào)用。提示詞模板是給人看的你復(fù)制粘貼到對(duì)話框里模型讀一遍就執(zhí)行技能包是給代理看的代理需要在合適的時(shí)機(jī)發(fā)現(xiàn)它、加載它、按它定義的輸入輸出執(zhí)行它還要能在多輪任務(wù)里保持狀態(tài)。Agent Skills spec的核心是把一個(gè)技能定義成幾個(gè)明確的部分技能的名稱和描述代理靠這個(gè)判斷“當(dāng)前任務(wù)該不該用這個(gè)技能”、觸發(fā)條件什么情況下加載、輸入?yún)?shù)需要用戶或上游任務(wù)提供什么、執(zhí)行步驟具體怎么做、輸出格式產(chǎn)出什么結(jié)構(gòu)、以及邊界說(shuō)明什么不做。這幾塊里最容易被忽略、但最關(guān)鍵的是“描述”和“觸發(fā)條件”。代理在決定調(diào)用哪個(gè)技能時(shí)靠的就是這兩塊的信息密度。你寫“生成SEO內(nèi)容”代理不知道什么時(shí)候該用你寫“根據(jù)目標(biāo)關(guān)鍵詞和搜索意圖生成包含F(xiàn)AQ結(jié)構(gòu)化數(shù)據(jù)的落地頁(yè)文案適用于獨(dú)立站產(chǎn)品頁(yè)和博客文章”代理的判斷就準(zhǔn)得多。營(yíng)銷場(chǎng)景為什么特別需要這個(gè)因?yàn)闋I(yíng)銷任務(wù)的“意圖”往往很模糊。用戶說(shuō)“幫我優(yōu)化一下這個(gè)頁(yè)面”這句話背后可能是改標(biāo)題、可能是加內(nèi)鏈、可能是補(bǔ)結(jié)構(gòu)化數(shù)據(jù)、可能是重寫元描述。如果只有一個(gè)大而全的提示詞代理只能猜如果有一組邊界清晰的技能代理可以按頁(yè)面當(dāng)前的問(wèn)題逐個(gè)調(diào)用。這就是技能包相對(duì)提示詞模板的本質(zhì)優(yōu)勢(shì)它把“模糊意圖”拆成了“可判定的任務(wù)”。2.2 營(yíng)銷技能的三個(gè)層次診斷類、生成類、校驗(yàn)類我在實(shí)際拆解營(yíng)銷工作流的時(shí)候發(fā)現(xiàn)技能可以分成三個(gè)層次這個(gè)分層對(duì)后續(xù)組織技能包非常有用。診斷類技能負(fù)責(zé)“看”。比如競(jìng)品頁(yè)面結(jié)構(gòu)分析、關(guān)鍵詞缺口分析、內(nèi)鏈健康度檢查、結(jié)構(gòu)化數(shù)據(jù)覆蓋率檢查。這類技能的特點(diǎn)是輸入是外部數(shù)據(jù)頁(yè)面HTML、關(guān)鍵詞列表、搜索結(jié)果輸出是結(jié)構(gòu)化的診斷報(bào)告。它們不直接產(chǎn)出內(nèi)容但決定了后續(xù)生成類技能該做什么。生成類技能負(fù)責(zé)“寫”。比如FAQ結(jié)構(gòu)化數(shù)據(jù)生成、元描述批量生成、落地頁(yè)文案生成、內(nèi)鏈錨文本建議。這類技能輸入是診斷結(jié)果加業(yè)務(wù)約束輸出是可直接使用的內(nèi)容或代碼片段。它們是最容易被濫用的一類因?yàn)榭雌饋?lái)“讓AI寫就行了”但如果沒有診斷類技能在前面約束生成的內(nèi)容往往偏離搜索意圖。校驗(yàn)類技能負(fù)責(zé)“查”。比如生成的結(jié)構(gòu)化數(shù)據(jù)是否符合規(guī)范、元描述是否超長(zhǎng)、內(nèi)鏈?zhǔn)欠裰赶蛴行ы?yè)面、關(guān)鍵詞密度是否合理。這類技能是質(zhì)量兜底也是最容易被跳過(guò)的一類。我見過(guò)太多人用AI批量生成內(nèi)容后直接發(fā)布結(jié)果結(jié)構(gòu)化數(shù)據(jù)語(yǔ)法錯(cuò)誤、元描述被截?cái)?、?nèi)鏈指向404反而拉低了站點(diǎn)質(zhì)量。這三層不是必須嚴(yán)格分開的一個(gè)技能包內(nèi)部也可以包含診斷加生成的組合。但在設(shè)計(jì)marketingskills這類技能集合時(shí)先按這三層把技能列出來(lái)再?zèng)Q定哪些合并、哪些獨(dú)立思路會(huì)清晰很多。2.3 為什么Claude Code是承載這類技能的合適載體Claude Code這類AI編程代理和純對(duì)話式AI最大的區(qū)別是它能讀寫文件、能執(zhí)行命令、能在項(xiàng)目目錄里持續(xù)工作。這對(duì)營(yíng)銷技能來(lái)說(shuō)太重要了。SEO相關(guān)的很多工作輸入輸出都是文件——頁(yè)面HTML、sitemap、關(guān)鍵詞CSV、結(jié)構(gòu)化數(shù)據(jù)JSON-LD。如果代理只能在對(duì)話框里輸出文本你還得手動(dòng)復(fù)制粘貼到文件里如果代理能直接讀寫項(xiàng)目文件整個(gè)流程就順了。Agent Skills spec在Claude Code里的落地方式通常是把技能定義成項(xiàng)目目錄下的技能文件代理在需要時(shí)加載。這意味著你可以把marketingskills組織成一個(gè)技能目錄里面按診斷、生成、校驗(yàn)分文件存放代理在處理一個(gè)獨(dú)立站優(yōu)化任務(wù)時(shí)可以依次加載“頁(yè)面結(jié)構(gòu)診斷”“FAQ結(jié)構(gòu)化數(shù)據(jù)生成”“結(jié)構(gòu)化數(shù)據(jù)校驗(yàn)”這幾個(gè)技能形成一條完整的工作流。這個(gè)能力是純提示詞方案給不了的。3. 把營(yíng)銷手藝拆成技能我的拆分邏輯和具體清單3.1 拆分的第一原則一個(gè)技能只做一件可驗(yàn)證的事拆技能最容易犯的錯(cuò)是貪大。我一開始設(shè)計(jì)的時(shí)候?qū)懥艘粋€(gè)叫“SEO頁(yè)面優(yōu)化”的技能描述是“對(duì)頁(yè)面進(jìn)行全面的SEO優(yōu)化”。結(jié)果代理加載后輸出了一大堆泛泛的建議什么“標(biāo)題應(yīng)該包含關(guān)鍵詞”“內(nèi)容要有價(jià)值”全是正確的廢話。問(wèn)題就出在“全面優(yōu)化”這個(gè)目標(biāo)不可驗(yàn)證——代理不知道做到什么程度算完成也不知道優(yōu)先做哪一項(xiàng)。后來(lái)我改成按“可驗(yàn)證的最小動(dòng)作”來(lái)拆。什么叫可驗(yàn)證就是這個(gè)技能執(zhí)行完你能明確判斷“做完了沒有”“做對(duì)了沒有”。比如“檢查頁(yè)面是否包含F(xiàn)AQ結(jié)構(gòu)化數(shù)據(jù)”是可驗(yàn)證的“優(yōu)化頁(yè)面SEO”不是。按這個(gè)原則我把營(yíng)銷技能拆成了下面這些具體項(xiàng)。診斷類里我保留了這幾個(gè)頁(yè)面標(biāo)題與元描述現(xiàn)狀提取、H標(biāo)簽層級(jí)結(jié)構(gòu)檢查、關(guān)鍵詞覆蓋與缺口分析、內(nèi)鏈指向與錨文本盤點(diǎn)、結(jié)構(gòu)化數(shù)據(jù)類型識(shí)別、競(jìng)品頁(yè)面模塊拆解。生成類里FAQ結(jié)構(gòu)化數(shù)據(jù)生成、元描述批量生成、落地頁(yè)首屏文案生成、內(nèi)鏈錨文本建議、博客文章大綱生成。校驗(yàn)類里JSON-LD語(yǔ)法校驗(yàn)、元描述長(zhǎng)度與關(guān)鍵詞校驗(yàn)、內(nèi)鏈有效性校驗(yàn)、結(jié)構(gòu)化數(shù)據(jù)必填字段校驗(yàn)。這個(gè)清單不是固定的你可以根據(jù)自己站點(diǎn)的實(shí)際情況增減。但拆分的粒度可以參考一個(gè)技能的執(zhí)行時(shí)間最好控制在代理一次加載能完成的范圍內(nèi)輸出結(jié)果最好是一份結(jié)構(gòu)化數(shù)據(jù)或一個(gè)明確的狀態(tài)。3.2 每個(gè)技能必須寫清楚的五件事拆完技能清單接下來(lái)是給每個(gè)技能寫定義。我總結(jié)了一個(gè)模板五件事必須寫清楚缺一個(gè)都會(huì)導(dǎo)致代理調(diào)用不穩(wěn)定。第一件是技能名稱和一句話描述。名稱要具體描述要包含“什么時(shí)候用”。比如“FAQ結(jié)構(gòu)化數(shù)據(jù)生成”這個(gè)名稱描述寫成“當(dāng)頁(yè)面需要補(bǔ)充FAQ模塊且已有明確的問(wèn)題列表時(shí)生成符合規(guī)范的FAQPage結(jié)構(gòu)化數(shù)據(jù)”。這樣代理在遇到“這個(gè)產(chǎn)品頁(yè)要不要加FAQ”的任務(wù)時(shí)能判斷出該不該加載這個(gè)技能。第二件是輸入?yún)?shù)。要明確每個(gè)參數(shù)是什么、格式是什么、是否必填。比如FAQ生成技能的輸入是問(wèn)題列表數(shù)組必填、答案列表數(shù)組必填、頁(yè)面URL字符串必填、語(yǔ)言字符串選填默認(rèn)中文。參數(shù)寫清楚代理才知道該向用戶要什么或者從上游任務(wù)里取什么。第三件是執(zhí)行步驟。步驟要寫成代理能照著做的動(dòng)作序列而不是給人看的說(shuō)明。比如“第一步校驗(yàn)問(wèn)題列表和答案列表長(zhǎng)度是否一致第二步對(duì)每個(gè)問(wèn)題生成對(duì)應(yīng)的FAQPage條目第三步將所有條目組裝成JSON-LD結(jié)構(gòu)第四步輸出完整代碼塊”。步驟里要包含判斷邏輯比如長(zhǎng)度不一致時(shí)該報(bào)錯(cuò)還是該截?cái)?。第四件是輸出格式。輸出必須是結(jié)構(gòu)化的最好是JSON或明確的代碼塊。我一般要求輸出包含三部分狀態(tài)成功/失敗/部分成功、結(jié)果數(shù)據(jù)、以及執(zhí)行說(shuō)明。這樣上游技能或用戶能直接判斷結(jié)果能不能用。第五件是邊界說(shuō)明。明確寫出這個(gè)技能不做什么。比如FAQ生成技能不負(fù)責(zé)“想問(wèn)題”只負(fù)責(zé)“把已有問(wèn)題轉(zhuǎn)成結(jié)構(gòu)化數(shù)據(jù)”不負(fù)責(zé)校驗(yàn)答案的SEO質(zhì)量只負(fù)責(zé)格式正確。邊界寫清楚代理就不會(huì)越界也不會(huì)在該做A的時(shí)候跑去做B。3.3 一個(gè)完整的技能定義長(zhǎng)什么樣光說(shuō)結(jié)構(gòu)可能還是抽象我拿“FAQ結(jié)構(gòu)化數(shù)據(jù)生成”這個(gè)技能寫一份完整的定義示例。這份定義可以直接放到Claude Code項(xiàng)目的技能目錄里代理加載后就能用。# 技能名稱FAQ結(jié)構(gòu)化數(shù)據(jù)生成 ## 描述 當(dāng)頁(yè)面需要補(bǔ)充FAQ模塊且已有明確的問(wèn)題與答案列表時(shí)生成符合FAQPage規(guī)范的結(jié)構(gòu)化數(shù)據(jù)。適用于獨(dú)立站產(chǎn)品頁(yè)、博客文章、幫助中心頁(yè)面。 ## 觸發(fā)條件 - 用戶明確要求為頁(yè)面添加FAQ結(jié)構(gòu)化數(shù)據(jù) - 上游診斷技能發(fā)現(xiàn)頁(yè)面缺少FAQPage類型結(jié)構(gòu)化數(shù)據(jù) - 頁(yè)面內(nèi)容中已存在問(wèn)答形式的文本塊 ## 輸入?yún)?shù) - questions: 數(shù)組必填問(wèn)題文本列表 - answers: 數(shù)組必填答案文本列表長(zhǎng)度需與questions一致 - pageUrl: 字符串必填頁(yè)面完整URL - language: 字符串選填默認(rèn)zh-CN ## 執(zhí)行步驟 1. 校驗(yàn)questions與answers長(zhǎng)度是否一致不一致則返回錯(cuò)誤狀態(tài)并說(shuō)明差異 2. 校驗(yàn)每個(gè)問(wèn)題是否以問(wèn)號(hào)結(jié)尾未結(jié)尾則自動(dòng)補(bǔ)全 3. 校驗(yàn)每個(gè)答案長(zhǎng)度是否在50到300字之間過(guò)短則標(biāo)記警告過(guò)長(zhǎng)則標(biāo)記警告 4. 按FAQPage規(guī)范組裝JSON-LD結(jié)構(gòu)mainEntity數(shù)組包含所有問(wèn)答對(duì) 5. 輸出完整JSON-LD代碼塊并附帶校驗(yàn)狀態(tài) ## 輸出格式 返回JSON對(duì)象包含 - status: success | partial | error - data: JSON-LD代碼塊字符串 - warnings: 警告信息數(shù)組 - message: 執(zhí)行說(shuō)明 ## 邊界說(shuō)明 - 不負(fù)責(zé)生成問(wèn)題或答案內(nèi)容 - 不負(fù)責(zé)校驗(yàn)答案的SEO質(zhì)量或搜索意圖匹配度 - 不負(fù)責(zé)將代碼塊插入頁(yè)面HTML僅輸出代碼這份定義里觸發(fā)條件、輸入?yún)?shù)、執(zhí)行步驟、輸出格式、邊界說(shuō)明都齊了。代理拿到這份定義能清楚判斷什么時(shí)候用、怎么用、用完得到什么。這就是技能包和提示詞模板的本質(zhì)區(qū)別。4. 在Claude Code里跑通第一個(gè)營(yíng)銷技能從環(huán)境到驗(yàn)證4.1 環(huán)境準(zhǔn)備里最容易被忽略的兩個(gè)細(xì)節(jié)Claude Code的安裝和基礎(chǔ)配置網(wǎng)上教程很多我不重復(fù)。我說(shuō)兩個(gè)實(shí)際用起來(lái)最容易卡住的細(xì)節(jié)。第一個(gè)是項(xiàng)目目錄結(jié)構(gòu)。Claude Code是在項(xiàng)目目錄里工作的技能文件放哪里、代理怎么找到它們直接決定技能能不能被加載。我的做法是在項(xiàng)目根目錄下建一個(gè).claude/skills/目錄每個(gè)技能一個(gè)Markdown文件文件名用技能名稱的英文短橫線格式比如faq-schema-generator.md。然后在項(xiàng)目根目錄的配置文件里聲明技能目錄路徑。這個(gè)結(jié)構(gòu)不是官方強(qiáng)制的但實(shí)測(cè)下來(lái)代理識(shí)別最穩(wěn)定。第二個(gè)是文件編碼和換行符。這個(gè)坑我踩過(guò)。技能文件里如果有中文一定要確保是UTF-8編碼換行符統(tǒng)一用LF。我有一次在Windows上編輯技能文件保存成了CRLF加GBK編碼代理加載后中文全亂碼觸發(fā)條件判斷直接失效。后來(lái)統(tǒng)一用UTF-8加LF再?zèng)]出過(guò)問(wèn)題。如果你在Windows上編輯建議用VS Code右下角能看到編碼和換行符改一下就行。4.2 加載技能并執(zhí)行一次完整調(diào)用環(huán)境準(zhǔn)備好之后怎么驗(yàn)證技能能被正確加載和執(zhí)行我的做法是先用一個(gè)最簡(jiǎn)單的任務(wù)測(cè)試。比如我建好FAQ生成技能后在Claude Code里輸入“讀取項(xiàng)目里的FAQ結(jié)構(gòu)化數(shù)據(jù)生成技能用以下問(wèn)答對(duì)生成結(jié)構(gòu)化數(shù)據(jù)問(wèn)題‘獨(dú)立站SEO多久見效’答案‘通常需要三到六個(gè)月取決于內(nèi)容質(zhì)量和外鏈建設(shè)進(jìn)度’?！贝響?yīng)該做幾件事找到技能文件、讀取定義、校驗(yàn)輸入、執(zhí)行步驟、輸出JSON-LD。如果代理沒有加載技能而是直接憑自己的理解生成了一段JSON-LD說(shuō)明技能沒被識(shí)別到。這時(shí)候要檢查技能文件的路徑和描述是否足夠明確。描述里最好包含“當(dāng)用戶要求生成FAQ結(jié)構(gòu)化數(shù)據(jù)時(shí)使用”這類觸發(fā)語(yǔ)句代理的匹配會(huì)準(zhǔn)很多。執(zhí)行成功后輸出應(yīng)該是一個(gè)完整的JSON-LD代碼塊包含context、type: FAQPage、mainEntity數(shù)組每個(gè)條目有type: Question、name、acceptedAnswer。如果輸出里缺了context或者mainEntity結(jié)構(gòu)不對(duì)說(shuō)明技能定義里的執(zhí)行步驟寫得不夠具體代理自由發(fā)揮了。這時(shí)候要回到技能定義把步驟寫得更死一點(diǎn)。4.3 驗(yàn)證技能穩(wěn)定性的三個(gè)測(cè)試用例一個(gè)技能跑通一次不算數(shù)要測(cè)穩(wěn)定性。我一般用三個(gè)用例測(cè)正常輸入、邊界輸入、異常輸入。正常輸入就是標(biāo)準(zhǔn)的問(wèn)題答案對(duì)看輸出是否符合規(guī)范。邊界輸入是答案特別短比如只有10個(gè)字或者特別長(zhǎng)比如500字看技能是否按定義返回警告。異常輸入是問(wèn)題和答案數(shù)量不一致看技能是否返回錯(cuò)誤狀態(tài)而不是硬著頭皮生成。這三個(gè)用例跑下來(lái)如果正常輸入輸出正確、邊界輸入有警告、異常輸入有錯(cuò)誤狀態(tài)說(shuō)明技能定義是完整的。如果異常輸入時(shí)代理還是生成了數(shù)據(jù)說(shuō)明邊界說(shuō)明沒寫清楚或者執(zhí)行步驟里缺少校驗(yàn)邏輯。這個(gè)測(cè)試方法我用了很多次能快速發(fā)現(xiàn)技能定義的漏洞。5. SEO場(chǎng)景下最值得先做的三個(gè)營(yíng)銷技能5.1 FAQ結(jié)構(gòu)化數(shù)據(jù)生成為什么它比你想的更重要FAQ結(jié)構(gòu)化數(shù)據(jù)這個(gè)技能看起來(lái)簡(jiǎn)單但它是獨(dú)立站SEO里性價(jià)比最高的技能之一。原因有兩個(gè)。第一FAQPage結(jié)構(gòu)化數(shù)據(jù)能讓頁(yè)面在搜索結(jié)果里展示問(wèn)答折疊塊占據(jù)更多視覺空間點(diǎn)擊率提升明顯。第二FAQ模塊本身能覆蓋大量長(zhǎng)尾問(wèn)題這些問(wèn)題的搜索意圖明確轉(zhuǎn)化路徑短。但很多人做FAQ結(jié)構(gòu)化數(shù)據(jù)的方式是錯(cuò)的。他們直接在頁(yè)面底部堆一堆問(wèn)題然后手動(dòng)寫JSON-LD或者用插件生成。手動(dòng)寫容易出錯(cuò)插件生成的結(jié)構(gòu)往往不符合最新規(guī)范。用技能生成的好處是格式校驗(yàn)和結(jié)構(gòu)組裝交給代理人只需要提供問(wèn)題和答案效率高且一致。我在技能定義里加了一條答案長(zhǎng)度在50到300字之間。為什么是這個(gè)范圍太短搜索引擎可能認(rèn)為內(nèi)容單薄不展示太長(zhǎng)折疊塊里顯示不全用戶看不到重點(diǎn)。這個(gè)范圍是我實(shí)測(cè)下來(lái)展示效果最好的區(qū)間。當(dāng)然這不是硬性規(guī)定你可以根據(jù)自己行業(yè)調(diào)整但技能定義里最好有個(gè)明確范圍否則代理生成的答案長(zhǎng)度會(huì)飄。還有一個(gè)細(xì)節(jié)問(wèn)題必須以問(wèn)號(hào)結(jié)尾。這個(gè)看起來(lái)是小事但結(jié)構(gòu)化數(shù)據(jù)規(guī)范里name字段是問(wèn)題文本如果結(jié)尾沒有問(wèn)號(hào)部分搜索引擎可能不識(shí)別為問(wèn)題。技能定義里加一條自動(dòng)補(bǔ)全問(wèn)號(hào)的邏輯能省掉很多手動(dòng)檢查。5.2 元描述批量生成批量不等于千篇一律元描述批量生成是另一個(gè)高頻需求。一個(gè)獨(dú)立站幾百個(gè)頁(yè)面每個(gè)頁(yè)面的元描述都要寫手動(dòng)寫不現(xiàn)實(shí)用AI批量生成又容易千篇一律。技能化之后關(guān)鍵是在定義里加入“差異化約束”。我的做法是技能輸入里除了頁(yè)面標(biāo)題和目標(biāo)關(guān)鍵詞還要求提供頁(yè)面的核心賣點(diǎn)或內(nèi)容摘要。代理生成元描述時(shí)必須把賣點(diǎn)融進(jìn)去而不是只替換關(guān)鍵詞。同時(shí)技能定義里加一條同一批次生成的元描述開頭五個(gè)詞不能重復(fù)。這條約束能有效避免“歡迎來(lái)到XX網(wǎng)站”這種模板化開頭。元描述長(zhǎng)度控制在150到160個(gè)字符之間這是搜索結(jié)果展示的常見上限。技能定義里要寫清楚超長(zhǎng)要截?cái)噙^(guò)短要補(bǔ)充。截?cái)嗖皇呛?jiǎn)單砍掉而是保留完整語(yǔ)義這個(gè)邏輯要寫進(jìn)執(zhí)行步驟里。5.3 內(nèi)鏈錨文本建議被低估的SEO杠桿內(nèi)鏈錨文本這個(gè)技能是我覺得最被低估的。很多人做內(nèi)鏈錨文本就是“點(diǎn)擊這里”“了解更多”這對(duì)SEO幾乎沒幫助。好的錨文本應(yīng)該包含目標(biāo)頁(yè)面的核心關(guān)鍵詞同時(shí)和當(dāng)前頁(yè)面的上下文自然銜接。技能化的做法是輸入當(dāng)前頁(yè)面內(nèi)容、目標(biāo)頁(yè)面URL和核心關(guān)鍵詞輸出三到五個(gè)錨文本建議每個(gè)建議附帶使用位置的說(shuō)明。技能定義里要加一條約束錨文本不能和當(dāng)前頁(yè)面已有錨文本重復(fù)且要符合當(dāng)前頁(yè)面的語(yǔ)氣。這條約束靠代理自己判斷但定義里寫清楚代理的執(zhí)行會(huì)穩(wěn)很多。我實(shí)測(cè)下來(lái)用技能生成的內(nèi)鏈錨文本比手動(dòng)寫的覆蓋關(guān)鍵詞更全而且因?yàn)榇頃?huì)讀當(dāng)前頁(yè)面內(nèi)容銜接自然度也夠。這個(gè)技能配合診斷類的“內(nèi)鏈盤點(diǎn)”技能一起用效果最好——先盤點(diǎn)哪些頁(yè)面缺內(nèi)鏈再針對(duì)性生成錨文本。6. 技能包維護(hù)和迭代那些文檔里不會(huì)寫的經(jīng)驗(yàn)6.1 技能不是寫完就完了要跟著規(guī)范變結(jié)構(gòu)化數(shù)據(jù)的規(guī)范不是一成不變的。FAQPage、HowTo、Product這些類型搜索引擎時(shí)不時(shí)會(huì)調(diào)整字段要求。技能定義如果寫死了字段規(guī)范一變就失效。我的做法是把規(guī)范相關(guān)的字段校驗(yàn)邏輯單獨(dú)抽出來(lái)放在技能文件的一個(gè)“規(guī)范版本”注釋里方便后續(xù)更新。同時(shí)技能定義里的校驗(yàn)步驟盡量寫成“按當(dāng)前FAQPage規(guī)范校驗(yàn)必填字段”而不是硬編碼字段列表。這樣規(guī)范小改的時(shí)候代理能根據(jù)最新理解執(zhí)行不用改技能文件。6.2 技能之間的依賴關(guān)系要顯式聲明marketingskills不是一堆孤立技能它們之間有依賴。比如FAQ生成依賴診斷技能先發(fā)現(xiàn)“頁(yè)面缺FAQ”元描述生成依賴診斷技能先提取“頁(yè)面標(biāo)題和關(guān)鍵詞”。如果依賴關(guān)系不寫清楚代理可能在不該調(diào)用的時(shí)候調(diào)用或者該調(diào)用的時(shí)候不知道先調(diào)哪個(gè)。我的做法是在技能定義的描述里加一句“前置技能”說(shuō)明。比如FAQ生成技能的描述里寫“前置技能頁(yè)面結(jié)構(gòu)化數(shù)據(jù)診斷”。代理在規(guī)劃任務(wù)時(shí)會(huì)先加載前置技能拿到診斷結(jié)果再執(zhí)行生成。這個(gè)做法不是官方規(guī)范但實(shí)測(cè)能提升多技能協(xié)作的穩(wěn)定性。6.3 定期用真實(shí)頁(yè)面回歸測(cè)試技能包用了一段時(shí)間后一定要拿真實(shí)頁(yè)面做回歸測(cè)試。我一般每個(gè)月挑三到五個(gè)頁(yè)面跑一遍完整的診斷、生成、校驗(yàn)流程看輸出質(zhì)量有沒有下降。下降的原因通常是模型更新導(dǎo)致的理解偏差或者技能定義里的描述不夠精確。回歸測(cè)試能及時(shí)發(fā)現(xiàn)這些問(wèn)題避免批量生成的內(nèi)容出問(wèn)題。測(cè)試的時(shí)候要記錄每次的輸出對(duì)比歷史結(jié)果。如果發(fā)現(xiàn)某個(gè)技能的輸出格式開始飄比如JSON-LD里多了不該有的字段或者元描述長(zhǎng)度超了就回去改技能定義把約束寫得更死。技能包的質(zhì)量就是靠這種持續(xù)迭代維持的。7. 關(guān)于marketingskills我目前的一些真實(shí)體會(huì)做這套技能包的過(guò)程中我最大的體會(huì)是AI代理做營(yíng)銷瓶頸不在模型能力而在任務(wù)定義的清晰度。你把任務(wù)拆得越清楚、邊界劃得越明確、輸入輸出契約寫得越死代理的執(zhí)行就越穩(wěn)。反過(guò)來(lái)如果你指望一句“幫我優(yōu)化SEO”就能得到好結(jié)果那不管用什么模型都會(huì)失望。另一個(gè)體會(huì)是技能包的價(jià)值會(huì)隨著數(shù)量增加而指數(shù)級(jí)上升。單個(gè)FAQ生成技能省的是寫JSON-LD的時(shí)間但當(dāng)你有診斷、生成、校驗(yàn)三層技能能串成一條完整工作流時(shí)省的是整個(gè)頁(yè)面的優(yōu)化周期。我現(xiàn)在處理一個(gè)新頁(yè)面從診斷到生成到校驗(yàn)代理跑一遍大概幾分鐘人工只需要審核和微調(diào)。這個(gè)效率提升是單個(gè)提示詞給不了的。最后說(shuō)一個(gè)我還在摸索的方向技能包和站點(diǎn)數(shù)據(jù)的結(jié)合?，F(xiàn)在技能主要處理頁(yè)面級(jí)任務(wù)如果能把站點(diǎn)級(jí)的sitemap、關(guān)鍵詞庫(kù)、內(nèi)鏈圖譜接進(jìn)來(lái)代理就能做更全局的優(yōu)化決策比如“這個(gè)頁(yè)面應(yīng)該內(nèi)鏈到哪三個(gè)頁(yè)面”“這批頁(yè)面的元描述應(yīng)該怎么差異化”。這個(gè)方向我還在試等跑通了再單獨(dú)寫一篇。 用Claude Code和Agent Skills打造營(yíng)銷技能包：SEO場(chǎng)景下的AI代理實(shí)戰(zhàn)
1. 從“marketingskills”這個(gè)標(biāo)題說(shuō)起它到底想解決什么問(wèn)題第一次看到“marketingskills”這個(gè)詞我腦子里蹦出來(lái)的不是某個(gè)具體工具而是一類很實(shí)際的需求做營(yíng)銷的人尤其是做獨(dú)立站、做SEO、做內(nèi)容增長(zhǎng)的人手里有一堆重復(fù)性高、但又必須做得足夠?qū)I(yè)的活兒——關(guān)鍵詞調(diào)研、競(jìng)品頁(yè)面拆解、FAQ結(jié)構(gòu)化數(shù)據(jù)生成、落地頁(yè)文案打磨、內(nèi)鏈規(guī)劃、元描述批量?jī)?yōu)化。這些活兒?jiǎn)瘟喑鰜?lái)都不算難但架不住量大、瑣碎、還要求一致性。一個(gè)人一天能認(rèn)真寫幾條高質(zhì)量元描述能拆幾個(gè)競(jìng)品頁(yè)面能維護(hù)多少條內(nèi)鏈邏輯答案往往很扎心。“marketingskills”這個(gè)標(biāo)題本質(zhì)上指向的是把營(yíng)銷領(lǐng)域的這些“手藝”沉淀成可復(fù)用、可被AI代理調(diào)用的技能模塊。它不是一個(gè)孤立的腳本而是一套圍繞營(yíng)銷場(chǎng)景組織起來(lái)的技能集合。關(guān)鍵詞里出現(xiàn)了Claude Code、AI agents、Agent Skills spec、SEO這幾個(gè)詞放在一起指向就很清楚了用Claude Code這類支持Agent Skills規(guī)范的AI編程代理把營(yíng)銷工作流拆成一個(gè)個(gè)可被代理識(shí)別、加載、執(zhí)行的技能單元讓代理在真實(shí)項(xiàng)目里按需調(diào)用而不是每次都從零寫提示詞。我為什么對(duì)這個(gè)方向感興趣因?yàn)檫^(guò)去一年我?guī)秃脦讉€(gè)做獨(dú)立站的朋友處理過(guò)SEO相關(guān)的批量工作最深的體會(huì)是提示詞工程的天花板很低。你寫一個(gè)“幫我生成FAQ結(jié)構(gòu)化數(shù)據(jù)”的提示詞第一次效果不錯(cuò)第二次換個(gè)頁(yè)面就崩了第三次代理忘了輸出格式。問(wèn)題不在于模型不行而在于提示詞是“一次性”的沒有結(jié)構(gòu)化的技能定義、沒有明確的輸入輸出契約、沒有可復(fù)用的邊界。Agent Skills spec這類規(guī)范要解決的恰恰是這個(gè)——把“怎么做一件事”固化成代理能穩(wěn)定加載的技能包。所以這篇博文我不打算泛泛談“AI做營(yíng)銷”而是圍繞marketingskills這個(gè)主題把技能包的結(jié)構(gòu)、營(yíng)銷技能該怎么拆、在Claude Code里怎么落地、SEO場(chǎng)景下哪些技能最值得先做、以及我踩過(guò)的那些坑一條條講清楚。適合誰(shuí)看如果你已經(jīng)在用Claude Code或者類似的AI編程代理想把它用到營(yíng)銷和SEO的實(shí)際工作里這篇能幫你少走彎路如果你還沒上手但手里有大量重復(fù)的營(yíng)銷執(zhí)行工作也能從技能拆分的思路里拿到可復(fù)用的方法。2. Agent Skills spec到底規(guī)定了什么為什么營(yíng)銷場(chǎng)景特別需要它2.1 技能包不是提示詞模板它是一份“可被代理加載的契約”很多人第一次接觸Agent Skills會(huì)把它理解成“高級(jí)一點(diǎn)的提示詞模板”。這個(gè)理解偏差會(huì)直接導(dǎo)致你做出來(lái)的技能包沒法被代理穩(wěn)定調(diào)用。提示詞模板是給人看的你復(fù)制粘貼到對(duì)話框里模型讀一遍就執(zhí)行技能包是給代理看的代理需要在合適的時(shí)機(jī)發(fā)現(xiàn)它、加載它、按它定義的輸入輸出執(zhí)行它還要能在多輪任務(wù)里保持狀態(tài)。Agent Skills spec的核心是把一個(gè)技能定義成幾個(gè)明確的部分技能的名稱和描述代理靠這個(gè)判斷“當(dāng)前任務(wù)該不該用這個(gè)技能”、觸發(fā)條件什么情況下加載、輸入?yún)?shù)需要用戶或上游任務(wù)提供什么、執(zhí)行步驟具體怎么做、輸出格式產(chǎn)出什么結(jié)構(gòu)、以及邊界說(shuō)明什么不做。這幾塊里最容易被忽略、但最關(guān)鍵的是“描述”和“觸發(fā)條件”。代理在決定調(diào)用哪個(gè)技能時(shí)靠的就是這兩塊的信息密度。你寫“生成SEO內(nèi)容”代理不知道什么時(shí)候該用你寫“根據(jù)目標(biāo)關(guān)鍵詞和搜索意圖生成包含F(xiàn)AQ結(jié)構(gòu)化數(shù)據(jù)的落地頁(yè)文案適用于獨(dú)立站產(chǎn)品頁(yè)和博客文章”代理的判斷就準(zhǔn)得多。營(yíng)銷場(chǎng)景為什么特別需要這個(gè)因?yàn)闋I(yíng)銷任務(wù)的“意圖”往往很模糊。用戶說(shuō)“幫我優(yōu)化一下這個(gè)頁(yè)面”這句話背后可能是改標(biāo)題、可能是加內(nèi)鏈、可能是補(bǔ)結(jié)構(gòu)化數(shù)據(jù)、可能是重寫元描述。如果只有一個(gè)大而全的提示詞代理只能猜如果有一組邊界清晰的技能代理可以按頁(yè)面當(dāng)前的問(wèn)題逐個(gè)調(diào)用。這就是技能包相對(duì)提示詞模板的本質(zhì)優(yōu)勢(shì)它把“模糊意圖”拆成了“可判定的任務(wù)”。2.2 營(yíng)銷技能的三個(gè)層次診斷類、生成類、校驗(yàn)類我在實(shí)際拆解營(yíng)銷工作流的時(shí)候發(fā)現(xiàn)技能可以分成三個(gè)層次這個(gè)分層對(duì)后續(xù)組織技能包非常有用。診斷類技能負(fù)責(zé)“看”。比如競(jìng)品頁(yè)面結(jié)構(gòu)分析、關(guān)鍵詞缺口分析、內(nèi)鏈健康度檢查、結(jié)構(gòu)化數(shù)據(jù)覆蓋率檢查。這類技能的特點(diǎn)是輸入是外部數(shù)據(jù)頁(yè)面HTML、關(guān)鍵詞列表、搜索結(jié)果輸出是結(jié)構(gòu)化的診斷報(bào)告。它們不直接產(chǎn)出內(nèi)容但決定了后續(xù)生成類技能該做什么。生成類技能負(fù)責(zé)“寫”。比如FAQ結(jié)構(gòu)化數(shù)據(jù)生成、元描述批量生成、落地頁(yè)文案生成、內(nèi)鏈錨文本建議。這類技能輸入是診斷結(jié)果加業(yè)務(wù)約束輸出是可直接使用的內(nèi)容或代碼片段。它們是最容易被濫用的一類因?yàn)榭雌饋?lái)“讓AI寫就行了”但如果沒有診斷類技能在前面約束生成的內(nèi)容往往偏離搜索意圖。校驗(yàn)類技能負(fù)責(zé)“查”。比如生成的結(jié)構(gòu)化數(shù)據(jù)是否符合規(guī)范、元描述是否超長(zhǎng)、內(nèi)鏈?zhǔn)欠裰赶蛴行ы?yè)面、關(guān)鍵詞密度是否合理。這類技能是質(zhì)量兜底也是最容易被跳過(guò)的一類。我見過(guò)太多人用AI批量生成內(nèi)容后直接發(fā)布結(jié)果結(jié)構(gòu)化數(shù)據(jù)語(yǔ)法錯(cuò)誤、元描述被截?cái)?、?nèi)鏈指向404反而拉低了站點(diǎn)質(zhì)量。這三層不是必須嚴(yán)格分開的一個(gè)技能包內(nèi)部也可以包含診斷加生成的組合。但在設(shè)計(jì)marketingskills這類技能集合時(shí)先按這三層把技能列出來(lái)再?zèng)Q定哪些合并、哪些獨(dú)立思路會(huì)清晰很多。2.3 為什么Claude Code是承載這類技能的合適載體Claude Code這類AI編程代理和純對(duì)話式AI最大的區(qū)別是它能讀寫文件、能執(zhí)行命令、能在項(xiàng)目目錄里持續(xù)工作。這對(duì)營(yíng)銷技能來(lái)說(shuō)太重要了。SEO相關(guān)的很多工作輸入輸出都是文件——頁(yè)面HTML、sitemap、關(guān)鍵詞CSV、結(jié)構(gòu)化數(shù)據(jù)JSON-LD。如果代理只能在對(duì)話框里輸出文本你還得手動(dòng)復(fù)制粘貼到文件里如果代理能直接讀寫項(xiàng)目文件整個(gè)流程就順了。Agent Skills spec在Claude Code里的落地方式通常是把技能定義成項(xiàng)目目錄下的技能文件代理在需要時(shí)加載。這意味著你可以把marketingskills組織成一個(gè)技能目錄里面按診斷、生成、校驗(yàn)分文件存放代理在處理一個(gè)獨(dú)立站優(yōu)化任務(wù)時(shí)可以依次加載“頁(yè)面結(jié)構(gòu)診斷”“FAQ結(jié)構(gòu)化數(shù)據(jù)生成”“結(jié)構(gòu)化數(shù)據(jù)校驗(yàn)”這幾個(gè)技能形成一條完整的工作流。這個(gè)能力是純提示詞方案給不了的。3. 把營(yíng)銷手藝拆成技能我的拆分邏輯和具體清單3.1 拆分的第一原則一個(gè)技能只做一件可驗(yàn)證的事拆技能最容易犯的錯(cuò)是貪大。我一開始設(shè)計(jì)的時(shí)候?qū)懥艘粋€(gè)叫“SEO頁(yè)面優(yōu)化”的技能描述是“對(duì)頁(yè)面進(jìn)行全面的SEO優(yōu)化”。結(jié)果代理加載后輸出了一大堆泛泛的建議什么“標(biāo)題應(yīng)該包含關(guān)鍵詞”“內(nèi)容要有價(jià)值”全是正確的廢話。問(wèn)題就出在“全面優(yōu)化”這個(gè)目標(biāo)不可驗(yàn)證——代理不知道做到什么程度算完成也不知道優(yōu)先做哪一項(xiàng)。后來(lái)我改成按“可驗(yàn)證的最小動(dòng)作”來(lái)拆。什么叫可驗(yàn)證就是這個(gè)技能執(zhí)行完你能明確判斷“做完了沒有”“做對(duì)了沒有”。比如“檢查頁(yè)面是否包含F(xiàn)AQ結(jié)構(gòu)化數(shù)據(jù)”是可驗(yàn)證的“優(yōu)化頁(yè)面SEO”不是。按這個(gè)原則我把營(yíng)銷技能拆成了下面這些具體項(xiàng)。診斷類里我保留了這幾個(gè)頁(yè)面標(biāo)題與元描述現(xiàn)狀提取、H標(biāo)簽層級(jí)結(jié)構(gòu)檢查、關(guān)鍵詞覆蓋與缺口分析、內(nèi)鏈指向與錨文本盤點(diǎn)、結(jié)構(gòu)化數(shù)據(jù)類型識(shí)別、競(jìng)品頁(yè)面模塊拆解。生成類里FAQ結(jié)構(gòu)化數(shù)據(jù)生成、元描述批量生成、落地頁(yè)首屏文案生成、內(nèi)鏈錨文本建議、博客文章大綱生成。校驗(yàn)類里JSON-LD語(yǔ)法校驗(yàn)、元描述長(zhǎng)度與關(guān)鍵詞校驗(yàn)、內(nèi)鏈有效性校驗(yàn)、結(jié)構(gòu)化數(shù)據(jù)必填字段校驗(yàn)。這個(gè)清單不是固定的你可以根據(jù)自己站點(diǎn)的實(shí)際情況增減。但拆分的粒度可以參考一個(gè)技能的執(zhí)行時(shí)間最好控制在代理一次加載能完成的范圍內(nèi)輸出結(jié)果最好是一份結(jié)構(gòu)化數(shù)據(jù)或一個(gè)明確的狀態(tài)。3.2 每個(gè)技能必須寫清楚的五件事拆完技能清單接下來(lái)是給每個(gè)技能寫定義。我總結(jié)了一個(gè)模板五件事必須寫清楚缺一個(gè)都會(huì)導(dǎo)致代理調(diào)用不穩(wěn)定。第一件是技能名稱和一句話描述。名稱要具體描述要包含“什么時(shí)候用”。比如“FAQ結(jié)構(gòu)化數(shù)據(jù)生成”這個(gè)名稱描述寫成“當(dāng)頁(yè)面需要補(bǔ)充FAQ模塊且已有明確的問(wèn)題列表時(shí)生成符合規(guī)范的FAQPage結(jié)構(gòu)化數(shù)據(jù)”。這樣代理在遇到“這個(gè)產(chǎn)品頁(yè)要不要加FAQ”的任務(wù)時(shí)能判斷出該不該加載這個(gè)技能。第二件是輸入?yún)?shù)。要明確每個(gè)參數(shù)是什么、格式是什么、是否必填。比如FAQ生成技能的輸入是問(wèn)題列表數(shù)組必填、答案列表數(shù)組必填、頁(yè)面URL字符串必填、語(yǔ)言字符串選填默認(rèn)中文。參數(shù)寫清楚代理才知道該向用戶要什么或者從上游任務(wù)里取什么。第三件是執(zhí)行步驟。步驟要寫成代理能照著做的動(dòng)作序列而不是給人看的說(shuō)明。比如“第一步校驗(yàn)問(wèn)題列表和答案列表長(zhǎng)度是否一致第二步對(duì)每個(gè)問(wèn)題生成對(duì)應(yīng)的FAQPage條目第三步將所有條目組裝成JSON-LD結(jié)構(gòu)第四步輸出完整代碼塊”。步驟里要包含判斷邏輯比如長(zhǎng)度不一致時(shí)該報(bào)錯(cuò)還是該截?cái)?。第四件是輸出格式。輸出必須是結(jié)構(gòu)化的最好是JSON或明確的代碼塊。我一般要求輸出包含三部分狀態(tài)成功/失敗/部分成功、結(jié)果數(shù)據(jù)、以及執(zhí)行說(shuō)明。這樣上游技能或用戶能直接判斷結(jié)果能不能用。第五件是邊界說(shuō)明。明確寫出這個(gè)技能不做什么。比如FAQ生成技能不負(fù)責(zé)“想問(wèn)題”只負(fù)責(zé)“把已有問(wèn)題轉(zhuǎn)成結(jié)構(gòu)化數(shù)據(jù)”不負(fù)責(zé)校驗(yàn)答案的SEO質(zhì)量只負(fù)責(zé)格式正確。邊界寫清楚代理就不會(huì)越界也不會(huì)在該做A的時(shí)候跑去做B。3.3 一個(gè)完整的技能定義長(zhǎng)什么樣光說(shuō)結(jié)構(gòu)可能還是抽象我拿“FAQ結(jié)構(gòu)化數(shù)據(jù)生成”這個(gè)技能寫一份完整的定義示例。這份定義可以直接放到Claude Code項(xiàng)目的技能目錄里代理加載后就能用。# 技能名稱FAQ結(jié)構(gòu)化數(shù)據(jù)生成 ## 描述 當(dāng)頁(yè)面需要補(bǔ)充FAQ模塊且已有明確的問(wèn)題與答案列表時(shí)生成符合FAQPage規(guī)范的結(jié)構(gòu)化數(shù)據(jù)。適用于獨(dú)立站產(chǎn)品頁(yè)、博客文章、幫助中心頁(yè)面。 ## 觸發(fā)條件 - 用戶明確要求為頁(yè)面添加FAQ結(jié)構(gòu)化數(shù)據(jù) - 上游診斷技能發(fā)現(xiàn)頁(yè)面缺少FAQPage類型結(jié)構(gòu)化數(shù)據(jù) - 頁(yè)面內(nèi)容中已存在問(wèn)答形式的文本塊 ## 輸入?yún)?shù) - questions: 數(shù)組必填問(wèn)題文本列表 - answers: 數(shù)組必填答案文本列表長(zhǎng)度需與questions一致 - pageUrl: 字符串必填頁(yè)面完整URL - language: 字符串選填默認(rèn)zh-CN ## 執(zhí)行步驟 1. 校驗(yàn)questions與answers長(zhǎng)度是否一致不一致則返回錯(cuò)誤狀態(tài)并說(shuō)明差異 2. 校驗(yàn)每個(gè)問(wèn)題是否以問(wèn)號(hào)結(jié)尾未結(jié)尾則自動(dòng)補(bǔ)全 3. 校驗(yàn)每個(gè)答案長(zhǎng)度是否在50到300字之間過(guò)短則標(biāo)記警告過(guò)長(zhǎng)則標(biāo)記警告 4. 按FAQPage規(guī)范組裝JSON-LD結(jié)構(gòu)mainEntity數(shù)組包含所有問(wèn)答對(duì) 5. 輸出完整JSON-LD代碼塊并附帶校驗(yàn)狀態(tài) ## 輸出格式 返回JSON對(duì)象包含 - status: success | partial | error - data: JSON-LD代碼塊字符串 - warnings: 警告信息數(shù)組 - message: 執(zhí)行說(shuō)明 ## 邊界說(shuō)明 - 不負(fù)責(zé)生成問(wèn)題或答案內(nèi)容 - 不負(fù)責(zé)校驗(yàn)答案的SEO質(zhì)量或搜索意圖匹配度 - 不負(fù)責(zé)將代碼塊插入頁(yè)面HTML僅輸出代碼這份定義里觸發(fā)條件、輸入?yún)?shù)、執(zhí)行步驟、輸出格式、邊界說(shuō)明都齊了。代理拿到這份定義能清楚判斷什么時(shí)候用、怎么用、用完得到什么。這就是技能包和提示詞模板的本質(zhì)區(qū)別。4. 在Claude Code里跑通第一個(gè)營(yíng)銷技能從環(huán)境到驗(yàn)證4.1 環(huán)境準(zhǔn)備里最容易被忽略的兩個(gè)細(xì)節(jié)Claude Code的安裝和基礎(chǔ)配置網(wǎng)上教程很多我不重復(fù)。我說(shuō)兩個(gè)實(shí)際用起來(lái)最容易卡住的細(xì)節(jié)。第一個(gè)是項(xiàng)目目錄結(jié)構(gòu)。Claude Code是在項(xiàng)目目錄里工作的技能文件放哪里、代理怎么找到它們直接決定技能能不能被加載。我的做法是在項(xiàng)目根目錄下建一個(gè).claude/skills/目錄每個(gè)技能一個(gè)Markdown文件文件名用技能名稱的英文短橫線格式比如faq-schema-generator.md。然后在項(xiàng)目根目錄的配置文件里聲明技能目錄路徑。這個(gè)結(jié)構(gòu)不是官方強(qiáng)制的但實(shí)測(cè)下來(lái)代理識(shí)別最穩(wěn)定。第二個(gè)是文件編碼和換行符。這個(gè)坑我踩過(guò)。技能文件里如果有中文一定要確保是UTF-8編碼換行符統(tǒng)一用LF。我有一次在Windows上編輯技能文件保存成了CRLF加GBK編碼代理加載后中文全亂碼觸發(fā)條件判斷直接失效。后來(lái)統(tǒng)一用UTF-8加LF再?zèng)]出過(guò)問(wèn)題。如果你在Windows上編輯建議用VS Code右下角能看到編碼和換行符改一下就行。4.2 加載技能并執(zhí)行一次完整調(diào)用環(huán)境準(zhǔn)備好之后怎么驗(yàn)證技能能被正確加載和執(zhí)行我的做法是先用一個(gè)最簡(jiǎn)單的任務(wù)測(cè)試。比如我建好FAQ生成技能后在Claude Code里輸入“讀取項(xiàng)目里的FAQ結(jié)構(gòu)化數(shù)據(jù)生成技能用以下問(wèn)答對(duì)生成結(jié)構(gòu)化數(shù)據(jù)問(wèn)題‘獨(dú)立站SEO多久見效’答案‘通常需要三到六個(gè)月取決于內(nèi)容質(zhì)量和外鏈建設(shè)進(jìn)度’?！贝響?yīng)該做幾件事找到技能文件、讀取定義、校驗(yàn)輸入、執(zhí)行步驟、輸出JSON-LD。如果代理沒有加載技能而是直接憑自己的理解生成了一段JSON-LD說(shuō)明技能沒被識(shí)別到。這時(shí)候要檢查技能文件的路徑和描述是否足夠明確。描述里最好包含“當(dāng)用戶要求生成FAQ結(jié)構(gòu)化數(shù)據(jù)時(shí)使用”這類觸發(fā)語(yǔ)句代理的匹配會(huì)準(zhǔn)很多。執(zhí)行成功后輸出應(yīng)該是一個(gè)完整的JSON-LD代碼塊包含context、type: FAQPage、mainEntity數(shù)組每個(gè)條目有type: Question、name、acceptedAnswer。如果輸出里缺了context或者mainEntity結(jié)構(gòu)不對(duì)說(shuō)明技能定義里的執(zhí)行步驟寫得不夠具體代理自由發(fā)揮了。這時(shí)候要回到技能定義把步驟寫得更死一點(diǎn)。4.3 驗(yàn)證技能穩(wěn)定性的三個(gè)測(cè)試用例一個(gè)技能跑通一次不算數(shù)要測(cè)穩(wěn)定性。我一般用三個(gè)用例測(cè)正常輸入、邊界輸入、異常輸入。正常輸入就是標(biāo)準(zhǔn)的問(wèn)題答案對(duì)看輸出是否符合規(guī)范。邊界輸入是答案特別短比如只有10個(gè)字或者特別長(zhǎng)比如500字看技能是否按定義返回警告。異常輸入是問(wèn)題和答案數(shù)量不一致看技能是否返回錯(cuò)誤狀態(tài)而不是硬著頭皮生成。這三個(gè)用例跑下來(lái)如果正常輸入輸出正確、邊界輸入有警告、異常輸入有錯(cuò)誤狀態(tài)說(shuō)明技能定義是完整的。如果異常輸入時(shí)代理還是生成了數(shù)據(jù)說(shuō)明邊界說(shuō)明沒寫清楚或者執(zhí)行步驟里缺少校驗(yàn)邏輯。這個(gè)測(cè)試方法我用了很多次能快速發(fā)現(xiàn)技能定義的漏洞。5. SEO場(chǎng)景下最值得先做的三個(gè)營(yíng)銷技能5.1 FAQ結(jié)構(gòu)化數(shù)據(jù)生成為什么它比你想的更重要FAQ結(jié)構(gòu)化數(shù)據(jù)這個(gè)技能看起來(lái)簡(jiǎn)單但它是獨(dú)立站SEO里性價(jià)比最高的技能之一。原因有兩個(gè)。第一FAQPage結(jié)構(gòu)化數(shù)據(jù)能讓頁(yè)面在搜索結(jié)果里展示問(wèn)答折疊塊占據(jù)更多視覺空間點(diǎn)擊率提升明顯。第二FAQ模塊本身能覆蓋大量長(zhǎng)尾問(wèn)題這些問(wèn)題的搜索意圖明確轉(zhuǎn)化路徑短。但很多人做FAQ結(jié)構(gòu)化數(shù)據(jù)的方式是錯(cuò)的。他們直接在頁(yè)面底部堆一堆問(wèn)題然后手動(dòng)寫JSON-LD或者用插件生成。手動(dòng)寫容易出錯(cuò)插件生成的結(jié)構(gòu)往往不符合最新規(guī)范。用技能生成的好處是格式校驗(yàn)和結(jié)構(gòu)組裝交給代理人只需要提供問(wèn)題和答案效率高且一致。我在技能定義里加了一條答案長(zhǎng)度在50到300字之間。為什么是這個(gè)范圍太短搜索引擎可能認(rèn)為內(nèi)容單薄不展示太長(zhǎng)折疊塊里顯示不全用戶看不到重點(diǎn)。這個(gè)范圍是我實(shí)測(cè)下來(lái)展示效果最好的區(qū)間。當(dāng)然這不是硬性規(guī)定你可以根據(jù)自己行業(yè)調(diào)整但技能定義里最好有個(gè)明確范圍否則代理生成的答案長(zhǎng)度會(huì)飄。還有一個(gè)細(xì)節(jié)問(wèn)題必須以問(wèn)號(hào)結(jié)尾。這個(gè)看起來(lái)是小事但結(jié)構(gòu)化數(shù)據(jù)規(guī)范里name字段是問(wèn)題文本如果結(jié)尾沒有問(wèn)號(hào)部分搜索引擎可能不識(shí)別為問(wèn)題。技能定義里加一條自動(dòng)補(bǔ)全問(wèn)號(hào)的邏輯能省掉很多手動(dòng)檢查。5.2 元描述批量生成批量不等于千篇一律元描述批量生成是另一個(gè)高頻需求。一個(gè)獨(dú)立站幾百個(gè)頁(yè)面每個(gè)頁(yè)面的元描述都要寫手動(dòng)寫不現(xiàn)實(shí)用AI批量生成又容易千篇一律。技能化之后關(guān)鍵是在定義里加入“差異化約束”。我的做法是技能輸入里除了頁(yè)面標(biāo)題和目標(biāo)關(guān)鍵詞還要求提供頁(yè)面的核心賣點(diǎn)或內(nèi)容摘要。代理生成元描述時(shí)必須把賣點(diǎn)融進(jìn)去而不是只替換關(guān)鍵詞。同時(shí)技能定義里加一條同一批次生成的元描述開頭五個(gè)詞不能重復(fù)。這條約束能有效避免“歡迎來(lái)到XX網(wǎng)站”這種模板化開頭。元描述長(zhǎng)度控制在150到160個(gè)字符之間這是搜索結(jié)果展示的常見上限。技能定義里要寫清楚超長(zhǎng)要截?cái)噙^(guò)短要補(bǔ)充。截?cái)嗖皇呛?jiǎn)單砍掉而是保留完整語(yǔ)義這個(gè)邏輯要寫進(jìn)執(zhí)行步驟里。5.3 內(nèi)鏈錨文本建議被低估的SEO杠桿內(nèi)鏈錨文本這個(gè)技能是我覺得最被低估的。很多人做內(nèi)鏈錨文本就是“點(diǎn)擊這里”“了解更多”這對(duì)SEO幾乎沒幫助。好的錨文本應(yīng)該包含目標(biāo)頁(yè)面的核心關(guān)鍵詞同時(shí)和當(dāng)前頁(yè)面的上下文自然銜接。技能化的做法是輸入當(dāng)前頁(yè)面內(nèi)容、目標(biāo)頁(yè)面URL和核心關(guān)鍵詞輸出三到五個(gè)錨文本建議每個(gè)建議附帶使用位置的說(shuō)明。技能定義里要加一條約束錨文本不能和當(dāng)前頁(yè)面已有錨文本重復(fù)且要符合當(dāng)前頁(yè)面的語(yǔ)氣。這條約束靠代理自己判斷但定義里寫清楚代理的執(zhí)行會(huì)穩(wěn)很多。我實(shí)測(cè)下來(lái)用技能生成的內(nèi)鏈錨文本比手動(dòng)寫的覆蓋關(guān)鍵詞更全而且因?yàn)榇頃?huì)讀當(dāng)前頁(yè)面內(nèi)容銜接自然度也夠。這個(gè)技能配合診斷類的“內(nèi)鏈盤點(diǎn)”技能一起用效果最好——先盤點(diǎn)哪些頁(yè)面缺內(nèi)鏈再針對(duì)性生成錨文本。6. 技能包維護(hù)和迭代那些文檔里不會(huì)寫的經(jīng)驗(yàn)6.1 技能不是寫完就完了要跟著規(guī)范變結(jié)構(gòu)化數(shù)據(jù)的規(guī)范不是一成不變的。FAQPage、HowTo、Product這些類型搜索引擎時(shí)不時(shí)會(huì)調(diào)整字段要求。技能定義如果寫死了字段規(guī)范一變就失效。我的做法是把規(guī)范相關(guān)的字段校驗(yàn)邏輯單獨(dú)抽出來(lái)放在技能文件的一個(gè)“規(guī)范版本”注釋里方便后續(xù)更新。同時(shí)技能定義里的校驗(yàn)步驟盡量寫成“按當(dāng)前FAQPage規(guī)范校驗(yàn)必填字段”而不是硬編碼字段列表。這樣規(guī)范小改的時(shí)候代理能根據(jù)最新理解執(zhí)行不用改技能文件。6.2 技能之間的依賴關(guān)系要顯式聲明marketingskills不是一堆孤立技能它們之間有依賴。比如FAQ生成依賴診斷技能先發(fā)現(xiàn)“頁(yè)面缺FAQ”元描述生成依賴診斷技能先提取“頁(yè)面標(biāo)題和關(guān)鍵詞”。如果依賴關(guān)系不寫清楚代理可能在不該調(diào)用的時(shí)候調(diào)用或者該調(diào)用的時(shí)候不知道先調(diào)哪個(gè)。我的做法是在技能定義的描述里加一句“前置技能”說(shuō)明。比如FAQ生成技能的描述里寫“前置技能頁(yè)面結(jié)構(gòu)化數(shù)據(jù)診斷”。代理在規(guī)劃任務(wù)時(shí)會(huì)先加載前置技能拿到診斷結(jié)果再執(zhí)行生成。這個(gè)做法不是官方規(guī)范但實(shí)測(cè)能提升多技能協(xié)作的穩(wěn)定性。6.3 定期用真實(shí)頁(yè)面回歸測(cè)試技能包用了一段時(shí)間后一定要拿真實(shí)頁(yè)面做回歸測(cè)試。我一般每個(gè)月挑三到五個(gè)頁(yè)面跑一遍完整的診斷、生成、校驗(yàn)流程看輸出質(zhì)量有沒有下降。下降的原因通常是模型更新導(dǎo)致的理解偏差或者技能定義里的描述不夠精確。回歸測(cè)試能及時(shí)發(fā)現(xiàn)這些問(wèn)題避免批量生成的內(nèi)容出問(wèn)題。測(cè)試的時(shí)候要記錄每次的輸出對(duì)比歷史結(jié)果。如果發(fā)現(xiàn)某個(gè)技能的輸出格式開始飄比如JSON-LD里多了不該有的字段或者元描述長(zhǎng)度超了就回去改技能定義把約束寫得更死。技能包的質(zhì)量就是靠這種持續(xù)迭代維持的。7. 關(guān)于marketingskills我目前的一些真實(shí)體會(huì)做這套技能包的過(guò)程中我最大的體會(huì)是AI代理做營(yíng)銷瓶頸不在模型能力而在任務(wù)定義的清晰度。你把任務(wù)拆得越清楚、邊界劃得越明確、輸入輸出契約寫得越死代理的執(zhí)行就越穩(wěn)。反過(guò)來(lái)如果你指望一句“幫我優(yōu)化SEO”就能得到好結(jié)果那不管用什么模型都會(huì)失望。另一個(gè)體會(huì)是技能包的價(jià)值會(huì)隨著數(shù)量增加而指數(shù)級(jí)上升。單個(gè)FAQ生成技能省的是寫JSON-LD的時(shí)間但當(dāng)你有診斷、生成、校驗(yàn)三層技能能串成一條完整工作流時(shí)省的是整個(gè)頁(yè)面的優(yōu)化周期。我現(xiàn)在處理一個(gè)新頁(yè)面從診斷到生成到校驗(yàn)代理跑一遍大概幾分鐘人工只需要審核和微調(diào)。這個(gè)效率提升是單個(gè)提示詞給不了的。最后說(shuō)一個(gè)我還在摸索的方向技能包和站點(diǎn)數(shù)據(jù)的結(jié)合?，F(xiàn)在技能主要處理頁(yè)面級(jí)任務(wù)如果能把站點(diǎn)級(jí)的sitemap、關(guān)鍵詞庫(kù)、內(nèi)鏈圖譜接進(jìn)來(lái)代理就能做更全局的優(yōu)化決策比如“這個(gè)頁(yè)面應(yīng)該內(nèi)鏈到哪三個(gè)頁(yè)面”“這批頁(yè)面的元描述應(yīng)該怎么差異化”。這個(gè)方向我還在試等跑通了再單獨(dú)寫一篇。