meng shao@shao__meng · 6月24日70

[官方博客] Codex Remote 工程实践指南 手机上远程操作 Codex 的真正作用是什么？真正用好的 10 个最佳实践是什么？Codex 官方这篇博客都讲到了，一起看看。 https://developers.openai.com/blog/mastering-codex-remote-for-engineering # 核心心智模型：手机是「控制面」，不是「终端」 很多人第一眼会把 Codex Remote 当成「远程盯任务进度」的工具——能看，但价值有限。 Codex 官方给出的定位更准： · 开发机（Mac / Windows / devbox）：跑代码、跑测试、持有凭证与环境 · 手机：启动、指挥、审批、审查、组织工作 关键决策——用哪个 repo、哪个 worktree、是否批准命令、diff 是否 OK——可以在离开工位时完成，而不必把 iPhone 伪装成迷你终端。 # 十个高杠杆能力（按工程价值排序） 1. 任务开始前：10 秒选对环境，省 10 分钟清理 启动前可选：主机、workspace、分支、是否新建 worktree、是否先跑环境 setup。 常见模式： · 当前 checkout → 快速排查 · 新 worktree → 隔离改动 · 指定 base branch → 避免事后修 Git 状态 · Composer 还支持附件（文件、截图、相机）、Skills/Plugins 内联确认——能消除歧义就先在第一轮带上。 2. Queue vs Steer：最不直观、但杠杆最高 Agent 已在运行时，后续消息有两种行为： · Queue：等当前回合结束再发送，适用于第二项任务、补测、默认安全选项 · Steer：注入到进行中的工作，适用于方向错了、需立刻纠偏 Steer 示例：「修复限定在 mobile 包内，不要重构 shared renderer」「只测 resume 路径，不测 live 路径」。 官方建议：默认 Queue，Steer 刻意使用——误用 Steer 的代价通常高于多等一轮。 3. Side Chat：主线程干活，旁路理解 /side 或选中 transcript 文本 →「Ask in side chat」，开轻量旁路对话，不打断主线。 适合：「为什么选这个架构？」「这个 error 什么意思？」「批准前该验证什么？」 主线程 = 推进工作；旁聊 = 理解工作。 4. Plan vs Goal：路径 vs 结果 · Plan 模式：回答 - 怎么做？，适用于任务模糊、风险高、跨多系统 · Goal：回答 - 完成标准是什么？：适用于跨多轮持久目标，不必每轮重述 典型流程：Plan → 审边界 → 定 Goal → 实现 / 测试 / review / cleanup 持续推进。 5. 对话内 Code Review：手机也能做「决策型审查」 完整链路：变更摘要 → diff → 单文件语法高亮 → 行内 comment → 回传 Agent 修改 → 再审小 diff。 态度客观：手机不能替代大屏深读；但很多 review 卡在 1–2 个决策点，不必等回工位。 6. 权限：工作流的一部分，不是麻烦 对命令、文件变更、网络、工具的请求，可选一次性 / 当前 chat / 更宽范围批准。 原则：选最窄权限让工作继续，而非全部放行。线程级审批策略应和 host、branch、model 一起在任务开始时想好。 7. 上下文生命周期：/status → /compact → /fork · /status：session、workspace、context 用量、限流 · /compact：目标不变、线程过长时压缩 · /fork：目标分叉时继承历史开新主线 Side chat ≠ fork：前者是旁问，后者是新工作线。 8. Thread Desk：小型运维台 Pin 活跃线程、按 outcome 重命名、完成后归档（归档非删除）。通知一键跳转到待审任务；Spotlight / Shortcuts / iPad 快捷键进一步缩短路径。 定位：Chief of Staff——不只发 prompt，还管理哪些工作在跑、阻塞、待审、已完成。 9. 命令速查 /plan /goal /side /review /status /compact /fork /fast /feedback——输入 / 即暴露产品概念模型。 10. 五个典型工作流 1. Release Captain：单线程盯 release/PR，pin，steer 仅用于推翻当前调查方向 2. Interrupt Bug Fix：附件 + 先诊断再改，side chat interrogation 可疑 error 3. Mobile Reviewer：branch review + 行内 comment + 只改 comment 点 4. Long-running Goal： concrete 完成条件（测试绿、review 清、性能阈值），用通知/status 而非反复问「好了没」 5. Multi-machine Operator：按机器/环境命名 host，在「有 Mac 模拟器 / Windows 环境」的那台启动任务 对 AI coding agent 的通用启示： 1. 异步 + 人机协作 比同步 pair programming 更适合 mobile 2. Steer / Queue / Side / Fork 是在管理 agent 的「注意力与状态机」，不是聊天 UX 花样 3. Goal + Plan 是把 open-ended agent 约束成可交付工程任务的结构 4. 权限粒度 决定 remote 能否用于生产环境

译OpenAI 发布 Codex Remote 工程实践官方博客。核心心智模型：手机是“控制面”而非终端——开发机跑代码，手机负责启动、指挥、审批、审查。十大高杠杆能力包括 Queue vs Steer、Side Chat、Plan vs Goal、对话内 Code Review、细粒度权限管理等。另有 /status /compact /fork 命令与五个典型工作流（Release Captain、中断修复、移动端审查等）。对 AI coding agent 的启示：异步协作、注意力与状态机管理、目标约束、生产级权限粒度。

gabriel@gabriel1 · 6月24日55

STOP HOLDING BACK WHEN PROMPTING you can literally one shot whatever feature in one prompt just yap for longer. aim to describe every thing you can possibly imagine in ONE prompt and obviously use voice. i often talk for 15minutes straight

译提示时不要再克制了，你可以真的只用一个提示就一次性搞定任何功能，多说一会儿就好。目标是尽可能把你想到的一切都描述在一个提示中。 另外，显然要用语音。我经常连续说上15分钟。

Rohan Paul@rohanpaul_ai · 6月24日60

Atomic Chat just made Cline run coding agents on local AI models. @cline is the agent layer: it can read files, edit code, run terminal commands, inspect errors, and ask approval before actions. Atomic Chat is the model layer: it runs open-weight models offline locally, supports 1000+ models, and exposes a local API that other tools can call. A quieter shift in many areas: powerful agents moving back onto private machines.

译Atomic Chat 集成 Cline，使代码智能体能在本地 AI 模型上运行。Cline 作为智能体层，可读文件、编辑代码、运行终端命令、检查错误并请求批准，已被 800 万+开发者信任。Atomic Chat 作为模型层，支持 1000+ 模型离线本地运行，并暴露本地 API 供其他工具调用。整个过程私有、免费、开源，体现了强大智能体回归本地私有设备的趋势。

elvis@omarsar0 · 6月24日61

Very cool to see more focus on agent observability tools. I pointed Latitude at my Claude Code setup and immediately saw which tasks were actually eating my token budget. It's a great way to: > See what your agent does > Catch the failures that keep repeating, with the frequency and reason > Fix them without leaving your editor Open source and MIT licensed! Try it free at http://latitude.so

译DAIR.AI 创始人 Elvis Saravia 推荐开源（MIT 许可）工具 Latitude，用于 AI 智能体可观测性。将 Latitude 指向 Claude Code 配置后，可实时查看哪些任务消耗 token 预算，观察智能体行为、捕获重复失败及其频率与原因，并在编辑器中直接修复。引用推文指出：公司最被低估的数据源是 AI 智能体对话，Latitude 能捕捉这些被浪费的数据。免费试用地址：latitude.so。

elvis@omarsar0 · 6月23日27

Highly-recommended read. It's exciting to see large-scale agentic RL becoming more accessible. Cool to see the infra layer for this is being built and I think this plays an important role in self-improving agents arc and "owning your AI."

译一篇博客文章汇总了在 GLM-5 上进行强化学习所需的所有基础设施组件。主推文作者强烈推荐阅读，并认为这对自我改进智能体发展至关重要。

Nathan Lambert@natolambert · 6月23日32

Something I should add -- on-policy distillation was the last content I got to sneak into the book before going to print. Felt very important to have this method covered, it's growing rapidly and used in distinct ways. So you can also read what is covered in this lecture!

译Nathan Lambert 为新书新增 7.4 小时讲座视频，内容涵盖从 2015 年 Hinton 知识蒸馏论文到当下多教师 on-policy 蒸馏（OPD、MOPD、OPSD）。视频重点讲解了使 on-policy distillation 适配主流 RL 框架所需的 3–4 项核心公式改动，并回顾了合成数据如何逐步占领训练后数据研究领域。此外还介绍了 Constitutional AI、AI 反馈以及将评分准则作为奖励等主流方法。时间线：00:00 合成数据兴起，10:50 师生蒸馏背景，24:47 on-policy 蒸馏，37:11 Constitutional AI，45:50 评分准则与结论。

