原文：https://x.com/trq212/article/2033949937936085378
為什麼我會讀這篇文章
其實一開始的原因很單純，就是我對 Skills 這個主題有興趣
最近這個概念真的很熱門，大家常把它當成 prompt engineering 的延伸來討論
所以我會想知道，Claude 團隊自己到底是怎麼看待這個工具，又是怎麼把它用在實際工作上的
對我來說，比起只看大家怎麼分享用法，我更想知道原本在第一線使用這些工具的人，最後整理出了哪些真正有用的做法
尤其如果 Skills 真的不只是 prompt 的延伸，而是能進一步接進開發流程，那 Claude 團隊的經驗應該很值得參考
文章裡最值得記住的四件事
1. Don’t State the Obvious
這點我認為很實用，因為很多時候我們在寫規則時，會不自覺把一些模型本來就知道的事情重複寫進去，最後反而稀釋了真正重要的上下文 比起重複常識，一份好的 skill 更應該聚焦在專案特有的規則、例外情況與操作邊界，讓 AI 把注意力放在真正會影響結果的地方
2. Build a Gotchas Section
把 AI 在實際使用 skill 時反覆遇到的失敗、容易忽略的細節持續記錄下來 這類內容看起來不像華麗的方法論，卻往往最有長期價值，因為它記錄的是實際踩坑後留下來的操作知識
3. Use the File System & Progressive Disclosure
文章也提到，不要把所有資訊硬塞進同一份說明文件，而是應該把 skill 拆成有層次的結構，讓 AI 先讀主要規則，必要時再深入更細的內容 這樣的設計不只對 AI 友善，對人類維護者也更友善，因為內容的責任邊界會更清楚，更新起來也比較容易
4. Avoid Railroading AI
skill 的目的不是把 AI 變成只能照稿演出的工具，而是提供足夠的脈絡、資源與限制，讓它能在合理範圍內靈活完成工作 這點我覺得很關鍵，也讓 skill 比我原本想得更像是一種開發流程設計，而不只是提示工程
Skills 真正連接的是流程，不只是知識
我現在會把 Skills 理解成一種流程介面
它不是單純幫 AI 補充背景知識，而是把那些原本只存在於個人經驗、團隊默契與操作習慣中的內容，轉譯成 AI 也能理解、調用與執行的工作方式
所以我讀完之後最直接的感覺是，現在這個時代，已經不是單純「會不會用 AI」的問題，而是能不能把 AI 真正融入 RD 原本的開發流程裡 工具本身大家都能接觸，但真正拉開差距的，會是誰能把這些經驗、規則、腳本與限制整理起來，沉澱成自己的工作資產
所謂「打造自己的專屬武器」，其實就是善用這些技巧去持續迭代、優化自己的開發流程
像是整理 Gotchas、拆分文件結構、補上必要的腳本與限制，這些看起來都只是小技巧，但累積起來，就是讓 AI 更穩定協作的基礎
與其說是在學怎麼使用 AI，不如說是在學怎麼替自己的開發流程建立更強的延伸能力
我最想先驗證的流程
如果要先挑一個我覺得最有機會落地的方向，我目前會先想到 Code Review。現在有了 AI 之後，開發速度其實已經快很多 但往往人工審查還是會花不少時間，特別是在風格一致性、結構檢查、風險提醒，或一些容易遺漏的細節確認上 所以對我來說，比起一開始就追求很大的自動化，我會更想先從 review 這種相對具體、也比較容易觀察效果的流程切入 像是把常看的重點、常見問題、專案慣例整理成 skill，看看 AI 能不能先幫忙做第一層檢查與提醒
結論
我讀完這篇文章後最大的感想是，AI 真正的價值不只是幫忙生成內容，而是能不能被穩定地接進原本的自己的開發流程
Skills 對我來說，不只是提示技巧的延伸，而是一種把經驗、規則與流程整理成可複用資產的方法
文章裡提到的那些技巧，看起來都很細但其實都指向同一件事：讓 AI 更貼近真實工作，而不是停留在一次性的對話互動，而是慢慢把這些做法變成自己工作方式的一部分