Claycui828 ASU 简历真实性审计 Skill
把简历视为一组可以独立检验的主张。目标不是判断一个人“好”或“坏”，而是确定现有证据支持什么、直接反驳什么，以及哪些内容仍然无法核验。
必须交付的结果
除非用户明确缩小范围，否则生成以下内容：
report-data.json：标准化主张、来源、结论、包装模式、时间线和限制。- 自包含
report.html：不引用外部样式、脚本、字体或图片。 - 与同一数据模型一致的
report.pdf。 - 一段简短的对话总结：优先说明最强的支持证据、直接矛盾和未解决缺口。
完成 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.0 到 2.0 的迁移。
- 性能指标确实提升了 25%。
- 该提升由候选人的工作造成或得到其实质贡献。
每条主张记录：
- 简历原文；
- 标准化主张；
- 主张类别；
- 时间范围；
- 组织或项目；
- 隐含角色与责任范围；
- 核验所需证据。
数据格式见 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 必须保持自包含并使用附带的纸张式证据报告设计，至少包含：
- 范围与限制；
- 证据状态卡片；
- 调查流程图；
- 最高风险主张；
- 完整主张-证据矩阵；
- 包装模式及反向证据；
- 时间线；
- 来源和下一步核验。
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：中文测试任务和预期行为。