如何证明一项技能？能力证据的 6 级模型

Skills First 将重点从学历、头衔等形式标签转向一个人真正能够展示的能力。但这并不会自动解决如何评价这些能力的问题。

OECD 将 skills-first 描述为一种调整招聘和人才管理实践的方法，使人们根据已经展示的技能受到评价。报告也强调了合适的评估工具和技能框架的重要性。 [1]

因此，仅仅用更长的 "Skills" 部分替代 "Education" 并不够。我们还需要更好地说明 为什么某项技能声明值得信任。

两个人可以写下完全相同的技能，但实际经验可能截然不同。

假设两位专业人士都写着：

Angular - 高级

第一位完成了课程，做过几个个人项目，理解 framework 的基本机制。

第二位连续三年开发 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 级模型本身是本文提出的原创概念模型，并不被表述为上述出版物的研究结果。