---
name: asu-resume-audit-skill
description: 以证据为中心的简历真实性审计与报告生成技能。用户要求核验简历、打假履历、调查候选人经历、分析 GitHub/开源贡献、识别 contributor 到 maintainer/core author 的角色膨胀、核验中外合作办学或学校 title、检查业务指标、梳理公开争议，或者把调查结果制作成 HTML/PDF 时，应主动使用本技能。技能会把简历、截图、链接、帖子、代码仓库和官方记录拆成原子主张，区分事实、矛盾、指控和不可核验信息，并生成不含开盒信息、不把未经证实指控写成事实的自包含证据报告。
---

# ASU 简历真实性审计 Skill

把简历视为一组可以独立检验的主张。目标不是判断一个人“好”或“坏”，而是确定现有证据支持什么、直接反驳什么，以及哪些内容仍然无法核验。

## 必须交付的结果

除非用户明确缩小范围，否则生成以下内容：

1. `report-data.json`：标准化主张、来源、结论、包装模式、时间线和限制。
2. 自包含 `report.html`：不引用外部样式、脚本、字体或图片。
3. 与同一数据模型一致的 `report.pdf`。
4. 一段简短的对话总结：优先说明最强的支持证据、直接矛盾和未解决缺口。

完成 JSON 后，用 `scripts/render_report.py` 生成 HTML/PDF；交付前用 `scripts/validate_report.py` 校验。

## 证据与伤害边界

简历审计涉及可识别个人，错误结论可能造成真实的名誉伤害，因此始终遵守以下规则：

- 只使用公开且与任务直接相关的信息。不得搜集住址、电话、家庭成员、账号凭证、私人消息或无关个人信息。
- 截图、指控文章、匿名评论和候选人自有主页只能证明“有人这样说过”，不能自动成为独立证据。
- 使用 `公开证据仅支持 contributor，尚未支持 core author` 等精确表述，避免使用 `骗子`、`害虫` 或 `欺诈者` 等人格标签。
- 只有可靠证据与主张直接冲突时才标记 `contradicted`；否则使用 `unsupported`、`partially_corroborated` 或 `unverifiable`。
- 主动提 issue、贡献前端/文档、与维护者建立关系或因此获得正式社区身份，本身不是不当行为。要核验的是简历是否准确描述正式角色、技术深度和个人贡献。
- 不得用学校排名或“双非”身份推断诚信。“双非”是非正式标签，不是造假证据。应核验院校、项目、学籍与学位授予方。
- 性别、外貌、性格、税务或动机推断通常与简历真实性无关；除非权威证据证明其直接关联某条简历主张，否则排除。
- 对当事人有利的重要证据必须与不利证据同等展示。

给结论状态前先阅读 `references/evidence-methodology.md`。核验开源或教育主张前，阅读相应专项参考。

## 工作流程

### 1. 确定范围并保存来源集合

列出用户提供的全部材料：

- 简历 PDF 或截图；
- 文章和社交媒体帖子；
- 代码仓库及个人主页链接；
- 网页存档；
- 用户提供的就业、学校、奖项或付费社群背景。

条件允许时完整阅读链接和文档，以原始分辨率检查图片。页面被安全策略或登录限制阻挡时，说明限制；可使用用户提供的正文或其他公开来源，但不得绕过访问控制。

立即为每个来源分配编号（`S-001`、`S-002`……），并标记来源类型：

- `official_record`：官方记录；
- `repository_record`：代码仓库记录；
- `candidate_self_statement`：候选人自述；
- `user_provided_document`：用户提供材料；
- `media_or_commentary`：媒体或评论文章；
- `anonymous_or_unverified`：匿名或未经核验来源。

### 2. 把简历拆成原子主张

不要把整段经历作为一条主张。将角色、范围、结果和因果关系分开检验。

例如：

> “作为核心作者主导项目从 1.0 到 2.0，性能提升 25%。”

应拆为：

