如何證明一項技能？能力證據的 6 級模型

Skills First 將焦點從學歷、職稱等形式標籤，轉向一個人真正能展示的能力。但這並不會自動解決如何評估這些能力的問題。

OECD 將 skills-first 描述為一種調整招募與人才管理實務的方法，讓人們依據已展現的技能受到評估。報告也強調適當 assessment tools 與 skill frameworks 的重要性。 [1]

因此，只用更長的 "Skills" 區塊取代 "Education" 還不夠。我們也需要更好地說明 為什麼某項技能聲明值得信任。

兩個人可以寫下完全相同的技能，但實際經驗可能非常不同。

假設兩位專業人士都寫著：

Angular - 進階

第一位完成課程、做過幾個個人專案，理解 framework 基本機制。

第二位連續3年開發 production application，負責系統部分 architecture，執行過 Angular versions 之間的 migration，而且能指出具體成果。

在一般技能清單中，兩個人可能看起來非常相似。

只有 放在脈絡中的證據 才開始顯示真正的差異。

這個模型不是為了給每個人一個統一分數。不同職業會產生不同類型的證據，也不是每個專案都能公開。

它要回答的是更簡單的問題：

支撐某項能力可信呈現的材料究竟有多強？

最簡單的層級是使用者自己的聲明。

例如：

• Angular
• Figma
• SEO
• 團隊領導
• B2B 談判

這些資訊對搜尋與 discovery 有幫助，但證據強度有限。

我們仍不知道：

• 在哪裡使用過,
• 使用多久,
• 在什麼規模下使用,
• 承擔什麼責任,
• 產生什麼結果

聲明是評估起點，不是終點。

當我們知道技能 在哪裡、在什麼脈絡中使用，證據會更強。

不只是：

Angular

而是：

在物流產業 SaaS application 開發中使用 Angular 2 年。

這還不能證明工作品質，但增加了重要脈絡：

• 真實專案,
• 使用時間,
• 應用領域,
• 工作環境性質

到了這個層級，技能不再只是標籤。

下一層級是能把聲明與經驗連結到 真實的工作成果物。

依職業不同，可以是：

• 可運作 application,
• code sample,
• repository,
• interface design,
• prototype,
• report,
• analysis,
• campaign,
• article,
• documentation,
• financial model,
• photograph,
• engineering design,
• 已完成工作的紀錄

成果物回答一個重要問題：

我們能否看到真正使用這項技能創造出來的東西？

這不代表 portfolio 就是正式能力測驗。不過人員甄選研究指出，work samples、職務知識測驗等貼近真實工作的方式，可以成為有用的績效預測指標。同時，結果應結合具體脈絡、成本和方法限制解讀。 [2]

即使有成果物，也可能還有一個重要問題沒有答案：

這個人具體做了什麼？

這在團隊專案中特別重要。

一個 application 可能由20人開發，一次 campaign 可能由8人團隊執行，一次 rebranding 也可能同時有 agency、內部 marketing 團隊與外部 consultant。

因此，更強的證據是 明確個人貢獻的 case study。

好的 case study 至少應該區分：

• 問題或目標,
• 整體專案範圍,
• 專業人士個人責任,
• 實際執行的工作,
• 使用的能力,
• 與他人的協作,
• 結果

與其寫：

我建立了 e-commerce platform。

不如寫：

我負責 frontend architecture、checkout implementation 與 payment-flow integration。專案由5人團隊完成。

後者更有價值，因為沒有把整個團隊的工作歸給一個人。

當工作帶來 具體結果，而且能清楚描述時，證據會更強。

例如：

Frontend
將主要頁面載入時間從4.2秒縮短到1.8秒。

UX
重新設計註冊流程後，降低表單放棄率。

Marketing
在維持相近 traffic quality 的情況下降低 cost per lead。

Sales
開發新的 customer segment，並完成一定數量的合約。

Operations
將數天的流程縮短到數小時。

並不是所有職業都應該用百分比或金額表示結果，也不應為了讓資料更好看而虛構 metric。

