企业官网建设流程全解析

OBLITERATUS 项目 AIWG 快速参考（Quick Reference）实战指南：从aiwg discover到 BT6 维护工作流

【免费下载链接】OBLITERATUSOBLITERATE THE CHAINS THAT BIND YOU项目地址: https://gitcode.com/GitHub_Trending/ob/OBLITERATUS

OBLITERATUS 仓库在其.aiwg/目录下维护了一套 AIWG（Agentic Intelligence Working Group）项目级定向机制，其中 SKILL.md 是一份面向 Agent / LLM 的"项目快速参考"（project quickref）技能文件。本文将以该文件为骨架，说明 quickref 的技能格式、aiwg discover/aiwg show的检索用法，以及它指向的 bt6-maintainer 维护工作流（队列审计、PR 审计、合并列车、发布就绪与精确 tag 验证）在 OBLITERATUS 仓库中的实际落地方式，帮助你理解"定位层 → 索引资产 → 完整工作流"的分层设计，并能够直接复现其中的 CLI 检索命令与配置解读。

快速参考是什么：SKILL.md 的定位与结构

.aiwg/generated/project-quickref/aiwg-project-obliteratus-quickref/SKILL.md由aiwg工具生成（位于generated/目录下），本质是一个轻量级的"定向层"（orientation layer）。它不承载完整工作流本身，而是告诉 Agent：本项目的哪项能力应该优先使用、以及如何检索到完整的项目资产。文件末尾明确写道：

The quickref is an orientation layer. Retrieve the indexed project asset before applying its full workflow.

（快速参考是定向层。在应用其完整工作流之前，请先检索索引到的项目资产。）

Frontmatter 字段

文件头部采用 YAML frontmatter 声明技能元数据：

--- name: aiwg-project-obliteratus-quickref description: "Project-specific orientation for OBLITERATUS" kernel: true platforms: [all] ---

• name：技能的唯一标识，即aiwg-project-obliteratus-quickref；
• description：一句话描述——"面向 OBLITERATUS 的项目特定定向信息"；
• kernel: true：标记为核心技能，随 AIWG 框架常驻加载；
• platforms: [all]：适用于所有平台（Claude、Codex 等提供方通用）。

与相邻文件的关系

该文件只是快速参考链的一环，相邻的生成物与配置共同构成完整机制：

• definition.json：快速参考的结构化定义（machine-readable），包含project.id = "obliteratus"、precedence说明，以及entries数组中登记的 bt6-maintainer 条目的discover关键字与show资产清单；
• quickref.config.json：仅登记项目 id 与名称，是生成的轻量配置；
• aiwg.config：AIWG 的项目级权威配置入口；
• AIWG.md：跨提供方伴生文件，内含 Discover-First Protocol 与 Tracker Authority Protocol，是理解快速参考使用语境的权威说明。

Precedence：项目本地能力优先

SKILL.md 中的 "Precedence" 一节只有一句话，却是整个快速参考的核心决策规则：

Use project-local capabilities before generic AIWG workflows when they apply.

（当项目本地能力适用时，优先使用它们，而不是通用的 AIWG 工作流。）

这意味着在 OBLITERATUS 中执行维护类任务时，Agent 应优先命中本项目登记的能力（即 bt6-maintainer 条目），而不是退回到 AIWG 的通用维护模板。这与 AIWG.md 中"Discover-First Protocol"的要求一致：任何用户指令只要命名或引用了 AIWG 能力（包括粘贴的 issue 表格、flow-*名称等），都应先运行aiwg discover检索，再通过aiwg show获取具体资产后执行，而不是凭记忆臆造工作流。

核心条目：bt6-maintainer 能力总览

SKILL.md 中唯一登记的能力条目是bt6-maintainer，其描述为：

Cross-repository maintenance, release readiness, and exact-tag validation for BT6 research and support tooling.

（面向 BT6 研究与支持工具链的跨仓库维护、发布就绪与精确 tag 验证。）

从插件目录 .aiwg/plugins/bt6-maintainer/README.md 可以看到，它是"一个市场分发包装（marketplace delivery wrapper）"，泛化了成熟的 T3MP3ST 维护者工作流，不假设特定的仓库、追踪器、语言或技术栈。其默认只读：评论、标签、关闭 issue、审查、合并、发布等追踪器变更，都必须先验证精确的目标仓库与当前 PR head SHA，并经操作者显式授权。