向阳乔木@vista8 · 6月23日68

新智元起名果然有一套，AI总结的规律： 1. 中位标题长度 32 字 2. 标点常用 ！ 和 ， 接近八成 3. 数字出现率 56.7% 4. 英文模型/公司名出现率 90.8% 常见结构 “实体/数字/刚刚 + 动作/冲突 + 后果/榜单/人群影响” Skill安装 npx skills add joeseesun/qiaomu-xinzhiyuan-title 仅供娱乐，如有侵权，请联系删除。

译网友Vista通过AI分析新智元标题风格，总结出中位长度32字、标点使用率近八成、数字出现率56.7%、英文名出现率90.8%等规律，并发布名为`joeseesun/qiaomu-xinzhiyuan-title`的Skill，可用`npx skills add`安装，生成类似标题。

Berryxia.AI@berryxia · 6月23日43

一张图可以骗过多少人的眼睛 ，你一眼看出来是AI图了么😂 因为现在Exo的集群 不可能是网线啥的，北面的接口c口没有 ，电源线不对…

译网友分享一张AI生成图，图中Exo集群的网线、C口、电源线等硬件细节明显错误，暴露了图片是AI所作。引用推文指出，2026年最新炫富方式不再是豪车名表，而是在家部署一个满血GLM5.2模型集群。

Nathan Lambert@natolambert · 6月23日44

New lecture for the book! Nominally about synthetic data, but mostly is a walk through of the distillation literature from the Hinton 2015 paper to multi-teach on-policy distillation of today! At 7.4 hours of video in my post-training brain dump and counting :) It was fun to stare at the math long enough and talk through the 3-4 core changes that needed to be made to the original formulation to have on-policy distillation be ready for the mainstream like it is today (and in RL frameworks). Otherwise, I include a bit of a history lesson for how synthetic data generally slowly took over all post-training data research (it wasn't always the case)! Then I do some 101 review on constitutional AI, rubrics, and other popular methods. 00:00 The emergence of synthetic data 10:50 Background on teacher-student knowledge-distillation 24:47: On-policy distillation (OPD, MOPD, and OPSD) 37:11 Constitutional AI & AI Feedback 45:50 Rubrics as rewards & conclusions Ofc, watch on YouTube etc.

译Nathan Lambert 为其新书发布讲座（7.4 小时），名义上关于合成数据，实则系统梳理知识蒸馏文献——从 Hinton 2015 年论文到现今主流的 on-policy 蒸馏（OPD/MOPD/OPSD）。他重点分析了使 on-policy 蒸馏落地所需的 3-4 个核心数学改动。讲座还回顾了合成数据逐步取代后训练数据研究的历史，并介绍了 Constitutional AI、rubrics 等流行方法。提供章节时间戳（00:00–45:50）。

向阳乔木@vista8 · 6月23日25

看看这个skill生成的标题，是不是有新智元的味道了😂

karminski-牙医@karminski3 · 6月23日69

刚刚 Doubao-Seed-2.1-pro 发布啦! 给大家分享一个自我迭代 Agent 的构建技巧啊, 也是我在今天字节 seed-2.1 模型发布 demo 中用到的技巧. 这个技巧的核心就是, 干一件复杂的事情, 用两个Agent比用一个Agent要好. 简单来讲打工Agent干完活之后, 还要增加一个评审Agent, 这个Agent要给打工Agent的产出评分, 然后说明评分理由, 哪里做得好, 哪里做的不好. 然后, 一定要输出结构化的评分结果(JSON就行), 这样, 打工Agent接到评分后, 进行修改, 修改完毕再次交给评审Agent, 评审Agent再次打分, 这时候就可以跟上次的打分进行对比. 只有得分大于上次的得分, 你的框架才合并这次的修改. 这就是 Agentic 自我迭代了. 基于 AI 反馈的强化学习的雏形基本就是这样的了, 以及吴恩达提出的 Agentic Workflow 核心原则之一就是 Reflection（反思），框架让模型像人类程序员提交 PR一样：打工 Agent 提交 PR，裁判 Agent 跑测试、打分。只有 Review 通过才能 Merge 到主分支。这就是真正的“工程化迭代”了. 甚至我框架内其实就是采用的Git模式, 多个Agent进行并行评估模拟多个分支, 只有打分高的才会合并到主分支. 最终得益于 Seed-2.1 本身的自我迭代和多模态能力也很强, 在它的驱动下, 成功实现了这个【只需要上传一个城市的相册, 就能建模一整个城市】的demo. 相信在现场的同学已经看到这个 demo 了哈哈. 下一期告诉你当这个办法也失效了, 该怎么办☆. #AIAgent #seed21 #AI自我迭代

译字节跳动发布 Doubao-Seed-2.1-pro 模型。作者分享自我迭代 Agent 技巧：用两个 Agent（打工+评审），打工 Agent 完成任务后，评审 Agent 输出结构化评分（JSON）并说明优劣；打工 Agent 根据评分修改，评审 Agent 再次打分，仅当新得分高于上次才合并修改。此方法基于 AI 反馈的强化学习雏形，类似吴恩达 Agentic Workflow 中的 Reflection 原则。最终利用 Seed-2.1 的强多模态与自我迭代能力，实现“上传城市相册即可建模整个城市”的 demo。

Josh Woodward@joshwoodward · 6月23日57

⚽️Turn your team loyalty into a custom trading card, mural, or virtual plushie in @GeminiApp How to create yours: 1) Go to http://gemini.google or open the app 2) Tap Images (side panel) 3) Select the "Get in the game" template 4) Upload your photo and share your output here

译⚽️在@GeminiApp 中将你的球队忠诚转化为定制卡牌、壁画或虚拟毛绒玩具 如何创建你的作品： 1) 访问 http://gemini.google 或打开应用 2) 点击“图片”（侧面板） 3) 选择“Get in the game”模板 4) 上传你的照片并在此分享你的输出

AYi@AYi_AInotes · 6月23日74

