Jev 这类 System One 模型：先验证需求，再蒸馏出专用分类器

深度摘要

“System One”模型（如 Jev）是快速通用分类器。分类器自 1958 年就已存在，但传统分类器必须针对特定任务训练：识别狗的分类器无法判断路灯颜色或信件是否紧急。而 Jev 像 LLM 一样可以通过提示词处理各种任务，从邮件分类到玩 Doom。作者认为这类模型会很重要：很多任务理论上 LLM 能做，但实际太慢太贵——例如逐条读取 Slack 新消息并判断是否需要通知用户。虽然可以为这类任务专门训练分类器，但有两个障碍：其一，训练专用分类器超出大多数普通工程团队的技能范围；其二，训练需要组装大规模数据集。Jev 显然解决了第一个问题：任何工程团队都能接上 System One 模型，用“根据以下标准，这条消息是否值得通知用户？”这样的提示词直接使用。作者认为它同样解决了第二个问题：严肃场景下，专用手建分类器永远比 Jev 更便宜更快——通用分类器要在权重里编码大量无关知识以应对各种任务，因此更大、更慢、更贵。但把一个调好的 Jev 实例替换成手建分类器会出奇地容易：一旦对 Jev 分类器的表现满意（想必已经花了几天调提示词），就可以直接收集它的输入输出数据——在 Slack 通知的例子里，就是 Slack 消息（含上下文）和最终的通知决策。攒够数据后，就能用这些数据训练自己的分类器。它不再是 Jev 那样的通用分类器，但在特定任务上表现应该不错，而且快得多。当然这仍需要一些 ML 专业知识，但一旦验证了功能值得做，再去发展（或租用）这份专业知识就容易得多。换句话说，因为 Jev 必须针对具体任务写提示词，任何成功的 Jev 用法都应该很容易被蒸馏成专用分类器。如果 System One 模型流行起来，作者预期这会成为常见模式。脚注补充：用 LLM 标注数据并非新思路，但在一个不确定功能是否成立的阶段，这一步成本太高；Jev 让“先验证、再蒸馏”的路径变得便宜。

关键要点

• Jev 这类 System One 模型是“快速通用分类器”：像 LLM 一样接受提示词，但只输出多选题决策，换来持续快速的响应。
• 核心论点：LLM 理论上能做但太慢太贵的任务（如逐条判断 Slack 消息是否值得通知），是 System One 模型的主场。
• 部署模式：先用 Jev 加提示词验证功能价值，过程中自然积累输入输出数据，再蒸馏成更快更便宜的专用分类器。
• Caveat：全文没有给出任何实测数字；“蒸馏很容易”依赖于 Jev 输出质量足够好、标签噪声可控，作者未讨论这一点。

关键事实

文中以 Slack 新消息通知判断为贯穿全文的例子。可确认：Jev 被描述为只输出多选题决策的快速通用分类器；作者此前写过《Two techniques for working with System One models》，称用约 150 行 Python（多为错误处理）拼出过基础版——批处理单 token 提示词加结构化输出，即得持续快速的通用分类器。作者声称：分类器概念自 1958 年就有；专用手建分类器在严肃场景下永远比 Jev 更便宜更快，原因是通用分类器权重里编码了大量无关知识；一旦提示词调好，收集输入输出数据并无额外成本，蒸馏“出奇地容易”。作者未提供独立验证：没有给出 Jev 与蒸馏后分类器的实测速度/成本对比数据，也没有讨论标签噪声问题。

作者观点

作者的判断是：System One 模型会很重要，因为它同时解决了“工程团队不会训分类器”和“冷启动没有数据集”两个障碍；他预期“先用 Jev 验证、再蒸馏成专用分类器”会成为常见模式；他承认专用分类器仍需 ML 专业知识，但认为那是功能验证之后才需要解决的问题。这些是基于工程经验的推断，而非实测数据支持的结论。

为什么重要

给“LLM 太贵太慢”的任务提供了一条务实的上线路径：用通用分类器做冷启动验证，用蒸馏做长期降本。值得跟踪的是 Jev 这类模型本身的进展，以及是否有团队公开蒸馏前后的成本对比。

编辑点评

