技术人才专项盘点 — SKILL.md
§0 TRACE 自检
| 维度 | 评估 | 证据 |
|---|---|---|
| Trust（可信赖） | ✅ 通过 | 所有评估维度给出具体行为锚定和反面信号，不做笼统描述；每个工具有明确的"何时适用/何时不适用"的约束标注 |
| Reliability（可靠） | ✅ 通过 | 独立可用——用户拿到即可在技术团队中落地双轨盘点。路径完整：轨道定位→四维评估→九宫格落位→发展路径→校准会话术。无外部依赖 |
| Adaptability（可适配） | ✅ 通过 | 分段设计——用户可根据团队规模使用完整版或仅取"双轨定位+四维评估"两模块；混合型人才处理（两条轨都适合）给出专门规则而非视为异常 |
| Convention（规范） | ✅ 通过 | 符合SkillHub人才发展模块三文件交付规范；§0-§I固定结构一致 |
| Effectiveness（有效） | ✅ 通过 | 每个模块在实战中有明确产出：轨道=清晰标签、四维=可沟通评分表、九宫格=可视化结果、校准语=不用用技术术语跟非技术Leader沟通的价值 |
§Q 能力边界
本 Skill 会做：
- 帮助技术管理者和技术团队HRBP对技术人才进行双轨（架构轨×业务轨）定位
- 提供技术深度 / 技术影响力 / 工程素养 / 技术领导力四维专属评估框架和评分表
- 根据四维评估结果将技术人才映射到双轨九宫格上，形成可视化定位
- 输出角色画像（架构师 / 基础架构 / Tech Lead / 技术PM / 创业型工程师等）和最优格位警示灯
- 提供校准会话术——让非技术背景的校准会参与者（HRBP / 非技术Leader）能用最小词汇集理解技术人才价值
- 输出发展路径卡——基于九宫格位置和轨道，给出下一步发展建议
本 Skill 不会做：
- 不替代已有的公司级人才盘点体系和流程
- 不提供薪酬方案或晋升决策——本工具提供的是评估语言和定位框架，最终人事决策仍需管理者自行做出
- 不适用于非技术岗位的评估
- 不适用于少于5人的技术团队（讨论精度足够时不需要形式化工具）
§1 核心知识库
1.1 为什么技术人才需要专用九宫格
通用人才盘点九宫格的核心逻辑是：绩效（过去×现在）×潜力（未来）=九宫格位置。其中潜力维度的经典四维（学习敏锐度/思维复杂度/人际敏捷度/驱动能量）对技术人才有结构性盲区。
盲区1：技术影响力不在评估维度中。 一个写了公司核心框架的人的影响力和一个跟着Leader走的能力强的人是同等的"绩效×潜力"——但前者有无法被替代的技术资产。
盲区2：管理晋升不是所有技术人才的默认路径。 把优秀架构师推上管理岗是一种常见错误。九宫格给出"3C=应该承担更多管理责任"——但对架构轨的人，"更多管理"是一种损耗。
盲区3：技术人才的"下一步"结构不同于非技术岗位。 同样的3C——一个业务轨的人下一步是管理更大的团队+更深的业务理解；但一个架构轨的人下一步可能是主导更复杂的系统/更大的技术范围/更前沿的技术方向——两种路径需要的支持完全不同。
1.2 双轨定义与边界
| 特征 | 架构轨 | 业务轨 |
|---|---|---|
| 核心产出 | 架构文档、技术标准、基础设施、技术方向共识 | 产品功能、业务指标、交付速度、技术对业务价值的转化率 |
| 技术关注点 | 怎么写得好、怎么长期可持续、怎么避免技术债务 | 做什么对、做什么是当前最有价值的事、怎么用技术加速业务迭代 |
| 典型决策 | 系统设计选型、接口规范、技术栈方向、重构时机 | 需求优先级排序、功能范围界定、资源与交付节奏、技术方案对业务目标的适配度 |
| 评估难点 | 价值难量化——"从单体拆成微服务"这件事的ROI很难跟非技术Leader讲清楚 | 技术含金量容易被低估——"只是做了个CRUD但影响了2000万用户"这件事很容易在技术评审面前被贬低 |
| 成长路径 | 更大复杂度 → 更广范围技术影响力 → 更前沿技术领先 | 更深业务洞察 → 更大业务结果的责任 → 更强商业+技术双项判断力 |
混合型处理规则：约15%-20%的技术人才两条轨道都具备明显特征（多是资深Tech Lead/Tech Lead Manager）。混合型人才在九宫格中放在架构轨做主评，业务轨的分数作为维度的加分项计入。在角色画像标记为"A+BNote"——表示架构轨主评但业务轨有额外加分。
1.3 四维技术评估体系
| 维度 | 含义 | 架构轨权重 | 业务轨权重 |
|---|---|---|---|
| 技术深度（TD） | 在核心领域的技术造诣 | 40% | 25% |
| 技术影响力（TI） | 对团队/公司/行业的技术方向的引导力 | 30% | 20% |
| 工程素养（EC） | 交付质量和可持续性 | 20% | 30% |
| 技术领导力（TL） | 通过技术共识推动团队的能力 | 10% | 25% |
> 实际使用时权重不是硬公式——是告诉盘点者"主要看什么"的方向感。
§2 双轨定位指南
2.1 20题自测
用1-5分（1=完全不像我，5=完全像我）回答下面问题。
以下10题更倾向架构轨：
- 我在一个技术方向上的思考深度让同事觉得"有洞见"，不是"知道而已"
- 当我设计一个系统模块时——我第一反应不是"现在能用"而是"未来三年来其他人在上面加东西时会不会觉得结构清晰"
- 别人写了一段复杂的代码来跟我讨论——我能抓住核心思路并提出更好的方案
- 我对技术选型的判断标准——不只是"够不够新/够不够快"，而是"在这个场景适不适合"
- 我对团队技术债务的积累有持续的焦虑感——并不总能获得Leader支持去解决
- 我在技术会议上提出过至少3次"框架级优化建议"并被采纳
- 我能在10分钟内画出一张清晰的架构图解释当前系统的核心模块和边界
- 当业务需求和技术方案有冲突时——我倾向于从技术方案的可持续性出发，而不是"先上线再说"
- 我对某个开源项目或技术论文有深入追踪，并能在团队中讲到让同事理解的程度
- 我在晋升答辩中——最骄傲的成果不是"上线了什么功能"而是"建立了一套技术标准"
以下10题更倾向业务轨：
- 我在需求评审会上经常说的一句话是："用户要的不是这个——他们说A但其实要的是B"
- 我对业务指标数据有天然敏感——看到数据变化第一反应是"这对产品和用户意味着什么"
- 我理解一个功能为什么重要——不只是"Leader优先级定为P0"而是因为我对用户痛点的认知
- 我在拆分任务时——会主动把对业务价值最大的部分优先处理，即使它在技术上不是最有趣的
- 我交付的东西在业务方眼里是"快质量高"的——我对工程质量和交付速度都同样在意
- 我能在没有技术细节的前提下——跟非技术Leader讲清楚一个技术决策对业务的具体影响
- 我对工程速度的天生感觉是"够用就好+可扩展的剩余空间"——不是"我要把它做得完美"
- 我对团队交付瓶颈的直觉是对技术和流程的交叉判断——不是或者只看人或只看代码
- 我在产品和技术之间有桥梁作用——做产品的人会咨询我技术可行性，做技术的人会问我产品意图
- 我对新技术的态度是"这个技术对我的业务目标有没有帮助"——而不是"这个技术新不新、好不好用"
2.2 判定逻辑
- 架构轨得分明显高于业务轨（分差≥6）→ 当前主轨=架构轨
- 业务轨得分明显高于架构轨（分差≥6）→ 当前主轨=业务轨
- 两条轨道接近（∣分差∣≤5）→ 混合型：在九宫格中放在架构轨做主评，但业务轨分数以"B+"额外标注
2.3 Leader指定指南
当Leader不同意自测结果时——遵循"Leader定轨"原则。Leader定轨时需要写下三条具体行为证据：
> "我认为XX应定为[架构轨/业务轨]——因为：
> 1. [具体行为1]
> 2. [具体行为2]
> 3. [具体行为3]"
§3 四维评估卡
3.1 技术深度（TD）
正面行为指标：
- 在自己的核心领域能做出超越常规的选择——有"技术判断力"而不是"技术搜索力"
- 遇到复杂的技术问题，即便是自己没做过的领域，有系统性的方法快速掌握——而非只是问人或搜索
- 同事遇到技术难题时主动找TA咨询——TA的"深度"在团队中已经形成了默认共识
反面信号：
- 了解很多新技术但对每一个都停留在"用过"或"知道"层面——深度不够但广度伪装成深度
- 当被追问"为什么选这个方案而不是另一个"时——回答不出来底层理由，只能说"大家都这么做的"
- 代码产出的关键决策（库选型、接口设计、错误处理策略）看不出深度思考痕迹——浅度可互换
技术团队常见误区：
- 把"写了很久这个技术"误判为深度——年限≠深度，但业内很多人犯这个错误
- 把"会用很多框架"误判为深度——工具箱大≠每个工具能用得好
- 注意：深度不只关于"多懂"——更关于"在关键时刻中的精准判断力"
轨道差异：
- 架构轨：技术深度是核心中的核心。深度不够的架构轨是高风险的——TA会设计出看起来对但底层有致命缺陷的系统
- 业务轨：技术深度够用就好。反而过度追求技术深度的业务轨人才——容易出现"用大炮打蚊子"的工程判断力问题
3.2 技术影响力（TI）
正面行为指标：
- TA推荐的技术实践被团队成员主动采纳（不是行政要求），后来确实带来了可见的改进
- 在团队技术决策中——TA的意见有不成比例的权重，且这种权重来自于"TA说的基本都对"而不是"TA职位高"
- TA产出的技术资产（框架/工具/指南/文档）被TA所在团队以外的人使用或认可——影响力出圈
反面信号：
- 技术产出仅限于个人负责范围内——无法影响同组其他人更无法影响更广范围
- 在技术分享中——讲的干货少、讲的多是"我们做了什么"而不是"为什么这样做有用"——没有产生学习价值
- 态度上轻视"不产生代码的贡献"（文档/培训/开源/生态）——不理解影响力的本质是"让更多人在正确方向上"
技术团队常见误区：
- 把"职级高"误判为技术影响力——职级是影响力的结果（有时），但反过来不对
- 把"GitHub star多"误判为组织内的技术影响力——外部影响力≠内部影响力，这是两个不同维度
- 把"经常说话"和"经常被赞同"当做技术影响力——要看有没有改变了团队的实际做法
轨道差异：
- 架构轨：技术影响力是核心中的核心——没有影响力的架构师是一个高级开发，不是架构师
- 业务轨：技术影响力是加分项而非核心——业务轨的人通过"产物质量和交付速度"建立公信力
3.3 工程素养（EC）
正面行为指标：
- TA的代码或系统在异常情况下发生时——有线上故障但很少是"低级错误"导致的
- 提交的质量一致性好——不是有时候精品有时候烂尾；评审中可以区分"这是TA的代码风格"
- 对测试/监控/回滚等工程基础设施有自觉——不是等Leader要求，而是自己认为"代码不该没有测试"
反面信号：
- 代码只关注"跑通了"不关注"怎么跑不通时怎么知道原因"——对可观测性的自觉为0
- 技术债务积累有"后人解决"心态——当前任务的完成度在看下一次自己遇到时会怎样
- 对Code Review的态度消极——觉得"别人看我的代码是闲着没事干"
轨道差异：
- 架构轨：工程素养是基本盘——架构师写的代码不该比其他人的更难维护。低工程素养的架构轨=会在最高层面引入技术债务
- 业务轨：工程素养是客户感知层——业务轨交付的东西是给用户的第一印象；工程素养差的业务轨=产品体验层面有质量问题
3.4 技术领导力（TL）
正面行为指标：
- TA能让团队中其他人改变技术方向——不是通过行政权力而是通过"论证说服"和"以例带动"
- 在技术评审和其他技术决策场景中——TA不仅会"说no"还会给出"要做yes应该怎么做"的替代方案
- TA对团队中其他工程师的成长有可见影响——不用是"导师制"的形式关系，但同事会找TA请教
反面信号：
- 在技术决策中不表态——或只在私下批评但不在公开场合提出建设性想法——被动旁观者
- 对团队规范和技术标准没有建立和维护的参与——只是使用者不是制定者
- 当出现技术分歧时——不去找到共同点而是选择消极退出或"随便你们"
轨道差异：
- 架构轨：技术领导力是加分项——强技术领导力的架构轨=能在整个技术组织推广技术方向；弱技术领导力=仍是好架构师但无法跨团队推动
- 业务轨：技术领导力是核心——一个不能带人的Tech Lead Manager本质上不是一个合格的角色持有人
§4 双轨九宫格
4.1 架构轨九宫格
架构轨横轴=技术贡献度（过去+现在），纵轴=技术引领可能性（未来）。
| 位置 | 名称 | 简要描述 |
|---|---|---|
| 3A | 技术领导者 | 当前在核心技术方向上有决定性影响，且具备跨团队技术引领潜力 |
| 3B | 技术基石 | 在当前技术方向上是核心依赖——价值巨大但影响力尚未出圈 |
| 3C | 技术先锋 | 当前贡献已经很强，且能看到在更大技术范围引领的潜力 |
| 2A | 可靠架构师 | 技术贡献度在稳定高水平，但技术引领特征尚不明显 |
| 2B | 中坚力量 | 技术贡献稳定——适合继续在当前领域深耕 |
| 2C | 成长型技术人才 | 技术贡献度有提升空间但表现出了技术引领潜质 |
| 1A | 技术专家 | 技术深度突出——但影响力或工程素养有短板 |
| 1B | 可提升工程师 | 贡献度需要显著提升——目前按预期水平执行 |
| 1C | 待观察 | 需要注意——是否有技术潜力但缺乏当前贡献的可视化 |
4.2 业务轨九宫格
业务轨横轴=工程价值贡献度（过去+现在），纵轴=业务和技术双项判断力的成长潜力。
| 位置 | 名称 | 简要描述 |
|---|---|---|
| 3A | 技术驱动者 | 对业务和技术都有本能直觉——是那种能让技术对业务产生扭转型影响的稀缺人才 |
| 3B | 业务桥接者 | 对业务有深入直觉但技术深度相对弱——但能让技术能力精准服务业务需求 |
| 3C | 全栈型领导者 | 技术能力和业务判断力双高——且在团队中建立了交付可靠性 |
| 2A | 能力交付型 | 交付能力稳定强大——下一步可以是更大的业务责任 |
| 2B | 中坚交付 | 稳定产出——但还没表现出对业务成果的独特额外价值 |
| 2C | 业务导向成长型 | 当前技术能力还在成长——但对业务理解有超常规兴趣和直觉 |
| 1A | 技术熟练者 | 技术能力硬——但对业务方向和价值的理解滞后于技术能力 |
| 1B | 基础执行者 | 交付符合预期——急需找到在技术才能和业务价值之间的连接点 |
| 1C | 待转型 | 目前能力未表现出清晰的轨道方向——需要跟TA做一次深度对话讨论职业方向 |
4.3 双轨九宫格之间的转换
一个人可以从一条轨变到另一条轨——这不是"贬级"而是"重定位"。
- 从架构轨转到业务轨：通常需要TA表现出对业务的主动兴趣+减少对"技术应该做到完美"的执着。这个转换需要6-12个月的过渡期
- 从业务轨转到架构轨：通常需要TA深入一个技术方向至少12-18个月+表现出"在代码评审或技术分享中贡献独特洞见"的迹象
§5 角色画像模板与警示灯
5.1 架构师
轨道：架构轨
最优九宫格目标格：3A（技术领导者）或 2A（可靠架构师）——取决于技术领导力的当前程度
不在最优格的警示灯：
- 3B（技术基石）：技术影响力没有出圈——架构师的影响力被封锁在单一系统内。警惕TA是否只是在维护现有系统而不是在推动架构演进
- 2B（中坚力量）：可能被团队定位为"高级开发"而不是架构师——跟TA核对有没有主导过架构决策
- 1C（待观察）：这个位置与"架构师"角色的基本要求不匹配。可能TA从未真正承担过架构师职责——需要重新评估其技术判断力的发挥空间
5.2 基础架构工程师
轨道：架构轨（有时混合型）
最优格：3C（技术先锋）或 2C（成长型技术人才）——基础架构的人影响力天然跨团队
警示灯：
- 3B（技术基石）但持续6个月未产生"跨团队影响力指标"→ 可能只是在做工具功能叠代，不是在做基础架构影响力的推广
- 工程素养不够→ 基础架构代码的工程素养直接关联生产稳定性和团队信任——如果多次生产事故源于基础架构的bug，需要立即处理
5.3 Tech Lead
轨道：混合型（架构轨主评，业务轨加分）
最优格：3C（全栈型领导者）——一个Tech Lead需要能同时思考系统质量和业务目标
警示灯：
- 业务轨得分极低 → 警惕TA是否在做"纯技术推手"而不是"用技术创造业务价值的Leader"
- 技术影响力不够 → 警惕TA是否只在做"高级管理"而不是"带人写对的东西"
5.4 技术PM
轨道：业务轨
最优格：3B（业务桥接者）或 2C（业务导向成长型）
警示灯：
- 技术深度打分过高→ 警惕TA是否在做"兼PM的技术负责人"而不是用技术能力精准服务业务需求的PM
- 工程素养不够 → 如果技术PM对工程质量和交付可靠性不敏感——会导致团队失去对交付速度和质量的本能感觉
5.5 创业型工程师
轨道：业务轨
最优格：3C（全栈型领导者）或 3A（技术驱动者）
警示灯：
- 技术深度显著低于业务理解 → 警惕TA是否在追求业务结果但不愿意深入系统理解——这会导致"把复杂需求转化成简单方案"的能力缺失
- 技术影响力有限 → 创业型工程师不一定要有跨团队影响力——但如果完全没有，TA对团队的技术成长产生的影响为0
§6 校准会技术专用语 — 给非技术Leader的最小词汇集
6.1 核心技术价值翻译表
| 技术概念 | 给非技术Leader的说法 | 对应九宫格位置区域 |
|---|---|---|
| "TA写的框架被其他团队用了" | "TA做的东西让另一个团队省了至少3个月的重复工作——这不是一个功能，是一个基础设施" | 3A / 3C |
| "TA在团队里建立了高质量代码标准" | "在有TA之前和之后——这个团队产出质量有明显的不同。TA的贡献是让整个团队的质量提升了——不是TA一个人写得好" | 2A / 3A（架构轨） |
| "TA对系统架构有很深的理解" | "这个人对所有模块是怎么连接的有一个全图——不是只看自己负责的那一块。当需要做一个跨模块的决策时，TA是唯一能快速给出正确判断的人" | 2A / 3A |
| "TA的技术债务处理一直在推" | "这个人有一种'对可持续性的本能责任感'——TA会为长期的工程质量花时间，即使这让短期速度看起来没那么快" | 2A / 2C（架构轨） |
| "TA的产品感觉很好" | "这个人做出一个功能的时候对产品团队的反馈通常很少再改——因为TA做了第一轮产品判断" | 3B / 2C（业务轨） |
| "TA的交付速度和质量平衡得很好" | "这个人不用别人催——自己就能判断一个功能需要哪种质量水平。不是所有东西都追求完美，但要完美的东西TA会做到完美" | 2A / 3C（业务轨） |
6.2 校准会沟通原则
- 不要问非技术Leader"TA的技术深度怎么样"——他们回答不了。问："在TA负责的模块里，有没有出现过低级的线上故障？"→ 这就给出了"工程素养"的间接证据
- 不要问非技术Leader"TA对行业趋势的判断怎么样"——问："有没有别的团队用过TA做的技术工具或组件？"→ 这就给出了"技术影响力"的证据
- 对技术Leader的话需要翻译一次：当技术Leader说"这个人技术很强"——追问两个问题：①"怎么强？举个例子？"②"TA的'强'是被TA一个人锁在脑子里了——还是让别的团队成员也变强了？"→ 这就区分了技术深度和技术影响力
§7 技术人才发展路径卡
7.1 九宫格到发展行动
| 九宫格位置 | 架构轨发展行动 | 业务轨发展行动 |
|---|---|---|
| 3A | 主导跨团队技术方向（年度技术Roadmap掌舵）；组织外部技术分享或开源——提升行业影响力；辅导至少2位架构轨的2C型人才 | 主导一个对公司核心业务指标产生直接影响的重点项目；输出"如何用技术创造业务价值"的内部培训或文档——让非技术部门的人也能理解 |
| 3B | 输出一个跨团队的技术标准并推动落地；主动承担一次跨业务模块的技术评审主导；走出自己的团队推广一套实践 | 跟一位资深产品Leader做6个月的结对学习——强化产品判断力；培养至少1位有技术深度的人帮TA补齐技术短板 |
| 3C | 主导一个"技术先进+业务相关性高"的高影响力零到一项目；建立技术方向的系统性文档（不是只靠口头）——为更大的技术范围做准备 | 主导一个跨部门的复杂项目——要求协同至少3个不同职能团队；建立"用数据做技术判断"的思维方式——不只是"我觉得这个方案好" |
| 2A | 找机会在更多系统模块上做架构扩展——不是只在自己的舒适区；每季度输出一份"系统健康度报告"加上改进建议 | 主导一个有业务增长目标的项目——从需求→交付→监控全部负责；培养"工程指标+业务指标"双重对话能力 |
| 2B | 通过一项新技术的深入探索打破当前的平台期——6个月内成为一个新技术方向的团队内专家 | 主导一个"质量改善型"项目——提升某个核心功能的工程质量和客户体验 |
| 2C | 跟1位高级架构师做12个月的技术深入辅导——重点是"系统判断力"而不是"编码能力"；主导一个中复杂度项目的架构设计 | 承担一个跨团队工作的侧面——锻炼技术和产品的交叉判断力；跟Leader密集做每周一次的技术决策推演——"为什么这个方案是对的" |
| 1A | 识别当前系统中最大的技术短板——主动承担改善；输出高质量技术分享而非只做 | 跟一位有强业务理解的人（PM/业务方）做6个月结对——每周主动问"为什么这个需求优先级比那个高" |
| 1B | 确定TA想深入的技术方向——连续6个月保持对这个技术方向的追踪和学习（输出内部文档）；承担至少一次Code Review主导——讲清楚每条建议的原因 | 主导一个从0到1的小需求全流程——主动做需求评估→方案设计→交付→用户反馈→下一次迭代 |
| 1C | 做一次坦诚的职业方向对话——确认TA是否真的想留在技术方向；如果是——指定一个明确的技术方向+6个月的具体目标+每周辅导 | 做一次坦诚的职业方向对话——确认这个岗位/团队对TA是否合适；如果不合适——帮TA找内部转岗的机会 |
§8 使用流程
- 轨道定位：用§2的20题自测或Leader指定，确定每个人当前的主轨道
- 四维评估：用§3的评估卡对每个人在4个维度上打分。建议1-5分制，对每个分数给出1条具体行为证据
- 九宫格落位：根据四维综合分和轨道——映射到对应的九宫格位置
- 角色画像验证：对比§5的角色画像——如果一个人被放在一个和TA角色预期严重不匹配的九宫格位置，这本身就是值得讨论的线索
- 发展路径输出：基于九宫格位置和轨道——从§7的发展路径卡中选择行动项
- 校准会准备：为每个将被讨论的技术人才——用§6的非技术Leader语言准备1-2句"这个人核心价值描述"
§H 交付清单
- 技术人才专项盘点-需求说明书：目标用户、痛点分析、核心框架、功能模块和产品定位
- 技术人才专项盘点-README：功能摘要、核心理念、使用示例、版本记录
- 技术人才专项盘点-SKILL.md：本文件——完整操作指南，包含§0-§I全部章节
§I 版本历史
| 版本 | 日期 | 作者 | 变更说明 |
|---|---|---|---|
| 1.0.0 | 2026-07-20 | Marvis | 首次发布。双轨九宫格框架（架构轨×业务轨）、四维技术评估体系（TD/TI/EC/TL）、20题自测定位、角色画像模板（5种角色）、校准会技术专用语、发展路径卡、完整使用流程 |
| （内容由AI生成，仅供参考） |
