我们从「本地模型很烂」到「本地模型其实挺行」的时间窗口压缩得非常快——大概只用了 12 个月。但我认为还不够好。我们需要一个 Opus 4.5 水准的本地模型。那个时刻到来时,我觉得整个世界都会翻篇。 Opus 4.5 非常惊艳,搭配一个 frontier 级别的 planner/judge,几乎能胜任所有任务。 当然跑起来肯定需要极贵的机器——大概 5000 美元以上的笔记本或 Mac Studio。但相比 API 费用,加上隐私保障等好处,这点钱最终会显得微不足道。
这就是为什么 PR diff 加载速度如此重要。这不是专门针对 GitHub——GitLab、Forgejo 等都一样甚至更差。但这种事让我抓狂,因为这是核心工作流,卡到我手都会从键盘上抬起来。 顺便说一下,视频里我的鼠标在左边乱抖,是因为页面真的在掉帧,我下意识地甩鼠标看它还能不能响应。键盘输入那里,你甚至能听到我打完了字,字母还没显示出来。 对我这种工具老手来说,我的脑子能驾驭这工具的速度,远比它自己能跟上的速度快得多——这不是好事。工具不应该挡在路中间。
AI slop 其实是好事。Slop 让快速并行实验成为可能。真正的技能在于理解 slop 的边界——它存在于哪里、该清理到什么程度。 几个例子: 我现在正在做某个系统的内部架构。它的 API 和 GUI 完全是零羞耻的 slop,很糟糕。但这让我能专注于核心质量,同时向测试人员交付可用的 alpha 版本(对 slop frontend 完全透明)。 类似地,这个系统有插件。我们让 agent 跑了一夜,生成了几十个插件。插件是 slop,质量差,插件 API/SDK 也远没完成。 但我们可以测试一个配有完整插件生态的 GUI。修改 API 时可以重新生成所有插件。变更成本只是 token,速度无可比拟。 我做过 Terraform。TF 0.1 发布时只有约 3 个很弱的 provider,因为时间不够。构建很慢,改 SDK 的代价极高。10 年后的今天完全不同了。今天我会用 slop 生成 100 个 provider(保持透明、后续清理,只是为了验证可行性)。 反例:我不会在没有提前说明的情况下把这个 PR 提给别的项目。我不会在没有充分审查或透明度的情况下交付给客户。我不会接受第一版 slop——它几乎从来都不对。 Slop 是一种工具。和其他任何东西一样,没有绝对好坏,上下文决定一切。
760 tweets · 188 sources