上周末 Claude 官方在 X 上挂出一条帖子，盘点了最近几周让他们眼前一亮的 6 个创意项目，浏览量已经破 200 万。
里面既有做火山分析系统的，也有拿涂鸦在笔记本上下象棋的。多数跑在 Opus 5.5 上，少数两个用的是 Sonnet 5.5 和 Haiku 5.5。
看完只有一个感受：这帮人的脑洞是真的大。顺带也说明了一件事——Opus 5.5 在审美和 coding 这两块，已经强到有点不讲道理。
我又顺着搜了一圈案例，然后就收不住了。下面挑 8 个我自己觉得最值得看的，逐个拆。
一百二十页笔记炼出一套手写字体
这是官方帖子里提到的项目，也是我最想单独拎出来说的。
工程师 Harshpreet 把大学时期整整 120 页的计算机网络手写笔记全部丢给 Opus 5.5，一个多小时之后，模型提取出笔记里手写字的所有特征，直接生成了一套新字体。作者说，那就是他自己的字迹。
两个细节挺狠。
第一，笔记页数太多，很多上传的照片放大之后字母糊得不行，按作者的说法单个字母高度只有 34 个像素左右。Opus 5.5 的处理方式是追踪笔尖的实际运动路径，再逐个字母重绘。
第二，模型把他手写时的怪癖也留下来了。字母 i 上面不点点，非要画个小圈；字母 t 只在另一侧划横线。这些特征 Opus 5.5 全记住了。
真要复现这件事，输入侧有几个坑得先知道。图像输入不是无限塞的，单次请求能带的图片数量有上限，120 页得分批投喂，每批控制在十几页比较稳，批与批之间用文字摘要衔接风格特征，否则后一批容易丢掉前一批的笔迹细节。分辨率也别一味压缩，34 像素高的字母已经接近可辨识下限，再降 OCR 和笔迹还原都会崩。
字体生成出来不等于能用。实现前至少做三件事：用 fontTools 统计字形覆盖率，确认 ASCII 和常用标点没有缺字；导出 TTF 后在 FontForge 里检查基线对齐和 hinting，小字号下不发虚才算过关；最后拿一段中英混排文本实际渲染一遍，看字距是否均匀。缺字和基线漂移是这类生成字体最常见的两个翻车点。
涂鸦棋盘上的象棋对局
另一个被官方点名的项目，是用涂鸦的方式在笔记本上画棋盘下象棋。
它考验的不是棋力，而是模型对”非标准输入”的理解：手绘的格子歪歪扭扭，棋子是简笔涂鸦，走子靠涂改。Opus 5.5 要先把这张图翻译成结构化棋局，再推演下一步。
这类玩法对图像理解的鲁棒性要求很高，稍微糊一点的涂鸦就可能被误判成别的棋子。做类似项目时，建议在提示词里固定一套图例约定，比如圆形代表兵、方形代表车，让模型有稳定的映射依据，而不是每次靠猜。
火山分析系统
官方帖子里还有一个火山分析系统。这类项目的价值在于把多模态输入和领域推理接起来：卫星图、地形数据、历史喷发记录一起喂进去，让模型做趋势判断。
它不适合替代专业监测设备，但适合做初筛和异常提示。风险点在于模型对罕见地质模式可能过度自信，输出结论时必须保留人工复核环节，别把概率性判断当成确定性预警。
为什么这些案例集中在 Opus 5.5
把几个项目放一起看，规律很清楚：它们都同时吃两样东西——长上下文和细粒度视觉理解。
120 页笔记是长上下文，涂鸦棋盘和火山图是细粒度视觉。Opus 5.5 在这两块的组合能力，让”一次性处理一整套原始素材并产出成品”变成可能。Sonnet 5.5 和 Haiku 5.5 也能跑，但更适合素材量小、对延迟敏感的场景。
选型上有个简单判断：任务需要跨几十页材料保持风格或逻辑一致，上 Opus；任务只是单图单轮问答，Haiku 就够，成本差一个量级。
复现前先想清楚的三件事
第一，素材质量决定上限。手写字体那个案例里，34 像素已经是极限，再糊就只能靠模型脑补，脑补出来的字迹就不是你的了。
第二，分批投喂要有衔接策略。长文档切段之后，段与段之间丢失的上下文需要靠摘要或示例图补回来，否则风格会漂移。
第三，生成结果必须过验证。字体要看缺字和基线，棋局要看结构解决析是否准确，分析报告要看结论有没有超出输入证据的范围。模型给的是初稿，验收标准得自己定。
这八个案例真正有意思的地方，不是模型多强，而是它们都在做同一件事：把过去需要一整个工作流才能完成的活，压缩成一次输入加一次输出。门槛降下来之后，拼的就是谁的素材组织得更聪明。
ID:6954
