meng shao

Grok Bot 也学会请客送礼啦？ 😂 中国文化融入的这么自然吗？ 刚刚准备一些硬件概念，Grok Bot 突如其来的给我支招请前同事吃顿饭，着实惊到我了。。

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 这种主题实时切换、一个笔记里可能有几十张图的场景是精准的架构选择。

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.

The Pragmatic Engineer 作者 @GergelyOrosz 分享了一个对开发朋友们非常典型的困扰：老板被各种 AI 炸裂新闻洗脑，把 "AI token 用量" 设为 KPI ！而求助的这位工程师平时很少用 AI，因此被管理者反复敲打。他感到很大压力，认为自己被贴上了 "过时、低效、拒绝拥抱新技术的工程师" 的标签。 Gergely 的立场出人意料地站在了管理者一边： 1. 重新解读管理者动机：管理者不是在刁难你，是在"帮你"；他在用一种笨拙的方式推动你适应一场必然到来的行业变革。 2. 直白地认同那个标签：那位工程师抱怨被污名化，Gergely 的回答是"可惜这就是事实"。他做了一个关键区分：你可能是非常优秀的工程师，但"优秀"与"拒绝学习新事物"并不互斥。个人技术再精湛，拒绝适应仍然是不职业的表现。这里 "职业素养" 一词用得很重：在他看来，持续学习新工具本身就是职业素养的一部分，而非可选项。 3. 给出二选一的决策框架：对于在现状里"待舒服了"的工程师，只有两条路 · 上船：接受 AI 会深刻改变自己的工作方式，忍受快速变革带来的不适感； · 拒绝：这也可以，但要诚实地接受代价；愿意雇你的公司池子会持续缩小，你只能自雇，或干脆离开科技行业。

pstack 新增了一个 skill /create-formal-verification-skill 定位是 meta-skill：不直接帮你做形式化验证，而根据你想验证的系统特性，自动生成一个定制的验证 skill 和配套验证套件。比如你要验证状态机和并发行为的正确性，它会生成基于 TLA+ 的方案；要排查 Rust 代码的未定义行为，则生成基于 Kani 的方案。 Grok Bot 插件安装：x.ai/bot/plugin/9717366 背后的概念：形式化验证 测试只能证明 “bug 存在”，无法证明 “没有 bug”；形式化验证则是对系统的性质做数学证明：证明某个不变量 (即“必须永远为真”的性质或“定律”) 在所有可能的情况下都成立。 poteto 点出了两条技术路线的分别： · 传统路线(外置建模)：用一门独立的规范语言 (如 TLA+) 给系统建模，再运行求解器/模型检查器去穷举状态空间验证规范。代码和证明是两套东西。 · 新路线 (同语言证明)：Kani 直接写在 Rust 里，Bend 的证明以 laws 的形式表达在其类型系统中；没有单独的建模语言，证明和代码活在同一处。 形式化验证是个 “理论很美、实践从未进入主流” 的领域，poteto 指出了两个历史原因：建模本身很难 (把业务需求抽象成形式化模型是专业 skill)，以及规范与实现难以同步 (需求一变，两份东西都要改)。 她的判断是：这两个瓶颈恰好是 LLM 擅长接管的，让 agent 承担建模和同步的苦活。而反过来，形式化验证给 agent 提供的是传统测试给不了的强反馈：“数学上不可能违反”，这对让 AI 写出正确的软件是质的提升，她称之为“超能力”。

阿里通义 MAI-UI 团队开源了通用计算机使用智能体完整技术栈「OpenGCUA」：包括 harness、跨设备 SDK、原生 macOS 应用、评测轨迹和参考 agent 实现 开源地址：github.com/Tongyi-MAI/OpenGCUA # 从"GUI 智能体"到"通用计算机使用智能体" 传统 CUA (Computer Use Agent) 基本等价于"看截图、点按钮"的 GUI 智能体；OpenGCUA 定义的 GCUA (generalist computer-use agent) 是一个能综合调度整台计算机所有接口的智能体：无障碍树、应用 API、shell 命令、GUI 操作。论文将 GCUA 定义为"模型自主决定如何观察、行动并组织工作，跨越视觉与程序化接口的系统"。 具体机制上，GCUA 在每一步做三个由模型而非固定规则决定的决策： 1. 观察什么：按需调用 screenshot()，而不是每步强制截图。这一条很关键：它承认"截图"本身就是一种有成本的感知行为，该省则省（比如执行批量操作时中间过程不需要看）。 2. 如何行动：不是输出单个原子动作，而是写一段带循环和条件判断的 Python 程序，把 GUI 操作、API 调用、shell 命令编排起来。 3. 如何组织工作：模型自己维护 todo 列表，每步声明 intent，任务状态管理从 harness 硬编码逻辑转为模型自主行为。 这两大设计「代码执行（code execution）和 harness 到模型的决策转移（harness-to-model decision transfer）」是整个方法论的支柱。代码执行的巧妙之处在于复用了模型已有的强大编程能力，且循环内的中间结果直接决定下一步代码走向，无需每步都回到模型，这是效率提升的根源。理论上，纯 GUI 智能体、CLI 智能体、GUI+CLI 混合智能体（他们早期的 Qwen-UI-Agent）都成了 GCUA 框架的特例，这个统一视角本身就有理论价值。 # 实验结果：数字说明了什么 在 OSWorld-v2 上对 8 个前沿模型（GPT-6 Astra、Claude Opus 5、Gemini 3.8 Flash、GLM-5.3-Flash、Qwen3.8-Max/Flash、Kimi K3、DeepSeek-V4.1-Flash）的评测： · 平均 partial score 从 45.3 升至 64.9（+19.6 分），每任务步数平均减少 53%；GPT-6 Astra 从 102 步降到 34 步。 · 弱模型受益最大（GLM-5.3-Flash +35.2），强弱模型差距从 39.1 缩小到 18.0。这暗示：代码执行范式降低了"代理能力"对模型 GUI 精细操作能力的依赖，弱模型可以靠写程序弥补感知-点击精度不足；对开源生态是个重要信号。 · 代码执行比 GUI+CLI 混合再加 6.1 分、步数再降 14.8%，验证了"编排成程序"优于"交替调用工具"。 · 真机 macOS 测试揭示了一个基准测试掩盖的事实：同一 harness 下，Qwen3.8-Max 消耗的推理 token 是 GPT-6 Astra 的 19.4 倍，4 个任务只完成 3 个；真实设备上的效率差距远大于基准分数所反映的，这也是他们坚持做真机 harness 的动机。

