推文

Claude Code 的一个有趣用法：解读 Linear A——克里特岛上一种有 3500 年历史的古文字。 希望能通过同行评审！🤞

原来如果你做了大量优质的 context engineering，可以用 frontier 级别的智能只花一半的价钱，某些情况下甚至比单一 frontier model 表现更好 > 引用 @tomgreenwald：推出 Magnitude。 > > 这是一个完全基于 open models 运行的 coding agent。 > > 比 Claude Code 便宜 60%，性能毫不逊色。 > > 立即体验：npm i -g @magnitudedev/cli

关注下「loop engineering」这个趋势，这篇文章写得很好。 [引用 @omarsar0]: 从 Prompting Agents 到 Loop Engineering

用 /decision-mapping session 生成了一份超详细的 PRD。 很喜欢这个新工作流。

今天发布了 Flashtype，一款面向 Claude 和 Codex 的 Markdown 编辑器。 用 Claude/Codex 编辑 Markdown，追踪每一次改动，查看 diff。 开源，现已可用。

大概一个多月前，我的电脑中了木马，潜伏了一个月才被发现，也导致了我的 X 账号被盗。 用 Claude 和 Codex 逐一分析系统进程时，发现了一个叫 com.apple.accountsd.helper.plist 的进程，乍一看以为是苹果系统进程，但 Claude 对其提出了质疑。 顺着这条线索深入分析：木马先添加开机自启项长期潜伏，再用 root 权限写守护脚本，每秒探测是否有新用户登录，一旦登录就通过 AppleScript 切换为当前用户身份，运行一个叫 AccountsHelper 的程序。 对 AccountsHelper 做二进制分析，发现它依赖极少，主要职责是从远端加载指令，然后拉起一个交互式 PTY shell，攻击者就是通过这个 shell 远程操控电脑的。木马的每个环节清理工作都做得极好，几乎所有日志都被清除。 为溯源整个入侵过程，我分析了近两个多月的系统日志，只找到一条可疑指令：一个 curl 操作，下载并执行了一段混淆命令，这是唯一线索，解密后得到一个远端 IP 地址。 从公开情报中找到了这个木马，它是 AMOS Stealer 恶意软件家族的变种，之前主要针对 Windows，今年四月首次在 macOS 上被发现。 从 .zhistory 日志看，curl 前后都是 Claude Code 相关操作，高度怀疑是 agent 程序引入了这个木马。 我的 Claude Code 长期处于 bypass 模式，所有命令直接放行，怀疑是在安装或更新软件时，AI 从互联网找到了不安全的资源并下载了木马。 AMOS 木马主要扫描各类虚拟货币钱包（尤其是浏览器插件钱包），同时也把我的各种登录 Cookie 全部窃取，这才导致 X 账号被恶意添加了 Passkey。 木马入侵后，除了针对性攻击（如虚拟钱包转账、文件加密勒索）外，还会大肆搜集敏感信息：浏览器登录态、Keychain 账号密码、聊天工具登录状态、开发环境的 .env 文件和各类 token 等。 两个教训：1）所有能开 2FA 的账号都要开，登录时的二次验证能有效提高攻击门槛；2）AI 执行各种程序时务必注意它在做什么，尤其是安装和更新软件时，要先确认再执行。 和安全研究者交流后得知，近期此类事件极高频——攻击者会伪造各类软件官网，Google 搜出来默认排在第一位，专门诱导用户（尤其是 AI）下载木马，防不胜防！

// 自动化生成 SKILL.md // 越来越多人发现，挖掘历史 session 是改进 agent 的最佳途径之一。 OpenAI r…

昨天发布了 mattpocock/skills v1，包含： - /ask-matt：在 agent 内直接问我如何最好地使用这些 skills - Model-invoked 与 User-invoked skills 的区分 - /writing-great-skills：编码了我的 skill 编写最佳实践 欢迎使用。

用我们新的 /youtube-notetaker skill 从 YouTube 视频生成 Artifacts。 [引用 @omarsar0]: YT 视频 -> Artifacts 看我如何用新的 /youtube-notetaker skill 从 YT 视频生成 artifacts。可以提取幻灯片、笔记、字幕... 快去试试 ↓

