1. 从“skills”这个词说起：它到底指什么“skills”这个词最近又被推到了讨论中心，但很多人第一眼看到它，脑子里浮现的还是简历上那一栏“专业技能”。如果只是这个意思，那没什么好聊的。真正值得拆的是：当一个人说自己在整理自己的 skills、在搭建 skills 体系、在评估别人的 skills 时，他到底在做什么。我先把结论摆出来：skills 不是一张清单，而是一套可被调用、可被验证、可被组合的能力单元。清单是静态的，体系是动态的。你写“会 Python”是清单，你能在两天内用 Python 把一个杂乱的数据表清洗成可分析的结构，这是能力单元。前者是标签，后者是资产。这个区别为什么重要？因为绝大多数人在做自我提升或者团队建设时，卡住的地方不是“不知道要学什么”，而是“学了一堆东西，真到用的时候调不出来”。就像你手机里装了上百个应用，但紧急时刻能三秒内打开的那个，才是你真正会用的。skills 也一样，没有被调用过的 skill，等于不存在。所以这篇内容适合三类人看：第一类是想系统梳理自己能力、但不知道怎么下手的人；第二类是带团队、需要评估和培养成员能力的人；第三类是对“能力”这个概念本身感兴趣、想搞清楚它怎么运作的人。不管你是哪一类，接下来的内容都会围绕一个核心问题展开：怎么把模糊的“我会这个”，变成清晰的、可复用的、能产生结果的能力单元。我做过不少类似的能力梳理项目，也踩过很多坑。最常见的坑就是一开始就追求大而全，列了五十条 skills，结果一条都没法验证。后来我调整了思路，从“能产出什么结果”倒推“需要什么能力”，整个体系才活了起来。下面我把这套思路完整拆开讲。2. 为什么传统的 skills 清单基本没用2.1 清单思维的第一个致命伤：颗粒度失控你去看大多数人的技能列表，颗粒度是混乱的。有人写“沟通能力”，有人写“会用 Excel 的 VLOOKUP 函数”，这两个东西根本不在一个层级上。沟通能力是一个复合能力，VLOOKUP 是一个具体操作。把它们并列放在一张表里，就像把“会做饭”和“会切葱花”放在同一栏，看起来都是技能，实际上一个是目标，一个是手段。颗粒度失控带来的直接后果是：你没法判断自己到底缺什么。你说自己沟通能力不行，那到底是表达不行、倾听不行、还是冲突处理不行？说不清楚，就没法练。而 VLOOKUP 这种具体操作，你练十分钟就会了，它不构成真正的瓶颈。我的做法是强制分层。最上面一层叫领域能力，比如“数据分析”“项目管理”“内容创作”，这一层是方向性的，不需要太精确。中间一层叫任务能力，比如“用 SQL 做多表关联查询”“用甘特图排期”“写一篇产品测评”，这一层是可以直接对应到具体工作产出的。最下面一层叫操作能力，比如“记住 VLOOKUP 的第四个参数是精确匹配还是近似匹配”，这一层是即学即用的，不需要长期规划。三层分开之后，你会发现真正需要花时间打磨的是中间那层。领域能力靠积累，操作能力靠查手册，任务能力才是你每天真正在用的东西。2.2 清单思维的第二个致命伤：没有验证标准“熟练使用 Office”这句话，我见过不下几百次。但什么叫熟练？能做出一个带数据透视表和条件格式的销售报表算不算？能写一个自动抓取网页数据并生成图表的宏算不算？如果标准不统一，这句话就是废话。我后来给自己定了一个规矩：每一条 skill 后面必须跟一个可验证的产出。比如：不是“会数据分析”，而是“能在 30 分钟内用 SQL 从三张表中提取出月度复购率，并解释异常波动的可能原因”不是“会写文案”，而是“能针对同一产品写出三个不同角度的标题，且每个标题都能说出目标人群和触发情绪”不是“会带团队”，而是“能在项目延期时，用一次 15 分钟的站会重新对齐优先级，并让每个成员明确自己接下来 48 小时要做什么”有了验证标准，你才知道自己到底会不会。而且这个标准是你自己定的，不需要别人认可，你自己心里有数。2.3 清单思维的第三个致命伤：忽略能力之间的连接skills 最有价值的地方不是单个能力有多强，而是能力之间的组合方式。你会写代码，也会做设计，这两个单独看都是技能，但组合起来，你就能独立完成一个产品原型。你会做用户访谈，也会做数据分析，组合起来，你就能从定性反馈中提炼出可量化的假设。传统的清单是平铺的，看不出连接。我后来改用能力图谱的方式，把每个任务能力当作一个节点，用线连起来表示“这个能力可以和那个能力组合使用”。比如“写 SQL”和“做图表”连起来，就是“自动化报表”；“做用户访谈”和“写文案”连起来，就是“基于真实反馈的内容创作”。这个图谱不需要画得多漂亮，用一张白纸手画就行。关键是你要看到，你的能力不是孤岛，而是一张网。网越密，你能解决的问题就越复杂。3. 搭建个人 skills 体系的完整实操流程3.1 第一步：从最近三个月的实际产出倒推不要凭空想自己会什么，那样想出来的都是幻觉。打开你的工作记录、聊天记录、邮件、文档，把最近三个月你实际做出来的东西列出来。注意，是产出，不是任务。“参加了十次会议”不是产出，“输出了三份会议纪要并推动了两个决策落地”才是产出。列出来之后，对每一个产出问三个问题：这个产出用到了哪些具体能力？这些能力中，哪些是我已经熟练的，哪些是现学现卖的？如果再做一次，我能在哪些环节做得更快或更好？这三个问题会帮你把隐性的能力显性化。很多人其实会很多东西，但因为没有记录和反思，自己都不知道。我有个习惯，每周五下午花二十分钟写一个简单的周回顾，只写三件事：本周做了什么、用了什么能力、哪里卡住了。坚持了半年之后，我对自己能力的认知清晰了不止一个档次。3.2 第二步：给每个能力打三个维度的分我用的评分维度是：熟练度、调用速度、组合潜力。熟练度不用解释，就是你做这件事的质量。调用速度是指，从“我需要做这件事”到“我开始做并且进入状态”需要多长时间。组合潜力是指，这个能力能不能和其他能力搭配使用，产生更大的价值。每个维度用 1 到 5 分打分。举个例子：能力熟练度调用速度组合潜力写 SQL 查询445做数据可视化334写产品需求文档423主持复盘会议334打完分之后，你会看到一些有意思的模式。比如“写产品需求文档”的调用速度只有 2 分，说明我虽然会写，但每次开始写之前都要磨蹭很久。这就是一个明确的改进点：不是能力不够，而是启动成本太高。解决办法可能是做一个模板，或者把写文档拆成更小的步骤。注意：打分不要追求精确，重要的是相对值。你不需要知道自己的 SQL 到底是 3.7 分还是 3.8 分，你只需要知道它比你的可视化能力强，但调用速度比可视化慢。3.3 第三步：识别你的“杠杆能力”杠杆能力是指那些提升之后能带动其他能力一起提升的能力。比如：信息检索能力：你找资料越快越准，所有依赖输入的能力都会变强结构化表达能力：你能把复杂事情说清楚，所有需要协作的能力都会变强快速原型能力：你能快速做出一个粗糙但可用的东西，所有需要验证的能力都会变强识别杠杆能力的方法是：看你的能力图谱中，哪个节点连出去的线最多。线最多的那个，就是杠杆能力。把最多的时间花在杠杆能力上，回报率最高。我自己的杠杆能力是“结构化表达”。我发现只要我把一件事的框架搭清楚了，写代码、做设计、写文档都会变快。因为我不再需要一边想结构一边想细节，结构定了，细节就是填充。所以我现在会刻意练习“用三句话概括任何一件事”的能力，这个练习反过来提升了我的所有其他技能。3.4 第四步：建立能力更新的触发机制skills 体系不是建完就完了，它需要持续更新。但你不能靠“想起来才更新”，那样基本不会更新。你需要一个触发机制。我的触发机制是：每当我在一个任务上花了比预期多一倍的时间，就停下来问为什么。是因为某个操作能力不熟练？是因为某个任务能力缺失？还是因为领域能力不够导致判断失误？找到原因后，立刻更新到我的能力图谱里。这个机制的好处是，它把“学习”和“实际工作”绑定了。你不是为了学习而学习，你是为了解决一个具体问题而学习。学完之后立刻能用上，用上之后立刻能看到效果，看到效果之后就有动力继续学。这是一个正循环。4. 团队场景下的 skills 评估与培养4.1 为什么不能直接用个人体系套团队个人 skills 体系的核心是“自我驱动”，你对自己负责，所以你可以容忍模糊、容忍试错。但团队场景不一样，团队需要可比较、可沟通、可分配。你不能让每个人用自己的标准打分，那样没法横向对比。我在带团队时用过一套简化版的评估方法，核心是三个问题：这个人在这个能力上，能不能独立完成？能不能在遇到问题时自己找到解决方案？能不能把经验教给别人？这三个问题对应三个等级：执行级、解决级、传授级。执行级是能做但需要指导，解决级是能独立搞定，传授级是能带人。大多数人在大多数能力上处于执行级和解决级之间，传授级是少数。这套方法的好处是，它不追求精确的分数，而是追求清晰的定位。你知道一个人在某个能力上处于什么位置，就知道该怎么用他、怎么培养他。4.2 团队能力矩阵的搭建方法把团队成员列在左边，把团队需要的核心能力列在上面，每个交叉点填上等级。你会得到一张矩阵图。这张图能告诉你很多信息：哪些能力只有一个人会？这是单点风险，需要尽快培养备份哪些能力所有人都处于执行级？这是整体短板，需要集中培训哪些能力有人处于传授级？这是内部讲师资源，可以让他带人我见过一个团队，他们的矩阵图显示“数据分析”这一列只有一个人是解决级，其他都是执行级。后来那个人休假两周，整个团队的数据相关需求全部停摆。这就是单点风险的代价。提示：能力矩阵不需要覆盖所有能力，选 8 到 12 个最核心的就行。太多了没人看，太少了没意义。4.3 培养计划的制定逻辑知道了谁缺什么，接下来就是怎么补。但补不是平均用力，而是按优先级补。优先级怎么定？看两个维度：这个能力的使用频率和缺失带来的影响。使用频率高、缺失影响大的，优先补。使用频率低、缺失影响小的，可以暂时放一放。使用频率高但缺失影响小的，可以边做边学。使用频率低但缺失影响大的，可以找外部资源临时解决。我通常会做一个四象限图，把能力分到四个象限里，然后针对每个象限制定不同的策略。这个图不需要多精确，关键是让团队看到：我们不是什么都缺，我们只是有几个关键缺口需要优先解决。这样大家的焦虑感会降低，行动力会提升。5. 常见问题与排查技巧实录5.1 问题一：列了很多能力，但不知道从哪个开始练这是最常见的问题。我的建议是：不要从“哪个最重要”开始，而是从“哪个最容易看到效果”开始。先找一个你稍微练一下就能明显变好的能力，把它练到解决级。这个过程会给你信心，也会让你更清楚怎么练下一个。比如你觉得自己的“会议记录”能力不行，那就先练这个。找一个模板，下次开会时强迫自己用模板记录，会后花五分钟整理成三条结论。练三次之后，你会发现自己的会议记录质量明显提升。这个提升会带动你的“信息整理”和“结构化表达”能力，一举多得。5.2 问题二：练了一段时间，感觉没有进步这通常是因为没有反馈。你练了，但不知道练得好不好，所以感觉没进步。解决办法是给自己建立反馈机制。最简单的反馈机制是：找一个参照物。比如你想提升“写 SQL”的能力，那就找一些经典的 SQL 题目，做完之后看别人的解法。如果你的解法和别人的解法差距很大，说明还有提升空间。如果你的解法和别人的解法差不多，甚至更好，说明你已经不错了。参照物不一定是人，也可以是标准答案、优秀案例、行业模板。5.3 问题三：能力太多，维护不过来这说明你的能力体系太复杂了。能力体系不是越全越好，而是越精越好。我建议把核心能力控制在 10 个以内，其他能力作为附属。核心能力是你每天都要用的，附属能力是偶尔用到的。核心能力需要持续维护，附属能力只需要知道“我会，需要的时候能捡起来”就行。我自己的核心能力只有 6 个：信息检索、结构化表达、快速原型、数据分析、项目管理、写作。这 6 个能力覆盖了我 90% 的工作场景。其他能力比如“做 PPT”“剪视频”“画流程图”，都是附属能力，需要的时候现学现用，不纳入日常维护。5.4 问题四：团队里有人不愿意暴露自己的短板这是团队场景下的典型问题。解决办法是先暴露自己的短板。作为带团队的人，你先在能力矩阵里把自己的短板标出来，然后公开你的提升计划。大家看到你也在学、也在补，就会觉得暴露短板不是丢人的事，而是正常的事。另外，不要把能力矩阵和绩效考核挂钩。一旦挂钩，大家就会倾向于高估自己，矩阵就失真了。能力矩阵的目的是发展，不是评判。这个定位一定要在开始的时候就讲清楚。5.5 常见问题速查表问题可能原因排查方向解决建议列了很多能力但不知道练哪个没有优先级标准看使用频率和缺失影响从最容易看到效果的开始练了没进步缺少反馈找参照物对比建立定期反馈机制能力太多维护不过来体系太复杂区分核心和附属核心控制在10个以内团队不愿暴露短板缺乏安全感检查是否与考核挂钩先暴露自己的短板能力图谱画不出来颗粒度太细或太粗检查分层是否清晰强制分三层：领域、任务、操作6. 我踩过的坑和后来想明白的事最早做能力梳理的时候，我犯过一个很典型的错误：把“学习计划”当成了“能力体系”。我列了一堆要学的东西，Python、SQL、统计学、机器学习，然后排了一个时间表，每天学什么。结果坚持了两周就崩了，因为工作和学习冲突，一旦加班就学不了，一断掉就再也捡不起来。后来我想明白了：能力体系不是学习计划，能力体系是调用地图。学习计划是“我要学什么”，调用地图是“我现在会什么、缺什么、需要的时候去哪里找”。这两个东西的用途完全不同。学习计划适合有整块时间的人，调用地图适合边做边学的人。我现在用的就是调用地图。我不追求“学会”某个东西，我追求“知道这个东西能解决什么问题，以及需要的时候怎么快速找到解决方案”。比如我不会深度学习，但我知道深度学习能解决图像分类问题，需要的时候我知道去哪里找预训练模型、怎么调参、怎么评估效果。这就够了。另一个坑是过度追求量化。我曾经试图给每个能力打精确的分数，还做了加权计算，搞了一个总分出来。后来发现这个总分毫无意义，因为不同能力之间根本不可比。你没法说“SQL 4 分”和“写作 4 分”哪个更值钱。量化是为了比较，但能力之间本来就不该比较。现在我只用等级，不用分数，反而更清晰。还有一个坑是忽略身体状态对能力的影响。skills 不只是脑子的事，也是身体的事。你睡眠不足的时候，调用速度会下降，组合潜力也会下降。我以前经常熬夜写代码，第二天看自己写的代码，简直想删掉重写。后来我强制自己每天睡够七小时，同样的代码，白天两小时写完，晚上可能要四小时。身体状态是能力体系的底层基础设施，这个基础设施不稳，上面搭什么都是白搭。最后说一个我最近才想明白的事：skills 的终极形态不是“我会什么”，而是“我能让别人也会什么”。你一个人会十项技能，不如你让十个人各会一项技能然后协作。前者是个人能力，后者是组织能力。个人能力有上限，组织能力没有。所以我现在花在“教别人”上的时间，比花在“自己学”上的时间还多。教的过程也是学的过程，而且学得更深。这个内容后续还可以这样扩展：如果你对团队能力矩阵感兴趣，可以进一步研究“能力与岗位的匹配模型”；如果你对个人能力图谱感兴趣，可以尝试用一些可视化工具把它画出来，每隔三个月更新一次，看看自己的网是变密了还是变疏了。我自己是每季度更新一次，每次更新都会发现一些之前没注意到的连接。
1. 从“skills”这个词说起：它到底指什么“skills”这个词最近又被推到了讨论中心，但很多人第一眼看到它，脑子里浮现的还是简历上那一栏“专业技能”。如果只是这个意思，那没什么好聊的。真正值得拆的是：当一个人说自己在整理自己的 skills、在搭建 skills 体系、在评估别人的 skills 时，他到底在做什么。我先把结论摆出来：skills 不是一张清单，而是一套可被调用、可被验证、可被组合的能力单元。清单是静态的，体系是动态的。你写“会 Python”是清单，你能在两天内用 Python 把一个杂乱的数据表清洗成可分析的结构，这是能力单元。前者是标签，后者是资产。这个区别为什么重要？因为绝大多数人在做自我提升或者团队建设时，卡住的地方不是“不知道要学什么”，而是“学了一堆东西，真到用的时候调不出来”。就像你手机里装了上百个应用，但紧急时刻能三秒内打开的那个，才是你真正会用的。skills 也一样，没有被调用过的 skill，等于不存在。所以这篇内容适合三类人看：第一类是想系统梳理自己能力、但不知道怎么下手的人；第二类是带团队、需要评估和培养成员能力的人；第三类是对“能力”这个概念本身感兴趣、想搞清楚它怎么运作的人。不管你是哪一类，接下来的内容都会围绕一个核心问题展开：怎么把模糊的“我会这个”，变成清晰的、可复用的、能产生结果的能力单元。我做过不少类似的能力梳理项目，也踩过很多坑。最常见的坑就是一开始就追求大而全，列了五十条 skills，结果一条都没法验证。后来我调整了思路，从“能产出什么结果”倒推“需要什么能力”，整个体系才活了起来。下面我把这套思路完整拆开讲。2. 为什么传统的 skills 清单基本没用2.1 清单思维的第一个致命伤：颗粒度失控你去看大多数人的技能列表，颗粒度是混乱的。有人写“沟通能力”，有人写“会用 Excel 的 VLOOKUP 函数”，这两个东西根本不在一个层级上。沟通能力是一个复合能力，VLOOKUP 是一个具体操作。把它们并列放在一张表里，就像把“会做饭”和“会切葱花”放在同一栏，看起来都是技能，实际上一个是目标，一个是手段。颗粒度失控带来的直接后果是：你没法判断自己到底缺什么。你说自己沟通能力不行，那到底是表达不行、倾听不行、还是冲突处理不行？说不清楚，就没法练。而 VLOOKUP 这种具体操作，你练十分钟就会了，它不构成真正的瓶颈。我的做法是强制分层。最上面一层叫领域能力，比如“数据分析”“项目管理”“内容创作”，这一层是方向性的，不需要太精确。中间一层叫任务能力，比如“用 SQL 做多表关联查询”“用甘特图排期”“写一篇产品测评”，这一层是可以直接对应到具体工作产出的。最下面一层叫操作能力，比如“记住 VLOOKUP 的第四个参数是精确匹配还是近似匹配”，这一层是即学即用的，不需要长期规划。三层分开之后，你会发现真正需要花时间打磨的是中间那层。领域能力靠积累，操作能力靠查手册，任务能力才是你每天真正在用的东西。2.2 清单思维的第二个致命伤：没有验证标准“熟练使用 Office”这句话，我见过不下几百次。但什么叫熟练？能做出一个带数据透视表和条件格式的销售报表算不算？能写一个自动抓取网页数据并生成图表的宏算不算？如果标准不统一，这句话就是废话。我后来给自己定了一个规矩：每一条 skill 后面必须跟一个可验证的产出。比如：不是“会数据分析”，而是“能在 30 分钟内用 SQL 从三张表中提取出月度复购率，并解释异常波动的可能原因”不是“会写文案”，而是“能针对同一产品写出三个不同角度的标题，且每个标题都能说出目标人群和触发情绪”不是“会带团队”，而是“能在项目延期时，用一次 15 分钟的站会重新对齐优先级，并让每个成员明确自己接下来 48 小时要做什么”有了验证标准，你才知道自己到底会不会。而且这个标准是你自己定的，不需要别人认可，你自己心里有数。2.3 清单思维的第三个致命伤：忽略能力之间的连接skills 最有价值的地方不是单个能力有多强，而是能力之间的组合方式。你会写代码，也会做设计，这两个单独看都是技能，但组合起来，你就能独立完成一个产品原型。你会做用户访谈，也会做数据分析，组合起来，你就能从定性反馈中提炼出可量化的假设。传统的清单是平铺的，看不出连接。我后来改用能力图谱的方式，把每个任务能力当作一个节点，用线连起来表示“这个能力可以和那个能力组合使用”。比如“写 SQL”和“做图表”连起来，就是“自动化报表”；“做用户访谈”和“写文案”连起来，就是“基于真实反馈的内容创作”。这个图谱不需要画得多漂亮，用一张白纸手画就行。关键是你要看到，你的能力不是孤岛，而是一张网。网越密，你能解决的问题就越复杂。3. 搭建个人 skills 体系的完整实操流程3.1 第一步：从最近三个月的实际产出倒推不要凭空想自己会什么，那样想出来的都是幻觉。打开你的工作记录、聊天记录、邮件、文档，把最近三个月你实际做出来的东西列出来。注意，是产出，不是任务。“参加了十次会议”不是产出，“输出了三份会议纪要并推动了两个决策落地”才是产出。列出来之后，对每一个产出问三个问题：这个产出用到了哪些具体能力？这些能力中，哪些是我已经熟练的，哪些是现学现卖的？如果再做一次，我能在哪些环节做得更快或更好？这三个问题会帮你把隐性的能力显性化。很多人其实会很多东西，但因为没有记录和反思，自己都不知道。我有个习惯，每周五下午花二十分钟写一个简单的周回顾，只写三件事：本周做了什么、用了什么能力、哪里卡住了。坚持了半年之后，我对自己能力的认知清晰了不止一个档次。3.2 第二步：给每个能力打三个维度的分我用的评分维度是：熟练度、调用速度、组合潜力。熟练度不用解释，就是你做这件事的质量。调用速度是指，从“我需要做这件事”到“我开始做并且进入状态”需要多长时间。组合潜力是指，这个能力能不能和其他能力搭配使用，产生更大的价值。每个维度用 1 到 5 分打分。举个例子：能力熟练度调用速度组合潜力写 SQL 查询445做数据可视化334写产品需求文档423主持复盘会议334打完分之后，你会看到一些有意思的模式。比如“写产品需求文档”的调用速度只有 2 分，说明我虽然会写，但每次开始写之前都要磨蹭很久。这就是一个明确的改进点：不是能力不够，而是启动成本太高。解决办法可能是做一个模板，或者把写文档拆成更小的步骤。注意：打分不要追求精确，重要的是相对值。你不需要知道自己的 SQL 到底是 3.7 分还是 3.8 分，你只需要知道它比你的可视化能力强，但调用速度比可视化慢。3.3 第三步：识别你的“杠杆能力”杠杆能力是指那些提升之后能带动其他能力一起提升的能力。比如：信息检索能力：你找资料越快越准，所有依赖输入的能力都会变强结构化表达能力：你能把复杂事情说清楚，所有需要协作的能力都会变强快速原型能力：你能快速做出一个粗糙但可用的东西，所有需要验证的能力都会变强识别杠杆能力的方法是：看你的能力图谱中，哪个节点连出去的线最多。线最多的那个，就是杠杆能力。把最多的时间花在杠杆能力上，回报率最高。我自己的杠杆能力是“结构化表达”。我发现只要我把一件事的框架搭清楚了，写代码、做设计、写文档都会变快。因为我不再需要一边想结构一边想细节，结构定了，细节就是填充。所以我现在会刻意练习“用三句话概括任何一件事”的能力，这个练习反过来提升了我的所有其他技能。3.4 第四步：建立能力更新的触发机制skills 体系不是建完就完了，它需要持续更新。但你不能靠“想起来才更新”，那样基本不会更新。你需要一个触发机制。我的触发机制是：每当我在一个任务上花了比预期多一倍的时间，就停下来问为什么。是因为某个操作能力不熟练？是因为某个任务能力缺失？还是因为领域能力不够导致判断失误？找到原因后，立刻更新到我的能力图谱里。这个机制的好处是，它把“学习”和“实际工作”绑定了。你不是为了学习而学习，你是为了解决一个具体问题而学习。学完之后立刻能用上，用上之后立刻能看到效果，看到效果之后就有动力继续学。这是一个正循环。4. 团队场景下的 skills 评估与培养4.1 为什么不能直接用个人体系套团队个人 skills 体系的核心是“自我驱动”，你对自己负责，所以你可以容忍模糊、容忍试错。但团队场景不一样，团队需要可比较、可沟通、可分配。你不能让每个人用自己的标准打分，那样没法横向对比。我在带团队时用过一套简化版的评估方法，核心是三个问题：这个人在这个能力上，能不能独立完成？能不能在遇到问题时自己找到解决方案？能不能把经验教给别人？这三个问题对应三个等级：执行级、解决级、传授级。执行级是能做但需要指导，解决级是能独立搞定，传授级是能带人。大多数人在大多数能力上处于执行级和解决级之间，传授级是少数。这套方法的好处是，它不追求精确的分数，而是追求清晰的定位。你知道一个人在某个能力上处于什么位置，就知道该怎么用他、怎么培养他。4.2 团队能力矩阵的搭建方法把团队成员列在左边，把团队需要的核心能力列在上面，每个交叉点填上等级。你会得到一张矩阵图。这张图能告诉你很多信息：哪些能力只有一个人会？这是单点风险，需要尽快培养备份哪些能力所有人都处于执行级？这是整体短板，需要集中培训哪些能力有人处于传授级？这是内部讲师资源，可以让他带人我见过一个团队，他们的矩阵图显示“数据分析”这一列只有一个人是解决级，其他都是执行级。后来那个人休假两周，整个团队的数据相关需求全部停摆。这就是单点风险的代价。提示：能力矩阵不需要覆盖所有能力，选 8 到 12 个最核心的就行。太多了没人看，太少了没意义。4.3 培养计划的制定逻辑知道了谁缺什么，接下来就是怎么补。但补不是平均用力，而是按优先级补。优先级怎么定？看两个维度：这个能力的使用频率和缺失带来的影响。使用频率高、缺失影响大的，优先补。使用频率低、缺失影响小的，可以暂时放一放。使用频率高但缺失影响小的，可以边做边学。使用频率低但缺失影响大的，可以找外部资源临时解决。我通常会做一个四象限图，把能力分到四个象限里，然后针对每个象限制定不同的策略。这个图不需要多精确，关键是让团队看到：我们不是什么都缺，我们只是有几个关键缺口需要优先解决。这样大家的焦虑感会降低，行动力会提升。5. 常见问题与排查技巧实录5.1 问题一：列了很多能力，但不知道从哪个开始练这是最常见的问题。我的建议是：不要从“哪个最重要”开始，而是从“哪个最容易看到效果”开始。先找一个你稍微练一下就能明显变好的能力，把它练到解决级。这个过程会给你信心，也会让你更清楚怎么练下一个。比如你觉得自己的“会议记录”能力不行，那就先练这个。找一个模板，下次开会时强迫自己用模板记录，会后花五分钟整理成三条结论。练三次之后，你会发现自己的会议记录质量明显提升。这个提升会带动你的“信息整理”和“结构化表达”能力，一举多得。5.2 问题二：练了一段时间，感觉没有进步这通常是因为没有反馈。你练了，但不知道练得好不好，所以感觉没进步。解决办法是给自己建立反馈机制。最简单的反馈机制是：找一个参照物。比如你想提升“写 SQL”的能力，那就找一些经典的 SQL 题目，做完之后看别人的解法。如果你的解法和别人的解法差距很大，说明还有提升空间。如果你的解法和别人的解法差不多，甚至更好，说明你已经不错了。参照物不一定是人，也可以是标准答案、优秀案例、行业模板。5.3 问题三：能力太多，维护不过来这说明你的能力体系太复杂了。能力体系不是越全越好，而是越精越好。我建议把核心能力控制在 10 个以内，其他能力作为附属。核心能力是你每天都要用的，附属能力是偶尔用到的。核心能力需要持续维护，附属能力只需要知道“我会，需要的时候能捡起来”就行。我自己的核心能力只有 6 个：信息检索、结构化表达、快速原型、数据分析、项目管理、写作。这 6 个能力覆盖了我 90% 的工作场景。其他能力比如“做 PPT”“剪视频”“画流程图”，都是附属能力，需要的时候现学现用，不纳入日常维护。5.4 问题四：团队里有人不愿意暴露自己的短板这是团队场景下的典型问题。解决办法是先暴露自己的短板。作为带团队的人，你先在能力矩阵里把自己的短板标出来，然后公开你的提升计划。大家看到你也在学、也在补，就会觉得暴露短板不是丢人的事，而是正常的事。另外，不要把能力矩阵和绩效考核挂钩。一旦挂钩，大家就会倾向于高估自己，矩阵就失真了。能力矩阵的目的是发展，不是评判。这个定位一定要在开始的时候就讲清楚。5.5 常见问题速查表问题可能原因排查方向解决建议列了很多能力但不知道练哪个没有优先级标准看使用频率和缺失影响从最容易看到效果的开始练了没进步缺少反馈找参照物对比建立定期反馈机制能力太多维护不过来体系太复杂区分核心和附属核心控制在10个以内团队不愿暴露短板缺乏安全感检查是否与考核挂钩先暴露自己的短板能力图谱画不出来颗粒度太细或太粗检查分层是否清晰强制分三层：领域、任务、操作6. 我踩过的坑和后来想明白的事最早做能力梳理的时候，我犯过一个很典型的错误：把“学习计划”当成了“能力体系”。我列了一堆要学的东西，Python、SQL、统计学、机器学习，然后排了一个时间表，每天学什么。结果坚持了两周就崩了，因为工作和学习冲突，一旦加班就学不了，一断掉就再也捡不起来。后来我想明白了：能力体系不是学习计划，能力体系是调用地图。学习计划是“我要学什么”，调用地图是“我现在会什么、缺什么、需要的时候去哪里找”。这两个东西的用途完全不同。学习计划适合有整块时间的人，调用地图适合边做边学的人。我现在用的就是调用地图。我不追求“学会”某个东西，我追求“知道这个东西能解决什么问题，以及需要的时候怎么快速找到解决方案”。比如我不会深度学习，但我知道深度学习能解决图像分类问题，需要的时候我知道去哪里找预训练模型、怎么调参、怎么评估效果。这就够了。另一个坑是过度追求量化。我曾经试图给每个能力打精确的分数，还做了加权计算，搞了一个总分出来。后来发现这个总分毫无意义，因为不同能力之间根本不可比。你没法说“SQL 4 分”和“写作 4 分”哪个更值钱。量化是为了比较，但能力之间本来就不该比较。现在我只用等级，不用分数，反而更清晰。还有一个坑是忽略身体状态对能力的影响。skills 不只是脑子的事，也是身体的事。你睡眠不足的时候，调用速度会下降，组合潜力也会下降。我以前经常熬夜写代码，第二天看自己写的代码，简直想删掉重写。后来我强制自己每天睡够七小时，同样的代码，白天两小时写完，晚上可能要四小时。身体状态是能力体系的底层基础设施，这个基础设施不稳，上面搭什么都是白搭。最后说一个我最近才想明白的事：skills 的终极形态不是“我会什么”，而是“我能让别人也会什么”。你一个人会十项技能，不如你让十个人各会一项技能然后协作。前者是个人能力，后者是组织能力。个人能力有上限，组织能力没有。所以我现在花在“教别人”上的时间，比花在“自己学”上的时间还多。教的过程也是学的过程，而且学得更深。这个内容后续还可以这样扩展：如果你对团队能力矩阵感兴趣，可以进一步研究“能力与岗位的匹配模型”；如果你对个人能力图谱感兴趣，可以尝试用一些可视化工具把它画出来，每隔三个月更新一次，看看自己的网是变密了还是变疏了。我自己是每季度更新一次，每次更新都会发现一些之前没注意到的连接。