Who Is Actor

核心用法

Who Is Actor 是一款零依赖的 Git 仓库开发者分析工具，完全基于原生 git 命令（git log、git shortlog、git diff --stat 等）采集数据，无需安装任何脚本或依赖包。用户只需提供仓库绝对路径，即可触发对开发者提交习惯、工作节律、开发效率、代码风格、代码质量和参与度指数的六维深度分析。

使用方式极为简洁：通过自然语言指令如 "Analyze the repository at /path/to/project" 或 "Profile developers since 2024-01-01" 即可启动。支持按作者、时间范围、分支等维度筛选，最终输出包含汇总表格、个人雷达图、团队对比及 Bus Factor 风险预警的结构化 Markdown 报告。

显著优点

安全架构严谨：采用严格的命令白名单机制，仅允许 4 类只读 Git 子命令，全面禁止写操作、网络操作及任意 shell 命令。所有用户输入（路径、作者名、日期、分支）均通过正则白名单验证，从源头杜绝命令注入风险。

隐私保护到位：设计层面强制排除邮箱采集，仅用 %an（作者名）而非 %ae（作者邮箱），git shortlog 使用 -sn 而非 -sne，报告输出中绝不包含任何邮件地址。

零运维成本：无需 Python、Node 等运行时环境，无 pip/npm 安装步骤，纯 Git CLI 驱动，适用于任何具备 Git 的环境。

评价体系专业：六维评分体系（提交习惯、工作习惯、开发效率、代码风格、代码质量、参与度指数）覆盖开发者行为的完整切面，AI 评语风格定位为"资深 Tech Lead 的年度 Code Review"——严肃直接、有据可依、对事不对人。

潜在缺点与局限性

数据盲区明显：Git 记录无法捕获代码评审、架构设计、技术讨论、团队指导等非代码贡献。参与度指数明确标注"高得分≠摸鱼，低得分≠高效"，存在较大解读弹性。

时区与身份识别问题：提交时间依赖 commit 记录中的时区信息，跨时区协作可能扭曲工作节律分析；同一开发者若使用不同 Git 配置姓名，会被识别为多个独立个体（虽可通过 .mailmap 缓解）。

大型仓库性能瓶颈：全历史扫描可能耗时较长，虽建议通过日期范围限制，但仍缺乏增量分析或采样机制。

伦理使用依赖自律：工具内置"禁止用于 HR 决策"的声明，但技术上无法强制约束使用场景，存在被滥用于绩效评估或裁员决策的风险。

适合人群

• 技术团队负责人希望客观了解团队协作模式与个体工作特征
• 开源项目维护者评估核心贡献者分布与 Bus Factor 风险
• 开发者自我复盘，寻求具体可操作的代码实践改进方向
• 工程效能团队作为定性讨论的辅助数据参考（非决策依据）

常规风险

| 风险类型 | 具体表现 | 缓解措施 |

|---------|---------|---------|

| 命令注入 | 恶意构造的路径或参数突破白名单限制 | 严格的输入验证与正则白名单，验证失败立即终止 |

| 信息泄露 | 意外采集或输出开发者邮箱地址 | 设计层面禁用 `%ae` 与 `-sne`，作者参数拒绝 `@` 符号 |

| 误用决策 | 将参与度指数直接用于绩效考核或裁员 | 报告首页与指标说明中反复强调伦理限制，建议团队透明沟通 |

| 数据误读 | 忽略非代码贡献，对远程/兼职开发者形成偏见 | 六维评价与改进建议均附上下文说明，强调"了解全貌后再判断" |

| 心理安全 | 直言不讳的评语风格可能造成开发者不适 | 明确"Critique the work, not the person"原则，同步提供建设性改进路径 |

核心用法

who-is-actor 是一款纯文档型 Git 仓库分析 Skill，无需安装任何依赖或运行脚本。用户只需指定仓库绝对路径，即可触发 AI 代理执行预定义的原生 Git 命令（git log、git shortlog、git diff --stat 等），采集开发者提交记录后由 AI 进行六维度量化评估。

典型调用方式：

• Analyze the repository at /path/to/my-project
• Profile developers in /path/to/repo since 2024-01-01

输出内容： Markdown 格式结构化报告，包含汇总表格、个人六维雷达图评分（1-10 分）、团队横向对比、Bus Factor 风险预警及改进建议。

---

显著优点

1. 零依赖安全架构：不安装 Python/Node 包，不执行自定义脚本，仅使用系统原生 Git 命令，彻底消除供应链攻击风险。

2. 严格的安全防护：

• 输入白名单验证：仓库路径、作者名、日期、分支名均经正则过滤，禁止危险字符
• 命令白名单限制：仅允许 4 类只读 Git 子命令，明确禁止写入操作、网络操作及非 Git 命令
• 隐私保护：全程使用 %an（作者名），不采集邮箱地址

3. 六维度专业评估：提交习惯、工作节律、开发效率、代码风格、代码质量、参与度指数，提供可量化的改进路径。

4. 伦理设计：明确声明参与度指数不作为绩效/裁员/调薪依据，强调"评判工作而非人"。

---

潜在缺点与局限性

1. 数据盲区：Git 记录无法捕获代码评审、架构设计、技术讨论、团队指导等非代码贡献，可能误判专注其他工作的资深开发者。

2. 同名合并问题：同一开发者可能因不同 Git 配置显示为多个名称，需依赖 .mailmap 手动统一，Skill 本身不提供自动合并。

3. 时区与工作时间：跨时区团队的工作时段分析可能失真；远程办公者的"深夜提交"未必代表过劳。

4. 语言/框架差异：不同技术栈的"合理提交粒度"标准不同（前端配置改动 vs. 内核驱动），统一评分可能欠公平。

5. 大型仓库性能：未限制日期范围时，历史数据量大的仓库可能导致命令执行时间较长。

---

适合人群

• 技术团队负责人：需要客观了解团队协作模式、识别知识孤岛
• Engineering Manager：希望获得数据支撑的 1:1 沟通切入点（非考核依据）
• 开源项目维护者：评估贡献者活跃度与代码审查重点
• 个人开发者：自我复盘工作节律与提交习惯

不适合：直接用于绩效考核、裁员决策、薪酬调整的 HR 或管理层。

---

常规风险

| 风险类型 | 等级 | 说明 |

|---------|------|------|

| 命令注入 | 极低 | 完善的输入验证与白名单机制，但未验证 AI 代理是否严格执行 |

| 隐私泄露 | 极低 | 明确不采集邮箱，但用户需确认实际执行符合规范 |

| 误读误判 | 中等 | 参与度指数易被断章取义，需配合完整免责声明使用 |

| 团队信任 | 中等 | 秘密使用可能破坏心理安全感，建议提前透明沟通 |

关键建议：分析前告知团队成员，将报告仅作为改进协作流程的参考，结合面谈理解完整上下文。