歸藏(guizang.ai)@op7418 · 5月15日56

Codex CLI 设置 Chatgpt 远程控制

PixVerse@PixVerse_ · 5月15日49

This is what happens when PixVerse gets a press pass

译当PixVerse拿到媒体通行证时会发生什么 这些病毒式传播的球场镜头最有趣之处在于，它们有种随机的标志性感觉。 所以我用@PixVerse_重现了巴西对英格兰的SuperSport风格直播时刻，真实感简直离谱🔥 同一个世界，同一个目标。由PixVerse创作。⚽✨ #WEARE26 #PixVerseChallenge #FIFAWorldCup 📌查看下方提示👇🏾

歸藏(guizang.ai)@op7418 · 5月15日69

Codex 终于支持手机上的 ChatGPT 远程控制了！ 可以自动同步你绑定的 Codex 设备上的所有对话，而且可以直接发送指令、审批权限、监控进度。 我写一下设置的教程： 1. 点击桌面端 Codex 客户端左侧的“设置 Codex 移动版”，点击后系统会引导你开始设置。 2. 如果你的 ChatGPT 没有设置多重因素验证（MFA），系统会弹出网页要求你设置。这里推荐使用 Google Authenticator（谷歌身份验证器）App，不要用手机短信。 3. 系统会要求你使用手机 ChatGPT 客户端扫码。如果你直接打开手机端 App，它通常会弹出授权请求，直接点击允许即可，不扫码也是可以的。 4. 绑定完成后即可开始使用。你会在手机 ChatGPT 上看到一个 Codex 侧边栏，进去后能看到当前绑定的桌面端设备的所有 Codex 对话。你可以点击进入任意对话并发送命令让它执行。 注意：目前仅支持 Mac 版 Codex，Windows 版本还在开发中。 OpenAI 在封号上没有 Anthropic 那么激进和傻逼，所以你可以放心用。

译Codex现已支持通过手机上的ChatGPT应用进行远程控制，实现了跨设备对话同步与指令操作。用户需在桌面端Codex客户端内启动设置，并完成多重因素验证（推荐使用Google Authenticator）。绑定后，手机ChatGPT App将出现Codex侧边栏，可查看并控制已绑定桌面设备的所有对话，直接发送命令。目前该功能仅支持Mac版Codex，Windows版本仍在开发中。

Berryxia.AI@berryxia · 5月15日56

关于Claude 被封号，App store 礼品卡退款我说一下！ 再update一下后续： 我不知道过了几天收到了 退款， 我是朋友提醒前天去看了一下已经收到了125美金的退款。（图1） PS：我又用这个ID买了新的Claude Pro 号，不知道会如何，我再给大家反馈吧。 （图2） 顺利丝滑的买了20美金的会员。 为啥没买Max？ 因为封号的Max最多~

译用户因Claude账号被封，其通过App Store礼品卡支付的125美元Max档位订阅费未自动退款。通过拨打苹果400电话，提供Apple ID并转接至外区客服后，可选择网页自助或由客服手动提交退款申请，款项通常在48小时内原路退回。该用户已成功收到125美元退款，并已用同一Apple ID新购买了20美元的Claude Pro会员进行测试，但因Max档位封号情况较多而暂未再次订阅。

向阳乔木@vista8 · 5月15日73

如何在ChatGPT 客户端用Codex？ 很多人发新闻，就不发教程！其实配置稍微有点麻烦。 1. 更新Codex 本地客户端。 左侧会出现“设置 Codex 移动版”的入口。 注意！！！ 必须用官方订阅账号，API模式看不到这个入口。 2. 点击设置入口。 进去要求扫码，一定用苹果或安卓源生相机扫码。 （ChatGPT没找到扫码按钮，微信好像不行） 3. 登录ChatGPT账号（哪怕你App已登录账号） 4. 授权后搞定。 后续可改是否让电脑保持唤醒状态。 客户端下载地址见评论

译在ChatGPT客户端中使用Codex需先更新本地客户端，左侧会出现“设置 Codex 移动版”入口，但必须使用官方订阅账号，API模式无法显示。点击入口后，需用苹果或安卓原生相机扫码，ChatGPT应用内无扫码功能且微信不适用。接着登录ChatGPT账号，即使App已登录也需重新验证。授权后即可完成配置，后续可调整电脑保持唤醒状态的设置。客户端下载地址见评论。

Berryxia.AI@berryxia · 5月15日74

这个项目也可以直接 # 安装成 Claude Code skill 命令：violin --install-skill 以后就可以直接这样：violin input.mp4 output_zh.mp4 --language Chinese 大家需要注意： 去 http://api.together.ai 注册获取 Key（也支持 OpenAI、ElevenLabs，只需其中一个）。 Violin 默认使用 Together AI（免费注册可得额度），需要设置环境变量： # 永久生效，加到 ~/.zshrc echo 'export TOGETHER_API_KEY=你的key' >> ~/.zshrc source ~/.zshrc

译牛津大学博士后Kevin Lin开源了视频翻译工具Violin，可将视频自动进行语音识别、LLM翻译和语音合成，打破语言壁垒。工具支持个性化翻译风格，并能基于视频内容进行问答交互。它提供Web应用、CLI命令行及Agent Skill（如Claude Code skill）多种使用方式，默认利用Together AI的免费额度，也支持OpenAI等API。该项目旨在推动高质量视频内容的全球化传播。

向阳乔木@vista8 · 5月15日66

除 Github/Vercel/Cloudflare Cli 等开发工具。 最常用的就是飞书 Cli ，昨天看了眼 Github，居然已经 1w 多 Star 了。 强烈推荐安装，因为不少人的工作流起点是 Codex 和 Claude Code。 有了飞书 CLI，日常许多工作都能通过 AI Agent 串起来，比如： ① 让 AI 搜索调研整理资料，直接用 CLI 写入飞书文档。 ② 跟 AI 对话，让飞书 CLI 安排最近出差日程。 ③ 飞书开完会，直接CLI 读飞书妙记，写会议纪要、安排Todo。 安装指令：npx @larksuite/cli@latest install 以上只是个人Case，其实有更多最佳实践，不少玩法让我叹为观止，感兴趣的可以看这个文档 https://bytedance.larkoffice.com/wiki/ILuTww7Xcimb6GkhH0mcK2f4nS7

译飞书CLI工具在GitHub上已获超1万Star，成为连接AI工作流的关键工具。它允许用户将AI助手（如Codex和Claude Code）的产出直接整合到飞书生态中，实现自动化操作。典型应用包括：让AI搜索整理资料并自动写入飞书文档、通过对话安排出差日程、以及读取飞书妙记自动生成会议纪要和待办事项。该工具通过指令`npx @larksuite/cli@latest install`即可安装，官方文档提供了更多进阶使用案例。

ginobefun@hongming731 · 5月15日52

#BestBlogs 早报 2026-05-15 欢迎阅读BestBlogs 的今日早报，推荐阅读 Anthropic 关于 Claude Code 在大型代码库里的官方实践指南、OpenAI 关于 GPT-Realtime-2 的实现细节和开发演示视频，以及少楠关于大模型时代效率溢出之后的思考。

译本期早报重点推荐了三项内容。Anthropic发布了Claude Code在大型代码库中的官方实践指南。OpenAI则公开了GPT-Realtime-2的实现细节并提供了开发演示视频。此外，少楠探讨了在大模型时代，当效率大幅提升（效率溢出）之后所带来的深层思考。

ClaudeDevs@ClaudeDevs · 5月15日70

Useful tip to cut time-to-first-token on longer prompts in the API: pre-warm the prompt cache. Send your system prompt before the user prompt. Claude writes it to the cache, but skips generating any output. When the real user request lands, it'll hit a warm cache.

译减少API长提示首令牌生成时间的实用技巧：预热提示缓存。 在用户提示前发送系统提示。Claude会将其写入缓存，但跳过生成任何输出。 当真实用户请求到达时，将直接命中预热缓存。

AYi@AYi_AInotes · 5月15日69

做LLM生产落地的开发老哥们，可以看Andrew Ng刚出的这门课，免费版可以看所有视频和基础代码。 这个课程不是又一遍Attention is All You Need的数学推导， 也不是又一套调prompt的玄学技巧， 更不是又一个从零写Transformer的玩具项目，它直接把LLM的黑箱给你拆开了。 会让你亲手玩自回归循环， 看着模型一个token一个token生成，看着某一步概率采样走偏， 看着幻觉是怎么一步步从无到有长出来的。 甚至会让你拖动滑块调整temperature，实时看到输出多样性的变化， 看到不同的采样策略到底在改变什么。 以及让你点开每一层每一个注意力头， 看到哪个头在管语法， 哪个头在管事实， 哪个头在管逻辑推理。 最狠的是推理优化部分， 这是所有生产工程师每天都在踩的坑，慢推理，OOM，成本爆炸。 以前所有人都告诉你要换更大的GPU。要加更多的机器。 这门课告诉你， 70%以上的延迟根本不是参数量的问题，是内存带宽的问题，是注意力计算的问题。 量化，KV Cache，Flash Attention，投机解码， 每一个技巧都能让你的模型速度翻2到5倍，精度损失几乎可以忽略。 而且这次是和AMD深度合作，由AMD工程副总裁亲自主讲。 终于有一门课不是只讲CUDA了，终于有人开始讲硬件感知的优化了。 虽然会调用API的人已经满大街都是了，但能看穿模型内部。能诊断问题。能优化成本的人，才是未来三年最稀缺的。 我觉得这门课最大的价值，是它终于把Transformer从一个学术概念，变成了一个你可以摸得到，可以调试，可以优化的工程工具。

译吴恩达与AMD合作推出新课《Transformers in Practice》，旨在将Transformer从学术概念转化为可调试的工程工具。课程提供交互式可视化，让开发者深入模型内部，观察自回归生成、注意力头分工及幻觉产生过程。核心聚焦生产中的推理优化难题，指出大部分延迟源于内存带宽与注意力计算，而非参数量。课程将系统讲解量化、KV Cache、Flash Attention、投机解码等关键技术，以实现数倍速度提升且精度损失极小。其最大价值在于培养能诊断问题、优化成本的稀缺人才，弥补了仅关注CUDA而缺乏硬件感知优化的市场空白。

Alibaba Cloud@alibaba_cloud · 5月14日55

How can agent-based speech interaction become more stable and faster? 🚀 When concurrency rises, the message link can become the hidden bottleneck. See how RocketMQ LiteTopic enables stable, low-latency interaction at scale: https://int.alibabacloud.com/m/1000412958/

译如何让基于智能体的语音交互变得更稳定、更快速？🚀 当并发量上升时，消息链路可能成为隐藏瓶颈。了解 RocketMQ LiteTopic 如何实现大规模稳定低延迟交互： https://int.alibabacloud.com/m/1000412958/

Peter Steinberger 🦞@steipete · 5月14日70

Wrote a skill that runs codex /review in a loop until there's no booboos anymore. Caveat: It won't fix system architecture for ya, so you still need BRAIN as master model. https://github.com/steipete/agent-scripts/blob/main/skills/codex-review/SKILL.md

译编写了一个技能，可以循环运行codex /review直到没有错误为止。 注意事项：它不会为你修复系统架构，所以你仍然需要将BRAIN作为主模型。https://github.com/steipete/agent-scripts/blob/main/skills/codex-review/SKILL.md

Berryxia.AI@berryxia · 5月14日75

宝玉老师的微信CLI群聊来了！ 已经安装了，2步就给我搞定了真的方便。 我就复制了2次命令。

译宝玉基于卡比开发的wx-cli命令行工具，编写了一个微信群聊总结Skill。该工具通过解密本地微信数据库工作，安装简便，仅需几步命令即可自动总结指定群聊（如“AI产品蝗虫”）的当日消息。其优势在于无需关闭系统完整性保护（SIP），若运行报错，可将错误信息发送给AI代码助手寻求解决方案。相关项目源码已在GitHub开源。

Rohan Paul@rohanpaul_ai · 5月14日77

Qwen 3.6 27B on a MacBook Pro M5 Max 64GB hitting 34tokens per sec, locally with atomic[.]chat 90% acceptance rate, i.e. most draft tokens matched what the main model would have produced, so the speed gain is not from skipping quality checks, but from avoiding repeated full-cost decoding work. TurboQuant and GGUF handle the storage and runtime side: the model is compressed enough to run locally, while llama.cpp can feed Apple Silicon efficiently instead of waiting on huge weight movement. Pretty serious local-inference result, changes what “laptop AI” can feel like.