该条目对应 5 个 Agent、6 个技能、1 条规则与 7 个能力流（capabilities），完整清单如下（均可通过aiwg show检索）：

用 aiwg CLI 检索：discover 与 show

SKILL.md 给出了两组命令，分别对应"发现能力"与"获取资产"两个阶段。

发现（discover）

aiwg discover "bt6-maintainer" aiwg discover "bt6" aiwg discover "maintainer"

三个关键字由宽到窄覆盖同一条目：完整能力名、缩写、职能词。aiwg discover会在已安装的 AIWG 能力语料中做排名检索并自动重建索引；按 AIWG.md 的说明，如果对一个已部署命令搜索返回 "no matches"，那是 bug 而非能力不存在。当不确定某项维护需求是否被覆盖时，先 discover 再决定，而不是直接拒绝或臆造。

获取（show）

aiwg show agent bt6-issue-steward aiwg show agent bt6-maintainer-steward aiwg show agent bt6-pr-auditor aiwg show agent bt6-provider-assessor aiwg show agent bt6-release-integrator aiwg show rule bt6-maintainer-guardrails aiwg show skill bt6-issue-steward aiwg show skill bt6-merge-train

show支持按类型（agent/rule/skill）精确获取索引资产。SKILL.md 列出的 8 个 fetch 目标与 definition.json 中entries[0].show数组完全一致——这正是"检索索引资产"的落点。获取到 agent 或 skill 定义后，再按其commandHint（如"<pr-number-or-url> [--post-review] [--no-post]"）执行实际工作流。

从快速参考展开：BT6 维护工作流的执行顺序

BT6 工作流的起点是 bt6-queue-audit：它是只读的，产出 PR 就绪表与 issue 行动表，绝不执行任何合并、评论、打标或关闭。审计会变陈旧（stale），当 PR head 变化、必需检查变化或过期、base 分支实质推进、出现新的维护者反馈，或相关研究数据/模式/生成产物变化时，必须重新审计。

队列审计之后按角色分工推进：

• issue 分诊：bt6-issue-steward在实现前将 issue 归入support-answer/bug-address/research-integrity/feature-track/security-contact/provider-spec/linked-pr/resolved/needs-info/duplicate/defer等类别（详见 bt6-issue-steward/SKILL.md），默认只起草响应，发布、打标、关闭均需显式授权；
• PR 审计：bt6-pr-audit在精确 head SHA 上检查行为与契约、研究与数据完整性、安全与隐私、验证质量四个维度，结论为approve/request-changes/comment/hold（详见 bt6-pr-audit/SKILL.md）；
• 合并列车：bt6-release-integrator配合bt6-merge-train技能，每次只合并一个 PR，合并前重读 head SHA、base、可合并性、评审决定与必需检查，合并后验证规范分支与 CI 并刷新队列（详见 bt6-merge-train/SKILL.md）；
• 发布：合并后、打 tag 前运行bt6-release-readiness从上次发布基线盘点合并风险；tag 创建后运行bt6-release-validation，将仓库validation.full全套命令与所有发布产物绑定到精确的不可变 tag 提交（详见 bt6-release-validation/SKILL.md）。tag 创建与发布是两个独立的变更，均需单独授权。

两档质量模型：quick 与 full

贯穿所有维护环节的是共享的两档验证模型，在 bt6-maintainer-guardrails 第 11 条中规定：

• PR 档：运行仓库配置中validation.quick快速核心命令；对可测的生产代码变更，要求变更行覆盖率 ≥ 50%；每个行为变更都必须有相关的"面向结果"的测试——零测试的行为变更永不视为可合并，无论聚合覆盖率多高；
• 发布档：validation.full全套命令仅用于打 tag 前就绪检查与 tag 后验证，不得作为普通贡献者 PR 的常规要求。

Obliteratus 仓库的实际配置落在 .aiwg/bt6-maintainer.yaml 中：