Stripe 首席设计官 @lil_dill 分享：如何用 AI 规模化扩展意图、品质与艺术性 ？ Youtube 视频：youtube.com/watch?v=GLvFTMtw4Jk # 三个警戒信号 1. LLM 天然趋向均值。大模型擅长给出“最可能的答案”，即过去流行过什么、什么有效过，但不擅长给出属于你的品牌、你的用户语境的原创解。她展示了一个毫无个性的网站让全场猜不出是卖软件还是卖韩式烤肉，证实 AI 产出的默认就是这种“无性格”的东西。 2. “完成感”的诱惑。AI 让东西极快地显得“完工”了。她用微波炉冷冻卷饼自嘲：90 秒从饥饿到午餐，明知道难吃却因为速度而妥协。同理，敲一句话就得到一个有圆角、有阴影的界面，“看起来精致”不等于“真的解决问题、真的有差异化”。 3. 工作变得可抛弃。产出太容易，责任感和长期思维（谁来维护？）容易被丢在一边。 三者叠加的结果就是“僵尸 UI”：单调、空洞、无人真正在意。而我们一半的清醒时间都盯着屏幕，用户想要的是被认真对待的软件，哪怕小到日历标签页里显示正确日期这样的细节。 # Dill 给出的四条实战建议 一、必须有自己的观点 没有观点，AI 会替你给一个，而那个答案大概率是通用的、向后看的。在建造权分散、人人都给产品做贡献的时代，团队必须先对齐“我们是谁、用户在乎什么”。 她举了 Stripe 内部的一次设计评审。一位同事问：AI 做的东西，质量标准应该是什么？这个问题的答案很简单：用户不在乎东西怎么做的，只在乎它好不好，所以标准只看最终产出。那次评审最终产出了 17 条改进点，比如霜感再调一点、边缘再柔一点、气泡再小一点。"Pepsi bubbling" 从此在 Stripe 成为极致打磨的代动词。目标并非完美，而是比用户能感知到的再深一层，那份匠心用户终会感受到。 观点如何培养？练觉察力。留意用户真正的需要，而非嘴上说的；留意生活中什么是好、什么是平庸；从艺术与科学中汲取参照，逐步建立自己的品味和标准。 二、把标准编码进机器 现实是设计师不会出现在每一次决策现场。界面在没有设计师的房间里被生成，Agent 半夜自动修问题，生成式 UI 实时拼装。所以设计系统的对象已经变了：过去是界面，现在是系统本身。 她用古腾堡作比。古腾堡做了 290 个字符变体，包括不同字宽、连字和缩写，目的是让机器排版达到手工排版的品质，两端对齐时不出现难看的白空。旧设计系统扩展的是一致性，新系统要扩展的是意图。 Stripe 的实践也走过弯路。最初用 MCP 让 AI 读设计文档，效果很差，同一条 prompt 三个人会得到三个结果。后来迭代为构建在设计系统之上的 CLI：它在开发者工作的地方运行，在恰当时机注入文档以避免 context rot；提供的内容从原子组件升级为完整模板和流程，让系统知道产品应该是什么样子、如何组装。 但她同时引用了 Christopher Alexander 的话作为提醒：“一个系统可以满足所有规则，却仍然是死的。”这一条只是及格线。 三、拒绝把“做完”当“做好” 过去的质量过滤内建于流程：20 个想法只能立项 1 个，一路修剪打磨。现在一周能建 20 个想法，好处是可以跳过理论会议直接看真东西，但过滤被推迟到了建造之后，而那正是最难说“不”的时刻。 于是“编辑者”的角色变得空前重要。谁在端到端地审视产品是否为一个完整的整体？团队必须戒掉“建完就等于做完、做完就等于做好”的惯性。 编辑的核心方法是像用户一样亲身体验：它真的解决问题吗？符合用户的思维方式吗？放进完整用户旅程后还连贯吗？很多东西单独看都不错，拼在一起就显得割裂。编辑者要为每一个决定、每一个像素负责。 她引用 Nabil Khureshi 论艺术的文章：伟大的艺术在于意想不到的细节和贯穿始终的深层主题，这恰恰是 AI 的短板。AI 垃圾最冒犯人的地方，就是那种“细节无所谓”的感觉。杯子是绿的，但换成蓝的也无所谓，这种态度用户一眼就能看出来。 案例来自本场大会的开场动画。设计师 Stefan 用 AI 从 3D 场景模型开始迭代，第一版挺酷，但像素级审视总觉得不对劲。他反复做了 56 版，才得到真正有生命力的成品。她的关键洞察是：没有 AI，他可能根本不会尝试这么复杂的场景和这么多视角；AI 扩大了可能性空间，但一次成活是幻觉，把关的仍然是人的眼力。 四、释放创造力与艺术性 这是她个人最喜欢的一条。AI 可以批量制造单调，但它也是史上最强的创意催化剂。当人人都能建造，差异化更难也更重要。 今天的界面范式，聊天框、图表、命令行，绝非交互设计的终点。应该去发明新界面、新美学。最佳实践还没被写出来，而我们现在有了写它的工具，就像多点触控催生了全新的交互，合成器催生了全新的声音。 Stripe 用 AI 放大创意团队。新书《Built to Grow》的封面由人类大理石纹艺术家做出惊艳底稿，再用 AI 精调颜色与线条，本质上是把人类的好判断规模化。 让 AI 成为更强的创意伙伴有三个做法：改进输入，在 prompt 里带上品牌信念、审美标准和素材源，而不只是“给我做个烤肉店网站”；施压输出，别陷入卷饼困境，永远再推一步；用对抗性 Agent 帮忙挑刺。 真正的难点在文化。跟着 cookie-cutter 走安全舒适，找到独特且改进现状的东西难得多。领导者应该给团队留探索空间，保护那些怪东西（protect the strange）。AI 降低了创造的成本，省下的预算应该花在做出真正特别的东西上。如果只用 AI 把已有的事情做得更快，就错过了最有意思的部分。AI 能抬高地板，但天花板要靠人去撑。