译近期，Qwen 3.6 27B大型语言模型通过TurboQuant技术被量化为GGUF格式，并整合Multi-Token Prediction技术。在配备M5 Max芯片和64GB内存的MacBook Pro上，该模型实现了每秒34个token的本地推理速度。高达90%的接受率表明，性能提升并非以牺牲输出质量为代价，而是通过避免重复的全成本解码工作来达成。同时，利用llama.cpp进行高效调用，进一步优化了运行效率。这一技术组合显著扩展了“笔记本电脑AI”的应用边界，使得在本地设备上流畅运行大型模型成为可能，提升了用户体验。

meng shao@shao__meng · 5月14日50

OpenAI 给 Codex 在 Windows 造了一个沙箱，过程比想象中曲折 ... 来自 Codex 团队 David Wiesen 非常有深度的技术博客，推荐阅读！ https://openai.com/index/building-codex-windows-sandbox/ 问题的起点：Windows 上的 Codex 没有沙箱 Codex 运行在开发者本地（CLI / IDE 扩展 / App），默认以当前用户身份执行命令——既能读写文件、跑测试、操作 Git，也意味着潜在风险。 macOS 有 Seatbelt，Linux 有 seccomp/bubblewrap，Windows 原生缺乏这种"按进程做强约束"的能力。结果 Windows 用户只能在两个糟糕方案中二选一： · 每条命令都审批（甚至读操作），打断流畅性； · 开启 Full Access，放弃所有约束。 团队的目标，是把 Codex 在 macOS/Linux 已有的"默认安全"体验搬到 Windows：只能在工作区内写、默认无网络访问，且全程不需要用户介入。 现成 Windows 方案为什么都不够用？ · AppContainer：是为"功能边界清晰的应用"设计的；Codex 要驱动 shell、Git、Python、构建工具等任意二进制，形状不对 · Windows Sandbox：它是隔离的"另一个桌面"，无法直接作用于用户的真实仓库；且 Windows Home 版根本没有 · Mandatory Integrity Control：把工作区标成 Low，等于让所有 Low 进程都能写入，宿主信任模型被破坏，副作用太大 第一版原型：「免提权沙箱」（Unelevated Sandbox） 设计原则：不弹 UAC、不要求管理员。需要解决两件事：限制文件写入 + 限制网络。 1. 文件写入：靠 SID + Write-Restricted Token 真正落地 · 合成 SID：Windows 允许创建一个不绑定真实用户、却能出现在 ACL 中的身份。Codex 为此造了一个专属的 sandbox-write SID。 · Write-Restricted Token：一种特殊进程令牌，写操作要双重放行——token 的真实用户身份有权限； token 的"受限 SID 列表"中至少一个 SID 也被授权。 把 sandbox-write SID 通过 ACL 授予： · 当前工作目录 · config.toml 里配置的 writable_roots 并显式拒绝其写入 .git / .codex / .agents。 → 这是真正的 OS 级写边界。 2. 网络访问：只能"劝退"，无法强制 Windows Firewall 必须管理员权限，于是只能做环境层面的软封锁： HTTPS_PROXY / ALL_PROXY / GIT_HTTPS_PROXY = http://127.0.0.1:9 GIT_SSH_COMMAND = cmd /c exit 1 外加在 PATH 前塞 denybin，让假的 ssh/scp 先被解析到。 效果：拦得住行为良好的工具；但凡自己实现网络栈、绕过 PATH、或直接开 socket 的程序——一律失效。仅是 advisory，挡不住对抗性代码。 改版关键：为什么必须接受"需要提权" 要让 Windows Firewall 真正生效，必须按"身份"匹配规则。但： · 防火墙规则不能匹配 restricted token 中的合成 SID； · 按 codex.exe 路径匹配，覆盖不到它派生的 Git/Python 等子进程； · 按用户匹配又会误伤真实用户本人； · 按端口/地址匹配是错的策略——目标不是封 443，而是封这一棵受限进程树的所有出站流量。 唯一的出路：让沙箱命令以"另一个 Windows 用户"的身份运行。这就必须放弃"免提权"约束。 最终方案：「提权沙箱」（Elevated Sandbox） 1. 引入两个本地用户 Codex 在安装时创建： · CodexSandboxOffline —— 防火墙规则全封； · CodexSandboxOnline —— 不被防火墙规则覆盖。 子进程依旧跑在带 [Everyone, Logon, Synthetic] 受限 SID 列表的 write-restricted token 下，但 token 的主体（principal）换成了沙箱用户，而不是真实用户。 5.2 一次性 setup 步骤（需要管理员） · 创建合成 SID； · 创建在线 / 离线沙箱用户； · 凭据用 DPAPI 加密存储，沙箱用户自己读不到； · 为 CodexSandboxOffline 创建"封禁所有出站"的防火墙规则； · 给沙箱用户补 读 ACL——因为新用户默认读不到其他用户的 profile、C:\Users、C:\Program Files 等常用目录。这一步耗时，异步执行，不阻塞用户。 5.3 为什么需要 codex-command-runner.exe 直觉的流程是： codex.exe → LogonUserW → CreateRestrictedToken → CreateProcessAsUserW(child) 但在 CreateProcessAsUserW 这一步存在特权墙：以"真实用户"身份是无法可靠地把进程以另一个用户的受限 token 拉起来的。 解法是把流程切成两段： Part 1（在真实用户侧） · codex.exe 用 CreateProcessWithLogonW 把 codex-command-runner.exe 以沙箱用户身份拉起（此时还不是受限 token）。 Part 2（已经在沙箱用户侧） · runner 用 OpenProcessToken 拿到自己的 token； · GetTokenInformation 取出 logon SID； · CreateRestrictedToken 构造最终受限 token； · CreateProcessAsUserW 拉起真正的子进程。 5.4 最终四层架构 · codex.exe —— 普通非提权的 harness； · codex-windows-sandbox-setup.exe —— 一次性的提权安装； · codex-command-runner.exe —— 在沙箱用户内造受限 token 并起子进程； · child process —— 真正受约束的命令。 拆成独立二进制的好处：codex.exe 在其他平台不被 Windows 专属逻辑污染；UAC 边界只在必要时跨越；setup 的长耗时与主进程生命周期解耦。

译OpenAI 为在 Windows 上实现 Codex 的“默认安全”体验，从免提权沙箱演进到提权沙箱。Windows 缺乏原生进程级约束，初期方案通过合成 SID 和 Write-Restricted Token 限制文件写入，但网络封锁只能依赖环境变量软拦截，无法强制生效。团队最终放弃免提权约束，转向创建独立本地用户（在线与离线沙箱用户），需一次性管理员权限安装并配置防火墙规则。通过引入 codex-command-runner.exe 作为中介，解决跨用户创建受限令牌进程的权限难题，形成四层架构，在保障安全的同时最小化对主流程的侵入。

向阳乔木@vista8 · 5月14日68

宝玉老师基于卡比的wx-cli写了一个微信群聊总结Skill。 安装成功，正在总结下AI产品蝗虫今天的消息。 wx-cli不错啊，解密本地的微信数据库，甚至连SIP都不用关，如果报错，可以发给Codex或Claude Code解就行。 卡比的Cli：https://github.com/jackwener/wx-cli 宝玉老师的Skill：https://github.com/JimLiu/baoyu-skills/tree/main/skills/baoyu-wechat-summary

译宝玉老师基于卡比开发的wx-cli工具，编写了一个自动总结微信群聊消息的Skill。该工具通过解密本地微信数据库获取聊天记录，无需关闭系统完整性保护。用户可对指定群聊当天的消息进行内容总结，若遇报错可借助AI编程助手解决。相关工具源代码已在GitHub开源。

宝玉@dotey · 5月14日80

baoyu-skills 新加了一个 Skill： 微信群聊总结 Skill：https://github.com/JimLiu/baoyu-skills/tree/main/skills/baoyu-wechat-summary 依赖于 wx-cli：https://github.com/jackwener/wx-cli 如何配置使用 wx-cli 请看项目文档，无法提供帮助。另外目前只是借助其读取数据，其他没任何关系。 Claude Code + Claude Opus 4.6 效果最佳

宝玉@dotey · 5月14日61

问：上下文（Context）和上下文窗口（Context Window）什么差别？ 这两个概念经常被混用，但其实指的是不同层面的东西： 上下文是指 AI Agent 在执行任务时实际拥有的所有信息，包括系统提示词、用户的对话历史、检索到的文档、工具调用的结果、记忆模块注入的内容等等。你可以把它理解为“Agent 此刻脑子里装的所有东西”。上下文是一个动态的、可以被工程化管理的概念——哪些信息该放进来、什么时候放、怎么组织，这就是现在越来越多人说的 Context Engineering。 上下文窗口则是模型层面的一个硬性限制，指的是模型单次推理能处理的最大 token 数量。比如 128K、200K、1M 这些数字，说的就是上下文窗口的大小。它本质上是一个“容器的容量”。 打个比方：上下文窗口是你厨房操作台的面积，上下文是你实际摆在台面上的食材、调料、菜谱和工具。台面就那么大（上下文窗口有上限），但你放什么上去、怎么摆放（上下文的管理）决定了你能不能高效做菜。 在 Agent 开发中，一个核心挑战就是：Agent 需要的上下文往往远超上下文窗口的容量。对话越来越长、工具调用结果越来越多、检索的文档越来越大——这些都在消耗上下文窗口的空间。所以才需要各种策略来管理：摘要压缩历史对话、选择性检索而不是全量灌入、及时清理不再需要的中间结果等等。 简单总结就是：上下文（Context）是“内容”，上下文窗口（Context Window）是“装内容的容器”。做 Agent 工程的核心功夫之一，就是在有限的“上下文窗口”里塞进最有价值的“上下文”。

译上下文是AI Agent执行任务时动态拥有的全部信息总和，包括系统提示、对话历史、检索文档等，其管理属于“Context Engineering”。上下文窗口则是模型单次推理能处理的最大token数量的硬性技术限制。两者关系如同厨房操作台面积与台上实际摆放的食材工具。开发中的核心挑战在于所需上下文常远超窗口容量，因此需通过摘要、选择性检索等策略，在有限窗口内高效管理最有价值的内容。

Berryxia.AI@berryxia · 5月14日79

我靠，肉眼都跟不上这个速度了！ Daniel Han，UnslothAI创始人，YC S24，之前在NVIDIA做ML，刚刚把Qwen3.6的实验MTP GGUF放出来了。 27B模型单GPU直接跑到140 tokens/s。 35B-A3B版本更猛，冲到220 tokens/s。 比原版GGUF快超过1.4倍，精度零损失。 他们测了半天，发现draft tokens设成2就是甜点，再往上接受率暴跌，实际速度反而掉下去。 我看完那张benchmark曲线图，最大的感受是，本地大模型的性能天花板又被狠狠顶高了一截。 以前总觉得30B+模型本地跑太慢，现在MTP投机解码直接把消费级显卡的潜力榨干了。 如果你在玩llama.cpp、跑本地Agent或者日常coding，这波更新必须马上试。 本地AI越来越不像“妥协版”了。

译UnslothAI创始人Daniel Han发布了实验性的Qwen3.6 MTP GGUF模型，显著提升了推理速度。其中，27B模型在单GPU上达到每秒140个token，35B-A3B版本更是高达每秒220个token，相比原版GGUF速度提升超过1.4倍且精度无损。关键优化在于将draft tokens设置为2，这是性能与接受率的最佳平衡点。这项MTP投机解码技术极大提升了消费级显卡运行大模型的效率，推动了本地AI的性能边界。

ginobefun@hongming731 · 5月14日72

