fofr@fofrAI · 2天前73

You can bootstrap your agent quickly with the Omni API using the skill we published: https://github.com/google-gemini/gemini-skills It includes: - video editing - text to video - video generation with image references - first frame to video But it also has some helper tools for: - prepping input videos for editing (10s, 720p) - audio stripping if you want to generate new audio - video inspection

译Google 通过 Gemini Omni API 发布 gemini-skills 技能包，支持视频编辑、文生视频、图片参考视频生成、首帧生成视频，并提供预处理输入视频为 10 秒 720p、音频剥离、视频检查等辅助工具。同作者展示 Omni Flash 模型编辑能力：输入“将桌子改成浅水池”，模型输出湿手、水波、折射、阴影及音效。该 API 已开放，可用于构建视频编辑流水线。

elvis@omarsar0 · 2天前24

Recommended reading if you are scaling with open models. BTW, you should be thinking about how to scale with open-weight models.

译推荐阅读，如果你正在使用开放模型进行扩展。 顺便说一句，你应该思考如何使用开放权重模型进行扩展。

宝玉@dotey · 2天前65

Q：我们公司有十几个微服务，现在想让开发用 AI Agent 来做系统设计和编码。问题是一个 user story 经常需要多个微服务协作，Agent 必须了解每个服务的职责边界和业务概念才能做出合理的设计。我们打算把所有微服务放到一个 workspace 下，每个服务配上自己的文档，让 AI 自己去处理。这种方式合理吗？有没有更好的实践？ A：用好 Agent 的关键是两点：上下文的质量，和验证的闭环。 先说上下文质量。 放在一个 workspace 下是目前社区比较推荐的做法。 monorepo 天然适合和 AI 配合，因为 Agent 可以在一个地方同时看到 schema 定义、API 协议、各个服务的实现代码。如果因为历史原因确实不方便合成 monorepo，有个折中方案叫虚拟 monorepo，就是把多个仓库 clone 到同一个本地目录下。 除了放在一起，文档也是很好的让Agent获取上下文的方式，最好给 Agent 一张地图，加上按需加载： 1. 根目录放一份总的 AGENTS.md(或 CLAUDE.md)当索引用，列清楚有哪些服务、各自负责什么、要改某个服务就去读它目录下的文档。 2. 每个微服务自己目录里再放一份,写清自己的职责边界和业务概念,这其实就是 DDD 里的 bounded context。 3. 让 Agent 先看根索引，定位到相关的那几个服务，再去加载它们的细节。 不过要注意文档要及时更新，尤其是微服务协议变更了，一定要及时更新文档，否则会误导。 能从代码或规格自动生成的，就别手写。手写文档迟早会和代码对不上，而像 OpenAPI 这种机器可读的接口规格，一份东西既是文档，又能拿去生成 mock 和测试。 除了文档，还有一个很多人忽略的上下文来源：协议测试代码。高质量的 contract test 本身就是最准确的活文档，它精确地描述了服务之间实际的交互协议，比人写的文档更不容易过时，因为错了测试就无法通过。你如果已经有 OpenAPI spec 或者 Pact 契约文件，这些对 Agent 理解服务边界非常有价值。 再说验证。微服务场景下验证是最麻烦的部分，因为一个 user story 可能涉及好几个服务协作，你不可能让 Agent 每改一行代码就把整个系统跑起来做端到端测试。 一个实用的思路是：每个微服务提供 mock server 或者基于 OpenAPI spec 自动生成的模拟服务。Agent 写完代码后可以在本地跑 contract test 验证自己的改动有没有破坏和其他服务的协议约定，不需要依赖线上真实的 API 或者完整的集成环境。这样 Agent 就能形成一个“写代码→跑测试→自我修正”的闭环，不需要人在过程中频繁干预。 想再进一步,建议了解一下契约测试(consumer-driven contract testing，常用工具是 Pact)。思路是调用方把自己实际用到的接口形状记下来，生成一个契约文件，被调方再去验证自己能不能满足这个契约。 简单说：workspace 统一提供全局视图，分层文档 + 协议测试提供精准上下文，mock server + contract test 提供验证闭环。这三层搭好，Agent 处理跨微服务的系统设计就比较靠谱了。 一些参考资料 1. Anthropic 的 Effective context engineering for AI agents，讲怎么把上下文当稀缺资源来经营、按需加载: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 2. Anthropic 的 Effective harnesses for long-running agents，讲长任务里怎么给 Agent 搭脚手架(比如用进度文件加 git 记录跨上下文窗口接力)： https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents 3. 怎么在 monorepo 里组织 AGENTS.md 给 Agent 用,可以看 http://dev.to 上这篇 Steering AI Agents in Monorepos with AGENTS.md： https://dev.to/datadog-frontend-dev/steering-ai-agents-in-monorepos-with-agentsmd-13g0 契约测试入门，搜 Pact 加 consumer-driven contract testing 的指南就行。

译建议将所有微服务放在一个workspace（monorepo或虚拟monorepo），让Agent同时看到schema、API和实现代码。文档采用分层结构：根目录AGENTS.md索引各服务职责，每个服务内写清bounded context。优先用OpenAPI spec等机器可读规格自动生成文档。协议测试（contract test）是精准活文档，能验证服务间交互。验证环节各服务提供mock server或基于OpenAPI的模拟服务，Agent在本地跑contract test形成“写代码→跑测试→自我修正”闭环。可进一步引入consumer-driven contract testing（如Pact）。

凡人小北@frxiaobei · 2天前70

做 agent 自动化系统时，一个很容易踩的坑：把“放行信号”写在调用者也能写的地方。 比如 AI review 在 PR 下面贴评论，monitor 再回读评论，看到 High: None 就自动合并。听起来合理，其实很危险。 因为 PR 评论是第三方可写信道，任何有评论权限的人/agent 都能伪造格式正确的放行结果。 安全门禁的信任结果应该走进程内闭环：returncode、内存状态、FD、签名结果。 评论可以给人看，但不能当门禁。

译将放行信号放在PR评论等可被调用者写入的通道存在风险。AI review贴评论，monitor回读“High: None”即自动合并，但任何有评论权限的人或Agent都能伪造结果。安全门禁的信任结果应走进程内闭环（如returncode、内存状态），评论仅供查看，不可作为门禁依据。

小互@xiaohu · 2天前81

