你有没有想过，你的队友到底是在深夜灵感爆发，还是在白天假装忙碌？Git 记录里，藏着每个人的真实画像。

作为 Skill 插件，直接在对话中触发：

"分析一下这个仓库每个人的研发效率" "帮我看看团队成员的工作习惯" "对比一下 Alice 和 Bob 的代码质量" "看看团队的参与度" 

支持的参数：

市面上的 Git 分析工具，要么让你装 Python 包，要么让你跑 Node 脚本，要么直接甩一个 Docker 镜像。我只是想看看谁在划水，结果光配环境就花了半小时。

我心想：Git 本身就是最好的数据库啊。 git log 里有提交时间、作者、改动行数、文件列表、commit message……这些数据足够画出一个人的完整工作画像了。为什么非要装额外的东西？

于是 who-is-actor 诞生了 —— 一个零依赖、零脚本的 Git 仓库开发者画像分析 Skill。它只用原生 git 命令和标准系统工具（cut、sort、awk、grep 等 —— 大多数系统已预装）采集数据（所有输入经过严格校验，不采集邮箱），然后交给 AI 来解读，生成一份毫不留情的六维度体检报告。

"零依赖"的意思是： 不装 pip 包、不装 npm 模块、不跑自定义脚本。但它需要这些标准系统工具已在你的机器上：git、cut、sort、uniq、awk、grep、sed、wc、head（macOS / Linux 默认自带，Windows 请用 Git Bash 或 WSL）。

六个维度，把一个开发者扒得底朝天：

我用它分析了团队仓库，看到了一些很真实的画面：

Peak Hour: 23:00 Weekend Ratio: 78.6% Late Night Ratio: 57.1% Churn Rate: 43.7% 

这位老兄几乎只在深夜和周末提交代码。你以为他在偷懒？不，他可能只是把白天留给了会议，然后在万籁俱寂的时候才能安静地写代码。

但数据也暴露了一些问题：代码流失率 43.7%，意味着写下的代码有近一半后来又被删了。深夜写代码容易"先写再想"—— 写完不满意，推倒重来。这不一定是坏事，但如果长期如此，也许该看看白天的时间去哪了。

Total Lines Added: 84,224 Large Commit Ratio: 50.0% Ownership Ratio: 100.0% Churn Rate: 0.0% 

单次提交平均两万行？别慌，这是做项目初始化和架构搭建的人。他拥有仓库中 100% 的文件所有权，写下的每一行代码都还活着。搞基建的人就是这样，一砖一瓦都是实打实的。

Weekend Ratio: 66.7% Churn Rate: 3.8% Rework Ratio: 7.7% 

三分之二的提交在周末，但代码流失率只有 3.8%。这是一个想清楚再动手的人 —— 每次提交都目标明确，几乎不做无用功。如果深夜战士是"先开枪再瞄准"，这位就是"瞄准了才开枪"。

Total Commits: 1 Active Span: 1 day 

只出现过一次，留下一个提交就消失了。但别小看这一个 commit —— 也许是修了一个关键 bug，也许是补上了一段缺失的文档。每个 commit 背后都是一个真实的人，在某个时刻打开了编辑器，读懂了代码，然后伸出了手。

整个分析流程像一条极简流水线：

用户触发 → 确认参数 → 原生 git 命令采集数据 → AI 六维度分析 → 生成报告 

没有 Python，没有 Node，没有 pip install，没有 npm install。所有数据采集仅靠这些命令：

# 贡献者概览（不采集邮箱） git shortlog -sn --all # 提交时间分布（分析工作习惯） git log --author="xxx" --pretty=format:"%aI" | cut -c12-13 | sort | uniq -c # 增删行统计（分析研发效率） git log --author="xxx" --pretty=tformat: --numstat | awk '{ add += $1; subs += $2 } END { printf "added: %s, deleted: %s\n", add, subs }' # Bug Fix 检测（分析代码质量） git log --author="xxx" --grep="fix\|bug\|hotfix" --oneline -i | wc -l # Conventional Commits 检测（分析代码风格） git log --author="xxx" --pretty=format:"%s" | grep -cE "^(feat|fix|chore|docs|style|refactor|test|perf|ci|build)(\(.+\))?:"