使用 Claude 进行计算机和浏览器操作的最佳实践 Anthropic 针对 Claude 4.6 系列和 Opus 4.7 发布了 Computer Use 的官方最佳实践指南。如果你正在构建任何需要控制浏览器或桌面的 AI Agent，这篇是目前最权威的第一手资料。 核心问题是一个几乎所有人都踩过却不知道原因的坑。把截图发给 Computer Use API 的时候，API 有内部尺寸上限：Claude 4.6 系列是最长边不超过 1568 像素、总像素不超过 1.15 兆；Opus 4.7 是最长边不超过 2576 像素、总像素不超过 3.75 兆。超过上限之后，API 会在把图片交给模型之前静默压缩，但返回的坐标仍然是按原始分辨率计算的，结果就是点击位置系统性偏移。这个失败是静默的，没有任何报错提示，单纯表现为点击总是差那么一点。 解法直接：在发送截图之前，先在客户端把截图缩放到 1280x720（使用 Opus 4.7 可以从 1080p 起步）。这个分辨率既在两个限制之内，也是模型在训练中大量见过的标准分辨率，实测对现代 Web 界面和传统桌面应用都能良好支持。还有一个容易忽略的细节：macOS 上的截图默认是 2x 分辨率（Retina 屏幕），看起来正常但实际像素数是双倍，同样会触发压缩陷阱。 API 调用格式也有讲究：把文字指令放在截图之前（而不是之后）发送，模型先接收指令再处理图片，点击精度会有明显提升。 在模型选择上，Claude Sonnet 4.6 的机械点击精度更高，在需要大量降分辨率的场景下表现更稳；Opus 4.7 支持更高分辨率预算，点击精度差距大幅收窄，适合需要更多视觉信息量的复杂任务。多 Agent 组合方案可以让推理模型负责规划、让 Sonnet 或 Haiku 负责具体点击操作。 安全架构这部分原则非常清晰：任何 Computer Use 集成都必须运行在专用虚拟机或容器里，绝不能把有价值的主机数据暴露给 Agent 可以访问的范围。高风险操作（表单提交、文件删除、付款确认）应该设置人工确认门控，在 Agent 循环中暂停等待用户确认后再继续。 场景选型上，Browser Use（通过 Playwright 等 API 控制浏览器）适合结构化的 Web 任务，精度高、可靠性强；Computer Use（截图加点击控制整个屏幕）则适合没有结构化 API 可用的桌面应用、遗留系统或跨应用工作流。两种方式并不互斥，复杂任务可以组合使用。

译Anthropic发布了Claude计算机操作官方指南，核心解决了截图发送至API时因静默压缩导致的点击坐标偏移问题。关键在于客户端预先将截图缩放至1280x720等标准分辨率，并将指令置于截图前发送以提高精度。模型方面，Sonnet 4.6机械点击精度更高，Opus 4.7则支持更高分辨率。安全上必须在隔离环境中运行并设置高风险操作人工确认。Browser Use适合结构化Web任务，Computer Use则适用于桌面应用等非结构化场景。

ginobefun@hongming731 · 5月14日77

