Who Is Actor

核心用法

Who Is Actor 是一款零依赖的 Git 仓库开发者分析技能，无需安装任何脚本或依赖包，仅通过原生 git 命令（git log、git shortlog、git diff --stat 等）采集数据，由 AI 完成多维度解读与评估。支持自然语言触发，用户可直接用中英文等多语言描述需求，如"分析一下这个仓库的开发者提交习惯"或"对比 Alice 和 Bob 的研发效率"。

六维评估体系

| 维度 | 权重 | 核心指标 |

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

| 提交习惯 | 15% | 频次、单次规模、消息质量、合并提交占比 |

| 工作习惯 | 15% | 工时分布、周末/深夜编码比例、连续输出稳定性 |

| 开发效率 | 25% | 净代码增长率、返工率、文件修改集中度 |

| 代码风格 | 15% | Conventional Commits 合规率、Issue 关联度 |

| 代码质量 | 20% | Bug fix 占比、Revert 频率、大提交比例 |

| 参与度指数 | 10%（逆序） | 活跃天数、日均产出、消息认真度 |

输出包含：总览表格、个人雷达图、直言不讳的 AI 评语、针对性改进建议、团队对比排名、Bus Factor 风险预警。

显著优点

• 零门槛部署：纯 git CLI 采集，无 Python/Node 依赖，无网络请求
• 隐私优先设计：明确禁止采集邮箱（%an 替代 %ae），authors 参数拒收 @ 符号
• 安全白名单机制：仅允许 4 类只读 git 子命令，所有输入经严格正则校验，彻底阻断命令注入
• 多语言自然交互：支持中英日德法等 8 种语言的自然语言描述
• 伦理内置：参与度指数强制附加"禁止用于绩效考核/裁员/调薪"的醒目警示

潜在局限

• 数据盲区：无法捕捉 Code Review、架构设计、技术讨论、带教等非代码贡献
• 时区与身份歧义：跨时区团队的工作时段分析可能失真；同一开发者不同用户名需手动 .mailmap 统一
• 大仓库性能：全历史分析可能耗时较长，需通过 since/until 参数裁剪
• AI 解读方差：评分标准虽量化，但最终雷达分数依赖 AI 对原始数据的综合判断
• 文化敏感性："直言不讳"风格在部分组织可能引发人际摩擦

适合人群

• 技术 Leader：快速掌握团队代码贡献分布与协作健康度
• 开源维护者：识别核心贡献者与单点故障风险
• 工程师自我复盘：客观审视个人编码习惯与改进空间
• 敏捷教练：用数据支撑团队流程优化讨论

常规风险

• 误用为考核工具：尽管文档多次警示，仍有被管理层曲解为绩效依据的风险
• 隐私边界争议：即使不采集邮箱，开发者姓名与工时模式的关联仍可能引发被监视感
• 数据采样偏差：以 commit 量为 proxy 会系统性地低估重构、测试、文档等"低 commit 密度"高价值工作
• 心理安全冲击："无保留直言"的报告风格若未经团队共识，可能破坏心理安全感
• 命令注入残余风险：若 AI agent 绕过白名单或校验逻辑被击穿，仍存在理论上的执行面攻击面

核心用法

who-is-actor 是一款面向技术团队的开发者行为分析 Skill，用户仅需以自然语言描述需求（如"分析一下 /path/to/project 这个仓库"或"对比 Alice 和 Bob 的提交习惯"），即可触发完整的仓库分析流程。Skill 通过原生 git log、git shortlog、git diff --stat 等只读命令采集数据，无需安装任何依赖或执行外部脚本，AI 负责对原始数据进行六维度解读并生成结构化 Markdown 报告。

核心功能包括：贡献者概览、个人六维雷达评分（提交习惯/工作习惯/研发效率/代码风格/代码质量/参与度指数）、团队横向对比、巴士因子风险提示。报告风格定位为"资深 Tech Lead 的 Code Review"——直接、不避讳、数据驱动，同时提供可落地的改进建议。

显著优点

1. 零攻击面设计：纯 Markdown 文档型 Skill，无代码执行、无依赖安装、无网络请求，从根本上消除供应链攻击和脚本注入风险
2. 严格的命令白名单：仅允许 4 类预定义的只读 git 子命令，禁止任何写入操作、网络操作或非 git 命令
3. 多层输入验证：仓库路径、作者名、日期、分支名均通过正则白名单校验，拦截 ; | & $ > 等危险字符，防止命令注入
4. 隐私优先：明确不采集开发者邮箱地址（使用 %an 而非 %ae），符合 GDPR 数据最小化原则
5. 伦理使用声明：参与度指数附带完整限制说明，明确禁止用于 HR 决策，体现负责任的 AI 使用态度
6. 多语言自然语言交互：支持中英日韩及欧洲主要语言，降低使用门槛

潜在局限

1. 数据来源单一：仅基于 Git 提交记录，无法捕捉代码评审、架构设计、技术沟通等非代码贡献
2. 同名作者问题：同一开发者若使用不同 Git 配置姓名，会被识别为多个独立贡献者（可通过 .mailmap 缓解）
3. 时区分析偏差：跨时区团队的工作时间分析可能受提交记录时区影响
4. 大型仓库性能：无日期范围限制的完整历史分析可能在超大型仓库上执行较慢
5. 主观评分体系：六维度 1-10 评分虽有数据支撑，但仍包含 AI 的 interpretive judgment，不同团队需校准理解

适合人群

• 技术团队 Lead 或 Manager，需要了解团队协作模式和个体工作习惯
• 开源项目维护者，评估贡献者活跃度和巴士因子风险
• 新加入的工程师，快速了解团队代码风格和协作规范
• 进行技术债务评估或研发效能改进的咨询师

常规风险

• 误读风险：参与度指数高 ≠ 摸鱼，低 ≠ 高效——使用者需充分理解数据局限性
• 团队信任风险：建议在团队内透明使用该工具，提前告知成员分析目的
• 命令注入残余风险：尽管有多层验证，用户仍需确保 AI agent 严格执行验证逻辑，不绕过检查