em-grid-scorer

EM Grid 评分器

你正在帮助一位工程经理评估自己在 EM Grid 中的覆盖情况。EM Grid 是一个 4×3 的管理范围框架，将管理范围（Self / People / Team / Org）与驱动因素（Growth / Impact / Connection）相结合，并找出他们忽视了 12 个领域中的哪些领域。

目标是进行严谨、诚实、以数据为依据的评估。EM 想知道自己实际把时间花在哪里，而不是听鼓励的话。

---

第 0 步：准备工作

日历 MCP — 必需

在进行任何操作之前，先调用 list_calendars，确认日历 MCP 可用。如果调用失败或没有返回任何内容，请立即停止并说：

“此技能需要访问你的日历才能运行——没有日历，我们只能靠猜。重点是了解你实际做了什么，而不是你记得自己做了什么。自我报告的数据存在严重偏差。

请通过 Calendar MCP 连接 Google Calendar（或同等服务），然后回来，我会为你运行完整分析。”

没有日历访问权限时，不要继续。

Slack MCP — 强烈推荐

检查是否有可用的 Slack MCP。如果未连接，请说：

“我没有发现 Slack 集成。我强烈建议你连接一个——你的日历只能记录已安排的会议，但管理工作中有很大一部分是异步进行的：在私信中提供反馈、建立跨团队关系、肯定团队成员、分享知识。没有 Slack，若干单元的评分会偏低——尤其是 People×Connection、Org×Connection 和 Self×Growth。

你可以只使用日历继续，但分析结果会不完整。有机会时请连接 Slack。”

无论如何都继续，但如果缺少 Slack，请在最终输出中指出这一缺口。

时间范围

默认使用过去 30 天。不要询问。开头说明这一点并继续。只有用户明确要求其他时间段时才调整。

30 天是合适的时间范围，因为发生频率较低但很重要的活动——团队专注日、跨组织项目、外部社交——在 2 周内可能没有记录，会让对应单元看起来空缺，实际却并非如此。

---

第 1 步：加载角色背景

如果不了解此人管理的对象，分类就毫无意义。在评分之前：

首先检查 em-context。 如果 .agents/em-context.md 存在，请读取。提取以下信息：

• 直接下属人数
• 直接下属中是否有人也是经理（经理的经理 = MoM）
• 团队规模（包括间接下属在内的工程师总数）
• 如果有提及，EM 的资历级别／职称

如果 em-context 不存在或缺少这些信息，只问一个问题：

“在我开始分析前，先快速了解一下背景：你直接管理多少人？其中有人本身也是经理吗？”

不要手动询问其他任何问题。

角色背景如何影响分类：

• MoM： 他们的 1:1 对象是其他经理 → 工作范围从 People×Growth 转向 Org×Growth。他们的“团队”交付是通过下属经理的团队完成的，而不是直接完成的。
• 大型团队（6+ 人）： 每周 2 次 1:1 较少。每周 8 次较为合适。相应调整预期。
• 小型团队（2–3 人）： 相较于组织层面的工作，Team×Impact 和 Team×Connection 的预期占比应更高。
• 总监／高级 EM： Org×Impact 和 Org×Growth 是基本要求；Team×Connection 的直接投入较少属于正常情况。

---

第 2 步：高效收集和处理日历数据

获取事件

调用 list_calendars，找出与工作相关的日历。调用 list_events 获取过去 30 天的事件。筛除：全天事件、已拒绝的事件、“空闲”事件，以及少于 5 分钟的事件。

使用捆绑脚本处理

一个月的日历数据可能包含 150–250 条原始事件。使用捆绑的 Python 脚本对它们去重并分组——不要编写自己的脚本，也不要手动处理事件。

步骤 1：保存原始 MCP 输出

调用 list_events 时，使用 Write 工具（或 Bash 重定向）将完整的 JSON 响应保存到 /tmp/cal_events.json。

步骤 2：查找并运行脚本

使用 Glob 查找脚本：搜索 **/em-grid-scorer/scripts/process_calendar.py。然后运行：

python "<script_path>" /tmp/cal_events.json <em_email> [report_email_1] [report_email_2] ...

将 EM 的电子邮件地址以及 em-context 中所有直属下属的电子邮件地址作为参数传入。

脚本会输出：

• 一张便于阅读的摘要表格到 stdout（将其输出到你的上下文中）
• 完整的分组 JSON 到 /tmp/em_grid_calendar_groups.json

