谁是演员——Git仓库开发者画像技能

🔗项目仓库： https://github.com/wscats/who-is-actor

零安装依赖，零脚本。纯粹通过原生git命令和标准Unix文本工具（cut、sort、awk、grep等——这些在大多数系统上已存在）收集数据，通过AI解读，为每位开发者生成一份严肃、直接、不留情面的成绩单。

“零依赖”说明：此技能不安装任何东西——没有pip包，没有npm模块，没有自定义脚本。但它确实需要主机上存在以下标准系统二进制文件：git，cut，sort，uniq，awk，grep，sed，wc，head。这些命令几乎预装在所有类Unix系统（macOS、Linux）上。在Windows上，请使用Git Bash或WSL。

💬 自然语言（推荐）

您无需记忆任何命令或参数——只需用任何语言描述您的需求：

英语

💬 "Analyze the repository at /path/to/my-project"
💬 "Profile all developers in this repo"
💬 "Who are the most active contributors in /path/to/my-project?"
💬 "Compare commit habits of Alice and Bob"
💬 "Show me the code quality report for this project since 2024-01-01"
💬 "What does each developer's work pattern look like on branch main?"
💬 "Give me an honest review of every contributor's strengths and weaknesses"
💬 "Is there a bus-factor risk in /path/to/my-project?"

中文

💬 "分析一下 /path/to/my-project 这个仓库"
💬 "帮我看看这个项目里每个开发者的提交习惯"
💬 "对比一下 Alice 和 Bob 的研发效率"
💬 "生成这个仓库的开发者画像报告"
💬 "这个项目的代码质量怎么样？"
💬 "从 2024 年 1 月开始，分析 main 分支的提交记录"
💬 "团队里谁的代码风格最好？谁需要改进？"
💬 "看看这个仓库有没有巴士因子风险"

日语

💬 "このリポジトリの開発者を分析してください /path/to/my-project"
💬 "各開発者のコミット習慣を比較してください"
💬 "このプロジェクトのコード品質レポートを作成してください"
💬 "チームの開発効率を評価してください"

韩语

💬 "이 저장소의 개발자 프로필을 분석해 주세요 /path/to/my-project"
💬 "각 개발자의 커밋 습관을 비교해 주세요"
💬 "이 프로젝트의 코드 품질 보고서를 만들어 주세요"
💬 "팀의 개발 효율성을 평가해 주세요"

西班牙语

💬 "Analiza el repositorio en /path/to/my-project"
💬 "Compara los hábitos de commit de todos los desarrolladores"
💬 "Dame un informe de calidad del código de este proyecto"
💬 "¿Quién es el desarrollador más activo del equipo?"

法语

💬 "Analyse le dépôt situé à /path/to/my-project"
💬 "Compare les habitudes de commit de chaque développeur"
💬 "Génère un rapport de qualité du code pour ce projet"
💬 "Qui est le contributeur le plus actif de l'équipe ?"

德语

💬 "Analysiere das Repository unter /path/to/my-project"
💬 "Vergleiche die Commit-Gewohnheiten aller Entwickler"
💬 "Erstelle einen Code-Qualitätsbericht für dieses Projekt"
💬 "Wer ist der aktivste Entwickler im Team?"

⚙️ 参数

你将获得：一份结构化的Markdown报告，包含总结表格、每位开发者档案（六维雷达图评分、优势/劣势、改进建议）、团队对比以及巴士因子风险提示。

安全规范

所有shell命令参数在执行前必须经过严格验证，以防止命令注入攻击。

试运行模式（首次使用推荐）

在执行任何命令之前，代理应提供试运行模式该模式需：

1. 根据以下规则收集并验证所有参数
2. 构建完整的shell命令列表，这些命令将会
3. 被执行
4. 在不执行任何命令的情况下，将每条命令打印给用户审阅

等待用户明确批准后再进行实际执行

💬 "Show me the commands first before running them"
💬 "Do a dry run on /path/to/repo"
💬 "先列出要执行的命令，不要运行"

这使用户能够验证每条命令都严格匹配以下白名单。

命令白名单（仅允许以下命令）

此技能仅允许以下预定义的只读 git 子命令。不得执行任何其他 shell 命令：

严格禁止的命令类型：