http://x.com/i/article/2069352641423896576 # 30 分钟给你的 Agent 搭好永久记忆：能 cat 能 git 能直接编辑，保姆级教程零门槛上手 我最近搭Agent工作流有一个很大的感受，就是Openclaw、Hermes、以及Claude code、Codex等这些 Agent ，是不需要更大的上下文窗口的，它需要更好的记忆能力。我花了 30 分钟给常用的编码 Agent 接上持久记忆 —— 没开 Docker，没搭向量库集群，而且这次，它的大脑就是一堆我能直接打开、直接编辑的 Markdown 文件。 ## 一、你的 Agent，每天醒来都失忆 做过 Agent 的人，大概都受过这个委屈：昨天它刚陪你定位完一个磨人的 bug，今天开个新会话，它对昨天发生的一切一无所知。 你那些决策、工作流、好不容易踩明白的坑，没有一样跟着它走。上下文被锁在上一段对话里，关掉就蒸发了。 我们的第一反应，通常是把 prompt 塞得更满。把历史记录、用户偏好、项目背景一股脑灌进上下文窗口，然后祈祷模型别忘。 但这条路很快撞墙。窗口有上限，token 要花钱，更要命的是——你塞进去的那点"记忆"是一次性的，关掉窗口就没了。 说到底，你缺的不是更大的 prompt，是一层持久记忆。 这篇我会带你用大约半小时，给一个 Agent 接上 EverOS，一个开源、本地优先的记忆操作系统。 不用搭 MongoDB，不用 Elasticsearch，也不用一整套向量数据库集群。 最妙的一点是，它把记忆存成你能直接打开、阅读、甚至手动改的 Markdown 文件。跟着走完，你的 Agent 就有了跨会话的长期记忆，而这份记忆是透明的，是你的。 那话不多说，咱们开始。 ## 二、为什么是 EverOS，而不是再自己搓一个向量库 动手前，先花一分钟说清它跟"再写一个向量库"差在哪，因为这决定了这半小时值不值。 大多数记忆方案是个黑箱，你把文本喂进去，它吐一串向量存进数据库，检索时再还你一堆相似度分数。 那么问题来了：出错的时候，你根本不知道它到底"记住"了什么、为什么这么记，调试基本靠猜😂 EverOS 走的是另一条路， 它的存储是一套本地三件套：Markdown 当唯一可信来源，SQLite 管状态和处理队列，LanceDB 管向量、BM25 全文索引和标量过滤。 关键在第一件，你想知道 Agent 记住了什么？cat 一下就行，想改掉一条记错的？编辑器打开删掉就行，这种可检视性，是黑箱向量库怎么都给不了的。 顺一句佐证，官方那几个跑分也不难看：LoCoMo 93\.05%、LongMemEval\(\-S\) 83\.00%、HaluMem 大约 90%\+，都是官方口径，你自己掂量，但真正打动我的肯定不只是分数。 说白了，我们的Agent 的大脑，就是一堆能打开的文件。 好，理念讲完，咱直接上手操作。 ## 第一步：环境准备（约 5 分钟） 一共三样东西。 Python 3\.10 以上，官方推荐 3\.12\+，一个叫 uv 的高性能包管理器，EverOS 用它管依赖和虚拟环境。 还有两个 API key——默认配置下，一个 OpenRouter 管 LLM 和多模态，一个 DeepInfra 管向量化和重排。 uv 没装的话，一行搞定： key 这块先交个底：EverOS 兼容所有走 OpenAI 协议的端点。 所以你手上要是已经有 OpenAI、自建 vLLM 或者本地 Ollama，完全可以换掉默认那两家，下一步配置我会讲怎么改。 ## 第二步：安装与初始化（约 5 分钟） 两种装法，按目的二选一： 想顺手读读代码、做点改造，从源码装： 只想把它接进自己项目，直接装包： 两种方式装完，用同一条命令初始化： 它会生成一个起始 .env。打开，填进你那两个 key： 这里插一句，别手滑：.env 里装着你的 key，记得先把它加进 .gitignore。 提交进仓库这种事，翻一次车够你后悔半天。 填完跑这两条确认没问题： ## 第三步：启动服务并验证（约 3 分钟） 起服务： 让它在这个终端保持运行。新开一个终端，做次健康检查： 一切正常的话，你会看到： 看到这行 ok，你的本地记忆服务就活了。 小提醒：文档写的默认端口是 8000，但你本地起来后亲眼确认一下，别想当然。接下来是这篇的核心。 ## 第四步：第一条记忆——写进去，再搜回来（约 8 分钟）⭐ EverOS 最值钱的就一件事，我给它起了个名，叫核心循环：写入一条事实 → 落盘成持久的 Markdown → 通过本地索引搜回来。咱完整跑一遍。 先写一条关于用户的事实。注意带上 user_id，它决定这条记忆归谁——这也是 EverOS 能在多用户、多 Agent 场景下不串味的关键。 这里我得说句实在话。1\.0\.0 本地版写入/检索的确切调用方式（是 CLI 子命令还是 REST 请求体），请你一定以仓库根目录的 QUICKSTART.md 为准，README 自己也把权威示例指到了那儿。我不照搬旧版的接口字段，免得你跟着翻车。下面这条是示意，跑通后请换成你本地真实的命令： 写完这一下，EverOS 在后台做了三件事：把这句话抽取成结构化记忆，落盘成 Markdown，同步进 SQLite 和 LanceDB 的本地索引。 现在换个会话，假装是"第二天"，用大白话把它搜回来： 跑通后，把你本地真实搜回来的那条结果贴在这——它该命中刚才那条偏好，还带着相关度。 这背后是一套混合检索：BM25 抓关键词，向量 ANN 抓语义，标量过滤按 user_id 这类维度精确切片，三路由 LanceDB 统一撑着。所以你哪怕换个问法，它照样能搜回来。 跑到这，你的 Agent 已经有跨会话记忆了。但 EverOS 最让我上头的，是下一步。 ## 第五步：掀开黑箱，看看记忆长啥样（约 5 分钟）⭐ 还记得开头那句"大脑就是一堆文件"吗？现在咱去把这堆文件翻出来。 打开 ~/.everos： cat 一下 users/alice/user.md。你会发现刚才那条偏好，已经被结构化地写进了 Alice 的画像里，人能读，你也能直接改。 对，就是字面意思——你的 Agent 的记忆，是一份你随手能打开的笔记。 这就是"Markdown 作为唯一可信来源"的真正含义。 更带感的是，你可以直接拿 Obsidian 打开整个 ~/.everos 目录，把 Agent 的记忆当成一座可视化知识库来逛。 这个画面，强烈建议你截张图，它比任何一句文案都更能说明"透明记忆"是什么。 你大概也注意到目录里有两条线，users/ 和 agents/， 这正是 EverOS 的双轨记忆：用户轨记情景和画像（用户是谁、有啥偏好），Agent 轨记案例和技能（Agent 干过啥、学会了啥）。两条线分开抽取，互不污染。 ## 再往前一步，它还能玩什么 这半小时咱只跑通了最核心那一圈，但 EverOS 能干的远不止这些，简单点几个方向，留给你接着探。 多模态摄取——一次 API 调用，就能把 PDF、图片、文档、表格、网页 URL 吃进记忆。 这里有个坑提前说：Office 文档的解析依赖系统装了 LibreOffice，没装的话 .docx/.pptx/.xlsx 会失败，但 PDF、图片、音频不受影响。 自我演化——每个完成的任务被记成一个 Case，那些反复成功的模式会自我提升成可复用的 Skill，在整个 Agent 团队间共享，不用你手动整理。 路线图上还有 Knowledge Wiki（把碎片记忆整理成可版本化的 wiki 页）和 Reflection（系统空闲时连接弱信号、压缩历史、改进画像）。 方向我挺期待，但毕竟还在路上，这里只当个预告。 ## 几个容易翻车的点 最大的一个坑，必须单拎出来说。 网上很多"EverOS 教程"，其实讲的是它早期那个重型版本，要 docker-compose up 拉起 MongoDB、Elasticsearch、Redis 一整套。 你要是照着抄，从第一步就翻车。本文这个 1\.0\.0 轻量版的全部价值，恰恰就是不需要这些——命令认准 everos init / everos server start 这套 CLI 就对了。 剩下两个一句话带过：Office 文档解析记得装 LibreOffice；.env 一定进 .gitignore。 ## 收尾：记忆这件事，值得你认真对待 半小时前，你的 Agent 每开一个会话都从零开始。 现在，它有了一层跨会话的持久记忆——而且这份记忆不是黑箱里一串你看不懂的向量，是你能打开、能读、能改、能用 Git 版本化的文件。 这正是我觉得它值得收藏的原因，它没把"记忆"做成一个玄乎的概念，而是给了开发者一套能跑、能看、能改的具体东西。 如果你手上正有需要长期记忆的 Agent、LLM 应用或者编程助手，现在就把这个仓库收藏了，下次开新项目你会想起它： 👉 https://github\.com/EverMind\-AI/EverOS 本文基于 EverOS 1\.0\.0 轻量本地版整理，跑分均为官方口径。仓库更新较快，发布前请核对最新版本号、默认端口，以及 QUICKSTART\.md 里写入/检索的权威示例，并把你本地真实跑出的命令和返回替换进正文。

译EverOS 1.0.0是一款开源、本地优先的记忆操作系统，专为AI Agent提供跨会话持久记忆。其核心是将记忆存储为可直接cat、git、编辑的Markdown文件（唯一可信来源），配合SQLite管理状态、LanceDB处理向量/BM25索引及标量过滤，无需Docker或向量数据库集群。官方基准：LoCoMo 93.05%、LongMemEval‑S 83.00%、HaluMem约90%+。支持多模态摄取（PDF/图片/网页URL），任务可自我演化成可复用Skill，计划加入Knowledge Wiki和Reflection。用户通过CLI（everos init/server start）约30分钟上手。

fofr@fofrAI · 6月23日72

For your agents: > npx skills add google-gemini/gemini-skills --skill gemini-interactions-api --global

译今天，Interactions API 正式可用，作为 Gemini 模型和智能体的主要接口。该 API 基于开发者反馈构建，针对有状态、智能体的工作流优化，带来 Managed Agents、后台执行、扩展工具支持、多模态生成以及即将推出的 Gemini Omni 等新能力。开发者可通过 `npx skills add google-gemini/gemini-skills --skill gemini-interactions-api --global` 为其 agent 添加该 API 技能。

jason@jxnlco · 6月23日29

Codex irl

译Codex 现实生活

Berryxia.AI@berryxia · 6月23日46

刚刚看到YouMind已经第一时间接入了Doubao Seed2.1 Pro 于是乎我试了一把，就是这几个字，自己理解来帮我做了个网页游戏。 反正看着还行，至少逻辑关系、审美都还可以。 后面我谢谢Skills 看看效果如何！

译YouMind 已支持豆包（Doubao）Seed2.1 Pro 模型，据称性能可媲美 Opus 4.6，且积分消耗更低。有用户试用该模型仅凭简单提示词生成网页游戏，评价其逻辑关系与审美表现尚可，并计划后续测试 Skills 功能。

