Slang 项目文档锚定测试束的 Agent 审阅流程_review.md审阅提示词深度解析【免费下载链接】slangMaking it easier to work with shaders项目地址: https://gitcode.com/GitHub_Trending/sl/slang本篇技术指南围绕 Slangshader-slang仓库中docs/generated/tests智能体化测试套件的审阅环节展开核心文献为 docs/generated/tests/_meta/prompts/_review.md。该提示词定义了一个由非生成方模型家族执行的测试束审阅契约逐条核验测试是否真正锚定文档声明、CHECK 断言是否稳健、元数据是否合规并产出结构化的审阅报告。读完本文你将掌握 Slang 项目中文档声明 → 测试生成 → 交叉审阅 → 修复与反馈全链路的运作方式以及审阅报告 YAML 格式、严重度分级与 FileCheck 模式卫生学pattern hygiene的具体实践。一、背景Slang 仓库中的智能体化测试套件Slang 编译器仓库项目主页见 README.md定位为 Making it easier to work with shaders在 docs/generated/tests/ 下维护了一套**文档锚定doc-anchored**的智能体化测试套件。其核心思想是每一个测试都必须追溯到某一条文档声明而不是为了打中某一行源码而编写。根据 docs/generated/tests/_meta/PIPELINE.md 的说明测试套件由两棵并行目录树构成各自承担不同职责测试树锚定的文档角色docs/generated/tests/conformance/docs/language-reference/人工编写的规范规范符合性测试失败即规范 vs 编译器漂移信号docs/generated/tests/design/area/docs/generated/design/LLM 反推的设计文档回归覆盖测试失败即已知行为的回归两棵树被刻意允许在同一编译器表面上重叠——它们验证的是不同性质规范符合性 vs 行为回归。当conformance/测试失败而对应的design/测试通过时这正是套件设计要暴露的规范与编译器漂移信号。每个测试束bundle由 docs/generated/tests/_meta/manifest.yaml 登记包含source_doc声明来源文档、watched_paths变更会使束失效的编译器源码、depends_on与coverage_targets等元信息。束内的每个.slang测试文件必须以//META块开头声明doc_ref指向真实锚点、purpose、intent、doc_section_digest等字段。二、审阅环节在流水线中的定位整个流水线生成 → 审阅 → 修复 → 反馈由 docs/generated/tests/_meta/CAMPAIGN.md 编排。审阅是其中承上启下的关键关卡生成另一模型家族→ 审阅本提示词不同模型家族→ 修复remediate→ lint/verify → CI 夜间回归_review.md开篇的拒绝横幅Refusal banner揭示了本环节最独特的机制如果执行者自我识别为 Claude / Anthropic 模型必须输出REFUSED: Claude model detected; the review step requires a different model family并停止。审阅环节刻意由与生成束不同的模型家族执行目的是让幻觉与契约违背能被具有不同盲区的模型捕获——生成者与审阅者同族会产生系统性盲区交叉验证才能形成有效的质量闸门。与之对称修复环节的提示词 docs/generated/tests/_meta/prompts/_remediate.md 则要求执行者必须是生成束的同一模型家族Claude/Anthropic因为修复动作改写测试以匹配引用的声明、调整元数据与原始生成时对提示词的解释紧密耦合。审阅者的输入包括束的README.md与全部.slang文件、束的source_doc、分节提示词与 docs/generated/tests/_meta/prompts/_common.md、以及束记录的source_commit处已解析的受监视源码仅用于核验不得用于寻找新测试思路。输出则是一份报告落在docs/generated/tests/_meta/reviews/bundle-key.review.md。三、审阅契约逐测试检查The Contract审阅者对照一份九条契约逐测试核验。这些条目从测试是否真在验证文档声明到断言是否稳健层层递进1. 文档锚定Doc-anchored检查//META: doc_ref是否解析到source_doc中的真实锚点且被引用章节的文本是否确实包含该测试要验证的声明。这一条直接对应 docs/generated/tests/_meta/prompts/_common.md 中最重要的规则每个测试必须锚定到文档声明doc_ref是形如docs/language-reference/expressions-literal.md#integer-literal-expressions的单一path#anchor。锚点必须按 GitHub 的规则从标题推导小写、删除标点、空格转连字符例如标题### MemberExpr / StaticMemberExpr的锚点是#memberexpr--staticmemberexpr双连字符。2. 声明得到验证Claim verified检查测试的purpose是否复述了被引用章节且测试主体实际验证了purpose声称的内容。这堵住了目的写得好、断言却测了别的东西的伪测试。3. 非源码定向Not source-targeted检查测试是为了验证文档化声明而写还是为了打中slangc的特定行/分支而写——后者必须标记。束内不得包含任何源码定向测试。这与 docs/generated/tests/_meta/prompts/_expand.md 的硬性规则一致展开束时操作者不得提供任何未覆盖源码行信息测试永远只能源于文档。4. 可编译性Compiles检查指令行语法是否合法、着色器主体在声明目标下是否应该能通过slangc编译。注意审阅者实际不运行slangc——这是纯阅读式审阅reading review由后续的regenerate.py verify承担真实执行。4b. CHECK 模式稳健性CHECK patterns are robust这是审阅中最容易发现问题、也是最常导致过 lint 却在 FileCheck 下失败的环节参照_common.md的 FileCheck / CHECK pattern hygiene 一节需标记以下六类问题钉死了生成式 ID/名字字面量%29、_S3、main_0或对操作数使用纯数字捕获%{{[0-9]}}。SPIR-V 反汇编在部分运行模式使用友好名%f_0在另一些模式使用数字——钉死其中一种形式会在另一种模式下失败。正确写法是%{{[A-Za-z0-9_]}}。未转义的[[...]]或{{字面量Metal/HLSL 属性会原样发射[[...]]而 FileCheck 把[[...]]当作变量引用、把{{...}}当作正则。必须写成{{\[\[}}unroll{{\]\]}}。短而未锚定的 CHECK/CHECK-NOT 成为真实 token 的子串OpFunction会命中OpFunctionEndStructuredBuffer会命中RWStructuredBuffer——应使用最具体的 token 并用{{^}}锚定。顺序 CHECK 假设了错误的发射顺序被调者先于入口点发射、IR 转储按 pass 自上而下——不确定顺序时应改用CHECK-DAG。依赖优化的断言slang-test 默认-O0若声明是助手被内联/调用消失指令上必须加-O1否则应断言未优化的形态。钉死了声明并不依赖的 token典型是紧邻被测对象的声明限定符__device__、__noinline__、inline、static或声明从未提及的 decoration。判断标准如果该 token 变了锚定的声明会变假吗不会——就应通配或省略规则 8。在目标不支持的特性上做断言如String在cppkernel目标上不可用发射 E55213却在host-cpp上可用。目标无法表达声明时应写负向/诊断指令钉住诊断或记入## Untested claims绝不可放宽 CHECK 来凑绿。DIAGNOSTIC_TEST 问题编造消息字符串、错位 caret、non-exhaustive使用错误所有诊断都已标注时出现、或仍有次要 note 未标注时缺失。5. 意图分类正确Intent classified correctlyfunctional主声明、expansion重读文档派生的边角情况、negative诊断/失败测试、regression仅当引用了已修复的问题。分类错误即视为问题。6. 无重复No duplicates同一束内两个测试不应以相同形态锻炼同一锚点。四、束级检查For the bundle as a whole7. 前置元数据有效Front-matter validREADME.md与每个//META块中的每个必需键都必须存在。参照_common.md束 README 必须以 YAML 前置块开头generated: true、model、generated_at、source_commit、watched_paths_digest、source_doc、source_doc_digest、warning正文固定四个章节## Intent、## Functional coverage、## Untested claims、## Doc gaps observed。8. 覆盖表一致Coverage table consistent束内每个.slang文件必须在## Functional coverage表的 Tests 列恰好出现一次Claim 单元格必须与对应测试的//META: purpose...逐字一致Anchor 列匹配//META: doc_ref...Intent 列匹配//META: intent...混合意图的声明行用逗号分隔。9. 文档缺口已记录Doc gaps recorded若文档存在束未覆盖的可见声明生成方应将其记录为## Doc gaps observed表的行。审阅者需检查是否有未列出的未覆盖声明并核对每行的Kind是否与描述吻合——例如文档列出了 X 但未给出 Slang 表层应归类为missing-surface而非undocumented-behavior。_common.md定义了完整的 Kind 受控词表missing-example、missing-surface、undocumented-behavior、cascading-only-mention、ambiguous-claim、drift-from-source该表是文档再生成的反馈通道。五、审阅报告格式审阅者将结果保存为docs/generated/tests/_meta/reviews/bundle-key.review.md结构由 docs/generated/tests/_meta/schema/review-report.schema.json 约束。报告的 YAML 前置块字段如下字段含义review_report固定为truereviewer_model审阅者模型标识不得包含 claude 或 anthropic软性强制reviewed_atISO 8601 UTC 时间戳target_bundle束键target_bundle_source_commit/watched_paths_digest/source_doc_digest从束 README 复制分别要求 7–64 位十六进制、64 位十六进制source_commit审阅时的 git HEADchecklist六个检查项doc_anchored、claims_verified、test_compiles、no_source_targeting、intent_classification、front_matter_validity每项取值pass/partial/failfinding_count发现总数整数≥0severity_breakdowncritical/major/minor/nit四个计数正文的## Findings部分使用固定列的表格式ID | Severity | File | Description | Evidence | Recommendation。每条发现附上证据如source_doc lines 412–438 do not mention specialized与可执行的建议如 Either change doc_ref to #generic-substitution, or remove the test.。若没有任何发现写作(no findings)并把finding_count与全部严重度设为 0。六、严重度分级Severity scalecritical——束不可安全使用幻觉声明、摘要不匹配、测试永远不会通过。major——意图错误、doc_ref 断裂、源码定向测试。minor——重复覆盖、误导性的 purpose 文本。nit——命名、措辞、排序。该分级与修复环节的响应动作直接挂钩major及以上的发现通常要求fixed改写或删除测试文档从未作出该声明、但该测试应该测属于rejected-out-of-scope指向文档改进任务而非新增测试。七、审阅者必须不做的事What you must NOT do三条红线构成了文档锚定审阅的伦理边界不得编辑束。只有修复环节下一阶段可以修改测试文件。不得提出需要读取未覆盖源码行号的建议。审阅是文档锚定的不是源码锚定的——这与整个套件的非源码定向原则一脉相承。不得虚构声明。文档没说的就标记测试待移除而不是为它编造引文。这三条与 docs/generated/tests/_meta/prompts/_claims.md 的声明驱动方法论呼应束的完备度以每条枚举声明要么有测试、要么有分类原因为准测试数量是过程产出而非目标。八、反馈闭环审阅如何反哺文档与编译器审阅报告并非终点。根据 PIPELINE.md 的说明套件被设计为改善自身输入文档缺口 → 文档regenerate.py doc-gaps聚合所有束的## Doc gaps observed行按锚定文档分组并生成gap_id作为下一轮设计文档生成的输入。锚定在人工规范docs/language-reference/上的缺口则进入人工分诊队列因为任何 Agent 都不得编辑该规范。发现 → 编译器分诊后的发现docs/generated/tests/_meta/findings/ 下的结构化 YAML被regenerate.py findings file归档为追踪问题修复后移除 docs/generated/tests/_meta/expected-failures.txt 中的对应条目。漂移检测 → 再生成source_doc_digest与watched_paths_digest使束在文档或受监视源码变更时变陈旧staleregenerate.py list-stale列出、mark-fresh在再生成后清除标记。审阅者的每一条major/minor发现都会经由修复报告docs/generated/tests/_meta/remediations/转化为对束的编辑或对文档/提示词/清单的改进任务从而持续收紧文档声明 — 测试断言 — 编译器行为三者之间的一致性。九、实战要点速览审阅目标是让束内每个测试同时满足锚点真实、目的复述声明、断言验证目的、非源码定向、可编译、CHECK 稳健、意图正确、无重复让束整体满足元数据有效、覆盖表一致、缺口已记录。CHECK 模式稳健性是失败高发区审阅时应优先核查生成 ID 钉死、[[...]]未转义、短 token 子串碰撞、顺序 CHECK 与发射顺序不符、无-O1的优化依赖断言、与声明无关的钉死 token。审阅报告是机器可读的结构化文档schema 见 review-report.schema.jsonchecklist六项与finding_count/severity_breakdown是后续修复环节_remediate.md逐条回应的依据。实际运行验证由regenerate.py lint/verify完成用法见 PIPELINE.md 的驱动命令参考表审阅阶段只做静态阅读式核验verify的三类结果passed/ignored/FAILED中只有FAILED需要修复后才可提交。【免费下载链接】slangMaking it easier to work with shaders项目地址: https://gitcode.com/GitHub_Trending/sl/slang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Slang 项目文档锚定测试束的 Agent 审阅流程：`_review.md` 审阅提示词深度解析
Slang 项目文档锚定测试束的 Agent 审阅流程_review.md审阅提示词深度解析【免费下载链接】slangMaking it easier to work with shaders项目地址: https://gitcode.com/GitHub_Trending/sl/slang本篇技术指南围绕 Slangshader-slang仓库中docs/generated/tests智能体化测试套件的审阅环节展开核心文献为 docs/generated/tests/_meta/prompts/_review.md。该提示词定义了一个由非生成方模型家族执行的测试束审阅契约逐条核验测试是否真正锚定文档声明、CHECK 断言是否稳健、元数据是否合规并产出结构化的审阅报告。读完本文你将掌握 Slang 项目中文档声明 → 测试生成 → 交叉审阅 → 修复与反馈全链路的运作方式以及审阅报告 YAML 格式、严重度分级与 FileCheck 模式卫生学pattern hygiene的具体实践。一、背景Slang 仓库中的智能体化测试套件Slang 编译器仓库项目主页见 README.md定位为 Making it easier to work with shaders在 docs/generated/tests/ 下维护了一套**文档锚定doc-anchored**的智能体化测试套件。其核心思想是每一个测试都必须追溯到某一条文档声明而不是为了打中某一行源码而编写。根据 docs/generated/tests/_meta/PIPELINE.md 的说明测试套件由两棵并行目录树构成各自承担不同职责测试树锚定的文档角色docs/generated/tests/conformance/docs/language-reference/人工编写的规范规范符合性测试失败即规范 vs 编译器漂移信号docs/generated/tests/design/area/docs/generated/design/LLM 反推的设计文档回归覆盖测试失败即已知行为的回归两棵树被刻意允许在同一编译器表面上重叠——它们验证的是不同性质规范符合性 vs 行为回归。当conformance/测试失败而对应的design/测试通过时这正是套件设计要暴露的规范与编译器漂移信号。每个测试束bundle由 docs/generated/tests/_meta/manifest.yaml 登记包含source_doc声明来源文档、watched_paths变更会使束失效的编译器源码、depends_on与coverage_targets等元信息。束内的每个.slang测试文件必须以//META块开头声明doc_ref指向真实锚点、purpose、intent、doc_section_digest等字段。二、审阅环节在流水线中的定位整个流水线生成 → 审阅 → 修复 → 反馈由 docs/generated/tests/_meta/CAMPAIGN.md 编排。审阅是其中承上启下的关键关卡生成另一模型家族→ 审阅本提示词不同模型家族→ 修复remediate→ lint/verify → CI 夜间回归_review.md开篇的拒绝横幅Refusal banner揭示了本环节最独特的机制如果执行者自我识别为 Claude / Anthropic 模型必须输出REFUSED: Claude model detected; the review step requires a different model family并停止。审阅环节刻意由与生成束不同的模型家族执行目的是让幻觉与契约违背能被具有不同盲区的模型捕获——生成者与审阅者同族会产生系统性盲区交叉验证才能形成有效的质量闸门。与之对称修复环节的提示词 docs/generated/tests/_meta/prompts/_remediate.md 则要求执行者必须是生成束的同一模型家族Claude/Anthropic因为修复动作改写测试以匹配引用的声明、调整元数据与原始生成时对提示词的解释紧密耦合。审阅者的输入包括束的README.md与全部.slang文件、束的source_doc、分节提示词与 docs/generated/tests/_meta/prompts/_common.md、以及束记录的source_commit处已解析的受监视源码仅用于核验不得用于寻找新测试思路。输出则是一份报告落在docs/generated/tests/_meta/reviews/bundle-key.review.md。三、审阅契约逐测试检查The Contract审阅者对照一份九条契约逐测试核验。这些条目从测试是否真在验证文档声明到断言是否稳健层层递进1. 文档锚定Doc-anchored检查//META: doc_ref是否解析到source_doc中的真实锚点且被引用章节的文本是否确实包含该测试要验证的声明。这一条直接对应 docs/generated/tests/_meta/prompts/_common.md 中最重要的规则每个测试必须锚定到文档声明doc_ref是形如docs/language-reference/expressions-literal.md#integer-literal-expressions的单一path#anchor。锚点必须按 GitHub 的规则从标题推导小写、删除标点、空格转连字符例如标题### MemberExpr / StaticMemberExpr的锚点是#memberexpr--staticmemberexpr双连字符。2. 声明得到验证Claim verified检查测试的purpose是否复述了被引用章节且测试主体实际验证了purpose声称的内容。这堵住了目的写得好、断言却测了别的东西的伪测试。3. 非源码定向Not source-targeted检查测试是为了验证文档化声明而写还是为了打中slangc的特定行/分支而写——后者必须标记。束内不得包含任何源码定向测试。这与 docs/generated/tests/_meta/prompts/_expand.md 的硬性规则一致展开束时操作者不得提供任何未覆盖源码行信息测试永远只能源于文档。4. 可编译性Compiles检查指令行语法是否合法、着色器主体在声明目标下是否应该能通过slangc编译。注意审阅者实际不运行slangc——这是纯阅读式审阅reading review由后续的regenerate.py verify承担真实执行。4b. CHECK 模式稳健性CHECK patterns are robust这是审阅中最容易发现问题、也是最常导致过 lint 却在 FileCheck 下失败的环节参照_common.md的 FileCheck / CHECK pattern hygiene 一节需标记以下六类问题钉死了生成式 ID/名字字面量%29、_S3、main_0或对操作数使用纯数字捕获%{{[0-9]}}。SPIR-V 反汇编在部分运行模式使用友好名%f_0在另一些模式使用数字——钉死其中一种形式会在另一种模式下失败。正确写法是%{{[A-Za-z0-9_]}}。未转义的[[...]]或{{字面量Metal/HLSL 属性会原样发射[[...]]而 FileCheck 把[[...]]当作变量引用、把{{...}}当作正则。必须写成{{\[\[}}unroll{{\]\]}}。短而未锚定的 CHECK/CHECK-NOT 成为真实 token 的子串OpFunction会命中OpFunctionEndStructuredBuffer会命中RWStructuredBuffer——应使用最具体的 token 并用{{^}}锚定。顺序 CHECK 假设了错误的发射顺序被调者先于入口点发射、IR 转储按 pass 自上而下——不确定顺序时应改用CHECK-DAG。依赖优化的断言slang-test 默认-O0若声明是助手被内联/调用消失指令上必须加-O1否则应断言未优化的形态。钉死了声明并不依赖的 token典型是紧邻被测对象的声明限定符__device__、__noinline__、inline、static或声明从未提及的 decoration。判断标准如果该 token 变了锚定的声明会变假吗不会——就应通配或省略规则 8。在目标不支持的特性上做断言如String在cppkernel目标上不可用发射 E55213却在host-cpp上可用。目标无法表达声明时应写负向/诊断指令钉住诊断或记入## Untested claims绝不可放宽 CHECK 来凑绿。DIAGNOSTIC_TEST 问题编造消息字符串、错位 caret、non-exhaustive使用错误所有诊断都已标注时出现、或仍有次要 note 未标注时缺失。5. 意图分类正确Intent classified correctlyfunctional主声明、expansion重读文档派生的边角情况、negative诊断/失败测试、regression仅当引用了已修复的问题。分类错误即视为问题。6. 无重复No duplicates同一束内两个测试不应以相同形态锻炼同一锚点。四、束级检查For the bundle as a whole7. 前置元数据有效Front-matter validREADME.md与每个//META块中的每个必需键都必须存在。参照_common.md束 README 必须以 YAML 前置块开头generated: true、model、generated_at、source_commit、watched_paths_digest、source_doc、source_doc_digest、warning正文固定四个章节## Intent、## Functional coverage、## Untested claims、## Doc gaps observed。8. 覆盖表一致Coverage table consistent束内每个.slang文件必须在## Functional coverage表的 Tests 列恰好出现一次Claim 单元格必须与对应测试的//META: purpose...逐字一致Anchor 列匹配//META: doc_ref...Intent 列匹配//META: intent...混合意图的声明行用逗号分隔。9. 文档缺口已记录Doc gaps recorded若文档存在束未覆盖的可见声明生成方应将其记录为## Doc gaps observed表的行。审阅者需检查是否有未列出的未覆盖声明并核对每行的Kind是否与描述吻合——例如文档列出了 X 但未给出 Slang 表层应归类为missing-surface而非undocumented-behavior。_common.md定义了完整的 Kind 受控词表missing-example、missing-surface、undocumented-behavior、cascading-only-mention、ambiguous-claim、drift-from-source该表是文档再生成的反馈通道。五、审阅报告格式审阅者将结果保存为docs/generated/tests/_meta/reviews/bundle-key.review.md结构由 docs/generated/tests/_meta/schema/review-report.schema.json 约束。报告的 YAML 前置块字段如下字段含义review_report固定为truereviewer_model审阅者模型标识不得包含 claude 或 anthropic软性强制reviewed_atISO 8601 UTC 时间戳target_bundle束键target_bundle_source_commit/watched_paths_digest/source_doc_digest从束 README 复制分别要求 7–64 位十六进制、64 位十六进制source_commit审阅时的 git HEADchecklist六个检查项doc_anchored、claims_verified、test_compiles、no_source_targeting、intent_classification、front_matter_validity每项取值pass/partial/failfinding_count发现总数整数≥0severity_breakdowncritical/major/minor/nit四个计数正文的## Findings部分使用固定列的表格式ID | Severity | File | Description | Evidence | Recommendation。每条发现附上证据如source_doc lines 412–438 do not mention specialized与可执行的建议如 Either change doc_ref to #generic-substitution, or remove the test.。若没有任何发现写作(no findings)并把finding_count与全部严重度设为 0。六、严重度分级Severity scalecritical——束不可安全使用幻觉声明、摘要不匹配、测试永远不会通过。major——意图错误、doc_ref 断裂、源码定向测试。minor——重复覆盖、误导性的 purpose 文本。nit——命名、措辞、排序。该分级与修复环节的响应动作直接挂钩major及以上的发现通常要求fixed改写或删除测试文档从未作出该声明、但该测试应该测属于rejected-out-of-scope指向文档改进任务而非新增测试。七、审阅者必须不做的事What you must NOT do三条红线构成了文档锚定审阅的伦理边界不得编辑束。只有修复环节下一阶段可以修改测试文件。不得提出需要读取未覆盖源码行号的建议。审阅是文档锚定的不是源码锚定的——这与整个套件的非源码定向原则一脉相承。不得虚构声明。文档没说的就标记测试待移除而不是为它编造引文。这三条与 docs/generated/tests/_meta/prompts/_claims.md 的声明驱动方法论呼应束的完备度以每条枚举声明要么有测试、要么有分类原因为准测试数量是过程产出而非目标。八、反馈闭环审阅如何反哺文档与编译器审阅报告并非终点。根据 PIPELINE.md 的说明套件被设计为改善自身输入文档缺口 → 文档regenerate.py doc-gaps聚合所有束的## Doc gaps observed行按锚定文档分组并生成gap_id作为下一轮设计文档生成的输入。锚定在人工规范docs/language-reference/上的缺口则进入人工分诊队列因为任何 Agent 都不得编辑该规范。发现 → 编译器分诊后的发现docs/generated/tests/_meta/findings/ 下的结构化 YAML被regenerate.py findings file归档为追踪问题修复后移除 docs/generated/tests/_meta/expected-failures.txt 中的对应条目。漂移检测 → 再生成source_doc_digest与watched_paths_digest使束在文档或受监视源码变更时变陈旧staleregenerate.py list-stale列出、mark-fresh在再生成后清除标记。审阅者的每一条major/minor发现都会经由修复报告docs/generated/tests/_meta/remediations/转化为对束的编辑或对文档/提示词/清单的改进任务从而持续收紧文档声明 — 测试断言 — 编译器行为三者之间的一致性。九、实战要点速览审阅目标是让束内每个测试同时满足锚点真实、目的复述声明、断言验证目的、非源码定向、可编译、CHECK 稳健、意图正确、无重复让束整体满足元数据有效、覆盖表一致、缺口已记录。CHECK 模式稳健性是失败高发区审阅时应优先核查生成 ID 钉死、[[...]]未转义、短 token 子串碰撞、顺序 CHECK 与发射顺序不符、无-O1的优化依赖断言、与声明无关的钉死 token。审阅报告是机器可读的结构化文档schema 见 review-report.schema.jsonchecklist六项与finding_count/severity_breakdown是后续修复环节_remediate.md逐条回应的依据。实际运行验证由regenerate.py lint/verify完成用法见 PIPELINE.md 的驱动命令参考表审阅阶段只做静态阅读式核验verify的三类结果passed/ignored/FAILED中只有FAILED需要修复后才可提交。【免费下载链接】slangMaking it easier to work with shaders项目地址: https://gitcode.com/GitHub_Trending/sl/slang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考