http://x.com/i/article/2071795831028826112 # 一个人，管理开发5款产品，而且80% 时间不在写代码，靠这一步... Every 单人团队运营 5 款产品，核心是每次完成功能后多做的一步：把解法存进系统，让 AI 下次自动避坑。 > ⚑ 立场提示：本文是 Every 团队自述其「复利工程」方法论与自家开源插件的实践，文中的并发规模、时间分配、产品数量都是官方口径。下面只讲它怎么运作、每个数字代表什么。 > ▸ 先认识下 Every：Every（every.to）是一家 2020 年成立的媒体 + 软件公司，CEO 兼联合创始人是 Dan Shipper。它每天发一份讲「科技下一步」的付费 newsletter，同时自己动手做软件产品——文中的 Cora、Monologue、Sparkle、Spiral 都出自它，另外还做 AI 课程和咨询。所以「复利工程」不是纸上谈兵，是一家又写又做、天天泡在 AI 里的公司，从自家实战里攒出来的方法。 ## 速览 - Every 用「复利工程」（Compound Engineering），以基本单人的工程团队维护旗下 5 款产品，核心是 Plan → Work → Review → Compound 四步循环。 - 传统工程走到 Review 就停了，第四步 Compound 把每次解决的问题变成系统知识，让 AI 下次自动避开同类错误，效率差距就来自这里。 - 这套方法主张工程师 80% 的时间花在 Plan 和 Review，只有 20% 用来实际写代码。 - 配套插件已开源，支持 Claude Code / OpenCode / Codex，含 26 个专项 agent、23 条工作流命令、13 项技能，零配置即用。 - /workflows:review 一次调用并发 14 个专项 agent 审查代码，/workflows:plan 开 ultrathink 模式可并发 40 多个研究 agent。 ## 一个人撑五款产品，怎么做到的 Every 团队最近公开了一套叫「复利工程」（Compound Engineering）的方法论，外加一个配套的开源插件，讲他们怎么用基本是单人配置的工程团队，同时维护旗下五款产品。 五款产品 Cora、Monologue、Sparkle、Spiral，加上官网 Every.to，每个产品的工程团队基本只有一个人。撑住这套规模的不是更长的工时，而是一个四步循环里被大多数团队省掉的最后一步。 > ◆ 为什么值得看：Every 把平时只在内部跑的东西开源了，包括 14 个 AI 同时审一段代码、计划阶段并发 40 多个研究 agent，外加 26 个专项 agent。这是目前公开的多 agent 并行工程实践里，数字最具体的开源参考之一。 ## 代码越写越难碰，根子在哪 大多数代码库随时间越来越难维护，原因不复杂：每加一个功能，就往系统里注入一份新的复杂度，新功能要和所有旧功能「谈判」。十年下来，团队花在跟历史代码较劲上的时间，比花在造新东西上的还多，代码变得越来越难懂、难改、难信任。 复利工程把这条曲线反过来。功能不再是往系统里加负担，而是教会系统一项新本领；修一个 bug，顺手消掉未来一整类同类 bug；一个解法被固化下来，就变成下次能直接复用的工具。迭代越多，系统越好用。 ## 四步循环：80% 的时间根本不是在写代码 支撑这套规模的，是一个四步循环：Plan（计划）、Work（执行）、Review（审查）、Compound（固化），然后重复。不管你是花五分钟修个 bug，还是花几天做个功能，走的都是这四步，只是每步花的时间多少不同。 前三步任何开发者都熟，第四步 Compound 才是复利工程和普通工程的分界线。跳过它，你做的就只是「有 AI 助手的传统工程」。传统工程到 Review 收手，复利工程多走 Compound 一步，把这一轮学到的东西留给下一轮。 反直觉的地方：写代码只占两成时间。 Plan 和 Review 加起来占工程师 80% 的时间，真正动手写（Work）加上固化（Compound）只占 20%。大部分思考发生在代码被写出来之前和之后。 四步各自在做什么： - Plan 计划：把想法变成蓝图。弄清需求和约束、研究代码库里同类功能怎么实现、查框架文档和最佳实践、设计方案、再校验方案是否站得住。 - Work 执行：先用 git worktree（仓库的隔离沙盒副本，多任务可各开一份并行跑、互不干扰）开出隔离环境，agent 按计划逐步实现，每改一处就跑测试、linting 和类型检查。 - Review 审查：多个专项 agent 并行审，把问题标成 P1（必须修）/ P2（应该修）/ P3（可以修），修完再校验，并记录这次出了什么问题。 - Compound 固化：把解法抽成可复用的知识写回系统——下面一节专门讲。 几个 Every 建议丢掉的旧观念： - ✕「代码必须手写」 你的职责是产出可维护、解决对问题的好代码，谁敲键盘不重要。 - ✕「第一版就该写好」 他们的经验里第一版 95% 是垃圾、第二版还有 50%，这是过程，目标是迭代够快让第三版落地比第一版还省时。 - ✕「不亲手敲就学不到」 今天理解比肌肉记忆重要，审 10 个 AI 实现比手敲 2 个学到的模式更多。 - ✕「代码是自我表达」 代码从来不属于你个人，它属于团队、产品和用户。 ## 第四步具体怎么做：把解法变成系统的记忆 前三步产出的是「一个功能」。第四步 Compound 产出的是「一个每次都能把功能做得更好的系统」。它落到地上是四个动作： 1. 记录解法——什么管用、什么没用、可复用的点是哪个。 1. 加元数据——用 YAML frontmatter 打标签，方便日后检索。 1. 更新 CLAUDE.md——把新模式写进 agent 每次启动都读的文件。 1. 验证学到了——下次它能自动接住同类问题吗。 > 复利的来源：传统开发停在第三步审查，复利工程多走这一步——把刚解决的问题写进系统。这一步不产出代码，产出的是「系统下次自动避开同类问题」的能力。效率差距就来自这里。 > 打个比方：CLAUDE.md 就是放在项目根目录的「AI 操作手册」，agent 每次启动都会先读它。它像新员工入职必读的 SOP：每当有人解决了一个之前没遇到的问题，就往里加一条规则，下一个人来就自动懂了，不用再踩一遍同样的坑。 下面这个对照，能直观看到这条规则攒下来之后的差别： - ✕ 没有积累：agent 不知道这个坑，你和它一起调试、定位、修好。修完，Compound 把「为什么会出、怎么避开」写进 CLAUDE.md，并存一份带 YAML 标签的文档进 docs/solutions/。这一次多花了点时间记录。 - ✓ 系统已经记住了：agent 一启动就读到那条规则，docs/solutions/ 里也能搜到上次那份解法。于是在 Plan 阶段它就主动绕开了同类问题，根本走不到出 bug 那一步。前面那次记录的时间，在这里连本带利赚回来。 每完成一次 Compound，CLAUDE.md 就多一条知识：迭代 1 → 1 条，迭代 3 → 3 条，迭代 5 → 8 条，系统越用越聪明。docs/solutions/ 就这样攒成一座机构知识库——Every 用 /workflows:compound 跑这一步，并发派出六个子 agent（理解问题、抽取解法、找相关旧文档互链、写「怎么避免复发」、做分类标签、排版成文档），日后任何一次会话都能自动翻到过去的解法。 ## 14 个 AI 同时帮你审代码 一条 PR 进来，/workflows:review 会一次性派出 14 个专项 agent，同时开跑，每个只盯一个维度，最后合并成一份按 P1 / P2 / P3 排好优先级的清单。 1. security-sentinel（安全）— 扫 OWASP Top 10、注入攻击、认证与越权。 1. performance-oracle（性能）— 揪 N+1 查询、缺索引、可缓存点、算法瓶颈。 1. architecture-strategist（架构）— 评估系统设计、组件边界、依赖方向。 1. pattern-recognition-specialist（架构）— 识别设计模式、反模式、代码坏味道。 1. data-integrity-guardian（数据）— 校验数据库迁移、事务边界、引用完整性。 1. data-migration-expert（数据）— 检查 ID 映射、回滚安全、生产数据校验。 1. code-simplicity-reviewer（质量）— 执行 YAGNI，揪多余复杂度。 1. kieran-rails-reviewer（质量）— Rails 规范、模型与控制器职责。 1. kieran-python-reviewer（质量）— PEP 8、类型注解、Pythonic 写法。 1. kieran-typescript-reviewer（质量）— 类型安全、现代 ES、整洁架构。 1. dhh-rails-reviewer（质量）— 37signals 风格：简单优先于抽象。 1. deployment-verification-agent（部署）— 上线前检查单、上线后验证、回滚预案。 1. julik-frontend-races-reviewer（前端）— 揪 JS 和 Stimulus 里的竞态。 1. agent-native-reviewer（Agent-native）— 确保功能不只人能用，agent 也能用。 > 顺带科普 · N+1 查询：查一张 100 条的列表，写法不对就变成每条再单独查一次，一共 101 次请求。像去超市买 10 样东西却跑了 11 趟——先去看看有什么（1 趟），再每样单独取一次（10 趟）。 合并去重后归到一份带优先级的清单，大致长这样： - P1 必须修：搜索查询有 SQL 注入漏洞（security-sentinel）／创建用户缺少事务包裹（data-integrity-guardian） - P2 应该修：评论加载有 N+1 查询（performance-oracle）／控制器里塞了业务逻辑（kieran-rails-reviewer） - P3 可以修：有一个未使用的变量（code-simplicity-reviewer） /resolve_pr_parallel 自动处理全部问题，先修 P1 再 P2、各自隔离跑、最后你人工过一遍；想先筛再修就用 /triage 逐条决定。 ## 插件里有什么，装上怎么用 整套流程打包成一个插件，零配置装上就能用，支持 Claude Code，也实验性支持 OpenCode 和 Codex。 - 26 个专项 agent：每个只精一件事——14 个 review 专家，外加研究型、设计型、自动化、文档型。 - 23 条工作流命令：主循环 plan / work / review / compound，加一批实用工具命令。 - 13 项技能：即取即用的领域知识，比如 agent-native 架构技能、风格指南技能。 四个目录各管一摊：CLAUDE.md（agent 每次启动必读的操作手册）、docs/solutions/（每个解决过的问题存成可搜索文档）、docs/plans/ 与 brainstorms/（计划产出）、todos/（review 查出的问题带优先级）。 Claude Code 两行装好： > claude /plugin marketplace add https://github.com/EveryInc/every-marketplace claude /plugin install compound-engineering 还有个一键到底的 /lfg：你只描述功能，它把计划 → 深化计划 → 执行 → 审查 → 修问题 → 浏览器测试 → 录功能演示 → 固化整条流水线串起来自动跑，全程派出 50 多个 agent，最后交你一个能直接合并的 PR，中途只在计划批准处停一下。 ## 关键数字：并发规模到底有多大 - 5 款——Every 用这套方法维护的产品数量，工程团队基本为单人配置。 - 80 / 20——计划＋审查占工程师 80% 时间，执行＋固化只占 20%。 - 14 个——/workflows:review 一次调用同时运行的专项审查 agent 数量。 - 40+ 个——/workflows:plan 开 ultrathink 模式后派出的研究 agent 数量。 - 26 / 23 / 13——插件包含的专项 agent 数 / 工作流命令数 / 技能数。 > 每一份工程工作，都应该让后续的工作更容易，而不是更难。 —— Every《Compound Engineering》 本文为 Every 团队自述其「复利工程」方法论与开源插件实践，文中并发规模、时间分配、产品数量均为其官方口径。原文：Every《Compound Engineering》，every.to/guides/compound-engineering。插件开源地址：github.com/EveryInc/compound-engineering-plugin。

