一些新手使用 Skill 的問題請教

筆記

神仙打架!?

同問～

MCP 跟 scripts 我都用過，簡單講 stateful 的選 MCP，one-shot 用 scripts 比較省事也省 token

Skill vs MCP 怎麼選我自己有一個蠻簡單的判斷法，給你參考： 需要「來回對話」或「即時拉資料」→ MCP。像你要拉 PR diff、查 CI status、拿 reviewer comments 這些，MCP 比較適合，因為它本來就是設計來讓 agent 跟外部系統互動的。 靜態的 knowledge、guideline、規則 → Skill。iOS coding convention、你們產品的 review checklist、架構原則這類東西不會每次都變，塞 skill 就對了。 所以 code review 這個 use case 其實天然適合兩個搭配用：MCP 負責拉資料（diff、PR context），skill 負責告訴 agent「用什麼標準來 review」。分工蠻清楚的。 你現在 Codex 建 MCP 接自家 API + skill 放 knowledge 的架構基本上就是對的方向 XD 繼續跑應該會越來越順。

MCP 自己包一層接內部 API 確實是正解，尤其你們平台不是 GitHub/GitLab 那種有現成 integration 的。我們之前也幹過類似的事，接內部的 code hosting。 不過有個坑先提醒：PR diff 一大，context window 直接爆掉，review 品質會斷崖式下跌。我後來的做法是先在 MCP 那層做 pre-filter，只餵改動量大的檔案跟關鍵路徑，不要整包丟進去。 至於 skill 放 iOS knowledge 做 review 這個方向沒問題，但建議拆細一點。一包大的「iOS best practice」不如拆成 memory management、concurrency、UI lifecycle 各自一份，agent 比較抓得到重點。塞太多它反而會開始講幹話。

setup.sh 是OK可以行的，我自己也有維護，也很多開源的可以直接用 但是 skill 本身接入還是跟 Coding Agent 或說模型而有點不同， claude Code 提供更深度的應用層介入，而 Codex 則更依賴純粹的 LLM 推理 玩下去就會發現有些 Skill 很難讓共用 Skill+MCP or Skill+Scripts 看個人需求有沒有必要包一層 MCP，自己用的情況 Scripts 就夠，想讓人用又怕程式碼外洩，或有認證等機制，就在往上做 MCP 其實我覺得規畫得很好呀，先從小的案例試試看馬上就能掌握了 :)