http://x.com/i/article/2054698692955996160 # BestBlogs 05.14 早报 · Claude Computer Use 最佳实践、Codex 沙箱安全与生产级 Agent 评估框架 在线阅读和收听早报：https://www.bestblogs.dev/explore/brief/2026-05-14 BestBlogs Pro 早鸟内测开放：你可以自定义订阅源、配置兴趣标签，每天获得一份属于自己的头条早报。欢迎抢先体验，并把反馈发回给我们：https://bestblogs.dev ## 导语 AI 智能体的工程化落地，今天这期带来三篇拿来就能用的深度实战。 Anthropic 和 OpenAI 分别给出了 Claude Computer Use 与 Codex 沙箱的第一手架构经验，直接回答生产环境最棘手的安全与性能问题。评估体系那篇则揭示了一个让人警醒的现实：基准测试 95% 准确率的 RAG Agent，上线后幻觉率可能高达 30%——测试集永远无法覆盖生产流量的真实分布。 速览部分有李想与罗永浩的 AI 转型深度对话、Shopify 从零构建多 Agent 系统的工程教训、Databricks 用精度换延迟的速率限制重构，以及快手电商搜索的生成式新框架。 今天是 2026 年 5 月 14 日，星期四，欢迎收听 BestBlogs EP56 早报。 ## 精讲一：使用 Claude 进行计算机和浏览器操作的最佳实践 来源：Claude Blog 如果你正在构建任何形式的桌面或浏览器自动化 Agent，这篇来自 Anthropic 的官方最佳实践指南是目前最权威的参考文档。它针对 Claude 4.6 系列（Opus 4.6、Sonnet 4.6、Haiku 4.5）和 Claude Opus 4.7 发布，覆盖了从分辨率配置、安全架构到场景取舍的完整生产经验。 点击不准的根本原因：坐标系偏移 许多开发者在构建 Computer Use 集成时遭遇点击落点系统性偏移，往往以为是模型能力问题，反复尝试提示工程优化却收效甚微。实际上，根本原因更底层、更隐蔽：截图超过 API 内部尺寸上限后会被静默下采样，但坐标系仍然按你指定的原始分辨率空间返回，导致模型点的地方和你的界面坐标对不上。 Claude 4.6 系列的 API 内部处理限制是：最长边不超过 1568 像素，总像素不超过 1.15 兆像素。Opus 4.7 支持更高分辨率：最长边不超过 2576 像素，总像素不超过 3.75 兆像素。超出任意一个限制都会触发内部下采样，进而引发坐标偏移。官方明确指出，这个单一修复的收益超过几乎所有其他优化手段。 推荐分辨率策略 对大多数场景，推荐从 1280×720 起步。这个分辨率使用约 80% 的像素预算，始终在两个限制之内，是模型训练期间见过的标准分辨率，对现代 Web UI 和传统桌面应用都能良好支持。 如果使用 Opus 4.7，建议从 1080p 起步，相比 720p 有明显的画质提升，同时保持 token 使用量和性能的合理平衡。 对于想最大化视觉信息量的开发者，文章还提供了「最大 API 适配」方案：按每张截图的原始宽高比动态计算最优分辨率，充分利用可用像素预算而不引入宽高比失真。这种方式在准确率上比固定 1280×720 略有提升，但实现稍复杂。 文章也给出了明确的「应当避免的分辨率」指导，帮助开发者排除高分辨率下的常见误区。 模型思考能力与任务复杂度 文章在内部测试了不同思考努力等级在端到端 UI 自动化任务上的表现，覆盖桌面应用、浏览器和跨应用工作流。测试结果印证了两个关键模式：Opus 4.7 在 OSWorld Verified 基准上表现优于整个 4.6 系列，高思考等级在复杂多步骤任务中的收益最为显著，而简单重复性任务则不一定需要开启高思考。这为开发者在成本和性能之间的取舍提供了实验依据。 安全架构：不容妥协的底线 文章在安全架构上的态度非常明确，提出了几条硬性原则： 任何 Computer Use 集成都必须在专用虚拟机或完全隔离的容器环境中运行，绝不能将包含敏感凭证、个人数据或业务数据的主机文件系统暴露在 Agent 可访问的范围内。Agent 循环中必须设置人工确认门控，对高风险操作——包括表单提交、文件删除、账号操作、支付相关流程——必须暂停等待人工确认，而不是让 Agent 自主完成。 这些原则背后的逻辑是：Computer Use Agent 本质上是在执行任意操作序列，攻击面远大于普通的 API 调用型 Agent。任何一次误操作都可能造成不可逆后果。 Browser Use 与 Computer Use 的场景取舍 文章对这两种模式提供了清晰的场景划分：Browser Use（通过 Playwright 等浏览器自动化 API 控制浏览器）适合结构化 Web 任务，API 层面的操作精度高、可靠性强、可重复；Computer Use（通过截图 + 点击控制整个屏幕）适合无 API 可用的桌面应用、遗留系统或需要跨多个应用的工作流。两者并不互斥，复杂任务可以组合使用——先用 Browser Use 完成可 API 化的部分，遇到需要截图感知的场景再切换到 Computer Use。 与今日其他内容的关联 这篇文章和精讲三的 Agent 评估框架有直接呼应。Computer Use 集成的准确率指标——点击精度、任务完成率、工具选择准确率——正是精讲三 12 项指标体系中「Agent 行为层」的典型评测对象。如果你在构建桌面自动化 Agent，建议两篇配合阅读：前者告诉你如何让 Agent 执行正确，后者告诉你如何度量 Agent 是否在正确执行。 ## 精讲二：在 Windows 上为 Codex 构建安全有效的沙箱 来源：OpenAI Blog 这篇文章来自一位 2025 年 9 月加入 Codex 工程团队的工程师，记录了他们如何在 Windows 平台上从零构建沙箱隔离方案的完整历程。文章的价值不只在于结论，更在于对失败方案的诚实记录——这些踩坑经验对所有需要在 Windows 上运行不完全受信代码的 Agent 系统都有直接参考价值。 背景：Windows 没有开箱即用的沙箱原语 在 Linux 上，seccomp 和 bubblewrap 提供了细粒度的系统调用过滤和命名空间隔离；在 macOS 上，Seatbelt（又名 sandbox-exec）可以通过 profile 文件精确控制进程的文件访问权限。这些工具让构建可靠的隔离环境变得相对直接。 Windows 没有类似的内置能力。Codex 在 Windows 上的默认模式是以真实用户权限运行，也就是说，如果用户能做某件事，Codex 就能做某件事——包括删除任意文件、修改系统配置、访问所有用户数据。在没有沙箱的情况下，用户只有两个糟糕的选择：批准几乎每一条命令（高频中断，失去自动化价值），或者开启完全访问模式（放弃监督）。 逐一评估现有方案及其不足 工程师先系统评估了 Windows 提供的现有工具： AppContainer 是 Windows 内置的应用沙箱机制，但其权限模型是为 Store 应用设计的，粒度过于粗放——要么完全隔离，要么保留所有用户权限，无法实现「允许读取任意位置、但只允许向指定目录写入」这种精细控制。 Windows Sandbox 本质上是一个轻量虚拟机，Home 版 Windows 不可用，并且每次启动都需要独立的虚拟机实例，资源消耗和启动时间都不适合作为每条命令的执行环境。 MIC（Mandatory Integrity Control）完整性标签 可以降低进程的信任级别，但调整整个工作区的完整性标签会改变所有访问该目录的进程的行为，对用户的正常工作流产生不可预期的副作用，风险难以控制。 最终方案：专属 SID + 写受限令牌 Codex 团队最终选择了自研方案，核心机制是两个 Windows 安全原语的组合： 第一步，为 Codex 创建一个专属的 Windows 用户账户，配套一个专属的安全标识符（SID）。这个 SID 不是系统中的任何现有用户，仅属于 Codex 沙箱进程。 第二步，使用 写受限令牌（write-restricted token）。Windows 的受限令牌机制在检查写操作权限时会执行双重校验：普通用户身份（令牌的所有者）必须有权限，且受限 SID 列表中至少有一个 SID 也被明确授权，写操作才会被允许。 通过对指定工作区目录设置 ACL（访问控制列表），授予 Codex 专属 SID 写入权限，对其他目录不授予，就实现了精确的文件系统隔离：Codex 可以读取几乎任意位置（维持工具的有效性），但只能向你的工作区目录写入。这整套机制在操作系统层面强制执行，无需进程树中的任何软件层面配合，也无需管理员权限。 迭代路径：从 advisory 到 enforce 文章诚实地记录了中间的失败尝试。早期版本曾尝试通过设置环境变量（NO_PROXY、GIT_SSH_COMMAND）来阻止网络访问，但进程可以直接忽略环境变量、绕过 PATH、或者直接打开套接字，advisory 约束无法真正阻止恶意行为。加入防火墙规则之后仍然是 advisory 级别。最终决定使用操作系统层面的强制隔离，这才提供了真正可靠的保证。 工程范式的通用性 这个「专属 SID + 写受限令牌 + ACL 白名单」的设计模式，对所有需要在 Windows 上运行不完全受信代码的系统都有参考价值：AI 编程工具、自动化测试框架、RPA 产品，乃至任何需要给用户提供「让 AI 帮你跑命令」能力的服务。文章清晰呈现了从需求分析、方案评估到工程实现的完整思路，是难得的 Windows 系统安全工程案例。 ## 精讲三：为生产级 AI 智能体构建评估框架：来自 100+ 次部署的 12 项指标体系 来源：Towards Data Science 这篇文章来自真实的生产教训，而不是理论框架。作者团队在为医疗行业客户部署 AI Agent 系统三个月后，被合规官问了一个无法回答的问题：「你如何知道你的 Agent 没有在幻觉患者症状？」当时他们有单元测试、集成测试、在 demo 数据集上表现漂亮的模型，但没有任何能够在生产环境度量幻觉率、上下文忠实度或工具选择准确率的框架。 这个缺口差点让整个项目夭折。六周后，他们补上了覆盖每条 Agent 响应、每次工具调用、每次检索操作的 12 项指标框架，合规团队签字通过，Agent 正式上线。此后经历 100+ 次企业级 Agent 部署，这套框架演变成了他们的标准交付物。 最值得警惕的数据点 在基准测试集上准确率达到 95% 的 RAG Agent，在真实生产流量上幻觉率可能高达 30%。 这个数字让很多人难以置信，但背后的逻辑简单而扎实：测试集是你精心构建的，覆盖了你认为重要的场景；而生产流量是用户真实发来的，措辞更多样、边界案例更密集、上下文更复杂。你的测试集永远无法覆盖生产流量的真实分布。没有生产级的评估框架，你只是在用基准分数给自己一个安全感幻觉。 12 项指标的四层结构 这 12 个指标按四个层次组织，每层各有侧重： 检索层（Retrieval）：上下文相关性，目标阈值 >0.85，衡量检索到的块是否与查询真正相关；召回率，>0.90，衡量是否把所有相关信息都检索到；精确率，>0.80，衡量排名靠前的块是否是最相关的；检索延迟，P95 <200ms，衡量检索速度是否影响整体体验。 生成层（Generation）：回答忠实度，>0.95，衡量模型的回答是否与检索到的上下文一致，这是防幻觉的核心指标；回答相关性，>0.90，衡量回答是否真正回应了用户的问题；幻觉率，<2%，衡量模型杜撰事实的频率。 Agent 行为层（Agent Behavior）：工具选择准确率，>0.92，衡量 Agent 是否在正确的场景调用了正确的工具；工具执行成功率，>0.98，衡量工具调用本身是否成功（区别于逻辑正确性）；多步骤连贯性，>0.85，衡量 Agent 在长任务中是否保持了逻辑一致性。 生产层（Production）：单次查询成本，典型值 <$0.05，用于成本控制和单位经济核算；P99 延迟，<3s，衡量最差情况下的响应速度是否在用户可接受范围内。 跳过任何一层都意味着盲区。跳过检索层指标，你不知道是不是因为召回率低导致回答质量差；跳过生成层指标，你不知道模型在什么场景下开始编造事实；跳过 Agent 行为层，你不知道 Agent 选错工具是不是系统性问题；跳过生产层，你不知道成本和延迟是否在可接受范围内。 三种典型的错误模式 模式一：「MVP 之后再补评估」。这是最常见也是代价最高的模式。等 MVP 上线之后，工程团队已经有了 UI、API、集成和用户，这时候再补评估基础设施通常需要 4-6 周。更麻烦的是，数据收集本身有延迟——你必须先有一定量的生产流量，才能开始建立基线、检测回归。这段空窗期里，用户已经在发送不可预期的查询，任何模型更新引发的回归可能要数天后才能被发现，信任损失往往已经无法挽回。 模式二：「准确率就够了」。测试集准确率是必要条件，但绝不是充分条件。一个 RAG Agent 可以在你的评估集上拿到 95% 的准确率，同时在生产流量上有 30% 的幻觉率——因为评估集是你选的、生产流量是用户给的，两者分布不同。没有忠实度、幻觉率和工具选择指标，你只是在盲飞。 模式三：「人工抽检就行」。每天 100 条查询时人工检查可行，这个方法在 10000 条时就会彻底崩溃。达到那个规模后，要么工程师因为重复审查而过劳，要么实际上已经在接受一个名存实亡的审查体系。自动化评估在超过每日几千条查询时就应该是标配，而不是可选项。 实践建议：从第一天就构建 文章最核心的行动建议是：在 MVP 上线之前就把评估框架搭好。这意味着在架构阶段就为每层指标的数据采集做好预留，而不是在系统上线后再反向插入。这和「测试先于代码」的 TDD 理念类似——先定义什么叫「正确」，再去实现。 如果已经在生产但没有评估框架，文章建议优先从幻觉率和工具选择准确率开始，这两个指标覆盖了最高频的故障模式，也最容易用自动化方式度量。 与今日主题的关联 这套框架和今天两篇精讲之间的关联非常紧密。精讲一 Computer Use 的点击准确率对应工具执行成功率，多步骤 UI 自动化对应多步骤连贯性；精讲二 Codex 沙箱的隔离机制直接影响工具执行成功率（沙箱失效 = 工具崩溃）。任何生产级 Agent 系统都需要同时具备「执行能力」和「评估能力」，两者缺一不可。 ## 速览 李想×罗永浩：通过 AI 技术，让普通人也过上富豪的生活 | 罗永浩的十字路口 理想汽车创始人李想在这期长达两小时的播客中，深入阐述了公司从传统车企向 AI 与具身智能公司转型的战略逻辑。新旗舰 SUV L9 Livis 搭载了自研马赫 M100 芯片，算力达到 2560 TOPS，以及全球首个完全体全线控底盘和 800V 主动式悬架系统。李想的核心判断是：自动驾驶不会显著影响购车需求，人形机器人是继汽车之后规模最大的硬件赛道，而 AI 技术的终极价值在于让普通人享受到此前只有富豪才能获得的服务质量——从专属管家到全天候健康顾问。播客还涉及 AI 时代顶级人才的标准、激进的组织调整、以及新能源车企出海的路径。对汽车行业 AI 转型方向感兴趣的读者，这是近期最有深度的一手资料。 从头构建多智能体系统学到的经验 | InfoQ Shopify 高级工程师 Paulo Arruda 分享了从零构建多 Agent 系统的完整历程。核心结论是：专注于特定领域的 Agent 远比通才型 Agent 更有效，为领域专家提供更好的工具比组建 AI 特种部队更实用。这个洞察和当下很多团队盲目追求「万能 Agent」的做法形成直接对比。文章以 Shopify 的 Hacker Culture 为背景，记录了从最初 LibreChat 内部工具到真正可用的多 Agent 系统的演进路径，是一份有现实温度的工程经验总结。 Databricks 的高性能速率限制：以精度换延迟 | ByteByteGo Newsletter 2023 年初，Databricks 的速率限制器基于 Envoy + Ratelimit Service + 单 Redis 实例架构，在 real-time model serving 上线后开始出现尾部延迟飙升、扩容失效、单点故障三个问题。重设计后，团队将计数器从 Redis 迁移到分片内存存储，并引入异步批量上报模式，将尾部延迟降低了十倍。代价是容忍约 5% 的精度超限——部分请求可能在配额刚好耗尽的瞬间被错误放行。这个取舍本身很有代表性：在高并发场景下，严格精度和低延迟往往不可兼得，选择哪个取决于业务场景的容忍度。文章配有架构演进图，适合分布式系统工程师收藏参考。 快手 OneSearch-V2：生成式搜索进入「懂你」时代 | 快手技术 快手电商搜索团队发布 OneSearch-V2，针对 V1 的三个核心瓶颈——复杂查询理解不足、用户潜在意图推理不足、奖励系统易过拟合——提出了系统性解决方案。关键创新是推理内化的自蒸馏：不引入额外参数，通过信息不对称的自蒸馏机制，将显式推理能力直接编码进模型权重，转化为「直觉」。系统已全量上线，在不增加任何推理成本的前提下，商品点击率提升 3.98%、买家数提升 2.07%、订单量提升 2.11%。搜索和推荐工程师值得深读论文部分，代码已开源。 让 AI Agent 感知浏览器渲染：为 Agent 构建前端验收 Harness | 百度 Geek 说 百度工程团队开发了基于 Chrome DevTools Protocol 的开源工具，让 Agent 能从路径、内容、视觉、交互、控制台、网络六个维度验证真实浏览器渲染结果，补上 AI 编程流水线「写完代码看不到效果」的盲点。核心洞察是：代码正确不等于界面正确——CSS cascade、运行时数据、异步状态共同决定了最终渲染，这些问题只有在浏览器里才能暴露。工具已开源，可通过 npx skills add hixuanxuan/browser-automation --skill visual-verify 安装，前端 AI 自动化团队可以直接参考。 Claude 付费计划将包含程序化调用月度专用额度 | ClaudeDevs 从 6 月 15 日起，付费版 Claude 计划将包含一个月度专用额度，覆盖通过 Agent SDK、claude -p 命令行工具、Claude Code GitHub Actions 以及基于 Agent SDK 构建的第三方应用的程序化调用。这实际上将程序化访问权限捆绑到了订阅模式中，开发者无需单独为 API 付费即可构建和部署自动化工作流。对于之前依赖订阅账号进行轻量级自动化的用户，需要关注额度上限细节。 五种多智能体架构类型：注意力才是真正的瓶颈 | 跨国串门儿计划 Factory 核心 Agent 框架负责人 Luke Alvoeiro 在 AI Engineer 的分享中，拆解了五种多 Agent 通信模式：委派、创作者 - 验证者、直接通信、协商和广播。他的核心判断是：今天的模型已经足够聪明，真正的工程瓶颈是人类的注意力带宽。Factory 的 Missions 系统通过三角色架构（编排者 - 工作者 - 验证者）和「验证合约」机制，实现了最长 16 天的自主任务执行——在编写任何代码之前先定义好与实现无关的正确性断言，从根本上阻断 Agent 系统跑偏的可能。克隆 Slack 的生产案例中，代码内测试占比 50%，覆盖率超过 90%。 ## 扩展阅读 积压队列的数学原理：面向队列恢复的容量规划 | InfoQ 用三阶段数学框架推导队列积压的形成、持续和恢复过程，将「需要多少超额容量才能在 N 分钟内消化积压」从经验估算变成可计算的工程问题。还分析了重试放大和级联积压两个高危模式。适合基础设施和平台工程师，特别是要做 SLA 容量规划的团队。 [AINews] 微调时代的终结 | Latent Space 围绕 OpenAI 弃用微调 API 展开的行业分析。核心论点是：对大多数 AI 工程师来说，提示工程、RAG 和专用推理栈已经能覆盖绝大多数需求，微调正在成为少数真正需要定制模型行为的顶尖应用的专属手段。想厘清「我的场景到底需不需要微调」的读者值得一读，文章给出了判断框架。 Browser Run：现已运行于 Cloudflare Containers，速度更快、扩展性更强 | The Cloudflare Blog Cloudflare 将 Browser Run 服务迁移到 Containers 平台，并发限制提升 4 倍（每分钟可启动 60 个浏览器、最多 120 个并发），Quick Action 响应速度提升超 50%。关键架构改动是将状态管理从 KV 迁移至 D1 和 Queues，文章有详细的性能数据对比。需要在云端运行无头浏览器的团队可以直接参考，改进已经上线，无需更改现有代码。 ## 今日阅读路径 时间有限的话，建议按以下顺序阅读： 第一优先：精讲三（Agent 评估框架） 这是今天最有普适价值的一篇。无论你在构建哪种 AI Agent，无论规模大小，在上线之前都需要有回答「你怎么知道它没有幻觉」这个问题的能力。12 项指标、四层结构，结合阈值参考值，是可以直接带回去用的框架。那个「基准 95% 准确率、生产 30% 幻觉率」的案例本身就值得每个 Agent 工程师认真对待。 第二优先：精讲一（Claude Computer Use 最佳实践） 如果你的 Agent 需要控制桌面或浏览器，这篇的分辨率配置和安全架构部分可以帮你避开 90% 的坑。特别是截图下采样导致坐标偏移这个问题，不读原文很难自己发现，修复也非常简单——在发送截图前主动下采样到 1280×720，这一个改动的收益超过绝大多数其他优化手段。 第三优先：速览中的 Shopify 多智能体经验 篇幅不长，但提供了一个反直觉的工程结论：专才 Agent 优于通才 Agent，为领域专家提供更好的工具比组建 AI 特种部队更有效。如果你正在做 Agent 系统的架构选型，这篇来自 Shopify 生产环境的结论值得认真对待。 精讲二（Codex Windows 沙箱）主要面向平台工程师和需要在 Windows 上部署 Agent 的团队，专业性强。如果你的部署目标平台是 Linux 或 macOS，可以跳过，但如果面向 Windows 用户，这篇是目前最完整的参考案例。

译BestBlogs早报聚焦AI智能体的工程化落地。Anthropic官方指南详解Claude Computer Use最佳实践，包括解决点击偏移的根本原因、推荐分辨率策略及必须采用虚拟机隔离与人工确认门控的安全原则。OpenAI工程师分享了为Codex构建Windows安全沙箱的历程，其最终方案通过专属安全标识符和写受限令牌，实现了操作系统层面的强制文件系统隔离。早报同时指出，基准测试优异的RAG Agent在生产环境中可能出现高达30%的幻觉率。

AYi@AYi_AInotes · 5月14日29