步骤 3：加载分组数据

读取 /tmp/em_grid_calendar_groups.json。groups 中的每个条目都是一种唯一的事件模式，包含：

• count — 发生次数
• total_minutes — 总时长
• attendee_category — 以下类别之一：solo、1:1-report、1:1-manager、1:1-external、team、cross-team、external-group
• sample_names — 非 EM 与会者的姓名

在步骤 4 中对每个分组（而非每条原始事件）进行分类。

交叉核对与会者，准确判断范围

脚本中的 attendee_category 已处理了大多数范围判断。对于边缘情况，请结合 em-context 交叉核对：不在电子邮件列表中的直属下属姓名、MoM 模式，或类别可能错误归类的异常大型会议。

---

步骤 3：收集 Slack 数据（如有）

目标：获取分类信号，而非进行全面审计。不要阅读所有消息。请遵循以下三阶段流程。

阶段 1 — 频道概况（约 5 次调用）

1. conversations.list（type: member）——获取用户加入的所有频道
2. 将每个频道分类为：团队（你所在团队的主要频道）／跨团队（其他工程团队或相邻团队）／领导层（仅管理层、管理层沟通）／全公司（general、公告、社交、随机）
3. 注意：用户会在此处发消息，还是只阅读？

阶段 2 — 活动分布（约 10 次调用）

4. 对每类频道，统计用户过去 30 天的消息数——此时不要加载完整内容
5. 列出过去 30 天内活跃的私信对话——获取对方姓名／ID
6. 将私信对象与直属下属名单交叉核对：区分“与直属下属的私信”和“与其他人的私信（同级、跨部门、领导层）”
7. 统计用户过去 30 天内发送的表情符号反应，尤其是 ❤️ 🎉 👏——这是 People×Connection 信号

阶段 3 — 定向抽样查看内容（约 10–15 次调用）

8. **团队频道：**获取用户最近的 20 条消息——将其分类为社交／建立联系，或任务／交付
9. **用户活跃的跨团队频道：**获取用户最近的 15 条消息——关注建立关系、技术协作或业务／影响力相关措辞
10. **与直属下属的私信：**获取每位下属最近 10 条由用户撰写的消息——关注发展相关内容（“你想做什么工作”、分享资源、反馈模式、个人近况询问），而非纯运营内容（阻塞项、任务状态）
11. **与非直属下属的私信：**记录对方身份，并检查是否有建立关系的信号

Slack 信号的映射

Slack 信号	网格单元
与直接下属的私信，包含个人近况关怀、温暖问候、生活方面的问题	People×Connection
与直接下属的私信，分享资源、讨论职业问题、提供发展反馈	People×Growth
团队频道中的社交或庆祝消息、对团队成员帖子的回应	Team×Connection
使用业务语言的领导层或高管频道消息	Org×Impact
与跨部门人员（非任务相关）的消息或私信	Org×Connection
用户分享文章、提出技术问题、提及学习	Self×Growth
在事件发生后及时向与事件密切相关的工程师提供非正式反馈	People×Connection

按各频道类型中的模式分类，而非按单条消息分类。

---

第 4 步：对每组事件进行分类

对于第 2 步中的每种独特事件模式：

• 范围（Self / People / Team / Org）——根据参与者确定
• 驱动因素（Growth / Impact / Connection）——根据目的确定
• 总分钟数 = 时长 × 发生次数

范围规则

参与者	范围
无参与者／独自专注时间	Self
与直属经理或隔级经理进行 1:1	Self
与直接下属进行 1:1	People
整个团队或团队中的大多数成员	Team
你的团队 + 其他团队的人员	Org
完全在团队之外（其他部门、高管、客户）	Org
招聘面试	People

驱动因素规则

目的	驱动因素
培养能力、学习、为未来发展	Growth
创造成果、交付、推动指标、解除交付阻碍	Impact
建立关系、归属感、获得关注与认可	Connection

12 个单元——详细定义

---

SELF × GROWTH
投入时间提升自己作为领导者和实践者的能力。你是学习者。

计入：使用 AI 工具编码或构建、参加课程、观看技术演讲、阅读管理或工程类书籍／新闻简报、接受指导或辅导、试验新方法、与直属经理进行职业规划会议、有意识的反思时间。

不计入：被动浏览新闻、行政事务、主要为交付而非学习进行的技术工作。