1. 候选人正式或事实上属于核心作者。
2. 候选人领导了 1.0 到 2.0 的迁移。
3. 性能指标确实提升了 25%。
4. 该提升由候选人的工作造成或得到其实质贡献。

每条主张记录：

- 简历原文；
- 标准化主张；
- 主张类别；
- 时间范围；
- 组织或项目；
- 隐含角色与责任范围；
- 核验所需证据。

数据格式见 `references/report-schema.md`。

### 3. 先做确定性的内部一致性检查

联网研究前，先让简历与自身对账：

- 重算转化率、增长率和比例；
- 比较简历、主页、offer 和帖子中的日期；
- 标记重叠的全职或实习时间；
- 比较不同平台使用的角色级别；
- 找出没有明确比较范围的“最年轻、第一、核心”等最高级；
- 区分项目整体指标与个人影响指标；
- 检查是否在没有基线或对照组时宣称因果关系。

算术矛盾不依赖外部解释，通常可以给出高置信度。

当材料能够明确给出分子、分母和展示百分比时，在对应的结构化 Claim 中写入：

```json
"metric": {
  "numerator": 200,
  "denominator": 2000,
  "displayed_percent": 10
}
```

交由确定性校验器重算。不要从只有“转化率 38%”的自然语言中猜测分母。数字关系不一致只说明当前口径下的数值不一致，不自动等于候选人造假；若可能存在未披露的分母，应在分析中说明这一限制。

当材料明确给出基线、结果、变化类型和展示变化值时，也在同一个 `metric` 对象中记录 `baseline`、`result`、`change_type` 与 `displayed_change`。`relative_percent` 按 `(result - baseline) / baseline * 100` 重算，例如 100 到 125 是 `25%`；`percentage_points` 直接相减，例如 60% 到 70% 是 `10` 个百分点，而不是 `10%` 的相对变化（相对变化约为 16.67%）。不要从自然语言猜测变化类型或基线。相对变化的 baseline 为零时应说明无法计算；数字关系不一致同样只说明已提供数值之间的关系，不自动等于候选人造假。

### 4. 用最强来源核验每条主张

技术与机构主张优先使用一手资料。

#### 开源与 GitHub 主张

先阅读 `references/open-source-audit.md`，再检查：

- 作者 PR 和 issue 搜索；
- merged、closed-unmerged、open、duplicate、superseded 的区别；
- 修改文件、代码所有权、评审记录和 release note；
- README 致谢、maintainer 列表、CODEOWNERS、组织成员与正式任命；
- 贡献类型：核心引擎、功能、缺陷修复、前端、网站、文档、测试、生成代码、评论或仅 issue；
- 贡献时间与所声称版本/架构阶段的关系；
- star、排名、采用率和项目成功是否早于候选人的贡献。

GitHub contribution 数量不等于合并到生产的代码；某个子项目的正式 committer 身份也不等于整个核心引擎的作者身份。

#### 就业、offer 与内部项目主张

优先使用雇主记录、offer 元数据、主管确认、内部设计文档、代码所有权、上线记录或指标看板。无法取得时标记 `unverifiable`，不能直接判假。

遇到 `owner`、`0-to-1`、`core author`、`architect` 或 `lead` 时追问：

- 谁授予或分配了这个角色？
- 实际负责哪个子系统？
- 哪些决策由候选人本人提出？
- 哪些产物通过评审并进入生产？
- 哪个结果可以归因于个人而不是团队？

#### 学校与中外合作项目主张

阅读 `references/education-branding-audit.md`，分别核验：

- 录取和注册学籍所在院校；
- 实际就读校区或项目；
- 海外合作院校；
- 交换或访问身份；
- 中外合作项目状态；
- 学位授予院校；
- 最终取得的学位、文凭或证书。

只有在官方项目和学历证明允许的范围内，才能使用合作院校品牌。不得因为学校不够知名就推断造假。

#### 产品、创业与付费用户指标

要求定义注册用户、活跃用户、付费用户、转化事件、分母、时间窗口、收入、退款和测试账号。重算所有可见比例。第三方流量估算不能证明内部支付数据或项目归属。