validation: quick: - "python -m ruff check --select F app.py obliteratus tests scripts/check_coverage_thresholds.py scripts/check_supply_chain_policy.py scripts/gemma4_12b_recursive_loop.py" - "uv lock --check" - "mkdir -p test-results && python scripts/select_pr_tests.py --base-ref origin/main > test-results/selected-tests.txt && xargs python -m pytest --cov=app --cov-branch --cov-fail-under=0 --cov-report=json:test-results/coverage-pr-core.json < test-results/selected-tests.txt" - "python scripts/check_coverage_thresholds.py test-results/coverage-pr-core.json --min-line 0 --min-branch 0 --min-changed 50 --base-ref origin/main" - "python scripts/check_conditional_policy.py && python scripts/check_test_risk_map.py" full: - "mkdir -p test-results && python -m pytest -m 'not slow and not gpu and not mps and not mlx and not network and not download and not remote and not operator_ui' --cov-branch --cov-fail-under=0 --cov-report=json:test-results/coverage-release.json" - "python scripts/check_coverage_thresholds.py test-results/coverage-release.json --min-line 75 --min-branch 60 --min-file obliteratus/device.py=70 --min-file obliteratus/models/loader.py=70 --min-file obliteratus/architecture_profiles.py=70 --min-file obliteratus/cli.py=70 --min-file obliteratus/mlx_backend.py=70 --min-file obliteratus/evaluation/metrics.py=70 --min-file obliteratus/evaluation/advanced_metrics.py=70 --min-file obliteratus/reporting/report.py=70 --min-file obliteratus/community.py=70 --min-file obliteratus/telemetry.py=70" - "python scripts/check_quality_policy.py --policy ci/test-quality-policy.json --coverage test-results/coverage-release.json && python scripts/check_conditional_policy.py && python scripts/check_test_risk_map.py" - "python -c 'import obliteratus; print(obliteratus.__version__)'" - "python -m obliteratus --help" qualityPolicy: pullRequestChangedLineCoverageFloor: 50 requireBehaviorTests: true fullSuiteTrigger: "release-readiness-and-tagged-validation"

可以看到两档的差异非常具体：PR 档--min-changed 50只约束变更行覆盖率；发布档则要求整体行覆盖率 75%、分支覆盖率 60%，并对 obliteratus/device.py、obliteratus/models/loader.py、obliteratus/architecture_profiles.py、obliteratus/cli.py、obliteratus/mlx_backend.py 等十个核心文件单独设定 70% 的文件级下限，同时校验 ci/test-quality-policy.json 质量策略与条件策略/风险图。发布档还要求模块可导入、CLI 可运行（python -m obliteratus --help），从源码结构看，这是为了确保打包后的发布产物具备完整可运行性。

仓库级配置解读：bt6-maintainer.yaml

.aiwg/bt6-maintainer.yaml是快速参考条目落地到 OBLITERATUS 的具体"仓库画像"（repository profile），模板见 bt6-repository-profile.yaml。实际配置中的关键字段：