译媒体软件公司Every公开「复利工程」方法论，以单人工程团队维护5款产品。核心是四步循环：Plan→Work→Review→Compound，其中Compound将每次解决问题的解法写入CLAUDE.md和docs/solutions/，使AI下次自动避坑。工程师80%时间花在Plan和Review，仅20%用于写代码。配套开源插件支持Claude Code等，含26个专项agent、23条工作流命令、13项技能，可零配置使用。/workflows:review一次并发14个agent审查代码，/workflows:plan在ultrathink模式下可并发40多个研究agent。

宝玉@dotey · 2天前63

开源项目推荐：Claude Code From Scratch 这是一本学习 Claude Code 的开源电子书，严格来说不仅仅是电子书，还有代码，不需要你去看 Claude Code 的 50 万行代码。 用 ~4300 行代码（TypeScript 和 Python 两个版本分别实现）复现了 Claude Code 的核心架构——Agent Loop、13 个工具（含并行执行 + 流式早期启动）、4 层上下文压缩、语义记忆召回、技能系统、多 Agent、MCP 集成……每一步都对照真实源码讲解它怎么做的 → 我们怎么简化的。 有 13 章内容，每一章都是一份分步教程，跟着动手写几千行代码，快速理解 Claude Code 这样最好用的 coding agent 的精髓。 读完你就能大致理解了 coding agent 的工作原理，我跟着快速浏览了下都有了些新的收获，推荐有兴趣的可以看看。 有中英文版： https://diwang.info/claude-code-from-scratch/#/

译开源电子书用约4300行代码（TypeScript和Python）复现Claude Code核心架构，涵盖Agent Loop、13个工具、4层上下文压缩、语义记忆召回、技能系统、多Agent、MCP集成。全书13章分步教程，讲解如何简化实现。提供中英文版。

karminski-牙医@karminski3 · 3天前40

本质上草稿模型生成的高接受率的token往往都是信息熵比较低的，比如标点符号，助词，代码的容易补全的语法等。但是这些计算成本在大模型中是不变的。所以这部分一旦被接受，不会降智但能提升性能。而真正决定prompt质量的那些接受率是特别低的。所以这也是DSpark聪明的一点，它还后置了一个置信度调度器。

译主推文解释DSpark（类似MTP的预测技术）为何不降智：草稿模型生成的高接受率token（标点、助词、代码语法等）信息熵低，计算成本不变，被接受后提升性能而不影响质量；真正决定prompt质量的token接受率低。后置置信度调度器进一步保证效果。回应了引用中关于“小模型逆合不如大模型自解码为何不降智”的疑问。

karminski-牙医@karminski3 · 3天前57

DeepSeek真的是性价比和技术双重斩杀线... 有同学看不懂DSpark是啥, 简单给大家写个小教程讲讲. 推测性解码(投机解码)这个技术是用来提升大模型输出速度的. 本质是让小模型给大模型接话, 大模型判断小模型说的对不对. 因为现在模型普遍卡内存带宽, 而GPU算力是富余的, 所以大模型的prefill速度(看字)比decode速度(吐字)快很多. 那么让小模型沿着大模型的思路先说一段话, 大模型判断对不对(只需要看字), 只要小模型猜对了, 那么这就利用了prefill速度, 吐字就会成倍的提升. 但问题来了, 外挂小模型也要看字(prefill), 也要占用显存, 也要吃显存带宽. 那么有没有更好的方法来解决呢? 来了, 这就是DSpark. 看我的这个图(左侧DSv4架构图是 @rasbt 大佬的), DSpark 接在了 Final RMSNorm 过程中. 不是接一个完整的小模型, 而是一个3 层的MTP(多Token预测)微型Transformer堆叠. 大模型算完前面60多层后, 刚把当前这句话的"高浓缩概念"(特征向量/隐藏状态)推到 Final RMSNorm 这个出口，还没来得及翻译成具体文字时，DSpark开始截胡: 首先是半自回归极速脑补 (MTP + Markov Head), DSpark自己有一丢丢参数, 然后它就瞬间并行猜5个字(特征向量), 然后再用自己内部的一个串行网络理顺逻辑. (注意啊,先并行然后串行消除并行导致的逻辑不连贯). 然后, 它会有一个置信度预测头, 预判自己猜的准不准, 比如5个字的后2不准就直接砍掉, 防止后续送回大模型浪费算力. 最后把留下的3个字塞回词表映射层, 把向量翻译为token. 到此为止DSpark工作就做完了. 然后就是大模型扫一遍DSpark输出的对不对(只用prefill，不decode), 一旦正确了, 就直接吐字, 这样之前模型一次只能吐一个字, 现在就能吐3个字了! 最后, 推测性解码是不会降智的, 速度能提升60%-85%! 之前是雇一个小模型帮忙写草稿, 现在则是直接脑子里植入芯片了. 目前SGLang已经有这个特性的PR了(29538), 而且DeepSeek刚在自己的HuggingFace主页发了一大堆小模型的DSpark魔改版. 大胆猜一波未来发布的模型会不会标配DSpark? #dspark #deepseek #投机解码 #推测性解码

译DeepSeek推出的DSpark是一种推测性解码技术，通过在Final RMSNorm后接入3层MTP微型Transformer堆叠，让大模型在输出前并行猜5个token，经置信度头剪裁后，送回大模型用prefill验证，正确则一次性吐出多个token。相比外挂小模型更高效，不降智，速度提升60%-85%。目前SGLang已有相关PR（#29538），DeepSeek已在HuggingFace发布多款DSpark魔改版小模型。

swyx @aiDotEngineer WF Day 1@swyx · 3天前18

AIE workshop day https://x.com/i/broadcasts/1dGYllOggQoKX

译AIE 工作坊日 https://x.com/i/broadcasts/1dGYllOggQoKX

Berryxia.AI@berryxia · 3天前61

睡前来一发，这个视频还是挺完美的。 Anthropic的应用AI工程师Margot Van Laar在Code with Claude分享了提示词工程的实战手册。 核心观点是：我们很少从零写提示词，大部分时间都在调试和维护已有的生产提示词。 最好的起点永远是评估（Eval），而不是直接改提示词。 她用两个真实场景演示了最佳实践： 1. 维护已有提示词**（客服机器人） - 先做通用清理：用XML标签结构化（角色/政策/语气/指南分开）、移除冗余补丁、明确输出格式。 - 常见陷阱：以前为旧模型加的“禁止列表”指令，在新模型上会过度拟合，导致模型隐瞒它其实能提供的信息。 - 当模型需要做精确计算时，指令没用，要给它工具。 - 升级/转人工的决策，要把代价和收益两面都说清楚，否则模型会过度优化某一边。 2. 从零构建新Agent（零售排班） - 单一复杂提示词容易失败。 - 更好的方式是拆成生成-评估-修复循环，让三个简单提示词各司其职。 - 模型选择很重要：更强的推理模型（Opus）+ 自适应思考，往往比小模型+复杂提示词更高效。 她反复强调：评估是唯一能告诉你改动是否真正有效的严谨方式。 没有评估，就只是在碰运气。

译Anthropic应用AI工程师Margot Van Laar在Code with Claude分享提示词工程实战手册。核心观点：维护已有提示词比从零写更常见，最佳起点是评估（Eval）而非直接改提示词。两个场景：客服机器人需用XML标签结构化，移除旧模型冗余指令，为精确计算提供工具；零售排班Agent应拆分成生成-评估-修复循环，使用更强推理模型（Opus）+自适应思考。强调评估是判断改动有效性的唯一严谨方式。

Berryxia.AI@berryxia · 3天前77