AI 拿到这些原始数据后，负责解读、计算指标、打分、生成点评。

命令白名单机制： 本 Skill 仅允许执行预定义的 git 只读命令（ git log 、 git shortlog 、 git diff --stat 、 git rev-parse ），严禁任何写入操作（ git push/commit/merge ）、非 git 命令（ curl/python/node ）、文件写入（ > / >> ）和网络操作（ git fetch/pull/clone ）。管道 | 仅允许连接 cut 、 sort 、 uniq 、 awk 、 grep 、 wc 、 sed 、 head 等只读文本处理工具。

输入校验：

所有用户输入在拼接到 shell 命令前，都必须通过严格的白名单校验：

校验失败的参数会被拒绝或降级处理，绝不会未经验证直接执行。

预览模式（Dry-Run）： 首次使用时推荐说"先列出要执行的命令，不要运行"，代理会展示所有将要执行的命令供你审查，确认无误后再实际执行。

敏感数据保护： 提交消息默认仅在本地进行统计处理（长度计算、关键词匹配），完整的提交消息文本不会发送给 AI 模型，只发送聚合后的指标。此外，所有文本在离开本地环境前会自动脱敏以下模式：API 密钥、令牌、AWS 密钥、私钥、数据库连接字符串等。详见 SKILL.md 中的"Sensitive Data Filtering Rules"。

仓库作用域限制： 代理仅访问用户提供的特定仓库路径，不会遍历父目录或访问仓库以外的文件系统。

执行验证协议： 由于本技能是纯指令型（无可执行代码），安全规则依赖代理正确执行。首次使用前，建议在测试仓库上运行验证：1) 使用 dry-run 确认所有命令在白名单内；2) 故意输入无效值（含 ; 的路径、含 @ 的作者名）验证拒绝行为；3) 确认代理只发送聚合指标而非原始提交消息。详见 SKILL.md 中的"Enforcement Verification Protocol"。

此外，本工具不采集开发者邮箱，所有 git 命令仅使用作者名（ %an ）标识开发者。

综合五个信号，加权计算出 0-100 分（越低代表 Git 上可见的参与度越高）：

等级对照表：

重要提示： 此指数仅基于 Git 提交记录计算，无法反映代码评审、架构设计、技术讨论、团队指导等不产生提交记录的工作。高分不等于"不努力"，低分也不等于"高效"。

⚠️ 用途限制： 此指数仅供团队协作模式参考，严禁直接用于绩效考核、裁员决策、薪酬调整等人事决定。

综合评分 = 提交习惯 × 15% + 工作习惯 × 15% + 研发效率 × 25% + 代码风格 × 15% + 代码质量 × 20% + (100 - 参与度指数) / 10 × 10% 

研发效率权重最高（25%），因为写出有效代码才是硬道理。代码质量其次（20%），因为写得快但 bug 多等于白写。

每位开发者会拿到：

1. 数据仪表盘 — 六维度关键指标一目了然
2. AI 点评 — 严肃、直接，好就是好，差就是差
3. 改进建议 — 针对缺点给出具体可执行的建议
4. 六维雷达评分 — 各维度 1-10 分
5. 一句话总结 — 一句犀利的话概括此人

必须坦诚地说：这个工具不是用来搞绩效考核的。

那个凌晨三点提交代码的同事，也许比任何人都更热爱这个项目；那个 commit message 只写 "fix" 的人，也许正在争分夺秒地修复一个线上事故；那个只贡献了一个提交的人，也许是花了整整一周才理解了代码才敢动手。

参与度指数高分的人，可能只是在做那些 Git 记录不了的事 —— 设计方案、技术评审、帮新人答疑、在白板前画了一下午的架构图。

写这个工具的初心，是想透过冰冷的 Git 记录，看到背后一个个真实的、有温度的人。看到他们的工作节奏，理解他们的习惯，在必要时帮助他们 —— 比如发现某人连续深夜加班，也许该找他聊聊是不是遇到了什么困难。

代码会说话，但只有用心听，才能听到正确的答案。

技术栈：原生 Git + AI —— 就这么简单

开源协议：MIT —— 拿去用，拿去看看你的团队

⚠️ 参与度指数仅基于 Git 提交数据，不反映非代码贡献，请勿作为绩效考核的唯一依据