这个模式的吸引力在于把两个难题解耦：产品验证不需要 ML 团队，降本不需要重写。但有两处作者没展开的约束：第一，蒸馏的数据标签来自 Jev 自己的输出，Jev 的系统性错误会被完整继承，相当于用模型的偏见训练下一代模型，作者只字未提标签噪声；第二，“攒够数据”在 Slack 通知这种低频决策场景可能需要很久，冷启动到蒸馏的时间线未必如文中轻快。尽管如此，作为工程思路，它比“直接上 LLM”或“直接训分类器”都更诚实。

深度摘要

擅长构建和擅长交付是两种不同的技能，短期内甚至相互抵触：越有构建天赋，越难交付。作者引用 Ira Glass 的名言——所有做创意工作的人入行都是因为品味好，但最初几年的作品配不上自己的品味，品味反而成了折磨；唯一的出路是咬紧牙关把东西发出去，哪怕觉得它是垃圾。编程部分：天赋型程序员近乎病态地追求优雅、正确、整洁的系统，这驱使他们钻研语言细节、反复打磨重构，但也让他们不愿交付——代码里的任何瑕疵都会在情感上困扰他们，带着瑕疵发布仿佛在昭告天下自己没注意或修不好。在大公司里这更致命：任何大型系统都布满瑕疵，时间压力、经验不足、棘手需求都是原因；与之共处是妥协的艺术，是在代码库的怪癖下找最优解；由于大代码库最重要的是 consistency，有时正确做法甚至是复制已有的瑕疵（只要不致命）。天赋型程序员常常僵住：退回能掌控“正确”的小领地（调开发环境、重构测试），或是什么都不做，在羞耻和负罪感里打转直到崩溃离职。作者刻薄地总结：品味差一点，他们编程会变弱，但会好用得多——坏的 diff 可以靠时间和努力改进，没有 diff 什么都改进不了。写作部分：作者自称对别扭的句子极敏感，写博客过半时候觉得成品不行，但大多还是咬牙发布，因为要偏向交付。和任何技能一样，交付越练越容易：一个月不发，再看草稿总觉得不堪；每天发一篇时，每篇都自我感觉良好。回头重读旧文，分不清哪些是当时满意哪些不满意，而受欢迎程度与当初自我感觉毫无相关。他列出几篇写作时不看好却火了的，和几篇自我感觉良好却没水花的，结论是：你无法预测什么会受欢迎，高产量的总收益远高于少量精雕细琢；要 momentum-based，不要 outcome-based。常见误区是把想法看得太珍贵，怕“浪费”在一个写得不好的故事里；但同一件事完全可以写三十遍直到写好——作者说自己写过约三十篇讲交付的博客，并打算继续。文末补记：Anthony Burgess 声称《发条橙》三周写成；柯南·道尔自认被遗忘的历史小说《Sir Nigel》远胜福尔摩斯。

关键要点

• 核心区分：擅长构建不等于擅长交付，短期内两者甚至相互抵触——品味越好，越难忍受瑕疵，越发不出去。
• 大代码库的务实规则：最重要的是 consistency；非致命瑕疵有时应该被复制而非修复。
• “坏的 diff 可以改进，没有 diff 什么都改进不了”——针对完美主义导致僵住、退回小领地或空转的程序员。
• 反直觉的经验：作者回头看，分不清哪些文章当时满意；受欢迎程度与自我感觉无关，因此高产量策略优于精雕细琢。
• 不要把想法看得太珍贵：同一主题可以写三十遍，想法不会被“浪费”。

关键事实

可确认：文中引用 Ira Glass 关于品味与作品差距的名言；作者列举的具体篇目——写作时不看好但受欢迎的：Do the simplest thing that could possibly work、Software engineering may no longer be a lifetime career、Software engineers should be a little bit cynical；自我感觉良好但没火的：Weak engineering managers、Paths through the space of all possible solutions、Trying to impress people you don’t respect。作者声称：自己“写过约三十篇”讲交付的博客；“回头看分不清哪些当时满意”、受欢迎与自我感觉“毫无相关”——均为个人经验陈述，无数据支撑；Burgess 三周写成《发条橙》、道尔更看重《Sir Nigel》为作者转述的轶事。

作者观点

作者的判断：构建天赋与交付能力短期互斥；在大代码库中一致性优先于正确性，为保持一致而复制非致命瑕疵是正确做法；交付是可练习的技能；成功不可控，只能靠高产量提高命中率。这是基于个人工程与写作经验的经验结论，带有明显的价值判断（“品味差一点会好用得多”）。

为什么重要