Margot Van Laar是Anthropic应用AI团队的工程师。 她在Code with Claude大会上做了一场关于提示词工程实战的分享。 核心观点只有一个：我们很少从零写提示词，大部分时间都在调试和维护已有的生产提示词。 她用两个真实场景演示了这件事。 第一个场景是客服机器人的维护。 团队接手了一个已经在跑的提示词，第一步不是改内容，而是做结构化清理——用XML标签把角色、政策、语气、指南分开，移除冗余补丁，明确输出格式。 然后她发现了一个经典陷阱。 团队之前为旧模型加了一条"禁止列表"指令，告诉模型不要提供某些信息。 换到新模型后，这条指令导致模型过度拟合——它开始隐瞒自己其实能提供的信息。 旧模型需要这条指令是因为能力不够，新模型不需要了，但指令还在。 另一个发现是：当模型需要做精确计算时，提示词里的"请仔细计算"没有用。 要给它工具。让模型调用计算器，比让它在脑子里算靠谱得多。 升级转人工的决策也是个坑。如果提示词只告诉模型"用户不满就转人工"，模型会过度优化这一边，把所有对话都转出去。 正确做法是把代价和收益两面都说清楚，转人工的成本是什么，不转的风险是什么，让模型自己权衡。 第二个场景是从零构建零售排班Agent。 团队最初的方案是写一个复杂提示词，把所有逻辑塞进去。结果频繁失败。 更好的方式是拆成三个简单提示词，组成生成-评估-修复循环。 第一个负责生成排班方案，第二个负责评估方案是否合规，第三个负责修复问题。 每个提示词只做一件事，组合起来比一个大提示词稳定得多。 她还提到了模型选择。 团队测试发现，用更强的推理模型（Opus）加自适应思考，效果往往比小模型加复杂提示词更好。不是所有场景都需要优化成本，有时候用更好的模型反而是最省事的方案。 她反复强调一句话：评估是唯一能告诉你改动是否真正有效的严谨方式。 没有评估，就只是在碰运气。 这句话适用于所有做AI应用的人。 大部分人改提示词的方式是"感觉这样写更好"，然后上线看效果。但"感觉"不是评估。 你需要一个可量化的基准，每次改动后跑一遍，才能确定到底是变好了还是变差了。

译An anthropic应用AI工程师Margot Van Laar在Code with Claude分享提示词工程实战，核心观点：大部分时间在调试和维护已有生产提示词而非从零编写。两个场景：客服机器人维护中，用XML标签结构化清理，移除旧模型遗留的“禁止列表”指令（新模型会过度拟合），精确计算应调用工具，转人工决策需明确代价与收益；零售排班Agent从零构建时，拆成生成-评估-修复三个简单提示词更稳定，选用更强推理模型（Opus）。她反复强调：评估（Eval）是唯一严谨方式，没有评估就是碰运气。

Berryxia.AI@berryxia · 3天前64

睡前来一发，这个视频还是挺完美的。 Anthropic的应用AI工程师Margot Van Laar在Code with Claude分享了提示词工程的实战手册。 核心观点是：我们很少从零写提示词，大部分时间都在调试和维护已有的生产提示词。 最好的起点永远是评估（Eval），而不是直接改提示词。 她用两个真实场景演示了最佳实践： 1. 维护已有提示词（客服机器人） - 先做通用清理：用XML标签结构化（角色/政策/语气/指南分开）、移除冗余补丁、明确输出格式。 - 常见陷阱：以前为旧模型加的“禁止列表”指令，在新模型上会过度拟合，导致模型隐瞒它其实能提供的信息。 - 当模型需要做精确计算时，指令没用，要给它工具。 - 升级/转人工的决策，要把代价和收益两面都说清楚，否则模型会过度优化某一边。 2. 从零构建新Agent（零售排班） - 单一复杂提示词容易失败。 - 更好的方式是拆成生成-评估-修复循环，让三个简单提示词各司其职。 - 模型选择很重要：更强的推理模型（Opus）+ 自适应思考，往往比小模型+复杂提示词更高效。 她反复强调：评估是唯一能告诉你改动是否真正有效的严谨方式。 没有评估，就只是在碰运气。

译Anthropic应用AI工程师Margot Van Laar在Code with Claude分享提示词工程实战手册。核心观点：生产提示词大多时间在调试维护，最好起点是评估而非直接修改。维护客服机器人提示词时，需用XML标签结构化，移除冗余补丁，明确输出格式；避免旧模型“禁止列表”指令在新模型上过度拟合；精确计算应赋予工具；升级决策需说明代价与收益。从零构建零售排班Agent，应拆分为生成-评估-修复循环，三个简单提示词各司其职；更强推理模型+自适应思考更高效。评估是唯一验证改动的严谨方式。

Berryxia.AI@berryxia · 3天前45

兄弟们，终于跑通了~ 爆肝完成，现在做项目介绍太方便了！ 这套视频讲解的Skills 差不多跑通了，只需提供网站、内容、视频地址等就可以直接给你剪基础这样的讲解视频。 还挺方便的，需要的人多吗？ 感兴趣的朋友多么？评论区告诉我

译Berry Xia 宣布成功完成了一套“视频讲解的Skills”开发与测试。用户只需提供网站、内容、视频地址等信息，该技能就能自动生成基础的讲解视频。作者询问社区兴趣度，表示如果需求多可能会进一步分享。目前未披露具体使用的模型或平台名称。

elvis@omarsar0 · 3天前56

LLM-as-a-Judge explained in ~10 mins. Knowing how to build AI verifiers and judges is one of the most important emerging AI skills today. Here is a quick intro on the topic and where to learn how to apply LLM-as-a-Judge.

译LLM-as-a-Judge 在约10分钟内解释完毕。 学会构建AI验证器和裁判是当今最重要的新兴AI技能之一。 这里提供一个快速介绍，以及在哪里学习如何应用LLM-as-a-Judge。

fofr@fofrAI · 3天前54

> This is a prompt showing that text works well in Omni. The exact text of this prompt is shown verbatim in this ambient video. The text appears one sentence at a time, like at the beginning of a movie. The backdrop is flying through a blue sky.

译这是一个提示词，展示了文本在Omni中的良好效果。 该提示词的精确文本逐字显示在此环境视频中。 文本逐句出现，如同电影的开头。 背景是飞过蓝天。

fofr@fofrAI · 3天前71

I'm using this skill for everything an agent writes now. Huge quality of life improvement.

译我现在用这个技能来处理 agent 写的所有内容。生活质量大幅提升。

fofr@fofrAI · 3天前70

I am loving this process for skill making: - setup subagents that can do deep research - ask for X research runs covering different angles of a thing - distill the research reports into a single SKILL.md - include research alongside skill for reference

译我非常喜欢这个技能制作流程： - 设置能进行深度研究的子智能体 - 针对某事物不同角度要求进行X次研究运行 - 将研究报告蒸馏成一份SKILL.md文件 - 将研究内容与技能一同包含以供参考

MiniMax (official)@MiniMax_AI · 3天前39

This is a glimpse of where local AI is heading and we are glad to be part of it. Really impressive work by all the teams involved @Gradient_HQ, @tryParallax, and @GA_agent_ai

译MiniMax官方转发了Gradient、Parallax和GenericAgent团队的演示结果。他们在本地运行了MiniMax M3（428B参数模型），通过Parallax工具部署在3台Mac上，再由GenericAgent驱动一个约3000行代码的自主智能体，完成了创建5只股票投资组合并写入磁盘的任务。整个过程完全在本地进行，无云端调用、无API费用，数据未离开机器。MiniMax表示这是本地AI未来发展的一个缩影。

数字生命卡兹克@Khazix0918 · 3天前64