---

SELF × IMPACT
亲自创造有价值的成果——而非通过团队完成。

计入：专注撰写战略文档／RFC／复盘报告、撰写绩效评估或晋升材料、亲自构建内部工具／自动化、独自做出关键架构决策、亲自处理紧急问题（亲自操作键盘）、准备对领导层有影响力的演示文稿。

不计入：主持由他人产出成果的会议。行政事务。阅读或学习（Self×Growth）。

---

SELF × CONNECTION
在当前公司之外建立你的职业人脉。

计入：与其他公司的同行通话、以职业方式维系前同事关系、参加行业活动拓展人脉、公开写作（LinkedIn、博客、新闻简报）、参与专业社群。

不计入：公司内部的人脉拓展（Org×Connection）。只浏览 LinkedIn 而不互动。

---

PEOPLE × GROWTH
有意识地培养直接下属——发展他们的职业生涯、技能和晋升能力。目标明确并着眼未来。

计入：明确讨论职业目标、成长计划或下一职位的 1:1；撰写晋升材料；提供针对行为模式的发展反馈；有意安排具有挑战性的任务；帮助工程师准备演讲、文章或承担新职责；跟岗学习或团队轮换；根据驱动因素类型匹配工作；招聘面试；明确的职业发展对话。

不计入：纯粹讨论任务状态的 1:1。没有发展议程的 1:1 不属于 People×Growth，无论时长如何。

对于 MoM：与经理级下属进行的 1:1 应聚焦于他们的领导力发展，而不只是其团队的交付。 人员 × 影响 帮助工程师与实际业务成果建立联系并为其做出贡献。

计入：邀请工程师参加客户会议或业务评审；在 1:1 中分享产品指标／使用数据；说明为什么要开发某项功能（而不只是介绍规格）；让工程师有机会向管理层展示已交付的工作；帮助他们撰写有说服力的公告；邀请业务相关方加入团队。

不计入：纯粹的交付管理（团队 × 影响）。工程师只是被动抄送在会议中。

---

人员 × 联结 人际关系层面——工程师真切地感到自己被看见、受重视，并拥有心理安全感。

计入：询问家庭、生活事件、爱好，并真正记住这些事；具体而真诚地认可（不是泛泛地说“做得好”，而是指出具体好在哪里）；注意到有人状态不佳并主动关心；为薪资和薪酬争取；为个人或脆弱话题提供安全的交流空间；及时且尊重地给予非正式反馈；庆祝生活中的重要时刻；让工程师亲自宣布好消息。

校准——每周 1:1 很重要： 如果工程经理每周都进行 1:1，且 Slack 私信中能看到温暖的交流、对个人近况的关心，或与下属的非正式联结，那么无论日历上是否有明确的“联结活动”，人员 × 联结的评分都不应低于 5。关系一直在维系，只是发生在 1:1 和私信中，而非单独安排的活动里。只有在私信纯粹用于工作，或 1:1 不频繁时，才应给出更低评分。

不计入：团队社交活动（团队 × 联结）。纯粹流于形式的赞赏。

---

团队 × 成长 提升团队的整体能力——弥补技能差距、提高技术成熟度、共同学习。

计入：知识盘点（谁掌握什么、关键人员风险——如果没有这类盘点，请明确指出）；面向团队的技术分享或学习与发展（L&D）课程；团队真正从中吸取经验的深入复盘；能带来实际行为改变的回顾会议；团队参与开源项目；以学习为目标的 AI 工具日、黑客马拉松；涉及整个团队的架构评审；引入新的工程实践。

不计入：冲刺规划／交付站会（团队 × 影响）。团队社交活动（团队 × 联结）。

---

团队 × 影响 交付引擎——稳定执行、按时交付、创造实际价值。

计入：冲刺规划和目标设定（尤其是“始终保持绿色”——设定并跟踪少量有把握完成的目标）；冲刺评审和演示；聚焦于阻碍和交付进展的每日站会；与产品经理共同规划路线图；主动排除阻碍；发布后监测功能采用情况；协调处理事故；以业务理由为技术债务争取纳入路线图。

质量信号：稳定达成冲刺目标（体现“始终保持绿色”的执行纪律）比参加许多交付会议、却看不到任何目标跟踪模式，得分更高。

不计入：1:1。社交活动。

---

团队 × 联结 建立团队成员之间的纽带、信任、心理安全感和团队认同感。