正在跑 GLM 5.2 的朋友们，你们是怎么做的？ 用的什么 harness/provider？ 这是我第一次对一个开源权重模型产生 FOMO

Vibe coding 现状：功能开发 7 分钟，古法手工打磨 UI 和动效 7 小时🤪

听朋友说这几篇文章成了 AI 岗位面试备考必读，汇总一下，希望对大家有帮助，也祝正在从传统工程师转型 AI 岗位的朋友顺利找到满意的工作。 1. 你不知道的 Claude Code：架构、治理与工程实践 2. 你不知道的 Agent：原理、架构与工程实践 3. 你不知道的大模型训练：原理、路径与新实践 4. 你不知道的 AI Coding：非技术人的上手、场景与实战 5. 你不知道的 GEO：AI 可见性的原理、实践与取舍 6. 你不知道的具身智能：从小机器狗到 Optimus

herdr 挺不错，但我一直想要一个以 session 为核心来管理的工具。最近发现了 agent-deck，用了用感觉不错。 以 session 为管理核心，支持 session resume/fork 等功能，体验很好。

非常期待 @GroqInc 或 @cerebras 这类超快定制硅推理服务商能跑起 GLM 5.2。 Cerebras 已有 GLM-4.7，Groq 目前主要还是 Llama 3.x 和 gpt-oss。 【引用 @jeremyphoward】： 哇。 GLM 5.2 简直是奇迹！它**至少**和 Opus 4.8、GPT 5.5 一样强。速度超快、价格低廉、回复不啰嗦。 它的回答有细微判断力，长上下文处理也非常出色。 我从没见过这样的开源权重模型。

如果你正在做一个涉及 web app 的十亿美元公司，这里是我关于前端架构的笔记。 不做这些大概率也没事，但迟早会雇人来修——而那个人本可以做更有价值的事，如果你在第 1 天就做对几个关键决策的话。 而且你甚至不用自己学，直接让 agent 来做就行！ 好，开始： - **让 server 代码生成 OpenAPI spec，再从 spec 生成所有客户端代码。永远不要手动写。**手敲 backend 类型而不是生成，应该被禁止。 - 你需要决定客户端如何与 backend 通信。REST/GraphQL 都行，这种情况下请用 TanStack Query。其他库看起来类似，但 TanStack Query 真的是神。 - 如果想要 Linear 那种实时同步或离线模式，**从第 1 天就认真想清楚并把架构定好**。事后加上去极其痛苦。 - 很多人喜欢用纯 React Router，但现在已经进化很多了。试试它的 framework 模式，或者直接用 TanStack Router。用 route data loaders。 - 如果大量状态存在 query params 里，把它做成一等公民并确保类型安全。用 nuqs 或 TanStack Query。 - 大多数 app 只需要一套管理 server state 的状态管理方案就够了。如果有其他特殊需求，我比较喜欢 zustand 和 xstate/store。 - 如果你的 app 高度交互、内容频繁进出视图、还在放音乐之类的，**认真学 xstate**。如果想保住理智，你需要把前端建模成状态机，否则你会深陷 useEffect 地狱。 - React compiler 来了，useMemo 和 useCallback 的时代结束了。更新你的认知。 - Tailwind 简单好玩，但在大型 app 里很难维持一致的样式。你需要一个「agent-first 设计系统/组件库」，但这是另一个话题了。 - 不要怕魔改你的路由库来更贴合你的需求。很多 app 有 drawer 来展示额外信息。你应该能说「这是一个 route，把它做成 drawer」，剩下的全自动处理。 - 用 isPending 和 isError 管理 loading 和 error 状态是一种折磨。多用 Suspense 和 ErrorBoundary。 - 如果你在做 AI 相关的东西，第 1 天就定好 WebSocket 和 SSE 的标准方案，长期来看绝对值得。 - **如果你在做 SPA，别用 Next.js**，真的毫无意义。 - 部署在 Cloudflare 或 Vercel。其他服务总有奇怪的功能缺失。 - 假设你做出了人们想要的东西，下一个任务是**把工厂建好，让它能高效地持续生产**。按这个逻辑行动。