http://x.com/i/article/2071459685358792704 # 分享2个Vibe Coding必备的超实用Prompt。 周末跟几个之前的老朋友吃饭。 大家也都不由自主的聊到了AI，然后也聊到了Vibe Coding。 因为几乎都不是专业的程序员，都是各个其他职业的，有基金经理、设计师、老师、产品经理、媒体人等等等等，所以大家也都说了蛮多自己使用Vibe Coding的心得，也聊了不少过程中遇到的坑。 然后他们就问我，你几乎每天都在Coding，也写了那么多的教程和分享，问我说如果让你给大家安利几个Vibe Coding中最实用的小技巧，你觉得是什么。 我当时还真的想了半天。 最后，我想到了两个技巧，同时也是两个神级Prompt，是我觉得上至巨佬，下至萌新都有用的超级好用的东西： 1. 第一性原理。 2. 对抗式审查。 可以说，我自己在这将近1年的Vibe Coding时间里，这两个词，绝对是我如今每天跟AI说的最高频词汇。 前者管生成，后者管验证，基本能保证你在Vie Coding的时候，写出来的代码和最后的运行，有质的飞跃。 其他的技巧当然也有用，比如我自己一直在说的约束先行、洁癖skill做文档迭代等等，这些也都是好东西。 但如果你只能选两个，那我就选这两个，它们加在一起构成了一个完整的闭环，是我当今心目中Vibe Coding的两大基石，并肩站在一起的那种。 然后给大家在饭桌上解释了一下，大家说，你不如写成文章吧，他们觉得还挺有用。 所以，这篇文章就来了。 也强烈给给大家安利一下这两个技巧。 1. 第一性原理 这个技巧有多简单呢，就是你平时咋说就咋说，但是最后加一句“从第一性原理出发”就行。 你相信我，加了这一句话后，你会发现Agent写方案的能力、找BUG的能力，都进化了一大截。 举个我周末的例子。 我自己做的AIHOT周五出了一个很严重的事故，就是我们的精选消息飞书推送出了BUG，导致周六凌晨，像OpenAI发布GPT-5.6这种大新闻，在飞书群里居然没有被推送。 然后用户直接反馈，有的甚至都在别的消息卡片下面评论，我周六中午一醒，飞书的反馈提醒直接炸了，二十多条用户反馈。 我就赶紧让Agent去修，他查了下跟我说，是因为之前测试一个国产模型的时候，OpenAI的抓取被那个国产模型给瞎改改坏了，所以断了三天，OpenAI的官网信源其实就一直没有抓取到，只不过今天才发现，让我修好就行。 但是我当时有一种直觉，我寻思，这不对啊，这个背后，感觉有更严重的问题，这个修复，好像治标不治本。于是又补了一句，根据第一性原理来找一下原因。 这一次，瞬间就不一样了。 细节我就不太好说了，不过它找到了我们抓取海外信源的规则中的一个巨大的隐患，而且这个隐患非常的底层非常的深，是流量路由层面的，这个代码甚至都是今年4月中写的，只是因为那个国产模型瞎改代码，在表层上面做错了一个小点，然后把整个底层的流量路由问题都暴露出来了。 我们当然可以非常简单的把OpenAI的抓取给单独修复一下，但是未来因为这个底层机制，未来你保不齐又有什么信源会出问题，你倒是可以再修再补，但是那就跟一艘破船一样，缝缝补补，最后堆成一座屎山，到时候再暴雷，那就真的会爆个天大的了。 于是我花了半天时间，把这个底层的路由问题直接重构了，目前从机制上看，未来大概率就可以安心了。 你看，一个是治表，一个是治本，这个差异，还是巨大的。 这就是第一性原理的力量。 在跟AI对话时，更是格外好用。 社区里更是有朋友，把它称为神之Prompt之一。 坦率的讲，现在的AI，很多都还是在做类比推理，跟人类一样，你跟它说写一个过滤函数，它会在训练数据里找到几万个类似的过滤函数，然后给你写一个符合你项目的看起来差不多的出来。 这个过程很快，结果也能用，但它跳过了一个我认为最最最最最关键的步骤。 就是，这个问题真的应该这么解吗？ “从第一性原理出发”这七个字，做的事情就是强制打断AI的类比推理，逼它回到问题的本质去思考，不要参考别人的方案，从最基本的事实出发，重新推导。 这个道理亚里士多德两千多年前就说过了。 然后马斯克把这套思维用在了SpaceX上。 当时行业里所有人都说火箭发射就是得花几个亿，这就是所谓的行业共识。 马斯克我觉得你在放屁，我们重新材料成本开始算起，铝合金、碳纤维、航空级燃料，这些原材料加起来才多少钱，你告诉我几个亿？然后SpaceX从这个数字出发重新设计整个制造流程，最后发射成本降了90%。 GitHub上甚至已经有人做了专门的skill，就叫first-principles。 不过我觉得，你也没必要装什么Skill，不需要写什么System Prompt，你就在需要的时候，比如解决问题、修BUG、让AI帮你设计架构的时候，在你的Prompt后面加一句“从第一性原理出发”，相信我，这就够了。 只要你的任务稍微复杂一点，这个Prompt几乎是万能的。 神级Prompt，我觉得，当之无愧。 2. 对抗式审查 这是我之前发现的，超级有用的一个审查Prompt。 我现在只要做开发，最后的测试流程，几乎都必然是对抗式审查这句话了。 第一性原理可以保证帮你找到好的方案、帮你找到BUG的真正的最本质的解法，但是他们没办法保证，开发完了以后，能稳定的上线。 而这，就是这个Prompt去解决的试了，怎么保证AI写的代码确实没啥毛病。 今年6月初的时候，也就是Claude Opus 4.8和动态工作流上线之后，我对AIHOT做了一次比较大的对抗式审查，就是纯找BUG。 当时我印象中，开启了近40个Agent，跑了很久，然后找出了N个可能的风险。 比如有一个叫OOM的死循环问题，就是后台worker如果处理一个特别大的任务时内存爆了，就会被系统杀掉，然后会自动重试，然后结果必然是又爆，又被杀，无限循环。 对抗式审查从“如果我是一个恶意用户，我会提交一个50MB的HTML来搞崩你的worker”这个角度，把整条路径从入口到崩溃全走了一遍，找出了这个缺口，避免了后续一系列的风险，因为我后面信源加多了之后，还真的看到过100M的HTML。。。 最搞笑的是还有一个未来时间污染的BUG。 就是如果某个信源发布了一篇文章，但这篇文章的发布时间因为时区错误或者别的原因，显示的是未来的某个时间，比如明天，那这篇文章就会排到整个精选信息流的最前面，因为它的时间戳最新。 它甚至还可能会被推送给用户，进入飞书群PUSH，进入RSS订阅，日报也会把它排在最前面。 一篇来自未来的文章，就会把整个信息流都污染了。 这种BUG你自己写代码的时候根本不会想到。 但当你让AI站在我要用各种奇怪的数据来搞崩掉你的系统这个角度来审查的时候，它就会问，如果发布时间是未来怎么办？ 然后还有一堆乱七八糟的，比如因为HTML清洗模块的性能炸弹、翻译模块的同类隐患、部署探活的缓存穿透假阳性的各种奇奇怪怪的BUG。 提前发现问题，提前解决，考虑到所有的情况，尽可能不让你的真实项目出现问题。 毕竟我也不懂代码，我就是个废物，我只能依赖AI来帮我进行Vibe Coding，而大家也懂，Vibe Coding出来的东西，漏洞也是真的多，如果你不提前把这些问题全都考虑到，直接扔到线上，那伤害的，就是你的用户了，那就是真正的事故了。 而对抗式审查，我强烈建议是，多开Agent进行对抗式审查。 比如Claude Code我现在就很喜欢说：“开启Ultracode（也就是动态工作流，会有N个Agent进行并发）来对之前开发的功能进行对抗式审查。” Codex也可以，直接就说开启多Agent帮我进行对抗性审查就可以了，它会自动开好几个Agent的。 极致且纯粹的攻防战。 自从用了对抗式审查之后，我对自己代码和项目的信心反而变的很强了。 写在最后 我现在除了日常的开发外，我也几乎现在是每2到3周，定期对整个项目进行全局性的从第一性原理出发的对抗式审查。 让Agent从最底层原理出发，去并发去审查架构、依赖关系、代码质量、文档对应等等，正好也可以用来去测试新模型的能力，也能整体review一下这两三周开发的功能，最好玩的是，每次都能挑出来之前没注意到的技术债和潜在风险。 特别有意思。 而且这些问题说实话，如果不主动去找，它们就会一直潜伏在那里，等到某天突然爆发。 作为一个纯粹的不懂代码的小白，这个纯粹用Vibe Coding方式做出来的AIHOT，最近一周的请求量就超过千万，Skill的调用量也远远超乎我的预期，是网页端的10倍以上，虽然偶尔出一些小BUG，但是能稳定的为这么多用户提供服务，我心里还是很自豪的。 而这两个Prompt，第一性原理和对抗性审查，居功甚伟。 而且说实话，我觉得这两个东西的应用范围，也真的远不止Vibe Coding，远不止代码。 它甚至是我们对待世界的处世哲学。 你写完一篇文章，可以让AI帮你对抗式审查，它可能会从逻辑漏洞、事实准确性、论证力度多个维度来挑毛病，比帮我看看这篇文章怎么样有用太多了。 你做完一个商业方案，让AI从第一性原理出发审视这个方案，它会剥掉你的所有假设，直接质问你的核心逻辑是否成立。 你甚至可以在做人生决策的时候用这两套思路。 比如，我要不要换工作，先从第一性原理想清楚自己到底想要什么，再用对抗式审查让AI专门找你思考中的盲点和你下意识回避的风险。 因为这两个Prompt的核心逻辑，从本质上来说，跟具体领域无关，只是在Vibe Coding领域格外好用。 第一性原理的核心就一句话，回到最根本的事实重新推导。 对抗式审查的核心也就一句话，你永远需要一个站在你对面的力量来告诉你，你可能是错的。 想想还挺浪漫的。 相信我。 这两种思维习惯一旦内化。 你用AI的水平，会有一个质的飞跃。

译卡兹克分享Vibe Coding两个必备技巧：①“从第一性原理出发”——强制AI回归问题本质，曾助其发现AIHOT海外信源抓取底层路由隐患并重构；②“对抗式审查”——让AI从恶意用户角度测试，曾找出OOM死循环、未来时间污染等隐蔽BUG。作者建议每2-3周全局对抗式审查。当前AIHOT每周请求量超千万，Skill调用量为网页端10倍以上。两个技巧适用于任何需要验证与创新的场景。