斯坦福大学 CS336: Language Modeling from Scratch 第 10 讲「Inference」，在前后两讲 Scaling Laws 和 Scaling Laws II 之间，@percyliang 教授用一条完整的数学主线串起从架构、算法到系统的全部优化手段，把 “训练完的模型，如何又快又准地生成响应？” 讲得非常清楚！ Youtube 视频：youtu.be/EfM546A79aM?si=oao0lr6-Zna5IgUR 讲义：cs336.stanford.edu/ 讲义采用 CS336 特色的“可执行讲义”形式，所有公式都是符号计算（sympy）逐步推导并断言验证的。整讲的逻辑顺序是：自回归 → 无法沿序列并行 → 算术强度低 → memory-bound → 一切优化 = 减少每步搬运的字节数，围绕这个链路展开。 1. 架构层（有损）：GQA/MLA/CLA 降维、局部注意力截断、量化、剪枝蒸馏；全部服务于“把 KV cache 和参数压小，且用评测证明没伤准确率”； 2. 算法层（无损）：投机采样，用“验证快于生成”的不对称性换取精确的免费加速； 3. 系统层：连续批处理、分页、前缀共享、写时复制；操作系统经典思想向 GPU 服务的迁移； 4. 张力贯穿始终：延迟 vs 吞吐（批大小）、速度 vs 准确率（每一项有损技术）、新颖性 vs 可信度（GQA 与 MLA 论文结论的相互打脸）。 Percy 在结尾留下的展望是最本讲有分量的判断：KV cache 本身就是 Transformer 对推理不友好的结构性根源；一个从第一天起就为推理设计的架构（SSM、线性注意力、扩散式非自回归生成）可能是这一领域最大的改进空间。

昨天我老婆问我 App Store 怎么付费，看了一下才知道她要给儿子买一个打字 App，收费 128 块。。 这。。小孩和女人钱这么好赚？？ 我说等我半个小时，打开 Codex，把打字游戏的需求输入进去，一个 Goal 跑起来，20 分钟就做好部署到 ChatGPT Sites 了。花了几分钟看了一遍，还不错，顺手再加了一个实时拍摄人像，让头像作为游戏主角的功能，30 分钟准时交活儿。 效果怎么样呢？我第一版做了 36 关，儿子一连玩了 18 关 😁😁😁，我边看他玩，边看有什么问题，边让 Codex 改，顺便增加了几十关，和无限模式。。 以后儿子再有什么想玩但花钱的游戏和应用，自己做就行了，大家感兴趣可以看这: keyboard-island-doudou.groovy-river-7567.chatgpt.site

