新模型的发布页很容易让人想直接换工具。我更想先固定一件小事：如果拿它辅助学Rust，什么结果才算帮上忙？

Anthropic于2026-10-07发布Haiku 5.5，官方将它定位于高频、成本敏感任务，也提到在编码工作中作为子Agent使用。这些是厂商对产品的介绍，不能直接换成“它能正确教会我所有权”。官方发布页

没有调用Haiku，没有做模型横评，也没有采用发布页上的客户引语当作个人体验。下面是一份可以拿给任何助手、也可以自己完成的学习验收。

第一题：先把函数合同讲明白

给出要求：返回切片里第一个偶数；找不到时返回None；负偶数和0也算偶数。先让助手复述输入输出，再给实现。

这道题看起来简单，却能区分“输出一个看起来对的值”和“守住规格”。返回最小偶数、忽略负数、把0当作没找到，都不满足要求。

下面是验收参考，不是某个模型的回答：

fn first_even(xs: &[i32]) -> Option<i32> { xs.iter().copied().find(|x| x % 2 == 0) } fn main() { assert_eq!(first_even(&[]),None); assert_eq!(first_even(&[3,5]),None); assert_eq!(first_even(&[3,-2,4]),Some(-2)); assert_eq!(first_even(&[0,2]),Some(0)); println!("task contract: 4 cases passed"); }

保存为main.rs，运行rustc --edition=2024 main.rs -o task-check && ./task-check。在本地macOS aarch64、rustc 1.98.0上，四组断言通过，输出task contract: 4 cases passed。

这只能说明参考实现通过这四组构造样本。它没有测模型能力，更不能产生“某模型准确率100%”这种结论。

第二题：修好报错，也要保留原需求

可把第一题扩成一段有编译错误的代码，要求返回借用而不是拷贝。验收时同时看签名、行为和解释：如果助手为了消除生命周期错误把全部数据clone一遍，它可能写出了能编译的程序，却改掉了练习目标。

因此我会保留三列记录：原需求、助手改变了什么、为什么认为改变合理。遇到'static、unsafe或不必要的clone，先追问调用者承担了什么条件，不以报错消失为结束。

编译器是证据的一部分。它不会替我们判断需求是否被偷偷换掉，也不会证明一段外部库调用的声明准确。

第三题：找出测试之外的契约

把题目换成一个C函数返回的指针，再问：“检查不为空以后，能直接变成Rust切片吗？”

合格的回答至少应该追到有效长度、对齐、初始化、存活时间、别名，以及由谁释放；若返回值来自C库，还要查该库的真实合同。只补一句unsafe，不是解释。Rustonomicon的FFI章节说明外部签名本身就需要调用方核实。

10月15日发布的Rust 1.99.1修复说明还列出了x86_64 FFI bool返回值回归。这给这道题一个具体背景：类型层面写着bool，ABI层面的位模式仍然可能需要工具链修复。这里没有在aarch64本机声称复现该问题。

验收分开记，才知道下一步学什么

Miri文档也明确它不能从一次运行证明soundness，对原生FFI还有覆盖限制。工具越多，越需要说明每项检查照到了哪一段。

对非科班自学者而言，这份清单不要求先变成框架专家。一次把“第一个”解释清楚，一次能指出一处未核实的外部前提，都是可观察的进展。以后真要评估某个模型，也应该在获准调用后固定提示、版本和任务预算，保留原始回答；在此之前，只把它叫验收设计。