Berryxia.AI@berryxia · 3天前50

这几天一大批的Claude 账号被封，群里就有好几个人的号被封了，A社真的是不做人。 如果遇到被封号了，使用礼品卡之类充值的记得申请退款。 对了之前订阅过的Apple ID 还可以继续订阅其他新的Claude 账号。 话说，可以换Codex 就用Codex吧。

译近期大量 Claude 账号被封，用户反馈通过 App Store 礼品卡充值的可申请退款。引用推文显示已成功收到 125 美金退款，且同一 Apple ID 可重新订阅 Claude Pro（20 美金），但 Claude Max 版本封号风险最高。建议改用 Codex 替代。

Berryxia.AI@berryxia · 4天前72

真的 ，这一套东西搞成课程。 线下陪跑不得卖个万八千的，兄弟们。 看看行动力的时候了、姚老师居然都免费开源。 抄作业吧。不废话了。👇

译Berry Xia称赞@yaojingang（姚老师）将本可卖到上万元的GEO内容工程课程资料全部免费开源。资源包括：3份核心文档（操作手册、研究报告、实操教程）、2本推荐书籍、3篇学术论文；GEO改写提示词、改写Skill、单篇内容GEO特征标注演示；以及3个GitHub开源仓库（GEO Skills、GEOFlow、Meta skill）。所有资源通过链接直接获取，无需付费或陪跑课程。

Berryxia.AI@berryxia · 4天前17

我特么还真想成为那1%的人，可惜我也不知道😄

译99%的人不知道的Claude Code分屏功能。如果你是Claude Code桌面端用户，一定要看看。原推主感叹：我特么还真想成为那1%的人，可惜我也不知道😄

AYi@AYi_AInotes · 4天前67

现在用 Hermes 最聪明的做法，不是堆提示词，而是给它搭一个会自己复盘迭代的记忆循环， 越用越贴合你的工作习惯，能力拉满。 核心靠一份 [Memory.md](Memory.md)，跑「会话学习 - 记录沉淀 - 迭代优化」闭环，每次对话都承接过往经验，不再重复踩坑、反复重说偏好。 精准落地 4 步流程 1️⃣桌面新建 [Memory.md](Memory.md)，固定分层框架 ## 偏好 ## 更正 ## 模式 ## 学到的经验 2️⃣粘贴绑定提示词，接入代理 每次会话开始，阅读 [Memory.md](Memory.md) 并完整应用全部内容。 每项任务结束完成三件事： ・记录有效做法 + 核心原因 ・记录失败问题 + 根源分析 ・总结提炼下次复用规则，不重复堆砌条目，新结论覆盖旧内容 3️⃣每周执行精炼提示词压缩收敛 通读 [Memory.md](Memory.md)，提炼零散经验为精简通用规则，移除过时被覆盖内容，压缩留存高质量核心逻辑 4️⃣定期日期命名归档备份文件，避免改写出错丢失历史 不用微调模型、无需开发部署，几分钟就能启动运行。 从零散随机输出，慢慢收敛成贴合你的行文节奏、工作逻辑、纠错记录的专属智能代理，成倍放大日常效率。 收藏留存，立刻就能改造你的代理工作流，把单次会话的临时效果，变成长期滚动成长的核心资产。

译为用户提供不依赖微调或开发的Hermes代理优化方案：通过Memory.md文件构建“会话学习-记录沉淀-迭代优化”闭环。核心流程：1)桌面新建Memory.md，固定偏好、更正、模式、学到的经验四层框架；2)绑定提示词，每次会话前读取并完整应用，任务结束后记录有效做法与失败根因，新结论覆盖旧内容；3)每周精炼压缩零散经验为通用规则；4)定期日期命名归档备份。无需模型微调或部署，几分钟启动，使代理越用越贴合个人工作习惯，从单次随机输出收敛为专属智能体。

jason@jxnlco · 4天前64

http://x.com/i/article/2071134358359187456 # Two kinds of scheduled work in Codex You want Codex to do something later, or keep checking something until it changes. That sounds like one feature. It is actually two different kinds of work, and the difference is simple: - Scheduled Tasks create a new thread every time they run. - Scheduled Messages use the same existing thread every time they run. ## Use a Scheduled Task when every run can start fresh A Scheduled Task is best when the job makes sense without the conversation that created it. For example: Every morning at 9 AM, summarize what I need to catch up on from my email, calendar, and team messages. Tomorrow's summary does not need to remember today's summary. It needs the same instructions, current information, and a fresh place to report the result. ## Use a Scheduled Message when the next check needs the thread A Scheduled Message, sometimes called a thread automation or heartbeat automation, returns to the same existing thread each time it runs. For example: Check this PR every 30 minutes. If there are comments, address them and keep CI green. Stop when the PR merges. The next check depends on the work that already happened. The thread knows which PR you mean, which comments were addressed, what failed in CI, and what has changed since the last check. This is the right shape for: - polling for updates - checking for a status change - ongoing research or triage - work with a clear stopping condition The thread is the thing that connects the runs. ## Make your own loop skill Give Codex this prompt: Create a reusable loop skill for scheduled work. When I give it a request, first decide whether each run can start fresh or whether the next check needs the current thread's context. If each run can start fresh, help me create a Scheduled Task. If the next check needs the current thread, help me create a Scheduled Message. Infer what you can from the conversation. Ask only the missing questions that materially change the workflow: - What should Codex do each time? - How often should it run? - What change is important enough to report? - When should it stop? - When should it ask me for input? Then create the scheduled workflow with a short, durable prompt that will still make sense on a later run.

译Codex 支持两种计划工作方式。Scheduled Tasks 每次运行创建新线程，适合无需上下文延续的任务，如每日 9 点自动总结邮件、日历；Scheduled Messages 在同一现有线程反复运行，适合需要历史上下文的场景，如每 30 分钟检查 PR 状态并处理评论，直至合并。推文还给出创建可复用循环技能的提示词，让 Codex 自动判断使用哪种方式并引导用户填写关键参数。

Berryxia.AI@berryxia · 4天前56

Google Research在2024年悄悄开源了一个时间序列模型。 除了做预测的人，没人注意到。这是一个错误。 这个模型叫TimesFM。 论文发在ICML 2024，标题是"一个用于时间序列预测的解码器架构基础模型"。 核心思路直接借鉴语言模型：先在海量数据上预训练，然后用同一个模型预测任何新序列，不需要重新训练。 过去几十年，时间序列预测一直是一个数据集一套模型的模式。 你收集某个问题的数据，选一个模型架构。 在这个数据上训练，验证。如果问题变了，从头来过。 每个数据集都是一个独立项目。 每个场景都是一条独立流水线。 TimesFM改变了这件事，它在大量跨领域、跨频率的时间序列数据上预训练。 训练完成后，面对任何新的时间序列都能直接预测，零样本预测。 2025年9月，Google发布了2.5版本。 参数从500M降到200M，上下文从2048拉到16K。 加了一个30M的分位数预测头，能同时输出点预测和10%到90%的置信区间。 更小的模型。更长的上下文。 更好的结果。这很少见。 实际影响很具体，200M参数跑一张GPU就行。 16K上下文意味着你可以喂五年日数据，模型能抓住年度季节性。 分位数预测头意味着你不只有一个预测值，还有不确定性范围。 Google内部已经在用了。BigQuery ML里用SQL直接调。Google Sheets的Connected Sheets里内置了。Vertex AI提供了Docker端点。 开源版本免费，两行Python。 加载模型，调用forecast。输入numpy数组，输出预测结果。 2026年4月，Google加了通过HuggingFace Transformers和PEFT用LoRA微调的能力。 这意味着你可以用少量领域数据把预训练模型适配到你的具体场景。 时间序列预测不是一个光鲜的领域。没有病毒式传播的演示。没有十亿美元的消费产品。 但每个管理库存、预测需求、监控设备、交易金融工具的企业都依赖它。 TimesFM把这个行业最好的工具变成了pip install就能用的东西。 地址见评论区👇🏻

译Google Research 于2024年开源时序预测基础模型TimesFM（ICML 2024），采用预训练+零样本预测范式。2025年9月发布的2.5版本参数从500M降至200M，上下文窗口扩展至16K，新增30M分位数预测头，可同时输出点预测及10%-90%置信区间。200M参数单GPU可运行，16K上下文支持五年日数据。模型已内置在BigQuery ML、Google Sheets、Vertex AI中，开源版本通过pip install即可使用。2026年4月通过HuggingFace Transformers和PEFT支持LoRA微调，便于领域适配。

Tibo@thsottiaux · 4天前55

Talking to your plants isn't weird anymore. You can just codex things.

译OpenAI 发布 planttalk 构建指南，让植物拥有声音。 主推文评论：和植物对话不再奇怪，只需 codex 即可。