对完美主义工程师是直接可用的行为处方；对管理者则是识别“僵住的高天赋员工”的视角。局限是它本质上是经验谈，没有可验证的因果证据。

编辑点评

这篇文章最有意思的不是“多发”本身，而是它对大代码库的判断：一致性优先于正确性。这与“工匠精神”叙事直接冲突，但符合大型系统的真实约束——理解成本压倒一切。不过作者把“品味”几乎写成原罪，略过了另一种可能：好的品味如果配上交付纪律，恰恰是稀缺组合；他批判的是没有纪律的品味。另外“复制瑕疵”的建议他自己加了“非致命”限定，引用时别丢了这个限定。

深度摘要

这是 Simon Willison 在 Hacker News 帖子“MCP was always a bad idea?”下的评论。他先让步：如果你跑的是全功能终端 agent（Claude Code、Codex、Meta Muse、OpenClaw 等），且给了它不受限的互联网访问，那确实几乎没理由用 MCP——直接让它调 API 就行。但他认为原帖完全错过了 MCP 今天的价值：只要你想做的东西比“全油门 YOLO”稍微克制一点，你就会想要四样东西：精确控制 agent 能访问哪些外部服务；一种处理认证的方式，且不让 agent 直接接触 API 密钥；一个合理的 UI 让用户连接并认证更多服务；对发生的一切做强审计日志。MCP 让这四件事都容易得多。结论：因为全功能 coding agent 不需要 MCP 就断言 MCP 过时，错过了人们还想构建的其他东西。

关键要点

• 让步前提：全功能终端 agent 加不受限互联网访问，确实不需要 MCP，直接调 API 即可。
• MCP 的四项真实价值：精确控制可访问服务、不让 agent 直接接触 API 密钥的认证方式、用户自助连接服务的 UI、强审计日志。
• 核心反驳：“coding agent 不需要”不等于“没人需要”，MCP 过时论错过了其他形态的 agent 产品。

关键事实

可确认：这是作者在 Hacker News 讨论串下的评论，评论对象标题为“MCP was always a bad idea?”；作者列出的四项需求为：精确控制 agent 能访问哪些外部服务；处理认证，且不让 agent 直接接触 API 密钥；合理的 UI 让用户连接并认证更多服务；对发生的一切做强审计日志。作者引用的全功能终端 agent 例子：Claude Code、Codex、Meta Muse、OpenClaw（作者称它们可直接调 API）。以上均为作者的观点陈述，非实测结论。

作者观点

作者的判断：MCP 的价值不在能力层而在治理层——访问控制、密钥隔离、连接 UI、审计；“MCP 过时论”犯了以偏概全的错误，用 coding agent 这一个场景否定了其他形态的 agent 产品。这是技术路线判断，属于观点而非事实。

为什么重要

给 MCP 的定位之争提供了一个清晰的框架：能力问题 vs 治理问题。做企业级或面向普通用户的 agent 产品时，这四项需求几乎必然出现，值得在架构早期就考虑。

编辑点评

这个评论有意思的地方在于它把 MCP 从“协议之争”拉回到“谁需要被管”的问题上——YOLO 式的开发者工具不需要治理，但任何要交给别人的系统都需要。有趣的是，作者同一天发布的 llm-keys-ui（本期第 4 篇）正是第 2 项需求的一个具体解法：不把 API 密钥粘贴进 agent 会话。这两篇放在一起看，构成“问题—解法”的一组呼应。

深度摘要

这是一个解决非常具体问题的插件。作者开始用 Codex Remote 在多台机器上跑 coding agent，再用手机控制。有时他要在那些机器上折腾 LLM 项目，偶尔就需要在某台机器上配置 API 密钥。他不想把 API 密钥粘贴进 agent 会话，所以想要一种不经由 ChatGPT 应用、直接把密钥送上机器的办法。用法：让 Codex 运行 `uvx --with llm-keys-ui llm keys-ui --all`，它会返回一个 URL（含局域网或 Tailscale 设备 IP），打开是一个用来保存 API 密钥的网页界面；之后 agent 需要密钥时，在 shell 命令里用 `llm keys get anthropic` 这样的命令取用。已保存的密钥值永远不会被显示出来。配图显示界面中已存 anthropic、openai、openrouter、qwen-dummy 四个密钥，有“Key name / New value / Save key”表单。

关键要点