Berryxia.AI@berryxia · 6月23日72

有人把自己的剪辑 Skills 接上 Codex，现在能让Agent从口播素材直接跑到最终成片。 成峰之前开源了一个2000+ Star的剪辑Skills，这次和Codex结合后，整个流程打通了。 把原始口播视频和文字稿丢给Agent，它就能自动剪辑、分镜、做动画，最后合成完整视频。已经帮他跑出好几条千赞内容。 具体流程是这样的： 先让Codex安装他的剪辑Skills，然后用斜杠命令 /剪口播 把素材和稿子扔进去，Agent会生成审核页，确认后直接输出剪好带字幕的视频。 接下来用 /口播成片 命令，Agent会生成一个HTML分镜核对页，左边是画面，右边是字幕和任务描述。 你可以直接反馈哪一段需要改，Codex用Computer Use自己去调整。 确认没问题后进入时间线预览，最后用HyperFrames合成最终MP4。 以前做视频是人围着时间线操作，现在是人给方向，Agent围着工作流跑。 视频生产正在从“手动执行”变成“流程编排”。 地址见评论区👇

译成峰开源了一款2000+ Star的剪辑Skills，与Codex结合后，Agent可自动完成口播视频的剪辑、分镜、动画及合成。流程：先安装Skills，用/剪口播命令上传素材和文稿，生成审核页并输出带字幕视频；再用/口播成片命令生成HTML分镜核对页，用户反馈后Codex通过Computer Use自动调整，最后用HyperFrames合成最终MP4。视频生产从手动执行转向流程编排。

OpenRouter@OpenRouter · 6月23日49

Tip 💡: if you have @1Password installed, OpenRouter will detect it and help you save your API keys

译提示 💡：如果你安装了 @1Password，OpenRouter 会检测到它并帮你保存你的 API 密钥。

AYi@AYi_AInotes · 6月23日60

激情世界杯，你最喜欢哪国的抓拍？

译用户通过Claude Fable 5总结出AI生成性感人像提示词的8种有效写法：用“成人+气质+材质”定人设；用“服装剪裁+面料质感”替代直白身体描述；用“表情瞬间”制造吸引力；用“镜头语言”强化质感；用“光线”塑造皮肤轮廓；用“背景虚化+前景留白”凸显主体；用“克制的性感”而非夸张；用强负面词避免跑偏。此外还需使用干净住宅IP以避免风控拒绝。

jason@jxnlco · 6月23日13

https://shnatsel.medium.com/the-unreasonable-effectiveness-of-llms-for-auditing-rust-code-d4df8bf0afd3

译我刚刚读了这篇文章：https://shnatsel.medium.com/the-unreasonable-effectiveness-of-llms-for-auditing-rust-code-d4df8bf0afd3

SenseTime@SenseTime_AI · 6月22日50

Thanks YouTuber xCreate for the great breakdown of 𝗦𝗲𝗻𝘀𝗲𝗡𝗼𝘃𝗮 𝗨1! Great to see the model's powerful 𝘁𝗲𝘅𝘁-𝗶𝗺𝗮𝗴𝗲 𝗶𝗻𝘁𝗲𝗿𝗹𝗲𝗮𝘃𝗲𝗱 𝗿𝗲𝗮𝘀𝗼𝗻𝗶𝗻𝗴 and 𝗶𝗻𝗳𝗼𝗴𝗿𝗮𝗽𝗵𝗶𝗰 capabilities featured — along with a 𝘀𝘁𝗲𝗽-𝗯𝘆-𝘀𝘁𝗲𝗽 𝗴𝘂𝗶𝗱𝗲 𝘁𝗼 𝗿𝘂𝗻𝗻𝗶𝗻𝗴 𝗶𝘁 𝗹𝗼𝗰𝗮𝗹𝗹𝘆 𝗮𝗻𝗱 𝘃𝗶𝗮 𝗦𝗲𝗻𝘀𝗲𝗡𝗼𝘃𝗮 𝗦𝘁𝘂𝗱𝗶𝗼. 🎥https://www.youtube.com/watch?v=FWaQC_exKh0 🎛️SenseNova Studio: https://unify.light-ai.top (Try infographics; also join Discord for text-image interleaved gen) 🤗https://huggingface.co/collections/sensenova/sensenova-u1 🛠️https://github.com/OpenSenseNova/SenseNova-U1 👾Discord: https://discord.com/invite/BuTXPHmQub

译商汤SenseTime发布推文，感谢YouTuber xCreate对SenseNova U1模型的详细拆解，重点展示其文本-图像交错推理（text-image interleaved reasoning）和信息图表（infographic）生成能力。推文附有逐步指南，指导用户通过SenseNova Studio在线使用或本地运行模型。相关资源包括YouTube视频、HuggingFace模型集合、GitHub仓库及Discord社区链接。

Berryxia.AI@berryxia · 6月22日64

兄弟们，睡前搞个小教程给大家！ 直接教你将免费或者低成本的模型接入到沉浸式翻译，不废话直接看视频操作，包你学会。 操作步骤如下： 1. 打开沉浸式翻译，点击“设置” 2. 进入设置后，点击左侧的“翻译服务” 3. 点击右上角的“添加自定义翻译服务”，然后选择“自定义 AI” 4. 在自定义 AI 页面填入 API Key，以及你接入的大模型 API 接口地址 (a) 接口地址务必填对，不同的模型可能会有一些差别，可以查看对应的官方文档 (b) 选择对应的模型。如果你使用的是自定义模型，请勾选下方框中的“输入自定义模型名称” (c) 我这里以小米的 MiMo 模型为例，给大家进行视频演示 （Base URL ：https://api.xiaomimimo.com/v1/chat/completions） 5. 填好后点击“测试服务”，如果测试通过，就完成了对应的配置 如果你想要切换使用，直接在沉浸式翻译的服务选项中，选择你刚刚自定义的模型即可，非常方便。 你学会了吗？ 记得一键三连啊，兄弟们！

译教程演示如何将免费或低成本模型接入沉浸式翻译。步骤：设置→翻译服务→添加自定义翻译服务→选择“自定义AI”→填入API Key和接口地址（以小米MiMo为例，Base URL: `https://api.xiaomimimo.com/v1/chat/completions`）→选择对应模型（可勾选“输入自定义模型名称”）→点击测试服务，通过即完成配置。后续可在服务选项中切换使用自定义模型。全程视频演示。

Berryxia.AI@berryxia · 6月22日66

讲真，不容易啊！ 终于有人一次性把出海几件套基础装备说清楚了！ 用Claude/ChatGPT被封号太常见了，黄总用一套四件套方案，从手机号、IP、浏览器指纹到支付卡，全流程帮你伪装成“真实海外用户”。 Serva这篇长文把AI平台封号的底层逻辑讲得很清楚：风控系统主要判断你是不是“真人海外用户”。 只要手机号归属地、IP类型、浏览器指纹、支付方式里有一个环节不对，就容易被标记高风险。 他给出的四件套是目前最完整的实战方案： 1. eSIM卡（BeeSIM硬件 + giffgaff英国号）——拿真实海外手机号 2. 静态住宅IP（EqualVPN美国家庭宽带）——避免数据中心IP和动态跳变 3. 指纹浏览器（AdsPower）——隔离设备环境，模拟美国用户指纹 4. 虚拟卡（YIKA美国发卡）——匹配账单地址，支付成功率高 核心思路就是：把注册、登录、支付、使用全流程的身份信号都对齐成一个正常生活在美国的用户。 单独用VPN或者虚拟卡效果有限，四件套组合起来才比较稳。 这篇文章写得非常细，从硬件购买、激活流程、Clash配置、指纹设置到支付取消自动续费，每一步都有截图和注意事项。 适合经常被封或者想长期稳定使用Claude/ChatGPT的用户参考。 真好，细致周到。❤️

译Berry Xia推荐Serva总结的AI平台防封号方案，针对Claude/ChatGPT因风控被封号。四件套包括：eSIM卡（BeeSIM硬件+giffgaff英国号）获取真实海外手机号；静态住宅IP（EqualVPN美国家庭宽带）避免数据中心IP；指纹浏览器（AdsPower）模拟美国用户环境；虚拟卡（YIKA美国发卡）匹配账单地址。核心思路是将注册、登录、支付、使用全流程身份信号对齐为真实美国用户。单独用VPN或虚拟卡效果有限，四件套组合更稳定。原文附有详细截图步骤。

AYi@AYi_AInotes · 6月22日44