Rohan Paul@rohanpaul_ai · 5天前64

A Japanese dev spotted the trick: ask Claude Code to automatically Find Skills. Can match your goal to the right tool, using Vercel’s skills CLI across Claude, Codex, Cursor, and Gemini. so install skill like dev tools rather than rewritten by hand

译一位日本开发者发现了这个技巧：让Claude Code自动查找Skills。 可以跨Claude、Codex、Cursor和Gemini，使用Vercel的skills CLI将你的目标匹配到正确的工具。 所以像安装开发工具一样安装skill，而不是手动重写。

Berryxia.AI@berryxia · 5天前51

Claude Code用户你知道吗？ 你每天都在浪费一个功能！90%的都不知道！ Anthropic负责应用AI的负责人，刚做了一场2026年关于Agent记忆管理最实用的演讲 （晚点视频我更新到主页）。 他叫Lamis。 他和那些在前沿构建Agent的初创公司直接合作。 他拆解了Anthropic构建Agent记忆系统的完整方法论。 四层。 每一层解决了前一层的一个致命问题。 起点是一个Markdown文件。 他们在每次会话开头放一个CLAUDE.md文件，代码库结构。 组织信息，个人偏好，纯文本。 Anthropic的评价是"unreasonably effective"。 一个简单的文本文件，效果超过了复杂的Prompt工程方案。 但文件越来越长，上下文膨胀。会话空间不够。这条路撞墙了。 于是他们做了记忆工具。 让Agent自己决定什么时候读取、什么时候写入、什么时候更新记忆。 全部在带内完成，也就是在会话上下文中进行。 让他们意外的是：Agent判断什么值得记住的能力，比人类还强。自主性在这种场景下运作得非常好。 第三步是Skills。 核心思想是渐进式披露。Agent只看文件顶部几行前言，决定是否需要加载整个文件。 Lamis的比喻很精准，房间里有一个书架。有人跟我说法语，我扫一眼书名，找到法语词典，抽出来读。 不需要把七年的法语课都塞进脑子里。 第四步最简单。 他们把整个记忆系统建模为普通文件系统。Markdown文件。bash，grep。 不需要向量数据库。不需要专门的工具。Agent本来就擅长搜索文件。 但生产环境暴露了新问题。 多个Agent同时写入同一个记忆文件。 一个Agent往组织级上下文写入错误信息，所有Agent全部受影响。 记忆过时了怎么办。有人通过提示词注入向记忆中写入恶意内容怎么办。 Anthropic设计了四道防线。版本控制，能回滚。基于哈希的并发控制。权限分层，组织级只读，Agent草稿区可写。干净的API保证可移植性。 然后是最有意思的部分：做梦。 带内记忆有一个根本性局限。 Agent既要完成任务，又要管理记忆。两个竞争性目标。 而且Agent只能看到当前会话的信息，识别不了跨会话的模式。 做梦是一个带外的异步处理过程。 它取一段时间内的所有会话记录，交给一个专门的Agent分析。这个Agent查看记忆存储，识别模式，提出更改建议。 就像一个校长审查所有学生的作业。发现每个地理学生都在同一道题上答错。查了课程表，发现整个主题根本没有教。 做梦有自己的专用资源，不和任务执行竞争上下文。 Anthropic已经在生产中跑这套系统了。 Agent第二次执行同一个任务时表现更好。成本降低，因为能一次性完成。延迟下降。做梦消耗的额外token，被任务本身的效率提升抵消了。 Lamis最后说了一句话：模型智能本身不会产生复利。它需要上下文来执行你交给它的具体任务。 上下文工程的效果是倍增智能，即使模型本身变得更聪明，这个投资依然有价值。 这场演讲来自2026年AI DevCon。值得花半小时看看。

译Anthropic 应用 AI 负责人 Lamis 在 2026 年 AI DevCon 上介绍 Claude Code 记忆管理。起点是 CLAUDE.md 纯文本文件，但会上下文膨胀。第二层让 Agent 自主读写记忆；第三层 Skills 实现渐进式披露；第四层将记忆系统建模为普通文件系统，用 bash/grep 操作。生产环境设版本控制、哈希并发控制、权限分层和干净 API 四道防线。核心“做梦”机制是带外异步处理：专用 Agent 分析会话记录、识别模式并建议更改，已投入生产，能降低延迟和成本。

Berryxia.AI@berryxia · 5天前65

周末窝在家里，花半小时学习它吧！ 别光刷短视频， 看下Anthropic的上下文管理的视频！ 2026年AI DevCon上，Anthropic的Lamis做了一场关于上下文工程的演讲。 整场演讲浓缩了过去一年Anthropic在上下文管理上的所有实践，从最简单的方案到最前沿的架构。 从Claude MD文件开始。 一个纯Markdown文件，放在会话开头，告诉Agent代码库结构、组织信息、个人偏好。 效果出奇地好：Anthropic的原话是"unreasonably effective"。（效果惊人出奇的好） 但问题也明显：文件越来越长，上下文膨胀，管理困难。 第二步是记忆工具。 让Agent自主决定何时读取、何时写入、何时更新记忆。全部在带内完成，也就是在会话上下文中进行。 Anthropic发现，在这种场景下，自主性运作得非常好。Agent比人类更擅长判断什么值得记住。 第三步是Skills。 核心思想是渐进式披露。 Agent只看文件顶部几行前言，决定是否需要加载整个文件。 Lamis的比喻很精准：就像房间里有一个书架，每次有人跟我说话，我扫一眼书单，看有没有相关书籍，然后取下来读。 不需要提前把所有知识塞进上下文。 第四步是文件系统。 把记忆系统建模为普通文件系统，用Markdown文件填充，Agent用bash和grep搜索。 不需要花哨的向量数据库，不需要专门的工具——Agent本来就擅长操作文件系统。 但当这些方案扩展到生产环境，问题就来了。 多个Agent同时写入同一个记忆文件怎么办。一个Agent写入错误信息到组织级上下文，所有Agent都会受影响。记忆过时了怎么办。 有人通过提示词注入向记忆中写入恶意内容怎么办。 Anthropic给出的解决方案是四个原则：版本控制（能回滚）、并发控制（哈希校验）、权限管理（组织级只读、个人级可写）、可移植性（干净的API，跨系统访问）。 然后是最有意思的部分：做梦。 带内记忆有一个根本性局限：Agent既要完成任务，又要管理记忆，这是两个竞争性目标。 而且Agent只能看到当前会话的信息，无法识别跨会话的模式。 做梦是一个带外的异步处理过程。 它取一段时间内的所有会话记录，交给一个专门的Agent分析。 这个Agent查看记忆存储，识别模式，提出更改建议。比如：所有地理学生都答错了同一个问题:说明课程中缺少了某个主题。 所有数学考试的答案都用弧度制而不是角度制,说明工具配置有问题。 做梦本质上是一个批量处理的"校长"，审查所有"学生"的作业，发现问题，调整"课程"。 它有自己的专用资源，不和任务执行竞争上下文。 Anthropic已经在生产中运行这套系统。 他们发现：Agent第二次执行任务时做得更好，成本降低（因为能一次性完成），延迟下降。 做梦的额外token消耗被任务本身的效率提升抵消了。 最后Lamis说了一句话值得记住：上下文工程是过去一年才真正发展起来的领域。 模型智能本身不会产生复利:它需要上下文来执行你交给它的具体任务。 而上下文工程的效果是倍增智能，即使模型本身变得更聪明，这个投资依然有价值。

译在2026年AI DevCon上，Anthropic的Lamis介绍了上下文工程演进路径：从纯Markdown的Claude MD文件起步，到记忆工具（Agent自主读写）、Skills（渐进式披露）、文件系统（Markdown + bash/grep搜索）。生产环境中遇到并发写入、权限、注入等问题，通过版本控制、哈希校验、组织级只读/个人可写权限、可移植API解决。最后提出"做梦"——带外异步处理，由专门Agent分析跨会话模式并调整记忆。该机制已投产，可提升任务效率、降低延迟，额外token消耗被效率提升抵消。

AYi@AYi_AInotes · 5天前62

Cloudflare 上免费无限使用GLM 5.2的方法，冲！

译在Cloudflare Workers AI上配置GLM 5.2免费使用：登录后创建API Token，在Chatbox中设置OpenAI API兼容的自定义API，填入API Key和拼接了Account ID的Host地址，模型名选@cf/zai-org/glm-5.2即可。但实测每日有使用限制，并非真正无限。冲！

AYi@AYi_AInotes · 5天前73

