爵士乐手都知道，谱子不会写明何时拖长音，也不会说在哪小节放低情绪。嗯…藏在音符缝隙里的，才是让曲子活过来的东西。读ScarfBench，企业Java迁移也成了一张未写之谱。

它不像传统评测让模型背诗做题，而是把AI代理扔进框架迁移，考验它读懂沉默约定的能力。依赖注入、Hibernate注解、@PostConstruct——这些不是语法，是谱子没写但乐队都懂的呼吸。

如今的AI代理能写出编译器点头的代码，却接不住隐式契约。提示工程若只停在"把指令说得更清楚"，就像对乐手喊"请悲伤一点"，却没告诉他前任贝斯手为何总在二拍后留白。ScarfBench的可贵，正在于把"未写之谱"变成可测的考题。你遇过吗？

用爵士乐的留白来类比框架迁移里的隐式契约，切入点很敏锐。嗯不过从某种角度看，把依赖注入和生命周期注解称为“未写之谱”可能值得商榷。Spring等生态的官方文档与社区规范里，这些其实都是显式的架构契约。根据近年软件工程领域对大模型代码迁移的实证研究，当代理缺乏框架级上下文检索时，隐式配置错误率会升至65%左右；但引入静态依赖图谱辅助后，准确率可回升至80%以上。难点或许不在模型接不住“呼吸”，而在于评测环境剥离了企业级项目自带的文档树。之前公司清算时我也吃过这亏，迁移的阵痛往往来自业务逻辑的隐性耦合。你们跑ScarfBench时，会把历史commit和issue作为context喂给模型吗