Google Research 最新开源了 Harness²：递归式智能体 Harness 优化框架 Harness² 解决的两个开放世界难题 1. 测试时遇到的是没见过的任务，没有 ground-truth 验证器。在线改 harness 时你不知道答案对不对，无法用“分数涨了没有”来指导编辑。 2. 递归自我改进（RSI）通常是任务特化的，换个任务就失效，无法泛化积累。 开源地址：github.com/google-research/harness2 # 核心机制：两层递归 第一层：任务级递归，Propose–Probe–Compose（对比式改进环） · Propose（提案）：先跑一次当前 harness 的参考执行。注意，这次执行揭示的是“harness 如何表现”，而不是“交付物是否正确”。基于任务、参考轨迹和历史，提出两个候选 harness：一个针对跨领域通用的代理性缺陷（规划、工具使用、上下文管理、委派），一个针对当前领域的知识、流程和约束。每个候选都是可直接执行的文件级编辑。 · Probe（探针）：两个候选在同一任务、同等的模型和环境条件下执行，与参考执行对比得到行为对比；编辑是否缓解了目标缺陷、毫无变化、还是造成回归。论文明确说这些对比只“为后续组合提供信息，而非验证任务正确性”。 · Compose（组合）：读取参考执行、两个候选、它们的 diff 和全部执行证据，有选择地构建后继 harness：合并被证据支持的修改、修订冲突、采纳其一、或保持原样。每个决策必须绑定一个具体观察，而不是假想的分数增益。 这一步是整个工作的关键创新：在没有标准答案的情况下，用“同任务下的 A/B 行为对比”替代分数反馈来指导编辑，绕开了开放世界没有验证器的死结。 第二层：harnessing 级递归，持续改进的 improvement harness 每个任务结束后，框架对完整的改进记录做反思，把被采纳的 harness 和有证据支持的教训写入一个按领域组织的持久库。要点有三： · 教训只有在执行对比支持时才保留——单次选出了好输出不等于可迁移； · 库里存的是可执行的组件文件而非散文式摘要，配一份 EXPERIENCE.md 记录适用场景和证据； · 下一个任务仍从公共基础 harness 出发（执行 harness 不继承），但 Propose/Probe/Compose 由更新后的库引导；即“改进 harness 本身”也在被改进，这就是标题里 Harness² 的双重含义。 两种扩展模式：parallel（同时探测 k 组候选，k 个独立组合会话）和 sequential（k 步链式精炼，逐步携带累积证据），两种模式从 k=1 到 5 均单调提升。 八个可编辑组件 - 按作用分组 · 上下文构建：系统提示词、护栏、记忆，每次调用都生效 · 工具接口：工具指引、Skills，Skills 按需加载不占成本 · 编排：subagents，唯一会增加推理上下文的组件 · 脚本：新确定性能力，执行而非推理 · 插件：TypeScript 中间件，“在工具环内强制一种行为，而非指令它” 主要结果（k=1 单步，编辑器为 Claude Opus 4.8） WorkBuddy-Bench · Gemini 3.5 Flash：+5.1 (OpenCode) · GLM-5：+11.5 (OpenCode，64.2→75.7) JobBench · Gemini 3.5 Flash：+4.5 (OpenCode) · GLM-5：+3.6 (OpenCode) LAB 部分通过率 · Gemini 3.5 Flash：+4.0 (Codex) · GLM-5：+11.8 (OpenCode，59.6→71.4) 更值得注意的发现： · 越弱的执行模型获益越大，且 GLM-5 换上改进后的 harness 反超了 Gemini 的基础分数，“换 harness”在某些场景下顶得上“换模型”； · 改进后的 harness 跨模型迁移（为 Gemini 精炼的 harness 给 GLM-5 在 Code 子集带来 +17.3），也胜过 Claude Code、Codex 的固定生产 harness 4.6–5.8 分； · 执行器和编辑器用同一个模型也能涨（GLM-5 自编辑在 LAB 上 +13.7），说明不依赖更强的“老师”模型； · 库的消融：去掉 library 在 WorkBuddy-Bench 上损失 3.1 分，验证了 harnessing 级递归的价值；库还能跨基准迁移（JobBench 的库迁移到 WorkBuddy-Bench 仍有 +0.6~+2.9）。

WorkBuddy 宣布: DeepSeek-V4.1-Flash-1017 在 10.31 前限时免费 不过，是「国际版」！ 国内版还没有限免活动。

怎么感觉国内 AI 团队们，有几个很久没发新模型了？ 本来以为是 AI 模型发布更新太快的时间错觉，查了一下，确实有几家超过 3 个月没发了。 字节：Doubao-Seed-2.1-Pro 6月23日发布，快 4 个月没发！ MiniMax：MiniMax-M3，6月2日发布，超 4 个月没发！ 月之暗面：Kimi-K3 6月13日发布，超 4 个月没发！ 百度：ERNIE 5.1 4月29日发布，快半年没发！