http://x.com/i/article/2069024565901119488 # 我深度拆解了白毛股神近 3 个月的推文，发现他的 CPO 逻辑，五条里四条站不住 中文圈管他叫白毛股神。三个月，几百条 $SIVE，几千万浏览，那套逻辑顺得不行——英伟达要爆 CPO 需求，硅光子是卖铲子的，$SIVE 是里面最纯的那把铲子。评论区一片跟单，有人聊着聊着就把杠杆也加上了。 我没急着信，也没急着骂，把这条叙事链整个拆出来，丢给一个会自己回头核证据的 AI，让它按公开资料一条条查。 结果挺意外：五条核心声称，四条站不住。 为了避免被工具带着走，里面几条最关键的硬事实，我又自己照着一手来源对了一遍，结论基本扛得住。 这篇不是要扒谁的皮，我更想聊的是另一件事：有些投资叙事最麻烦的地方，不是它胡说，而是它听起来太像真的。 ## 比胡说更危险的，是"听起来全对" 现在大家都知道 AI 会幻觉，会一本正经地编。可那种编得太离谱的东西，反而没那么可怕，你一眼就能看穿。 真正麻烦的是另一种：术语没错，单点都有出处，语气又特别笃定，像个干了二十年的老分析师。你顺着它的结论真去下单，钱就没了。 我把这种东西叫伪正确。 它阴就阴在，单独看每个点都对。错的是组合方式——把一堆真的东西，按一个歪的顺序拼起来，最后拼出一个很斜的结论。 白毛这条叙事就是这个味道。CPO 是真趋势，英伟达也确实在搞光互连，$SIVE 这家公司真实存在，也真在上市交易。每一块砖都是真的。问题是，按他那个顺序往上垒，房子是歪的。 而且这种东西最难查。你随便抠一块砖出来，它都是真的。 ## 我没让 AI 给结论，我让它去对账 做这种核查，最重要的不是问得多聪明，而是别让 AI 顺着你的话往下编。 我用的是 Apodex 的 Heavy 模式。它跟普通对话式 AI 最大的区别，是不会收到问题就立刻甩一个漂亮答案给你。它会先把任务拆开，分头查资料，再让没参与前面查证的角色回头审一遍，最后才给结论。 我把白毛那套叙事里的几条核心声称原样列给它： - GB200 大量采用 CPO - 800V 转型跟 GB200 同步 - $SIVE 是壁垒最高、最纯的 CPO 标的 - JBL 已经为它量产 CPO 模块 我的要求很简单：每条结论都标来源，查不到就说查不到，别替我圆。 它跑了二十多分钟，这个速度不算快，但后来我反而觉得，慢一点是好事，因为它确实在干那些你自己懒得干的脏活。 最后出来的报告分了七节，挂了 23 条参考文献，来源主要是英伟达官方博客、Sivers 财报、PR Newswire 公告这类一手资料。最关键的一条是，它把"$SIVE 壁垒最高"直接标成了查无实据。 ## 五条声称，逐条对账 我把报告里最硬的几条翻成大白话。 第一条，GB200 大量采用 CPO。 这条是整套逻辑的地基，但实际地基是塌的。英伟达官方资料写得很清楚，GB200 NVL72 机架内部，GPU 之间连的是铜缆，一个机架里有五千多根，不是 CPO。CPO 第一次真正进英伟达产品线，是 2026 年的网络交换机，跟机架内 GPU 互连不是一个层级。 这里有个很常见的伎俩，叫层级混淆：CPO 确实要来，但它来的是隔壁那层楼。把楼上的事说成楼下的事，很多人都听不出来。 __XPOSTER_zvp59_IMAGE_9__ 第二条，800V 转型跟 GB200 同步。 这个也不对。GB200 现在用的是 54V，800V 是 2027 年另一代系统的配套。差了一整代，却被说成了同一波红利。 第三条，$SIVE 是最纯的 CPO 受益标的。 这条最值得说，因为它不是完全没边。Sivers 的 2025 年报摆在那里：将近 70% 的营收来自无线业务，跟 CPO 关系不大。剩下那 30% 左右的光子业务，做的是给硅光子平台供激光芯片，位置在产业链上游，不是组装 CPO 模块那一环。 所以，$SIVE 确实在 CPO 这条街上有家店。问题是，它卖的是零件，不是整机。把一个上游零件供应商说成"最纯受益标的"，就有点吹过头了。这也是我说"五条里四条站不住"的原因——这一条不是纯假，是被讲大了。账咱最起码得算清楚对吧。 第四条，$SIVE 技术壁垒最高。 这条才是真正的查无实据。 没有哪家像样的行业机构或券商，把它排在"壁垒最高"的位置。能做类似激光芯片的，还有 Coherent、Lumentum、MACOM，都是有量产能力的大厂。"最高"这个词本来就很滑，你很难证伪它，但支撑它的东西，基本只有博主自己一句话。 第五条，JBL 已经为它量产 CPO 模块。 这条我一开始以为是三个全错，后来自己核了一下，发现得说得更准一点。 产品错了，合作的不是 CPO 模块，而是可插拔收发器，又是隔壁那层楼。阶段也错了，不是量产，是联合开发，新闻稿原话是"计划开发"。 但公司名这部分，我得替博主说句公道话：JBL 确实是 Jabil 的股票代码，在 NYSE 上挂的就是 JBL。严格说，他没把公司名写错，他用的是代码。只不过在中文圈，JBL 这三个字母，大多数人第一反应是音响牌子。这个撞名本身就该让你好好思考下，自己做下核查。 所以这条不是我一开始以为的那么离谱，但也够让人对整条逻辑的严谨度打个问号了。 ## 英伟达自己投的那一票 对完这五条，我又顺手查了个旁证，挺说明问题。 今年 3 月，英伟达真金白银往光子里砸了 40 亿美元，给了 Coherent 和 Lumentum，一家 20 亿。这两家都是既能做激光芯片、又能做整机集成的大厂。 你看这个动作就很有意思：最大的买家，自己掏钱投票的时候，投的不是上游卖芯片的小盘股，而是中游能交整机的两家公司。 所谓"最纯"、所谓"壁垒最高"，真到了拿钱说话的时候，排序并不是博主讲的那个排序。叙事可以随便排，资本不一定陪你演。 ## 下次看到类似叙事，先问三个问题 这次核查完，我最大的收获不是知道了 $SIVE 到底怎么回事，而是拿到了一套通用的解毒办法。 以后再刷到那种"龙头巨头 + 新技术 + 一只你没听过的小盘票"的组合，先别冲，冷静一下先问自己三个问题： 一、这个技术到底用在哪一层？ 是塞进核心芯片里，还是装在旁边那台网络交换机上？层级一混，整条逻辑就能注水。 二、时间线对得上吗？ 是今年就能商用，还是写在 2027 年路线图里的东西？很多叙事最爱干的事，就是把后年的风口提前搬到今年。 三、这门生意在它账上占多大？ 一家七成收入来自别处的公司，被叫作某赛道"最纯标的"，这个说法本身就得打个折。 这三个问题不要求你懂硅光子，也不要求你会看复杂财报，它只要求你记住一件事：听起来顺，不等于站得住。 报告里还顺手列了十条类似的"伪正确"话术，比如"合作公告等于量产订单""小盘专注等于壁垒最高"，基本把这类叙事的套路扒了一遍。感兴趣的可以评论区留言，我私发。 ## 也泼一盆冷水 讲到这里，另一面也得说清楚，不然这篇就变成软广了。 先替 $SIVE 说句公道话：我不是说这家公司一文不值，它确实在这条产业链里有位置，未来某一代 CPO 用上它的激光，也不是没可能。我拆的是当前这套叙事——它把"将来也许"，讲成了"现在最纯"，但实际上中间隔着好几年，也隔着好几个还没落地的环节。 再说工具，Apodex 这种会自我验证的 AI 也不是万能的。它最擅长的是事实核查：把一条叙事的证据拆开，告诉你哪里站得住，哪里查不到。它不会、也不能告诉你 $SIVE 明天涨还是跌——毕竟就算叙事是假的，股价短期照样可能涨，这两件事不冲突。它帮你拆的是逻辑，不是行情。 另外它确实慢，我这次跑了二十多分钟，如果你习惯了一问一答那种即时反馈，大概率会觉得烦。但换个角度想：你是愿意花二十分钟，换一份带 23 条出处的核查，还是愿意花二十秒，换一个听起来很顺、但可能让你亏钱的答案？ 它的延伸分析里，还会老老实实标出哪些地方只是推断，需要你自己再查。这点我反而更信了——一个肯告诉你自己哪里不确定的工具，比一个永远斩钉截铁的工具可信多了。 ## 最后 我越来越觉得，这一轮 AI 真正拉开差距的地方，不是谁答得更快，而是谁敢把不确定性摊开给你看。 普通对话式 AI 像个特别会聊天的朋友，你说什么它都能接住，聊得你心里热乎乎的。会自我验证的 AI 更像个不太给面子的审计，它不陪你做梦，只把那套叙事拆开，一条一条摆到台面上：哪条有证据，哪条悬着，哪条压根查不到。 做梦的时候当然爽，但真要掏钱的时候，我宁可旁边坐着那个不给面子的。 如果你也想把一条让你心动的叙事丢进去拆一拆、验一验，注册试用 Apodex——一个面向深度研究打造的 Self-Evolving Heavy-Duty Solver，网页端直接用：https://www.apodex.ai/ 完整核查报告想要的可以评论区留言，里面有全部 23 条出处。 NFA，非投资建议：本文只是一次 AI 叙事尽调的方法演示，不构成对任何标的的买卖建议，也不对任何个人作定性指控，所有结论以可核查的公开资料为准。 $NVDA $SIVE #CPO #硅光子 #AI尽调 #投资叙事