说实话，大多数人盯着孙宇晨那些奇葩故事—— 3000 万请巴菲特放鸽子、620 万美元吃掉一根香蕉、SEC 起诉、和特朗普家族互撕…… 觉得这就是一个流量怪人，仅此而已。 但你要是去翻一下他过去 10 年的公开投资清单，会有点尴尬。 2016 年他公开喊 90 后："别买房，去买比特币、英伟达、特斯拉、腾讯。" 那年所有人都在抢燕郊的房，那张清单被当成笑话。 十年过去，英伟达涨了大约 24000%，特斯拉 2683%。当年 1 万块买英伟达，今天是 240 万。 如果 2016 年按那张清单各押 20 万，光英伟达那一份，就是 4800 万。 而那年抢燕郊的人，现在房子可能还套着。 这还不是最反直觉的地方，2025 年 11 月，所有人冲存储冲得最凶的时候，他说了一句："短期缺芯片，长期缺能源，永远缺存储。" SNDK 当年最高涨了快 50 倍，HBM 订单排到 2028 年。 然后呢？所有人才开始追存储的时候，他已经转向了下一个判断——具身智能、无人机、空间计算、太空。 他自己 2025 年 8 月飞了一趟蓝色起源，35 岁，最年轻的华人商业宇航员。 我盯着这条时间线看了很久，越看越觉得，被骂得最凶的那个人，可能恰恰是 alpha 最高的那一个。 争议是他最好的烟雾弹。 大家忙着嘲笑他吃香蕉，他已经把仓位悄悄从信息世界，搬到了物理世界。过去 20 年，互联网改的是信息怎么流动——微信代替写信，淘宝代替赶集。 未来 20 年，AI 要改的是物理世界怎么运行——工厂里站着机器人，战场上飞着蜂群，月球上先落下来的可能是 AI 居民。 数字世界已经到顶了。 物理世界，才是下一张万亿级的大桌。 那个 2016 年喊大家别买房的年轻人，今天已经飞过了卡门线。 而我们大多数人，可能还在等下一个燕郊啊。

译孙宇晨以争议行为闻名，但其2016年公开推荐比特币、英伟达、特斯拉等资产，十年后涨幅惊人，展现超前投资眼光。他断言数字世界已到顶，未来转向物理世界，布局具身智能、无人机、空间计算、太空等领域。争议成为其高alpha投资的烟雾弹。类似地，在Claude中转站市场中，ccode.dev通过自研技术解决模型冒充问题，提供真实Claude Opus服务，确保稳定透明，体现了在噪音中识别真实价值的能力。

StepFun@StepFun_ai · 5月14日58

This is what building with Step 3.5 Flash on @gg_lemonade looks like — from prompts to a playable game loop in minutes

译用户通过@gg_lemonade平台使用Step 3.5 Flash模型，在几分钟内将简单的文本提示转化为一个可玩的Roblox游戏基础循环。过程包括创建计分收集系统、调整机制使收集物重生，以及对地图进行美化抛光。该体验被描述为非常有趣且对新手友好，展示了从提示到可交互游戏原型的快速迭代能力，并为进一步添加功能奠定了基础。

Orange AI@oran_ge · 5月14日47

最近终于把沉浸式翻译的方案换完了 陪读蛙+DeepSeek V4 Flash 用用看

Tibo@thsottiaux · 5月14日51

We are continuing to invest in making agents work better on Windows. Highly recommend reading David's engineering post on our unique approach to windows sandboxing for Codex: https://openai.com/index/building-codex-windows-sandbox/

译我们正持续投入以提升智能体在Windows上的表现。 强烈推荐阅读David关于Codex独特Windows沙盒方案的工程文章：https://openai.com/index/building-codex-windows-sandbox/

Kling AI@Kling_ai · 5月14日70

Another amazing write-up from @PJaccetturo! Check out the thread to learn more about this masterpiece from @Gossip_Goblin, using mostly Kling for its animation!

译又一篇来自@PJaccetturo的精彩解析！ 查看完整推文，了解@Gossip_Goblin这部主要使用Kling制作动画的杰作！

Luma@LumaLabsAI · 5月14日55

The packaging tells the story. Now let the product show it. Upload your design, apply it to the product, and let Luma Agents build every promo image from there. From concept to campaign ready in minutes. Take it further → http://lumalabs.ai/app

译包装讲述故事，现在让产品展示它。 上传您的设计，应用到产品上，然后让Luma Agents构建所有宣传图片。从概念到活动就绪，只需几分钟。 进一步了解 → http://lumalabs.ai/app

Krea@krea_ai · 5月14日61

great moodboards tutorial!

译很棒的情绪板制作教程！ [引用 @goo_vision]：使用Krea 2进行创作 🧵 第一步：建立情绪板。 不必强求填满全部250个图片位。 即使只有10-20张优质参考图，也足以确立坚实的视觉方向并产出优秀成果。

向阳乔木@vista8 · 5月13日59

