---
name: who-is-actor
license: MIT
description: >
  当用户需要分析 Git 仓库并为每个开发者生成提交习惯、工作习惯、研发效率、
  代码风格、代码质量和参与度指数画像时，应触发本技能。完全无需安装任何
  额外包或运行任何自定义脚本，纯粹依赖原生 git CLI 命令和主机上已有的
  标准 Unix 文本处理工具，由 AI 驱动解读。
  触发词包括 "analyze repository" "profile developers" "commit habits"
  "developer report card" "代码分析" "研发效率" "开发者画像"
  "提交习惯" "工作习惯" "参与度"。
---

# Who Is Actor — Git 仓库开发者画像技能

> 🔗 **项目地址：** [https://github.com/wscats/who-is-actor](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。

---

## 💬 自然语言使用（推荐）

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

### 中文

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

### English

```
💬 "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"
💬 "各開発者のコミット習慣を比較してください"
💬 "このプロジェクトのコード品質レポートを作成してください"
💬 "チームの開発効率を評価してください"
```

### 한국어

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

### Español

```
💬 "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?"
```

### Français

```
💬 "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 ?"
```

### Deutsch

```
💬 "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?"
```

---

## ⚙️ 参数说明

| 参数 | 说明 | 必填 | 默认值 |
|------|------|------|--------|
| `repo_path` | 目标 Git 仓库的绝对路径 | ✅ 是 | — |
| `authors` | 逗号分隔的作者显示名（**不接受邮箱**） | 否 | 全部贡献者 |
| `since` | 起始日期，ISO 格式（`YYYY-MM-DD`） | 否 | 完整历史 |
| `until` | 截止日期，ISO 格式（`YYYY-MM-DD`） | 否 | 完整历史 |
| `branch` | 要分析的目标分支 | 否 | 当前活跃分支 |

**你将获得：** 一份结构化的 Markdown 报告，包含总览表、每位开发者的个人画像（六维雷达评分、优缺点、改进建议）、团队交叉对比以及巴士因子风险预警。

---

## 安全规范

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

### 预览模式 / Dry-Run（推荐首次使用）

在执行任何命令之前，代理**应当**提供 **预览模式（dry-run）**：

1. 收集并校验所有参数
2. 构建将要执行的完整命令列表
3. **将所有命令展示给用户审查，不实际执行任何命令**
4. 等待用户明确批准后再实际执行

触发预览模式的说法：
```
💬 "先列出要执行的命令，不要运行"
💬 "做一次 dry run"
💬 "Show me the commands first before running them"
```

> 这使用户可以验证每条命令是否严格匹配下方的白名单。

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

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

| 允许的命令 | 用途 | 是否修改仓库？ |
|-----------|------|---------------|
| `git -C <path> rev-parse --is-inside-work-tree` | 验证路径是否为有效 Git 仓库 | ❌ 只读 |
| `git -C <path> shortlog -sn --all` | 获取贡献者列表及提交次数 | ❌ 只读 |
| `git -C <path> log ...` | 获取提交历史详情 | ❌ 只读 |
| `git -C <path> diff --stat ...` | 获取变更统计 | ❌ 只读 |

**严格禁止的命令类型：**
- ❌ 任何写入操作：`git push`、`git commit`、`git merge`、`git rebase`、`git reset`、`git checkout`、`git branch -d`
- ❌ 任何非 git 命令：`curl`、`wget`、`python`、`node`、`bash -c`、`sh`、`eval`、`rm`、`cp`、`mv`
- ❌ 任何文件写入或重定向：`>`、`>>`、`tee`（管道 `|` 仅允许连接只读文本处理工具：`cut`、`sort`、`uniq`、`awk`、`grep`、`wc`、`sed`、`head`）
- ❌ 任何网络操作：`git fetch`、`git pull`、`git clone`、`git remote`

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

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

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

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

3. **`since` / `until`（日期参数）校验：**
   - 必须匹配 ISO 日期格式：`^[0-9]{4}-[0-9]{2}-[0-9]{2}$`
   - 如果校验失败，忽略该参数并警告用户

4. **`branch`（分支名）校验：**
   - 仅允许字符：字母、数字、`/`、`-`、`_`、`.`
   - 正则白名单：`^[a-zA-Z0-9/_.-]+$`
   - 不得包含 `..` 子串
   - 如果校验失败，使用默认分支并警告用户

### 隐私保护规则

- **不收集开发者邮箱地址。** 所有 git 命令仅使用 `%an`（作者名）标识开发者，绝不使用 `%ae`（作者邮箱）。
- **`git shortlog` 使用 `-sn` 而非 `-sne`**，避免泄露邮箱地址。
- **`authors` 参数仅接受显示名，不接受邮箱地址。** 输入校验会拒绝包含 `@` 的值。
- 注意：`git --author` 参数会同时匹配姓名和邮箱字段。由于本技能禁止邮箱格式的值，`--author` 将仅通过姓名部分进行匹配，不会利用邮箱字段。
- 最终报告中 **不得包含任何邮箱地址**。

### 敏感数据过滤规则（强制执行）

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

1. **提交消息仅在本地处理统计数据：**
   - 代理通过 shell 命令在本地收集提交消息的**长度**（字符数）和**关键词匹配**（如 `fix`、`feat`、`revert`）。
   - **完整的提交消息文本不得原样转发给 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 <path> rev-parse --show-toplevel` 确定）并告知用户。

### 执行验证协议

由于本技能是纯指令型（无可执行代码），安全保证依赖于 AI 代理正确实现上述规则。**用户应在信任本技能处理敏感仓库之前验证执行情况。**

**验证步骤（先在安全的测试仓库上运行）：**

1. **Dry-run 测试：** 让代理使用预览模式分析测试仓库。验证：
   - 所有提议的命令都出现在上方的命令白名单表中
   - 没有命令使用 `%ae`（邮箱格式）或 `-sne` 标志
   - 所有用户提供的值（路径、作者、日期）都被正确引用

2. **输入校验测试：** 故意提供无效输入并验证拒绝：
   ```
   "分析 /tmp/test; rm -rf /"          → 代理必须拒绝（危险字符）
   "分析作者 user@email.com"           → 代理必须拒绝（不允许 @）
   "分析 since 2024-13-99"             → 代理必须拒绝或警告（无效日期）
   "分析分支 ../../etc/passwd"          → 代理必须拒绝（不允许 ..）
   ```

3. **数据过滤测试：** dry-run 之后，询问代理：
   ```
   "你会把什么数据发送给 AI 模型？"
   ```
   代理应确认只发送聚合指标（计数、平均值、百分比），而非原始提交消息或完整文件路径。

4. **脱敏测试：** 如果请求了提交消息，验证：
   - 消息被截断至 ≤120 个字符
   - 类似 `API_KEY=xxx` 的模式显示为 `[已脱敏]`
   - 消息仅出现在最终报告中，而非中间处理过程中

> **如果任何验证步骤失败，请勿在敏感仓库上使用本技能。** 请向技能维护者报告问题。

## 适用场景

- 当用户需要分析 Git 仓库中每位开发者的真实行为画像时
- 当用户想要对比团队成员的提交习惯、工作节奏和代码质量时
- 当用户想要了解团队的参与度分布时
- 当用户需要对每位开发者的优缺点进行诚实评价并附带改进建议时

## 核心原则

> **不安装任何东西，不运行任何脚本。** 所有数据采集完全通过原生 git 命令（`git log`、`git shortlog`、`git diff --stat` 等）完成。AI 负责解读和评估。

> **安全第一。** 所有用户输入在被纳入 shell 命令之前，必须通过上述校验规则。任何校验失败必须导致终止或优雅降级 — 绝不跳过校验。

## 工作流程

### 步骤 1：确认分析参数

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

| 参数 | 说明 | 默认值 |
|------|------|--------|
| **仓库路径** | 目标 Git 仓库的绝对路径 | （必填） |
| **目标作者** | 要分析的特定开发者，留空则分析全部 | 全部贡献者 |
| **日期范围** | 起止日期，ISO 格式 | 完整仓库历史 |
| **分支** | 要分析的目标分支 | 当前活跃分支 |

> **⚠️ 执行步骤 2 之前，所有参数必须按照上述"安全规范"进行校验。校验失败的参数不得用于命令构建。**

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

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

> 以下示例中的 `<repo_path>`、`<author>` 等为步骤 1 中经过校验的安全值占位符。

#### 2.1 贡献者总览

```bash
# 列出所有贡献者及提交次数（不包含邮箱以保护隐私）
git -C <repo_path> shortlog -sn --all
```

#### 2.2 逐作者提交详情

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

```bash
# 详细提交日志：哈希、作者名、日期、消息、文件统计（无邮箱）
git -C <repo_path> log --author="<author>" --pretty=format:"%H|%an|%aI|%s" --numstat

# 按小时统计提交次数（用于工作习惯分析）
git -C <repo_path> log --author="<author>" --pretty=format:"%aI" | cut -c12-13 | sort | uniq -c | sort -rn

# 按星期几统计提交次数（1=周一，7=周日）
git -C <repo_path> log --author="<author>" --pretty=format:"%ad" --date=format:"%u" | sort | uniq -c | sort -rn

# 新增/删除行数汇总
git -C <repo_path> log --author="<author>" --pretty=tformat: --numstat | awk '{ add += $1; subs += $2 } END { printf "added: %s, deleted: %s\n", add, subs }'

# 提交消息长度
git -C <repo_path> log --author="<author>" --pretty=format:"%s" | awk '{ print length }'

# 涉及的文件类型
git -C <repo_path> log --author="<author>" --pretty=tformat: --name-only | grep -oE '\.[^./]+$' | sort | uniq -c | sort -rn | head -20

# 每日提交次数（用于频率分析）
git -C <repo_path> log --author="<author>" --pretty=format:"%ad" --date=short | sort | uniq -c | sort -rn | head -20

# 近期返工检测：7 天窗口内多次修改同一文件
git -C <repo_path> log --author="<author>" --pretty=format:"%ad %s" --date=short --name-only | head -200
```

#### 2.3 代码质量信号

```bash
# Bug 修复提交（消息包含 fix/bug/hotfix/patch）
git -C <repo_path> log --author="<author>" --grep="fix\|bug\|hotfix\|patch" --oneline -i | wc -l

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

# 大提交（>500 行变更）
git -C <repo_path> log --author="<author>" --pretty=format:"%H" --shortstat | grep -E "([5-9][0-9]{2}|[0-9]{4,}) insertion" | wc -l

# 合并提交
git -C <repo_path> log --author="<author>" --merges --oneline | wc -l

# 约定式提交检查（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 团队级别数据

```bash
# 仅有一个贡献者的文件（巴士因子风险）
git -C <repo_path> log --pretty=format:"%an" --name-only | sort | uniq -c | sort -rn | head -30

# 每位作者的活跃日期范围
git -C <repo_path> log --author="<author>" --pretty=format:"%ad" --date=short | sort | sed -n '1p;$p'
```

### 步骤 3：AI 分析与评估

基于采集的原始数据，从以下 **六个维度** 分析每位开发者，每个维度评分 1-10：

---

#### 📝 维度一：提交习惯

**分析因素：**
- 总提交次数、日均提交频率
- 每次提交的平均变更行数（增加 + 删除）
- 提交消息平均长度和质量
- 合并提交比例
- 大提交（>500 行）频率

**评分标准：**
- 10：日均 2-5 次提交，每次 50-200 行，消息清晰且格式规范
- 5：频率不稳定，偶尔有巨型提交，消息质量参差不齐
- 1：提交极少或频繁巨型提交，消息只有一两个词

---

#### ⏰ 维度二：工作习惯

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

**评分标准：**
- 10：规律工作时间，深夜/周末比例 <10%，持续稳定输出
- 5：有一些深夜/周末提交，节奏波动适中
- 1：几乎所有提交都在深夜/周末，或极度不规律

> 注意：深夜/周末编码不一定是"坏的"，但持续的模式可能表明流程或资源问题。

---

#### 🚀 维度三：研发效率

**分析因素：**
- 净代码增长率：(新增 - 删除) / 新增
- 代码流失率：删除 / 新增
- 返工率：7 天窗口内修改同一文件的频率
- 活跃日的日均产出

**评分标准：**
- 10：高净增长率，流失率 <20%，低返工率，稳定产出
- 5：中等流失率，有一定返工
- 1：大量代码删除，频繁返工，产出波动剧烈

---

#### 🎨 维度四：代码风格

**分析因素：**
- 主要编程语言 / 文件类型分布
- 约定式提交（Conventional Commits）合规率
- 提交消息是否引用 issue 编号
- 文件修改集中度（集中在少数模块 vs. 分散）

**评分标准：**
- 10：>80% 约定式提交合规率，消息引用 issue，修改集中
- 5：部分合规，偶尔分散
- 1：几乎不合规，消息无意义

---

#### 🔍 维度五：代码质量

**分析因素：**
- Bug 修复提交比例
- Revert 提交频率
- 大提交（>500 行）比例
- 测试相关文件修改频率

**评分标准：**
- 10：Bug 修复比例 <10%，无 revert，大提交 <5%，有修改测试文件
- 5：Bug 修复 15-25%，少量 revert，有一些大提交
- 1：Bug 修复 >30%，频繁 revert，大量巨型提交

---

#### 📊 维度六：参与度指数

> **⚠️ 使用限制：** 本指数仅作为团队协作模式的宏观参考。**严禁将其作为个人绩效考核、裁员决策、薪酬调整或任何其他人事决策的依据。** 用户应理解该指数的局限性并承担相应的伦理责任。

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

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

| 信号 | 权重 | 说明 |
|------|------|------|
| 日均提交极低（<0.3） | 25% | 活跃日的产出过低 |
| 活跃日占比低（<30%） | 20% | 时间跨度大但实际工作天数少 |
| 净代码增长极低或为负 | 20% | 删除的代码比编写的更多 |
| 提交消息草率（平均 <15 字符） | 15% | 不认真对待提交记录 |
| 高流失率 + 高返工率 | 20% | 大量无效劳动 |

**等级：**
- 0-20：高度活跃 — 考虑是否存在倦怠风险
- 21-40：稳定参与，持续产出
- 41-60：中等参与，有提升空间
- 61-80：低参与度 — 检查是否有未被记录的非代码贡献
- 81-100：极低参与度 — 建议与本人沟通了解全貌

> **重要提示：** 该指数仅根据 Git 提交记录计算，无法反映代码评审、架构设计、技术讨论、团队指导等不产生提交的工作。高分不等于"摸鱼"，低分不等于"高效"。请在了解完整背景后再做判断。

### 步骤 4：生成报告

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

#### 4.1 总览表

| 开发者 | 提交数 | 行数 +/- | 日均 | 周末% | 深夜% | Bug修复% | 流失率 | 参与度 | 综合评分 |
|--------|--------|----------|------|-------|-------|----------|--------|--------|----------|
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |

#### 4.2 个人开发者画像

为每位开发者输出：

1. **数据面板**：六个维度的关键指标
2. **AI 点评**：严肃、直接地评估优缺点（不粉饰太平）
3. **改进建议**：针对每个弱点给出具体、可操作的建议
4. **六维雷达评分**：每个维度 1-10 分
5. **综合评分**：加权平均（提交习惯 15%、工作习惯 15%、研发效率 25%、代码风格 15%、代码质量 20%、参与度指数反向 10%）
6. **一句话总结**：一句犀利、令人印象深刻的话概括该开发者

#### 4.3 团队交叉对比

- 各维度排名
- 突出最佳 / 最差表现者
- 团队整体健康度评估
- 巴士因子风险预警

## 点评风格要求

- **严肃直接**：不粉饰，不含糊。数据说话 — 好就是好，差就是差。
- **温暖而坚定**：指出问题的同时提供改进路径。对事不对人。
- **犀利但公平**：像一位资深技术负责人进行年度 Code Review — 既不手软也不刻薄。
- **数据驱动**：每个结论都必须有相应数据支撑。不凭直觉。

## 重要注意事项

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

## 伦理使用政策

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

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