@yetone 看完了这个，我更不明白啥是 ai slop 了，ai 喜欢用的就是 slop 吗？可 ai 学习的本来就是最常见的“最佳实践”，到底是用 xxx 是 slop，还是没用统一风格基调整体不协调是 slop 呢

LLM 这块真的有什么硬性的护城河吗，开源社区已经把各种大模型，基础设施都端上来了，openai 和 anthropic 的领先地位到底还能持续多久？又或者以后是否还有必要为那一点智能支付高昂的溢价？目前的感觉是，谁有卡谁就是大爷，这么看马斯克布局数据中心确实是一手好棋

抽空做了个 Eval,评估下最近比较火的 GLM-5.2 能力 先说结论: GLM-5.2 的模型能力(理解 + 写代码)不输 Opus 4.6,真正的差距在"如何在真实环境里高效干活"——而这恰恰是最吃 harness / RL 训练的部分，也是 Cursor Composer 重度使用的方式。harness 调好了,这模型的威力还能再放出不少。 方法:同一道 Rust bug(serde_json #979#),给 evot / claude-code / pi 三个 agent ,分别换 GLM-5.2 和 Opus 4.6 两个模型跑,对比它们的执行轨迹。 结果: 两个模型、6 个 session 全部 PASS,GLM-5.2 在"做对"这件事上没问题,bug 理解和最终代码质量都过关。 但代价差了一个量级: • Opus 4.6:三个 agent 齐刷刷 18 轮收工,~80s • GLM-5.2:38 / 43 / 61 轮,慢约 7 倍 拆 trace 看清楚了,差距不在懂不懂 bug,而在 agentic 执行这层: 1. 环境处理是软肋——GLM 有十几轮卡在 cargo 上反复试错(CARGO_HOME、cargo metadata、翻 serde 源码),Opus 一轮就绕过去了 2. 不收敛、爱反复验证——写完还手搓临时测试文件建了又删,thinking 字符数是 Opus 的几十倍 3. 但代码品味在线——GLM 最终的 fix 反而更克制地道,一个 match 合并三个 case,注释把设计意图讲清楚了,比 Opus 那版还干净

上个月，CloudFlare发布了一篇关于Mythos Preview使用感悟的文章，他们发现Mythos给所有在使用AI的安全人员有着以下启示： 1. AI 阶跃的能力分水岭：攻击维度的“链条化思维” 以往的 AI 在安全领域被视为 SAST/DAST 等自动化扫描器的替代品，其输出依然停留在“发现孤立代码缺陷”的行业平均水平。但 Mythos 的出现标志着一个分水岭：大模型正在跨越从“缺陷发现者”到“高阶攻击研究员”的鸿沟。 其体现在两个方面： ① 从“单点缺陷”到“全链条利用” 传统的扫描器只会死板地把低危漏洞扔进积压任务（Backlog）。而Mythos具备了将数个原本孤立、低危的“原生安全隐患”串联起来的能力。它像一个资深黑客一样，能思考如何利用 A 漏洞突破内存，再利用 B 漏洞劫持控制流，最终拼图般组装成一个高危的远程代码执行（RCE）攻击链。 ②闭环自我修正 AI 能够自主在隔离沙箱环境中编写概念验证（PoC）代码、编译、执行，并根据报错信息不断调整假设、重试，直到漏洞被证实成立。这种“漏洞挖掘 + 自动化验证”的闭环，直接让 0-Day 的生产线实现了全自动工业化。 2. 防守方的工程破局点：“外壳（Harness）”决定大模型能力的上限 如果说通用大模型代表了行业的平均基准，那么企业围绕大模型构建的工程化外壳（Harness），就是拉开专家与平庸者差距的“杀手锏”。直接把一个通用编码 Agent 丢给全量代码库去扫，是彻头彻尾的工程灾难。 大模型天然存在上下文膨胀带来的幻觉、极高的误报噪声，以及“概率性拒绝执行（有机推诿）”等不确定性。而工业级的解法必须是“用架构规范模型”。通过将庞大的任务拆解为窄域隔离（Narrow Scoping）的单点任务，并引入 AI vs. AI 的自动化对抗评审机制（用一个 Agent 去审计和削减另一个 Agent 的噪声），才能把大模型的平均能力，淬炼成极高精准度的安全生产力。 3. DevSecOps 的终极演进：从“疲于修补”走向“架构免疫” 在 AI 能够批量规模化制造、组合漏洞的时代，传统的防御体系（如依赖特征码、SLA 为数小时的 WAF 规则、无休止的代码修补流水线）已经彻底失效。 其具体体现在漏洞增长速度与修补能力的脱节，即 AI 找漏洞的效率是成百上千倍的提升（例如 Mozilla 借此单次修复 Firefox 271 个漏洞，Cloudflare 发现 400 个高危漏洞）。防守方如果只是在前端卷漏洞修补速度，就会陷入被 AI 刷出的“漏洞海”活活淹死的死胡同。 因此未来的网络安全治理核心必须向全域治理与业务上下文（Business Profiles）隔离靠拢。安全的终局是通过纵深防御和架构设计，让“漏洞即便存在，攻击者也无法在多云、多细分网络中闭环利用”。 《Project Glasswing: what Mythos showed us》

之前在 codex 里装了 notion 的 mcp，后面发现不太好用而且拉慢了启动时间所以就删掉了，结果后面发现有时候还是会出现，删不掉，困扰了我好久，今天突然灵感乍现，果然，是 ccswitch 的问题。。。 因为某些原因， ccswitch 保存了旧的配置，然后某些情况下，就会覆盖新的配置，导致删不掉。。。

这个运营商的公益短信到底要怎么屏蔽？！联通总是三天两头给我发公益短信，和骚扰几乎没什么区别，给客服打过电话反馈过了但也没什么用，第二天照发无误。 我记得曾经熊猫吃短信是可以屏蔽掉这些信息的，不知道为啥后来突然就不行了，呼叫 @waylybaye 真的绝望了 🥹

最近几个月都在高强度使用 AI 写代码，感受是 vibe coding 确实简单，只要你会打字，基本就能做出东西。 但如何使用 AI 真正高效地交付一个产品，却并不简单。最大的问题在于，信息的传递是有损的。人与人之间沟通会丢失掉一些信息，人指挥 agent 时又会丢失掉一些信息，一直走下去，势必就会出问题。 当出现问题时，人往往已经丧失了对代码 100% 的掌控，而 agent 又倾向于做保守式，向后兼容式的修复，导致继续糊屎。 最后实在受不了了，只能让 agent 按照旧实现重写一个新的 😵‍💫

上周六分享了「Trace 即 Evals」，聊了一个问题：Agent 改了 prompt、换了模型、加了 tool，到底变好还是变差？ 几个关键点： - Agent 是链式反应，一步偏了后面全偏，只看 pass/fail 没用 - 同任务同模型，换 harness，token 消耗差 3 倍，成本差 67% - 轨迹存下来才有归因的可能——哪一步选错 tool、哪一步上下文炸了，展开就能看到 - Anthropic、OpenAI这种头部模型公司迭代 agent 靠的就是 trace 驱动的量化闭环，这套方法不该只有大厂能用 Slides 👉

Cursor 还是有两下子的，危机感非常强，训 Composer 2.5 的做法： 1. 把全部权重押在一个任务上。不做通用编程，只做"Cursor 里的软件工程"。模型就像一块存储盘，容量有限，那就把所有权重都喂给这一个任务 —— Composer 比 Opus 便宜一个数量级 2. 基座用 Kimi（1T MoE，30B active），先做接近预训练规模的 mid-training 灌代码 token，把分布铺宽；再上大规模 RL 把分布削尖。mid-training 让它会写代码，RL 让它写"对"的代码 3. 让模型直接在自己的 harness 里 RL。工具怎么调、环境怎么导航，全部烤进权重，不靠 prompt 描述 —— "prompt engineering 有上限，想做好产品就得改模型本身"。连上下文压缩都塞进 RL loop（self-summarization）：200K 窗口的模型，实际能连续跑到百万 token 4. 不用第三方 RL 环境厂商，直接拿生产环境（隔离副本）训；再加 real-time RL —— 从用户 happy/sad 的信号里，每几小时更新一次模型 Cursor × Fireworks · Sequoia Podcast 2026.05

这一段时间两大头部 AI lab 的模型发布似乎侧面印证了在现在的架构上没法做到智力与安全对齐的平衡。 opus 4.7 4.8 也许都是 用 mythos 作为 teacher 模型微调出来的稍小模型，同时加入更多安全对齐手段，可惜从目前情况来看效果并不如人意。 但某种程度上这也许又是好事，有能力限制那就有空间去解决问题，还不至于让大家都饿死 🤪