三個文件，十五行指令：我的自動化翻車實錄

　　三個Markdown文件，每個文件大約15行指令——這就是我當初為網站內容自動化搭的“體系”。在VS Code里點一下，讓Copilot對著YouTube鏈接抓取元數據，再把結構化信息寫進對應目錄，看起來一片歲月靜好。可幾個月跑下來，我跟這套方案之間，裂開了一道深溝。

　　先看一眼原來的提示文件有多“精致”。視頻創作的指令長這樣：

　　description: 'Add a new video to the content/videos directory'tools: ['playwright/*']# Add a new videoAdd a new video using the MCP server to navigate to the URL to get the required info you need.- Ask the user for the url if not provided.- Do not invent titles and descriptions.- Do not add extra tags only add ones that already exist in the other video files.- Make sure the date for the video is correct.- Make sure you add a host- Close the browser when done.

　　十幾行松散的自然語言指令，沒有變量約束，沒有異常處理分支。播客和博客的提示文件幾乎一模一樣，只是替換了幾個字段名字。當時我覺得這很優雅：一套規則，稍微改改就能覆蓋三種內容類型。現在回頭看，這種“優雅”其實是技術債的溫柔陷阱。

　　第一個坑：重復指令像癌細胞擴散。三條規則里都寫著“Do not invent titles and descriptions”，都要“only add tags that already exist”，都要“make sure the date is correct”。哪天我想把標簽校驗邏輯改得更嚴——比如只允許已有標簽的前兩類——就得打開三個文件逐個修改。更荒誕的是，它們已經開始互相背叛了：視頻提示里引用的是playwright/*，播客提示卻寫成了microsoft/playwright-mcp/*，版本指向都不一樣。維護成本不知不覺就翻了倍。

　　第二個坑：生成完就當甩手掌柜，完全沒有驗證環節。提示腳本創建好Markdown文件就宣告結束，內容到底能不能在網站里正常渲染，全靠我手動啟動開發服務器、打開瀏覽器一行行去瞅。萬一AI誤解了某個字段的含義，或者用錯了日期格式，等我發現時很可能已經發布了錯誤頁面。自動化只解決了“寫文件”這件事，讀起來像是做了個半成品的機器人，剩下的質檢還得人類自己上場。

　　第三個坑：不帶Pull Request創建，等于白省一半力氣。文件生成后，我還得手工切分支、級聯提交、推送、去GitHub上點開PR模板。整條流水線里，真正讓我煩躁的正是這些重復的Git操作，AI居然完全沒碰。結果就是：最消耗心神的步驟依舊手動，自動化只替我干了最輕快的那部分，性價比低到離譜。

　　第四個坑：被鎖死在VS Code + Copilot的孤島上。這些.prompt.md文件里的tools前置元數據，完全是VS Code Copilot Agent模式的親兒子格式。一旦我想換到Goose、Claude Code這類新興的智能體工具，這些提示文件瞬間變成一坨無法解析的文本。八成的AI編碼工作流都在往跨平臺方向發展，我的自動化卻把自己焊死在一個單一IDE的私槽里，想想就不爽。

　　第五個坑：指令模糊得像在跟實習生打啞謎。“Use the MCP server to navigate to the URL”這半句話，人類讀完大概能猜出要干啥，但AI需要的是手術級指引。實際頁面一復雜就翻車：YouTube彈出Cookie同意彈層，AI直接傻在原地不動；視頻發布日期顯示為“7天前”，AI不會倒推精確日期，只能偷懶寫個近似值。這些靠人工經驗才能消化的邊角細節，提示文件里一個字都沒交代，你只能對著生成結果的偏差生悶氣。

　　坑跳得多了，自然開始往根上找病。一套內容自動化方案，不該是一堆散落、重復、不可遷移的提示文件，而應該像一個可復用的技能包：有清晰輸入輸出、內置校驗、跨工具通用，還得順手把PR這類工程雜務一起包圓。于是從幾周前分享那篇“為什么用AI代理與MCP”的思路出發，我決定發起一場遷移——把這三個半殘的提示文件，重新熔鑄成一枚真正的Agent Skill。而第一步，就是把之前停留在大腦里的架構，落成一串可執行的規則。