• 解决的问题：在远程机器上给 coding agent 配 API 密钥，但不想把密钥粘贴进 agent 会话。
• 用法：`uvx --with llm-keys-ui llm keys-ui --all` 起一个网页界面（支持局域网/Tailscale IP 访问），在手机浏览器里录入密钥。
• 取用：`llm keys get <名称>`，密钥值永不回显。
• 这是作者 llm CLI 生态的一个小插件，0.1 版，功能单一。

关键事实

可确认：版本号 0.1；启动命令为 `uvx --with llm-keys-ui llm keys-ui --all`；取用命令形如 `llm keys get anthropic`；配图显示服务端口为 8010，界面列出 anthropic、openai、openrouter、qwen-dummy 四个已存密钥名，密钥值不显示。作者称：他用 Codex Remote 在多台机器跑 agent 并用手机控制——为个人使用场景陈述。

作者观点

作者的判断很简单：API 密钥不应该出现在 agent 会话文本里，应该有一个独立的录入与取用通道。这是一个工程习惯层面的主张，而非宏大论断。

为什么重要

远程 agent 越来越常见，密钥分发是个真实痛点；这个小工具给出了“带外录入、运行时取用”的干净模式。意义限于个人与小团队工作流，不宜拔高。

编辑点评

小而美的典型 Willison 式工具：只解决一个具体痛点。它和作者同一天的 MCP 评论形成呼应——“不让 agent 直接接触 API 密钥”正是他列出的 MCP 价值第 2 条，而这个插件是同一原则在个人工作流里的轻量实现。两种路线（协议层治理 vs 小工具绕行）各有位置。

深度摘要

起因是 John Gruber 列出了他的 iPhone 名机堂：初代 iPhone、iPhone 4、iPhone 5S、iPhone X、iPhone 17 Pro。Jim Nielsen 接着给出自己的版本：初代 iPhone、iPhone 4、iPhone X、iPhone 12 Mini、iPod Touch。他的理由：初代不排第一说不过去，就像排总统山不放华盛顿；论美学，iPhone 4 是巅峰（只要你“拿对姿势”，顺手开了天线门的玩笑）；iPhone X 美学上接近 4，论形态则是最佳（顺带致敬 3GS 的曲面背板握感）；12/13 Mini 证明了商业成功不等于伟大，它们只是生不逢时。最后一个选择需要解释：iPod Touch 甚至不是 iPhone。但作者不同意——Touch 是“属于其余人的 iPhone”。当年买不起 iPhone（价格、地理、运营商限制），Touch 就是 gateway drug。对他而言是价格：2007 年还是穷大学生的他买不起 iPhone（还只能用 AT&T，更贵），Touch 是他第一次尝到 iPhone 的滋味；后来才在 eBay 淘到初代 iPhone 并越狱用在 T-Mobile 上（还记得 Cydia 吗？）。

关键要点

• 回应 Gruber：Nielsen 的五 pick 是初代、4、X、12 Mini，外加一个出人意料的 iPod Touch。
• 评选标准是设计与形态，而非销量：4 的美学、X 的形态、Mini 的“生不逢时”。
• iPod Touch 入选的理由：它是“属于其余人的 iPhone”，作者 2007 年作为穷大学生靠它第一次接触 iPhone。

关键事实

可确认：Gruber 的名单为初代、4、5S、X、17 Pro；Nielsen 的名单为初代、4、X、12 Mini、iPod Touch；作者称 2007 年因价格买不起初代 iPhone，后在 eBay 购入并越狱用于 T-Mobile。以上除名单外均为作者个人回忆陈述。

作者观点

作者的价值判断：美学上 4 最佳、形态上 X 最佳；商业失败的产品可以同样伟大（Mini）；iPod Touch 应被视为 iPhone 家族的一员，因为它承担了“让买不起 iPhone 的人尝到 iPhone”的历史角色。这是设计品味层面的个人榜单，无意论证客观排名。

为什么重要

一篇轻松的设计品味随笔，意义止于怀旧与审美讨论；顺带记录了 iPod Touch 在 iPhone 历史中的独特位置。

编辑点评

保持克制——这就是一篇博客主之间的趣味互动。唯一值得多看一眼的是它的评选逻辑：把“商业成功”从“伟大”里摘出去，以及给 iPod Touch 一个名分。这两者都是品味史观，而非产品史观，读的时候别当真去争排名。