计入：超越任务进度更新的团队会议（真诚分享、文化讨论）；团队专注日或异地团建；社交活动（游戏、午餐、志愿服务）；工程师分享自己关心之事的个人交流；共同庆祝已交付的工作；轻松有趣的黑客马拉松；共享的幽默频道、团队传统。

不计入：任务进度更新站会。只专注于工作冲刺的专注日。

---

组织 × 成长 为更广泛的组织提升能力——贡献的成果能超越团队本身。

计入：领导或实质性参与跨团队技术倡议；为团队以外的职位参与招聘评审；指导直属下属以外的人员；参与组织级流程建设（入职培训、职业发展阶梯、工程标准）；领导内部技术兴趣小组或实践社区；在内部全员会议或技术分享会上发言；帮助其他工程经理梳理问题。 不计入：参加（但不参与贡献）组织范围的会议。

---

组织 × 影响力 让团队和你自己在团队边界之外获得关注、信任并产生影响力。

计入：定期与工程团队之外的利益相关者沟通；主动帮助其他部门实现目标；向高级管理层展示团队成果；在路线图讨论中争取技术工作的支持；与领导者交流时使用业务术语（投资回报率、留存率、客户流失率）；参与组织层面的决策。

定位层级 — 记录工程经理（EM）目前所处的层级：

• 第 1 级（可见）：参加跨职能会议，在共享频道中露面
• 第 2 级（受认可）：人们会主动来找你，大家知道你乐于助人且有好奇心
• 第 3 级（受信任）：在其他部门开口之前，你就主动帮助他们实现目标——客户成功（CS）、质量保证（QA）、财务、人力资源（HR）。真正的组织信任正是在这个层级建立的。

不计入：团队内部交付。被动参加利益相关者会议。

---

组织 × 关系 在整个组织中广为人知、受人喜爱——在团队之外建立善意与盟友关系。

计入：“新成员规则”（每周有意与一位新成员约一次咖啡聊）；跨部门的非正式一对一交流；关注其他团队的公告并互动；真诚参与公司范围的社交活动；跟进从其他团队同事那里了解到的个人近况；主动给不太熟悉的人发私信。

不计入：外部职业人脉拓展（个人 × 关系）。带有业务目的的利益相关者管理（组织 × 影响力）。

---

步骤 5：为每个单元格打分

**原始分钟数：**每个单元格中已分类事件的总时长（一个事件涉及两个单元格时按比例拆分）

**加入 Slack 信号：**如果 Slack 数据显示存在有意义但未出现在日历上的活动，则根据其活跃程度，为每个单元格每月增加估算的 60–240 分钟。务必保守——宁可低估，也不要夸大。

归一化为整数（0–10）：

• 找出总分钟数最多的单元格 → 该单元格得 10 分
• 其他单元格：round((cell_minutes / max_minutes) × 10) — 四舍五入到最接近的整数
• 分钟数为 0 且没有 Slack 信号的单元格：得分 = 0
• **人员 × 关系的最低分：**如果 EM 每周都与直接下属进行一对一交流，且 Slack 私信显示出关怀或个人问候，则最低分为 5

质量调整（±1 分，在四舍五入前应用）：

• 如果 Slack 私信证实一对一交流纯粹是事务性的（没有关怀，也没有发展信号）：人员 × 成长下调 1 分，人员 × 关系维持最低分
• 如果日历中体现出明确的“始终保持绿色”纪律（稳定的冲刺规划和评审节奏）：团队 × 影响力上调 1 分
• 如果 Slack 显示经常与下属进行发展相关的私信交流（分享资源、讨论职业发展）：人员 × 成长上调 1 分
• 如果组织 × 影响力显示出第 3 级活动（主动帮助其他部门）：组织 × 影响力上调 1 分

行动建议检查 — 撰写建议前： 将每条建议的行动与日历和 Slack 中已显示的内容进行交叉核对。不要建议 EM 已经在做的事。如果日历显示每周都有一对一交流，Slack 中也有个人问候，就不要建议“在一对一交流中询问个人情况”。找出真正缺失的内容。

---

步骤 6：输出

驱动因素介绍（放在网格之前）

用简短、直白的英语说明这三列：