真正有用的問題是：

這項工作讓什麼發生了改變？

最強的層級是至少有一部分資訊可以 獨立於資料擁有者自己的聲明進行驗證。

例如：

• 公開專案,
• 有 contribution history 的 repository,
• 公開 publication,
• 已確認的專案參與,
• 可以合法公開的客戶或同事 reference,
• 可獨立確認的結果,
• 真正相關時的 official credential,
• 可以確認特定工作的其他來源

這不代表所有專案都必須公開。

許多重要專案受到 NDA、營業秘密或其他保密義務保護。

因此，缺少公開證據 不代表缺少能力。

它只代表獨立驗證程度較低。

第 1 級 - 聲明
Angular。

第 2 級 - 脈絡
在 SaaS applications 中使用 Angular 3 年。

第 3 級 - 成果物
公開 application、repository 或其他可展示的 work sample。

第 4 級 - 個人貢獻
負責部分 module architecture、shared components 與 application migration。

第 5 級 - 結果
透過 optimization 將 main module startup time 從4.2秒降低到1.8秒。數字僅為示例。

第 6 級 - 驗證
可以透過公開 project、change history、reference 或其他獨立來源進一步確認結果與貢獻。

處在同一級別的兩份證據，價值可能完全不同。以下五個面向有助於判斷品質。

1. 相關性 - 證據真的與正在評估的能力有關嗎？

2. 時效性 - 技能何時使用，在這個領域近期經驗有多重要？

3. 個人貢獻與責任 - 我們知道這個人真正做了什麼嗎？

4. 脈絡 - 專案規模、複雜度、責任、資源和工作條件如何？

5. 可驗證性 - 是否有獨立方式確認至少一部分資訊？

相關性

如果某項技術在專案中只被邊緣使用，這份證據弱於該能力是核心工作內容的專案。

時效性

重要程度因領域而異。有些領域十年前的經驗仍非常有價值，有些領域工具和實務變化很快。

個人貢獻與責任

專案和團隊越大，越需要把整體結果與個人貢獻分開。

脈絡

同樣的結果可能因專案規模、時間限制、資源、責任和問題複雜度而具有不同意義。

可驗證性

獨立驗證並非總是可能，也不應在所有情況下強制要求。但獨立來源能確認結果或貢獻時，會提升可信度。

一個人可能很好地完成自己的部分，但專案最終在商業上失敗。

也可能參與非常成功的專案，但對最終成功的影響很小。

因此需要區分三件事：

1. 能力
這個人能否完成這種類型的工作？

2. 貢獻
他真正負責哪部分？

3. 結果
這項工作帶來什麼改變？

把三者一起看，才能得到更完整的判斷。

Certificate 或其他 formal credential 可以是有價值的證據，但價值取決於 它真正證明了什麼，以及如何取得。

例如可能證明：

• 完成 training,
• 達到特定 learning outcomes,
• 通過某種 assessment,
• 了解某項 standard,
• 滿足正式要求

European Commission 將 micro-credentials 描述為透過短期學習經驗獲得的 learning outcomes 紀錄，歐洲方法強調 transparency 與 quality。 [3]

不應自動把 certificate 等同於一個人在真實職業環境中可以獨立完成複雜工作的證明。

因此 credential 是 可能的證據元素之一，其意義取決於脈絡。

無法公開專案不應抹去有價值的經驗。

但 NDA、保密義務、營業秘密、著作權與資料保護規則優先於展示 portfolio 的需求。

專業人士只能在合約、適用法律以及其他個人與組織的權利允許範圍內描述專案。只移除客戶名稱並不一定足夠，因為其他細節仍可能識別專案、客戶、技術、結果或保密方法。

在允許揭露的情況下，可以考慮以足夠概括的方式描述：

• 產業,
• 不含機密資訊的問題性質,
• 自己的角色和責任,
• 使用的能力,
• 在允許範圍內的規模,
• 不公開受保護資料的結果類型,
• 適度概括的方法

