一个零依赖、零脚本的开发者画像分析 Skill

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

怎么用？

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

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

支持的参数：

| 参数 | 说明 | 默认值 | |------|------|--------| | repo_path | 仓库绝对路径 | 必填 | | authors | 指定分析的作者列表 | 全部贡献者 | | since | 开始日期（ISO 格式） | 仓库全部历史 | | until | 结束日期（ISO 格式） | 仓库全部历史 | | branch | 目标分支 | 当前活跃分支 |

一切的起源：能不能不装东西？

市面上的 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）。

它能看到什么？

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

| 维度 | 它在看什么 | |------|-----------| | 📝 提交习惯 | 你一天提交几次？每次改多少行？commit message 是认真写的还是随便糊的？ | | ⏰ 工作习惯 | 你是早起鸟还是夜猫子？周末在不在偷偷加班？最长连续写了几天代码？ | | 🚀 研发效率 | 你写的代码有多少后来又被删了？是不是在同一个文件上反复改来改去？ | | 🎨 代码风格 | commit message 有没有遵循 Conventional Commits？有没有关联 Issue？ | | 🔍 代码质量 | 修 bug 的提交占了多大比例？有没有动不动就甩一个巨型提交上来？ | | 📊 参与度指数 | 综合以上五项，衡量在 Git 上可见的活跃参与程度（0-100）。 |

扒出来的「真实画像」

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

🌙 深夜战士

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 命令前，都必须通过严格的白名单校验：

| 参数 | 校验规则 | |------|---------| | 仓库路径 | 必须是绝对路径，不含 ; \| & $ 等危险字符，且通过 git rev-parse验证为合法仓库 | | **作者名** | 白名单：^[a-zA-Z0-9 .-]+$（不含@，禁止邮箱输入），最长 128 字符 | | **日期** | 严格 ISO 格式：^[0-9]{4}-[0-9]{2}-[0-9]{2}$| | **分支名** | 白名单：^[a-zA-Z0-9/.-]+$，不含..` |

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

预览模式（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 上可见的参与度越高）：

| 信号 | 权重 | 逻辑 | |------|------|------| | 日均提交极低（<0.3） | 25% | 活跃天数内产出过低 | | 活跃天数占比低（<30%） | 20% | 时间跨度大但实际干活天数少 | | 代码净增长极低或为负 | 20% | 写的还没删的多 | | Commit message 敷衍（平均<15字符） | 15% | 不认真对待提交记录 | | 高流失率 + 高返工率 | 20% | 大量无效劳动 |

等级对照表：

| 分数 | 等级 | 建议 | |------|------|------| | 0-20 | 🏆 高度活跃 | 建议关注是否过劳 | | 21-40 | 💪 稳定参与 | 持续输出，继续保持 | | 41-60 | 😐 中等参与 | 有提升空间 | | 61-80 | 🤔 低参与度 | 建议了解是否有非代码贡献未被记录 | | 81-100 | ❓ 极低参与度 | 建议与当事人沟通了解全貌 |

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

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

综合评分的加权公式

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

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

生成的报告长什么样？

总览表

| 开发者 | 提交数 | 增/删行数 | 日均提交 | 周末% | 深夜% | Bug Fix% | 流失率 | 参与度 | 综合评分 | |--------|--------|-----------|----------|-------|-------|----------|--------|---------|----------| | Alice | 142 | +8, 230 / -2, 103 | 2.1 | 12.0% | 8.5% | 7.0% | 25.6% | 22 | 8.1 | | Bob | 67 | +15, 440 / -890 | 0.8 | 55.2% | 42.0% | 3.0% | 5.8% | 45 | 6.3 | | Carol | 4 | +84, 224 / -0 | 2.0 | 25.0% | 0.0% | 0.0% | 0.0% | 38 | 7.0 |

每个人的画像

每位开发者会拿到：

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

写在最后：数据不是审判

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

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

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

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

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

---

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

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

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