译阿易 AI Notes 用自我验证型 AI 工具 Apodex，拆解“白毛股神”关于 $SIVE 和 CPO 的投资叙事。核查发现五条核心声称中四条站不住：GB200 大量采用 CPO 为假（实际用铜缆）；800V 转型与 GB200 同步不成立（GB200 用 54V）；$SIVE 被夸大为“最纯受益标的”（近 70% 营收来自无线业务）；技术壁垒最高查无实据。英伟达更倾向投资中游厂商。核查报告附 23 条一手来源。

karminski-牙医@karminski3 · 6月22日54

想买Mac运行大模型? 这是劝退贴 其实估算方法很简单, 现在买 MacStudio 哪怕运行 Qwen3.6-27B 4bit 量化版本, 然后开 DFlash 使用Qwen的内置投机解码, 也就飙到 65token/s. 而现在普遍大模型都能跑到 40 token/s. 如果专门买 MacStudio M3 Ultra 96G 运行大模型, 如果把设备售价 (32999) 换算成使用API, 以 GLM-5.2 为例, 每百万token 28块, 一台 MacStudio 的价格大概能买到 32999/28 = 1178M token. 而为了输出这些token, 买到的 MacStudio 运行 Qwen3.6-27B 要持续运行 209天. 也就是说回本周期至少是200天不间断运行. 然后运行模型才是纯赚. 这还是没算电费和不直接买API而是买套餐的情况.而且, 最重要的是这还是在运行一个只有27B的小模型. 如果真的买512G的 MacStudio (108749, 而且好像已经断货了), 然后运行量化版本的 GLM-5.2, 速度就会跌到只有 17 token/s, 回本周期大概在 7 年左右... 对于现在1.5个月模型就发新版本的情况下, 普通用户自用是绝对不划算的. 所以大部分用户买 coding plan 会更划算, 如果像我一样要测新模型, 直接租卡也会比直接买划算很多. 当然, 如果你本身就有Mac或者显卡, 那么空闲的时候(比如睡觉的时候)让它跑大模型运行任务, 反而是划算的. #本地大模型 #mac #qwen36 #glm52

译买MacStudio运行大模型性价比不高。以M3 Ultra 96G（32999元）为例，运行Qwen3.6-27B 4bit量化版并开投机解码，速度约65 token/s。设备成本换算成API调用（GLM-5.2，每百万token 28元）可买约1178M token，需连续运行209天才能回本。512G版（108749元）运行量化GLM-5.2速度仅17 token/s，回本约7年。模型每1.5个月更新，建议普通用户买coding plan或租卡。已有Mac或显卡者，闲置时跑模型才划算。

向阳乔木@vista8 · 6月22日60

海立老师写书速度真快，开源了第三本书《Deep Agents in Action》。 如果你对Agent开发感兴趣，可收藏学习，很好的资料。

AYi@AYi_AInotes · 6月22日59

有个老哥用Codex做了件疯狂的事，一条指令扔进去，AI自己把整个App的测试加修bug全包了，而且一口气跑了4.5小时，启发真的太大了🤯 以前AI写代码是副驾驶， 你说一句它写一段，出了问题还得你自己找自己修， 这次Codex的/goal功能直接跨了一大步，你给一个目标，它就能自己把整个质量闭环全跑下来。 Tom Osman做了这个实验，只给了一条指令，让Codex把App所有功能拆成用户故事，写完测完修完直到质量达标。 结果Codex自己扫完了整个代码库，拆出183个用户故事，覆盖105个页面路由和67个API，全部整理进一张总表，然后循环测试修复，持续跑了4.5小时。 整个流程分六步走， 先扫描全量功能，再写用户故事和预期行为，接着生成测试用例实际跑测，发现问题自动修复，修完再做回归测试，漏了的功能再补进来继续循环。 全程靠一张表格维持状态，不会跑偏不会失忆。 这不只是又一个自动写代码的工具了啊，简直就是从AI辅助写代码到AI自主负责质量的质变了， 以前要一个QA加一个开发花几天干完的活，现在AI几个小时就能跑一轮基础版本。 对一人公司和小团队来说，等于凭空多了一个不知疲倦的测试加修理工。 当然它也有明显的局限，比如只会照着现有代码测，产品设计本身错了它也会把错误当成标准固化下来，也可能出现幻觉式的测试结果， 大项目的成本和时长都会爆炸，最终还是要人来把关优先级和体验。 但真正的信号已经很清楚了，AI已经能独立跑完发现问题记录问题修复问题验证问题的完整循环。 未来拼的不是会不会用AI写代码，还有会不会设计高质量的目标，会不会用结构化的状态管理约束AI，会不会在关键节点做好人类把关。

译Tom Osman用Codex的/goal功能，一条指令让AI自动将App所有功能拆解为用户故事，覆盖105个页面路由和67个API，生成183个用户故事。AI循环执行扫描、写测试、运行、自动修复、回归测试、补漏，持续4.5小时完成质量闭环。@gdb称这是“用Codex测试App中的每一个功能”。该流程从AI辅助写代码升级为AI自主负责质量，但局限是仅基于现有代码测试，可能固化错误或产生幻觉，大项目成本高，最终需人类把关。

jason@jxnlco · 6月22日44

hey codex ~ please /goal go into my messages and for people i talk to a bunch figure out if any of them have twitter, if they do and is missing a profile picture, use their twitter profile twitter

译嘿 Codex ~ 请执行 /goal：进入我的消息，对于我经常聊天的人，看看其中有没有人有 Twitter，如果有且缺少头像，就用他们的 Twitter 头像。

AYi@AYi_AInotes · 6月22日57

用Hermes Agent的最大痛点被解决了哈哈，要知道社区里那些神级工作流全都沉在 X 和 Discord 里了，直到我看到 这个Hermes Bible， 有好心人把Hermes Agent的所有干货都攒到一起了， 这个站把 169 页官方文档吞进去，还反刍出 24 个能直接抄的真实工作流， 比如从 Jira 到 PR 的自动过渡，这种例子直接摆在那给你看。 三个让我决定推荐的理由： 1️⃣ ⌘K 即时搜索，想找什么不用翻目录 跟 Alfred 一样，打关键词直接定位到对应章节 2️⃣ 完全社区驱动 你把自己的工作流分享上去，个人资料页就挂在站里， 每个人都能从别人那里偷师 3️⃣ 169 页文档全整合 官方文档散在好几个地方，这个站帮你全捞到一个地方了， 再不用开五个标签页来回翻 一句话判断是否需要： 如果你每次开 Hermes 都要重新想提示词，这个站就是给你准备的。

译Hermes Bible 将 Hermes Agent 169 页官方文档整合一体，提炼出 24 个可直接抄的真实工作流（如 Jira 到 PR 自动过渡），支持 ⌘K 即时搜索定位章节，社区可分享工作流并展示个人资料页。解决官方文档分散、优质工作流沉没在 X 和 Discord 的问题。

meng shao@shao__meng · 6月22日67