新版 Claude Code (v2.1.181) 有个小而实用的 DX 改进： 现在可以用 /config key=value 内联设置任意 session 参数，不用再打开菜单： /config useAutoModeDuringPlan=false 在 interactive、-p 和 Remote Control 模式下都有效。 希望 /model、/effort、/color 甚至 skill 参数也能用同样的模式 👀

刚发布了 Datasette Apps——一个 Datasette 插件，可以在 iframe 沙箱中托管完整的 HTML+JS 应用，这些应用能查询你的数据库并对数据做各种有意思的处理。

自动化重复性工作从未如此简单——只需在 Cursor 中运行 /automate [引用 @cursor_ai]：推出 /automate，一个让 agent 帮你配置自动化的 skill。用自然语言描述你的任务，Cursor 自动配置触发器、指令和工具。

我最近最喜欢的 agent loop 之一，来自 Peter Steinberger： 「重构直到你对架构满意为止。每完成一个关键步骤后，对系统做实时测试、跑 autoreview、然后提交。在 /tmp/refactor-{projectname}.md 里追踪进度。」

让 Codex 用它内置的浏览器自己处理所有 Google Cloud 设置，实在太爽了 https://t.co/goLAn1aIo2

Claude 社区页面新上线：分享你用 Claude 构建的作品并获得推荐展示，还可了解即将举办的活动、大使计划等。

最近最喜欢的 stack：GitHub Actions + Sandcastle + Claude Code 给 issue 打上标签，自动获得实现。 也支持多步骤 PRD，这是一个正在运行的示例：

我一直在 Claude Code 中把 Artifacts 用于所有事情：难懂代码的可视化解释、系统架构图、几种动画方案的快速预览、与团队共享的数据分析看板。它彻底改变了我与 Claude 的协作方式。迫不及待想听大家的使用感受！ 【引用】Claude Code 新功能：Artifacts。 从你的会话中生成交互式页面，比如 PR 演示或实时项目看板，通过私密链接与团队共享。 Team 和 Enterprise 计划现已开放 Beta 测试。

OpenAI Codex 上线了 Record & Replay 功能：在 Mac 上把一个重复性操作演示一遍，Codex 会观察你的操作过程，自动生成一个可复用的 Skill。下次遇到同样的任务，换一组输入参数，Codex 就能替你重新执行。 目前仅限 macOS，欧盟暂不可用，需先开启 Computer Use。 这个功能解决的问题很具体。很多日常工作流程步骤固定但难以用文字描述清楚：报销填单要选对科目和审批人，发视频要按固定顺序填标题/标签/缩略图，创建 issue 要勾选特定标签和指派人。以前想让 AI 做这些，你得把每一步写成精确指令。Record & Replay 的思路是——与其写说明书，不如做一遍给它看。 操作流程不复杂：在 Codex 桌面端打开 Plugins，点加号菜单，选 Record a skill，然后正常在 Mac 上完成一遍操作。完成后停止录制，Codex 会分析操作，生成一份 Skill 文件，包含触发条件、所需输入、执行步骤和验证方式。这份 Skill 可以检查、可以编辑，不是黑盒。 重放时开一个新对话，告诉 Codex 用这个 Skill，给它不同的参数就行。Codex 会结合 Computer Use（桌面操控）、浏览器操作和已连接的 plugin 来完成任务。

Matt Pocock 刚刚解释了为什么大家都在关注错误的东西—— 不是模型，是 harness（编排层）

Claude Code 现在可以上传和编辑 HTML artifacts，可以分享给团队或其他 Claude！ 先向 Teams 计划开放，Pro 和 MAX 计划即将跟进。 （引用 @claudeai）Claude Code 新功能：Artifacts。 从你的会话直接生成交互页面——比如 PR 解读或实时项目看板，通过私有链接分享给团队。 现已在 Team 和 Enterprise 计划 Beta 上线。