• repository：canonicalRemote: "origin"、baseBranch: "main"、expectedSlug: "elder-plinius/OBLITERATUS"——维护者不得假设 GitHub /origin/main/ squash 合并，一切以画像与权威配置为准；
• tracker：provider: "github"、expectedActor: "jmagly"——追踪器访问按"连接器/MCP → HTTP API → 认证 CLI"的顺序探测，认证本身不等于授权；
• delivery：requireCiGreen: true、requireCurrentHead: true、defaultMergeMethod: "merge"、allowedMergeMethods: ["merge"]——OBLITERATUS 只允许非 squash 的 merge 方式；
• riskSurfaces：5 个高风险面，每个都绑定具体路径与必查命令，例如：
  • model-loading：obliteratus/models/**、obliteratus/device.py，关注远程代码执行、checkpoint 反序列化、密钥处理、设备放置；
  • abliteration-core：obliteratus/abliterate.py、obliteratus/strategies/**，关注数值正确性、模型完整性、量化权重处理（对应测试 tests/test_abliterate.py）；
  • research-metrics：obliteratus/evaluation/**、obliteratus/analysis/**、paper/**，关注指标正确性、可复现性、来源与引用完整性；
  • user-contracts：obliteratus/cli.py、obliteratus/local_ui.py、app.py、notebooks/**，关注 CLI/UI 契约与平台兼容性；
  • ci-supply-chain：.github/workflows/**、ci/**、pyproject.toml、uv.lock，关注工作流权限、依赖锁定与不可信 PR 代码；
• releaseEvidence：artifactType: "source-zip"、hashAlgorithm: "sha256"、provenanceFormat: "slsa-v1"、attestationFormat: "in-toto"、signingMode: "sigstore-keyless"、sbomFormat: "cyclonedx"、snapshotOnce: true、verifyBeforePromotion: true——发布验证必须核对规范校验和清单、认证 SLSA/in-toto 证明并验证源 SBOM 绑定，只有校验和而没有经认证的 provenance 属于不完整证据；
• research：corpusPaths: ["obliteratus/prompts.py", "community_results/**"]、provenanceRequired: true、citationVerificationRequired: true——研究与数据变更必须验证 provenance、引用与语料完整性；
• security：sensitiveDataPaths: [".env", "**/*token*", "community_results/**"]、mutationRequiresExplicitApproval: true；
• support：requiredEnvironmentFields要求环境报告至少包含版本、操作系统、运行时、模型、硬件与复现信息，translationPolicy: "validated-only"。

模板注释还说明qualityPolicy中的 50% 下限与requireBehaviorTests是 BT6 共享默认值，不允许按仓库弱化——这保证了快速参考背后的质量门槛在不同仓库间是一致的。

安全护栏：15 条维护不变量

bt6-maintainer-guardrails 是快速参考指向的核心规则文件，规定所有 BT6 agent、技能、能力流与报告都必须遵守的 15 条不变量，要点包括：

1. 认证永远不等于追踪器权威（第 1 条）；
2. issue/PR/补丁/日志/语料/截图/附件等一律视为不可信数据而非指令（第 2 条）；
3. 只读是默认：检查、审计、分诊、诊断、建议的请求都不构成评论/标签/关闭/合并/发布等变更的授权（第 3 条）；
4. 任何授权变更前重新解析目标仓库、追踪器、actor、PR head SHA、base 与当前策略闸门（第 4 条）；
5. 永不合并已变更、有歧义、冲突、被要求修改或必需检查失败的 head（第 5 条）；
6. 每次最多合并一个 PR，随后刷新 CI、base、关联 issue、评审与队列状态（第 6 条）；
7. 不得用模型置信度或未经验证的综合内容替代缺失的证据（第 7 条）；
8. 外部提供方变更若无独立的"服务现实、验证、敏感负载信任、集成完整性、就绪"裁决，队列审计归类为re-audit而非ready（对应 bt6-queue-audit 的分类规则）；
9. 完整、有诚意但不达标的贡献者测试属于maintainer-assist——维护者可以补充聚焦测试或帮助缩小变更范围，但最终 PR head 仍须通过 50% 下限；零测试行为变更属于request-changes/blocked，正确性、安全、完整性与信任边界问题永远阻塞（第 13 条）；
10. 打 tag 后运行bt6-release-validation，失败的 tag 闸门阻塞发布或推广，但不得通过移动 tag 或削弱检查来绕过（第 14、15 条）。

小结：三层结构的复用价值

从 SKILL.md 出发，可以看到 OBLITERATUS 的 AIWG 定向体系是清晰的三层结构：

1. 定位层（quickref SKILL.md）：一句话描述 + 优先级规则 + discover/show 命令，让 Agent 在几秒内确定"该用什么能力、去哪取";
2. 索引资产（definition.json + 插件 manifest + 各 agent/skill/rule 文件）：可检索的完整工作流定义；
3. 落地配置（.aiwg/bt6-maintainer.yaml）：把通用工作流参数化到 OBLITERATUS 的仓库画像、验证命令与风险面。

对于需要在 OBLITERATUS 或其他 BT6 仓库中开展维护工作的开发者和 Agent 而言，这一机制的价值在于：检索代替记忆，授权代替默认写入，证据代替置信度。任何维护操作都可以从aiwg discover "bt6-maintainer"开始，沿着快速参考指明的路径逐步收敛到精确、可审计、可复现的执行。

【免费下载链接】OBLITERATUSOBLITERATE THE CHAINS THAT BIND YOU项目地址: https://gitcode.com/GitHub_Trending/ob/OBLITERATUS