• ❌ 任何写操作：git push，git commit，git merge，git rebase，git reset，git checkout，git branch -d
• ❌ 任何非 git 命令：curl，wget，python，node，bash -c，sh，evalrm,cp,mv❌ 任何文件写入或重定向操作：
• >,>>,tee（管道|仅允许连接只读文本处理工具：cut,sort,uniq,awk,grep,wc,sed,,头)
• ❌ 任何网络操作：git fetch、git pull、git clone、git remote

如果AI代理尝试执行白名单之外的命令，用户应立即拒绝执行。

输入验证规则（必须在执行任何Git命令前完成）

1. repo_path（仓库路径）验证：

   • 必须是绝对路径（以/开头）
   • 不得包含以下任何危险字符或子字符串：；、|、&、$,`,(,),>,<,\n,\r,$(),..
   • 路径必须是一个真实、已存在的 Git 仓库（通过git -C <路径> rev-parse --is-inside-work-tree返回true来验证）
   • 如果验证失败，立即中止并向用户报告错误——不得执行任何后续命令

2. 作者（作者姓名）验证：

   • 仅允许使用的字符：字母（a-z A-Z）、数字（0-9）、空格、连字符（-）、下划线（_）、点（.）
   • 符号@不允许使用（禁止使用电子邮件格式，以符合隐私保护规则）
   • 正则表达式白名单：^[a-zA-Z0-9 _.-]+$
   • 最大长度：128个字符
   • 如果输入包含@，则提示用户使用作者的显示名称替代，然后跳过该作者

3. 自/至（日期参数）验证：

   • 必须匹配ISO日期格式：^[0-9]{4}-[0-9]{2}-[0-9]{2}$
   • 如果验证失败，忽略该参数并警告用户

4. 分支（分支名称）验证：

   • 仅允许使用以下字符：字母、数字、/,-,_,.
   • 正则表达式白名单：^[a-zA-Z0-9/_.-]+$
   • 不得包含..子字符串
   • 如果验证失败，使用默认分支并警告用户

隐私保护规则

• 不收集开发者电子邮件地址。所有 git 命令仅使用%an（作者姓名）来识别开发者，从不使用%ae（作者电子邮件）。
• git shortlog使用-sn而非-sne以避免泄露电子邮件地址。
• 该作者参数仅接受显示名称，不接受电子邮件地址。输入验证会拒绝包含@符号的值。
• 注意：git --author参数会同时匹配姓名和电子邮件字段。由于此技能禁止使用电子邮件格式的值，--author将仅通过姓名字段进行匹配，不会利用电子邮件字段。
• 最终报告不得包含任何电子邮件地址。

敏感数据过滤规则（强制要求）

在发送任何数据给AI模型进行分析之前，代理必须应用以下过滤：

1. 提交信息仅在本地处理用于统计：

   • 代理会收集提交信息的长度（字符计数）和关键词匹配（例如，修复、功能、回滚），这些操作均通过本地shell命令完成。
   • 严禁将完整的提交信息文本逐字转发给AI模型。相反，仅发送聚合指标（平均长度、关键词计数、常规提交合规率）。
   • 如果用户明确要求查看特定提交信息，代理必须：
     1. 首先应用下方列出的所有脱敏模式
     2. 将每条信息截断至最多120个字符
     3. 仅在最终面向用户的报告中展示脱敏后的信息，切勿在中间AI提示中显示。
     4. 警告用户提交信息可能包含敏感信息

2. 自动对机密模式进行涂改：在将任何文本（提交信息、文件名、分支名称）包含到AI提示中之前，代理必须扫描并涂改以下模式：

   • API密钥/令牌：匹配以下模式的字符串(?i)(api[_-]?key|token|secret|password|credential|auth)[=:]\s*\S+
   • AWS密钥：AKIA[0-9A-Z]{16}
   • 私钥：-----BEGIN .* PRIVATE KEY-----
   • 连接字符串：(?i)(mysql|postgres|mongodb|redis)://\S+
   • 通用机密：任何在键值模式中出现在=或:之后，且仅包含字母数字字符、长度超过20个字符的字符串
   • 将匹配到的内容替换为[已涂改]

3. 文件名过滤：

   • 收集文件名仅用于确定文件扩展名用于语言/类型统计。
   • 除非用户明确请求文件级别的分析，否则不应将完整文件路径发送给AI模型。
   • 如果发送了完整路径，请对任何符合常见机密文件模式的路径组件进行脱敏处理：.env、.credentials、*secret*、*password*、*token*。

仓库路径范围规则

• 代理必须仅访问用户提供的特定仓库路径。
• 代理不得遍历父目录（..）或访问仓库根目录之外的文件。
• 代理不得列出或读取文件系统中的任意文件——只能通过git允许针对已验证仓库执行命令。
• 若用户提供仓库内的子目录路径，代理应使用仓库根目录（通过git -C <路径> rev-parse --show-toplevel命令确定）并告知用户。

执行验证协议

由于此为纯指令性技能（无可执行代码），安全性保障依赖于AI代理对上述规则的正确实施。用户在对敏感仓库使用本技能前，应先验证执行机制。

验证步骤（请先在安全测试仓库中运行）：

1. 预运行测试：要求代理使用预运行模式分析测试仓库。验证以下事项：

   • 所有建议命令均出现在上方的命令白名单表中
   • 未使用%ae（邮箱格式）或-sne参数
   • 所有用户提供的值（路径、作者、日期）均被正确引用

2. 输入验证测试：故意提供无效输入并验证是否被拒绝：

   "Analyze /tmp/test; rm -rf /"          -> agent MUST reject (dangerous characters)
   "Profile author user@email.com"         -> agent MUST reject (@ not allowed)
   "Analyze since 2024-13-99"              -> agent MUST reject or warn (invalid date)
   "Analyze branch ../../etc/passwd"       -> agent MUST reject (.. not allowed)
   

3. 数据过滤测试：在试运行后，询问代理：

   "What data will you send to the AI model?"
   

   代理应确认其仅发送聚合指标（计数、平均值、百分比），而非原始提交信息或完整文件路径。

4. 信息脱敏测试：如果请求提交信息，需验证：

   • 信息被截断至不超过120个字符
   • 类似API_KEY=xxx的敏感模式显示为[已脱敏]
   • 信息仅出现在最终报告中，不出现在中间处理过程

如果任何验证步骤失败，请勿在敏感代码库中使用此技能。将失败情况报告给技能维护者。

使用场景

• 当用户需要分析Git代码库中每位开发者的实际行为画像时
• 当用户希望比较团队成员的提交习惯、工作节奏和代码质量时
• 当用户希望了解团队的参与度分布情况时
• 当用户需要诚实地评估每位开发者的优势与不足，并提供改进建议时

核心原则

无需安装任何组件，不运行任何脚本所有数据收集均通过原生git命令完成（git log、git shortlog、git diff --stat等）。AI负责解析与评估工作

安全第一所有用户输入必须通过前述验证规则后，才能被整合到shell命令中。任何验证失败都必须导致流程终止或优雅降级——绝不可跳过验证环节

工作流程

步骤一：确认分析参数

向用户确认以下参数（若未指定则使用默认值）：

⚠️ 在执行步骤2之前，必须根据上方的“安全规范”对所有参数进行验证。未通过验证的参数不得用于命令构建。

步骤2：数据收集（纯Git命令）

按顺序执行以下git命令以收集原始数据。所有命令均针对目标仓库目录运行——无需安装任何依赖。

在下面的示例中，<仓库路径>、<作者>等是来自步骤1中已验证的安全值的占位符。

2.1 贡献者概览

# List all contributors with commit counts (no email to protect privacy)
git -C <repo_path> shortlog -sn --all

2.2 按作者提交详情

针对每位待分析作者，执行以下命令（若指定了日期范围或分支，则附加--since、--until、<branch>参数）：

# Detailed commit log: hash, author name, date, message, file stats (no email)
git -C <repo_path> log --author="<author>" --pretty=format:"%H|%an|%aI|%s" --numstat

# Commit count per hour of day (for work habit analysis)
git -C <repo_path> log --author="<author>" --pretty=format:"%aI" | cut -c12-13 | sort | uniq -c | sort -rn

# Commit count per day of week (1=Mon, 7=Sun)
git -C <repo_path> log --author="<author>" --pretty=format:"%ad" --date=format:"%u" | sort | uniq -c | sort -rn

# Lines added/deleted summary
git -C <repo_path> log --author="<author>" --pretty=tformat: --numstat | awk '{ add += $1; subs += $2 } END { printf "added: %s, deleted: %s\n", add, subs }'

# Commit message lengths
git -C <repo_path> log --author="<author>" --pretty=format:"%s" | awk '{ print length }'

# File types touched
git -C <repo_path> log --author="<author>" --pretty=tformat: --name-only | grep -oE '\.[^./]+$' | sort | uniq -c | sort -rn | head -20

# Commits per day (for frequency analysis)
git -C <repo_path> log --author="<author>" --pretty=format:"%ad" --date=short | sort | uniq -c | sort -rn | head -20

# Recent rework detection: files modified multiple times within 7-day windows
git -C <repo_path> log --author="<author>" --pretty=format:"%ad %s" --date=short --name-only | head -200

2.3 代码质量信号

# Bug fix commits (messages containing fix/bug/hotfix/patch)
git -C <repo_path> log --author="<author>" --grep="fix\|bug\|hotfix\|patch" --oneline -i | wc -l

# Revert commits
git -C <repo_path> log --author="<author>" --grep="revert" --oneline -i | wc -l

# Large commits (>500 lines changed)
git -C <repo_path> log --author="<author>" --pretty=format:"%H" --shortstat | grep -E "([5-9][0-9]{2}|[0-9]{4,}) insertion" | wc -l

# Merge commits
git -C <repo_path> log --author="<author>" --merges --oneline | wc -l

# Conventional commit check (feat/fix/chore/docs/style/refactor/test/perf/ci/build)
git -C <repo_path> log --author="<author>" --pretty=format:"%s" | grep -cE "^(feat|fix|chore|docs|style|refactor|test|perf|ci|build)(\(.+\))?:"

2.4 团队层面数据

# Files with only one contributor (bus factor risk)
git -C <repo_path> log --pretty=format:"%an" --name-only | sort | uniq -c | sort -rn | head -30

# Active date range per author
git -C <repo_path> log --author="<author>" --pretty=format:"%ad" --date=short | sort | sed -n '1p;$p'

步骤3：AI分析与评估

基于收集的原始数据，从以下六个维度分析每位开发者，并为每个维度分配1–10分：

📝 维度1：提交习惯

分析因素：

• 提交总数、日均提交频率
• 每次提交平均变更行数（增加+删除）
• 提交信息平均长度与质量
• 合并提交占比
• 大型提交（>500行）频率

评分标准：

• 10分：每日提交2-5次，每次50-200行代码，提交信息清晰且格式规范
• 5分：提交频率不稳定，偶尔出现大型提交，提交信息质量参差不齐
• 1分：提交次数极少，或频繁出现附带单词语句的大型提交

⏰ 维度二：工作习惯

分析要素：

• 提交时间分布（高峰时段）
• 周末提交占比
• 深夜编码比例（22:00–04:59）
• 最长连续编码周期（天数）
• 活跃天数 / 总时间跨度

评分标准：

• 10分：规律工作时间，深夜/周末提交比例<10%，产出持续稳定
• 5分：存在部分深夜/周末提交，工作节奏存在适度波动
• 1分：几乎所有提交都在深夜/周末完成，或呈现极不规律的工作模式

注：深夜/周末编码本身并非"不良行为"，但持续性的特殊模式可能暗示流程或资源配置问题

🚀 维度三：开发效率

分析要素：

• 代码净增长率：(增加行数 - 删除行数) / 增加行数
• 代码变动率：删除行数 / 增加行数
• 返工率：7天内重复修改同一文件的频率
• 活跃日平均产出量

评分标准：

• 10分：高净增长率，变动率<20%，低返工率，产出稳定
• 5分：中等变动率，存在部分返工
• 1分：大量代码删除，频繁返工，产出波动剧烈

🎨 第四维度：代码风格

分析要素：

• 主要编程语言/文件类型分布
• 规范提交遵从率
• 提交信息是否关联问题编号
• 文件修改集中度（集中在少数模块 vs 分散修改）

评分标准：

• 10分：规范提交遵从率>80%，信息关联问题，修改集中度高
• 5分：部分遵从，偶尔分散修改
• 1分：几乎不遵从规范，提交信息无意义

🔍 维度五：代码质量

分析要素：

• 缺陷修复提交比例
• 提交回退频率
• 大型提交（>500行）比例
• 测试相关文件修改频次

评分标准：

• 10分：缺陷修复比例<10%，无回退提交，大型提交<5%，定期修改测试文件
• 5分：缺陷修复比例15–25%，偶发回退，存在部分大型提交
• 1分：缺陷修复比例>30%，频繁回退，大量巨型提交

📊 维度六：参与度指数

⚠️ 使用限制：本指数仅作为团队协作模式的宏观参考指标严禁将其用于个人绩效考核、裁员决策、薪酬调整或任何人力资源决策依据使用者应充分理解本指数的局限性并承担相应的伦理责任

注：本指数旨在客观衡量代码仓库中的可见参与度，作为补充参考。Git记录仅反映代码提交活动，不代表开发者的全部工作（设计、代码审查、沟通、指导等均未被Git记录）。

计算方法（综合以下信号，0-100分制，分数越低表示可见参与度越高）：

等级划分：

• 0–20分：高度活跃——需考虑是否存在倦怠风险
• 21–40分：稳定参与，持续产出
• 41–60分：中等参与度，有提升空间
• 61–80分：参与度低——请核查是否存在未记录的代码外贡献
• 81–100分：参与度极低——建议与本人沟通了解完整情况

重要说明：本指标仅基于Git提交记录计算，无法反映代码审查、架构设计、技术讨论、团队指导等不产生提交记录的工作。高分不等同于"懈怠"，低分也不等同于"高效"。请在了解完整背景后再作判断。

第四步：生成报告

最终报告必须包含以下结构：

4.1 汇总表格

...

4.2 个人开发者档案

1. 为每位开发者输出：数据仪表板
2. ：所有六个维度的关键指标AI 评论
3. ：对优势和劣势进行严肃、直接的评估（不粉饰）改进建议
4. ：针对每个弱点的具体、可操作的改进建议六维度雷达图评分
5. ：每个维度 1–10 分加权平均（提交习惯15%，工作习惯15%，开发效率25%，代码风格15%，代码质量20%，参与度指数倒数10%）
6. 一句话总结：一句犀利、令人印象深刻的句子，总结这位开发者

4.3 团队横向比较

• 各维度排名
• 突出最佳/最差表现者
• 整体团队健康状况评估
• 关键人物风险警报

评论文风要求

• 严肃且直接：不粉饰，不回避。让数据说话——好就是好，坏就是坏。
• 温和但坚定：指出问题的同时提供改进路径。批评工作，而非个人。
• 犀利但公正：如同高级技术主管进行年度代码审查——既不手下留情，也不刻薄伤人。
• 数据驱动：每个结论必须有相应数据支撑。不凭直觉。

重要说明

• 所有数据收集仅使用原生git命令——无需pip包，无需安装或执行Python/Node脚本
• 必需的系统二进制文件： git、cut、sort、uniq、awk、grep、sed、wc、head——这些必须在主机上可用（在大多数类Unix系统中已预安装）
• 所有用户输入在执行前必须按照“安全规范”规则进行验证以防止命令注入攻击
• 首次使用时建议采用试运行模式执行前需审查所有命令
• 强制验证协议：在敏感代码库上使用前，请在测试仓库运行"强制验证协议"，以确认您的代理正确实施了所有验证、白名单和脱敏规则
• 敏感数据保护：提交信息仅在本地处理用于统计指标（长度、关键词计数）——默认情况下完整提交信息文本不会发送给AI模型常见密钥模式（API密钥、令牌、凭证、连接字符串）在数据离开本地环境前会自动脱敏。详见《敏感数据过滤规则》
• 代码库范围：代理仅访问指定代码库路径——禁止上级目录遍历或任意文件系统访问
• 不收集开发者邮箱以保护个人隐私
• 对于大型代码库，建议通过限制日期范围来控制命令执行时间
• 请注意同一人员可能使用不同名称变体（可通过.mailmap)
• 时区差异可能影响工作时间分析——请使用提交记录中的时区
• 参与度指数完全基于Git提交数据，并不反映非代码贡献（设计、评审、指导等）——不应作为绩效评估的唯一依据

道德使用政策

本技能生成的报告应遵循以下原则：

1. 补充参考，而非决策依据：报告仅供内部团队参考，以帮助理解协作模式和改进领域。严禁直接用于绩效评估、裁员决策、薪酬调整或其他人力资源决策。
2. 透明度：如果在团队内使用此工具，建议提前告知所有被分析的团队成员。
3. 完整上下文：引用报告时应包含完整的免责声明，避免断章取义。
4. 对事不对人目标是改进团队协作流程和个人工作方法，而不是评判一个人的价值。