遷移代碼倉用到的那批 Skill，連 MCP 也一起被換掉了：一篇掘金分享的前端 AI 工作流

先把背景補上。2026 年 9 月 30 日，掘金作者「菠蘿的蜜」發布了一篇工作流分享，主題很具體：他在做遷移代碼倉時用到的幾個 skill，以及一批量 MCP 的捨棄與替代方案。作者自稱「喫胖 20 斤的前端仔」，任職於某互聯網公司，帳號累積 92 篇文章、26.4 萬閱讀。

這類貼文向來是技術社羣的流量密碼之一。它不談宏大架構，只展示「我每天真的這樣用」，而這次分享裡最有意思的一點，是他把 MCP 換成了 token 消耗更低的 skill 方案，等於在 AI 工具選型上做了一次明確的取捨。

六個 skill，各管一段

作者的遷移流程大致是這樣排開的：

• show-me：遷移過程中會生成大量組件，這個 skill 用來直觀呈現模組之間的組件關係與數據流走向，方便復盤或研究效能問題。
• to-tickets：作者已自建一套 spec 生成流程，因此不需要 to-spec，而是用 to-tickets 把已制定好的功能清單再切細，生成幾張小清單。他的說法是，這樣 agent 工作時不會無序錯亂，開發後的驗證更有保障，幻覺也更少。
• implement：與 to-tickets 搭配使用，清單切好後由它實施功能開發。
• resolving-merge-conflicts：多人開發或上遊有更新時使用，會追溯代碼提交源頭、分析上下遊代碼，最後解決衝突。
• code-review：一個分支對應一個 issue，開發完成後調用，基於專案 rules 檢查不足之處，主要是規範類和 spec 功能清單的檢查。
• code-simplifier：代碼行數超過 350 行時用一下。

可以看到，這套流程的核心不是單點工具，而是把「切清單、實作、驗證、收拾」拆成不同環節，每個環節交給對應的 skill。清單切得越細，agent 越不容易跑偏，這是作者反覆強調的一點。

MCP 被換掉的那一批

分享的後半段是替換方案。playwright-mcp 換成 playwright-cli，context7 換成 ctx7。作者的說法是，本質上就是把 MCP 方案換成 token 消耗更低的 skill 方案，並提到 playwright-cli 官網有一張圖可以說明差異。

另外他也推薦 Mac 用戶試試 ego-lite 瀏覽器。理由有三個：它提供 ego-browser skill，可以打開一個獨立的瀏覽器空間做功能驗證；共享原本的 cookie；頁面上的 DOM 節點會映射為 ref 節點，更省 token。他的結論是比 playwright 好用不少。

為什麼這類分享一直有人看

把這篇和技術社羣裡其他 AI 工作流貼文並排放在一起看，脈絡是清楚的。開發者圈對 AI 協作的討論，已經從「能不能用」進入到「怎麼省著用、怎麼驗證」的階段。token 消耗、幻覺控制、清單化管理，這些詞彙反覆出現在分享文中，幾乎成了這一波 AI 工作流貼文的共同語彙。

這也與先前在 V2EX 流傳的Agent 模型層與規則層的分享講的是同一件事：能力上限看模型，行為紀律看規則與流程設計。菠蘿的蜜這篇提供了其中一種更具體的前端版本，用清單和驗證環節把 agent 的活動範圍框住。

當然，這是單一作者的個人工作流，token 省了多少、好用多少，文中並沒有附上量化數據，瀏覽器的偏好也屬於個人體驗。但對正在做代碼倉遷移、或被 agent 產出搞得手忙腳亂的前端來說，這種「拿現成流程直接抄」的分享，價值就在於它足夠具體。至於 MCP 與 skill 之爭會不會走向一邊倒，還得看更多實際專案的驗證。