Back to Details

model-pr-diff-dossier

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Model PR Diff Dossier

模型PR差异档案

Use this skill before publishing any model PR optimization history document that cites framework PRs.
在发布任何引用框架PR的模型PR优化历史文档前，请使用本技能。

Non-Negotiable Standard

不可妥协的标准

Do not summarize a PR with only a title-level sentence. Do not use a script or bulk generator to fill motivation, implementation notes, or code excerpts.
For every PR cited as model optimization evidence, the document must include or link to a diff-reviewed PR card with:
  • PR link, title, state, merge time when available, additions/deletions, and changed-file count.
  • Motivation: why the PR existed, inferred from PR body, title, issue context, docs changes, tests, and code diff.
  • Key implementation idea: what runtime path changed and how the patch implements the change.
  • Key code excerpts: short, relevant snippets from the actual diff, not invented pseudocode.
  • Reviewed files: important files from the full diff, grouped by runtime/docs/tests where possible.
  • Validation implications: tests, benchmark paths, launch flags, or regression lanes implied by the diff.
  • Diff coverage note: state that the full diff was fetched/read and include diff line count.
请勿仅用一句话概括PR内容。 请勿使用脚本或批量生成工具填充动机、实现说明或代码片段。
对于每一个被列为模型优化依据的PR，文档必须包含或链接至一份经过差异审查的PR卡片，其中需涵盖：
  • PR链接、标题、状态（若有）、合并时间、新增/删除代码行数，以及变更文件数量。
  • 动机：结合PR正文、标题、相关议题上下文、文档变更、测试内容及代码差异，推断该PR存在的原因。
  • 核心实现思路：运行时路径发生了哪些变更，以及补丁如何实现这些变更。
  • 关键代码片段：来自实际差异的简短相关代码片段，而非虚构的伪代码。
  • 已审查文件：从完整差异中筛选出的重要文件，尽可能按运行时/文档/测试进行分组。
  • 验证影响：差异所涉及的测试、基准测试路径、启动标志或回归测试环节。
  • 差异覆盖说明：声明已获取并阅读完整差异，并包含差异的行数统计。

Workflow

工作流程

  1. Collect exact PR links from the target model history files. Use GitHub PR URLs, not bare 
    #123
    text.
  2. Open each PR diff directly with GitHub, 
    gh pr diff
    , or the local framework repository commit. Read the changed source files, not just the PR title.
  3. For merged PRs, cross-check the final mainline code in the relevant framework checkout when the diff is ambiguous.
  4. Write the PR card manually in the matching model history document. Use 
    references/card-schema.md
    when you need the exact card shape. The card must name concrete files/functions/classes and include a short real code excerpt.
  5. For docs-only or config-only PRs, quote the exact command/config line that changed and explain why it matters for serving or validation.
  6. After each model family, review the cards for repeated shallow words such as "follow-up", "bugfix", or "optimization"; replace them with concrete implementation detail.
  7. Run repository tests and formatting before publishing.
  1. 从目标模型历史文件中收集精确的PR链接。请使用GitHub PR完整URL，而非仅
    #123
    这类文本。
  2. 直接通过GitHub、
    gh pr diff
    命令或本地框架仓库的提交记录打开每个PR的差异文件。阅读变更后的源码文件，而非仅看PR标题。
  3. 对于已合并的PR，当差异内容不明确时，在相关框架的检出版本中交叉核对最终主线代码。
  4. 在对应的模型历史文档中手动编写PR卡片。若需要精确的卡片格式，请参考
    references/card-schema.md
    。卡片必须明确提及具体的文件/函数/类，并包含一段简短的真实代码片段。
  5. 对于仅涉及文档或配置的PR，引用变更后的具体命令/配置行，并解释其对服务或验证的重要性。
  6. 完成每个模型系列的文档后，检查卡片中是否存在“后续跟进”、“bug修复”或“优化”这类空泛词汇；将其替换为具体的实现细节。
  7. 在发布前运行仓库测试并进行格式调整。

Review Gate

审查门槛

A model PR history is not ready if any PR card says only "follow-up", "bugfix", "docs", or "optimization" without:
  • named files/functions/classes touched by the diff,
  • a concrete motivation,
  • a concrete implementation summary,
  • and at least one code excerpt or an explicit reason why the PR is docs-only.
若任何PR卡片仅标注“后续跟进”、“bug修复”、“文档更新”或“优化”，但未包含以下内容，则模型PR历史文档未准备就绪：
  • 差异所涉及的具体文件/函数/类名称，
  • 具体的动机，
  • 具体的实现总结，
  • 至少一段代码片段，或明确说明该PR仅涉及文档的原因。