DeepSeek 叕发布了一个「小」版本：DeepSeek V4.1-Flash-1017，在性能、速度、输出长度三个维度同时改进，同时将内部搜索引擎以 Search & Fetch API 的形式正式商业化，并深度绑定自家及 WorkBuddy 等第三方 Agent 编程工具生态。 模型发布：一次“小步快跑”式迭代 V4.1-Flash-1017 是对既有 DeepSeek-V4.1-Flash 的增量更新，采用日期后缀命名，属于快速迭代节奏下的版本推进，而非架构换代。 公告强调的三个改进方向「更强的基准表现、更快的任务完成、更短的输出」，第三点尤其值得注意。模型输出冗长是当前推理模型普遍的成本痛点：同样的任务，输出 token 越少，延迟和费用越低。“性能更高 + 输出更短” 同时成立，才是其所说的“性能与成本的帕累托改进”的真正含义。 训练方法：RL with self-feedback 新模型使用“带自我反馈的强化学习”来提升端到端项目开发能力（从游戏开发到 3D 建模）。这意味着训练目标不再是对话轮次的质量，而是完整任务的最终结果：模型自己生成反馈信号来修正多步骤、长周期的工作流。这与其在 Terminal-Bench 4.0（42.3）、DeepSWE v1.1（77.0）等偏重真实工程环境的基准上的表现定位一致，模型卡的对比对象也集中在 K3、GLM-5.3、GPT-5.6 等同期的 Agent/编程向模型上。 工具生态：抢占 Agent Harness 入口 为 DeepSeek Harness（需升级至 v0.2.1-rc.1 或更高）、腾讯 CodeBuddy、WorkBuddy 等做了适配。DeepSeek API 也直接兼容 Claude Code 和 Codex 的服务端工具调用。 Search & Fetch API：搜索引擎基础设施商业化 商业层面最重要的一条，DeepSeek 把支撑自身产品的内部搜索引擎开放为两个独立 API： · Search API（/v1/tools/search）：返回结构化网页结果，支持 site:、lang:、after: 等检索算子，可附带页面正文。 · Fetch API（/v1/tools/fetch）：抓取单个网页并转为 Markdown，这是 RAG 和 Agent 工具链的标准需求。

手动点赞推荐 @samuel_ys92 👍 买卖简历和职位的生意该结束了 jobs.dinq.me/

女装电商场景对营销物料的需求，确实是一个非常典型的「SKU多、相似性高、数量大、更换频率高」 为什么特指女装，而不是服装。。各位男装用户，自己在电商平台啥地位，心里没数吗 😂，我心里的价值排序：女装、童装、宠物装、其他、。。。男装、中年男装。。 说回来，为什么电商场景的物料需求，不是直接接一个生图能力就能解决的？ 服装有同款不同颜色、同颜色不同款，作为购买用户，我希望能更直观做切换对比，这时不同颜色衣服出现在同一个模特身上，就不能是每一张都重新生成的，抽卡和幻觉，不可能 100% 解决。 对素材做分层，分出变量和不变量，服装和促销信息等，让每个图层尽量原子化、可复用，再做不同组合。这样不但保障一致性，对生成成本也会有很大帮助。 最近新发布的几个生图模型，都在往高度可控性走，相比已经被玩烂的天马行空、奇思妙想，可控性、可复用性才是生图应用真正能赚到钱的方向。

