Slang 自主测试生成战役模式Campaign Mode协议解析基于文档声明驱动的 conformance / design 双层测试套件【免费下载链接】slangMaking it easier to work with shaders项目地址: https://gitcode.com/GitHub_Trending/sl/slang本文深入解析 Slang 编译器中用于自主批量生成测试的战役模式Campaign Mode协议——一份面向操作者或自主 Agent的批处理测试生成流程文档。它以docs/language-reference/权威规范与docs/generated/design/由源码逆向生成的架构文档为“源文档树”为每个尚未覆盖的文档生成测试包bundle并驱动每个包达到 100% 的声明覆盖率claim coverage。读完本文你将掌握该协议的分诊规则、声明枚举方法、测试包结构与//META元数据规范、regenerate.py驱动工具的全部子命令以及如何通过“结构化发现finding”把编译器 bug 与文档缺陷反馈回主干工作流。一、战役模式是什么从“文档”到“测试包”的自动化流水线Campaign战役模式定义了一个可重复执行的批处理协议操作者或自主 Agent 针对一棵源文档树source-doc tree运行批量测试生成遍历树中的每个文档为尚未覆盖的文档创建测试包bundle并通过“写一个测一个、验证一个”的方式把每个包推进到 100% 声明覆盖率。其产物目录为 docs/generated/tests/含 INDEX.md 导航与 README.md 总览。整个战役由三个关键概念构成源文档树source-doc tree测试声明的来源文档集合。测试包bundle对应一份源文档的一组测试文件存放在docs/generated/tests/bundle-key/目录下包含一个带 YAML front-matter 的README.md、N 个带//META块的.slang测试文件以及可选的.expected输出文件。声明claim文档中一条独立可验证的规范语句一条语法产生式、一个表格行、一句 “must/shall/is rejected” 句子、一个显式例外是测试的锚点与覆盖目标。战役是声明驱动而非数量驱动的一份文档被分解为扁平的声明列表包在每条声明都被沿文档承诺的维度至少一个测试覆盖、或被列入“未测试声明”并给出分类原因时才算完成。测试数量是该过程的输出而非目标——详见 prompts/_claims.md 中的方法论定义。战役模式的完整协议定义在 docs/generated/tests/_meta/CAMPAIGN.md它是围绕声明枚举/映射方法论prompts/_claims.md的编排循环分诊、节奏控制、停止条件与发现findings处理。二、两条测试树conformance 与 design 的职责划分战役由它运行在哪棵树上参数化战役源文档树测试包根目录源真相权重source-of-truth weightconformancedocs/language-reference/docs/generated/tests/conformance/权威的人工编写规范designdocs/generated/design/docs/generated/tests/design/从可能有 bug 的源码逆向而来与规范冲突时以规范为准两条树是平行且允许重叠的——它们验证的是不同性质conformance/测“规范一致性”测试失败即规范与编译器的分歧信号design/测“已固化为文档的既有行为回归”测试失败即已知行为退化。当某个conformance/测试失败而对应的design/测试通过时这正是本套件设计要暴露的“规范 vs 编译器漂移”信号应登记为 finding。从当前仓库的实际产物看conformance/树已包含 24 个与语言参考逐章对应的包如basics-program-execution、expressions-literal、types-array、generics、lexical-structure等design/树按区域组织包括pipeline/01-lex-preprocess、02-parse-ast、03-semantic-check、04-ast-to-ir、04b-pre-link-passes、04c-layout-ir、05-ir-passes、06-emit、overview、ast-reference/、ir-reference/、name-resolution/、syntax-reference/、cross-cutting/、target-pipelines/。两条树共用同一套“测试放哪里”的放置策略见 prompts/_common.md § Where the test lives语言参考描述了该声明 → 放入conformance/doc-name/否则 → 放入对应的design/包同一表面在两处都被描述 →两棵树都写因为它们的职责不同。源真相层级Source-of-truth hierarchy当同一行为在多处被描述时语言参考的优先级高于生成的设计文档docs/language-reference/*.md——人工编写的语言参考手册描述 Slang 行为应当是什么是权威规范docs/generated/design/*.md——LLM 生成的架构文档由编译器源码逆向而来可能把 bug 固化为“看似有意的行为”仅在语言参考对该行为保持沉默时作为兜底引用编译器源码——永远不作为测试的首要引用。若语言参考与设计文档对同一行为描述冲突测试锚定语言参考并让它失败——失败本身就是信号编译器只匹配其中一方由人工分诊决定是规范错了还是编译器错了。同时要在包 README 的## Doc gaps observed中写一行drift-from-source文档缺口把两处引用都写清楚供下次文档再生成时消费。三、前置条件Pre-flight开工前的三件事在启动一次战役会话前必须确认本地构建 Slangcmake --build --preset release --target slang-test slangi slangc需要slang-test测试运行器、slangi字节码解释器和slangc编译器。确认regenerate.py verify --help可调用verify子命令必须存在于当前分支它负责包裹slang-test并应用套件级 expected-failures 列表与requires-tool过滤。对 conformance 战役确认regenerate.py lang-ref-coverage能返回当前基线——这是战役的里程表odometer。驱动工具 regenerate.py 的所有命令都在仓库根目录运行python3 docs/generated/tests/_meta/regenerate.py subcommand [args...]。它无任何第三方 Python 依赖PyYAML 可用则用、但非必需仅要求 Python 3.9、可用的 git 与干净的工作区。完整子命令清单见 regenerate.md子命令用途list/list-stale打印清单中的所有包 / 将每个包分类为missing、stale、freshdigest bundle计算当前 watched-paths 与 source-doc 摘要show bundle清单条目 已解析的源文件 源文档mark-fresh bundle [--commit SHA] [--model NAME]记录一个 fresh 条目lint [bundle...]结构检查器README front-matter、每个.slang必须有//META块、doc_ref可解析index [--write]重新生成套件INDEX.md导航表doc-gaps [--source-doc path] [--tree design\|language-reference] [--format md\|json]跨包聚合文档缺口行按文档分组每行携带gap_idcoverage-gaps bundle [--from report.txt]每包未覆盖目标汇总包级expansion-candidates [--from report.json]按欠覆盖程度给包排序输出包键 分数review-status / mark-reviewed / mark-remediated两阶段审查/补救Phase D当前为桩findings list [--include-filed]/findings show id/findings file id [--dry-run]/findings dup id --of issue-number/findings fixed id --verified-at commit编译器 bug 发现的生命周期管理Phase F四、逐文档工作流从分诊到提交的九步闭环战役对源文档树中的每个文档按优先级顺序执行如下工作流。这是本协议的核心骨架每一步都配有可验证的落盘产物。步骤 1分诊文档Triage通读文档内容是否具有规范性语法产生式、行为声明、表格行、“shall/must”句子若只是纯散文引言、术语表或标记了 TODO则跳过并在§ Skipped docs中记录跳过理由。估算可测试声明数量若少于约 3 条跳过——测试包的开销不值当。仓库中已有大量分诊记录沉淀在 CAMPAIGN.md 的跳过清单里详见下文第七节例如expressions-conversions.md标记 TODO、正文为空、shaders-and-kernels.md26 行无标题、可测规范性声明不足 3 条、attributes.md陈旧、仅描述单个属性[[vk::spirv_instruction]]且只影响 SPIR-V 发射等以及若干 3–22 行的占位 stubtypes-class.md、types-special.md、basics-name-lookup.md等。同时存在“伞形/总览章节”豁免types.md、expressions.md、basics.md、basics-translation-overview.md作为描述性文档被豁免其声明由各专题子包行使。步骤 2枚举声明并映射到测试按照 prompts/_claims.md 第 1–3 节执行——这是整个战役的承重步骤在写任何测试之前先产出文档中每条规范性、可测试语句的扁平编号列表。一条声明 一个独立可验证的断言“0xFFFFFFFF无后缀、十六进制类型为uint”“前缀得到新值后缀得到旧值”是两条声明尽管可被一个文件测试“UINT_MAX 1回绕为0”是一条声明但它沿{int, uint, int64_t, uint64_t}× 每个运算符、-、*、/…倍增——一条声明、多个测试。对每条声明沿文档实际承诺的维度写测试基本用例永远存在、边界值MIN/MAX/零/NaN/±Inf、拐角用例空输入、零长数组、单元素向量、主要特性组合结构体成员、泛型内、extension后、[ForceInline]被调者内、不同类型文档声称适用的每种类型/形状/限定符、有意义的后端见下文步骤 4 的后端扇出。枚举列表作为包 README 的Claims部分入库——它是评审者与下一战役会话判断包是否完成的依据。声明数量是包的目标不是测试数量。步骤 3创建测试包Bundle清单条目在 manifest.yaml 中按conformance/doc或design/area/doc键登记组内按字母序。source_doc 文档路径watched_paths包含该文档加上 1–2 个最相关的编译器源文件。清单中的coverage_targets命名该包负责行使的 slangc 源文件绝不作为行级细节喂给写测试的 promptdepends_on列出依赖包生成顺序上依赖包先生成其 README 作为附加上下文size_cap_files是.slang文件数量的软上限lint 超限警告默认 30。示例design/pipeline/01-lex-preprocesswatched_paths指向 slang-lexer.cpp、slang-token-defs.h、slang-preprocessor.cpp 等 7 个文件coverage_targets指向 slang-lexer.cpp 与 slang-preprocessor.cpp。包目录docs/generated/tests/key/。共置的_prompt.md记录子区域与声明提取策略文档中哪些句子算声明、哪些非规范性。prompt不重复包 README 的声明列表——它解释该列表是如何推导出来的使未来再生成得到一致的枚举。包 README带 YAML front-matter、## Intent、## Claims、## Functional coverage、## Untested claims、## Doc gaps observed五部分详见下文步骤 4 之后并用regenerate.py digest bundle计算摘要。regenerate.py digest计算的watched_paths_digest与source_doc_digestSHA-256会写入 README front-matter连同generated: true、model:、generated_at:、source_commit:与警告Auto-generated. May drift from source. Do not edit by hand.。步骤 4编写测试写一个、验证一个按 prompts/_claims.md 第 3 与 5 节为每个声明 × 维度组合写一个.slang文件默认产出functional emission 成对测试每个文件带//META块引用最具体的源文档锚点。真实示例见 suffix-u-unsigned.slang//META: generatedtrue //META: modelclaude-opus-4-7 //META: generated_at2026-06-01T13:00:0000:00 //META: source_commitd25453d7f0b4867db4cb5eabf34fb6cd088cf596 //META: doc_refdocs/language-reference/expressions-literal.md#integer-literal-expressions //META: doc_section_digest769b627a9edfb98d3dcd82a049d5720ec282bc1a720cf4d1da09d5420919dd11 //META: purposeSuffix U forces an unsigned type per the suffix table; 1U resolves the uint overload, not int. //META: intentfunctional //META: pipeline_stageparse //META: warningAuto-generated. May drift from source. Do not edit by hand. // 引用文档的后缀表将小十进制值上的 U/UL/LU 映射到 uint。 // 重载决议在调用点区分字面量类型若 1U 是 uint则 uint 重载胜出。 //TEST:INTERPRET(filecheckCHECK): int probe(int x) { return 1; } int probe(uint x) { return 2; } int probe(int64_t x) { return 3; } int probe(uint64_t x) { return 4; } void main() { int picked probe(1U); //CHECK: picked2 printf(picked%d\n, picked); }//META块的必填键包括doc_ref形如path#anchor的单一引用lint 校验路径与锚点是否真实存在、doc_section_digest被引用小节正文的 SHA-256从锚点标题起到下一个同级或更高级标题止、purpose与 README 功能覆盖表中 Claim 单元格逐字一致、intent受控词汇表functional | boundary | negative | stress | expansion | regression、pipeline_stagelex | preprocess | parse | check | lower | ir-pass | layout | link | emit | runtime可选键requires-tool用于声明后端依赖dxc、fxc、nvrtc、metal-toolchain、spirv-tools、tint缺工具时verify将该测试报告为ignored而非 FAILED。//META块之后要写 1–4 行注释说明“该测试验证哪条声明、如何验证”——但严禁逐字引用文档“The doc says: …”是反模式锚点已在doc_ref、声明已在purpose正文注释只需补充推理——测试计算/发射了什么、CHECK断言什么、为何该观察能证明声明。可用测试指令由slang-test执行全部来自 prompts/_common.md指令用途//TEST:SIMPLE(filecheckCHECK):-target hlsl/glsl/spirv-asm/metal/wgsl/cuda/cpp编译为文本目标并用 FileCheck 匹配发射代码//TEST:SIMPLE(filecheckCHECK):-target dxil编译为 DXIL 字节码仅 CI//DIAGNOSTIC_TEST:SIMPLE(diagCHECK):验证诊断以期望文本/严重级/代码号发射//TEST:COMPARE_COMPUTE(filecheck-bufferCHECK):-cpu/-vk/-dx12/-cuda -output-using-type计算内核并验证缓冲值后三者仅 CI//TEST:INTERPRET(filecheckCHECK):在slangi字节码解释器下运行//TEST:SIMPLE...-dump-ir...用 FileCheck 检查 IR后端扇出纪律先对声明分类——目标无关声明词法、预处理、解析、名字查找、重载决议、泛型特化语义、常量折叠值、多数诊断、AST 形态用 1–2 条指令即可INTERPRET 或COMPARE_COMPUTE -cpu为主目标相关声明发射代码形态、内建函数降级、布局、资源绑定、能力门控必须对每个可行文本发射目标各加一条SIMPLE指令——hlsl、glsl、spirv-asm、metal、wgsl、cuda、cpp不要停在 HLSLSPIR-V。多目标时每个目标用独立的 FileCheck 前缀//TEST:SIMPLE(filecheckHLSL):-target hlsl -entry main -stage compute //TEST:SIMPLE(filecheckSPV):-target spirv-asm -entry main -stage compute //TEST:SIMPLE(filecheckMETAL):-target metal -entry main -stage compute //TEST:SIMPLE(filecheckWGSL):-target wgsl -entry main -stage compute //TEST:SIMPLE(filecheckCUDA):-target cuda -entry main -stage compute //HLSL: ... //SPV: ... //METAL: ...边界覆盖是强制的每个声明一条冒烟测试只是地板而非天花板。文档触及整数类型时必须测0、文档化MIN/MAX、MAX1溢出、超大字面量负测浮点类型必须测0.0/-0.0、最小正规数、denormal、最大有限值、±inf、NaN缓冲/数组/指针访问必须测索引0、N-1、N越界、-1下溢、运行时边界 vs 静态边界、零长缓冲、双引用别名诊断必须每个文档化诊断码一个负测、逐字引用E####与消息文本。lint 会拒绝“源文档触及强制轴但包内无对应测试”的包。每个边界值一个文件、文件名反映边界如add-uint32-max-overflow.slang、purpose指名具体边界。步骤 5边写边验证每个测试写完后立即验证slang-test path应打印100% of tests passed (1/1)再进入下一个。之后对整包运行python3 docs/generated/tests/_meta/regenerate.py lint bundle python3 docs/generated/tests/_meta/regenerate.py verify bundleverify包裹slang-test -test-dir docs/generated/tests按包过滤报告三个桶passedCHECK 匹配、ignored本机缺少指令所需后端测试仍提交、由 CI 夜班验证、FAILED指令运行但 CHECK 未匹配或诊断测试运行器报错。每个 FAILED 测试必须在提交前修复——lint 必须干净verify 必须显示FAILED: 0任何失败必须已在expected-failures.txt中。步骤 6测试揭示编译器 bug 时——写结构化 finding绝不自行提 issue战役模式的核心纪律prompts/_common.md § Reporting suspected compiler bugs绝不在战役模式中运行regenerate.py findings file id这会在会话中途刷出一堆 GitHub issue。在_meta/findings/id.yaml不是/filed/下写结构化 finding YAML其bundle:字段为包键conformance/doc或design/area/doc。字段结构由 finding.schema.json 定义必填schema_version、idkebab-case 且必须与文件名一致、suspected_kindsigsegv | wrong-diagnostic | wrong-codegen | regression | catalog-drift | doc-claim-overstated、observed_at、evidencecommand精确复现命令、source_slang工作区相对路径、observed_summary、expectedclaim一句话正确行为、citation_kind: spec | sibling-test | older-slangc | doc、citation必须可解析的真实路径、provenanceagent_model、source_commit、doc_anchor可选scope、title≤80 字符、exit_code、stderr_tail、agent_self_assessment.confidence/alternatives_considered。把受影响的测试加入 expected-failures.txt注释中指名待决 finding YAML 路径——战役模式下 expected-failures lint 接受_meta/findings/id.yaml作为合法“跟踪链接”。然后继续continue。已归档 finding 的真实示例countof-local-array-returns-bytewidth.yaml——slangi对固定大小局部数组的countof()返回字节宽度 4 而非元素数 5suspected_kind: wrong-codegen附最小复现、退出码 0、stderr 尾部、期望声明、引用文档与agent_self_assessment.confidence: medium。finding 是证据而非结论不得自行调用gh、不得尝试最小化复现那是操作者分诊时的职责、不得推测根因“这大概在特化 pass 里”是禁止的手挥、不得在可引用更强来源时引用设计文档设计文档本身是 LLM 生成的。当失败来自草稿变体/tmp文件或未保留的一次性编辑时必须把精确的失败源码内联进evidence.repro_source——一次对 17 个 finding 的分诊中有 7 个因此完全无法重跑其中 2 个产生了说服力极强的**假“已修复”**结果。lint 会在命令指名草稿路径且无repro_source时告警。步骤 7文档与编译器分歧但非编译器 bug 时——记录 doc gap当测试揭示文档虚构声明、表述含糊、或点名了不存在的特性编译器拒绝文档提出的输入如 E00017 “unknown command-line option”、E36107 “unavailable features in entry point”正确反应不是默默提交失败测试或硬塞 workaround而是在包 README 的## Doc gaps observed中记一行drift-from-source/ambiguous-claim。文档再生成工作流会消费这些行。已发现的实际案例包括SPIR-V 文档点名-validate-spirv标志而该标志并不存在只有SLANG_RUN_SPIRV_VALIDATION环境变量与-skip-spirv-validation是真实表面Metal 文档声称NonUniformResourceIndex是直通而核心模块的能力集把 Metal 排除在外、该内建根本无法编译。步骤 8lint 与 verify 整个包python3 docs/generated/tests/_meta/regenerate.py lint bundle python3 docs/generated/tests/_meta/regenerate.py verify bundlelint 校验的内容详见 prompts/_common.mdREADME front-matter 完整、每个.slang有//META块且doc_ref路径可解析、锚点与标题匹配、功能覆盖表中每个.slang文件都出现于 Tests 列、表格行数与表头一致、单元格内字面|已转义为\|、README 正文中绝不出现裸{{或{%README 带 front-matterGitHub Pages 的 Jekyll 会先对正文跑 Liquid未闭合的{{会中止整个站点构建——安全写法是空格分隔{ {1,2},{3,4} }FileCheck 模式则用code#123;#123;.*#125;#125;/code数字实体。步骤 9每个包一个提交一个包一个提交保持历史可评审。建议消息key: N tests K findings例如conformance/types-array: 6 tests。包 README 的完整结构含真实示例以 conformance/expressions-literal/README.md 为真实样例front-matter 之后是## Intent一段话说明该包行使哪份文档及覆盖策略接着四张声明表## Claims扁平的编号声明列表按子区域/文档标题分组是基准枚举## Functional coverage每行一条已有测试的声明列Claim | Intent | Anchor | Tests。Intent 用受控词汇functional | boundary | negative | expansion | regressionAnchor 是到源文档节的 markdown 链接路径相对包目录conformance 树比 design 树浅一层../步数要按实际包数## Untested claims每行一条无测试的声明Claim | Reason | Anchor | Why untested。Reason 分三族测试工具替代needs-unit-test、needs-multi-file-test、needs-cli-test、运行器能力gpu-dxr、gpu-mesh-shader、gpu-cuda、gpu-metal-toolchain、gpu-spirv-tools、gpu-cooperative等 14 个标签、终局link-stage-only、out-of-bundle、deprecated、process-doc、internal-source-fact、compile-time-toggle、requires-external-tool、implementation-detail## Doc gaps observedAnchor | Kind | Gap | Suggested additionKind 用受控词汇missing-example | missing-surface | undocumented-behavior | cascading-only-mention | ambiguous-claim | drift-from-sourceGap 以文档读者视角写 1–3 句并逐字引用原文Suggested addition 写成可直接执行的指令文档再生成 agent 会逐字读取。该包 11 条功能覆盖声明锚定 expressions-literal.md 的#integer-literal-expressions与#boolean-literal-expressions两个锚点4 条未测试声明浮点/字符串/nullptr字面量未规范化描述、指针宽度后缀待基础设施4 条文档缺口八进制弃用路径与词法器行为漂移、INT64_MAX以上字面量的警告-回退路径不存在、最小负 int32 豁免的类型声明上下文相关、slangiVM 的false参数求值为truebug。五、停止条件包的完成态与会话的终止一个包在 prompts/_claims.md 第 6 节意义下完成## Claims中枚举的每条声明要么出现在## Functional coverage沿文档承诺的维度要么出现在## Untested claims并带分类原因out-of-bundle/compiler-bug-pending/non-normative/unclassified。unclassified行是评审者标记而非已关闭的包。满足即转入下一个包。整个会话在以下任一条件成立时终止并提交 推送当前状态某个包的 verify 显示FAILED 0且失败不是已归档的编译器 bug文档非规范性仅引言/术语表/导航——在§ Skipped docs记录跳过并继续不要结束会话下一个包的 source_doc 对“什么算声明”存在未解决的结构性问题如文档正在重写中——把问题记入该包的_prompt.md并结束会话等待人工评审连续多个包浮出阻碍前行的编译器 bugfindings 积压需要人工分诊后才能继续在同一破损表面上写测试。六、会话之后人工评审与 findings 归档战役模式的本地-only bug 流在会话结束后交给人工走查_meta/findings/未归档 YAML用regenerate.py findings file id决定归档哪些为跟踪 issue该命令gh issue create并设置项目字段把 YAML 移到findings/filed/支持--dry-run共享根因的 findings归档一个其余用regenerate.py findings dup id --of issue-number去重更新expected-failures.txt把_meta/findings/id.yaml引用注释替换为上一步产生的跟踪 issue URL。另有findings fixed id --verified-at commit用于退役不再复现的 findingYAML 移到findings/resolved/见 findings/resolved/ 下的 6 个实例。当前_meta/findings/下已有约 60 个待决/已归档/已解决 finding覆盖 SIGSEGV、错误诊断、错误代码生成、VM 字节码缺陷等类别。七、覆盖率里程表anchor coverage 与 claim coverage 的区分对conformance战役在每个会话开始与结束时运行regenerate.py lang-ref-coverage。战役目标是 docs/language-reference/ 各文件覆盖率百分比的单调递增。design战役改用coverage-targets/expansion-candidates报告针对 docs/generated/design/。两种覆盖度量锚点覆盖率Anchor coverage——工具当前报告的量文档中规范性锚点中至少有一个测试引用它们的百分比。这是代理指标——容易计算但 100% 锚点覆盖的包仍可能有锚点章节内未测试的声明。声明覆盖率Claim coverage——真正的目标按包 README## Claims条目中出现在## Functional coverage的比例。100% 声明覆盖率是包的完成态剩余的## Untested claims必须有分类原因out-of-bundle/compiler-bug-pending/non-normative/unclassifiedunclassified行是评审者标记。战役在树中每个未跳过文档都有对应包且声明覆盖率达 100% 时完成。锚点覆盖率是途中有用的代理规范性章节的 0% 锚点总是意味着该章节的声明提取尚未发生但 100% 锚点覆盖不隐含100% 声明覆盖——以包 README 的## Claimsvs## Functional coverage差异作为权威度量。八、跳过清单避免重复论证的决策记录§ Skipped docs是分诊后判定“暂不适合”的文档的运行清单含理由与时间戳让后续会话不必重新辩论。当前条目包括文档跳过理由expressions-conversions.md标记 TODO章节正文为空expressions-evaluation-classes.md编译期/运行期分类学用户可观察声明极少“static const 强制编译期”可测但脆弱attributes.md陈旧仅描述单个属性低于约 3 条声明的阈值shaders-and-kernels.md26 行无标题可测规范性声明不足 3 条执行模型由basics-program-execution覆盖basics-behavior.md33 行非规范性行为分类散文无可见编译器表面preprocessor.md19 行过薄/占位预处理行为由design/pipeline/01-lex-preprocess回归包覆盖types-class.md/types-special.md/types-traits.md/types-attributes.md3–22 行 stub低于阈值basics-name-lookup.md/expressions-value-categories.md4–7 行 stub无可测声明types.md/expressions.md/basics.md/basics-translation-overview.md伞形/总览章节——描述性文档豁免声明由各专题子包行使九、与主仓库的集成CI、阶段规划与手工编辑政策战役生成的套件与主仓库通过 regenerate.md 定义的阶段Phase逐步集成当前状态Phase A框架脚手架、B1/B1.5–B1.8引导生成、边界扩展、目录清扫、GPU 目标扩展、B2夜班接线与 F结构化 finding已实现Phase C跨链接、D非 Claude 模型评审/补救schema 与 prompt 已就位、E覆盖驱动扩展循环为已规划/脚手架状态。夜班运行Phase B2.github/workflows/nightly-slang-test.yml定时每日 04:00接在覆盖率夜班 02:00 槽之后运行regenerate.py verify它包裹slang-test -test-dir docs/generated/tests并应用套件级 expected-failures 列表 requires-tool过滤。仅建议性不阻塞 PR——夜班的通过/失败门只有非预期失败数。夜班还会上报passing tests that are expected to fail段落列出任何已开始通过的条目——即从 expected-failures.txt 移除它的提示。PR 上的 lint任何触碰docs/generated/tests/或docs/generated/design/的 PR 运行regenerate.py lint与regenerate.py list-stale软警告、非门禁。手工编辑政策docs/generated/tests/key/下的.slang与README.md禁止手工编辑_meta/manifest.yaml、_meta/schema/*、_meta/prompts/*可手工编辑它们是再生成的事实来源_meta/freshness.json、_meta/review-state.json由驱动编辑。发现测试错误时正确动作是改进 per-section prompt、改进源文档或改进 manifest如增加 watched path、提高 size cap然后重新生成并用regenerate.py mark-fresh bundle记录。lint 会标记任何//META: generatedtrue却带操作者无法证明的近期提交的文件。此外regenerate.py verify之前值得注意的既有经验全部沉淀在 prompts/_common.md-dump-ir快照在目标合法化之前OptiX 专用 opcode、SPIR-V bindless、Vulkan-RT 的GetVulkanRayTracingPayloadLocation等不在其中需锚定最终文本发射常量折叠会先算掉字面量算术用uniform参数/缓冲喂值来观察add(%a, %b)slangi无法实例化class、printf不支持%s、throw/catch在解释器下求值错误、cbuffer/非 const 模块级 static 不被接受DIAGNOSTIC_TEST 默认省略non-exhaustive运行时若所有诊断都被注释匹配反而报Unnecessary non-exhaustive测试必须用真实 CLI 拼写-target cuh而非CUDAHeader、-target spirv-asm而非SPIRV而不是 C 枚举名。十、结语战役模式的工程价值Campaign 模式是 Slang 将“文档即规范”落地的工程化机制它让docs/language-reference/的每一条规范性句子都有可执行的验证锚点让docs/generated/design/这份由源码逆向出的文档成为可回归的测试表面同时通过“finding 本地化 人工分诊”的分离把会话中发现的编译器 bug 与文档缺陷变成结构化的、可复现的、可归档的证据而不是淹没在失败噪音里。对想为 Slang 贡献测试、或想理解这套文档驱动测试生成协议的读者CAMPAIGN.md、prompts/_claims.md、prompts/_common.md 与 regenerate.md 四份文档构成了完整的协议闭环而 conformance/expressions-literal/ 与 design/pipeline/ 目录下的真实产物则是协议的最佳阅读示例。【免费下载链接】slangMaking it easier to work with shaders项目地址: https://gitcode.com/GitHub_Trending/sl/slang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考