Bitwarden Server 的 bump-rust-sdk 技能评测集用 5 个行为用例守住 Rust SDK 升级的关键决策【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/server导读本文以 .claude/skills/bump-rust-sdk/evals/README.md 为主线完整讲解 Bitwarden Server 仓库中bump-rust-sdkClaude Skill 的评测evals体系如何用 5 个行为测试用例覆盖该技能最实质性的决策——NPM 版本到 git 提交的映射、拒绝已废弃的 GitHub Actions run-number 方案、MSRV/工具链升级、定点cargo update -p、以及破坏性变更修复。读完本文你将掌握这套评测集的用例设计、通过标准expectations、消融ablation记录方法并理解其背后的 RustSdk 升级全流程原理与仓库源码佐证。一、背景bump-rust-sdk 技能与它的评测集.claude/skills/bump-rust-sdk是仓库中为 AI 助手Claude定义的一个技能目录核心文件为 SKILL.md。它的职责是把服务器端 util/RustSdk/rust/Cargo.toml 中bitwarden-crypto的 git rev 固定值升级到某个bitwarden/clients生产版本所对应的提交并处理升级过程中的破坏性变更与验证。该技能对应的评测集放在 .claude/skills/bump-rust-sdk/evals/ 下README 明确说明Behavior test cases for thebump-rust-sdkskill, in theskill-creatorschema.即这是按照skill-creator模式编写的行为测试用例用于验证技能在被调用时是否做出正确决策。evals.json中存放了 5 个用例每个用例的expectations就是通过标准其中用例 4 和 5 还带有notes记录各自的消融实验结果earned vs. borderline。评测的运行方式为在 Benchmark 模式下通过/skill-creator:skill-creator命令执行分别对比“带技能with-skill”与“不带技能without-skill”的表现。二、RustSdk 在仓库中的真实地位在深入用例之前有必要先明确 RustSdk 的角色因为评测集的每一个决策点都建立在它的定位之上。从 SKILL.md 可以确认util/RustSdk/rust/Cargo.toml以 git rev 方式固定bitwarden-crypto来源为bitwarden/sdk-internal仓库需要周期性升级以跟随bitwarden/clients发布RustSdk 是 Seeder 的测试基础设施位于util/而非生产代码src/它通过 FFI 为 C# Seeder 提供字段级加密能力encrypt_string/decrypt_string/encrypt_fields用来生成密码学上正确的 Protected Data供集成测试使用EncryptPropertyAttribute见 util/Seeder/Attributes/EncryptPropertyAttribute.cs驱动哪些字段需要被加密。仓库源码印证了这一点util/Seeder/Factories/CipherEncryption.cs中通过RustSdkService.EncryptFields(...)/EncryptFieldsWithCipherKey(...)调用 Rust FFICollectionSeeder、FolderSeeder、ProjectSeeder等均通过RustSdkService.EncryptString(...)加密名称字段。因此升级bitwarden-cryptorev 是否准确直接决定测试数据的密码学正确性。三、5 个评测用例总览evals.json.claude/skills/bump-rust-sdk/evals/evals.json中的 5 个用例覆盖了该技能的核心决策路径用例 ID评测主题关键决策点1NPM→git-SHA 映射从发布的 WASM 中读取内嵌main (short-sha)并git rev-parse而非查询 Actions run number2抵制废弃的 run-number 方法纠正“查询 GitHub Actions run number 取 head_sha”的错误思路3MSRV/工具链升级将rust-toolchain.toml的 channel 提升到工作区rust-versionMSRV而非 dev 工具链4定点cargo update -p使用cargo update -p bitwarden-crypto而非裸cargo update5破坏性变更修复SymmetricCryptoKey::make_aes256_cbc_hmac_key()变为pub(crate)后的编译修复四、用例 1NPM→git-SHA 映射核心决策4.1 用例内容最新客户端生产版本将bitwarden/sdk-internal固定在0.2.0-main.841。请把该 NPM 版本映射到util/RustSdk/rust/Cargo.toml中应固定的bitwarden-cryptogit rev并解释推导过程。期望输出解析到c5d5bba159bd222321f3ecfd90f5ae6192c2c8eb——通过读取发布 WASM 中内嵌的main (short-sha)字符串再执行git rev-parse得到而不是通过查询 GitHub Actions run number 或关联时间戳。通过标准expectations最终 git rev 为c5d5bba159bd222321f3ecfd90f5ae6192c2c8eb方法必须包含“下载 npm tarball → 在bitwarden_wasm_internal_bg.wasm中 grepmain (short-sha)→ 对 short sha 执行git rev-parse”响应中不得出现通过 GitHub Actions run-number 查询如gh api .../actions/workflows/.../runs取head_sha来映射版本的方式响应中不得提出c9f9dba或1e45444作为 rev它们分别对应0.2.0-main.842和0.2.0-main.840。4.2 为什么不能依赖 run number 或时间戳SKILL.md 给出了明确的技术依据客户端以 npm 形式消费 sdk-internalbitwarden/sdk-internal如0.2.0-main.841而服务器固定的是 git rev.NNN后缀是一个来自私有 Azure 发布任务的不透明计数器不是GitHub Actions 的run_number也不与main分支的提交一一对应仓库已验证过841→c5d5bba、842→c9f9dba、840→1e45444三者之间没有时间相关性——靠 run number 或时间戳推断 SHA 都会选错提交。正确的做法是读取构建时写入发布 WASM 的提交信息# VERSION 是客户端 release tag 中的 npm 版本例如 0.2.0-main.841 cd $(mktemp -d) curl -sSL https://registry.npmjs.org/bitwarden/sdk-internal/-/sdk-internal-VERSION.tgz -o pkg.tgz tar xzf pkg.tgz grep -ao main ([0-9a-f]\{7\}) package/bitwarden_wasm_internal_bg.wasm | sort -u # - main (c5d5bba) cd /path/to/sdk-internal git rev-parse c5d5bba # - 需要在 Cargo.toml 固定的完整 rev这里有一个关键设计考量由于bitwarden/commercial-sdk-internal与开源 tarball 打包的是同一个提交因此开源 tarball 内嵌的 SHA 对两者都具有权威性——这正是该方法可被自动化的根本保证。仓库当前状态可以交叉验证util/RustSdk/rust/Cargo.toml中bitwarden-crypto的固定值正是c5d5bba159bd222321f3ecfd90f5ae6192c2c8eb与用例 1 的期望答案完全一致。五、用例 2抵制废弃的 run-number 方法5.1 用例内容为了升级 RustSdk我打算直接查询 sdk-internal 发布 841 的 GitHub Actions run number 并取其 head_sha。请带我按这种方式操作。期望输出纠正该方法——run-number 方式已被移除/不可靠且发布计数器并不与提交一一对应应引导用户改从已发布 WASM tarball 中读取内嵌的main (short-sha)。通过标准明确指出 GitHub Actions run-number 方法对该映射已废弃/移除且不可靠引导改读 npm tarball WASM 中内嵌的main (short-sha)不得产出把 run-number 方法当作获取 rev 途径的分步操作指导。5.2 设计意图这个用例考验的是技能的“纠错”能力当用户主动提出一条错误但看似可行的路径时技能必须基于对映射原理的准确理解进行拦截与重定向而不是顺着用户的思路给出“看似可执行”的指令。它与用例 1 形成一正一反的组合从“正确做法”和“错误做法”两个方向同时锁定映射决策的边界。六、用例 3MSRV/工具链升级6.1 用例内容我正在把 bitwarden-crypto 升级到一个其 sdk-internal 工作区 rust-version 为 1.88.0 的 rev。util/RustSdk/rust-toolchain.toml当前 channel 为1.87.0。工具链该怎么处理期望输出把rust-toolchain.toml的 channel 提升到1.88.0以匹配 MSRV工作区rust-version不是sdk-internal 的 dev 工具链跳过该升级会导致 “requires rustc X or newer” 的构建失败。通过标准指示将rust-toolchain.toml的 channel 提升到1.88.0说明 channel 应对齐 MSRV工作区rust-version而非 sdk-internal 的 dev 工具链解释跳过 MSRV 升级会触发 “requires rustc X or newer” 构建失败。6.2 原理与仓库现状SKILL.md 的“Apply”步骤对此有完整规定对比目标 rev 工作区的rust-version与util/RustSdk/rust-toolchain.toml若 MSRV 高于当前 channel则将 channel 提升到MSRV而不是 sdk-internal 的 dev 工具链否则构建报 “requires rustc X or newer”。这里的关键陷阱在于sdk-internal 的开发者可能使用比 MSRV 更新的本地工具链若盲目对齐 dev 工具链版本会把不必要的升级引入服务器构建。正确的基准永远是工作区声明的rust-version。值得注意的是仓库当前 rust-toolchain.toml 的 channel 已是1.94.1——这是后续多次升级累积的结果2026 年 6 月那次从1.87.0升到1.88.0之后又继续演进。用例 3 描述的是该技能设计时所针对的典型场景其决策原则对齐 MSRV 而非 dev 工具链在每次升级中都同样适用。七、用例 4定点cargo update -p7.1 用例内容我已经更新了util/RustSdk/rust/Cargo.toml中的 bitwarden-crypto rev。对于新 rev应如何重新解析 Cargo.lock期望输出使用定点形式cargo update -p bitwarden-crypto而不是裸cargo update——后者会搅动无关 crate 并让 lockfile 差异无谓膨胀。通过标准推荐cargo update -p bitwarden-crypto定点形式指出裸cargo update会搅动无关 crate / 不必要地膨胀 lockfile diff。7.2 消融记录为什么这条指令是“承重墙”该用例带有notes记录了一次于 2026-07-01 执行的消融实验每个配置 3 次盲评EARNED — kept.Baseline无技能本身 2/2 能稳定偏好-p但移除这条指令后with-skill 的通过率跌到约 33%0/2、0/2、2/2当技能在场时Step 5 的cargo build变成了干扰项模型会推荐“以构建驱动重新解析”而不是定点更新。这条指令是承重墙因为它抵消的是技能自身的引导偏差而非 baseline 的失败。这是一个非常值得借鉴的评测洞见评测用例的价值不能只看 baseline 是否失败。有些指令之所以必须保留是因为技能内部其他步骤这里是cargo build会产生误导性的强信号评测需要验证技能能否抵抗自己的内部干扰。这种“消融后 with-skill 反而退化”的现象是衡量用例是否 load-bearing 的关键判据。八、用例 5破坏性变更修复8.1 用例内容在旧 rev 与新 rev 之间SymmetricCryptoKey::make_aes256_cbc_hmac_key()变成了pub(crate)。RustSdk 在多个位置调用了它。影响是什么如何修复期望输出判定为破坏性变更调用点无法编译修复方式是改用make(SymmetricKeyAlgorithm::Aes256CbcHmac)并导入SymmetricKeyAlgorithm枚举。通过标准识别受影响调用点将无法编译是破坏性变更不是警告给出修复替换为SymmetricCryptoKey::make(SymmetricKeyAlgorithm::Aes256CbcHmac)说明必须导入SymmetricKeyAlgorithm枚举。8.2 仓库源码印证当前仓库源码已经完成了这次迁移可以交叉验证修复后的最终形态util/RustSdk/rust/src/lib.rs 第 102 行let key SymmetricCryptoKey::make(SymmetricKeyAlgorithm::Aes256CbcHmac);util/RustSdk/rust/src/cipher.rs 第 273 行encrypt_fields_with_cipher_key_internal中生成每 cipher 独立密钥let cipher_key SymmetricCryptoKey::make(SymmetricKeyAlgorithm::Aes256CbcHmac);provider.rs、attachment.rs中的密钥构造同样统一为make(SymmetricKeyAlgorithm::Aes256CbcHmac)。同时references/api-surface.md该文件声称由源码自动生成记录 RustSdk 从bitwarden-crypto导入的全部类型、trait 与函数在SymmetricCryptoKey条目下已不再列出make_aes256_cbc_hmac_key()而 SKILL.md 的流程要求升级后重新生成该清单二者相互印证。8.3 消融记录borderline 用例为什么保留用例 5 的notes记录了 2026-07-01 的消融结果每个配置 3 次盲评borderline通过率与 baseline 持平with-skill 78%、baseline 78%各出现一次 flaky。但保留理由是(1) baseline 只能靠回忆通用的make(SymmetricKeyAlgorithm::Aes256CbcHmac)API 才能答对而该 API 是版本相关的、会随 rev 漂移——baseline 已出现一次 flaky 到错误猜测的 APIgenerate/try_from一个错误的密钥构造器悄悄进入 Seeder 正是这个用例要防的失败(2) with-skill 的正确回答来自 worked example即 references/examples/2026-06-bump.md——这种按需读取的参考内容几乎不占常驻上下文却固定了经过验证的具体迁移方案并为下次升级示范了处理破坏性变更的方法(3) 仅凭通过率持平就裁剪用例已经失败过一次即用例 4。这里揭示的评测原则是即使通过率与 baseline 持平只要用例守住的是“版本漂移导致的错误 API 猜测”这类高风险失败就值得保留——测试数据密码学正确性的底线不能交给模型对特定版本的记忆。九、评测集背后的完整升级流程5 个用例各自锚定了升级流程中的一个决策点。完整流程见 SKILL.md识别目标——从 clients 最新web-v*release tag 出发取其 npm 版本gh release list --repo bitwarden/clients --limit 5 | grep web-v git -C /path/to/clients show tag:package.json | grep sdk-internal # - 0.2.0-main.841映射 npm → git SHA——即用例 1、2 覆盖的嵌入式 SHA 方法分析破坏性变更——将每个提交与references/api-surface.md交叉比对重点检查类型重命名、函数移除/废弃、签名变更与 trait 变化cd /path/to/sdk-internal git log --oneline old-rev..new-rev -- crates/bitwarden-crypto git diff old-rev..new-rev -- crates/bitwarden-crypto/src/keys/mod.rs crates/bitwarden-crypto/src/lib.rs应用变更——更新Cargo.toml中的 revMSRV 检查用例 3执行cargo update -p bitwarden-crypto用例 4修复编译错误对新增的废弃 API 加#[allow(deprecated)]并附 why 注释构建与验证cd util/RustSdk/rust cargo build cargo test # 关卡测试encrypt_string_decrypt_string_roundtrip cargo fmt --check git diff ../NativeMethods.g.cs # 必须保持不变 dotnet test test/SeederApi.IntegrationTest/并检查Cargo.lockdiff 中是否出现意外的传递性加密 cratersa、aes、sha2人工验证仅限人类执行AI 只负责呈现——人工播种并确认 Protected Data 在 web 客户端可解密。其中“验证”一环同样有源码依据util/RustSdk/rust/src/cipher.rs的测试encrypt_string_decrypt_string_roundtrip第 308 行验证了 EncString 往返RustSdkCipherTests位于 test/SeederApi.IntegrationTest/则从 C# 侧覆盖 FFI 行为。十、与 worked example 的呼应2026 年 6 月那次升级references/examples/2026-06-bump.md 记录了确立“嵌入式 SHA 映射”的那次真实升级——在此之前旧的 run-number 方法和时间戳关联法都选错了提交旧 revabba7fdab687753268b63248ec22639dff35d07c2026-02-05bitwarden-crypto2.0.0目标web v2026.6.3 / desktop、browser、CLI v2026.6.0NPM 版本0.2.0-main.841新 revc5d5bba159bd222321f3ecfd90f5ae6192c2c8ebbitwarden-crypto3.0.0。该文档明确记录时间戳启发式曾错误地选中c9f9dba实际对应0.2.0-main.842而0.2.0-main.840内嵌1e45444——证明发布计数器并不按时间跟踪提交。这与评测用例 1 的期望答案、用例 2 的纠错场景完全互文也解释了为什么评测集把“读取 WASM 内嵌 SHA”作为不可妥协的决策。此外这次升级发现了两个破坏性变更正是用例 3、5 的原型SymmetricCryptoKey::make_aes256_cbc_hmac_key()变pub(crate)5 个调用点编译失败以及工作区 MSRV 从1.85.1升至1.88.0。Cargo.lock 层面还出现了一批 major 升级aes0.8→0.9、sha20.10→0.11、rsa0.9→0.10.0-rc、新增后量子ml-dsa并新增了非可选依赖bitwarden-api-key-connector→reqwest/hyper传递 HTTP 栈。最终 Rust 13 个单测、C# 177 个 SeederApi.IntegrationTest含 17 个RustSdkCipherTests全部通过。十一、评测集设计模式总结纵观这套 evals可以提炼出对同类“升级类技能”评测具有普适性的设计方法围绕实质性决策而非步骤完整度设计用例——5 个用例各自对应一个“做错会造成真实损失”的决策点选错提交、用错方法解析 lockfile、漏升 MSRV、误用被移除的 API正反成对——用例 1 教正确做法用例 2 专门拦截错误做法防止技能在用户引导下“顺着错路给出可执行指令”期望输出描述“方法而非结果”——expectations 不仅检查最终 rev 正确还明确禁止 run-number 查询路径防止模型碰巧答对但方法错误用消融记录判断用例的承重性——用例 4 展示了“baseline 能答对、移除指令后 with-skill 反而退化”的承重墙特征用例 5 展示了“通过率持平但守住版本漂移高风险”的保留理由评测与文档、示例形成闭环——SKILL.md、references/api-surface.md、references/examples/2026-06-bump.md 与 evals 相互印证让每次升级既能被验证、也能被追溯。对于需要长期维护“升级依赖/同步上游”类技能的团队这套“行为用例 正反用例 消融记录”的组合是一个可以直接借鉴的评测模板。【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/server创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考