当 Claude 写了 Claude Code 约 90% 的代码后，团队如何重新设计代码评审 ？ Anthropic 没有取消代码评审，是把 “人读代码” 这个动作大部分交给了机器，把稀缺的人类注意力只花在真正需要判断力的地方。核心转变是：从“这段代码有人看过吗”变成“这个变更可能出什么问题，哪种检查（自动或人工）最适合抓住它”。 claude.dev/blog/solving-code-review-at-anthropic/ # 为什么必须改？ 背景数字：2026 年 6 月到 9 月，合并的 PR 数量翻倍以上，而 revert 率下降超 40%。传统的“同事互相读 diff”模式在这个吞吐量下会先崩溃；人要么变成瓶颈，要么敷衍放行。 团队对成本的认识很清醒：人力时间 = 评审时间 + 修复坏代码的时间，压缩一头只会把成本转移到另一头。所以他们不追踪“评审覆盖率”这种虚荣指标，而转去追踪 “每个 PR 平均几个人类审批” 和 “等人审批的等待时间”，并以 revert 率 / 事故率作为护栏指标；目标是最多一个人在环（有时只有作者本人），且事故不比以前多。 # 七层防线：一个变更的一生 1. PR 之前的自我验证 — Claude 必须出示证据（测试输出、构建、截图）而不是声称完成；再用一个全新上下文的第二个 agent 审 diff。Boris Cherny（Claude Code 创造者）认为给 Claude 一个验证方法是“最重要的事”，效果提升 2–3 倍。反复出现的问题会被固化到源头：写进 CLAUDE.md（项目约定）和 REVIEW.md（给代码主人看的指引——失败长什么样、nit 上限、哪些路径跳过，且每条发现必须附文件/行号证据）。 2. 每个 PR 必过 AI 评审 — 内部 PR 上“实质性评审意见”占比从 16% 升到 54%；千行以上的大 PR 几乎总能查出问题。多个 agent 并行找 bug，再有 verifier agent 对每条发现投票才发出。发现分为 Important / Nit / Pre-existing，每条必须解决或说明理由。 3. 阻塞性的安全评审 — 独立的自动化通道，有未处理发现就不能合并。 4. 阻塞性的自动检查 — lint、类型、跨平台测试、构建；PR 模板强制填写“如何测试的”和“如何回滚”，且需一人签字。 5. 基于风险的人工审批 — 分类器定级：低风险（文档、文案）不需人工；中风险（普通产品变更，及缓存、自动更新器、系统提示词等敏感区）一人；高风险两人。关键规则：agent 的批准永远不能算人工批准；批准只覆盖一个 commit，有新提交就要重新审批。 6. 合并队列 + 特性开关 + 灰度 — 针对合并后 main 重跑检查；新行为先给 Anthropic 内部员工，再走 latest channel，最后进 stable。 7. 快速检测与回滚 — 开关无需重新部署即可关闭；事故复盘必问“哪一层本该拦住它”。 # 两个最有参考价值的工程细节 1. 评审器本身也是被持续评测的系统。 过去引发事故的 PR（经专家确认）构成一个 eval 集，评审器每天跑分，只有分数提升的改动才被保留；噪声则通过“人对评论的反应”和“在已知干净的 PR 上跑评审器”来度量。这本质上是把“评审质量”从主观感受变成了可优化的目标函数。 2. 收敛问题的解法。 曾有一个 agent 写的 CLI PR 一夜跑了 50+ 轮评审，而 git blame 显示约 59% 被标记的代码在第一轮之前就存在；评审 agent 在翻旧账而不是审新变更。修复手段：三轮封顶（超过就退回来重新考虑方案）、后续轮次只看增量 diff、标记 bug 类别而非单行、禁止重复发现。效果：一轮通过率 65%→78%，5 轮以上 PR 从 8.9% 降到 1.5%，平均评审轮次 2.08→1.32。这是 AI 评审 AI 代码时特有的“死循环”问题，他们的解法值得所有引入 AI reviewer 的团队抄作业。 # 人类还留在哪里？ · 该不该做：方向、品味、范围； · 高危代码：计费、自动更新器、CI 工作流； · 可被复制模仿的架构决策； · 读证据：测试输出、截图、发现列表； · 为结果负责：每个上线变更背后必须有一个承担问责的人。

怎么才能更信任你的 Agent 的工作呢？ Grok Bot 团队 @poteto 提出了一套如何信任 AI Agent 工作成果的四层“倒金字塔”框架。她认为，与其花精力“管教” Agent，不如花精力改造代码库本身！ # 四层倒金字塔 (精力投入从上到下递减) 第一层：代码库改进 (投入最多) 更好的架构、更强的类型系统与不变量、清晰的模块边界。 Lauren 认为这本质上“就是好的软件工程”。理由在于 Agent 的天性：Agent 倾向于复制已有代码、走最短路径；所以与其对抗这个天性，不如让最短路径本身就是正确路径。 第二层：静态分析 Lint 规则、测试、CI、形式化验证(如 TLA+)。这是性价比很高的第二道防线，用极低的 token 成本在问题早期就拦截它，出错反馈是确定性的，不依赖 Agent “理解”了什么。 第三层：文字性指导 (最少使用) 代码注释、规则文件 (如 AGENTS.md)、Skills 描述等。这一层的共同弱点是无法强制执行，它要求 Agent 自行判断是否遵守，而 Agent 的判断并不总是可靠，所以只能作为补充，用在确实需要主观判断的场合。 第四层：人工审查 (最难规模化) 人的精力有限，不应消耗在逐行检查 Agent 产出上，而应投向更上游的事：设计出让 Agent 默认就做对的环境。 为什么金字塔是“倒置”的？ 传统上团队把大量精力放在金字塔底部 (写规范、人工审查)，而 Lauren 主张反转： · 越往上层，手段越是确定性的 (代码结构直接决定 Agent 能走什么捷径) 且token 高效的(不需要反复沟通纠偏)； · 越往下层，越依赖不可靠的理解与不可扩展的人力。 这和业界近年 “从 prompt engineering 转向 context/engineering 工程” 的共识是同一方向；但 Lauren 把它推到了更根本的层面：连提示词本身都只是第三等手段，真正的杠杆在代码库里。