最近大家都在聊 loop，但大多数 loop 方案都烂透了。 分享一个我们实际在用的： Agent 写 React 代码很烂。@aidenybai 的 react-doctor 是我们对付这个问题的最爱。 你可以跑一次、用 ralph loop 把所有问题修光——但我不会去 review 一个 +80k/-80k 的 PR（@dexhorthy 也不会）。 但我每天早上到办公室后能读一个小 PR。 我们的做法是： 每天早上 7 点在 CI 里跑 react-doctor（顺带说，GitHub Actions 是个绝佳沙盒） Agent 挑出前 5 个问题，修完，开一个 PR 其他 CI job 在每个 PR 上检查回归 没办法一次把所有问题修完，但可以做到两件事：不让它变得更坏，以及每天 1% 的改进。

揭晓我 agentic engineering 工作台的下一件重器——Firstmate！ 这是我现在唯一直接对话的 agent session。如果你觉得同时管理多个 agent session 很耗费心力，这就是解法。 一如既往免费开源——详情见下 👇

我很想看到针对复杂 agent 的优秀 eval 设置案例。 大家都知道，断言「输入 prompt → 输出 prompt」根本没在测任何东西，但我很好奇大家实际上是怎么检验行为的。 比如：agent 有没有发出这个 tool call？有没有命中这个网络端点？有没有写入这个数据存储？ 其中有些是确定性的，但有些源自 loop 内部的真实行为。

如何用 Claude Code 搭建一个你一个人就能运营的 GTM 团队

我草。用 GLM-5.2（左）和 Opus 4.8（右）各做一个登录页面，效果请自行对比。另外 token 成本：GLM 0.06 美元，Opus 0.49 美元。

关于 LLM agent 技能路由的新论文。真实任务很少能映射到单一技能，往往需要多个技能组合——但如何优雅地路由和组合，是个难题。

做 web agent 的值得看这篇。 讲的是如何让 agent skill 可复用。 （收藏） LLM web agent 通常作为 tool caller 运行。每轮模型读取新页面并执行一个低层动作，导致在 Mind2Web、WebArena 等 benchmark 上 horizon 和策略侧 LLM 补全双双崩溃。 Skill library 本来是为了解决这个问题——把重复片段封装成可调用工具。但传统方案按指令相似度或站点元数据来触发复用，在 held-out 站点上几乎不生效。 这项工作改用「可迁移交互模式」来路由 skill 复用，让在某个站点学到的 skill 能在具有相同交互形态的新站点上触发。这在基于域名的检索失效的场景下显著提升了复用率。 为什么重要？ 搜索、筛选、翻页这套流程在各个网站上反复出现。把它抽象成模式键控的 skill，就能让 web agent skill 泛化到训练站点之外。

谁应该设计 RL agent 的训练环境——从业者，还是 policy 本身？ LLM 的 RL pipeline 通常……

在玩一个「决策地图」的想法： 1. 通过简短的追问环节找出决策的「边界层」 2. 展开多个并行的追问/原型/研究 session，逐步驱散迷雾 实录：同时对一个大项目的三个方面展开追问：

简单说就是： Skill 必须能引用其他 skill，且不产生额外的 token 开销。 【引用原文】 Skills spec 里我碰到了一个让人抓狂的 gap。 TL;DR：我想要三种「可调用」层级——用户可调用、skill 可调用、model 可调用。Skill 可调用的 skill 只能被用户或其他 skill 触发。 Skill 可以标记为 model-invocable 或 user-invocable。Model-invocable 的 description 会注入 context；user-invocable 对 model 不可见，不消耗 token。 但问题来了：如果一个 skill 既想独立使用（user-invocable），又想作为其他 skill 的子步骤，该怎么办？ 比如 /review skill： 1. 跑自动化检查 2. 对照原始 spec 审查代码 3. 对照编码规范审查 如果把第 1 步拆成独立的 /run-automated-checks，你就必须把它设为 model-invocable——description 就进了 context。 这是无意义的 token 浪费。你不能省略 description（违反 spec），又只能写一句「除非在其他 skill 里调用，否则永远不要触发」。 有人在做 skills spec 吗？这个问题考虑过吗？