http://x.com/i/article/2054577878822703104 # 产品经典书《启示录》解读，AI时代“加功能”的诱惑比以往任何时候都致命 昨天有网友让帮解读下《启示录》这本书。 借搜索和AI工具辅助，写了一篇AI时代重读《启示录》的解读，自己读了一遍，也有不少触动和启发。 内容大概一万三千字，汇集了三本书中的核心思想，内容如下： 有一个数字，在产品行业流传了将近二十年，没有人真正当回事，但所有人心里都知道它是真的： 九成的软件产品没能实现既定目标。 这不是哪家咨询公司编出来吓人的数字。 马蒂·卡根在《启示录》里用整本书解释这件事，他见过太多团队，聪明、努力、资金充裕，但结果一塌糊涂。 问题出在哪？不是执行力，不是团队不够聪明，不是市场不够大。 大多数产品失败，是因为在开发之前很久，方向就已经错了。 这本书2008年第一版，写的是硅谷顶级产品团队的方法论。 eBay、惠普、网景……卡根在这些公司工作过、观察过，然后把他认为最关键的东西写了下来。 豆瓣上这本书有将近五千条评论，是产品经理书单里几乎永远排在第一位的那本。 但我想说一件事：这本书读起来很顺，很多地方让你觉得"对对对，就是这样"，然后合上书，第二天继续写PRD，继续串行交接，继续开评审会。 读完没有任何改变，是因为你以为自己理解了，其实只是点了点头。 这篇文章试图做一件事：把这本书里真正有价值的东西，逐一拆开来说清楚。 ## 一、产品经理到底是做什么的 很多人入行做产品，做了两三年，说不清产品经理的核心职责是什么。 这不是他们的问题，是整个行业的问题，大多数公司对这个岗位的定义本来就是模糊的。 卡根给出了一个非常清晰的答案，只有两项： 评估产品机会，定义要开发的产品。 听起来简单，展开来说，这两件事里藏着很深的东西。 评估产品机会，意思是当一个产品创意出现在你面前，你要判断它值不值得做。 创意的来源很多，高管说"我们来做个这个功能"，销售说"客户有个需求你们得满足"，竞品上线了某个东西你们没有，用户在反馈里提了很多次某个诉求……面对这些来自四面八方的声音，产品经理的职责是过滤，是评估，是判断哪些值得做、哪些不值得做，而不是照单全收。 定义要开发的产品，意思是在决定要做某个东西之后，你要告诉团队做什么，但不是怎么做。 你要确定产品的价值、体验、发布标准，但技术方案是工程师的事，视觉设计是设计师的事，产品经理的职责是把"做什么"想清楚，留出空间让其他人发挥。 这两件事，加在一起，就是卡根所说的"产品探索"的核心。 但问题是，大多数公司的产品经理，花大量时间做的不是这两件事。 他们在盯进度，在写用户故事，在协调会议，在解答开发人员的各种问题，在跑上跑下确认需求，在处理各种来自不同部门的打断。 真正花在"评估机会"和"定义产品"上的时间，可能只有20%，甚至更少。 这不是个人效率问题，是岗位设计问题。 很多公司根本没有给产品经理留出做这两件事的时间和空间。 卡根还提到一个很多人没意识到的边界问题：产品经理不是项目经理，也不是产品营销经理。 这三个角色在中文互联网语境里经常被混用，但它们是完全不同的职能。 项目经理的核心任务是制订计划、跟踪进度、确保按时交付。 他关心的是"这件事能不能按时做完"，不是"这件事值不值得做"。 产品营销经理的核心任务是对外发布信息、培训销售队伍、定价、命名、推广。 他关心的是"怎么让市场知道这个产品"，不是"这个产品应该是什么"。 这三个角色分开来说都很清晰，但在实际公司里，常常被一个人兼任，或者职责边界模糊到没有人去认真追究。 结果就是，产品经理做了很多项目管理和营销配合的事，真正的产品定义工作没有人在认真做。 卡根的观点是：如果没有人在认真评估机会和定义产品，那么做得再好的项目管理和产品营销，也只是在高效地把一个错误的产品推向市场。 ## 二、机会评估：在动手之前，先把问题想清楚 知道了产品经理的核心职责，下一个问题就来了：怎么评估机会？ 卡根给了一个具体的框架，叫机会评估（Opportunity Assessment）。 他建议用几个关键问题来完成这个评估： - 这个产品要解决什么问题？ - 它解决的是谁的问题？ - 成功的判断标准是什么？ - 有没有更好的替代方案已经存在？ - 为什么现在是做这件事的时机？ - 公司为什么是做这件事的合适主体？ 这几个问题，读起来很基础，但真正逐一认真回答，会发现大多数产品创意在第二三个问题上就站不住脚了。 卡根强调，机会评估有一条铁律：只讨论待解决的问题，绝对不讨论解决方案。 这条规则背后有深意。 很多团队的会议是这样开的：有人提了一个创意，十分钟后，所有人已经在讨论怎么实现这个创意了。没有人追问这个问题本身是否成立，没有人质疑目标用户是否真实，没有人问成功的标准是什么。 把解决方案当成问题本身，是产品团队最常犯的错误之一。 一旦团队开始讨论"我们怎么做这个功能"，就很难再退回去讨论"我们是否应该做这件事"。 因为具体的方案会让人产生投入感，方案讨论得越深入，放弃的心理代价越大。 机会评估阶段就应该严格只讨论问题，把方案的讨论完全锁在门外。 还有一个微妙的地方：机会评估不是一个可以独自完成的工作。 它需要产品经理真正去接触用户、接触市场，而不是坐在办公室里想象用户会怎么想。 卡根后来在第二版里更加强调这一点，好的产品探索，必须建立在持续的用户接触上，而不是季度一次的用研报告。 豆瓣上一条高赞书评说得很直接：这本书最大的价值，是给了产品经理一个"拒绝权"，让你有足够的理论支撑去说"这个创意不值得做"。 有了"机会评估"这个框架，可以说"我们还没完成机会评估，先不进入方案"。 就成了一个可以在会议室里讲出来的句子。 ## 三、PRD的死穴：为什么文档无法替代原型 说到这里，必须谈产品行业里一个几乎所有人都知道是问题、但所有公司都还在用的东西：产品需求文档（简称PRD）。 PRD是什么？ 就是用文字、流程图、静态截图来描述一个产品应该是什么样子的文件。 几十页，甚至上百页，详细描述每一个功能点、每一个状态、每一个边界条件。 PRD本身不是坏东西，它的问题在于被用来做一件它根本做不了的事：验证产品是否真的有用。 你能用文字写清楚"点击这个按钮之后会出现一个弹窗，弹窗里有两个选项"，但你没办法用文字描述"用户看到这个弹窗之后会不会困惑，会不会点错，会不会直接关掉"。 动态的用户体验，文字描述不了。 更大的问题是：PRD无法用于真实用户测试。 你没办法把一份Word文档递给用户说"你来试试这个产品"，用户无法在文档上操作，你也看不到他们的真实反应。 这就导致了一种普遍的悲剧模式：团队花了三个月，按照PRD把产品开发出来，然后上线，才发现用户根本不知道某个核心功能怎么用，或者某个关键流程因为步骤太多用户直接放弃了。 此时想改，整个架构已经定型，牵一发动全身，代价极高。 > 卡根把这叫做"非常昂贵的原型"，你花了三个月时间和大量资金，最终只是验证了一个假设，这是对开发资源最大的浪费。 他的解决方案，是用高保真原型替代PRD。 高保真原型是什么？ 是可以点击、可以跳转、可以体验完整核心流程的交互稿，它不是最终产品，但它足够逼真，足以让用户在上面完成真实的操作，足以让工程师判断技术可行性，足以让整个团队看到他们在做什么。 在写第一行正式代码之前，先把高保真原型做出来，然后用它回答三个问题： 用户会不会用这个产品？用户喜不喜欢这个产品？工程师在现有技术条件下能不能做出来？ 三个问题都有明确答案了，再进入开发阶段。 这个顺序的改变，让所有的验证发生在代码之前，而不是在发布之后。 代价从三个月的开发资源降低到一两周的原型制作时间。 今天这个方案的执行成本比2008年低了一个数量级。 用Figma做高保真原型，一个设计师一周可以完成几乎任何复杂度的核心流程。 用Lovable或v0直接生成可交互的前端Demo，可能只需要几小时。"做原型来不及"这个说法从今以后站不住脚。 ## 四、怎么做用户测试：五个人够了 说到高保真原型，一个紧接着的问题是：怎么用它做用户测试？测多少用户？问什么问题？ 卡根推荐的方法，是"走廊测试"——不需要正式的用研实验室，不需要招募大量被试，就在走廊里或者咖啡馆里，找到目标用户，把原型放在他们面前，看他们怎么用。 尼尔森诺曼集团有一个著名的研究结论：找5个用户做可用性测试，能发现85%的可用性问题。 找更多用户，发现的新问题边际递减。 也就是说，用5个真实用户测试一个原型，成本低，但收获的信息已经足够。 做用户测试，有几个容易犯的错误： 第一个是告诉用户怎么操作。 用户拿到原型不知道怎么用，很多产品经理忍不住说"这里你可以点一下"。 一旦你开口提示，测试就失效了，你测的是有人提示后用户会不会用，不是用户会不会自然地找到这个功能。 第二个是问"你觉得这个设计好不好"。 这种问题得到的答案没有价值，因为用户不擅长评价设计，他们会说"还不错"，但他们可能在操作中完全走错了方向。 正确的方式是给用户一个任务："假设你要完成XX，你会怎么做？"然后观察，不要打断。 第三个是只找技术爱好者做测试。 技术爱好者愿意尝试新东西，对产品不成熟有更高的容忍度，他们能帮你发现很多Bug和可用性问题，但他们的使用行为不代表主流用户。 判断产品有没有真实市场，必须找那些被具体痛点折磨、正在主动寻找解决方案的普通用户。 第四个是测试完发现了问题却不改。 用户测试的价值在于发现问题，发现问题之后修改原型，然后再测，这个循环必须转起来。 很多团队做了用户测试，然后把报告放在文件夹里，继续按原来的方向开发，测试形同虚设。 卡根特别提到了一种用户类型：特约用户。 这是一批被你明确招募进来、愿意提前参与原型测试的目标用户，大概6到15个。 他们不是付费用户，而是合作伙伴，你把最早期的想法和原型给他们，他们给你真实反馈。 这样的关系比随机找用户测试深度大得多，而且他们往往在产品正式上线后会成为第一批真正的口碑传播者，因为他们亲历了产品从粗糙到成型的过程，有一种参与感和认同感。 在可行性验证这一端，卡根主张在原型阶段就把架构师或主程序员拉进来。 产品经理常犯的错误是完成了原型，直接扔给开发团队，认为可行性是开发的事。 但如果某个功能在技术上根本行不通，越晚发现代价越高。 最好的时机是原型阶段，此时改动成本最低。 工程师看了原型，可以直接指出"这里响应速度会不够"，"这个功能需要第三方API，存在合规风险"，产品团队可以立刻调整方向。 ## 五、三角共创：不是三道工序，是同一个过程 说完了产品探索本身，来说说谁来做这件事。 传统的产品开发流程是串行的：产品经理写完需求，扔给设计师，设计师出完图，扔给工程师，工程师写完代码，扔给测试，测试完发布。 每个环节是独立的，交接像接力赛。 这个模式的问题，不只是效率低，而是它把三个本来应该相互依存的角色，变成了三道独立的工序。 卡根的主张是，产品经理、交互设计师、软件架构师（或主程序员），这三个角色，应该从一开始就紧密协作，互相渗透。 他称这三人组合为"产品铁三角"。 为什么设计师必须在早期就参与？ 因为产品的交互方式会直接影响产品能解决什么问题，以及用户体验的质量。 如果产品经理先把功能需求定死，设计师只是在这个框架里填图，很多好的设计可能性就被排除了。 设计师早期参与，他们能提出一些产品经理没有想到的交互方案，有时候这些方案可以让同样的功能变得更直觉，更容易上手。 为什么工程师必须在早期就参与？ 因为可行性不是最后才考虑的问题。设计师做了一个很漂亮的交互，产品经理很兴奋，进入开发才发现实现这个交互需要额外两个月，或者性能上根本跑不起来。 工程师在原型阶段就介入，可以在成本最低的时候给出可行性判断，帮团队避开这些雷区。 三角共创的具体运作是什么样的？ 不是每周开一次碰头会，而是持续的、非正式的密集协作。 设计师在探索交互方案的时候，随时可以找产品经理确认方向，可以找工程师问技术限制。 工程师写代码遇到理解不确定的地方，不是等到下次会议，而是直接走过去问产品或设计。 原型在持续迭代，三方都在看最新版本，都对现在的方向有共同理解。 Teresa Torres在她的书《持续发现习惯》里，把这种协作方式叫"产品三角"，并且给出了更具体的描述： - 产品三角里，产品经理是战略思考者，负责统合用户需求与商业目标； - 设计师是体验设计者，负责打造用户理解和喜爱的方案； - 工程师是技术实现者，了解什么在现阶段可行。 三者的分工不是流水线上的先后顺序，而是对同一件事的不同角度，必须同时在场。 高保真原型，在这种协作里扮演的角色是"共同语言"。 三个背景不同、思维方式不同的人，对着同一个看得见能点击的东西讨论，比对着文字理解彼此意思要高效得多。产品原型是三角共创的载体，没有原型的三角协作，效果大打折扣。 卡根还提到了一个关于节奏的建议：产品经理和设计师的工作进度，应该比开发团队领先一到两个迭代周期。 也就是说，当开发在做当前周期的功能时，产品和设计应该已经在探索下一个或下下一个迭代的方向了。 这样工程师拿到的永远是已经过测试和验证的方案，不需要在开发中等待决策。 ## 六、功能工厂：一个让团队越忙越糟糕的陷阱 说到这里，必须谈《启示录》里另一个被反复提及的概念：功能工厂（需避免）。 什么叫功能工厂？ 就是一个团队把"持续输出功能"当成工作目标。路线图上永远有排不完的需求，团队永远在开发，产品越来越大，功能越来越多，但用户留存没有改善，核心商业指标没有上升，甚至因为产品太复杂，用户越来越难用。 这个模式普遍到令人沮丧。 功能工厂是怎么形成的？ 一是管理层对"进度"的焦虑。 产品开发有很强的不确定性，不确定让管理层不舒服，于是他们用"我们这周上线了什么"来代替"我们解决了什么问题"作为进度指标。 每周都要有功能上线，团队自然变成了功能生产线。 另外是客户和销售的压力。 客户说"你们如果有XX功能我就续费"，销售说"竞品有这个你们没有"，这些声音在短期内都指向一个方向：加功能。 但每次妥协，团队就离真正的通用产品方向更远一步。 最后一个是产品经理自己的问题。 有些产品经理对创造的热情高于对问题的专注，喜欢提新功能，喜欢看到自己的想法变成现实，但对功能上线之后用户是否真的在用、真的有价值，缺乏持续追踪的意愿。 功能工厂最危险的地方，是它看起来很像在努力工作。 团队很忙，每个人都在做事，每周都有发布，路线图上每个季度都在推进。 但如果你去看真正重要的指标，比如周活跃用户数、30天留存率、核心流程完成率，这些数字没有在动。 卡根给出的解法，是把注意力从"我们做了什么"转移到"我们解决了什么问题"。 路线图不应该是功能列表，而是要解决的问题清单。 每个项目的成功标准，应该在开始之前就定义清楚，而不是上线之后回头解释。 具体操作上，卡根建议用数据找到用户流失的关键节点，比如注册流程有五个步骤，发现大量用户在第三步放弃了，那么下一个迭代的重点就是优化第三步，而不是加新功能。 这种聚焦，和功能工厂的思维完全不同。 在AI时代，功能工厂陷阱升级了。 当AI工具能帮你在两小时内实现一个新功能，"加一个新功能"的门槛更低，诱惑更大，团队更容易陷入"高产出、低价值"的循环。 Nikhyl Singhal，曾任Meta和Google产品领导者，有一个观察放在这里很准确：AI让项目的前10%几乎免费，探索、原型、生成备选方案都变容易了，但最后10%的精致度、稳定性和规模化依然一样难。 这意味着现在最危险的处境，不是团队做不到，而是团队做了太多没必要做的事。 ## 七、七大死亡陷阱：扼杀产品创新的组织模式 《启示录》里有一章我认为每个产品从业者都应该背下来，就是卡根列出的那些会系统性扼杀创新的组织模式。 这些模式不是某一家公司才有的问题，而是在绝大多数公司里以不同形式出现的通病。 第一种：依赖冗长PRD，把文档当成产品定义的主要工具。 上一节已经说过PRD的问题。 在这里补充一点：冗长的PRD还有一个副作用，就是它制造了一种"工作已经完成"的错觉。 当一份50页的文档写完，所有人都会觉得"我们想清楚了"，但这份文档从来没有被真实用户验证过，从来没有被工程师认真评估过可行性，只是思考的产物被打印了下来。 第二种：妥协于大客户的"特例产品"需求。 这是一个非常经典的陷阱，尤其在早期阶段。 销售带来一个大客户，对方愿意付一笔不错的钱，但条件是产品必须增加某些他们特定的功能。 管理层一看，钱到手的机会，说干就干。 这样的事发生一次，两次，慢慢地，产品里有越来越多只服务少数特定客户的功能，这些功能被合同锁死，每次版本迭代都要做兼容测试，代码越来越复杂，维护成本越来越高。 同时，用于大众市场的通用功能探索越来越少，因为团队的资源被这些特例需求占据了。 卡根说，这条路的终点，是把自己变成一家定制软件公司，失去了做通用产品的能力。 第三种：把产品管理部门归属于开发部或市场部。 产品管理放在开发部下面，产品经理很容易被技术细节和执行要求淹没，没有时间和空间做真正的市场探索和机会评估。 产品管理放在市场部下面，产品管理和产品营销会被混淆，产品经理花大量时间做对外宣传相关的事，产品的核心定义工作被忽视。 卡根的建议是，产品管理应该是一个独立的职能部门，和开发部、市场部平级，直接向高层汇报。 这在组织架构上给了产品探索应有的地位和资源。 第四种：瀑布式串行开发，设计后置。 产品先写完所有需求，再把设计工作开始，设计完了再开始开发。每个阶段结束，交接，进入下一阶段。 这种模式的问题上面已经讲过：设计介入太晚，一旦进入开发，修改设计的成本极高；工程师只能被动接受，无法在早期影响产品方向；整个流程缺乏验证环节，错误会一直传到发布才被发现。 第五种：闭门造车，没有真实用户验证的"产品发现"。 这个模式比功能工厂更隐蔽，也更危险。 团队并不是不做产品发现，他们也在讨论用户，也在分析数据，也在做内部评审——但所有这些都是在团队内部完成的，没有真实用户参与。 等到产品做出来了，才去测试，才去收集用户反馈。 此时如果发现大问题，已经太晚，产品的基础架构已经固定，根本性的改变不可能了。 第六种：把产品管理等同于项目管理。 没有专职的产品经理，由项目经理兼任产品职责，或者反过来，产品经理花大量时间做项目管理的事。 项目管理的核心是确保按计划交付，产品管理的核心是确保做了正确的事。 这是两种完全不同的思维方式，长期混淆会让团队变成一个"按时交付错误产品"的机器。 第七种：一味追加功能的"功能工厂"心态。 上一节已经详细说过，不再重复，但值得在这里强调：这是一个可以摧毁好产品的慢性病，危险在于它的破坏性是隐性的，你会在功能越做越多的过程中感觉良好，但核心指标在缓慢下降。 这七种模式，在不同的公司里有不同的组合。 有些公司同时中了三四种，有些公司只有一两种，但任何一种单独存在，都足以让一个有才华的团队做出一个让用户失望的产品。 ## 八、"授权团队"vs"功能团队"：卡根后来说得更清楚了 卡根在《启示录》之后，又写了一本书叫《赋能》，这两本书合在一起，构成了他完整的产品哲学。 《赋能》里引入了一个在他看来是产品工作核心矛盾的概念：功能团队和授权团队的区别。 功能团队是什么样的？ 团队的工作来自路线图，路线图来自管理层或销售，团队的任务是把路线图上的功能做出来，做得又快又好。 他们被"交付的是功能"，问题是，交付的功能是不是真的解决了用户的问题，团队不负责回答这个问题。 授权团队是什么样的？ 团队被"交付的是问题"。 管理层告诉团队，我们想提高三个月用户留存，但怎么提高，由团队来探索和决定。 团队对问题的解决方案有自主权，他们需要用自己的判断去探索最好的方案，而不是等待上级给出功能清单。 卡根认为，大多数公司是功能团队，但真正做出优秀产品的公司，是授权团队。 Amazon、Netflix、Stripe，这些公司的产品团队拿到的是目标，而不是功能列表。 他们对自己负责的业务区域有深度理解，有足够的自主权去探索解决方案，也需要对结果负责，而不是只对交付负责。 这个转变的难点在于管理层。 功能团队的存在，很大程度上是因为管理层不相信团队有足够的判断力，所以用功能清单来控制方向。 要转向授权团队，需要管理层在"确定性"和"自主权"之间做一个艰难的取舍。 卡根给产品评审委员会（Product Council）的设计，正是为了解决这个矛盾。 他建议大公司由关键部门高管组成产品评审委员会，人数控制在十人以内，只在四个关键节点做决策：评估机会是否值得投入，批准进入原型阶段，批准进入正式开发，批准发布。 这四个节点之间，产品团队有完全的自主权，管理层不介入具体方案。 这样既保证了管理层对方向的掌控感，又给了团队应有的探索空间。 ## 九、二十年后，这本书有哪些地方是错的或过时的 说了这么多书里正确的东西，现在来说说它的问题。 这是《启示录》值得真正研究的地方：即使是一本好书，也有它的时代局限，读者有责任自己分辨。 第一个局限：书里的成功案例，几乎全来自美国大公司。 eBay、惠普、网景，这些公司的产品模式，是在特定的资源禀赋、市场环境和组织文化下形成的。 把这套方法论直接搬到一家资源有限的早期创业公司，或者搬到组织文化完全不同的中国互联网公司，需要大量的本土化翻译，而书里没有给出这个翻译的框架。 Reddit上有一个很有意思的讨论，有人问"谁真的读过《启示录》"，高赞回复说：这本书讲的是产品经理"应该"怎么做，但现实生活远比理想复杂，产品管理是一个很模糊的工作，在大多数公司里，推动改变比学方法论难得多。 这个批评是准确的。 书里描述的是一个理想状态，真正的挑战是在一个不理想的组织里，怎么逐步往这个方向推。 第二个局限：对用户研究的深度不够，缺少可操作的节奏框架。 卡根强调要做产品探索，要做原型测试，要接触真实用户，这些方向都是对的。 但书里缺少一个具体的、可以每周执行的用户研究系统。 什么时候做用户访谈？怎么找用户？访谈用什么结构？结果怎么转化为产品决策？ 这些操作层面的问题，在2008年的版本里几乎没有答案。 Teresa Torres后来专门写了《持续发现习惯》来填补这个缺口，后面会详细说。 第三个局限：对AI时代的产品特殊性完全没有覆盖。 2008年的产品，功能边界是清晰的，用户体验是可预测的，系统行为是确定的。 AI产品不是这样：大模型的输出是概率性的，存在幻觉，响应延迟不可控，调用成本会随用户规模急剧上升。 这些特性，完全改变了可行性评估的内容，也改变了用户测试的方法。 卡根在2025年的采访和写作里，开始谈AI对产品团队的影响，但核心书籍还没有完全覆盖这个维度，需要读者自行补充。 第四个局限：对中国本土市场的特殊性无能为力。 中国互联网产品有很多在硅谷语境下不存在的约束：监管合规要求、流量获取逻辑、用户行为差异、微信生态的特殊性。 书里的很多建议，在这些背景下需要重新判断是否适用。 ## 十、AI时代的产品发现：必须自己补上的四个维度 上面讲了书里没有的东西，现在来说AI时代的产品团队具体要补什么。 第一个：可行性评估必须升级为"算力经济学评估"。 传统软件的可行性问题是：这个功能技术上能不能实现？对于确定性系统，这个问题通常有清晰的答案。 AI产品要多问一些问题： - 大模型的响应延迟是多少？主流用户能接受等3秒吗？如果某个核心功能需要5秒以上，用户流失会有多严重？ - 这个应用场景的幻觉率是多少？如果大模型有5%的概率给出明显错误的输出，对这个应用来说是可接受的边界误差，还是会摧毁用户信任的灾难？ - 每次API调用的成本是多少？乘以预期的用户规模和使用频率，商业模型能不能跑通？ - 合规风险在哪里？内容安全、数据隐私、各垂直行业的监管要求，是否已经在产品设计阶段就考虑进去？ 这几个个问题，在原型阶段就要拉入主程序员认真评估，而不是留到开发完成再发现问题。 第二个：用技术爱好者测Bug，用真实用户测价值。 卡根对技术爱好者的警惕，在成熟市场是准确的。 但中国AI早期，情况有所不同。 技术爱好者的价值在于：他们愿意忍受产品的不成熟，有能力理解新技术的运作原理，能提出有深度的Bug报告，是早期阶段最高效的产品测试者。 你完全可以把他们当做"高级测试团队"来用。 但判断产品有没有真实市场，必须去找那些被具体痛点折磨、已经在主动搜索解决方案的普通用户。 他们不关心底层技术是大模型还是规则引擎，他们只关心自己的问题有没有被解决。 这两类用户的反馈，要分开处理，分开权重，不能混在一起评估。 第三个：AI创业的极简起步阵型。 卡根在书里提到，创业公司初期最高效的配置是三人组合：产品经理、交互设计师、原型工程师，专注于产品探索，方向验证清楚再扩张团队。 这个建议在2025年的AI创业环境里更加有力。 一个会用大模型的工程师，可以在几小时内搭出一个功能级Demo，一个懂AI产品的设计师可以快速迭代原型，三个人可以在一两个月内完成从想法到"有人真的愿意用并且愿意付费"的完整验证。 很多AI创业团队在验证阶段就招了十几个工程师，大量开发资源投入进去，结果发现方向不对，代价极高。 资源越有限，越需要在投入大规模开发之前，用最低的成本把方向验证清楚。 ## 十一、Teresa Torres和"持续发现习惯"：把探索变成日常节奏 卡根的书给出了"应该做什么"，Teresa Torres的《持续发现习惯》给出了"每周怎么做"。 这两本书是最好的配套，一个讲方向，一个讲系统。 Torres的核心主张是：产品发现不应该是某个阶段的特定项目，而应该是持续的、固定节奏的日常习惯。 她给出的最小可行发现节奏是：每周至少做一次真实用户访谈。不是季度一次的大型用研项目，不是在重大节点前临时找几个用户，而是每周一次，持续进行，不中断。 为什么每周一次这么重要？ 因为产品决策需要不断的信号更新。用户的反馈在变，市场在变，你对问题的理解也在随着每次访谈深化。 如果信号更新的频率太低，就会出现一种常见的问题：团队对用户的认知停留在三个月前的那次用研里，但用户早就不一样了，产品也走偏了方向。 Torres引入了一个工具，叫"机会解决方案树"。 它的结构是这样的： - 最顶层是你想达到的业务目标，比如提高30天留存； - 中间一层是你从用户访谈里发现的机会，比如"用户觉得新功能上手太难"，"用户找不到某个关键功能的入口"； - 最底层是针对每个机会的具体解决方案，比如优化新手引导，重新设计导航结构。 这棵树的价值，是把用户洞察、产品机会和解决方案之间的关系可视化。 它能帮团队看清楚：我们正在探索的解决方案，对应的是哪个用户机会？如果这个解决方案做出来了，它能解决的机会是不是足够重要？有没有更好的解决方案可以解决同样的机会？ 对于AI产品团队，持续发现系统的价值更加突出。 大模型能力在快速迭代，用户对AI功能的预期也在快速变化，今天用户觉得AI能做这件事是令人惊喜的，三个月后可能变成理所应当的基础能力。 如果没有持续更新的用户信号，就很难判断什么时候应该投入资源去升级某个AI能力，什么时候应该转移注意力去解决其他问题。 Torres还有一个观点值得在这里单独说：发现工作的质量，直接取决于产品三角里每个人参与的深度。 如果产品经理自己做访谈，不让设计师和工程师参与，这样收集到的信号经过了一次转述，信息密度和准确度都会下降。 最好的方式是产品三角一起做访谈，三个人看同样的用户，听同样的故事，各自带着自己的专业视角来理解，讨论时会更有深度。 ## 十二、从初级到高级：产品经理的成长路径 读完《启示录》，一个很自然的问题是：知道了这些，我要怎么做？ 先说入门阶段。 很多人做产品的第一年，主要工作是学会写需求，学会用Axure或Figma做原型，学会和开发、设计沟通，学会在评审会上讲清楚功能逻辑。 这些是基础技能，是必要的但不是充分的。 《启示录》里有一个建议，适合入门阶段的产品经理：找机会做用户访谈。不是等到公司安排，而是自己主动去找。 每周找一个真实用户聊30分钟，问他们在使用你负责的产品时遇到的最大困惑是什么，最常做的操作是什么，什么情况下他们会停下来不知道该怎么做。 这一步会改变一个新产品经理的思维方式：从"我觉得用户会这样用"变成"我知道用户是这样用的"。 这个转变，是从初级到中级最关键的一步。 中级阶段，产品经理面对的主要挑战，是开始要负责产品方向，而不只是执行别人的方向。 这时候机会评估的能力变得关键，你需要学会在大量输入中识别真正重要的信号，需要学会说"这件事我们不做，因为它不符合核心目标"，需要建立自己的优先级判断框架。 高级产品经理面对的主要挑战，是影响组织。 《启示录》里关于组织设计的那些建议，主要是给高级产品人和管理层看的：怎么建立独立的产品职能，怎么推动从功能团队向授权团队的转变，怎么建立有效的产品评审机制，怎么创造让创新发生的组织环境。 在这个阶段，理解书里的组织批判部分，比理解产品探索方法论更重要。 因为你自己的判断力可能已经够了，真正的障碍是系统性的组织问题。 ## 十三、三本书的阅读路线图 说了这么多，最后说说这本书和其他书怎么组合在一起读。 第一本：《启示录》，作为基础框架 读这本书，不要读得太快，要带着问题读：我们公司现在的流程是什么样的？和书里的建议有哪些差距？差距的根源在哪里？ 不要只是点头说"对对对"，要具体问：我们上一个失败的产品，在哪个环节犯了书里描述的哪种错误？ 把书当防御手册来用，比当教科书来用收益更大。 第二本：《精益创业》，作为节奏框架 《精益创业》和《启示录》是互补的。 卡根告诉你产品探索为什么重要，精益创业告诉你探索的节奏应该有多快。 精益创业的核心是"构建-测量-学习"的循环：快速构建最小可行产品，快速测量关键指标，快速从结果里学到东西，然后决定是继续还是转向。 这个循环的速度，是精益方法的核心竞争力。 两本书合在一起，会让你对"产品探索应该长什么样"有更立体的理解：它是一个以周为单位的持续循环，不是一个季度启动一次的阶段性项目。 第三本：《持续发现习惯》，作为操作系统 前两本书都在讲方向，Teresa Torres这本书给出操作系统。 具体内容已经在前面讲过了，这里补充一个读书建议：不要只是把这本书读完，要在读的过程中，设计出你自己的最小可行发现节奏。 你每周可以做一次用户访谈吗？如果一次不行，两周一次呢？ 你的产品三角现在存在吗？如果不存在，可以从哪里开始建立？ 你有机会解决方案树吗？如果没有，可以用一张白纸先画出来试试吗？ 把书里的框架转化成你可以下周就开始做的事，才算真正读完了这本书。 ## 十四、名词是权力，先把词汇表建起来 读完这三本书之后，你会拥有一套产品工作的词汇表。 这件事听起来平凡，但它的价值被严重低估。 当你能说"我们现在正在做机会评估，这个阶段不讨论解决方案"，会议室里的讨论就会被重定向。 当你能说"这个需求属于特例产品，接了会把我们带离通用市场"，你就有了一个可以在会议上说出来的理由，而不只是内心的迟疑。 当你能说"我们的团队模式更接近功能团队，但我们希望往授权团队方向转变"，组织讨论就有了一个可以锚定的方向。 名词是权力。 你有了准确的词汇，就可以精确地描述问题，精确地描述问题，才有可能推动有意义的改变。 有一件事值得说一下：《启示录》在中国产品从业者里的名声非常响，豆瓣八点几分，书单必推，很多产品面试会直接问"你读过《启示录》吗"。 但真正读进去、读出东西的人，远比声称读过的人少。 这不是批评，是一个观察。 这本书不是很难读，但它的很多观点和我们工作中习以为常的方式是相反的，所以"读进去"需要一种特别的意愿：允许自己被说服，允许承认自己公司的流程有根本性的问题。 最后一件事： 有人在Reddit上问，这本书在现实工作里真的有用吗？高赞回复是这么说的： "书里讲的很多东西，在大多数公司里你根本推不动，因为组织阻力太大。但这本书最大的价值，不是给你一套马上能用的操作手册，而是让你知道问题在哪里，知道更好的方式是什么。当你知道了这些，你会对公司里的坏模式更加敏感，更有意愿去推动改变，哪怕只是一点点。" 这个回复，我觉得是对这本书最诚实的评价。 读完《启示录》，你未必能立刻改变你的公司，但你会开始清楚地看到，问题出在哪里，更好的方式是什么，以及下一步你可以做什么。 这已经足够。

