一条二十多个英文单词的提示词，能让大模型写出多深的代码？
技术博主 Simon Willison 在 2026 年 10 月 23 日做了一次极简测试。他只给 Claude Opus 5.5 High 发了一句话，要求模型构建一个能在几秒内读取本地照片、并在网页 Canvas 上模拟画笔绘制油画效果的单页工具。生成的工具随后被命名为 Quick Study，代码以单一 HTML 文件 quick-study-painter.html 的形式收录进他的个人开源工具库。
常人以为这种随手搓出来的单页玩具无非是叠两层 CSS 滤镜，或者靠随机数在屏幕上胡乱涂抹色块。但当你右键打开这个独立网页的源代码，看到的是一套完整的启发式非真实感渲染管线：底层数据结构缓存、自适应边缘检测、多轮次误差修正，以及浏览器时间切片调度。
这不再是离散的代码片段拼凑，而是模型在零算法指引下自主完成的端侧计算图形学实践。
藏在 HTML 里的专业图形流水线
在这个只有单文件的 quick-study-painter 内部，大模型没有选择依赖任何重型外部三方库，而是用原生 Web API 搭起了一套完整的图像分析机制。
面对用户随意上传的高清大图，工具第一步直接写死约束：设定最长边分辨率 LONG = 1000 像素，将所有输入图像等比压缩至这一规格以内。这一刀切的设定并非偷懒，而是保证端侧纯 CPU 计算密度的底线屏障。
在图像加载完成的瞬间，脚本立刻调用 Float32Array 建立连续内存，缓存所有基础颜色通道，并在初始化阶段预先跑一遍 Sobel 梯度算子。这套边缘检测生成的梯度场，决定了后续油画笔触的走势——笔锋沿着轮廓边缘的切线流动，而不是死板地网格平铺。
更成熟的细节在于模糊缓存。算法预先计算并缓存不同半径的高斯模糊参考图。绘制初期，虚拟画笔先用粗大笔刷从深度模糊层取色，铺开大色块底色；随后笔触逐渐收窄，转向细部清晰层刻画。这种从大局到局部的层次感，恰好契合真实画师作画的思维。
原始图像输入 ──> 等比缩放 (最长边1000px) ──> Float32Array 内存预载
│
┌────────────────────────────┴────────────────────────────┐
▼ ▼
Sobel 梯度矢量场生成 多层级半径模糊金字塔
(决定画笔切线与走势) (大色块铺底至高频细节刻画)不仅如此，为了实现逼真的油画推演，代码拆分出多轮绘制过程。每一轮迭代里，函数 planPass 会调用主图层的 pctx.getImageData 读取当前画布快照，对比它与目标原图的颜色误差，优先把下一批画笔调度到误差最大的区域进行补偿覆盖。
在渲染展示上，它甚至还采用了经典的多层 Canvas 方案。笔刷轨迹在主图层上永久落色，而跟随鼠标位置的实时笔刷预览与参数标识，则在上方独立的 Overlay 画布上每一帧清空并重绘。这种物理图层的分离，让交互反馈彻底脱离了对已绘制油画底色的破坏。
调度妥协：藏在流畅背后的 22 毫秒裂痕
既然整套图形算法构建得严丝合缝，那它在浏览器运行时的真实表现究竟如何？
在渲染主循环里，Claude Opus 5.5 引入了 requestAnimationFrame 配合批处理调度。代码设定为每绘制 32 次笔画就执行一次耗时检查；如果当前这一帧的连续运算耗时累积超过 22 毫秒，就强行中断循环，把主线程控制权交还给浏览器，等待下一帧继续排队。
这种时间切片设计，是为了防止大量复杂的 Canvas 矢量绘制操作彻底卡死页面 UI。但只要你对现代浏览器帧预算稍有了解，就会发现这里的工程权衡留下了明显的瑕疵。
纸上得来终觉浅，绝知此事要躬行。
标准 60Hz 屏幕的单帧时间窗口只有 16.7 毫秒。如果把切片阈值直接放宽到 22 毫秒，意味着渲染密集时浏览器主线程必然掉帧。
更严峻的问题在主循环之外。每一轮绘制规划执行 planPass 时，代码都会直接在主线程中同步调用 getImageData 进行整屏像素回读与误差遍历。这种操作在移动端或核显设备上，会带来瞬间的内存带宽拥堵和不可避免的偶发卡顿。
模型学会了时间切片这一高级概念，但它对帧率底线与异步离屏渲染的把握，依然停留在粗放的经验主义阶段。
- 风险.在低性能设备或超大视口中，单帧超过 22 毫秒的硬性阻塞与同步像素抓取，极易引发明显的掉帧与交互撕裂。
演进标尺：从参数堆叠到像素逆向
如果把 Quick Study 放到更长的时间线上对比，大模型在计算图形学理解上的跨越会更加刺眼。
就在两个月前的 2026 年 8 月 25 日，Simon Willison 也曾做过一次类似的图形测试。当时使用的是 Claude Fable 5 Max，生成的是一个名为 pelican-watercolor 的实验工具。
在那个水彩鹈鹕实验中，模型的思路本质上是参数化的艺术规则模拟：依靠 P5.js 绘制水彩画，代码里写满了专门针对水彩风格的独立控制逻辑，包括分层的洗色层（wash layers）、边缘渗透效果（edge bleed）、手绘特有的墨线抖动（ink wobble）以及水彩飞溅（splatter）。那是一个依靠精细微调参数堆砌出来的风格化画笔生成器，它并不理解用户输入的图片内容本身。
到了 10 月的 Quick Study，核心逻辑完全变了。模型不再向外索求封装好的高级创意库，而是转向对原生像素数组的逆向解析。从基于 Sobel 梯度的几何引导，到依据颜色差分逐步迭代收敛，模型展现出一种近乎工程师本能的底层算法重构能力。
2026.08 pelican-watercolor (Claude Fable 5 Max)
┌──────────────────────────────────────────────────────────┐
│ 依赖 P5.js 框架 │
│ 针对风格的参数堆砌：洗色层 / 边缘渗透 / 墨线抖动 / 飞溅控制 │
│ 属于静态规则驱动的风格画笔 │
└──────────────────────────────────────────────────────────┘
│
▼ 认知跨越
2026.10 Quick Study (Claude Opus 5.5 High)
┌──────────────────────────────────────────────────────────┐
│ 脱离三方渲染库，手写原生 Canvas API │
│ 像素级逆向分析：Sobel 边缘导向 / 差分误差收敛 / 多层金字塔 │
│ 属于数据驱动的自适应端侧渲染引擎 │
└──────────────────────────────────────────────────────────┘这种单次成型的自然语言开发模式，正悄悄重塑独立开发者的生产力边界。你不再需要从零查阅计算摄影学教材去实现一套复杂的非真实感渲染算法，模型能在几秒内为你搭好骨架。
- 结论.大模型已经具备将高级抽象意图直译为准工业级底层渲染流水线的能力，但涉及深度帧率控制与端侧极限性能优化时，人类工程师的兜底与重构依然必不可少。
回看 Willison 最初抛出的那一句话需求，最耐人寻味的变量从来不是工具画出的油画有多像莫奈。真正的质变在于，大语言模型已经跨过了单纯代码搬运工的阶段；它在没有外在算法规范的前提下，自行决策并架构起了一整套数据结构与数学计算链条。至于那个偶尔卡顿的 22 毫秒，不过是这场机器工程进化留下的真实脚印。