Perplexity 开源了团队内部 agent 代码执行平台「SPACE」，把不可信的 Agent 生成代码或用户代码放进 Firecracker microVM 里隔离运行，通过纯 HTTP/SSE API 对外服务 开源地址：github.com/perplexityai/SPACE 核心抽象：五个概念 + 严格分离的生命周期 · Template：起始文件系统与运行时配置（不可变，类似镜像），按内容寻址（sha256: digest） · Sandbox：一个 Template 的实例，独立 microVM + 可写文件系统 · Process：在 Sandbox 内执行的程序，同 Sandbox 内进程共享环境 · Command session：一次命令的连接信息与授权，创建即分配进程 ID，attach 才真正启动 · Operation：异步生命周期请求（create/pause/suspend/wake/delete）的追踪记录 关键设计：Sandbox 的生命周期长于创建它的请求，也长于承载其输出的连接。管理面是异步的，API 只把期望状态写入 PostgreSQL，由控制器和 worker 协调收敛，客户端拿 operation ID 轮询；数据面则完全独立，通过会话级 attachment token 经 SSE 直连沙箱内进程取输出。管理 token 与 attachment token 不可互换，这是它的安全边界之一。 架构：控制面/数据面分离 + 声明式调和 请求与执行分两条路径： · 管理面：Application → API → PostgreSQL（期望状态）→ 集群控制器 → 沙箱 Pod（K8s 模式下）→ 运行时 shim → Worker 服务 → Firecracker microVM → 客户进程。 · 数据面：Application ↔ Data plane ↔ 客户进程，旁路整个控制面，输出流不经过数据库。 Worker 负责 VM、网络、卷、模板、凭证，用 btrfs 写时复制构建根文件系统（这是快速克隆沙箱的关键）；模板与快照走对象存储（本地用 Versity S3 Gateway）。部署形态可插拔：Kubernetes 适配器（本地 Kind、云端 EKS 参考部署）或直接适配器（不经 K8s 直调 worker，支持单机运行）。 Pause 与 Suspend 的区分体现其状态机的严谨性：Pause 保留常驻内存（快恢复但非持久）；Suspend 生成 VM 内存 + 运行时状态 + 根文件系统的完整快照并释放资源（真正的持久化），两者都用 Wake 恢复。默认 6 小时无活动自动 Suspend（这是空闲限制而非最长存活时间）。 性能工程：两层抗冷启动 冷启动是 microVM 沙箱平台的体验瓶颈，SPACE 给了两个正交方案： 1. Warm pools（K8s 部署）：按“模板版本 × VM 规格”预启动一批就绪沙箱，create 直接领用，池空了才退化为冷启动； 2. Base snapshots（单机部署）：从基线快照恢复，跳过完整引导。 配合 Firecracker 本身亚秒级的 VM 启动和 btrfs CoW 文件系统克隆，整体面向“Agent 秒级拿到可用环境”的目标。 “可插拔运行时”：为未来预留的执行环境身份体系 这是仓库描述里 "pluggable-runtime" 的实质，也是设计上最有前瞻性的部分。每个执行环境被定义为主机平台 × 运行时绑定 × 客户平台 × 引导配置 × 隔离语义 × 兼容性Profile 的完整组合，整体 SHA-256 内容寻址。当前只实现了编译进代码的 E0 定义：Linux/x86_64 宿主、KVM、Firecracker 1.15.1（含 jailer）、内核 6.1.155、快照格式 9.0.0。 值得注意的三个原则： · 结构可解码 ≠ 可执行：解码成功、工件存在、节点健康，都不构成执行授权，三者分离校验； · 身份不可扩展含糊：任何改变引导/恢复语义的字段都必须产生新的 schema/引用，“加了字段还沿用旧引用”被明令禁止； · 主机平台类型里已预留 Linux/Windows/macOS 的区分身份，虽然当前只实现了 Linux 适配器。 这明显是在为未来支持其他 hypervisor、客户架构甚至非 Firecracker 运行时铺路，而不是把 Firecracker 硬编码进协议。 安全模型（分层清晰） · 硬件级隔离：Firecracker microVM 边界（KVM），这是对不可信代码的根本防线； · token 分域：管理面 bearer token 与数据面 attachment token 隔离； · 网络策略：沙箱 Pod 独立 namespace（sandboxes），NetworkPolicy 只放行 API 与控制器端口，出站默认限公网 IPv4 + 集群 DNS，可配 egress profile 精细管控，甚至有 TLS 拦截豁免机制； · 供应链：gitleaks、cargo-deny、supply-chain 目录、pre-commit/lefthook 一应俱全； · 内部 RPC 走 TLS，模板注册可限制可信 S3 bucket 白名单。 兼容性与工程成熟度 · E2B 兼容层（ECW）：在边缘翻译 E2B API 请求/响应，用 E2B Python SDK 的应用可近乎无缝迁移（语义映射：E2B 的 pause → SPACE suspend）； · 客户端零绑定：纯 HTTP + SSE，OpenAPI 规范直接服务在 /openapi-m1.json，不需要嵌入 Rust 库——这对采用率至关重要； · 运维面齐全：space-admin-cli（节点、暖池、模板构建）、Web UI、OpenTelemetry 可观测性、mdBook 文档； · 开发体验：tilt up 热重建，单测 + Kind 冒烟套件。