译本文结合AI时代背景解读《启示录》，指出多数产品失败源于早期方向错误，而非执行力。产品经理核心职责是“评估产品机会”与“定义要开发的产品”。书中强调用“机会评估”框架聚焦问题本身，并主张以高保真原型（现可用Figma等工具快速制作）替代传统PRD，通过约5名目标用户的测试提前验证体验。在AI降低原型成本的当下，团队更应警惕盲目添加功能，回归产品探索本质。

歸藏(guizang.ai)@op7418 · 5月13日71

用藏师傅的 PPT Skill 让 Codex 配图的技巧 涉及到一些非常生僻的事实你怕 Codex 画的图有问题的时候，可以让他搜索相关图片，然后基于搜索的图片生成新的图片 这样既可以保证真实性，又可以生成符合比例要求和高清的图片 比如云南这种甲马符 GPT 肯定是不知道长啥样的，但是垫图之后他能画的很好。

译当使用Codex等AI生成涉及生僻事实的配图时，可先让其搜索相关图片作为参考，再基于此生成新图。该方法能确保图像的真实性，同时生成符合比例要求的高清图片。例如，对于云南甲马符这类GPT可能不了解的主题，通过垫图后AI能准确绘制。

SiliconFlow@SiliconFlowAI · 5月13日69

