Who Is Actor

核心用法

Who Is Actor 是一款纯命令行驱动的开发者行为分析工具，无需安装任何依赖包或脚本。它通过原生 git log、git shortlog、git diff 等命令采集数据，结合标准 Unix 文本处理工具（cut、sort、awk、grep 等）进行本地统计，最终由 AI 生成六维度开发者画像报告。

用户只需用自然语言描述需求，如"分析 /path/to/project 仓库"、"对比 Alice 和 Bob 的研发效率"或"检查巴士因子风险"，系统即自动执行参数校验、数据收集、AI 分析和报告生成全流程。

六维评估体系

| 维度 | 权重 | 评估重点 |

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

| 提交习惯 | 15% | 频率稳定性、单次变更规模、提交信息质量 |

| 工作习惯 | 15% | 作息规律性、深夜/周末占比、连续产出能力 |

| 研发效率 | 25% | 净代码增长率、返工率、代码流失率 |

| 代码风格 | 15% | Conventional Commits 合规性、模块化专注度 |

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

| 参与度指数 | 10%（逆向）| 可见活跃程度（仅限宏观参考，禁用于绩效决策）|

显著优点

1. 绝对零依赖：不安装 pip/npm 包，不执行任何脚本，仅需系统预装的 git 和 Unix 工具
2. 安全优先设计：严格命令白名单（仅只读 git 子命令）、多层输入验证、自动敏感信息脱敏（API Key、私钥、连接串等）
3. 隐私保护：完全不采集开发者邮箱，仅使用 %an 作者名字段
4. 透明可控：支持 Dry-Run 模式预览所有待执行命令，用户确认后才执行
5. 多语言自然语言交互：支持中英日韩德法西等语言直接下达分析指令
6. 直言不讳的评估风格：模拟资深 Tech Lead 的年度代码评审，数据驱动、不粉饰、有建设性

潜在缺点与局限性

1. 数据盲区：无法捕捉代码评审、架构设计、技术讨论、团队指导等非 commit 工作
2. 同名混淆：同一人的不同名字变体（未配置 .mailmap）会被视为多个开发者
3. 时区敏感：工作时段分析依赖提交记录时区，跨时区协作可能产生误判
4. 语义局限：提交信息关键词匹配（如 fix/feat）可能误报，无法真正理解代码变更意图
5. 大型仓库性能：全历史分析可能耗时较长，建议限定日期范围
6. Windows 体验：需依赖 Git Bash 或 WSL，原生 Windows 命令行不完全兼容

适合人群

• 技术团队负责人希望客观了解团队协作模式与个体工作特征
• 开源项目维护者评估贡献者分布与巴士因子风险
• 工程效能团队寻找无侵入式的代码库健康度诊断工具
• 开发者自我复盘，优化个人提交习惯与代码交付节奏

重要禁忌：本工具明确禁止用于绩效评定、裁员决策、薪酬调整等 HR 场景。参与度指数仅为宏观参考，高/低分均不直接等同于"偷懒"或"高效"。

常规风险

• 误读风险：六维分数若脱离上下文单独引用，可能造成对开发者的片面评价
• 隐私边界：虽然已屏蔽邮箱，但作者姓名与提交模式仍可能间接识别个人
• 过度优化：开发者若刻意"刷分"（如拆分无意义提交），可能反噬代码质量
• 合规注意：部分司法管辖区对员工监控有严格限制，使用前建议告知团队并获得共识

核心用法

who-is-actor 是一款纯文档型 Skill，无需安装任何依赖包或执行自定义脚本，仅通过系统预装的 git 命令及标准 Unix 文本工具（cut、sort、awk、grep 等）采集数据，经 AI 解读后生成开发者画像报告。用户只需用自然语言描述需求，如"分析 /path/to/repo 仓库的开发者提交习惯"或"对比 Alice 和 Bob 的研发效率"即可触发。

执行流程分为四步：确认分析参数（仓库路径、目标作者、日期范围、分支）→ 通过白名单内的只读 git 命令采集数据 → AI 基于六维模型（提交习惯、工作习惯、开发效率、代码风格、代码质量、参与度指数）评分 → 生成包含总表、个人雷达图、团队对比及巴士因子风险提示的结构化 Markdown 报告。

显著优点

安全架构严谨：通过 CLS-Certify A 级认证（82分），采用完整的输入验证规则（路径绝对化、危险字符过滤、正则白名单）、命令白名单机制（仅限 git log/shortlog/diff --stat/rev-parse 只读操作）、Dry-run 预览模式，有效阻断命令注入攻击。隐私保护设计完善：不采集开发者邮箱，commit message 仅本地统计长度与关键词，完整文本不发送至 AI，且内置 API 密钥、私钥、连接字符串等敏感模式的自动脱敏。

零依赖与跨平台：无 package.json、requirements.txt 等依赖文件，不安装任何 pip/npm 包，仅需系统预装 git 及 Unix 工具，macOS/Linux 原生支持，Windows 可通过 Git Bash 或 WSL 运行。

评估体系专业：六维雷达模型覆盖技术协作全链路，评分标准量化（1-10分），加权计算综合得分；报告风格定位为"资深 Tech Lead 的年度 Code Review"——直接、不粉饰，同时提供可落地的改进建议。

潜在缺点与局限性

数据维度单一：所有分析仅限于 Git 提交记录，无法捕捉代码评审、架构设计、技术讨论、团队指导等非代码贡献。参与度指数明确声明"高得分≠摸鱼，低得分≠高效"，存在误判风险。

名称归一化不足：同一开发者的不同 Git 配置名（如"Zhang San"与"san.zhang"）会被视为多人，虽文档提及 .mailmap 支持，但未实现自动合并。

大型仓库性能：未内置分阶段采集或进度指示机制，超大型仓库（百万级提交）可能面临命令执行超时。

时间分析精度：依赖提交记录时区，跨时区团队的工作时段分析可能存在偏差。

适合人群

• 技术团队负责人：需定期复盘团队效能分布、识别巴士因子风险
• 开源项目维护者：评估核心贡献者活跃度与代码质量趋势
• 研发效能工程师：建立数据驱动的代码协作基线
• 个人开发者：自我诊断提交习惯与代码风格改进空间

常规风险

伦理误用风险：参与度指数严禁用于绩效考核、裁员决策、薪酬调整，但工具本身无法技术性阻断此类滥用，需依赖使用者的组织自律。

过度解读风险：AI 生成的"犀利点评"若脱离上下文传播，可能对开发者造成不当评价压力，建议团队内透明使用并提前告知成员。

数据残留风险：虽执行过程脱敏，但生成的 Markdown 报告文件需使用者自行妥善保管，避免敏感统计信息外泄。