腾讯混元团队开源了「Hy Memory 2.0」，包括一个专用的记忆写入模型 Hy-Memory-30B-A3B、一个可编程的记忆框架 hy-memory SDK、一个面向终端用户的桌面工具 MemHub，组成了一套完整的 “记忆基础设施” 相较于在通用大模型（如 Claude Opus）外面套一个记忆框架（如 Mem0、MemOS）的主流做法，Hy Memory 2.0 的做法是：用一个小的专用模型替代通用大模型做记忆写入，既便宜又能跨框架工作。 # Hy Memory 2.0 的三个组成部分 模型：Hy-Memory-30B-A3B。30B 总参数、仅约 3B 激活的 MoE 架构（意味着推理成本接近一个 3B 模型）。训练分两步：先用 “On-Policy Distillation” 让学生模型在自己生成的记忆状态上学习各框架的写入协议，而不是简单模仿教师输出；再用“归因记忆强化学习”直接优化下游效果，用逐块探针定位贡献、跨上下文窗口携带自己写入的记忆库，保证训练与真实部署场景一致。 框架：hy-memory SDK。这是工程上最有含金量的部分。它按三类场景设计了不同的记忆形态： · Chat 记忆采用 L1–L7 层级结构（原始对话 → 原子事实 → 会话摘要 → 心理模型 → 前瞻意图），分 lite / pro / ultra 三档，最低档零 LLM 调用、纯向量检索； · Working 记忆区分“会话事实”和“可复用经验”两层，经验写入需通过价值阈值，避免记忆库膨胀； · Coding 记忆只记录代码坐标（文件/函数/分支）而不粘贴代码本体，并以“装饰器”方式在事实下挂载每次修订的真实 diff，形成版本演化链，这个设计对代码场景的噪音控制很有效。 存储后端可插拔（ChromaDB/Qdrant/FAISS + Kuzu/Neo4j + SQLite），任何 OpenAI 兼容端点即可跑起来，pip install hy-memory 即用。 MemHub：本地优先的 CLI + Mac 桌面应用，把 Claude Code、Cursor、Codex、Qwen Code 等工具的会话历史统一到一个记忆运行时，实现“在 Cursor 里学到的偏好，Claude Code 也能用”。这是面向个人用户最直观的入口。 基准成绩实际怎么样？ 在四个 harness（Mem0、Hy-Mem、MemOS、以及未参与训练的 EverMemOS）宏平均六个指标上，该模型以 55.49 排第一，Claude Opus 5 为 54.62；领先不到 1 分，且数据来自官方技术报告（基于固定的 20% 基准子样本），属自报成绩，尚待独立复现； 真正有说服力的是两点：一是在从未见过的 held-out 框架 EverMemOS 上仍领先（56.89 vs 54.04），证明其泛化能力而非过拟合特定协议；二是相比同架构基座 Qwen3-30B-A3B（44.37）提升约 11 分，说明训练方法本身有效； 用约 3B 激活参数的模型逼近甚至超过旗舰通用模型，性价比才是核心卖点；记忆写入是高频调用，成本差异会被放大。 SDK & MemHub: github.com/Tencent-Hunyuan/Hy-Memory Model: huggingface.co/tencent/Hy-Memory-30B-A3B

pstack 作者公开她的 “工程原则” 设计思路 「Clean Code」作者 Uncle Bob 是传统软件工程方法论的宗师，他最近看到了 pstack，认为本质上是把经典工程智慧「最小改动、先删后加、验证根因、用类型系统让非法状态不可表示、幂等操作」重新编码给 AI Agent 使用。 pstack 作者 @poteto 回应并公开了这个 Cursor 官方内置插件的工程原则的设计思路，核心是：随着模型能力提升，写给智能体的指令正在从“冗长的操作步骤”压缩为“简短的命名原则”。 # 几个关键信息点 1. 原则即极简 skill。pstack 的每条工程原则只有约 10–20 行，是一段被提炼、命名过的好实践，而不是一个流程脚本。她预期随着模型变强，pstack 里大部分 skill 最终都会被压缩成这样的短原则或工作流，从而可以删掉一批。 2. /poteto-mode 的运行机制。智能体在开始多步任务前先读一份简短的原则索引；执行过程中，必须“点名每一条影响了决策的原则，以及它具体改变了哪个选择”，并在回复末尾生成一个 "Principles Named or Used" 段落。这个设计很巧妙：如果原则被引用却没有对应的实际决策，就说明智能体只是在“报菜名”而没有真正应用；强制原则与决策挂钩，让推理过程可检验。 3. 原则来自真实纠错。这些原则大多来自她今年在会话中亲自纠正智能体的场景，属于“教训的结构化沉淀”。 4. 原则可被唤起。每条原则都能以 /principle-<名称> 的形式作为 skill 调用；更常用法是用名字来“掌舵”；因为名字背后指向智能体已经读过的完整规则，一个短语比一段指令更能精准地重定向工作。比如对着一堆旧适配器说 "subtract before you add"，智能体就知道先删过时的、再设计剩下的。