Who Is Actor

核心用法

Who Is Actor 是一款零依赖的 Git 仓库开发者分析技能，无需安装任何软件包或运行脚本，仅通过原生 git 命令采集数据，由 AI 进行六维度综合评估。

使用方法：直接向 AI 代理发送分析指令，如 "Analyze the repository at /path/to/project" 或 "Profile developers since 2024-01-01"，支持指定作者、日期范围、分支等参数。

数据收集流程：
1. 验证仓库路径、作者名、日期、分支等输入参数（严格防注入）
2. 执行白名单内的只读 git 命令：git shortlog -sn、git log、git diff --stat
3. 采集提交频率、代码增删、时间分布、文件类型、修复/回退提交等 20+ 指标

六维评估体系：

• 提交习惯（频率、消息质量、大提交占比）
• 工作习惯（作息规律、周末/深夜比例）
• 开发效率（净增长、返工率、代码流失率）
• 代码风格（规范提交、issue 引用、专注度）
• 代码质量（bug 修复率、回退频率、测试覆盖信号）
• 参与度指数（综合活跃度，0-100 反向计分）

---

显著优点

1. 真正零依赖：不安装 Python/Node 包，不执行任何外部脚本，纯 git CLI 即可运行
2. 隐私优先设计：全程不采集邮箱地址，仅用 %an 作者名，符合数据保护要求
3. 严格安全管控：命令白名单机制 + 多重输入验证（路径、作者、日期、分支），有效防御命令注入
4. 多语言场景适配：支持中文触发词（"代码分析""开发者画像"），国际化友好
5. 输出结构完整：含汇总表、个人雷达图、AI 评语、改进建议、团队对比、bus factor 风险警报
6. 伦理内置：参与度指数附带明确使用限制声明，禁止用于绩效/裁员/薪酬决策

---

潜在缺点与局限

1. 数据盲区：无法捕获代码评审、架构设计、技术讨论、团队指导等非提交工作；同一人的多个姓名变体需手动统一（.mailmap）
2. 指标片面性：参与度指数本质为"可见活跃度"，高得分可能反映过度提交或工作方式问题，而非效率低下
3. 时区误差：提交时间基于提交者本地时区，跨时区团队的工作时段分析可能失真
4. 大仓库性能：未限制历史深度时，全量 log 分析可能耗时较长
5. 评判主观性：六维度评分标准（如"良好提交消息"定义）依赖 AI 解释，不同模型可能有差异
6. 伦理依赖用户自律：工具内置警告但无法阻止滥用，高风险场景（如管理者用于裁员）缺乏技术拦截

---

适合人群

• 技术团队负责人：了解成员协作模式，识别流程改进点
• 工程效能团队：作为数据参考辅助 retrospectives
• 开源项目维护者：分析贡献者分布，评估 bus factor 风险
• 个人开发者：自我复盘提交习惯与代码质量

明确不适合：需要精确绩效量化的人力资源部门、寻求"裁员名单"的管理者、期望替代 360 度评估的场景。

---

常规风险

| 风险类型 | 说明 | 缓解措施 |

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

| 命令注入 | 恶意构造的 repo_path/author 可能执行任意代码 | 严格白名单验证 + 正则过滤 |

| 隐私泄露 | git log 默认包含邮箱 | 强制使用 `-sn` 而非 `-sne`，禁用 `--author` 邮箱匹配 |

| 误判风险 | 参与度指数被断章取义用于 HR 决策 | 报告多处醒目标注限制，用户承担伦理责任 |

| 数据误读 | 低参与度得分被误解为"懒惰" | 强调非代码贡献未被计入，建议面谈核实 |

| 团队信任损害 | 秘密分析引发成员反感 | 建议提前告知所有被分析者（透明度原则）|

核心用法

who-is-actor 是一款通过原生 git 命令分析代码仓库开发者行为模式的 AI Skill。用户只需指定仓库路径、可选时间范围和目标开发者，AI 代理即执行预定义的白名单命令采集数据，生成包含六维雷达评分（提交习惯、工作习惯、开发效率、代码风格、代码质量、参与度）的结构化报告。

显著优点

• 零依赖安全架构：不安装任何第三方包或脚本，完全基于本地 git CLI 执行只读操作，彻底规避供应链攻击风险。
• 严格的安全设计：命令白名单机制仅允许 git log、git shortlog、git diff --stat 等只读操作；输入参数经过多层正则验证，有效防御命令注入。
• 隐私优先：明确不采集开发者邮箱，所有分析基于 %an（作者名）而非 %ae（作者邮箱），符合 GDPR/CCPA 数据最小化原则。
• 多维量化评估：将抽象的「代码贡献」转化为 1-10 分的六维雷达图，支持跨开发者对比与团队健康度诊断。
• 伦理使用声明：明确限制「参与度指数」不得用于绩效考核、裁员等 HR 决策，体现负责任的 AI 设计。

潜在缺点与局限性

• 数据盲区：Git 记录无法捕捉代码评审、架构设计、技术讨论、团队指导等非 commit 工作，高参与度指数≠高效，低指数≠低产出。
• 来源可信度限制：作者为个人开发者（reky），无组织背书（T3 级别），长期维护能力和项目透明度需持续观察。
• 作者身份识别误差：同一开发者可能因不同机器配置产生多个名字变体（需依赖 .mailmap 手动统一），可能稀释或分散个体画像。
• 时区与作息误判：跨时区协作场景下，基于 commit 时间的工作习惯分析可能产生偏差。
• 大仓库性能风险：未限制历史深度时，全量 git log 命令在大型 monorepo 上可能耗时较长。

适合人群

• 技术团队 Lead 进行周期性代码审查与协作模式诊断
• 开源项目维护者了解贡献者分布与 bus factor 风险
• 工程效能团队作为补充性数据参考（非决策依据）

常规风险

• 误用风险：尽管文档明确禁止，但六维评分仍可能被管理层误读为「绩效排名」，引发团队信任危机。
• 隐私边界：虽然不采集邮箱，但开发者真实姓名与代码行为模式的关联仍可能构成变相画像，建议在团队内提前告知分析意图。