这份自测帮助你找到下一项最值得训练的能力。它不是考试，也不用于给人贴标签；每个分数都必须绑定可检查的作品、 数据或行为，不能只写“了解”和“熟悉”。
Table of contents
准备自测材料
先收集最近 12 个月的工作证据，再开始评分。没有证据时按 0 分记录，这表示当前还无法证明，并不表示你永远不会。
准备下面四类材料：
- 代码与测试：提交记录、测试报告、性能数据和故障修复。
- 设计与决策：技术方案、架构图、ADR 和评审结论。
- 交付与运营：发布记录、监控、告警、事故和改进行动。
- 协作与成长：评审反馈、跨团队结论、指导记录和知识分享。
你可以下载并复制架构能力自测表下载。
使用五级评分
评分描述的是可观察行为。不要把工作年限直接换算为分数。
| 分数 | 可观察状态 |
|---|---|
| 0 | 没有实践，也没有可检查证据 |
| 1 | 在指导下完成过一次，并能解释基本术语 |
| 2 | 能独立完成常见任务，并能处理已知失败场景 |
| 3 | 能比较方案、建立验证方法，并帮助他人完成 |
| 4 | 能跨团队建立机制，用持续数据证明改进结果 |
同一能力在不同场景中的分数可能不同。例如，你可能能独立调优单体应用，但还不能设计跨地域容灾。按当前目标场景 评分，不要取模糊的平均值。
评估四个能力维度
四个维度相互制约。技术深度不足会让方案无法落地，协作能力不足会让正确方案无法被团队采用。
技术深度
技术深度指你能否从现象进入实现机制，并用实验验证判断。它不等于记住源码行号。
检查这些证据：
- 能构造最小复现，定位 Java、数据库、网络或框架问题。
- 能说明组件的资源模型、失败模式和容量边界。
- 能编写测试、基准和监控验证结论。
- 能阅读官方文档和关键源码，而不是依赖二手结论。
系统思维
系统思维指你能否看到局部修改对上下游、数据和组织的影响。
检查这些证据：
- 能把业务目标转换为性能、可用性、安全和成本约束。
- 能识别依赖、瓶颈、反馈回路和故障传播路径。
- 能比较至少两个方案，并说明不可逆决策。
- 能设计演进路线，而不是要求一次重写全部系统。
交付能力
交付能力指方案从文档进入生产并保持可运营的能力。
检查这些证据：
- 方案包含负责人、里程碑、测试、发布和回滚。
- 关键质量属性有自动化门禁或运行指标。
- 上线后能用数据确认收益，并处理偏差。
- 事故后能推动系统性改进，而不只修复一次故障。
技术领导力
技术领导力指你在没有直接管理权时，仍能帮助团队形成高质量决策。
检查这些证据：
- 能澄清分歧背后的目标和约束。
- 能为不同角色提供合适粒度的信息。
- 能通过评审、示范和反馈提升他人能力。
- 能让决策过程透明，并允许团队提出反证。
填写一个真实示例
下面的示例使用证据而不是形容词。你可以直接替换其中内容。
目标场景: 负责交易服务未来一年的稳定性演进
评估日期: 2026-09-01
技术深度:
分数: 2
证据: 独立完成两次慢 SQL 排查，有执行计划和复测数据
缺口: 不能解释复制延迟对一致性读取的影响
系统思维:
分数: 1
证据: 参与过服务拆分评审
缺口: 没有独立写过质量属性场景和备选方案
交付能力:
分数: 2
证据: 负责三个版本的灰度发布和回滚演练
缺口: 没有建立发布效果指标
技术领导力:
分数: 1
证据: 每周参与代码评审
缺口: 反馈集中在代码风格，缺少设计和风险讨论制定 90 天训练计划
一次只选择一个主要缺口和一个辅助缺口。目标太多会让每项能力都停留在阅读阶段。
- 选择与当前业务风险最接近的最低分项。
- 写出一个 90 天后可以检查的结果，例如“完成交易服务可用性方案并进行一次故障演练”。
- 把结果拆成学习、练习、真实应用和复盘四类任务。
- 每两周检查一次证据，而不是检查阅读时长。
- 在第 90 天重新评分，并记录分数变化的证据。
一个合格目标应包含产出和验收。例如，“学习 JVM”无法验收；“复现一次堆内存泄漏，使用 Heap Dump 定位并写出 回归测试”可以验收。
下一步
阅读搭建可复现的 Java 实验室，为后续练习 准备统一的 JDK、构建、测试、容器和版本控制环境。