#### 奖项与“最年轻/首个/第一”主张

查找官方获奖名单和明确的比较集合。没有公开排名或可穷举比较范围时，即使底层奖项或身份真实，最高级仍应标记 `unsupported`。

### 5. 检查简历包装与夸大模式

阅读 `references/inflation-patterns.md`。必须先完成逐条证据核验，再判断是否存在模式。常见模式包括：

- contributor 升级为 maintainer/core author；
- 网站或文档贡献被表述为核心引擎深度；
- 项目 star、品牌和排名转移到个人；
- 社交或可见度工作被用来暗示技术权威；
- 复述完整系统架构代替个人产物证明；
- 团队结果和采用率归因于个人；
- 分母切换和伪精确指标；
- 在多个自有平台重复自授 title；
- 将合作学校或海外项目呈现为学位主体；
- 时间压缩及重复的 `owner/0-to-1` 表述。

发现模式只是调查信号，不能单独作为造假证据。

### 6. 分配证据状态

每条主张只使用一个状态：

- `corroborated`：强独立证据支持主张的关键内容。
- `partially_corroborated`：真实事实存在，但角色、范围、因果或幅度超过证据。
- `contradicted`：可靠证据与主张直接冲突。
- `unsupported`：合理搜索后仍没有足够证据。
- `unverifiable`：只有当前不可取得的内部或私人记录才能核验。

同时记录置信度（`high`、`medium`、`low`），并说明什么证据可以改变结论。

### 7. 建立报告数据

按 `references/report-schema.md` 创建 `report-data.json`。引用保持简短，每个重要结论都要指向来源。指控必须带归属，例如：

> `文章作者指控……；当前材料缺少原始截图，尚未独立验证。`

不要直接写：

> `当事人伪造了……`

除非直接、权威的证据已经证明该结论。

### 8. 生成 HTML 与 PDF

在技能目录运行：

```bash
python3 scripts/render_report.py \
  --input /absolute/path/report-data.json \
  --html /absolute/path/report.html \
  --pdf /absolute/path/report.pdf
```

HTML 必须保持自包含并使用附带的纸张式证据报告设计，至少包含：

1. 范围与限制；
2. 证据状态卡片；
3. 调查流程图；
4. 最高风险主张；
5. 完整主张-证据矩阵；
6. 包装模式及反向证据；
7. 时间线；
8. 来源和下一步核验。

### 9. 校验并视觉检查

运行：

```bash
python3 scripts/validate_report.py \
  --data /absolute/path/report-data.json \
  --html /absolute/path/report.html \
  --pdf /absolute/path/report.pdf
```

如果安装了 `pdftoppm`，将 PDF 渲染为 PNG 并检查每一页，确认没有文字裁切、中文缺字、表格破裂或元素重叠。发现问题后先修改再交付。

### 10. 使用校准后的语言交付

结论顺序为：

- 最强的已证实事实；
- 最强的直接矛盾；
- 最大的不可核验缺口。

不要复述文章中的煽动性措辞。明确区分 `字面虚构`、`角色/范围膨胀`、`缺乏支持的营销表述` 和 `仅仅缺少证据`。

## 附带参考资料

- `references/evidence-methodology.md`：来源等级与状态判断规则。
- `references/open-source-audit.md`：GitHub/Apache 贡献和角色审计。
- `references/education-branding-audit.md`：院校、中外合作、交换和学位表述。
- `references/inflation-patterns.md`：防御性简历包装分类。
- `references/report-schema.md`：报告生成器读取的 JSON 格式。
- `references/asu-case-study.md`：基于公开记录和用户材料的有限案例；不得将其视为永恒或全面事实。

## 附带工具

- `scripts/render_report.py`：确定性 HTML/PDF 生成器。
- `scripts/validate_report.py`：数据结构、证据引用、HTML 和 PDF 冒烟检查。
- `assets/report_template.html`：自包含中文 HTML 报告模板。
- `evals/evals.json`：中文测试任务和预期行为。