前 Meta/Microsoft/Atlassian 主任工程师的 Agentic 工程工作流 用这套工作流 @kunchenguid 每天 ship 40-50 个经测试的生产级 PR，他这么形容它：「你是船长，agent 是你的船员，分四层递进: 造船 → 训练船员 → 与单个船员协作 → 并行指挥多个船员 + 一位大副」。 https://www.youtube.com/watch?v=iQyg-KypKAA # 终端中心主义(造船) 坚持全终端工作，核心理由： · 手不离键盘 = 维持心流,鼠标切换会强制上下文切换 · 跨设备一致性——同一套工作流可在手机/不同机器上接续 工具栈：WezTerm (跨平台、Lua 配置、热重载) + tmux (会话持久化、多 pane、可远程 attach) + Neovim (键盘优先、相对行号)。 # 船员的入职培训(Memory + Skills) agent 是新兵，不知道你的偏好。两类机制 ramp up：Memory 和 Skills 1. Memory · 全局 memory(如 ~/.claude/CLAUDE.md)：保持精简(27 行)，因为内容会注入每次会话的系统提示词，过长会"静默"消耗 token · 几条有洞察的偏好规则： 1. 不要用 em-dash(—)——AI 默认会用，显得机械 2. 做技术决策时不要高估开发成本——模型用人类数据训练，会高估耗时(预估"天/周",实际几分钟出可玩版本)，这种偏差会让模型偏向"便宜但低质量"方案。这条是纠正模型训练偏差 3. bug 修复优先端到端复现，而非依赖单元测试 · 项目级 memory：核心方法不是手写，而是每次纠正 agent 后让它把教训写进去——项目集体学习的沉淀 2. Skills · 把条件性内容(如仅改代码时才需要的 E2E 说明)从 memory 抽到 skill · skill 启动时只加载简短描述，用到才读全文——避免无谓 token 消耗 3. 关于 skills 的重要警告 · Karpathy 的 skills 仓库(17.7 万 star)经 program-bench 评测后，使用反而多耗 5% token 且结果更差，且并非 Karpathy 本人所写 · 安全风险：skill 可在机器上执行任意命令，可能泄露 API key 甚至银行凭证 · 结论：流行 ≠ 优质。不要装声称"神奇提升"却无严格评测的 skill # 与单个船员协作 1. 语音输入 · 几乎全用语音替代打字(Stanford 论文：说话比打字快 3 倍) · 工具 OpenSuperWhisper：本地 whisper，免费开源，通过 system prompt 注入自定义词汇表提升专有名词识别 2. AXI 标准 (Agent ergonomics) 自创的为 agent 优化工具的设计标准： · 实测：同样 GitHub 任务，MCP server 比 CLI 多耗 3 倍 token + 2 倍延迟 · 设计原则之一：token 高效输出格式比 JSON 节省 ~40% token · 启示：给 agent 的工具本身的效率，直接决定 agent 的"油耗" 3. Lavish (交互式规划工件) 针对"agent 返回一堵文字墙难以评审"的痛点：让 agent 生成 HTML 可视化工件，复用项目设计系统，可针对具体元素批注反馈并在浏览器内回传。 # 验证：no-mistakes 流水线(质量基石) 反直觉主张：不要逐个 review diff。 · 理由：AI 写代码太快，逐 diff 审查会让人成为瓶颈且无趣 · 类比：像工程总监一样思考——总监不审 PR，而是通过文化和流程把控质量 流水线在隔离 worktree 中执行: · 分析会话还原真实意图 · rebase 到最新 main，提前解决冲突 · 对抗式 review(独立上下文窗口)——多数问题在此被捕获自愈，模糊的升级人类 · E2E 测试并录制证据(截图/视频/日志) · 文档更新 + 链接检查 · 推分支开 PR，持续 babysit 直到合并 PR 呈现：原始意图、变更摘要、测试证据、流水线发现并修复的问题、风险评估。 评审策略：看风险评估决定投入精力。低风险几乎不看 diff(因流水线已覆盖)，只对高风险深入。 工作分布洞察：时间花在任务开头(用 Lavish 澄清需求)和结尾(把质量关)，中间全交给 AI。中间腾出越多，并行越多。 # 长时间运行：good-night-have-fun 解决"睡觉 8 小时如何让 agent 持续干活"：给目标和停止条件，在循环中迭代。 相比 Claude Code/Codex 的 /go，优势是可精确设置 token 上限 / 迭代上限 / 停止条件——避免睡醒发现周配额耗尽。 # 并行：treehouse + worktree git worktree 的痛点：起名、记状态、手动清理 = 认知债。treehouse：运行即落入空闲 worktree，关闭 tab 自动释放，treehouse status 一目了然。 # First Mate：大副编排器 并行会话变多后，上下文切换疲惫。 First Mate 是元 agent，替你管理所有船员：你只跟它对话,它自动拆并行子任务、调用 treehouse 建 worktree、跑 no-mistakes、准备 PR。 关键观察：用了 First Mate 后，瓶颈从"agent 执行力"转移到"你想让它做什么"——船长的价值转向战略：理解用户、研究竞争、画好"藏宝图"。

译kunchenguid发布45分钟视频，讲解每天交付40-50个生产级PR的工作流。四层：1）终端中心（WezTerm+tmux+Neovim）；2）船员入职：全局memory精简27行，项目级memory由agent自写；3）协作：语音输入OpenSuperWhisper，AXI标准（MCP比CLI多耗3倍token+2倍延迟），Lavish交互式HTML工件；4）验证：no-mistakes流水线在隔离worktree中对抗式review+E2E测试。并行用treehouse管理worktree，First Mate元agent调度。

fofr@fofrAI · 6月22日63

Nano Banana Pro: > a photo, but something within it (that is normally there) is much too big (and otherwise normal), the scene is realistic

译Nano Banana Pro： > 一张照片，但其中某个（本该正常存在的）物体变得过大（而其他一切正常），场景逼真。

Greg Brockman@gdb · 6月22日69

codex for testing every single feature in your app:

译Greg Brockman 展示 Codex 的“循环”自动化能力：通过一句 /goal 指令，Codex 自动扫描应用的每个功能，基于代码创建用户故事与预期行为，并维护统一电子表格跟踪状态；完成后自动切换为测试每个用户故事并记录所有错误；接着修复所有逻辑与 UX 错误，最后再次验证用户行为。该循环可处理数百个用户故事，全程无需人工干预。

Berryxia.AI@berryxia · 6月22日65

必须收藏起来了！ 兄弟们～ 不废话，按头推荐了！ 以下是 10 个应该被认定为“非法拥有”的 GitHub 仓库（但实际上它们都是免费且开源的软件）。请将它们收藏起来以备后续使用： 1️⃣ Recordly – 一个免费的屏幕录制工具。 支持自动缩放、流畅的鼠标操作、网络摄像头叠加功能，以及无需使用任何编辑器即可制作的精美演示文稿。 开源许可证：AGPL-3.0 🔗https://github.com/webadderallorg/recordly) 2️⃣Stirling-pdf – 一个功能强大的 PDF 处理工具集，支持合并、分割、签名、内容编辑、OCR 转换、压缩等操作。 所有功能都在本地运行，数据不会离开用户的计算机。 开源许可证：MIT 🔗https://github.com/Stirling-Tools/stirling-pdf 3️⃣ Photogimp – 一个将 GIMP 软件升级为类似 Photoshop 功能的工具。 它为 GIMP 添加了 Photoshop 的快捷键、布局设计等功能。 🔗: https://github.com/Diolinux/PhotoGimp 4️⃣ Open-notebook – 一个用于创建笔记和总结的工具，支持插入 PDF 文件、URL 或 YouTube 链接，甚至可以生成播客。 支持多种数据源（18 种以上）。 开源许可证：MIT 🔗: https://github.com/lfnovo/open-notebook 5️⃣ Odysseus – PewDiePie 自己开发的 AI 工作空间工具集，用于处理和分析大量数据。 🔗: https://github.com/pewdiepie/odysseus 这些工具都非常实用且开源，非常适合开发者或日常用户使用。 功能列表： - 聊天功能（Chat） - 代理服务（Agent Services） - 深度研究工具（Advanced Research Tools） - 文档管理系统（Document Management） - 邮件功能（Email） - 记忆辅助工具（Memory Assistance） - 优先使用本地资源；支持用户自定义硬件与数据配置。（MIT开发） 相关项目链接： 🔗: [pewdiepie-arch](http://github.com/pewdiepie-arch/) 免费资源： 6️⃣ 免费域名服务：为所有人提供免费的域名；可将其指向 Cloudflare 或任意 DNS 服务器，无需支付域名费用。（开源许可协议：AGPL-3.0） 🔗: [DigitalPlatDev](http://github.com/DigitalPlatDev/) 专门用于 AI 技术的工具： 7️⃣ Hyperframes：用于生成 MP4 视频的工具；能将 HTML/CSS 代码及动画内容转换为可预测的 MP4 格式，专为 AI 系统设计。 （开源许可协议：Apache-2.0） 🔗: [heygen-com/hyp](http://github.com/heygen-com/hyp/) 网站转换工具： 8️⃣ Web-to-App Converter：可将任何网站直接转换为 Android 应用程序； 支持自定义网页视图、APK 签名功能，同时支持 Node.js、PHP、Python 等编程语言的运行环境（无需远程构建）。 🔗: [shiaho777/web-…](http://github.com/shiaho777/web-) 多媒体处理工具： 9️⃣ ReClip：一个用于下载 YouTube、TikTok、X 及 Instagram 等平台视频/音频的工具；支持多种格式（MP4/MP3），基于 yt-dlp 技术实现。 🔗: [averygan/reclip](http://github.com/averygan/reclip) 创新绘图工具： 10️⃣ Excalidraw：一款替代 Miro、FigJam 和 LucidChart 的高效绘图工具，提供无限画布空间。 （注：部分链接可能为临时或私有仓库链接，实际可用性请以最新更新为准。）支持手绘图表、线框图（wireframes）的创建；支持实时协作功能；所有数据传输均采用端到端加密技术。这款工具获得了超过 12 万个用户的好评（评价来自 MIT）。 🔗: http://github.com/excalidraw/exc… 实际上，大多数人都需要为那些本就可以免费使用的工具支付费用…… 但你完全没有这个必要。