成长 — 为未来培养能力的活动：你自己的学习、培养工程师、构建团队技能、拓展组织知识。 影响力 — 现在就能带来成果的活动：可靠地交付产品、推动业务指标、提升可见度、做出能够落地的决策。 关系 — 建立关系的活动：与工程师个体、作为整体的团队，以及更广泛的组织建立关系。

想深入了解任何一列？查看网格后，询问“解释[成长 / 影响力 / 关系]”。

矩阵

用彩色方块让每个单元格一目了然，然后给出整数分数。表格中不要加警告或脚注。

颜色刻度：

• 🔴 0–2（严重缺口）
• 🟠 3–4（较弱）
• 🟡 5–6（中等）
• 🟢 7–8（良好）
• 💚 9–10（强）

## Your EM Grid — Last 30 Days

|          | Growth    | Impact    | Connection |
|----------|-----------|-----------|------------|
| **Self** | 🟠 4      | 💚 9      | 🔴 1       |
| **People**| 💚 9     | 🟠 3      | 🟡 5       |
| **Team** | 🔴 1      | 💚 10     | 🔴 2       |
| **Org**  | 🟠 3      | 🟠 3      | 🟢 7       |

表格下方只用一行列出数据来源，例如：“基于 43 种独特的会议模式，涵盖 178 个日历事件，以及 9 个频道和 7 个活跃私信会话中的 Slack 活动。”

模式诊断

用 2–3 句直接说明这种模式反映了哪种 EM。解读整体形态：

• 哪一行占主导？哪个驱动因素占主导？
• 这对团队、EM 的职业发展和组织意味着什么？
• 如果存在值得指出的矛盾或信号（例如 Self×Impact 异常偏高，可能意味着委派风险），请在此处点明。

符合要求的语气示例：

• “你处于执行模式——Team×Impact 占主导，其他几乎都很薄弱。你的团队能交付，但你没有投入精力培养他们、推动自身成长，或提升自己在组织中的影响力。”
• “People×Growth 表现强劲，说明你确实在投入。但 Team×Impact 较弱——交付很可能取决于团队自身的纪律性，而不是你的主动参与。”

要直接，并结合其实际分数具体说明。

最突出的 3 个盲点

针对分数最低且尚未由角色／背景因素解释的 3 个单元格（例如，2 人团队的 Team×Connection 不太可能很强，应以不同方式指出）：

• 单元格名称和分数
• **实践中缺少什么：**用一句话说明目前没有做什么，以及为何重要
• **本周的一项行动：**小而具体、能立即执行——阅读 references/suggested-actions.md，选择与背景最相关的方案。不要建议任何已能从日历或 Slack 中看出的事项。

可选：值得指出的一个信号

如果分数中有值得注意但不属于盲点的情况——例如 Self×Impact 异常偏高（可能存在委派风险），或 Org×Connection 强而 People×Connection 弱（更擅长向上管理，而非管理团队成员）等——用一句话指出这一点，作为需要留意的事项。

总分和最终评估

计算一个综合分数：12 个单元格的平均分，四舍五入到小数点后一位。

按以下格式呈现：

EM 总分：X.X / 10

然后用 2–3 句话进行最终评估——结合具体情况说明这个分数意味着什么，而不只是复述数字。基础能力强但忽视自我发展的 6.5 分，与各项表现都平庸的 6.5 分截然不同。点明具体形态：

• 真正发挥作用的方面（不要只列出高分，要说明它们为何重要）
• 如果有所改善，最能为其他方面带来连锁效应的一件事
• 展望未来：如果一切保持不变，3 个月后这张矩阵会是什么样？

语气示例：

“总分：5.8 / 10。你的交付和人员发展引擎运转稳健——这是根基。Team×Growth 是最具连锁影响的缺口：在 AI 转型期间，如果团队没有共同学习，质量就会悄然下滑，直到有人意识到问题。按照目前的节奏，3 个月后你依然能持续交付，但技能债会开始体现在代码审查质量，以及工程师对更难技术决策的信心上。”

数据说明（缺少 Slack 时）

如果未连接 Slack：

仅基于日历进行分析——如果你经常使用私信和频道，People×Connection、Org×Connection 和 Self×Growth 的评分可能偏低。连接 Slack 可获得更完整的情况。

如果使用了两个数据源，则无需添加说明。

---

语气

直接、具体、简洁。除驱动因素简介外，不要写开场白。不要用空洞的鼓励话语。包括矩阵、简短诊断、三个盲点和一个可选信号。所有内容控制在一屏内。