新模型的发布页很容易让人想直接换工具。我更想先固定一件小事如果拿它辅助学Rust什么结果才算帮上忙Anthropic于2026-10-07发布Haiku 5.5官方将它定位于高频、成本敏感任务也提到在编码工作中作为子Agent使用。这些是厂商对产品的介绍不能直接换成“它能正确教会我所有权”。官方发布页没有调用Haiku没有做模型横评也没有采用发布页上的客户引语当作个人体验。下面是一份可以拿给任何助手、也可以自己完成的学习验收。第一题先把函数合同讲明白给出要求返回切片里第一个偶数找不到时返回None负偶数和0也算偶数。先让助手复述输入输出再给实现。这道题看起来简单却能区分“输出一个看起来对的值”和“守住规格”。返回最小偶数、忽略负数、把0当作没找到都不满足要求。下面是验收参考不是某个模型的回答fn first_even(xs: [i32]) - Optioni32 { 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 --edition2024 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返回值回归。这给这道题一个具体背景类型层面写着boolABI层面的位模式仍然可能需要工具链修复。这里没有在aarch64本机声称复现该问题。验收分开记才知道下一步学什么记录项可以写下的证据不能顺手推出的结论编译固定版本的命令与退出码业务规格一定正确测试输入、期望、实际输出所有输入都正确解释指出不变量和外部前提没有遗漏的安全证明工具检查工具覆盖范围内的诊断整个原生系统无错误Miri文档也明确它不能从一次运行证明soundness对原生FFI还有覆盖限制。工具越多越需要说明每项检查照到了哪一段。对非科班自学者而言这份清单不要求先变成框架专家。一次把“第一个”解释清楚一次能指出一处未核实的外部前提都是可观察的进展。以后真要评估某个模型也应该在获准调用后固定提示、版本和任务预算保留原始回答在此之前只把它叫验收设计。