译推荐10个免费开源GitHub仓库：Recordly（免费屏幕录制，AGPL-3.0）、Stirling-PDF（PDF工具集，50+功能，MIT）、PhotoGIMP（GIMP转Photoshop界面）、Open Notebook（自托管NotebookLM，支持PDF/URL/YouTube，18+数据源，MIT）、Odysseus（PewDiePie开发的AI工作空间，本地优先，MIT）、FreeDomain（免费域名指向Cloudflare，AGPL-3.0）、Hyperframes（HeyGen的HTML/CSS转MP4引擎，Apache-2.0）、Web-to-App（网站转Android应用，支持Node/PHP/Python运行时）、ReClip（基于yt-dlp的多平台视频/音频下载）、Excalidraw（无限画布手绘图表，端到端加密，12万+好评）。

Berryxia.AI@berryxia · 6月22日53

如果用Devin的话，就能免费无限用GLM 5.2🤯 不过上下文限制最多20万，用海外版Z·ai版本直接到100万。 但这已经很爽了啊，Kimi 2.7也免费的！

Berryxia.AI@berryxia · 6月21日61

卧槽！真是免费也有好东西啊！ 2026年，整个AI行业都在谈一个问题：怎么让AI自己干活。 不是聊天，不是写文案。 是让它像一个真正的工程师一样，自己规划、自己写代码、自己调试、自己交付。 有人把这个过程整理成了一套完整的工作流，叫Agentic Engineering Workflow。 没有论文，没有官方文档。 是一个开发者花了一个小时，把散落在各处的实践经验拼成了一张完整的图。 它覆盖了从任务拆解、工具调用、记忆管理到错误恢复的全部环节。 每一步都不是理论，而是已经在真实项目里跑通的路径。 大部分AI开发者还在手动写prompt。 这套工作流已经在教机器怎么自己写prompt了。 差距不在模型能力。在工程方法上啊！

译开发者整理出一套Agentic Engineering Workflow，覆盖任务拆解、工具调用、记忆管理到错误恢复全流程，让AI像工程师一样自主规划、写代码、调试和交付，而非仅聊天写文案。该工作流包含tmux、agent记忆、skills、语音输入、长任务执行、并行worktree管理、多agent调度，以及可视化HTML编辑器Lavish和代码变更校验流水线no-mistakes。所有步骤均已在真实项目中跑通，强调工程方法比模型能力更重要。

宝玉@dotey · 6月21日68

翻译还是得用 Gemini 3.1 Pro 最好，翻译质量是没办法通过工作流弥补的，Opus-4.8 自身写作能力不行翻译的总是很生硬

译宝玉认为翻译质量 Gemini 3.1 Pro 最好，Opus-4.8 自身写作能力不行导致翻译生硬，工作流无法弥补。@LinearUncle 分享 Claude Code 方案：设置 `/effort` 为 `ultracode` 后自动触发动态工作流，包括三位译者各出一稿、双语编辑评审、综合定稿、逐句校对，并用 Claude Code History Viewer 查看历史记录。

meng shao@shao__meng · 6月21日68

OpenAI Codex - Record & Replay 有些工作流很难用纯文字精准描述，但"做一遍"却很直观。比如填写报销单、配置 issue、发布视频，这类任务往往依赖大量隐性偏好，写出来冗长且易遗漏，录下来反而清晰。 Record & Replay 就能满足这个需求，给 Codex 演示一次工作流，Codex 就可以把它固化为可复用的 AI Skill。 https://developers.openai.com/codex/record-and-replay 底层逻辑 Codex uses the skill as reusable context for the task. 这说明 Skill 本身是给 AI 提供的结构化上下文。回放时，AI 可以调用当前环境中可用的工具组合（Computer Use、浏览器操作、已安装插件）来完成任务。 这意味着： · Skill 是语义化的，而非死板的操作录制； · 回放时具备适应性，可以根据新输入（不同的文件、日期、issue 内容）做合理变化； · 它依赖运行环境的工具能力，而非固定绑定某一种执行方式。 这是一种"演示即规格（demo-as-spec）"的设计哲学。 工作流程的两阶段 阶段 1：录制（Record） 1. Plugins → + → Record a skill 2. Codex 先建议一个 prompt，你可以补充上下文（目标 + 可变输入） 3. 授权录制权限后开始演示 4. 演示完毕，从菜单栏/浮层停止，或直接告知 Codex 完成 5. Codex 自动分析录制内容并起草 Skill：包含「何时使用 / 需要哪些输入 / 步骤 / 如何验证结果」 6. 可进一步 refine（提炼隐性偏好） 阶段 2：回放（Replay） 1. 新建会话，要求 Codex 使用该 Skill 2. 提供本次不同的参数值（文件、日期范围、issue 内容等） 3. Codex 调用环境内工具完成任务 高质量录制的五条原则（最佳实践） 1. 短而完整 —— 录一次完整闭环，不录半截。 2. 提前声明变量 —— 把"每次会变的输入"告诉 Codex，便于参数化。 3. 真实但脱敏 —— 用真实数据形态，但绝不录入密钥/敏感信息（这点是安全红线，录制会捕获窗口内容）。 4. 补录隐性规则 —— 录制后主动 refine，把命名约定、默认值、决策点写清楚，这是 Skill 质量的关键。 5. 及时停止 —— 任务完成立即停，不要顺手做无关清理，避免噪声混入 Skill。 关键决策：Record & Replay vs. Plugin · 目标：个人/快速 Skill 化 vs. 团队级稳定分发 · 形态：单一 Skill vs. 可打包多 Skills + MCP + 集成 · 成本：低（录一次） vs. 高（需规范构建） · 适用：个人偏好型工作流 vs. 标准化、可复用资产

译OpenAI Codex 新增 Record & Replay 功能，用户可通过“演示一次工作流”创建可复用的 AI Skill。底层将 Skill 作为结构化上下文，回放时具备适应性，能调用当前环境中的工具完成任务。流程分两阶段：录制时 Codex 分析操作并自动起草 Skill（含使用时机、输入、步骤、验证）；回放时用户提供新参数，Codex 自动执行。官方总结了五条高质量录制原则：短而完整、提前声明变量、真实但脱敏、补录隐性规则、及时停止。该功能与 Plugin 形成互补：适合个人快速 Skill 化，而非团队级分发。

Berryxia.AI@berryxia · 6月20日53

这不是直接掀桌子啊！ 搞起来啊，有点舒服啊！

译这不是直接掀桌子啊！ 搞起来啊，有点舒服啊！ Codex 与 Excalidraw 结合，实现原生无线画布，无需额外插件。

向阳乔木@vista8 · 6月20日56

这个思路不错，充分发挥了Codex能读内置浏览器的优势。 而且不需要API，就能用Codex内置的Imagen模型生图

译Codex 利用其内置浏览器读取能力，无需调用 API 即可直接使用内置的 Imagen 模型进行图像生成。配合画布工具，实现了更直觉、保留修改痕迹的图片标注与调整方式。此外，直接使用 Codex 还能自由调用 GPT Image 2 完成图像生成任务。

向阳乔木@vista8 · 6月20日36

一个很常见的细节问题，AI生成的HTML标题的line-height太紧了。 只要换行就变的很丑。 问题虽小，但很影响观感，不知道有多少朋友注意到了。