Run DeepSeek V4, GLM-5.1, Kimi K2.6 and more on @SiliconFlowAI directly in VS Code with @continuedev: Tab autocomplete, AI chat &amp; edit, and agent support Here's how to set it up in 3 steps 🧵⬇️

译通过@continuedev在VS Code中直接运行DeepSeek V4、GLM-5.1、Kimi K2.6等多款模型@SiliconFlowAI 支持标签自动补全、AI对话编辑和智能体功能 以下是3步设置指南 🧵⬇️

歸藏(guizang.ai)@op7418 · 5月13日70

Skills 已经更新了这个带地图的版式和地图组件 大家让自己的 AI 更新这个 Skills 就行。 地图支持放大缩小和拖动，以及 AI 可以在地图上做任意的标记。

译Skills功能已更新，新增了带地图的版式和地图组件。用户可让各自的AI更新此技能。更新后的地图支持缩放、拖动等基本交互操作，并且AI能够在地图上进行任意标记。这增强了AI在空间信息处理和可视化方面的能力。

Berryxia.AI@berryxia · 5月13日31

AI Agent 得记忆科普是让铁锤讲明白了，看完后身心愉悦，后背从此不再发凉。

译AI Agent 得记忆科普是让铁锤讲明白了，看完后身心愉悦，后背从此不再发凉。 [引用 @lxfater]：http://x.com/i/article/2054390427139383296

Peter Steinberger 🦞@steipete · 5月13日48

Codex was debugging a Telegram issue and needed a new token, so it used Peekaboo to open the Telegram Mac app, talked to botfather and just did it. Computer Use is amazing. https://peekaboo.sh

译Codex在调试Telegram问题时需要新令牌，于是使用Peekaboo打开Telegram Mac应用，联系botfather并完成了操作。 计算机应用令人惊叹。https://peekaboo.sh

歸藏(guizang.ai)@op7418 · 5月13日36

前几天去天津玩，去五大道的时候，无意间问了一下 AI 这里的历史，发现还是挺复杂的。 基本上近代好多名人和好多事件都与住在这儿的人有关系。 所以我就试了一下，用我的这个 PPT Skills 讲一下这些人的故事。 新增了一个排版： 1. 左侧是卡片 2. 右边是地图（这个地图是可以交互的，内嵌在了 PPT 里面） 后面会做更多这种尝试，让你的 PPT 内容更丰富，嵌入更多更详细的信息。

译作者在游览天津五大道时，尝试利用AI查询该区域复杂的历史背景，发现众多近代名人事件与此地相关。为此，他创新了PPT制作方式，将历史人物的故事卡片与可交互的嵌入式地图相结合进行展示。这种新排版旨在让演示内容更丰富、信息更详实，并计划在未来进行更多类似尝试，以提升PPT的信息承载与呈现能力。

Berryxia.AI@berryxia · 5月13日47

兄弟们，我现在也学精了。 之前我的刹车片有异响，被 4S 店忽悠着换了一套，记得当时花了一千多。 今年最近广东这边下大雨，空气非常潮湿，湿度干到80-90%，结果昨天我那刹车片又开始响了。 我就用 ChatGPT 问了一下是什么情况，最后判断排除，可能就是因为潮湿导致上面有了锈迹。 AI 推荐了一些清洗剂，我就去网上找了一下。昨天在京东买的，今天已经到了。 喷上之后试了几下，真的没有再响。 这种刹车片有个问题：它在低速怠速的时候容易响，高速转动刹车时反而不会响。 这玩意儿一瓶才 69 块钱，一喷就解决了。 以前真没注意这个问题，4S 店还跟我说是刹车片磨损什么的，纯粹就是忽悠人。 所以说，之前这笔智商税真的是交得妥妥的，还是得感谢 AI。😂

译车主发现刹车片在潮湿天气出现异响，未选择4S店建议的更换方案，转而通过ChatGPT分析问题。AI判断异响可能源于潮湿导致的锈迹，并推荐使用清洗剂处理。车主花费69元购买清洗剂后，喷洒试用成功消除异响。此前4S店曾以磨损为由建议更换整套刹车片，费用超千元。此事凸显了AI在日常生活问题诊断中的实用价值，帮助用户避免了不必要的开支。

Berryxia.AI@berryxia · 5月13日72

如何对本地大模型进行基准测试 ？ 1、拉取一个模型 2、运行 BenchLoop 3、实时查看质量 / 速度 / 可靠性评分 4、对比不同提示框架（如原生模式 vs Hermes 模式） 5、自动发布到公开排行榜 https://bench-loop.com

译BenchLoop 提供了一套对本地大模型进行基准测试的标准化流程。用户只需拉取模型并运行该工具，即可实时获取模型在质量、速度和可靠性方面的综合评分。平台支持对比不同提示框架（如原生模式与 Hermes 模式）下的性能表现。测试完成后，结果可自动发布至公开排行榜，便于横向比较不同模型的优劣。

Berryxia.AI@berryxia · 5月13日51

每天打开群聊 消息永远999+ 根本没时间慢慢爬楼 本以为腾讯元宝的群聊总结 是拯救懒人神器 结果实测完和我们想的不太一样 它根本做不到自动进群总结 还要自己手动多选聊天记录 而且不能全选，上限多少条还没有看到说明 再转发给元宝才行 总结出来的内容 也像单纯复制文本拼凑 完全没有AI该有的智能感 明明大家最需要的 就是直接把元宝拉进群 自动梳理每日群聊重点 偏偏最简单的需求 硬是不给做啊！🤔

译用户实测腾讯元宝的群聊总结功能，发现其与预期存在较大差距。该功能无法自动进群总结，需用户手动多选聊天记录并转发给元宝，且存在操作上限不明确的问题。生成的总结内容被批评为机械的文本拼凑，缺乏AI应有的智能分析与提炼能力。用户指出，最核心的需求是能将元宝直接拉入群聊并自动梳理每日重点，但目前这一简单需求并未得到实现。

宝玉@dotey · 5月13日57

1. Skills 是技能，领域知识，工作流等等，相当于怎么干好一件事的说明书。 比如 https://github.com/anthropics/claude-for-legal 仓库里有个 skill 叫 nda-review，在 commercial-legal/skills/ 文件夹里。里面是一份 SKILL.md，写清楚：审 NDA 时先比对哪些条款、按团队 playbook 打绿黄红三档、什么情况要升级、输出格式是 Word 修订模式。 它就是一份给 Claude 看的工作手册，本身不干活。 2. Agent 是真正执行任务的主题，除了主要执行的 Agent，通常自定义的 Agent 分两种：Subagent 和 Scheduled agent 2.1 Subagent 是单独派出去干一摊子活的“分身” 举个仓库里的例子：corporate-legal:tabular-review 这个 skill 要对一个数据室里几百份合同做表格化尽调。如果让主对话一份份读，上下文很快爆掉。所以它派 subagent，一个 subagent 负责一份文档，并行跑，最后把结果汇总回主对话。 主 Agent 看到的只是最终表格，中间几百次读取的信息被隔离在外。 2.2 Scheduled agent 是定时自己跑的后台任务 renewal-watcher 这个就是。每周自动扫一遍合同库，把 90 天内到期的合同列出来，发到指定 Slack 频道。你不用记日子，它替你盯。 docket-watcher（盯法院案件动态）、reg-feed-watcher（盯监管新规）都是这种。 3. MCP connector 是把外面的数据接进来的连接器 Skill 写得再好，也得有合同可审。仓库里配了 Ironclad（合同库）、DocuSign（已签合同）、iManage（文档管理）几个 MCP connector。 Agent 通过这些 MCP connector 去读公司真实的合同库，而不是让你手动复制粘贴。 类似地，诉讼那个 plugin 接的是 Everlaw（电子取证）、CourtListener（联邦法院判决数据库）、Trellis（州法院数据库）。换个执业方向，换一套数据连接器。 4. Plugin 是把上面这些打包到一起的容器 commercial-legal 这个 plugin 文件夹里装着： - 一堆 skill（nda-review、vendor-agreement-review、escalation-flagger……） - 几个 scheduled agent（renewal-watcher、deal-debrief） - 一份 .mcp.json，告诉 Claude 要连哪些外部系统 - 一份 CLAUDE.md 模板，用来记你团队的 playbook 你装上这一个 plugin，整套企业合同审查的能力就一次性配齐了。

译Claude通过四大组件实现自动化任务：Skill是领域工作流指南（如nda-review），指导操作但不执行；Agent是执行主体，Subagent用于并行处理子任务，Scheduled agent则定时自动运行（如合同到期监控）；MCP connector连接外部数据源（如合同库），使Agent能访问真实数据；Plugin将上述组件打包，提供完整功能集（如commercial-legal plugin实现企业合同审查）。这些组件共同协作，使Claude能高效处理复杂工作流。

ginobefun@hongming731 · 5月13日71

构建支持暂停、恢复且永不丢失上下文的长时间运行 AI 智能体（基于 ADK） 大多数 Agent 教程的终点是一个无状态的聊天机器人，容器一重启，什么都忘了。但真实的企业工作流不可能在一次 API 调用里完成。HR 入职流程跨越两周，发票纠纷要等供应商回复几天，销售跟进序列拉开一个月。这些流程被大量「空闲等待」主导，无状态架构天然无法应对。 Google 博客通过一个「新员工入职协调 Agent」实例，展示了三项让 Agent 从 Demo 走向生产的架构转变。 第一项是持久化状态机。不再靠对话历史追踪进度，而是定义显式的状态 schema：START、WELCOME_SENT、DOCUMENTS_SIGNED、IT_PROVISIONED、HARDWARE_DELIVERED、COMPLETED，六个明确节点。Agent 每次唤醒，从 session state 而非聊天记录里读取当前位置。这彻底解决了三个无状态架构的致命问题：对话历史在数百轮后充满过期噪音（上下文污染）、每次推理都要重放完整历史（token 成本爆炸）、长时间空闲后恢复时模型幻觉出从未发生过的中间步骤（推理幻觉）。 第二项是事件驱动休眠门控。Agent 在等待人工签字时不再主动轮询，而是挂起自身，等到外部事件（如文件签署通知）到达后才被唤醒。零资源占用，不会因为长时间等待而消耗 token 或算力。 第三项是多 Agent 委托。IT 账号配置这类专项任务，交给独立的 IT 子 Agent 完成，主 Agent 只负责协调和状态推进。这避免了单体 Agent 提示词膨胀，也让各子任务可以独立优化。 完整示例代码已放在 GitHub 上。这套架构的核心洞察是：Context 与 State 解耦，才是 Agent 从实验室走进生产环境的关键一步。

译Google博客以“新员工入职协调Agent”为例，指出AI智能体从演示走向生产需完成三大架构转变，核心是上下文与状态解耦。首先，采用持久化状态机，通过明确进度节点替代对话历史记录状态，解决上下文污染、token成本爆炸和推理幻觉问题。其次，引入事件驱动休眠门控，使Agent在等待外部事件时挂起以零资源消耗。最后，通过多Agent委托机制，将专项任务交由独立子Agent处理，避免提示词膨胀并支持独立优化。完整示例代码已开源。