skill不就是prompt嗎，為啥面試回答沒深度

怎麼理解 skill？理解到什麼程度才能算更深度？ 包括如果我們面試中被問到，該怎麼回答 才能體現出你對 skill 的理解？ 某種程度上來講， 很多人對於 skill 的理解不夠深入， 本質上是因爲這是一個技術和產品結合的題目 因爲你不理解技術的原理和 skill 的特性， 那產品的問題也回答不好 所以很多 AI 在學的時候， 我們並不需要學代碼， 但是技術的原理一定要去學 那爲什麼會有 skill？ 很多人都會說 skill 不就是 一個豐富版的 prompt 嗎？ 但實際上還真不是 這裏其實要從 prompt 工程的業務的瓶頸來講 最初大家解決 agent 能力的問題， 很容易想到的就是 我要把 prompt 寫得更完整 給模型更全的上下文 對輸出規範更明確 但隨着你任務的複雜度增加 會出現幾個問題 首先，prompt 越來越長， 要確保模型的輸出，就會把所有的規則 知識流程都要塞進去 它就會讓你的上下文越來越冗餘 與當前任務無關的知識也會長期佔用上下文 所以它就會進一步導致模型的注意力被稀釋 模型不知道重點，輸出反而變差 其次還有一個問題就是 你會發現能力是沒有辦法複用的 哪怕你寫了一個很好的 prompt 大量的知識和具體的項目具體的 prompt 偶合在了一起 你換個場景又需要重新寫，非常非常麻煩 所以 Skill 的出現本質上是在解決 怎麼把 Agent 的專業能力一次性的 Prompt 變成模塊化可發現可複用按需加載的能力 這就是基於業務的場景業務的需求來的技術的變化 所以我們經常會說 Skill 有幾個特性 第一個特性叫可觸發 Skill 不是默認全部加載 而是通過 Name 加 Description 來判斷 當前的任務適不適合使用這個 Skill 所以這個描述的本質上承擔了路由的作用 來判斷 Skill 該不該調用以及什麼時候用 那第二個特性叫漸進式加載 這是 Skill 非常非常重要的特質 不是說所有的知識同時進入你模型的上下文 而是模型從發現到激活到執行 到按需加載具體的資源 這是能夠規模化管理大量專業能力的基礎 否則上下文完全靠不住 第三個就是 Skill 包含了工作流加約束加工具 而不只是單純的知識 這是跟 Prompt 巨大的差別 一個 Skill 可以明確要按什麼步驟執行 哪些動作必須先做 哪些動作禁止做，什麼工具可以調用 哪些確定性的動作交給腳本 什麼情況下需要人來判斷 它都會講得清清楚楚 第四個 Skill 是可以被迭代的 所以作爲產品經理，你就順着它的技術特性就可以去判斷 我們對於 Skill 的理解到底要到什麼程度 首先你能判斷什麼東西可以被做成 Skill 不是所有的 problem 都應該 skill 化 你至少要考慮幾個維度 首先 Skill 本質是能力封裝 所以我們首先要判斷這個問題是否會反覆出現 一次性任務是沒有必要 skill 化的 其次也要判斷這件事是否存在一套專門的做事方法 這種專門的方法可能來自四類東西 第一類叫專門的工作流 比如說我們怎麼做 A/B 實驗，這明確的是步驟 第二個叫特定的工具使用方式 你知道應該調用哪些工具 比如說查詢數據庫執行SQL 讀取表格甚至PPT 而不是隻靠模型自己回答 這個明確的是用什麼做 第三個是領域知識和業務的規則 比如說數據分析裏面 我們對於數據口徑的統一 第四個就是固定的資源 比如說我們要做PPT 我必須用公司的模板 公司的模板其實有固定的資源 所以很多通用模型能做的事情 你都是沒有必要思考化的 第三個這個任務是否容易出現 知道怎麼做但執行不穩定 Skill最有價值的場景並不一定是模型不會 而是因爲缺少約束和工作流程導致輸出不穩定 第四個就是是否需要按需加載 如果需要一直放在上下文 那其實就是System Prompt 按需加載纔是Skill 第二個比較重要的點 你要定義Skill的能力邊界 這是涉及Skill的基本功 比如說出發的節點標準的工作流 任務進來之後是讓模型判斷，還是你有明確的規則約束 工具調用都包括 第三個要會做 skill 的系統性評測，你要會迭代它 所以，後續如果你想要去做 AI 產品經理 或者說想要學 AI 相關的產品知識 你可以直接去看我們給 大家準備的這個 AI 產品必須要了解的 PRD 裏面是基於某個大廠的文檔所做的抽象和總結 非常非常詳細