我当前做了什么，匹配什么能力
英文版：English
分数是怎么产生的
方法放在最前面，因为没有方法，数字就是噪音。雷达上每个 depth 分数都由证据密度推导：旗舰 artifact 的数量与深度（带证据引用的事故复盘、经受住重测的实测结果）、从工作中沉淀出的方法论体量（runbook、debug tree、固化的规则），以及是否存在公开可验证之物。它明确不是自评。
原因是：自评分数对读者没有信息量。自评在人与人之间没有校准，夸大的激励是结构性的，而且当你不同意时无处可查。一个由认证过的迁移支撑的 82 是可以审计的声明；一个由自信支撑的 82 只是一种心情。从证据推导分数还带来一个性质：它们可能以可检查的方式出错。这正是让它们值得发布的性质。
九个域，每域一段
**数据与状态：82/90。**旗舰证据：一次 ClickHouse 到 Doris 的迁移，约 52 亿行、约 3,700 列的表，在全量无采样数据集上认证 99.945% 行级完整，四类非直觉 OOM 和一次 livelock 的根因追到引擎层。另有一次全量恢复演练：52 亿行从快照恢复到独立卷并用查询验证。82 是最高的轴，因为证据钻得最深，深到引擎代码。不是 90，因为深度集中在一个引擎家族，且恢复演练是一次性的，尚未制度化。
**可观测性：80/85。**建设并运营一个多租户监控平台（50 集群、120 万活跃序列）；规模化的遥测取证，包括挖掘 7,470 万行生产 query log 并逆转了一个表设计决策；分段延迟归因证明了被怀疑的一层无罪。到 85 的差距不在工具，在 SLO 运营，见事件响应一节。
**分布式系统：78/88。**把存算分离当成一笔交易来论证（状态是被集中了，不是消失了），然后实际运营它；一套两层准入控制设计，其安全性从不依赖分类器判断正确；以及「点查瓶颈是打开文件数、不是扫描行数」这个发现。到 88 的距离是诚实的那种：我运营并推理 consensus 与复制层，但没有设计过一个。
**平台与自动化：76/85。**用 controller 替代脚本，并且这条标准反向也执行：平台 operator 成熟后，把自研 scaler 收缩成一次 JSON-patch。一套 AI agent triage harness 和一个 agent 控制面，加上升级自动化。差距在于：这些还没有一个作为产品被本团队之外的用户使用过。
**事件响应与可靠性：72/82。**作为 primary oncall 处置 20+ 生产 P1/P2，MTTR 约 30 分钟；两次 compaction 事故根因到引擎层；一次尾延迟调查最终追到一个伪装成物理规律的超时常量。72 度量的是响应能力。它刻意不包含的（因为记录里确实没有）是一个季度的 SLO 与 error budget 运营。这是到 82 的大部分距离。
**基础设施与容量：70/80。**一条四层 IaC 流水线（镜像烘焙、编排、配置、控制面引导）；作为 primary oncall 运维 50 集群、600+ 节点、6 个 region；容量决策来自实测，包括在花钱之前证明加节点无效。一条边界如实写明：我在 autoscaling group 和 launch template 层的深度是消费与修补，不是从零设计整个舰队。
**发布与变更：68/78。**生产 Kubernetes 从 1.24 升到 1.29，覆盖 50 集群零事故，自建自动化把单集群耗时从 18 至 21 小时压到 3 至 4 小时；一次 dry-run render-diff 拦下了 chart 升级把 serving 池从 4 副本静默重置为 1 的地雷。差距：服务级的渐进式交付作为日常实践，而不只是升级项目里的纪律。
**影响力与沟通：52/75。**监控栈的内部培训 deck 和引导式 onboarding；一项告警治理倡议；双语技术写作；一份逐行审计改变了 leadership 关于开源范围的决策。全部真实，全部局部。52 说的正是这个：记录里有说服和教学，但没有一个由我发起、跨越团队边界、带资源投入的项目。
**安全与合规：40/65。**真实的工作在 agent 一侧：默认拒绝的封装工具、写入 attestation、按爆炸半径分级的执行闸门。传统面（IAM 设计、SOC 2 类审计框架）在记录里基本缺席。40 是事实陈述，不是谦虚。
一次行为层面的交叉验证
上面的分数是自上而下、从证据评审中给出的。还存在一个独立产生的自下而上信号：我的 oncall 知识库。它是长期处置事故的副产品，不是为这个站点准备的。目前包含 21 篇 documented investigation（其中 20+ 为生产 P1/P2）、16 篇 runbook、15 张 fast-triage card、7 棵 debug tree、4 个反复出现的根因模式。
按域给这些条目打标签，得到：incident 14、data 8、obs 6、infra 6、dist 5、release 5、platform 2、security 0、influence 0。
在解读之前，先对分母做两点诚实说明。第一，这些是「写下来的」调查：计数衡量的既是暴露度，也是文档纪律，没写下来的工作在这里不可见。第二，「21 篇 investigation」和「20+ P1/P2」有重叠但不是同一个序列：investigation 是被带证据写下来的那个子集。
在这两条限定下，交叉验证是成立的。incident 领先是结构使然，它本来就是一个事故知识库。在主题域里，data 以 8 领跑，正好对应 data 是雷达最高的轴；obs、infra、dist、release 聚在中段，对应中等高度的轴；security 和 influence 是零，对应最低的两个轴。雷达形状和 triage 记录由不同过程在不同时间产生，而它们互相印证。如果我夸大了任何一个轴，矛盾会在这份记录里显形。