微信反截图

如果你用 claude computer use 在一些软件上，可能会触发他的保护机制，比如反截图，截图出来都是空的。这是当前 computer-use 方式的一个根本性限制。

nano vllm：prefill 和 decode 的本质

一句话本质区别：

Prefill:  100个token 同时进GPU  → 很快，GPU全力开工
Decode:   每次只出1个token     → 慢，GPU大部分时间在等显存

Scheduler 管的是两个队列

  • waiting 队列：新来的请求，还没开始处理
  • running 队列：正在 decode 的请求（已经 prefill 完，正在一个个吐 token）

每次 schedule() 的决策逻辑：有 waiting 里的请求 → 做 PREFILL，把它移到 running；没有 → 做 DECODE，处理所有 running 里的请求。这就是 continuous batching 的精髓。

preempt（抢占）：如果显存不够了 → 把 running 里某个请求"踢回" waiting → 释放它占的 KV cache 显存 → 等有空间了再重新 prefill 它。

KV Cache

没有 KV cache 时：生成第 2 个字之前，对所有字重新算一遍 K 和 V——其中之前算过的全部重算，浪费。

KV cache 就是把算过的结果存起来：直接从显存读取已缓存的 K、V，只需要算新字的 K6、V6。

KV cache = 草稿纸

Prefill 阶段：把 prompt 里每个字的"理解结果"全写到草稿纸上
Decode 阶段：每生成一个新字，只在草稿纸上加一行，不用重写前面的

为什么 decode 慢：每生成 1 个 token，都要把整张"草稿纸"从显存读一遍。草稿纸越来越长 → 读的数据越来越多 → 瓶颈在显存带宽，不在计算。

PagedAttention

朴素 KV cache 的问题：连续内存分配。请求 A 的 cache 越来越长但 A 后面紧跟着 B，没地方扩展。

PagedAttention 的解法——像操作系统管内存一样管显存：把显存切成固定大小的"块"（每块 16 个 token 的 KV cache），请求用不连续的块——就像电脑硬盘的文件系统。

请求A：  [块1] → [块3] → [块7]   ← 不连续没关系！
请求B：  [块2] → [块5]
请求C：  [块4] → [块6] → [块8]

Notion 分享：模型行为工程师（MBE）

这个角色是数据科学家 + PM + 提示工程师的混合体。核心产出是 eval 和 LLM judge，而非功能代码。为什么不是软件工程师？大量工作是定性判断——理解"这个任务算失败还是成功"，背后需要品味和直觉。Notion 有意识地把这个岗位做成了独立晋升路径，欢迎"misfit"——背景可以不是工程，但必须有对"什么叫做得好"的判断力。

Notion 把 eval 分成三层：CI 中的回归测试（必须达标）、发布质量报告卡（80-90% 通过才能上线）、以及"前沿/余量 eval"（故意只过 30%，用于理解模型天花板在哪里）。MBE 团队专门负责第三层，相当于 Notion 的"自己的期末考试"。

"软件工厂"的设计思路

  • 规范层（Spec）：用 Markdown 文件提交到代码仓库。要求人类可读、可浏览、可修改，是 agent 行动的"宪法"。
  • 自验证（Self-verification）：需要非常完善的测试层，agent 能够执行代码、看到测试结果、自己 debug、自己提 PR——整个闭环在同一个运行时环境里完成。
  • 缺陷流（Defect flow）：给 agent 群建一个内部 issue tracker（一个 Notion 数据库），manager agent 订阅并处理，把 30 个 agent 产生的 70 条日通知压缩到 5 条。
  • 保留关键不变性：最重要的例子是权限模型。agent 不能自行修改自己的权限——这是设计上刻意保留的人工干预点。