xulingfeng 那篇帖子是 10 月 16 日发的，标签打了 discuss、career、jokes 和 programming。Jokes 放在第三个，但评论区那 75 条回复的认真程度，像一群人在拿简历互砸，清一色按文章模板报岗位、年限、存活率，很多还附了第一生存法则。这种帖子在 dev.to 不罕见，但这次有个东西不对：玩笑越开越像真的。
作者给自己 50%。15 年 QA，50% 的存活率。然后补了一刀，说 QA 有个致命习惯——回去复现 bug。为了搞清楚变异的触发条件，得返回现场、收集日志、录像、二次复现。这一下把 50% 打到 5%。文章里写的是"最后一个边缘用例"，调侃的意味很足，但我读到这里的时候想的是另一件事：一个测试工程师在丧尸爆发里坚持回去复现 bug，直到被咬死——这件事本身，比很多公司生产环境里正在发生的事更像一个笑话。
我对这篇帖子的兴趣不在段子本身，在评论区那 75 条回复里漏出来的东西：这群人对自己职业能力的误判，和他们对风险定价的集体困惑。他们说存活率的时候，几乎没人真正算过这笔账。都是在用职业习惯套灾难场景，套完给个数字了事。
QA 的优势，作者讲得很具体：不轻信所谓正常流程。在多方基础设施同时失效的时候，QA 是最早意识到"这不是个别故障，是系统性崩溃"的人。暂停原路径、隔离风险、找替代方案——这个动作序列写出来平平无奇，但真在生产环境里做过故障处置的人会知道，能在多重告警同时爆发时做到第一反应是"停"而不是"修"，这种人不多。大多数人第一反应是把报错的那个服务重启一下，看看是不是自己好了。
这是 QA 值钱的地方。
但那个"复现 bug"的致命伤，几乎把前面所有优势都抵消了。而且这不是开玩笑——它是这个职业的底层逻辑。QA 的整个价值体系建立在"复现"上：一个 bug 如果不能复现，就等于不存在；一个测试如果不能再跑一遍，就等于白做。所以一个 QA 在丧尸爆发里的第一反应不是跑，是看日志、录像、回去复现。这是职业训练的结果，不是愚蠢。
把这件事翻译成生意话：一个把验证当核心能力的角色，在不确定性极高、样本量极小、容错为零的场景里，会被自己的方法论杀死。这个判断不止适用于丧尸爆发。
评论区有个数据我反复看了几遍。Owen Ross，入门级渗透测试员，从业 2 年，给了自己 10%。这是所有人里最低的。我觉得这个数字接近真实。不是因为他菜，恰恰是因为他刚入行，还清楚自己什么不懂。他给出的第一生存法则是"锁好门"。这条朴素到有点可笑的法则，可能是所有回复里最有效的一条。但他给 10%，不是因为锁门不够，而是因为渗透测试员的职业路径上，越资深越有一种危险的倾向：想看看那扇门后面藏着什么。文章里说安全工程师"隔离意识最强，但可能为了证明漏洞影响而闯入最危险的区域"。这件事放在丧尸爆发里是送死，放在企业安全审计里也是送死——只不过后者死的是合同和赔偿金。
把安全这一格单独拿出来看。文章的归类是：安全工程师隔离意识最强。这在丧尸场景里是保命的核心能力——最差的不是跑得慢，是把感染源和未感染区混在一起。安全的人天然理解分段、隔离、最小权限。但那个致命习惯，"为了验证漏洞影响而闯入最危险的区域"，也是同一个职业的底层逻辑。一个安全研究员如果每次写报告都停在"理论上这是不行的"，他交不了差，他得拿出 PoC。要 PoC 就得真的进那个危险的地方，在当前环境下亲手把这个洞打穿。把这套逻辑塞进一个"最危险区域会变异"的世界里，结果就是：越专业，死得越快。
James Anderson 作为 AI/Agent 工程师给自己 35%，并按这一行的逻辑提出了一个验证原则："证人是嫌疑人"。他的原文我不作逐句翻译，但他的意思很清楚：不能只信报告，要核实实际效果。这个原则放在生产环境里是完全正确的。Agent 的执行链路上每一步都可能给出看似成功的回报，但最终结果可能什么都没发生。文章里那句"两个智能体都报告任务成功而包裹原地未动"，几乎每一句都能对应到如今 agent 工程里真实的问题——执行层确认了，状态层确认了，日志层也确认了，但业务闭环没闭。用 agent 去侦察、再用另一个 agent 去复核结论，这在 agent 工程里是典型的多智能体验证模式，看起来严谨，但在容错为零的场景里有一个致命的前提：两个 agent 共享同一个错误的语义一致性。如果它们用的是同一套上下文理解模型，第二个 agent 的"复核"并不会增加有效的独立验证信息，它只是在用同一个漏洞确认同一个结果。
这个点文章没有展开说，但评论区的人在自己的语言里摸到了这个边。这几段算得有点碎，但账不细算不清。
后端工程师 Daniel Balcarek，15 年经验，说 AI 给他的存活率是 70%（仅限丧尸末日），然后补了一句"计划学木工来封门窗"。这句玩笑里有实话：后端的人对"封住"这件事有路径依赖。他们在职业里处理问题的方式是把入口挡住、把数据存好、把事务记下来，剩下的交给时间。但丧尸场景里没有事务回滚。这个答案如果是认真的，那 70% 里 69% 都来自他的木工计划，而不是后端能力本身。
nyao maru 是前端工程师兼开源维护者，55%，第一生存法则是"不要在事故中重写整座城市，先稳住关键路径"。我读这条的时候笑了。开源维护者的本能在这种事里意外地有用。
Sylwia Laskowska、Mustafa ERBAY、Yoshiyuku，给的数据不是关键。关键的是他们给这些数据时的依据，各自都从自己的职业角度找到了一个"优势和致命伤"的对称点。Mustafa 说绝不能信任单点故障，尤其当单点就是自己——这是系统架构师对自己职业思维的完整体现。Yoshiyuku 说自己可能为了统计显著性死在出口。这些都是段子，但每一个段子的内核，都是在说：你的职业训练把你塑造成什么样的人，你在灾难里的生存概率就会随之改变。
而这一点，评论区没有人真正点破。他们在玩笑，在自嘲，在用模板测自己的职业人格。但没有一个人停下来问：把职业习惯套在灾难里的游戏，背后的逻辑到底是什么？甚至连 xulingfeng 本人，也只是把这个东西写成了一个幽默模板，四段式总结每个岗位的优势和致命习惯，然后在结尾虚构了一张城级 bug 报告单。
问题出在这张 bug 报告单的最后几行。
Severity: Critical。Reproducibility: 100%。建议：立即阻止发布。Umbrella 管理层回复：已知问题，不计划修复，不影响核心业务。
很多人会把这几行当成全篇最好的笑点，因为它的确好笑，它完美复刻了很多人实际经历过的 Jira 对话。但我更愿意把它看成整篇帖子的题眼。整篇文章从头到尾每个岗位的生存率分析，到了这张 bug 报告单上，其实已经全盘揭开底牌了：问题不是职业习惯能不能帮你活下来，问题是灾难的责任方，是那个允许病毒"发布"出去的公司。QA 在整个故事里，不是被丧尸咬死的，是被"已知问题、不计划修复"杀死的。
这个梗的真正力度，不在它复刻了什么，在它绕开了什么。Umbrella 管理层说"已知问题、不计划修复、不影响核心业务"，这本身就是一个真实的商业决策模型。QA 的 50% 存活率，是在这个决策模型已经成立之后才被推入的；无论你怎么算，前 90% 的风险早在这种"已知问题、不计划修复"的决策里发生了。等 QA 在街上想着怎么复现 bug 的时候，其实这笔账已经结完了。
所以这篇帖子真正让我放不下的，不是那些职业段子，是"验证岗位在灾难性决策链条里的位置"这个更冷的问题。一个组织里承担"验证"职责的岗位，为什么总是最晚知道风险、却最早被派出去接刀。那篇帖子里的 15 个岗位，不管在笑话里给自己多少存活率，他们真正的风险在 Umbrella 决定"不计划修复"的那一刻就已经被锁死了。
落一句判断：在多数技术组织里，验证岗位的角色，是把"发现、核实、复现、上报"的成本扛起来，但修复决策的成本不在验证层。当问题被管理层标记为"已知"，复现这个动作就从职业义务退化成了自我消耗。在丧尸爆发里，QA 回去复现 bug，是职业习惯害死自己；在公司里，QA 反复复现同一个已经被"不计划修复"的 bug，是决策层把成本转嫁给了验证层——而验证层到死都以为自己在做正确的事。
xulingfeng 给他的 QA 同行算了 50% 的存活率，然后用一个"复现 bug"把它烧到 5%。这个数字可能没错。但我更想补充的是：在真实的生产环境中，QA 的存活率可能没这么糟糕，因为在真实的生产环境中，丧尸通常不会真的追到他们身上——它们被关在"已知问题"的队列里，永远不会有发布日。
而那个"最后一个边缘用例"，才是最不用担心的。
我的判断摆在这儿：这件事真正可迁移的框架，是"验证成本"与"执行成本"的错配——谁负责发现、谁负责确认、谁负责修复、谁负责决定不修复，四层之间一旦没有明确的价格信号，验证就会变成一种消耗性劳动，而不是一种保障。这个判断能被证伪：如果未来出现一种组织形态，把"验证结果"直接与"发布决策"之间做成硬绑定，且验证失败会产生真实的预算回拨或发布拦截，那我这套"QA 往往接刀"的理解就作废。在那个世界到来之前，我坚持这个判断。