AI Engineer onepage/ Skill Vector
Lucas Palma, Nubank · 16:24
這支影片在講：AI skills 進市集前，先把它當成供應鏈風險
Nubank 的安全團隊做了一道「技能入庫閘門」：先用確定性規則抓危險行為，再由 LLM 判讀脈絡，最後才依使用者與權限做出准入決策。目標不是封殺分享，而是讓共享能力可追溯、可核准、可治理。
發布：2026-07-29Video ID: iKQ78wyJEXU
01 / 問題
分享會放大攻擊面
一個 skill 可包含多個風險點；在受監管銀行裡，任意 shell 指令、破壞性操作或過度權限都不能直接流入開發者工具箱。
02 / 反轉
只靠規則不夠
靜態規則很適合抓明確模式，卻不懂語意與意圖；只用 LLM 又難以穩定重現。兩者要串成同一條審查路徑。
03 / 解法
把准入做成產品
Skill Vector 將掃描、決策、權限範圍與人工核准接在市集前面，使安全不是事後救火，而是發佈工作流的一部分。
Signals
影片最值得記住的四個訊號
Coverage
2,000+
已跑過超過兩千個 skills；單一 skill 可能帶有多個問題。
Scan order
Rules → LLM
先檢查可判定的危險模式，再讓模型補上規則看不見的脈絡。
Decision
Gate
不是「掃完就上架」；結果要進入准入、權限與核准流程。
Operating model
Vuln mgmt
發現的問題回流既有弱點管理，並保留人類確認。
Core story
一個可治理的 skill marketplace，至少要補齊三層
01
確定性檢查：把明確不可接受的行為先擋掉
像破壞性 shell command 等高訊號模式，應由規則快速、可重現地偵測。這讓團隊能說清楚「為何被擋」，也為後續審查建立一致底線。
02
LLM 審查：處理規則無法理解的上下文
Skill 的目的、指令組合與實際影響常不是單一字串能判定。LLM 適合補足語意判讀，但輸出應是輔助決策的證據，不是不可解釋的最終裁判。
03
准入與權限：讓「能不能用」與「誰能用」一起被治理
掃描結果需要連到市集決策、使用者範圍與人工確認；問題再回流弱點管理。安全控制因此留在技能被廣泛採用之前，而非事件發生之後。
Practical implications
對 agent / developer platform 團隊的實務啟發
把 skill 視為 dependency，而不是內容盤點它能呼叫什麼工具、取得什麼資料、執行哪些命令與會被哪些人安裝；這些都是供應鏈治理的輸入。
讓掃描結果可以被採取行動偵測到問題後，要有修正指引、核准條件與可追溯紀錄；影片也點出指引品質仍是需要持續改善之處。
把本地驗證前移講者提到在送審前先於本地執行與檢查的習慣仍需培養。這可縮短回饋迴路，也避免市集成為第一次接觸風險的地方。
人類核准保留在高風險邊界自動化用於擴大覆蓋率；涉及例外、權限或高影響行為時，仍需明確的 approval gate 與 human confirmation。
Use this checklist
準備開放內部 skills 分享前，先檢查這五件事
有沒有先定義不可接受的操作與權限邊界？將可確定判定的高風險模式做成可測試、可重現的規則。
規則失效時，誰來解讀上下文？以 LLM 補足語意，但保留輸入、理由與可複核的決策紀錄。
掃描結果是否能阻擋上架或收窄使用範圍？若結果不會改變准入或 permissions，掃描只是報表，不是控制。
高風險例外是否有人工確認與所有者？明確設置 approval gate，並將發現串回組織既有的弱點管理流程。
作者是否能在送審前本地驗證？把指引與預檢工具交給作者，降低被拒絕後才理解規則的成本。
Source video