In Sarah We Trust! MTS @MTSlive Notion AI lead @sarahmsachs argues that a lot of what runs on GPUs today should actually run on CPUs: "We have a strong perspective at Notion that a lot of things should be served on CPU that are served on GPU. There’s a lot of benefit and determinism in executed code." "Agents don’t need LLMs to reinvent that process every time, and that’s super token exhaustive, it’s super slow, and there’s no observability or determinism in it." "Giving the agent a local file system to store local thoughts, to write short Python scripts, that’s really important when there’s so much information. That has been probably one of the most important tools outside of edit and search that our internal agents rely on." @NotionHQ 🔗 View on Twitter 🔗 View Quoted Tweet
ARCHIVE
内容归档
正文、图片和 Markdown 均已本地保存，不包含回复区。
imagine this, imagine that imagine a tech industry with no hype Veee @vikktorrrre Dario Amodei: We may be only two or three years away from AI systems being better than humans at almost all tasks. “I call it a country of geniuses in a data center.” “Imagine tens of thousands of geniuses, smarter than a Nobel Prize winner across many fields.” “They could cure diseases and extend the human lifespan.” “I wouldn’t be surprised if we were able to double the human lifespan.” “They may even build robots for themselves and project themselves into the physical world.” “There are all kinds of questions around the balance of power.” 🔗 View on Twitter 🔗 View Quoted Tweet
在 X 逛久了，就会误以为大家都在用 Claude Code 和 Codex 等顶尖框架+模型。 国内多数人真实情况并非如此，感觉这个系列报告很有价值，值得追更。 原贴地址： x.com/LobsterAIYouda… 往期报告： mp.weixin.qq.com/s/Tp744o80FPQN… LobsterAI @LobsterAIYoudao 第一期《中国办公 Agent 用户行为报告》发布后，引发了媒体和用户的关注与讨论。大家关心 Agent 产品的发展，也关心人们究竟把哪些工作交给了它。因此，从本期起，我们将按月发布报告，持续记录用户使用习惯的变化。本期聚焦 9 月，并额外补充十一假期的使用变化。 9 月，用户单次任务规模继续增长；泛编程/IT 仍是办公 Agent 的主要用途，但是设计与内容创作正在升温。缓存策略的差异，为何能导致成本相差七倍多？哪些城市的用户深夜还在派活给 Agent？到了十一假期，使用高峰和任务需求又发生了什么变化？请锁定这期报告，我们看看 Agent 行业又有什么新变化！ 🔗 View Quoted Tweet
不同城市的人用 Agent 数据有啥不一样？ 印象最深的是重庆用户：晚上 10 点到凌晨 2 点调用，占全天 19.1%，果然是有夜生活的城市。 城市用量排行前几名不出意外，还是北上广深。 不过郑州、东莞能进前十榜也是有点意外。 图2看，办公 Agent 用户规模还在扩大，单次任务规模也从 3 月的 6.3 万涨 9月的 20.2 万Token。 感觉大家日常生活，慢慢都离不开AI Agent 了，且给的任务越来大。 报告还补充了国庆假期的数据，有点意思： 假期 Agent 使用高峰从下午 4 点，推迟到晚上 10 点。 白天出门玩，晚上回去继续蹬模型... 有了 AI Agent 后，大家都变得更忙了。 不过，“打工活儿”变少（文档、翻译、数据表格等），编程、学习、个人生活相关任务涨了。 放假了，“不得不做的事”先停，让“想做的事”继续。 最后，图像和视频生成任务中，字节太牛逼了！ Seed 系列模型调用超过一半，完全没对手，遥遥领先。（觉得还是需要竞争啊，其他大厂努力啊）
我去，读了网易 LobsterAI 刚刚发布的《中国办公 Agent 用户行为报告》 不少结论太反直觉了，跟 X 上大家 Agent 用法不一样。 比如： ① 微信竟然是最大办公 Agent 入口 ② 办公 Agent 的最大场景还是（泛）编程 ③ 73.6% 普通用户仅用一个模型 下面展开说说： 很多人把办公 Agent 接到微信、飞书、QQ 等 IM 里用，微信占比最高 77%，飞书 14.3%排第二，然后是 QQ。 微信跟国人绑定太紧了，也最顺手，上午 7-11点给 Agent 派活很多，看起来像上班路上用？ 交给 Agent 的工作中，泛编程/IT 最多，是最大的使用场景。另外，设计/影视/创作使用量上升飞快，感觉这两大类任务都是模型能力的甜点区。 从报告里看，感觉普通用户不怎么切模型，默认给啥用啥，73.6% 普通用户只用一个模型。 普通用户人均使用 1.6 个模型，重度用户是 2.4 个。 最常见两种组合：DeepSeek Flash 系列 + GLM 5.3 Flash（14.0%），DeepSeek Flash 系列 + V4 Pro（12.4%） 梁圣 DeepSeek 缓存有黑科技，性价比一直超高。 这数据用的是 V4.1 Flash 旧版，新上的 V4.1-Flash-1017 能力又大幅提升，接近GPT 5.6 sol，感觉又要杀疯了。 还有一些有趣的观察，见第二条
我们在这一期《Next Token》播客里的一些核心认知： 橘子说的：只要 AI 把一个东西打到了 60 分，这个东西就变成了 0 分。所以一个东西越火，越容易变成 AI slop，然后被大家抛弃 所有的 skill prompt 软件，唯一价值其实就是流量价值。目前随着 AI 破解能力和复刻能力越来越强，开源作品换注意力、然后再做转化，是一个非常常见的方式 多 Agent 拉群其实只有情绪价值，没办法带来能力上的提升 我还分享了一下我是如何不开电脑做自媒体的，包括发图文、剪视频等等。 这期昨天已经更新了，欢迎收听！ 早上一起床已经有 4000 多个播放，同时收听有几百个人在听。作为一个只更新了 6 期的播客，还是挺吊的
源： x.com/enggirlfriend/… Engineer Girlfriend @enggirlfriend there’s a ridiculous trend going viral on tiktok right now called “malfoid” a harry potter fanfic story where draco malfoy is a girl and in an enemies-to-lovers story line with harry the AI videos are so good and it’s actively shifting AI sentiment on tiktok to positive (was historically super negative) 🔗 View Quoted Tweet
源： x.com/rileybrown/sta… Riley Brown @rileybrown This video edit was created in a single prompt with Opus 5.5 and blender. I just recorded the video and uploaded it to claude and it used a skill i've been working on for a day. It cut out the mistakes, added the music, sound effects all rotating around a single scene in blender. I think it's about 3% as good as it could be. Will be iterating on it to make it 1% better every day. Just posted it on IG, let's see how it does. 🔗 View on Twitter 🔗 View Quoted Tweet
「弱结构」：对象身上的规定，少于使用者需要的规定。缺失的部分，由每个使用者自己补上。 「强结构」：对象身上的规定，等于或多于使用者需要的规定。使用者无法再补上任何东西，对象已经替他决定了。 一笔预算叫「创新基金」，产品团队拿它试新功能，市场团队拿它做品牌实验，技术团队拿它搞架构升级。三方对「创新」的理解不同，但这笔钱只要求一件事：跟创新沾边。各方各取所需，互不干涉。这是弱结构。 现在这笔预算加上了使用细则：只能用于经过创新委员会评审的项目，必须提交三页立项书，季度末汇报 ROI，单笔超过五万需要副总裁签字。三个团队拿到的是同一张表格，填出来的东西长得差不多。钱还是那笔钱，但它从一个各方都能往里装自己想法的容器，变成了一条只按评审委员会的标准才能通过的管道。这是强结构。 大公司病不是流程太多。流程是症状。病因是：本该保持弱结构的公共对象，被一步步固定成了强结构。 推动固定的往往不是工作需要，是那人想成为「必经之点」——他在对象上每多加一条规定，别人绕过他的路就少一条。当组织里大量公共对象都被这样固定，信息怎么流动就不再取决于谁需要它，而取决于谁有权放行它。
源： x.com/a16z/status/21… a16z @a16z Ben Horowitz on what it would take to actually see an AI "fast takeoff" scenario, using a framework from Databricks CEO @alighodsi : 1. Each new model needs far fewer GPUs than the last 2. Each new model takes less time to train 3. Each new model is more accurate than the last 4. It keeps happening, again and again "Zero of those four have been met... We're really talking about a risk that's entirely theoretical at this point." @bhorowitz on @theallinpod 🔗 View on Twitter 🔗 View Quoted Tweet
把封中国人的订阅钱 拿来做慈善改善形象呗？ Anthropic @AnthropicAI We’re committing a portion of Anthropic’s shares to the Anthropic Public Benefit Fund, a new wholly owned entity dedicated entirely to the public benefit. It will start off with 5% of our shares. For every 50% increase in the company’s value over a set baseline, we can contribute up to an extra 2%, subject to our board’s discretion. In total, this means that roughly 20% of Anthropic’s shares are committed to the public good. Our co-founders have already pledged to donate 80% of their equity, and around half our employees are donating a portion of their equity as part of a donation matching program we’ve run since our founding. In the post below, we share more details about our new fund. anthropic.com/news/public-be… 🔗 View Quoted Tweet
Obsidian CEO @kepano 开源了一个 Mermaid 图表渲染库「Pele」，它完全重写了 Mermaid 12.1.0 全部语法的解析与渲染，输出 SVG，零运行时依赖。它没从 mermaid.js 封装或 fork，是一套从词法分析、布局引擎到 SVG 生成全部自主实现的替代品，将成为 Obsidian 下一版本的内置渲染器。 开源地址： github.com/obsidianmd/pele Pele 和 mermaid.js 的数据对比非常惊人！ Bundle（gzip）：230 kB vs. 1.6 MB（约 6×） 渲染耗时：0.05–0.3 ms vs. 6–82 ms（最高约 500×） 直接依赖：0 vs. 23 # 架构：为什么能这么快、这么小 自己写解析器。 源码中约 30 个图型各自拥有独立的 lexer → parser → model → render 管线，没有引用 Mermaid 的运行时代码。解析器通过 Mermaid 官方的 parser spec 和差分模糊测试（differential fuzzing）验证语法兼容性。 自己的布局引擎。 src/layout/ 下有三个自研布局：分层布局（layered，约 78 KB，核心）、泳道布局（lanes）、复合嵌套布局（compound）。这意味着 Pele 摆脱了 mermaid.js 依赖链中的 dagre、d3 等库；这 23 个直接依赖正是 mermaid.js 体积和速度问题的主要来源。 同步渲染。 render(text) 直接返回 SVG 字符串，没有异步生命周期。这能成立的关键在于文本测量方案的差异：浏览器端用 canvas 测量，无 DOM 环境（如 Node）则用内置字符宽度表，可注入自定义 measurer。文本测量决定节点尺寸，这是多数图表库被迫异步等待 DOM 的根本原因，Pele 用同步测量把它解决了。 主题与渲染解耦。 颜色、字体、圆角全部通过 CSS 变量（--pele-fg、--pele-surface、图表系列色 --pele-series-1~8 等）下发，SVG 里不写死颜色。切换明暗主题时浏览器重新解析变量即可，无需重新渲染；这对 Obsidian 这种主题实时切换、一个笔记里可能有几十张图的场景是精准的架构选择。 kepano @kepano This is Pele, my new rendering library for diagrams and charts, compatible with the latest Mermaid syntax. - 100-500× faster than mermaid.js - 6× smaller bundle - No dependencies - Easy to theme - Responsive to device width In pursuit of making Obsidian insanely fast and cohesively designed, I always found the Mermaid library to be too big, too slow, and too hard to theme. Pele will be the new renderer in the next version of Obsidian, but you can start using it now. Pele [ˈpɛlɛ] is named after the goddess of volcanoes and fire. It's open source under the MIT license. Try the playground! 🔗 View on Twitter 🔗 View Quoted Tweet
Addy Osmani 谈 Agent 时代代码审查的重构 Claude 编写了 Claude Code 约 90% 的代码，而在 6 月到 9 月间，团队合并的 PR 数量翻倍以上，回滚率反而下降了超过 40%，怎么做到的呢？ Osmani 认为：当 AI 生成代码的速度远超人类审查能力时，瓶颈从 “写代码”，转向了 “证明它能正常工作”。解决方法不再是让更多人逐行审代码，是构建一套多层的、快速确定性反馈的验证系统；正是这套系统让“90% AI 编写”从风险变成了优势。 # 几点关键做法 审查的重新定义。 审查的目的从“是否有人读过这段代码”变为“这个变更可能出什么问题，该由哪一层检查来抓”。审查不再是合并前的终点关卡，更像拼写检查；大多数变更在被人类看到之前，已经被 AI 审查并修复过至少一轮。 具体的分层流水线： · PR 之前：Claude 运行测试、构建、linter，必须展示真实输出而非口头声称完成；另有一个全新上下文的 subagent 独立审查 diff。 · PR 上：必需 CI 阻塞合并；多个 AI 审查 agent 并行找 bug，由“验证者”投票过滤误报（内部 PR 获得实质性审查评论的比例从 16% 升至 54%）；独立的安全审查流程。 · 风险分级审批：由分类器（而非作者本人）判定风险等级；低风险（文档、flag 后的增量改动）零人工，中风险一人，高风险（计费、自动更新等敏感路径）两人。AI 的审批永远不能占用人工名额。 · 合并之后：flag 灰度内部先行，出问题可不部署直接关闭；每周 on-call，事故复盘追问“哪一层本应拦住它”。 两个特别值得注意的工程细节： 1. 事故转化为 eval。收集历史上导致事故的 PR 作为每日评测集，AI 审查器的任何改动（提示词、工具、模型）都要在这个集合上跑分，分数不升就放弃。这把“审查质量”从主观感受变成了可度量的回归测试。 2. 强制审查收敛。一个 PR 曾一夜被 AI 审查了五十多轮；团队发现 59% 被反复标记的是早已存在的旧代码，于是设定三轮封顶、只审新增 diff 等规则。效果是一轮通过的 PR 从 65% 升至 78%。 人的角色如何变化 人类保留的决策是：做不做这个功能（方向与品味）、高风险代码的审批、会成为他人模板的架构决策、以及对证据的阅读和最终问责；"you land it, you own it"。工程师的工作从逐行阅读，转向评估风险、评估证据、决定方向。 Osmani 结语这句话我自己很喜欢，分享给大家 Let the agents do what they do best and let you focus on what makes you irreplaceable: judgement, direction, and ownership. Addy Osmani @addyosmani Give your agent a way to verify its work. This can dramatically improve the quality of output. With this process in place, Claude Code was able to write 90%+ of its code itself. When generating software at a faster rate than you can review it, the bottleneck shifts to proving that it works. @bcherny and team invested enough in verification, we've been able to move fast while maintaining stability. Code reviews aren't going away, but you need to think of it differently. One human reading through line-by-line is no longer going to work as a gate, it needs to evolve into a multi-layered verification system, built with fast deterministic feedback loops for your agents. This is where e2e tests, feature maps (as @poteto has been advocating), property tests and multi-agent adversarial reviews come in. These all provide opportunities to catch errors early and fix them before things get out of hand. You don't have enough eyeballs for the amount of code being written so your focus needs to be on product intent, risk assessment and evaluating evidence rather than reviewing code. Delegate the code checking work to your automated tests, scale your approvals based on risk, and turn your test failures into living evaluations. This approach helps maintain speed without losing reliability. Let the agents do what they do best and let you focus on what makes you irreplaceable: judgement, direction, and ownership. We tried to capture how we handle code review and verification in this writeup. Hopefully it's helpful. 🔗 View Quoted Tweet
The Pragmatic Engineer 作者 @GergelyOrosz 分享了一个对开发朋友们非常典型的困扰：老板被各种 AI 炸裂新闻洗脑，把 "AI token 用量" 设为 KPI ！而求助的这位工程师平时很少用 AI，因此被管理者反复敲打。他感到很大压力，认为自己被贴上了 "过时、低效、拒绝拥抱新技术的工程师" 的标签。 Gergely 的立场出人意料地站在了管理者一边： 1. 重新解读管理者动机：管理者不是在刁难你，是在"帮你"；他在用一种笨拙的方式推动你适应一场必然到来的行业变革。 2. 直白地认同那个标签：那位工程师抱怨被污名化，Gergely 的回答是"可惜这就是事实"。他做了一个关键区分：你可能是非常优秀的工程师，但"优秀"与"拒绝学习新事物"并不互斥。个人技术再精湛，拒绝适应仍然是不职业的表现。这里 "职业素养" 一词用得很重：在他看来，持续学习新工具本身就是职业素养的一部分，而非可选项。 3. 给出二选一的决策框架：对于在现状里"待舒服了"的工程师，只有两条路 · 上船：接受 AI 会深刻改变自己的工作方式，忍受快速变革带来的不适感； · 拒绝：这也可以，但要诚实地接受代价；愿意雇你的公司池子会持续缩小，你只能自雇，或干脆离开科技行业。 Gergely Orosz @GergelyOrosz A middleware engineer in South Korea wrote to me, seeking help on what to do now that their manager is "blinded by GenAI hype" and set an "AI token usage" KPI. This eng is using v little AI, so manager is poking them to use more. My response: your manager is trying to help you 🔗 View Quoted Tweet
看了 LobsterAI 新一期的《中国办公 Agent 用户行为报告》 9 月单次任务的 Token 规模已经是 3 月的 3.2 倍了 大家交给 Agent 的任务，真是越来越大了… 设计/影视/创作的占比也涨到了 17.2%，这个我倒不意外 图和视频生成完，后面还有一堆整理、修改、交付的事情，都是 Agent 的强项。 缓存那张图建议存一下... Agent 做任务要反复读前面的内容，缓存能不能命中、命中后打几折，最后的费用可能差很多 看起来单价便宜，用起来不一定省钱！ 还有个数据：报告统计的 IM 派活用户里，77% 用微信。 这个入口确实太顺手了，想到什么先发过去，不用专门打开电脑。 人不在工位，但是任务到了 😂 城市那几张也挺有意思，郑州进前十，重庆用户深夜还在用。加上任务规模、模型搭配、实际费用，能看到不少平时刷模型新闻注意不到的东西 天天都在看新模型又涨了多少分，偶尔看看大家到底拿 Agent 做了什么，还挺有必要的。
pstack 新增了一个 skill /create-formal-verification-skill 定位是 meta-skill：不直接帮你做形式化验证，而根据你想验证的系统特性，自动生成一个定制的验证 skill 和配套验证套件。比如你要验证状态机和并发行为的正确性，它会生成基于 TLA+ 的方案；要排查 Rust 代码的未定义行为，则生成基于 Kani 的方案。 Grok Bot 插件安装： x.ai/bot/plugin/971… 背后的概念：形式化验证 测试只能证明 “bug 存在”，无法证明 “没有 bug”；形式化验证则是对系统的性质做数学证明：证明某个不变量 (即“必须永远为真”的性质或“定律”) 在所有可能的情况下都成立。 poteto 点出了两条技术路线的分别： · 传统路线(外置建模)：用一门独立的规范语言 (如 TLA+) 给系统建模，再运行求解器/模型检查器去穷举状态空间验证规范。代码和证明是两套东西。 · 新路线 (同语言证明)：Kani 直接写在 Rust 里，Bend 的证明以 laws 的形式表达在其类型系统中；没有单独的建模语言，证明和代码活在同一处。 形式化验证是个 “理论很美、实践从未进入主流” 的领域，poteto 指出了两个历史原因：建模本身很难 (把业务需求抽象成形式化模型是专业 skill)，以及规范与实现难以同步 (需求一变，两份东西都要改)。 她的判断是：这两个瓶颈恰好是 LLM 擅长接管的，让 agent 承担建模和同步的苦活。而反过来，形式化验证给 agent 提供的是传统测试给不了的强反馈：“数学上不可能违反”，这对让 AI 写出正确的软件是质的提升，她称之为“超能力”。 lauren @poteto pstack v0.15.27 ships with a new skill /create-formal-verification-skill! it's still in beta, and similar to /create-verification-skill, this is a meta-skill that creates a new skill and formal verification suite based on the characteristics you want to verify. for example, you may want to model state machines and systems with concurrency using TLA+, or use kani in rust to check for undefined behavior. if you're new to formal verification, think of it as mathematically proving properties and invariants (something that must always be true) or "laws" of your system. usually, this means modeling your programs in a separate language like with TLA+ and then running the solver on that spec. newer approaches like with kani and @bendlang take a different approach where there is no separate language: you write kani in rust, and bend in bend (it's also a programming language, and the proofs are written as laws and expressed in its type system). historically formal verification never reached mainstream status because of the difficulty in modeling and writing proofs. it's quite difficult to model your business requirements and keep them in sync! but i expect that we will see more innovation in formal verification in the future as being able to formally verifiy that the code does what you intended gives your agents superpowers in writing correct software. in the meantime though, i've been experimenting with modeling our code with TLA+ and have already found several bugs with the skill created by /create-formal-verification-skill. try it out and let me know how it goes! 🔗 View Quoted Tweet
it's crazy to see how universal the acclaim for YCSE is, despite the massive divergence in opinion in both interpretation as well as political affiliation. no one can agree on anything regarding any of the people/characters in the movie, but they all agree nathan fielder produced one of the best movies of 2026.