rodiyer.idv.tw 拉里拉雜
rodiyer.idv.tw 拉里拉雜
| 問 | Skill 組成結構中，提示詞 prompt（即 SKILL.md）是主要描述檔，描述如何做某件事? |
| ✓ | 〇 |
| ╳ | |
| www.rodiyer.com | |
| 問 | 在 SKILL.md 的 frontmatter 設定中，description 是 Agent 觸發此項 Skill 的唯一依據（包含做什麼及何時用）？ |
| ✓ | 〇 |
| ╳ | |
| www.rodiyer.com | |
| 問 | 因為 Rule（主要規則）是最高指導原則，每次與 AI 對話時都會自動送出，所以建議寫得非常長且非常詳細？ |
| 〇 | |
| ✓ | ╳ |
| www.rodiyer.com | |
| 問 | 若多個技能（Skill）在鏈接執行時出錯，為方便排除失敗的技能，建議將所有相關任務濃縮寫成一份長達一萬行的單一 Skill？ |
| 〇 | |
| ✓ | ╳ |
| www.rodiyer.com | |
| 問 | 在 Antigravity 中，Skill 的組成結構裡專門用來放「非核心且有需求時才讀取的參考資料（例如：內容規則.md）」，以實現漸進式揭露的目錄是？ |
| scripts | |
| ✓ | reference |
| assets | |
| raw | |
| www.rodiyer.com | |
| 問 | skill主要由哪三個部分組成? |
| ✓ | 提示詞 prompt |
| ✓ | 參考資訊 reference |
| 觸發條件 Triggers | |
| ✓ | 程式 scripts |
| www.rodiyer.com | |
| 問 | 在設計 Skill.md 描述檔結構時，若想避免 AI 隨意假設未提供的情境，或在輸入不完整時主動提示補充而非直接猜測，應該在以下哪一個區塊中進行規範？ |
| 任務目標 (Goal) | |
| 觸發條件 (Triggers / Inputs) | |
| 執行步驟 (Workflow Steps) | |
| ✓ | 防錯與限制條件 (Negative Constraints) |
| www.rodiyer.com | |
| 問 | 當我們從網路上安裝不信任來源的 Skill 時，為了避免資安風險，應該檢查哪些方面？ |
| ✓ | 檢查 Skill 內附的 scripts 程式是否有危險操作或傳送隱私資訊 |
| ✓ | 檢查 SKILL.md 描述檔中是否包含敏感指令 |
| ✓ | 評估 Skill 來源是否可靠，盡量從信任的來源去安裝 |
| 只要 Skill 有在 GitHub 上公開，就絕對安全不需做任何檢查 | |
| www.rodiyer.com | |
| 問 | 關於 Rule、Workflows 與 Skill 的使用情境，下列敘述何者正確？ |
| Rule 需要在每一次對話中手動使用 / 來觸發呼叫 | |
| ✓ | Workflows 每次需要透過 / 呼叫，其通常放置步驟明確且執行較複雜的重複性指令，且可包含 skills 的使用 |
| Skill 一在對話啟動時，AI 就會直接完整讀取整份 SKILL.md 描述檔 | |
| Rule 與 Workflows 的定位完全相同，可互相取代 | |
| www.rodiyer.com | |
| 問 | 下列何者「不是」使用 Skill 的主要優點？ |
| 增加 Agent 的能力、降低 LLM 幻覺 | |
| 避免重複輸入指令，維持穩定的結果輸出 | |
| ✓ | 可以自動修改 raw/sources 中的檔案，維護其唯一真實來源的地位 |
| 避免對話一開啟就因載入過於複雜的 Rule 導致 token 快速耗盡 |
沒有留言: