Prompt-Engineering
Source:2026-W03
Prompt Engineering
最近針對於Skill的功能使用體驗感到非常熱血，但是看的東西越多讓我腦中的使用情境也開始有點亂，尤其在閱讀這篇文章讓我更有共鳴，Spec-kit我還有購買線上課程去重複看了很多遍也覺得是大有可為的存在之餘，這篇的確也點出我的痛點
认知重建：Speckit 用了三个月，我放弃了——走出工具很强但用不好的困境
小小感想
看到這裡我不禁思考，我是不是應該把這一整套機制也開始評估導入到我的團隊，我突然的想法是
- Skills是否應該作為KPI，因為還是沒有人願意想要寫文件，追蹤產出是一個暴力解法push大家去學習
- 呼叫幾次可以作為指標，寫跟寫得好是兩回事，我是否有辦法統計AI呼叫SKill的次數，讓我足以判斷SKills的品質
Skill + Command + Agent 建立時機
下一步
第1步驟:建立 Skills(知識基礎)
建立團隊共識的標準
優先順序:
- fashion-ecommerce Skill (核心領域知識)
- vector-search Skill (技術規範)
- fastapi-patterns Skill (開發規範)
為什麼先建 Skills?
後續 Commands 和 Agents 都會自動載入這些知識
第2步:建立 Commands(加速開發)
當你發現重複做相同任務時,立即建立 Command:
- /create-search-endpoint (第 2 次生成 API 時建立)
- /batch-process-images (第 2 次批次處理時建立)
- /test-search-quality (第 3 次測試時建立)
觸發條件:「如果我再做一次這個任務,我會懶得重新輸入」→ 建立 Command
第3步+:建立 Agents(專業分工)
當系統穩定後,開始建立專家 Agents:
- @performance-auditor (效能優化階段)
- @code-reviewer (程式碼審查階段)
- @data-quality-checker (維護階段)
觸發條件:「這個任務的上下文太多,會干擾我的主要工作」→ 建立 Agent
先記錄到這邊
中間還有很多需要細細咀嚼的,對於怎樣落地、適合團隊的SOP、怎樣打照一個生態是下一步需要思考的