我今天用 codex 改了一个前 AI 时代的老项目。令我惊讶的是，现在已经不需要预先初始化 AGENTS.md 或 CLAUDE.md 了。Context Engineering 本身已经被模型内化了。

Codex 接入开源模型完整配置指南

Claude Design 新功能：跨项目保持设计系统品牌一致性，支持直接在 canvas 上编辑，并可同步……

谁应该设计 RL agent 的训练环境——实践者还是策略本身？ LLM 的 RL pipeline 通常依赖实践者在各阶段之间手动重新设计环境，靠猜测哪种配置能最好地改善当前策略。 这项工作提出了 LLM-as-Environment-Engineer 框架。当前策略分析自身的失败轨迹及上下文，并提出下一阶段的环境配置，将这个长期依赖人工的步骤自动化。他们还发布了 MAPF-FrozenLake，一个可控的多 agent 测试床，其生成器支持多维度环境配置。 为何重要？ RL 阶段间的课程设计如今主要靠直觉。让策略读取自身失败并塑造下一个环境，补上了实践者当前手动完成的这个闭环。

在你形成自己的品味和声音之前，不要用 AI 写作。 用 AI 写作本身没有错。危险在于，你还没建立起对「好内容」的判断力就开始用 AI 写。如果 AI 产出的是烂货，你甚至认不出来它是烂货。 多读，弄清什么是好的。多写，认清自己的声音是什么。只有在那之后，才用 AI 辅助写作——并确保输出读起来真的像你。

所以我让 Codex 跑了一个 /goal 任务，已经跑了 2 小时，但问题是它做了很多错误假设，我必须一直盯着它、不断纠偏。 这正常吗？也许我应该先让它做一个详细的计划？

Claude Code 与 Claude Design 现已实现双向同步。 运行 /design-sync 可将你的设计系统拉取到仓库，直接基于真实组件进行开发；或将你已构建的内容推送回 Claude Design，继续在画布上编辑。 [引用 @claudeai]: Claude Design 新功能：跨项目保持品牌一致性、支持直接在画布上编辑、与 Claude Code 同步，并接入更多你已在用的工具。

关于计算机操控 agent 的优秀论文。（值得收藏） 计算机操控 agent 通过屏幕驱动真实软件，但每次任务都从头解决。让它重复同一个任务，它会重新读屏幕、重新推理每一次点击，全部成本再付一遍。 PreAct 将首次成功运行编译成一个小型状态机程序——状态负责检查屏幕，转换负责执行动作——并在后续运行中直接回放。速度提升 8.5 到 13 倍，无需每步调用语言模型。 回放有保护机制。每一步，PreAct 都会验证屏幕是否与程序预期匹配再执行动作；若现实偏离，则将控制权交还给 agent。 为何重要？ 计算机操控的大部分成本在于对已解决任务的重复推理。将其摊销为可回放程序，是让 agent 第二次运行时变快的简洁方案。

Agent Loop 很火，但基座才是关键：从单代理到自我进化系统的 14 步路线图

Cursor 刚刚举办了他们的首次大会。 发布了： - 从零训练的 1.5T 参数模型 - GitHub 的直接替代品 Origin - iOS 应用 没人预料到这一幕 👇

/teach 现在会创建可复用组件，随着你学习的深入持续改进和演化。 更节省 token，也能积累学习动力。 看看这些漂亮的方块：

