开发工具Lint格式化静态分析CLI【免费下载链接】ruffAn extremely fast Python linter and code formatter, written in Rust.项目地址https://gitcode.com/GitHub_Trending/ru/ruff点击查看免费下载导读本文面向在 ruffAstral 出品的 Python 静态检查与类型检查工具链仓库中参与 ty 类型检查器 PR 评审的开发者系统讲解仓库内定义的ty 生态系统结果摘要报告编写规范模板位于 .agents/skills/summarise-ecosystem-results/assets/report-template.md。读完本文你将掌握报告的标准章节骨架项目故障、间歇性严重故障、诊断变化、复现信息、每条诊断/故障的命中计数规则、最小复现示例的写法以及如何借助仓库中的证据采集脚本scripts/collect_ty_ecosystem_run_metadata.py和复现运行器scripts/run_ty_ecosystem_repro.py把一次 PR 的生态系统实验转化为一份事实准确、可直接作为 GitHub 评论发布的摘要。一、模板在仓库中的定位与整体契约1.1 模板服务于哪类任务该模板是 .agents/skills/summarise-ecosystem-results/SKILL.md 的交付物规范。该 skill 在用户提出总结生态系统结果summarise ecosystem results这个 ty 生态系统报告里改了什么等请求时被调用输入通常是PR 编号、PR URL、GitHub 上的 ecosystem-results 评论或由ecosystem-analyzer生成的详细 HTML 报告输出则是仓库根目录下命名为PR_number_ECOSYSTEM_SUMMARY.md的 Markdown 文件。模板开头的 HTML 注释是整个报告格式的契约明确要求替换所有占位符并删除所有 HTML 注释后再呈现报告每个散文段落和列表项保持在单行内便于 GitHub 评论渲染每个章节内保留的变化小节连续编号且每个章节从 1 重新开始尽量把报告控制在 100 个变化小节以下但为了清晰、完整的覆盖可以超出此目标相关的原因可以合并到同一主题下但如果行为不同必须用各自的解释和示例分别说明不能为了凑小节数而把不同原因混为一谈。1.2 报告的交付形态必须是 GitHub 风格的 MarkdownGitHub-flavored Markdown适合直接作为 GitHub 评论发布外部源码位置一律用永久链接permalink表示格式如project file.py:123严禁输出裸 URL所有占位符、HTML 注释必须移除如果在一个 Codex App 线程中只要求做摘要这件事应把线程重命名为PR ecosystem summary。仓库中与之一一对应的既有实现可作参照ruff-ecosystem的 Markdown 渲染器python/ruff-ecosystem/ruff_ecosystem/markdown.py同样采用detailssummary…/summary…/details折叠结构、在标题中给出N -M增减统计并把差异包裹进pre或 diff 代码块中展示。二、报告标题与开篇摘要模板固定标题为# PR #number ecosystem summary紧随标题的是开篇摘要模板以占位符标注要求不超过两段精炼总结对项目故障和诊断行为的有意义变化包括涉及间歇性严重故障的变化及其意义开篇就要给出读者需要的分析结论不要描述报告是如何生成的。这与 skill 的优先级一致把读者能直接消化改了什么、为什么改、哪些反复出现的代码模式导致了这些影响放在最前面用示例展示变化而非冗长散文见 .agents/skills/summarise-ecosystem-results/SKILL.md 的 Priorities 一节。三、Project failures项目故障章节3.1 何时包含此章节只有当稳定的项目故障发生变化时才包含整个章节模板注释明确要求没有稳定项目故障变化就省略整个章节。每个不同的故障重复一个编号小节。3.2 小节结构## Project failures (N sections) ### 1. New, fixed, or changed project failure **per-outcome and per-rule hit counts, as applicable** details summaryAffected projects/summary - project: merge base: base outcome; PR: PR outcome. /details Explain the crash, panic, overflow, timeout, or abnormal exit, including relevant stderr where applicable.3.3 计数规则故障小节按每个受影响项目 × 每个不同的已报告故障结果计 1 个命中无论该结果在多少次运行中出现例如一次崩溃在 10 次运行中的 3 次新出现贡献 1 个故障命中但受影响的项目条目中必须保留 3/10 的频率信息同时保留合并基线merge base的频率故障计数与诊断总数分开统计如果某个故障小节同时覆盖诊断变化则也要给出按规则的计数。这一规则与 .agents/skills/summarise-ecosystem-results/SKILL.md 中的 Reporting Policy 相呼应报告新出现、被修复或有意义变化的 panic、崩溃、溢出和超时当涉及间歇性行为时要报告 merge base 与 PR 两侧的运行频率。3.4 最小复现器模板注释规定只有当故障能归因于源代码时才包含已验证的最小复现器否则省略该代码块minimal reproducer这与 .agents/skills/minimizing-ty-ecosystem-changes/SKILL.md 的先复现再解释不变量一脉相承复现器必须经过验证且保留底层触发原因而不仅是诊断规则、消息或显示的类型。四、Intermittent severe failures间歇性严重故障章节4.1 何时包含此章节只有当涉及间歇性结果的严重故障发生变化时才包含整个章节每个不同的变化重复一个编号小节。例如新出现或行为变化的间歇性 panic、崩溃、溢出、超时。4.2 小节结构## Intermittent severe failures (N sections) ### 1. New or changed intermittent panic, crash, overflow, or timeout **per-outcome and per-rule hit counts, as applicable** details summaryAffected projects/summary - project: merge base: base outcome and count/runs, or not present; PR: PR outcome and count/runs, or not present. /details Explain the change in failure behavior and relevant stderr. Do not include unchanged failures or frequency-only fluctuations.关键约束受影响项目的条目中必须记录merge base 与 PR 各自的结果及 count/runs例如 3/10不存在则写 not present只解释故障行为的变化和相关 stderr不得包含未变化的故障或仅频率波动的变化。在复现侧scripts/run_ty_ecosystem_repro.py 会以 JSON 输出timed_out与return_code超时给出true与null与 analyzer 的分类一致超时运行产生的部分诊断会被丢弃。这与模板把超时单列为一种故障结果、并与普通退出码区分的规则吻合。五、Diagnostic changes诊断变化章节5.1 整体结构与排序当稳定的诊断行为发生变化时才包含整个章节相关的成因应组织到主题性小节中。诊断小节及其子小节按生态系统总命中数降序排列descending total ecosystem hit count。5.2 小节结构## Diagnostic changes (N sections) ### 1. Common theme or behavior change **count rule; count other-rule** details summaryReport entries/summary - project1 file1.py:line: added, removed, or changed rule. - project1 file2.py:line: added, removed, or changed other-rule (count duplicate occurrences). - project2 file1.py:line: added, removed, or changed rule. /details Concisely explain the common theme and exact behavior on the merge base and PR. Distinguish related causes with separate explanations and examples, and identify which entries each example explains. Cover every changed rule with an example; one example may cover multiple rules when the same cause and explanation account for all of them.要点每个小节标题下紧跟一句加粗的按规则诊断计数且每个规则计数只出现一次详尽的条目清单必须放在details块内解释与示例放在块外每条记录必须标识诊断的来源永久链接、规则以及它是 added新增、removed移除还是 changed改写保留重复出现用显式倍数标注(N duplicate occurrences)对没有源诊断的故障列出受影响项目的结果小节的清单与示例要和小节计数一致所有小节清单要与最终报告清单对账保证每个保留条目恰好出现一次。5.3 计数规则最易出错的部分模板注释给出了精确的计分约定计数代表诊断出现次数含重复而不是项目数或示例数每次新增或移除出现都为自己的规则贡献 1 个命中不把新增与移除做净额抵消additions 和 removals 各自累计已验证的同规则改写如消息变化贡献 1 个 changed 命中而不是每个修订版本各 1 个把 1 个 invalid-argument-type 诊断替换为 1 个 no-matching-overload 诊断前者贡献 1 个 removed 命中、后者贡献 1 个 added 命中共2 个命中诊断总数 各规则计数之和。从源码侧看这套不净额抵消的哲学与ruff-ecosystem的RuleChanges实现一致python/ruff-ecosystem/ruff_ecosystem/check.pyadded_violations、removed_violations、added_fixes、removed_fixes四个 Counter 分别累计汇总时N -M分开展示绝不互相抵消。5.4 报告策略中的排除项忽略来自 ecosystem-analyzer 的所有unknown-rule诊断变化从复现任务、报告条目和命中计数中全部排除省略不稳定的诊断变化、未变化的故障、以及不改变观察结果的频率波动。六、最小复现器minimal reproducer的规范模板注释给出了最小复现器的完整规范最小复现器应用紧贴每一行上方的注释标注每个新增、改变或移除的诊断必须包含两个修订版本merge base 与 PR的完整错误消息与错误码包括重复项模板给出的示例结构from typing import Final # Merge base: [error-code-1] Some error message # PR: no diagnostic x: Final 42 if x: # Merge base: [error-code-2] Some error message # PR: [error-code-2] Some other error message Y 56补充规则只为已变化的规则或尚未覆盖的独立成因添加示例不要仅为给另一个规则单独示例而重复等价复现器用文字标签而非额外的小节标题来区分示例。这与 .agents/skills/minimizing-ty-ecosystem-changes/SKILL.md 的最小化目标一致尽量自包含、去掉可避免的导入与定义、保留底层触发原因如果最小化掩盖了真实世界的代码模式要恢复有意义的名称或足够的上下文结构并用散文说明连接关系。6.1 指向既有 ty 缺陷如果某个诊断变化暴露了 ty 的既有短板模板要求搜索 astral-sh/ty 问题跟踪器中覆盖该确切短板的 issue并只在存在匹配 issue 时加入以下段落**Existing ty issues:** ty#issue-number注意不要把不正确的第三方注解误认为 ty 短板见 .agents/skills/summarise-ecosystem-results/SKILL.md 工作流第 6 步。七、Reproduction复现信息章节报告末尾固定为## Reproduction内容是一个details折叠块逐项列出复现所需的精确环境与版本信息## Reproduction details - Detailed report: ecosystem-analyzer report - Actions run: run id, attempt attempt - Ruff comparison: merge-base to pr-revision - ecosystem-analyzer: revision - mypy-primer: revision - Dependency cutoff: EXCLUDE_NEWER - Project Python: project: version, ... - Python target platform: project: effective platform, ... - Execution environment: OS and architecture used for reproduction; uv version; relevant checker environment settings, including TY_UV set or unset; any difference from the CI runner - Checker deadline: deadline in seconds; analyzer profile - Project analysis mode: project: strict or non-strict, ... - Comparison method: concise exact commands or method used to run both copied ty binaries, including --config analysis.strict-equality-semanticstrue and --config analysis.strict-generic-narrowingtrue for strict projects /details这些字段与仓库中证据采集工具的输出一一对应scripts/collect_ty_ecosystem_run_metadata.py 会从 Actions 运行日志中解析Merge base:、PR commit:、EXCLUDE_NEWER:、MERGE_BASE:等键值从 uv.lock 解析ecosystem-analyzer修订从 mypy-primer 的 pyproject 解析其修订并解析每个项目的 CI Python 版本最终输出包含run、ruffmerge_base/pr_revision、exclude_newer、ecosystem_analyzer、mypy_primer、project_python、analysis_jobs、ty_config的 JSON 清单其中--config analysis.strict-equality-semanticstrue与--config analysis.strict-generic-narrowingtrue两个严格模式开关正是 .agents/skills/minimizing-ty-ecosystem-changes/SKILL.md 复现脚本中针对 strict 项目追加的配置用户级配置的原始内容来自 .github/ty-ecosystem.toml该文件开启了blanket-ignore-comment、disjoint-cast、division-by-zero、dynamic-function-decorator-return、truthiness-test-of-none-union、missing-type-argument、possibly-unresolved-reference、unsound-return-statement、unsound-yield、unsupported-dynamic-base、unsound-assignment、redundant-condition-strict等默认关闭的规则为 warn 级别并带#:schema ../ty.schema.json指向 ty.schema.json。模板同时明令禁止的内容包括不提及新 panic/溢出/超时的缺失、不添加变更计数表、机器人更新时间戳、复现完整性台账、导入审计细节、穷尽式溯源附录、裸 URL 或工件哈希。八、模板与仓库工具链的配合流程8.1 证据冻结evidence freeze在动笔之前必须先把证据冻结详见 .agents/skills/summarise-ecosystem-results/references/evidence-acquisition.md优先保留用户显式提供的详细报告或 ecosystem-results 评论只有用户未提供时才去查找 PR 当前评论一旦可访问就保存所选部署报告随后确定其匹配的 PR、Actions 运行与 attempt绝不用更新的评论、报告、PR 修订、工作流运行或上报 attempt 来替代创建唯一快照目录保存匹配评论如有与所选 attempt 的有效 job 图检查运行工件gh run download无法选择 attempt且新的 rerun 可能在不改变 Ruff 修订的情况下替换旧 attempt 的工件因此下载前必须验证full-report与各 diagnostics shard 均产生于所选 attempt 的对应任务优先使用所选 attempt 的已验证full-report/diff.json作为权威结构化变更清单保留匹配的冻结 HTML 报告并把评论用于方向性参考JSON 报告不可用时回退到冻结的 HTML 报告由于gh调用可能跨越不同 shell所有直接或间接gh调用都必须加GH_TELEMETRYfalse前缀。8.2 复现与最小化每个保留的、可归因于源码的诊断或 panic都必须先用精确环境复现忽略既往记忆与本地旧工件对于每个不同的、可归因于源码的行为变化都要走完 .agents/skills/minimizing-ty-ecosystem-changes/references/advanced-minimization.md 的完整化简循环并做最终审计复现运行器 scripts/run_ty_ecosystem_repro.py 会恢复清单中记录的 checker 环境TY_UV、UV_LOCKED、RUST_BACKTRACE值为 null 时表示未设置并执行 unset、强制 deadline并以 JSON 记录结果其自身成功退出只代表结果已记录不代表检查成功项目准备可借助 scripts/setup_primer_project.py 按精确修订、Python 版本与--exclude-newer拉取 mypy-primer 项目。8.3 并行执行与汇总当报告包含多个受影响项目或可独立调查的条目时skill 明确要求启动子代理参考 .agents/skills/summarise-ecosystem-results/references/subagent-handoff.md主代理持有冻结证据、共享 profiling 二进制、配置、协调与最终报告各子代理获得不重叠的项目或明确条目且表面相似只能用于调度、不能用于断定因果等价。若存在多个独立任务却未启动子代理必须记录具体原因。最终主代理要跨子代理结果做去重与综合只有相同 base-to-PR 行为、底层触发、解释与复现器能覆盖每条代表条目时才合并复现器诊断文本相同或显示的Todo类型相同不足以证明等价。报告围绕这些主题构建解释代表性示例与更广泛生态系统影响之间的连接。九、写作与校验检查清单按 .agents/skills/summarise-ecosystem-results/SKILL.md 工作流第 7 步交付前必须验证读者能否仅凭叙述与代表性示例就理解主要生态系统模式及其意义模板的呈现与覆盖要求是否满足每个可归因于源码的行为变化是否有满足最小化完成标准的复现器主代理必须核实每个保留的导入都是必要的既不删除它、也不内联其定义能保持底层行为对保留的第三方导入还要验证库的身份或第三方搜索路径分类对识别的 ty 行为是必要的每个最小化示例及其解释是否让原始真实代码模式可理解若被最小化掩盖需恢复有意义的名称或足够上下文后重新验证两个修订版本散文是否准确描述最终示例每个变化编号、链接、诊断、复现器来源与因果指纹是否在需要时核查无误。十、结语.agents/skills/summarise-ecosystem-results/assets/report-template.md表面上是一份 Markdown 模板实际上定义了 ruff/ty 团队把一次 PR 的生态系统实验转化为可发布结论的完整契约它以项目故障 → 间歇性严重故障 → 诊断变化 → 复现信息的固定骨架组织证据用精确的计数规则不净额抵消、含重复、按命中计保证统计可审计用最小复现器与永久链接保证每个结论可复现、可回溯并用省略未变化内容、忽略 unknown-rule、禁止台账式记录等策略保证报告聚焦于读者需要的信息。配合 scripts/collect_ty_ecosystem_run_metadata.py、scripts/run_ty_ecosystem_repro.py、.agents/skills/minimizing-ty-ecosystem-changes/SKILL.md 以及 python/ruff-ecosystem 工具链任何开发者都可以按此规范把一次类型检查器的改动对真实世界项目的影响写成一份信息密度高、证据链完整、可直接评审的摘要报告。赞分享开发工具Lint格式化静态分析CLI【免费下载链接】ruffAn extremely fast Python linter and code formatter, written in Rust.项目地址https://gitcode.com/GitHub_Trending/ru/ruff点击查看免费下载相关推荐Anthropic Cookbook摘要结果文本摘要效果评估Anthropic Cookbook摘要结果文本摘要效果评估 摘要技术评估体系深度解析 在大语言模型应用中文本摘要Text Summarization是示例工程文本摘要新范式DeepPavlov双引擎摘要系统实现指南文本摘要新范式DeepPavlov双引擎摘要系统实现指南 你是否还在为处理冗长文档效率低下而困扰是否需要快速从海量文本中提取核心信息本文将带你探索如何利用人工智能NLP深度学习Dify.AI文本摘要自动摘要生成Dify.AI文本摘要自动摘要生成 还在为海量文本信息而头疼面对冗长的报告、文章、邮件如何快速提取核心要点Dify.AI的文本摘要功能让你一键解决信息过人工智能大模型LLMOpsAI 应用RAGAI Agent低代码上一篇终极指南如何安全高效地安装Switch大气层定制固件系统下一篇Delta模拟器作弊码完整指南30秒启用金手指自定义代码一步到位创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ruff / ty 生态系统结果摘要报告规范：从 diff.json 到可发布的 GitHub 摘要
开发工具Lint格式化静态分析CLI【免费下载链接】ruffAn extremely fast Python linter and code formatter, written in Rust.项目地址https://gitcode.com/GitHub_Trending/ru/ruff点击查看免费下载导读本文面向在 ruffAstral 出品的 Python 静态检查与类型检查工具链仓库中参与 ty 类型检查器 PR 评审的开发者系统讲解仓库内定义的ty 生态系统结果摘要报告编写规范模板位于 .agents/skills/summarise-ecosystem-results/assets/report-template.md。读完本文你将掌握报告的标准章节骨架项目故障、间歇性严重故障、诊断变化、复现信息、每条诊断/故障的命中计数规则、最小复现示例的写法以及如何借助仓库中的证据采集脚本scripts/collect_ty_ecosystem_run_metadata.py和复现运行器scripts/run_ty_ecosystem_repro.py把一次 PR 的生态系统实验转化为一份事实准确、可直接作为 GitHub 评论发布的摘要。一、模板在仓库中的定位与整体契约1.1 模板服务于哪类任务该模板是 .agents/skills/summarise-ecosystem-results/SKILL.md 的交付物规范。该 skill 在用户提出总结生态系统结果summarise ecosystem results这个 ty 生态系统报告里改了什么等请求时被调用输入通常是PR 编号、PR URL、GitHub 上的 ecosystem-results 评论或由ecosystem-analyzer生成的详细 HTML 报告输出则是仓库根目录下命名为PR_number_ECOSYSTEM_SUMMARY.md的 Markdown 文件。模板开头的 HTML 注释是整个报告格式的契约明确要求替换所有占位符并删除所有 HTML 注释后再呈现报告每个散文段落和列表项保持在单行内便于 GitHub 评论渲染每个章节内保留的变化小节连续编号且每个章节从 1 重新开始尽量把报告控制在 100 个变化小节以下但为了清晰、完整的覆盖可以超出此目标相关的原因可以合并到同一主题下但如果行为不同必须用各自的解释和示例分别说明不能为了凑小节数而把不同原因混为一谈。1.2 报告的交付形态必须是 GitHub 风格的 MarkdownGitHub-flavored Markdown适合直接作为 GitHub 评论发布外部源码位置一律用永久链接permalink表示格式如project file.py:123严禁输出裸 URL所有占位符、HTML 注释必须移除如果在一个 Codex App 线程中只要求做摘要这件事应把线程重命名为PR ecosystem summary。仓库中与之一一对应的既有实现可作参照ruff-ecosystem的 Markdown 渲染器python/ruff-ecosystem/ruff_ecosystem/markdown.py同样采用detailssummary…/summary…/details折叠结构、在标题中给出N -M增减统计并把差异包裹进pre或 diff 代码块中展示。二、报告标题与开篇摘要模板固定标题为# PR #number ecosystem summary紧随标题的是开篇摘要模板以占位符标注要求不超过两段精炼总结对项目故障和诊断行为的有意义变化包括涉及间歇性严重故障的变化及其意义开篇就要给出读者需要的分析结论不要描述报告是如何生成的。这与 skill 的优先级一致把读者能直接消化改了什么、为什么改、哪些反复出现的代码模式导致了这些影响放在最前面用示例展示变化而非冗长散文见 .agents/skills/summarise-ecosystem-results/SKILL.md 的 Priorities 一节。三、Project failures项目故障章节3.1 何时包含此章节只有当稳定的项目故障发生变化时才包含整个章节模板注释明确要求没有稳定项目故障变化就省略整个章节。每个不同的故障重复一个编号小节。3.2 小节结构## Project failures (N sections) ### 1. New, fixed, or changed project failure **per-outcome and per-rule hit counts, as applicable** details summaryAffected projects/summary - project: merge base: base outcome; PR: PR outcome. /details Explain the crash, panic, overflow, timeout, or abnormal exit, including relevant stderr where applicable.3.3 计数规则故障小节按每个受影响项目 × 每个不同的已报告故障结果计 1 个命中无论该结果在多少次运行中出现例如一次崩溃在 10 次运行中的 3 次新出现贡献 1 个故障命中但受影响的项目条目中必须保留 3/10 的频率信息同时保留合并基线merge base的频率故障计数与诊断总数分开统计如果某个故障小节同时覆盖诊断变化则也要给出按规则的计数。这一规则与 .agents/skills/summarise-ecosystem-results/SKILL.md 中的 Reporting Policy 相呼应报告新出现、被修复或有意义变化的 panic、崩溃、溢出和超时当涉及间歇性行为时要报告 merge base 与 PR 两侧的运行频率。3.4 最小复现器模板注释规定只有当故障能归因于源代码时才包含已验证的最小复现器否则省略该代码块minimal reproducer这与 .agents/skills/minimizing-ty-ecosystem-changes/SKILL.md 的先复现再解释不变量一脉相承复现器必须经过验证且保留底层触发原因而不仅是诊断规则、消息或显示的类型。四、Intermittent severe failures间歇性严重故障章节4.1 何时包含此章节只有当涉及间歇性结果的严重故障发生变化时才包含整个章节每个不同的变化重复一个编号小节。例如新出现或行为变化的间歇性 panic、崩溃、溢出、超时。4.2 小节结构## Intermittent severe failures (N sections) ### 1. New or changed intermittent panic, crash, overflow, or timeout **per-outcome and per-rule hit counts, as applicable** details summaryAffected projects/summary - project: merge base: base outcome and count/runs, or not present; PR: PR outcome and count/runs, or not present. /details Explain the change in failure behavior and relevant stderr. Do not include unchanged failures or frequency-only fluctuations.关键约束受影响项目的条目中必须记录merge base 与 PR 各自的结果及 count/runs例如 3/10不存在则写 not present只解释故障行为的变化和相关 stderr不得包含未变化的故障或仅频率波动的变化。在复现侧scripts/run_ty_ecosystem_repro.py 会以 JSON 输出timed_out与return_code超时给出true与null与 analyzer 的分类一致超时运行产生的部分诊断会被丢弃。这与模板把超时单列为一种故障结果、并与普通退出码区分的规则吻合。五、Diagnostic changes诊断变化章节5.1 整体结构与排序当稳定的诊断行为发生变化时才包含整个章节相关的成因应组织到主题性小节中。诊断小节及其子小节按生态系统总命中数降序排列descending total ecosystem hit count。5.2 小节结构## Diagnostic changes (N sections) ### 1. Common theme or behavior change **count rule; count other-rule** details summaryReport entries/summary - project1 file1.py:line: added, removed, or changed rule. - project1 file2.py:line: added, removed, or changed other-rule (count duplicate occurrences). - project2 file1.py:line: added, removed, or changed rule. /details Concisely explain the common theme and exact behavior on the merge base and PR. Distinguish related causes with separate explanations and examples, and identify which entries each example explains. Cover every changed rule with an example; one example may cover multiple rules when the same cause and explanation account for all of them.要点每个小节标题下紧跟一句加粗的按规则诊断计数且每个规则计数只出现一次详尽的条目清单必须放在details块内解释与示例放在块外每条记录必须标识诊断的来源永久链接、规则以及它是 added新增、removed移除还是 changed改写保留重复出现用显式倍数标注(N duplicate occurrences)对没有源诊断的故障列出受影响项目的结果小节的清单与示例要和小节计数一致所有小节清单要与最终报告清单对账保证每个保留条目恰好出现一次。5.3 计数规则最易出错的部分模板注释给出了精确的计分约定计数代表诊断出现次数含重复而不是项目数或示例数每次新增或移除出现都为自己的规则贡献 1 个命中不把新增与移除做净额抵消additions 和 removals 各自累计已验证的同规则改写如消息变化贡献 1 个 changed 命中而不是每个修订版本各 1 个把 1 个 invalid-argument-type 诊断替换为 1 个 no-matching-overload 诊断前者贡献 1 个 removed 命中、后者贡献 1 个 added 命中共2 个命中诊断总数 各规则计数之和。从源码侧看这套不净额抵消的哲学与ruff-ecosystem的RuleChanges实现一致python/ruff-ecosystem/ruff_ecosystem/check.pyadded_violations、removed_violations、added_fixes、removed_fixes四个 Counter 分别累计汇总时N -M分开展示绝不互相抵消。5.4 报告策略中的排除项忽略来自 ecosystem-analyzer 的所有unknown-rule诊断变化从复现任务、报告条目和命中计数中全部排除省略不稳定的诊断变化、未变化的故障、以及不改变观察结果的频率波动。六、最小复现器minimal reproducer的规范模板注释给出了最小复现器的完整规范最小复现器应用紧贴每一行上方的注释标注每个新增、改变或移除的诊断必须包含两个修订版本merge base 与 PR的完整错误消息与错误码包括重复项模板给出的示例结构from typing import Final # Merge base: [error-code-1] Some error message # PR: no diagnostic x: Final 42 if x: # Merge base: [error-code-2] Some error message # PR: [error-code-2] Some other error message Y 56补充规则只为已变化的规则或尚未覆盖的独立成因添加示例不要仅为给另一个规则单独示例而重复等价复现器用文字标签而非额外的小节标题来区分示例。这与 .agents/skills/minimizing-ty-ecosystem-changes/SKILL.md 的最小化目标一致尽量自包含、去掉可避免的导入与定义、保留底层触发原因如果最小化掩盖了真实世界的代码模式要恢复有意义的名称或足够的上下文结构并用散文说明连接关系。6.1 指向既有 ty 缺陷如果某个诊断变化暴露了 ty 的既有短板模板要求搜索 astral-sh/ty 问题跟踪器中覆盖该确切短板的 issue并只在存在匹配 issue 时加入以下段落**Existing ty issues:** ty#issue-number注意不要把不正确的第三方注解误认为 ty 短板见 .agents/skills/summarise-ecosystem-results/SKILL.md 工作流第 6 步。七、Reproduction复现信息章节报告末尾固定为## Reproduction内容是一个details折叠块逐项列出复现所需的精确环境与版本信息## Reproduction details - Detailed report: ecosystem-analyzer report - Actions run: run id, attempt attempt - Ruff comparison: merge-base to pr-revision - ecosystem-analyzer: revision - mypy-primer: revision - Dependency cutoff: EXCLUDE_NEWER - Project Python: project: version, ... - Python target platform: project: effective platform, ... - Execution environment: OS and architecture used for reproduction; uv version; relevant checker environment settings, including TY_UV set or unset; any difference from the CI runner - Checker deadline: deadline in seconds; analyzer profile - Project analysis mode: project: strict or non-strict, ... - Comparison method: concise exact commands or method used to run both copied ty binaries, including --config analysis.strict-equality-semanticstrue and --config analysis.strict-generic-narrowingtrue for strict projects /details这些字段与仓库中证据采集工具的输出一一对应scripts/collect_ty_ecosystem_run_metadata.py 会从 Actions 运行日志中解析Merge base:、PR commit:、EXCLUDE_NEWER:、MERGE_BASE:等键值从 uv.lock 解析ecosystem-analyzer修订从 mypy-primer 的 pyproject 解析其修订并解析每个项目的 CI Python 版本最终输出包含run、ruffmerge_base/pr_revision、exclude_newer、ecosystem_analyzer、mypy_primer、project_python、analysis_jobs、ty_config的 JSON 清单其中--config analysis.strict-equality-semanticstrue与--config analysis.strict-generic-narrowingtrue两个严格模式开关正是 .agents/skills/minimizing-ty-ecosystem-changes/SKILL.md 复现脚本中针对 strict 项目追加的配置用户级配置的原始内容来自 .github/ty-ecosystem.toml该文件开启了blanket-ignore-comment、disjoint-cast、division-by-zero、dynamic-function-decorator-return、truthiness-test-of-none-union、missing-type-argument、possibly-unresolved-reference、unsound-return-statement、unsound-yield、unsupported-dynamic-base、unsound-assignment、redundant-condition-strict等默认关闭的规则为 warn 级别并带#:schema ../ty.schema.json指向 ty.schema.json。模板同时明令禁止的内容包括不提及新 panic/溢出/超时的缺失、不添加变更计数表、机器人更新时间戳、复现完整性台账、导入审计细节、穷尽式溯源附录、裸 URL 或工件哈希。八、模板与仓库工具链的配合流程8.1 证据冻结evidence freeze在动笔之前必须先把证据冻结详见 .agents/skills/summarise-ecosystem-results/references/evidence-acquisition.md优先保留用户显式提供的详细报告或 ecosystem-results 评论只有用户未提供时才去查找 PR 当前评论一旦可访问就保存所选部署报告随后确定其匹配的 PR、Actions 运行与 attempt绝不用更新的评论、报告、PR 修订、工作流运行或上报 attempt 来替代创建唯一快照目录保存匹配评论如有与所选 attempt 的有效 job 图检查运行工件gh run download无法选择 attempt且新的 rerun 可能在不改变 Ruff 修订的情况下替换旧 attempt 的工件因此下载前必须验证full-report与各 diagnostics shard 均产生于所选 attempt 的对应任务优先使用所选 attempt 的已验证full-report/diff.json作为权威结构化变更清单保留匹配的冻结 HTML 报告并把评论用于方向性参考JSON 报告不可用时回退到冻结的 HTML 报告由于gh调用可能跨越不同 shell所有直接或间接gh调用都必须加GH_TELEMETRYfalse前缀。8.2 复现与最小化每个保留的、可归因于源码的诊断或 panic都必须先用精确环境复现忽略既往记忆与本地旧工件对于每个不同的、可归因于源码的行为变化都要走完 .agents/skills/minimizing-ty-ecosystem-changes/references/advanced-minimization.md 的完整化简循环并做最终审计复现运行器 scripts/run_ty_ecosystem_repro.py 会恢复清单中记录的 checker 环境TY_UV、UV_LOCKED、RUST_BACKTRACE值为 null 时表示未设置并执行 unset、强制 deadline并以 JSON 记录结果其自身成功退出只代表结果已记录不代表检查成功项目准备可借助 scripts/setup_primer_project.py 按精确修订、Python 版本与--exclude-newer拉取 mypy-primer 项目。8.3 并行执行与汇总当报告包含多个受影响项目或可独立调查的条目时skill 明确要求启动子代理参考 .agents/skills/summarise-ecosystem-results/references/subagent-handoff.md主代理持有冻结证据、共享 profiling 二进制、配置、协调与最终报告各子代理获得不重叠的项目或明确条目且表面相似只能用于调度、不能用于断定因果等价。若存在多个独立任务却未启动子代理必须记录具体原因。最终主代理要跨子代理结果做去重与综合只有相同 base-to-PR 行为、底层触发、解释与复现器能覆盖每条代表条目时才合并复现器诊断文本相同或显示的Todo类型相同不足以证明等价。报告围绕这些主题构建解释代表性示例与更广泛生态系统影响之间的连接。九、写作与校验检查清单按 .agents/skills/summarise-ecosystem-results/SKILL.md 工作流第 7 步交付前必须验证读者能否仅凭叙述与代表性示例就理解主要生态系统模式及其意义模板的呈现与覆盖要求是否满足每个可归因于源码的行为变化是否有满足最小化完成标准的复现器主代理必须核实每个保留的导入都是必要的既不删除它、也不内联其定义能保持底层行为对保留的第三方导入还要验证库的身份或第三方搜索路径分类对识别的 ty 行为是必要的每个最小化示例及其解释是否让原始真实代码模式可理解若被最小化掩盖需恢复有意义的名称或足够上下文后重新验证两个修订版本散文是否准确描述最终示例每个变化编号、链接、诊断、复现器来源与因果指纹是否在需要时核查无误。十、结语.agents/skills/summarise-ecosystem-results/assets/report-template.md表面上是一份 Markdown 模板实际上定义了 ruff/ty 团队把一次 PR 的生态系统实验转化为可发布结论的完整契约它以项目故障 → 间歇性严重故障 → 诊断变化 → 复现信息的固定骨架组织证据用精确的计数规则不净额抵消、含重复、按命中计保证统计可审计用最小复现器与永久链接保证每个结论可复现、可回溯并用省略未变化内容、忽略 unknown-rule、禁止台账式记录等策略保证报告聚焦于读者需要的信息。配合 scripts/collect_ty_ecosystem_run_metadata.py、scripts/run_ty_ecosystem_repro.py、.agents/skills/minimizing-ty-ecosystem-changes/SKILL.md 以及 python/ruff-ecosystem 工具链任何开发者都可以按此规范把一次类型检查器的改动对真实世界项目的影响写成一份信息密度高、证据链完整、可直接评审的摘要报告。赞分享开发工具Lint格式化静态分析CLI【免费下载链接】ruffAn extremely fast Python linter and code formatter, written in Rust.项目地址https://gitcode.com/GitHub_Trending/ru/ruff点击查看免费下载相关推荐Anthropic Cookbook摘要结果文本摘要效果评估Anthropic Cookbook摘要结果文本摘要效果评估 摘要技术评估体系深度解析 在大语言模型应用中文本摘要Text Summarization是示例工程文本摘要新范式DeepPavlov双引擎摘要系统实现指南文本摘要新范式DeepPavlov双引擎摘要系统实现指南 你是否还在为处理冗长文档效率低下而困扰是否需要快速从海量文本中提取核心信息本文将带你探索如何利用人工智能NLP深度学习Dify.AI文本摘要自动摘要生成Dify.AI文本摘要自动摘要生成 还在为海量文本信息而头疼面对冗长的报告、文章、邮件如何快速提取核心要点Dify.AI的文本摘要功能让你一键解决信息过人工智能大模型LLMOpsAI 应用RAGAI Agent低代码上一篇终极指南如何安全高效地安装Switch大气层定制固件系统下一篇Delta模拟器作弊码完整指南30秒启用金手指自定义代码一步到位创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考