如果不確定某項資訊是否能公開，更安全的做法是在檢查合約或取得權利人許可前不要揭露。

能力證據系統不應假設所有職業都是 software development。

Designer 可以展示 process、design decisions、prototype 與結果。

Developer 可以展示 product、code、architecture 或 technical responsibility。

Marketer 可以展示 campaign、approach、responsibility 與結果變化。

Sales professional 可以在不公開客戶機密資料的情況下描述 market segment、sales process、個人角色與結果。

Project Manager 可以展示 project scope、工作組織、constraints 與對 delivery 的影響。

Photographer 可以展示完成作品，不需要虛構 KPI。

原則可以統一，但證據類型應保持彈性。

1. 檢查這項能力實際在哪裡使用過。

2. 尋找工作成果物或具體執行案例。

3. 把個人貢獻與整個團隊的工作區分開。

4. 在可以有意義描述的情況下查看結果。

5. 評估經驗的時效性，以及與目前問題的相似程度。

6. 在可能且合適的情況下尋找獨立確認。

這樣，評估就從資料中的關鍵字轉向 已展現的能力與具體需求之間的真實匹配。

這個模型用於整理資訊並支援人的判斷，不應被當作自動決定是否錄用、拒絕候選人或開始專業合作的結論。

並不是每項能力都需要第 6 級證據。

更有用的是回顧關鍵技能，逐項問自己：

• 我在哪裡用過這項技能？
• 當時解決什麼問題？
• 我具體做了什麼？
• 是否有工作成果物？
• 結果是什麼？
• 能否在不違反保密義務的情況下說明？
• 是否有人或來源可以確認我的貢獻？

僅僅從：

Figma - 進階

改成：

我設計了 B2B application 的 onboarding flow，並負責 research、prototyping、usability testing 與 final design system

就能明顯提升資料中的資訊品質。

只有當 "skill" 不只是一個 tag 時，Skills First 才真正有意義。

如果能力要成為發現與比較專業人士的重要方式，就應該與盡可能完整的脈絡連結：

experience -> portfolio -> individual contribution -> outcome -> verifiability.

不是每項能力都必須達到最高級別。

目標不是替資料中的每個項目增加強制流程。

目標是讓專業人士說明 為什麼自己的技能聲明值得信任，並幫助尋找專業能力的人做出資訊更充分的判斷。

1. 用具體資訊取代單純聲明 - 說明能力在哪裡、如何使用。

2. 用個人貢獻取代整個團隊的成功 - 把自己的工作與組織整體結果分開。

3. 用結果取代職責清單 - 可能的話，說明工作帶來什麼改變。

4. 用脈絡取代孤立數字 - 沒有條件的 metric 容易導致錯誤結論。

5. 能驗證時盡量驗證 - 獨立確認會提高可信度，但缺少獨立確認不代表能力無效。

專業個人資料不應讓讀者猜測技能清單背後到底有什麼。

聲明幫助一項能力被發現。證據幫助這項能力被理解。

6 個級別可以概括成一條簡單路徑：

1. 我說我會。
2. 我說明在哪裡使用過。
3. 我展示做出了什麼。
4. 我解釋具體做了什麼。
5. 我展示結果。
6. 在可能的情況下提供獨立確認。

能回答的問題越多，我們就越不需要只依賴一項聲明。

這時 Skills First 才不只是重新排列資料中的資訊。

[1] OECD - A Skills-First Labour Market: Promoting skills-first hiring and talent management, 2026
開啟來源

[2] Sackett, Zhang, Berry, Lievens - Revisiting the design of selection systems in light of new findings regarding the validity of widely used predictors, Cambridge University Press, 2023
開啟來源

[3] European Commission - A European approach to micro-credentials
開啟來源

方法說明: 來源 [1]-[3] 為 Skills First、能力評估與 credential 提供更廣泛的背景。能力證據的 6 級模型本身是本文提出的原創概念模型，並不被表述為上述出版物的研究結果。