终于有人把深度 Agent 的底层逻辑讲透了，不靠堆模型参数，通过三大工程化技巧直接解决长任务忘事崩链的问题。 LangChain 官方这套从零构建深度 Agent 的教程， 直接扒透了 Manus 和 Claude Code 这类顶级 Agent 的核心设计， 5 个渐进式 Notebook 手把手带你落地，全程可跑通。 核心就是三套上下文工程模式， 1. 结构化 TODO 任务规划，带状态管理，防止 Agent 跑偏漏步骤。 2. 虚拟文件系统卸载上下文，大幅省 token，实现跨轮次记忆。 3. 子代理委派加上下文隔离，复杂任务拆分并行，互不干扰。 从最基础的 ReAct 循环开始， 一步步叠加任务规划，文件系统，子代理能力， 最后直接搭出一个能联网做深度研究的完整 Agent。 不是那种纸上谈兵的理论，每一步都有可运行的代码。 本质上高级 Agent 的差距其实不在模型本身，主要在上下文工程的架构设计上。 想搞懂长周期 Agent 的朋友，跟着走一遍收获会很大， 配套还有开箱即用的 deepagents 生产库， 学完就能直接复用进自己的项目， 仓库链接放评论区了，推荐用 uv 管理依赖，跟着 Notebook 顺序跑就行。

译LangChain 官方发布深度 Agent 从零构建教程，通过三大上下文工程技巧解决长任务“忘事崩链”：1）结构化 TODO 带状态管理；2）虚拟文件系统省 token 实现跨轮记忆；3）子代理委派并隔离上下文。教程含 5 个渐进式 Notebook，从 ReAct 循环起步，逐步叠加规划、文件系统、子代理，最终搭建可联网深度研究 Agent。配套 deepagents 生产库可复用。强调高级 Agent 差距在上下文工程架构设计，而非模型本身。

宝玉@dotey · 5天前61

现在 Codex/Claude Code 的上下文压缩确实做的挺好了，加上 Prompt Caching，一个 Session 内持续聊没那么大成本压力了。我现在也越来越多的在一个会话内继续任务。 另外还有两个配套功能是很好的： 1. fork，就是从某一个对话位置开分支，只保留该对话前面的历史记录，让上下文更纯粹 2. /btw或者/side，在当前会话中提问，通常用于你想起来一件跟当前任务关系不大的事，没必要加入当前上下文中。 比如说使用 plan 模式时，你要回答一堆问题，但是这些问题选项说的不是很清楚你也不知道该选什么，这时候最适合用 /btw 让详细解释一下每个选项的意思，甚至还可以让它给你建议。

译@dotey 表示当前 Codex/Claude Code 的上下文压缩已做得很成熟，加上 Prompt Caching，单 session 内持续对话成本不高。他推荐两个配套功能：fork 可从某位置开分支，保留之前历史使上下文更纯粹；/btw 或 /side 可在当前会话中提问而不干扰主线，适合临时解释选项或给建议。引用 @reach_vb 称自 GPT 5.3 Codex 后不再担心上下文，Codex 能压缩并记住关键信息，还支持分支出新线程，这也是 /goal 命令有效的原因。

向阳乔木@vista8 · 5天前46

第二次GEO公开课直播的资料如下： 1、《GEO内容工程操作手册与评估标准》https://doc.laoyao.cn/9fl0bc 2、《GEO内容工程系统研究报告》https://doc.laoyao.cn/t754wa 3、《GEO 内容工程方法体系与单篇内容实操教程》https://doc.laoyao.cn/54yx5b 3、《系统之美》《人人都该懂的工程学》 4、《GEO: Generative Engine Optimization》https://doc.laoyao.cn/0elhy1 5、《Generative Engine Optimization in digital repositories: optimizing visibility for generative AI》https://doc.laoyao.cn/fnf30e 6、《A Measurement Framework for Generative Engine Optimization Across AI Search Platforms》https://doc.laoyao.cn/ykiktr 相关资源： 1、GEO改写提示词：https://ai.laoyao.cn/ylOfC 2、GEO改写Skill：https://ai.laoyao.cn/cqWRs 3、GEO单篇内容GEO特征标注演示：https://doc.laoyao.cn/00j3ps GEO系统与skill： 1、GEO Skills：https://github.com/yaojingang/yao-geo-skills 2、GEOFlow：https://github.com/yaojingang/GEOFlow 3、Meta skill：https://github.com/yaojingang/yao-meta-skill 课程PPT： https://ppt.qiaomu.ai/decks/geo-open-class-2-handout

译本周六晚8点，姚老师在WaytoAGI进行第二次GEO公开课，主题为“GEO内容工程”。直播资料包括三份核心文档（操作手册、研究报告、实操教程）、两本推荐图书（《系统之美》《人人都该懂的工程学》）及三篇GEO相关论文。相关资源有GEO改写提示词、改写Skill及单篇内容GEO特征标注演示。开源项目包括GEO Skills、GEOFlow、Meta skill的GitHub仓库及课程PPT。

Berryxia.AI@berryxia · 5天前66

这个包装成线下课，不得卖个9998 啊！ 这属于Codex 大集锦了，非常全面了～

译@gengdaJ 近日发布Codex玩法全集，涵盖变现、入门、记忆系统、Agent开发、工具集成、Computer Use实战及产品对比七大板块。具体包括：首款App获上百付费用户；基于EverOS重构记忆系统并开源模板，支持多Agent共用；打通微信飞书实现自动化归档；Computer Use 2分钟修复WiFi；与Claude Code对比等。该合集被评论可直接包装为9998元线下课程。

AYi@AYi_AInotes · 5天前57

现在用AI做视频可以跟喝水一样简单，不需要再付个700多块的剪映SVIP， 装这6个2026 年最顶的插件和skills就够了， 链接直接丢给你的AI Agent（Claude Code、Cursor、Hermes、OpenClaw 等等）让他们安装就， 老规矩6个安装链接🔗以及使用建议评论区自取⬇️

译推文指出，现在用AI做视频已变得极为简单，无需支付700多元的剪映SVIP。只需安装6个2026年最顶级的插件和Skills，提供安装链接，可直接交给AI Agent（如Claude Code、Cursor、Hermes、OpenClaw等）自动安装。具体链接和使用建议可在评论区自取。

歸藏(guizang.ai)@op7418 · 5天前38

用 Seedance 2.0 重新做了一下 Codepilot 的宣传片

AYi@AYi_AInotes · 5天前55

我们90%的人用Obsidian做知识管理，从根上就用错了。 存了一堆摘录PDF和高亮片段，手动加标签连双链，时间一长全是信息孤岛，图谱越铺越乱，最后要么彻底闲置，要么推倒重来。 Karpathy刚放出的这套LLM-WIKI思路，直接把整个逻辑反过来了。 人只负责筛选高质量原始资料，做最终判断。 剩下所有整理结构化，建链接，补更新，查矛盾的脏活，全交给AI。 核心是三层架构， 1️⃣原始层只增不改永远保留真相， 2️⃣知识层交给AI生成维护互相链接， 3️⃣规则层定义整套运行逻辑。 跟每次提问临时检索的RAG不一样，它是把资料一次性编译成有机的知识网络，让存量内容自己生长产生复利。 所以咱很多人总在找更厉害的笔记工具，但其实都没意识到，真正该升级的从来不是软件，而是人和AI的分工方式。 #知识管理 #AI效率 #Karpathy

译Karpathy LLM-WIKI反转逻辑：人只筛选高质量资料并做最终判断，AI负责整理、链接、更新等脏活。三层架构（原始层、知识层、规则层）将资料编译成有机知识网络，让存量内容生长复利。核心是升级人与AI的分工。

jason@jxnlco · 5天前60

Hey Codex, find everyone I've interacted with on Slack in the past 90 days and add them on LinkedIn.

译嘿 Codex，找到过去 90 天我在 Slack 上互动过的所有人，并在 LinkedIn 上添加他们。

jason@jxnlco · 5天前62

two skills that i love using if you use codex, press cmd+cmd ( left and right cmd buttons at the same time) and just say "make these two skills"

译两个我喜欢使用的技能 如果你使用 Codex，按下 cmd+cmd （同时按左右两个 cmd 键） 然后直接说"make these two skills"

OpenRouter@OpenRouter · 6天前49

In this OpenRouter MCP demo, your agent finds the best model at design: 1. Pulls the top design models from @DesignArena, live, through the MCP 2. Spins up three subagents - GLM-5.2, Opus 4.7, Kimi 2.6 - each designing a self-portrait as a webpage 3. Opens all three for you to compare side by side 4. You choose your favorite

译OpenRouter 通过 MCP demo 展示智能体实时拉取 DesignArena 的顶级设计模型，并启动三个子代理——GLM-5.2、Opus 4.7、Kimi 2.6——各自生成自画像网页，并排展示供用户挑选。引用推文点出普遍痛点：不同模型各有擅长，但逐一注册、加载凭证、重复跑提示词过于繁琐，致 99% 用户只跟风他人推荐。OpenRouter MCP 提供更便捷的对比方式。