---

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 中写入：

"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

在技能目录运行：

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. 校验并视觉检查

运行：

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：中文测试任务和预期行为。