1. Domain Champion (领域冠军)：这位工程师是代码库某个模块的“土皇帝”，每天重复优化同一段代码，仿佛在跟代码谈恋爱，团队其他人根本不敢碰他的“专属领地”，这种“专业”本质上是一种变相的“知识绑架”，管理者需引导其拓展技能边界。
2. Hoarding the Code (囤积代码)：这行为就像程序员中的“宅男”，喜欢独自闷头干几周，最后扔出一个几千行的PR，美其名曰“大功告成”，实则完全无视协作，把审查压力转嫁给队友，还自诩高效。
3. Unusually High Churn (异常高变更率)：这简直是程序员版的“强迫症”，同一段代码改了十几遍，每次改动都不大，但加起来能绕地球三圈，还振振有词“我在提升质量”，殊不知用户只关心功能能不能用。
4. Bullseye Commits (神枪手提交)：工程师精准拆解任务，代码提前完成，改动小、审查一次过，几乎没有返工，是团队里真正的“稳定输出”，值得在站会上公开表扬，堪称教科书级的开发范本。
5. Heroing (救火英雄)：发布前最后一刻跳出来修复严重缺陷，看似力挽狂澜，实则暴露流程漏洞，久而久之团队会依赖这种“救世主”，反而助长了前期的懒散和低质量。
6. Over Helping (过度帮忙)：一个工程师总在帮另一个擦屁股，改完一次又一次，表面是协作，实则让被帮者失去成长机会，自己也累得半死，形成病态依赖，最终拖垮两人效率。
7. Clean As You Go (边走边修)：在完成新功能的同时，顺手修复周边的烂代码，虽然没有“新功能”那么耀眼，但对减少技术债务至关重要，是团队里默默无闻的“代码清道夫”。
8. In the Zone (心流状态)：工程师每天稳定输出，代码节奏均匀，PR大小适中，参与审查积极，几乎零返工，像一台精密的机器，是可持续交付的典范，值得所有人学习。
9. Bit Twiddling (比特翻弄)：在一小块代码上反复微调，像拼图时不断拿起同一块又放下，毫无进展，通常是因为不理解问题本质，已陷入思维僵局，急需外力介入打破。
10. The Busy Body (忙碌的闲人)：在代码库各处跳来跳去，修一堆小问题，看似很忙，但从不负责大模块，缺乏归属感，长期如此容易因没有成就感而离职，是“伪忙碌”的典型。
11. Scope Creep (范围蔓延)：需求方在开发中途不断加功能，美其名曰“优化”，实则让团队加班加点，最后发现 sprint 末期工作量突然暴增，这就是典型的“我再加个小功能”陷阱。
12. Flaky Product Ownership (飘忽的产品Owner)：需求文档写得像谜语，开发中途又频繁改主意，导致工程师反复返工，不是技术不行，而是产品方自己没想清楚，却让工程师承担后果。
13. Expanding Refactor (扩张式重构)：本想优化一段代码，结果越改越多，从局部优化变成全面重写，最后把无关模块也牵扯进来，纯属“借题发挥”，浪费团队大量时间和精力。
14. Just One More Thing (再加一个小功能)：临近发布，团队成员纷纷提交“最后一个小改动”，导致PR堆积如山，审查草率，风险剧增，这是流程失控的信号，说明内部 deadline 形同虚设。
15. Rubber Stamping (橡皮图章式审查)：reviewer看都不看就写“LGTM”，然后点击合并，美其名曰“信任同事”，实则逃避责任，牺牲了代码质量、知识传递和团队协作的多重价值。
16. Knowledge Silos (知识孤岛)：几个工程师只互相审查代码，形成封闭小圈子，外人无法参与，一旦有人离职，项目就可能瘫痪，是团队健康的最大隐患，堪比“定时炸弹”。
17. Self-Merging PRs (自我合并PR)：工程师自己提交、自己批准、自己合并，代码直接进主干，完全 bypass 审查流程，无论多牛，这都是高风险行为，等于给生产环境埋雷。
18. Long-Running PRs (长期未关闭的PR)：一个PR开了半个月没人理，评论区只有几句模糊讨论，然后陷入沉默，像团队里的“幽灵任务”，消耗注意力，拖慢整体节奏。
19. A High Bus Factor (高巴士因子)：团队知识分布均匀，多人掌握同一模块，即使有人“被公交车撞了”，项目也不会瘫痪，是健康团队的标志，应作为管理目标持续追求。
20. Sprint Retrospectives (冲刺回顾)：本应是反思改进的会议，却常沦为“走过场”，只说空话。应引入数据，展示谁的PR长期未关、谁在囤积代码，用事实推动真正改变。