说实话我很喜欢 rahul，这篇文章的大部分内容都非常精彩，但我对开篇那句「模型基本上可以把英文编译成正确的代码」有异议。 我尽可能深入地用 Fable 做了测试，几乎没有发现代码是「正确」的——虽然大多数时候能跑起来，但 opus 4.5 也能做到这一点。 如果我们谈的是正确性的提升，我想看到的是真正结构良好、3-6 个月后不会崩掉的代码——而 Fable 远没做到。新的抽象层乱加、pattern 用错、在 server 端 fork shell 命令……所有的坑都踩了。 我真正欣赏的几点： - 优化杠杆——不是所有代码都需要完整 code review，但有些核心部分必须认真看，要确保 app 核心架构是健全的，因为模型现在还不值得信任来做这件事 - 把复杂度高但可以黑盒化的代码模块隔离出来，像对待神经网络一样——只看输出，不看内部实现 - 理解全栈的重要性，以及据此拆解问题的能力 【引用 @rahulgs】： 1. 在心智模型上，更正确的思路是把 Fable+ 这一级别的模型看作 English → code 解释器——无论问题复杂度和输出体量（diff 大小）如何，都能把你的想法转化成「正确」的代码。Fable 5 将是这一新型模型类别中最弱的起点。 2. diff 的大小/复杂度应该纯粹为 review 服务：高风险区域（auth/identity/数据访问/网络/支付）要小 diff；可以实证验证的代码（前端/后端管道/无网络或 DB 访问的代码/性能代码）可以大 diff。 3. 软件交付速度与产出 PR 的速度完全脱钩——真正的耗时取决于在规模化风险管理下 review 和合并代码的能力。 4. 解决上述瓶颈至关重要——linter/测试/CI/shadow mode 验证/实证验证。 5. 主动性（agency）极其重要——什么是提速和消除瓶颈的最大障碍？哪些问题需要解决，何时解决？今天把所有问题一次性解决需要什么条件？ 6. 对全栈的深度理解极其重要——哪些问题值得追？是否有更高层次的问题抽象需要先处理？应该给它子子任务、子任务还是任务本身？这个 PR 的主要风险是什么（按优先级：安全漏洞/正确性漏洞/性能漏洞）？有没有更快产出数据从而让这个 PR 可以合并的方式？是该跑 shadow mode、沙箱还是功能开关？不一定需要理解每一行逻辑，但理解和管理风险至关重要。 7. 复杂度本身的成本正在改变。现在可能值得「维护」多 50% 的代码来换取 5% 的性能提升。正确的抽象层变得不那么重要，因为大型重构不再那么繁琐。代码质量上的挑剔反而成了巨大阻力。很可能，更聪明的模型将来会维护你的代码，所以现在背负更多技术债是值得的。花时间手工架构和重建系统的速度代价极高。 8. 如果它走起来像鸭子、叫起来像鸭子，它就是鸭子。低风险场景下，把代码块（服务/函数）当作黑盒可能更明智，就像我们对待神经网络一样：只做完整的实证验证——这段代码在过去 10/100/1000/10000 次输入中产出了正确结果吗？能否把这大块代码隔离——禁止对外网络/数据库访问？代码出错会怎样——被黑/崩溃（内存/CPU）/只是个麻烦？是内部功能还是对外功能？如何规避这些风险？ 9. 最终，逐行 review 这种逻辑验证将付出极高代价——省着用在刀刃上，同时构建能够容忍实证验证的系统。有没有 decorator 能防止 DB/网络访问？正确性 bug 比访问控制 bug 容易修得多。 10. 什么样的「护栏」能让迭代更快？代码权限可以按需选择——DB 写、DB 读、网络出口（到哪里？）、PII 访问。获取 shadow mode 数据需要多久？能同时测多少个 PR？diff 的分类有哪些？

@dexhorthy：matt 花大量时间为软件架构打造优质 skills，背后的原因和我们构建 @humanlayer_dev 是一样的 [引用 @mattpocockuk]：发布 mattpocock/skills v1 - skill 描述的 token 成本降低了 63% - 将 skills 拆分为「模型可调用」和「用户可调用」两类，新增 /codebase-design、/domain-modeling 和 /grilling - （更新）/writing-great-skills——从头重写，融入我的 skill 编写最佳实践 - （更新）/diagnose → /diagnosing-bugs——改为模型可调用，调试复杂 bug 效果很好 - （新增）/ask-matt：一个路由 skill，教你如何把所有工程类 skills 串联起来使用

为什么中国公司在持续发布非常强的开源模型？