Chubby♨️@kimmonismus · 6月16日59

Not gonna lie, the government accidentally did the best product marketing for routing tools.

译OrcaRouter 发布 DSL 路由工具，对标 OpenRouter 48 小时前推出的 Fusion。其宣称复活了已停止的 Fable 5（来自 Anthropic）级智能，且更便宜、开源、用户掌握密钥。针对 Fusion 的 synthesizer 在深度研究中表现优秀但编码能力差的问题，OrcaRouter 进行了修复：用户只需一个 prompt，即可扩展到任意 panel，经 judge 和 synthesizer 输出高质量答案，并用 YAML 自定义整个流程，实现完全可控。

eric zakariasson@ericzakariasson · 6月16日52

mcp > cli im glad this debase is not as active anymore. i use both every day. they just serve different purposes cli for stuff the model already knows. git, gh, npm, docker, file ops. trained on man pages, and costs almost nothing in context. if im already signed in locally theres no reason to wrap it in anything mcp for most integrations. slack, notion, linear, twitter and its neat to have a protocol for all these integrations - add one server to my teams cursor and everyone gets access - auth once, persists, same locally and in cloud it also just feels better in cursor. rich icons, traceable, you can easily follow whats happening (tbh not reading that much) cli for personal, mcp for team (with oauth)

译开发者比较 MCP 与 CLI 在 AI 工作流中的用途：CLI 处理模型已掌握的任务（git、gh、npm、docker、文件操作），基于 man 手册，本地登录即用，上下文成本极低；MCP 用于集成 Slack、Notion、Linear、Twitter 等外部服务。作为统一协议，MCP 让团队在 Cursor 中添加一个服务器即可全员使用，一次认证持久保存且本地与云端一致，在 Cursor 中提供丰富图标和可追踪性。结论：CLI 用于个人场景，MCP 用于团队协作。

Andrew Milich@milichab · 6月16日54

Use your SuperGrok or X @premium subscription inside Warp

译在Warp中使用你的SuperGrok或X Premium订阅

Berryxia.AI@berryxia · 6月15日59

刚刚群里有人问哪里有PM经理的SKILLS。 这个PM产品经理的Skills已经斩获1.3W Stars 地址：https://github.com/phuryn/pm-skills 自己也mark一份~

译一个专门为产品经理准备的 Skill 包（pm-skills）在 GitHub 上 5 天内获得 13k Stars（约 1.3 万）。该项目覆盖产品经理日常工作范围，但发布者提醒用户警惕大而全的 Skill 包，建议根据实际需求进行微调后再使用。

meng shao@shao__meng · 6月15日67

Databricks 推出「Omnigent」 团队认为：Agent 能力的瓶颈，正在从「模型/harness 本身」上移到「如何组合、治理、协作多个 Agent」。Omnigent 就是针对这一层的新抽象：meta-harness。 它要解决什么问题？ Databricks 从自身实践出发（5000+ 工程师用 coding agent、对外交付 Genie 等产品），归纳出三类真实痛点： · 用户侧：同时开 4–5 个 Agent（Claude Code、Codex、Gemini 等），在 Agent、Docs、Slack 之间反复 copy-paste · 构建侧：新 harness、SDK、模型不断出现，换工具就要重写集成逻辑 · 架构侧：高质量 Agent 系统已是「多模型 + 多 harness + 多人协作」，但每个 harness 只认自己的 session，彼此隔离 Omnigent 是什么？ 基于现有 Agent（Claude Code、Codex、Pi、自研 Agent），提供统一接口、策略层和协作层。 关键设计洞察：无论底层 harness 如何调用 LLM，对用户界面本质相同——messages + files in → text streams + tool calls out。Omnigent 据此抽象出通用 API，同时覆盖 CLI coding agent 和 SDK（OpenAI Agents、Claude Agents SDK 等）。 三大能力支柱 1. Composition（组合） · 一行配置切换 Claude Code <-> Codex <-> Pi <-> 自研 Agent · YAML 定义 custom agent，可跨 harness 移植 · 同一 Agent 内可组合不同 harness 的 subagent 内置 Polly（coding orchestrator）、Debby（model debate）示例 价值：把「选哪个 harness」从架构决策降成配置决策。 2. Control（控制） 区别于 prompt 级 guardrail，Omnigent 在 meta 层做有状态、上下文感知的策略： · 成本策略：按 session 追踪 LLM 花费，例如每 $100 暂停并请求继续 · 上下文安全策略：例如 npm 安装新包后，git push 需人工批准；Agent 只能写自己创建的 doc · OS 沙箱：灵活限制文件系统/网络；凭证对 Agent 不可见，由 egress proxy 在批准请求时注入（如 GitHub token） 价值：策略与 harness 解耦，换 Agent 不换治理逻辑。 3. Collaboration（协作） · 通过 URL 共享 live agent session · 多人同时查看 workspace 文件、评论、甚至发送命令 · 同一 Agent 可从 terminal、Web、macOS 原生 App、mobile、REST API 访问 · 可在本机或 Modal/Daytona 等托管沙箱中运行，便于安全协作 价值：Agent session 从个人终端工具，变成可共享的协作 surface。 为何 Databricks 认为这很重要？ 用 Kubernetes / Terraform 类比：工程师不再管单个进程/服务器，而是管整个 fleet。Agent 领域同理—— 模型和 harness 会持续变化；你工作的抽象层不应随之反复重建。 Meta-harness 让 session、policy、skills 与具体 harness 解耦，形成可迁移的工作层。

译Databricks 推出 Omnigent，一个开源（Apache 2.0）meta-harness，位于 Claude Code、Codex、Pi 及自研 Agent 之上，提供统一接口。三大能力：组合（一行配置切换不同 harness，YAML 定义跨 harness 可移植 agent，同一 Agent 内可组合不同 subagent）；控制（有状态成本策略如每 $100 暂停，安全策略如 npm 后 git push 需审批，OS 沙箱，策略与 harness 解耦）；协作（通过 URL 共享 live session，支持多端访问及实时评论）。理念类似 Kubernetes，让 session、policy 与具体 harness 解耦，形成可迁移工作层。

elvis@omarsar0 · 6月15日53

I also never set /goal by myself. The agent is probably better equipped with its context to help you set a strong goal for longer autonomous runs. Smart to have it as a tool for agents. Exactly how I have it built in my orchestrator app. I even built a little UI for /goal in my orchestrator. Here is something you can try if you want to get better goals that agents follow. Mine your agent sessions, collect goals that performed well, and package those insights/best practices as a skill using an automation. That skill can then be reused with the /goal tool to set even stronger and more reliable goals. Doesn't get more meta than this. I am thinking of doing a live session on this if folks are interested. This is a simple workflow with tons of value and ways to optimize the results of /goal. It turns out that some of the weird behavior of LLM (e.g.g, reward hacking, bias to finish quickly, and other weird shortcuts) creep up a lot when using /goal, so you want to be extremely careful of that. I wrote a little more about better ways to set /goal here: https://x.com/omarsar0/status/2065880971031834786?s=20

译引用推文指出，Codex 可自主查看和设置 /goal，这是元提示的泛化。主推文作者强调，智能体凭借上下文能帮你设定更强目标，因此将 /goal 作为工具是明智之举。他还在编排器中为 /goal 构建了 UI，并建议从会话中挖掘表现良好的目标，封装为技能自动化复用。需注意，LLM 可能出现奖励黑客、偏向快速完成等奇怪行为，使用 /goal 时要格外谨慎。

Tibo@thsottiaux · 6月15日68

Codex can see and set its own /goal. Everything we build, we build also as a tool for the agent. This is a generalization of meta prompting, where you let the agent set its own task based on your intent.

译Codex 可以查看并设置它自己的 /goal。 我们所构建的一切，也都是作为该智能体的工具而构建的。 这是元提示的一种泛化，即让智能体根据你的意图自行设定任务。

🚨 AI News | TestingCatalog@testingcatalog · 6月15日51

Not sure when, but I finally got a new Connected App on the Gemini web. @canva is now available 🔥 There were loads of connectors in development for quite a while, plus mobile apps have much more than the web version. Which ones do you have? 👀

译不确定什么时候，但我终于在Gemini网页上看到了一个新的Connected App。 @canva 现已可用🔥 有很多连接器已经开发了相当一段时间，而且移动端比网页版拥有更多。 你有哪些？👀

elvis@omarsar0 · 6月15日51

I spent the last 6 months building my own harness and orchestrator. I built it to allow me to experiment on the frontier of ideas. Little did I know that the orchestration, the harness, routing capabilities, dynamic artifacts/workflows, verifiers, ability to switch/route between agent backends, automations, the skills, and the MCP tools would be the absolute best defense for what happened with Fable this week. The argument folks made when I was talking about "owning the agent orchestrator" at the beginning of the year is that this is just high maintenance, too costly, and is unsustainable. It might still feel like it to many. But there is too much to lose if you decide to lock yourself in with a specific tool or model provider. Really, the way I have built my orchestrator is through mining my agent sessions and using that to recursively build and test our new ideas that range from autonomous loops to continual learning/memory systems. I can test research ideas on the fly. I just can't go back to using a vendor that only offers me a set of features. My argument now is that you really don't have a choice. You need to be able to control cost, decision making, context management, and everything in between. If you don't, then how are you going to tap into the world of recursive self-improving AI? It won't get any easier if you don't own the decision-making part of the intelligence stack.

译Elvis Saravia（DAIR.AI）耗时6个月构建自有的 agent orchestrator（编排器），具备编排、路由、动态工件/工作流、验证器、agent 后端切换、自动化、技能及 MCP 工具等功能。这些能力在本周的 Fable 事件中成为最佳防御。他年初即主张“拥有自己的 agent orchestrator”，反对者认为维护成本高且不可持续，但他认为锁定特定工具或模型供应商损失更大。通过挖掘 agent 会话递归构建和测试新想法（包括自主循环、持续学习/记忆系统），他已无法回到仅提供固定功能的供应商。他强调必须控制成本、决策和上下文管理，否则无法进入递归自我改进 AI 领域。

elvis@omarsar0 · 6月15日73

To use an LLM Council with your own agent, check out my llm-council skill. It works with Fireworks AI APIs, but you can easily adapt it to OpenRouter. Built for Claude Code, but it might work with other agents. I use it a lot for deep research tasks. Let me know if you would like a full tutorial for this. I have a ton of ideas on how to expand this to other domains and use some of the more recent ideas like dynamic workflows. https://github.com/dair-ai/dair-academy-plugins/blob/main/plugins/llm-council/skills/llm-council/SKILL.md

译Elvis Saravia 开源了 llm-council 技能，专为 Claude Code 等 AI 智能体设计，适用于深度研究任务。该技能默认集成 Fireworks AI 的 API，可轻松适配 OpenRouter。项目代码托管在 GitHub，地址为 dair-ai/dair-academy-plugins。

Chubby♨️@kimmonismus · 6月14日58

This is so cool: OpenRouter launched Fusion: a server-side “panel of models” that sends your prompt to multiple models in parallel. It lets them use web search and bash tools, then has a judge compare their answers and a synthesizer write the final response. Potentially at lower cost than relying on one expensive frontier model. The claim: Fusion beats frontier models on Perplexity’s DRACO deep research benchmark.

译OpenRouter 发布 Fusion API，一种服务器端复合模型，将同一提示词并行发送给多个模型，允许它们调用网络搜索和 bash 工具。系统通过法官模型比较各模型回答，再由合成器生成最终回复。官方声称，Fusion 在 Perplexity 的 DRACO 深度研究基准上击败前沿模型，同时成本更低——以一半价格即可达到 Fable 级别的智能。

Peter Steinberger 🦞@steipete · 6月14日45

Got a PayPal verification text and thought I been hacked, but it was just codex signing up for a web service it needed.

译收到一条PayPal验证短信，以为被黑客攻击了，结果只是codex在注册它需要的网络服务。

Chubby♨️@kimmonismus · 6月14日45

Having access to different AI tools isn't the bottleneck anymore, it is the cognitive load of orchestrating them. LobeHub is tackling this systemic challenge with a new operational paradigm called the Chief Agent Operator (CAO). Instead of requiring users to micromanage individual tasks, the CAO serves as an autonomous management layer handling cross-tool orchestration behind the scenes.

译拥有不同AI工具不再是瓶颈，协调它们的认知负担才是。LobeHub正用一种名为"首席智能体操作员（CAO）"的新操作范式应对这一系统性挑战。 CAO不再要求用户微观管理单个任务，而是作为一个自主管理层，在后台处理跨工具编排。

Yuchen Jin@Yuchenj_UW · 6月14日62

This is super exciting - I’ve been using Omnigent at Databricks for a while, and today we open-sourced it. Omnigent is a meta-agent for orchestrating a swarm of agents. Why do we need this? The best results no longer come from a single model running in a single harness. I used to run the same task with Codex and Claude Code, then pick the better one. But the obvious thing is to let them collaborate, debate, and converge on something better. Omnigent makes this smooth. The other feature I love is real-time collaboration. You can invite people into an Omnigent session to watch, steer, and send commands. Multi-agent, multi-human collaboration is the future. Omnigent was built by @matei_zaharia and a very lean team in just 6 weeks, working every day out of a Databricks war room, truly amazing. Databricks AI really feels like a startup.

译Databricks 开源 Omnigent，一个位于 Claude Code、Codex、Pi 等 Agent 工具和 SDK 之上的元智能体编排框架。它让多个 AI 智能体协作、辩论并收敛出更优结果，同时支持实时人工协作——可邀请他人加入会话观察、引导和发送命令。Omnigent 由 Matei Zaharia 带领小团队在 6 周内建成，现已开源。

Rohan Paul@rohanpaul_ai · 6月13日51

Higgsfield just announced Higgsfield Games, a prompt-to-multiplayer product that can build and deploy 2D or 3D games with generated characters, props, and settings. Build and deploy multiplayer games from one prompt, in any genre, 2D or 3D. The hard part in any game project was turning an idea into code, assets, physics, multiplayer, and launch, and Higgsfield compresses that into one prompt. Claude Fable 5 reason through the game idea while Higgsfield MCP calls the tools that build characters, props, environments, and playable structure.

译Higgsfield 近日宣布推出 Higgsfield Games，这是一款可从一条提示词直接构建并部署任意类型 2D 或 3D 多人游戏的产品，自动生成角色、道具和场景。该产品由 Claude Fable 5 推理游戏创意，并通过 Higgsfield MCP 调用工具完成资产和物理逻辑构建，将创意转化为代码、资产、多人游戏和发布的全流程压缩为单次提示词操作。用户可通过 Claude 的 MCP 界面或 Higgsfield 超级计算机体验。

meng shao@shao__meng · 6月13日65

趁周六把我的「infocard-skills」更新了一版，主要对不同比例下的布局合理性做了提升，避免出现大块空白、或拥挤、截断等问题，保持了原有的瑞士国际主义风格。 看看八种风格下的展示，我自己还比较满意，感兴趣的朋友看这里： https://github.com/shaom/infocard-skills

译邵猛（@shao__meng）更新开源项目 infocard-skills，提升不同比例下的布局合理性，避免空白或截断，保留瑞士国际主义风格。支持 16/9、4/3、1/1 等常见信息卡比例及封面比例，默认 4/3。用户输入内容和比例，AI Agent 使用该 Skill 生成 HTML 并截图输出 PNG。项目开源于 GitHub。

Ethan Mollick@emollick · 6月12日38

Are there toolkits (or skillsets) being created specifically for AIs to use for building games? They default to 3js, reinvent how to make sprites from scratch each time, test technical issues but not gameplay loops, etc. It would help to point AIs at some tools to focus them.

译是否有专门为AI创建的工具包（或技能集）用于构建游戏？它们默认使用3js，每次都从头重新制作精灵，测试技术问题但不测试游戏循环等。 给AI指向一些工具让它们专注会有所帮助。

jason@jxnlco · 6月12日17

whats the best way to get youtube studio metadata out of the site? @OfficialLoganK any plans for webmcp or connectors for youtube as a creator?

译导出 YouTube Studio 元数据的最佳方式是什么？@OfficialLoganK 作为创作者，你们有 WebMCP 或 YouTube 连接器的计划吗？

Alibaba Cloud@alibaba_cloud · 6月12日66

🚀 Taming Agent Chaos? Paper reveals NLAH: Replace rigid code harnesses with executable natural language. ✅ Performance matches code, tokens drop 95% (60k→2.9k) ✅ Modular design enables precise value attribution ✅ Identifies "negative assets" like multi-candidate search Shift from glue code to scientific strategy. 💡https://int.alibabacloud.com/m/1000414388/ #AgentHarness #NLAH #LLMEngineering

译🚀 驯服智能体混乱？ 论文揭示NLAH：用可执行自然语言替代刚性代码框架。 ✅ 性能与代码持平，token减少95%（60k→2.9k） ✅ 模块化设计实现精准价值归因 ✅ 识别“负资产”如多候选搜索 从胶水代码转向科学策略。 💡https://int.alibabacloud.com/m/1000414388/ #AgentHarness #NLAH #LLMEngineering

向阳乔木@vista8 · 6月12日37

最近几次分享的PPT都是用Youmind做的。 玉伯在身边朋友是异类，持续独立思考，总有不一样的视角。 恭喜Youmind，竟然已经两年了，时间过得太快。 不少人觉得玉伯线下和线上感觉反差很大。 一个把真实做原则的人，坦诚到可怕，这种CEO太稀缺了

译Vista 分享近期多次用 Youmind 制作 PPT，祝贺 Youmind 已成立两年。他评价 Youmind 创始人玉伯是身边朋友中的“异类”，持续独立思考，线上线下反差大。玉伯以真实为原则，坦诚到让人感到“可怕”，这种 CEO 非常稀缺。

向阳乔木@vista8 · 6月12日75

现在都是 AI Agent做开发，人喜欢的 PRD 和 AI 喜欢的是不一样的。 为了精准高效开发，写了个专门服务于 AI 的PRD文档生成Prompt。 先有这个文档，再给AI开发，功能完整度和丰富性会远远比自己想的全面、好用。 Skill开发好了，安装指令： npx skills add joeseesun/qiaomu-ai-prd 开源地址和Prompt见评论

译推文提出AI Agent开发中人类与AI对PRD的需求不同，为此发布了一个专门服务于AI的PRD文档生成Prompt（命名为qiaomu-ai-prd）。开发者先使用该Prompt生成文档，再交给AI开发，可显著提升功能完整度和丰富性。安装指令为：`npx skills add joeseesun/qiaomu-ai-prd`，开源地址及Prompt见评论区。

歸藏(guizang.ai)@op7418 · 6月12日68

万字长文：做了些爆款 Skills 以后，我对 Skills 的看法 最近做了几个传播还不错的 Skills后，我对 Skills 的理解也有些变化。 这篇文章算是我目前对 Skills 最系统的一次复盘。 我写了为什么 Agent 不是聊天框，为什么 Agent 会放大人的能力差距，为什么 Skill 可能是普通用户真正用好 Agent 的关键中间层； 也写了一个好 Skill 应该怎么设计、怎么维护、怎么分发，为什么 Skill 生态不能只做成仓库列表，以及内容、产品、案例、反馈之间如何形成一个持续迭代的飞轮。 这不是一篇概念科普，也不是对别人观点的转述，更多是我自己做了一批真实案例之后沉淀下来的判断。 如果你正在做 Agent、AI 工具、插件生态、内容产品，或者想把自己的专业经验变成可复用的能力，这篇文章应该会有一些参考价值。

译@op7418 万字长文复盘爆款 Skills 经验，核心观点：Agent 不是聊天框，会放大能力差距；Skill 是普通用户用好 Agent 的关键中间层。好 Skill 需设计、维护与分发；生态不能只做仓库列表，需要内容、产品、案例、反馈形成迭代飞轮。基于真实案例。

歸藏(guizang.ai)@op7418 · 6月12日68

http://x.com/i/article/2065096982310567936 # 万字长文：做了些爆款 Skills 以后，我对 Skills 的看法 如果看不完的话，可以先帮忙点个赞，收藏一下以后看，感谢。 我最近几次聊 Skills，有一个越来越明确的判断： 大家现在都在说 Agent，但大多数人其实还没有真正理解 Agent。 大众理解里的 Agent，往往还是一个聊天框。 你输入一句话，它回答一段文字；你再输入一句，它继续回答。 这个视角下，AI 好像天然会带来一种平权：以前不会写代码的人可以写代码，不会做 PPT 的人可以做 PPT，不会剪视频的人可以剪视频。 只要模型足够强，大家的能力差距就会被抹平。 但我越来越觉得，这个判断是错的。Agent 不是简单抹平能力差距，而是在放大能力差距。 头部用户已经默认理解 Agent 的组成： 文档、规则、memory、loop、MCP、CLI、工具调用、权限、安全沙箱、上下文工程、定时任务、心跳、文件系统、代码执行和 Skill。 但普通用户只知道“Agent 能写代码”“Agent 可以调用 Skill”，并不知道 Agent 的上限从哪里来，也不知道自己应该如何组织目标、资料和流程，才能让 Agent 真正工作。 > Agent：这里指的不只是聊天机器人，而是能理解目标、规划步骤、调用工具并持续执行任务的 AI 系统。 > Memory：Agent 用来保存长期偏好、项目状态和历史决策的外部记忆，不等同于模型训练记忆。 > Loop：Agent 反复“思考、调工具、观察结果、再决定下一步”的执行循环。 这里就出现了一个很大的认知割裂：头部用户已经在搭系统，普通用户还在问聊天框。 目标清晰、上下文好、品味和判断强的人，会被 Agent 放大； 目标混乱、没有文档、没有判断的人，也会被 Agent 放大混乱。 所以用户会出现 K 型分化。去年还可以靠产品设计、交互设计和用户教育降低一些门槛，今年我觉得已经很难靠简单 UX 弥合这个差距。 Skill 则可以弥合 Agent 使用能力差距。 ## Skill 是能力商品，不只是提示词 我现在对 Skill 的一句话定义是： Skill 是把专家经验、工作流、品味和工具调用封装成可分发、可复用、可迭代的 Agent 能力单元。 > Skill：把提示词、流程、工具调用、模板、脚本、边界和经验打包起来的可复用能力单元。 它不是单纯的提示词，也不是传统意义上的 App。 它更像 Agent 时代的“能力商品”。用户不需要理解底层的 MCP、CLI、workflow、memory、loop、模型选择、代码执行和上下文工程，只需要知道： 它解决什么问题，产出什么结果，怎么使用，别人用得怎么样。 提示词本身很难成为产品。它容易被复制，难以分发，没有版本管理，也缺少安装和调用语义。 Skill 把提示词、规则、示例、工具调用、文件结构、脚本、依赖和使用说明打包起来，让它变成一个可以安装、调用、迭代和传播的能力包。 所以 Skill 和 Prompt 本质上并非完全不同，但 Skill 的调用效率更高，分发和理解成本更低，也能承载更多工程化内容。 更重要的是，很多任务并不是一句提示词能解决的。 它们是一组稳定流程：读取材料，分析需求，选择模板，调用工具，生成产物，验证结果，修复问题，导出文件。 Skill 把这套流程从一次性对话中抽出来，变成可以反复调用的工作流。 比如 PPT Skill 的流程不是“生成 PPT”这么简单。 它要读取文章或大纲，询问主题、页数和配图，选择主题、颜色和版式，生成 HTML PPT，自动后验检查常见问题，再修正缺属性、未居中、溢出、图片裁切、节奏重复等问题，必要时还要调用图像模型生成配图，最后输出可演示、可分享的文件。 这背后真正有价值的，是 Skill 把人的演示经验被外化了。 ## Skill 的核心，是把人的经验外化 我做的设计类 Skill 很能说明这一点。 真正有价值的部分是把人的审美、版式判断、设计系统经验、模板选择、图片裁切规则、明暗遮罩规则、字体和颜色规则固化进去。 这要求创作者同时懂三件事：传统专业知识，AI 的上下限，以及产品化思维。 传统专业知识决定你知道什么结果算好。比如设计、剪辑、写作、健身、法律、商业化投放，每个行业都有大量隐性判断。AI 的上下限决定你知道模型什么能做、什么做不稳、什么必须工程化兜底。 产品化思维决定你知道用户场景、使用门槛、反馈路径和稳定性要求。 这也是我做几个 Skill 时最深的体会。 PPT Skill 最开始不是为了“做一个 Skill”，是因为我真的要做一场分享。 第一版基本成型后，我通过五六轮对话调整间距、字号、字体、颜色、配图、重复内容、WebGL 背景等问题。 讲完之后发现大家最关心的不是分享本身，而是 PPT 怎么做，于是才把这套模板和流程沉淀成 Skill。 社交媒体卡片 Skill 也不是凭空抽象出来的。它来自非常具体的内容分发需求： 3:4 竖版图文卡片，适配小红书、公众号、Twitter 等不同场景。它要处理 11 类内容，两套视觉系统，28 个版式骨架，真实图片 + Coding 排版，还要规避 AI 图限流、文字不锐利、平台风格不匹配等问题。 Logo Generator Skill 也是同一逻辑。它没有直接让图像模型一把梭生成 Logo，因为图片模型的文字、结构和可编辑性不稳定。 它选择先生成 SVG Logo 变体，再生成展示图和 WebGL 背景，把 Logo 本体、展示场景和交互背景拆成不同层，分别用最适合的技术处理。 AI Desk Card 则说明 Skill 的边界可以扩展到物理环境。 它让 Agent 接管屏幕边缘的物理信息位：固件烧录、Wi-Fi 配置、信息推送、定时任务、memory、todo、日历、GitHub 展示、墨水屏刷新，都可以被封装成一套 Skill。 这些案例共同说明：Skill 和核心是“人把什么经验变成了可调用的能力”。 ## 用户不关心概念，用户关心结果 对普通用户来说，Skill、MCP、CLI、Plugin 叫什么并不重要。 他们关心的是：这个功能能解决什么问题，适合什么场景，我点一下能不能用，需要输入什么材料，结果长什么样，别人用得怎么样。 > MCP：Model Context Protocol，可以理解为让 AI 以统一方式连接外部工具、数据源和服务的协议。 > CLI：Command Line Interface，命令行工具；对 Agent 来说，它常常是比图形界面更稳定、更容易自动化的操作入口。 因此，面向用户的产品层不应该堆术语。Codex 把很多东西统一叫插件，我觉得就是一个正确方向：弱化概念，强调功能。 底层可以是 Skill、MCP、CLI 或原生 Plugin；用户只需要知道它能干什么。 但对产品和创作者来说，这些底层形态的区别又很重要。 Skill 适合承载相对垂直、可描述、可复用的工作，比如 PPT、社交媒体卡片、文章配图、写作润色、视频包装、简历优化、数据可视化、某个行业 SOP。 MCP 更适合 Agent 架构中的原子服务和上下文连接，比如地图、浏览器、网盘、设计稿、数据库、企业 API。 CLI 则是目前很现实的通用 Plugin 形态：命令行、代码、Skill 都可以封装进去，也不绑定单一 Agent 平台。 飞书 CLI 就是一个很好的例子。用户不用理解 200 多条命令，也不用知道背后是哪个 API。 他只需要说“帮我把今天的智能纪要拉到笔记里”，Agent 背后可以搜索云文档、读取妙记、下载逐句转写、写入本地 Markdown、建立反向链接。 用户看到的是结果，Agent 用的是工具，Skill 封装的是流程。 这也是为什么 Skill、CLI 和 MCP 的关系不能只从技术概念上理解。 它们最终都要落到一个问题：怎么让普通用户用上头部用户已经验证过的能力。 ## 好 Skill 的架构：中心短，辐射厚 很多人会把 Skill 理解成一个 SKILL.md 文件，这只说对了一半。 > SKILL.md：很多 Skill 的入口说明文件，用来告诉 Agent 什么时候加载这个能力、按什么流程执行、哪些坑不能踩。 好的 Skill 往往是一个目录。SKILL.md 只是入口，旁边还可以有 scripts/、references/、assets/、模板、schema、配置文件、子 Skill 和特殊案例。 复杂 Skill 不怕有复杂内容，怕的是把复杂内容一次性塞给模型。文件系统本身就是一种上下文工程。 > 上下文窗口：AI 一次能“看见”和处理的信息范围，文档、代码、聊天记录和工具说明都会占用它。 好 Skill 的信息架构应该是“中心短，辐射厚”。 SKILL.md 只放高信号流程和判断；references/ 放重文档和领域材料，按条件读取；scripts/ 放确定性逻辑，让 Agent 调用而不是重写；assets/ 放模板、schema、示例、字体、主题和版式骨架；配置文件或稳定数据目录放首次配置、偏好和历史记录。 这里有个很关键的点：Skill 的 description 不是宣传语，也不是功能摘要，是路由触发器。 好的 description 应该描述用户什么时候需要它，最好来自真实用户表达；坏的 description 只是解释“这个 Skill 做什么”。 比如一个 PPT Skill，不应该写“这个 Skill 可以生成漂亮 PPT”。 它应该写“当用户需要把文章、大纲或演讲内容转成可演示 HTML PPT 时加载”。前者是广告，后者是 Agent 的判断条件。 这能解释为什么“把所有能力塞进一个大 Agent”不是好方向。 大而全的 harness 会把工具定义、协议细节和长文档塞满上下文，带来更高延迟、更高 token 成本和更多误用。 反过来，薄 harness 只提供最小运行环境，Skill 作为按需加载的能力包，才能让系统长期复利。 > Harness：运行 Agent 的外层程序，负责模型循环、文件读写、上下文管理和安全边界。 更稳的架构是 Thin Harness, Fat Skills：harness 保持薄，负责跑模型循环、读写文件、管理上下文、执行权限和安全边界； Skill 变厚，承载流程、判断、领域知识、模板、脚本、资产、gotchas 和 eval； 确定性工具下沉给 CLI、scripts 或 API；模型留在理解、判断、综合、取舍和表达这些更适合它的部分。 > Thin Harness, Fat Skills：让 Agent 底层运行环境保持轻，把具体流程、领域知识、模板、脚本和失败经验放进按需加载的 Skill 里。 ## Skill 质量要像代码质量一样维护 好 Skill 不是一次写完。它需要维护，而且要像代码质量一样维护。 一个比较可靠的生命周期是： 1. 先用无 Skill 的 Agent 跑真实任务，找到它会错在哪里； 1. 基于真实 query 写 eval，包括正例、反例和 forbidden load； 1. 先调 description，确保该加载时加载，不该加载时不加载； 1. 写主体时删除显而易见的内容，只保留会改变模型行为的判断； 1. 把失败案例追加到 gotchas，而不是不断加长主流程；改 description 或路由边界时补 eval； 1. 再做跨模型测试，看不同编排模型对 Skill 触发和执行的差异。 > Eval：用一组真实或模拟任务测试 Skill 是否按预期触发、执行和交付结果。 > Gotchas：从真实失败里总结出来的“别这么做”清单，往往比正向说明更能提升 Skill 稳定性。 这里有一个很重要的原则：每个 Skill 都是一种税。 它进入索引后，每个会话、每个用户都在为它的 name 和 description 付上下文成本； 它被加载后，后续对话都在为主体内容付成本。 所以每一句都要问：没有这句，Agent 会不会做错？如果不会，就删。 gotchas 是最高价值内容，因为它们来自真实失败。 正向原则往往模型已经知道，负面边界才是专家经验。 设计 Skill 中“不要纯白纯黑”“连续三页相同节奏是 P0 错误”“文字不能压脸”“AI 图只在无合适真实图时使用”，都属于 gotchas 或强约束。 这也解释了为什么完全自动生成 Skill 只能做初稿。 模型可以帮你起草结构，但它无法凭空拥有你的失败样本、审美判断、行业边界和用户反馈。 真正有价值的是人把经验注入进去，再通过 eval 和 gotchas 让它持续变厚。 ## 设计 Skill 的本质：把品味变成约束 设计类 Skill 不是简单的“AI 会画图”。 它需要解决模型不稳定、图像限流、文字不锐利、排版不可控、风格一致性难判断等问题。 我现在越来越觉得，设计 Skill 的核心是把专业品味变成模型可执行的限制。 模型默认会收敛到一些平庸模式： Tailwind 大色块、紫色渐变、emoji 堆砌、Inter 字体、发光、过度圆角、无意义动效、信息密度失控。这不是模型没有审美素材，而是没有稳定的取舍原则。 所以设计 Skill 里最有价值的是主观但明确的约束： - 不使用纯白和纯黑，降低刺眼和廉价感； - 不让用户任意输入 hex，只提供经过验证的主题色板； - 不用紫色多彩渐变、发光和大面积 blur 作为主视觉捷径； - 动画只在必要时使用，且只动 transform 和 opacity； - 图文卡片优先真实摄影和截图美化，AI 生图只是兜底； - 版式骨架先被人工验证，AI 负责填充、组合和微调；文 - 字必须根据图像主体、明度和可读区域自适应落点、字色、遮罩和断行。 这些规则看起来限制自由，实际是在保护输出下限。 设计类 Skill 的质量来自“替用户排除绝大多数会变丑的选项”。 这也是我几篇 Skill 文章里反复出现的经验： 好看不是玄学，而是可拆解、可编码、可检查的行业常识。 Skill 的价值，就是把这些常识压进 SKILL.md、模板、checklist、主题变量和后验检查里。 PPT Skill 和社交媒体卡片 Skill 的一个共同方法，是把 AI 的任务从“自由设计”降级成“在高质量骨架里填充”。 PPT Skill 里，10 种页面布局、5 套主题色、字体三级分工、7:5 / 6:6 / 8:4 网格、hero 与 non-hero 的节奏交替，构成了一个稳定的演示系统。AI 不需要从零发明版式，只需要根据内容选择合适页面类型并填进去。 社交媒体卡片 Skill 进一步把场景校准到手机信息流： 3:4 是主战场，1 秒决定停不停下。它不是把 PPT 截图成竖图，而是重新定义了图文品类、版式比例、断行规则和素材优先级。 11 个内容品类、两套视觉系统、28 个版式骨架、截图美化、地图组件、真实图库和克制 AI 生图，共同构成了“内容平台视觉 Skill”。 Logo Generator Skill 也是同一逻辑： 不直接让图像模型一把梭生成 Logo，因为图片模型的文字、结构和可编辑性不稳定； 他是先生成 SVG 变体，再做展示图和 WebGL 背景。这里把 Logo 本体、展示场景、交互背景拆成不同层，分别用最适合的技术处理。 所以设计 Skill 的通用公式是： 人工沉淀审美系统，模型理解内容和语义，代码负责稳定排版和导出，图像模型只处理适合它的视觉部分。 这比单纯“让 AI 画一张图”更慢一点，但可控、可改、可复用，也更适合内容创作者长期使用。 ## Skill 生态不能做成仓库列表 如果一个 Skill 能被图文、案例、评价、使用数据、作者、应用场景反向链接起来，它就不只是一个工具，而是一个社区节点。 > 反向链接：从使用案例、文章、图文或项目页面反过来链接到某个 Skill，让人能看到它被谁用、怎么用、效果如何。 当前很多 Skill 展示的问题是： 列表很长，像 GitHub 仓库名；图标都一样；没有结果展示；没有评价指标； 多模态 Skill 也只用文本展示；用户不知道哪个适合自己。 推荐 10 个或 20 个精选 Skill，并讲清楚怎么用，远好过给用户几千个列表。 每个 Skill 都应该像一个软件功能页。页面应该说明： 它解决什么问题，适合什么场景，需要输入什么，输出长什么样，典型提示词是什么，生成结果截图或视频，谁用过、怎么评价，有哪些常见失败情况，如何安装和修改。 这本质上需要强运营。 不是把名字列出来，而是一个一个挑、一个一个写介绍、展示结果，最好还有视频讲解。 GitHub 是代码型 Skill 的天然托管地，因为 Skill 往往包含代码，需要版本管理； GitHub 有生态位、版权声明和分发基础；AI 也熟悉 Git 和 GitHub 操作；开源还能覆盖所有 Agent 平台，不绑定单一产品。 但小红书适合做视觉内容和使用案例分发。 小红书的优势是内容感知、视觉展示、用户审美和评论体系。 PPT Skill 和社交媒体卡片 Skill 都已经在小红书之外的人群中传播，比如咖啡馆主理人、数码测评、活动策划、餐厅、三线城市分享场景。这说明 Skill 能跨出 AI 圈。 应用商店式 Skill 分发也有潜力：更精准推荐、更低使用门槛、可能给创作者分成。 但对创作者来说，如果只在一个平台上架，就等于押注这个平台能做好产品、生态、分发和市场占领。 更稳的策略可能是：GitHub 做基础分发和跨平台覆盖，平台 Skillhub / 应用商店做体验优化、运营推荐和商业转化。 未来的 Skill 平台，本质上会同时是 App Store、GitHub、社区种草页、评价系统和 Agent 工具层。 ## 普通用户真正卡在哪里 AI 圈外的人并非不能用 Skill。 实际观察中，咖啡馆主理人、数码测评、活动策划、健身教练等都能用出好结果。 真正卡点是交互心智。 很多人仍然用传统软件思维，以为一次生成就该完成： 不习惯通过 chat 连续调整；不知道可以要求 AI 改颜色、改字、修溢出、换图；不知道如何提供上下文和素材；也不知道如何从自己的工作流中抽 Skill。 因此，Skill 产品不仅要提供安装，还要提供使用教育。 行业 Skill 会是一个很重要的方向。很多行业有非常好的经验和客户洞察： 健身、法律、餐饮、活动策划、教育、商业化投放等。但行业专家不一定知道如何做 Skill，也担心分享后被盗。 这里的关键不是把 Skill 作为服务添加项。 健身教练可以用 Agent 维护会员饮食、训练、有氧、提醒和反馈，提高客户粘性和服务效率。 法律从业者可以把琐碎文本处理、条文审查、格式检查做成辅助 Skill，但核心判断仍由人完成。 餐饮和活动行业可以用图文 Skill 把真实图片和故事包装成可传播内容。 AI 不能替代线下履约，但可以提高获客、沟通、维护和复用效率。 这类行业用户只需要基础启蒙：带他做一次需求分析，落地成一个 Skill，他就知道边界在哪里。 每个行业都有先锋用户：有创造力、有好奇心、想用 AI 获得竞争优势。先服务这些人。 ## 内容 Skill：文章、产品和案例互相喂养 从我已有文章看，我正在形成一条很清晰的内容 Skill 路线： 不是为某个抽象 AI 概念写文章，是先做出一个能用的 Skill，再把制作过程、设计判断和使用场景写成传播内容。 这类内容有几个特点。 PPT Skill 最初来自一次 AI 和组织分享，观众问得最多的是 PPT 怎么做，于是从一次交付沉淀成开源 Skill。这是副产品变主产品。 文章本身像说明书，但不是 README。 它要讲清楚为什么这样设计、适合谁、边界在哪、真实效果如何，降低用户理解门槛。 产品演示本身就是内容资产。PPT 截图、图文卡片、Logo 展示图、Desk Card 场景图，都可以成为传播素材。 Skill 反过来也提升写作效率。社交卡片 Skill 可以把文章段落直接转成更适合小红书、公众号或 Twitter 的视觉卡片。 每篇文章都在扩展 Skill 的语义边界。 PPT 是演示，Social Card 是内容分发，Logo 是项目品牌资产，Desk Card 是硬件和环境 UI，夜巡录则指向游戏 demo 工作流。 这说明 Skill 不只是“工具产品”，也是内容创作者的表达基础设施。 过去文章和产品是分开的：先做产品，再写推广。现在 Skill、文章、案例、开源仓库、社交反馈会互相喂养。 一个成熟路径可能是：用 Agent 完成一次真实任务，把过程沉淀成 Skill，用 Skill 产出的可视化结果写文章，文章带来用户和反馈，反馈补成 gotchas、模板和下一版 Skill，新版 Skill 再产生下一轮内容。 这就是个人产品在 Agent 时代的复利飞轮。 ## Skill 的边界会继续扩大 过去“插件”通常意味着软件里的一个按钮。现在 Skill 的边界可以明显更大。 浏览器 Skill 会是消费者入口。Tabbit Browser 一类产品说明，Skills 可以进入浏览器场景，变成普通用户在网页、资料、脚本和自动化之间的入口。 浏览器是大众最熟悉的工作环境，如果 Skill 能以“现成脚本 / 使用案例 / 一键执行”的方式出现，会比裸露 CLI 或 GitHub 仓库更容易被理解。 硬件 Skill 则说明 AI 可以接管环境 UI。 AI Desk Card 的价值在于它把 Agent 的能力延伸到了物理环境： 安装固件、配置 Wi-Fi、写 cron、读取 Memory、选择 widget、刷新墨水屏，全流程由 AI 引导。用户不再面对 App 设置页，AI 本身就是设置页。 游戏 Skill 代表更长链路的创作流程。 夜巡录开发手记里提到的“独立游戏 demo Skill”，从玩法母题、原型、素材采集、绿幕抠图、contact sheet、视频生成、音乐、Electron 打包、GitHub Actions 到 Release。 封装是一套跨程序员、美术、动画、作曲和运维的生产流水线。它的价值是把“做个原型”和“独立交付完整作品”之间的墙变薄。 这些案例共同说明： Skill 的未来不只会局限在聊天框里，它会扩展到浏览器、桌面、本地文件、硬件、内容平台、游戏引擎和真实工作环境。 ## Skill 与 Gene：手写经验和自动进化的边界 还有一个值得保留但需要谨慎使用的对比：Agent Skill 与 GEP Gene。 Skill 更像人类预先沉淀的能力包：有明确创建者、明确边界、明确流程和版本。 Gene / Capsule 这类概念强调运行中从成功经验里自动长出能力：带成功率、变异历史、适用上下文和自动修复机制。 > Gene / Capsule：这里指从 Agent 反复执行中的成功路径里沉淀出的可复用经验单元，强调自动演化而不是人工手写。 这两者不是简单替代关系，是不同的层级。 Skill 适合承载人的专家经验、审美、行业 SOP、工具不变式和明确交付标准； Gene 适合从重复执行中捕捉成功路径，把临时试错变成可复用经验；Capsule 类似把多个 Gene 组合成更长工作流。 从当前产品现实看，Skill 仍是更可落地的单位，因为它能被写、被审、被发布、被解释、被传播。 但长期看，自动沉淀 Skill / Gene 化经验会成为方向：Agent 先用通用工具试错，成功后把路径写回 Skill 或生成新的子能力。 这也回应了“自动沉淀 Skill”的讨论。系统可以自动发现重复流程，但是否值得沉淀、如何命名、边界在哪里、哪些失败要写进 gotchas，仍然需要人的判断。 真正理想的形态不是完全自动，也不是完全手写，而是人定义品味和边界，Agent 负责收集证据、提出改动、补充 eval 和维护长尾经验。 ## 盗用不是靠藏，防御方式是持续分发 Skill 很难靠闭源防盗。即便不开源，只要看到产出结果，试用几次，也可能被复刻。 所以防御方式不是“藏起来”，而是开源覆盖更多平台，用影响力威慑过分盗用者，做自媒体让用户知道源头是谁，用持续迭代建立领先，用社区案例和评价体系形成品牌资产。 在产品壁垒降低的时代，个人产品如果没有渠道、资源和营销，就必须自己做宣发。以前自媒体是可选项，现在是基础设施。 ## 平台真正该做什么 如果要做 Skill 平台，不能只押 Skill。用户下载独立端的理由，首先是 Agent 基础体验足够好： 漂亮好用的客户端，多模型支持，尤其国产模型；文件、项目、memory、CLI、MCP、Skill 管理； 权限和安全沙箱；长程任务和状态延续；多设备流转，手机控制桌面，桌面反向控制手机；官方高质量插件开箱即用。 Workbody 的启发是，它没有做特别独特的东西，只是把该有的基础体验做齐了。很多国内产品连这一点还没做好。 一些高频、必须、常见的能力应该内置并打磨好，不要让用户自己折腾安装。 官方插件强，会形成壁垒。多设备、云端和本地互控，也会形成壁垒。 Skill 与本地环境强相关时，移动端需要遥控 PC。 Skill 可跨端通用，但依赖本地文件、脚本、浏览器、CLI 的 Skill 在移动端很难直接跑。 移动端适合轻量级从 0 到 1 创作；桌面端适合重任务和本地环境调用。 自动沉淀 Skill 是长期方向，但好 Skill 仍需要人。Dumate 等产品提出“自动沉淀 Skill”：从用户重复工作中自动总结流程。 这个方向成立，但好 Skill 仍需要业务 SOP、品味、测试和迭代。自动生成可以做初版，真正能稳定交付的 Skill 需要打磨。 ## 一个完整 Skill 生命周期 如果把前面的判断收束成一条路径，一个完整 Skill 生命周期大概是这样的。 先发现真实需求，从自己或行业用户的重复工作开始。 再做一次高质量产物，不要先抽象，先用 Agent 解决真实任务。 然后抽象流程，识别可复用步骤、输入、输出、约束和工具。 接着工程化模板，把审美、版式、调用、验证和修复机制固化。 再做跨模型测试，好模型看上限，差模型保下限。 之后才是封装发布，GitHub 托管，配 README、示例和安装方式。 再做内容分发，用小红书、Twitter、公众号、视频展示结果。然后收集反馈，从 issue、评论区、用户案例和平台数据里找真实问题。 反馈还要筛选，只吸收能提升泛化和稳定性的部分。 这条路看起来长，但它的本质很简单： 每一次真实任务，都不只是在完成任务，而是在积累下一次能调用的能力资产。 Agent 时代最稀缺的是可复用的能力组织方式。 Skill 之所以重要，是因为它第一次让人的经验、工作流和品味，有机会变成一种可以分发、调用、评价和持续迭代的商品。 这可能才是 Agent 生态里真正的大机会。 好，今天的内容就到这里。如果你觉得有帮助，欢迎帮我点个赞，或者转发给你需要的朋友。

译作者认为Agent并非抹平能力差距，而是放大K型分化，Skill可弥合鸿沟。Skill是把专家经验、工作流、品味、工具调用封装成可分发复用的Agent能力单元，如PPT Skill、社交媒体卡片等。好Skill的信息架构应为“中心短，辐射厚”：SKILL.md只放高信号流程，其余依赖文件系统分层管理，以高效利用上下文窗口。

OpenAI Developers@OpenAIDevs · 6月12日69

Introducing developer mode for browser use in Chrome and the Codex in-app browser. Codex can use the Chrome DevTools Protocol (CDP) to debug browser issues by profiling JavaScript performance and inspecting console output, network traffic, and page state.

译为 Chrome 和 Codex 内置浏览器引入开发者模式。 Codex 可以使用 Chrome DevTools 协议（CDP）来调试浏览器问题，通过分析 JavaScript 性能、检查控制台输出、网络流量和页面状态。

Rohan Paul@rohanpaul_ai · 6月12日67

OpenAI is buying Ona to give Codex agents a secure cloud desk that stays open after humans leave. Codex already has 5M weekly users, up 400%, but harder work breaks the old chat pattern because agents need tools, files, credentials, logs, and time. Ona adds persistent cloud workspaces, meaning an agent gets a controlled place to run commands, inspect systems, preserve context, and resume work without depending on one device. The enterprise angle is the real acquisition target: companies want agents inside their own cloud boundary, with scoped credentials, review trails, access limits, and auditable activity. This makes Codexmore like a managed execution layer for tests, bug fixes, refactors, vulnerability work, migrations, and multi-step knowledge tasks.

译OpenAI 宣布收购 Ona，其安全云端执行技术可为 Codex 智能体创建持久云端工作空间——用户离开后，智能体仍可持续运行命令、检查系统、保留上下文并跨设备恢复任务。目前 Codex 周活用户达 500 万（增长 400%）。收购旨在强化企业级部署：智能体可在企业云边界内运行，具备作用域凭证、审核追踪、访问限制和可审计活动，适用于测试、漏洞修复、重构、迁移等多步骤任务。收购完成后，Ona 团队将加入 OpenAI Codex 团队。

xAI@xai · 6月12日73

Install the @sentry plugin and ask your agent to find and fix errors, analyze stack traces, and triage alerts

译Grok Build 插件市场现已进入公测阶段。你可以在终端中使用 MongoDB、Vercel、Sentry、Cloudflare 和 Chrome DevTools 等插件进行开发。详情：https://x.ai/news/grok-plugin-marketplace

xAI@xai · 6月12日70

Use the @vercel plugin to deploy to production, spin up sandboxes, or build apps with Shadcn.

译Grok Build 插件市场现已进入 Beta 阶段。您可以在终端中使用 MongoDB、Vercel、Sentry、Cloudflare 和 Chrome DevTools 插件进行开发。详情请见 https://x.ai/news/grok-plugin-marketplace

xAI@xai · 6月12日70

The @MongoDB plugin is live in the Grok Build Plugin Marketplace. Explore data, optimize database performance, and build high performance vector search systems with a single prompt.

译@MongoDB 插件已在 Grok Build 插件市场上线。 通过单个提示词，探索数据、优化数据库性能并构建高性能向量搜索系统。

Andrew Milich@milichab · 6月12日34

Have been using the @MongoDB plugin to make Grok Build sessions sync across devices - analyzing perf and managing DBs with prompts

译一直在使用 @MongoDB 插件让 Grok Build 会话跨设备同步——通过提示词分析性能和管理数据库

xAI@xai · 6月11日73

The Grok Build Plugin Marketplace is now in beta. Build with MongoDB, Vercel, Sentry, Cloudflare, and Chrome DevTools plugins from your terminal. Read more https://x.ai/news/grok-plugin-marketplace

译Grok Build 插件市场现已进入 Beta 测试阶段。 从终端使用 MongoDB、Vercel、Sentry、Cloudflare 和 Chrome DevTools 插件进行构建。 了解更多 https://x.ai/news/grok-plugin-marketplace

Rohan Paul@rohanpaul_ai · 6月11日52

The cold open in this Parloa video is every dev’s API stress list. docs, middleware, auth, error handling, retries, data mapping.... There has to be a better way. Parloa just launched Agent Skills, an MCP-based layer to replace brittle API glue with self-healing agent workflows. Their success numbers: first integration a day, the second an hour, every use case after that is config — and a top-10 travel co cut average handle time by over a minute.

译Parloa 发布 Agent Skills，基于 Model Context Protocol (MCP) 构建，旨在替代脆弱的 API 胶水代码。业务团队可在 AI Agent 管理平台 (AMP) 上零代码配置完整集成链，集成时间从 4-8 周缩短至数小时。关键特性包括：工具调用逻辑一致且能自愈、可定义成功条件追踪真实结果、执行链可审计可重试。早期数据：平均处理时间减少 67 秒，通话转接中客户沟通提升 39%，多工具路由可靠性提高 20%。首个集成一天完成，第二个仅一小时，后续用例只需配置。一家 Top-10 旅游公司平均处理时长缩短超一分钟。

数字生命卡兹克@Khazix0918 · 6月11日69

http://x.com/i/article/2064933671258439680 # 从0到1带你速通WorkBuddy，这可能是最适合国内的Agent产品。 之前我写了Claude Code和Codex的从0到1的新手教程，反响都还不错。 但写完之后，评论区里一直有一类声音说，这些工具是好，但是用不了啊。 确实，这两个产品虽然强，但它们对国内用户来说并不友好。 而大家日常的办公需求又是实实在在的。 然后，就有很多朋友问，能不能讲一讲，WorkBuddy的教程。 坦率的讲，WorkBuddy确实也是我觉得国内为数不都的，口碑还不错的通用Agent产品了。 所以这次，我也决定写一篇WorkBuddy的从0到1的教程。 带很多用不了Claude Code和Codex的朋友，用上这个国内我觉得是最棒的平替了，而且几乎Windows版本跟Mac一样，这个对国内用户真的挺友好的。 如果你不需要那么硬核的开发能力，也不愿意折腾，那相信我，WorkBuddy几乎能覆盖你日常办公场景里七八成的需求。 我会用一个日常的办公任务和一个简单的开发任务，两个实际案例来串起整篇教程。 跟着做，你也能上手。 OK，直接进正题。 # 一. 安装 第一步肯定就是安装了。 官网地址在此：workbuddy.cn Mac、Windows都支持，选你系统对应的版本下载就行。 我这里用的是Mac，所以就拿Mac来做演示。 下载完正常安装。 打开之后登录。 选择微信，再扫码，非常丝滑。 我真的，已经很久很久很久没对着一个Agent产品直接微信扫码登录了。 就像出来发现外面的世界根本没下雨，原来Agent产品也可以不用那么折腾的啊。。。 然后你就进来了。 个人体验版免费，能干点很简单的东西，个人专业版58块/月，适合重度用户，而且也不贵。 上周五腾讯刚开了一场发布会，正式推出了WorkBuddy企业版，类似我之前写过的Accio Work的企业版，如果你是企业用户有这方面需求，可以自己去了解一下。 # 二. 认识界面 主界面大概是这么个布局。 我们一起来快速过一遍界面，了解每个区域是干嘛的。 正中间这一大块，就是跟WorkBuddy交互的对话区，一般使用，有三个场景模式可以切换，分别是代码开发、日常办公、设计创意，几乎覆盖了绝大多数的办公人员了。 这三个模式是跟下面的快捷方式联动的。 你切到代码开发，下面出来的就是日常开发、网站开发、Agent应用、Skill开发这些。 切到日常办公，变成文档处理、数据分析及可视化、深度研究、幻灯片这类。 切到设计创意，就是网站设计、移动端App、PPT设计、交互原型、品牌设计这些。 然后下面的模板，点进去还有一层。 比如你选了日常办公中的文档处理，会展开一组更细的提示词模板。你把里面的内容替换成自己的实际需求，改改就能发。 产品的便利性和体验上，我说实话，这个还是国内做的更好一点。 再看对话框下方，左边有一排选项，我们从左到右过一遍。 第一个是工作模式，三种模式，能力从下到上是逐级递增的。 Ask，就是纯聊天，你问它答，跟你平时用豆包那种对话框是一样的。 Plan，是先出计划再动手，如果你是新手，对AI干活还没什么安全感，可以用这个模式先过一遍再开干。 Craft，是平时干活的Agent模式，大部分情况就是用这个。 这里提醒一下，WorkBuddy默认就是Craft模式。也就是说你随便发一条消息，它就直接开干了，积分也就开始消耗了。 所以如果你只是想聊两句、问个问题，记得先切到Ask，如果还没想清楚怎么做，就切到Plan。 模型方面，WorkBuddy内置了绝大多数的国产大模型，腾讯混元、DeepSeek、GLM、Kimi都有，不同模型消耗的积分不一样，这块你就别问为啥没有GPT、Claude之类的了。 不同模型擅长的方向不一样，每个人喜欢用的也都不一样，你完全可以根据自己的任务类型和偏好来选。 但如果你真不知道选啥，或者就想要一个最通用的，我就无脑推荐你使用DeepSeek V4 Pro，目前我感觉最适合绝大多数的C端用户的，价格低，且综合能力强，世界知识、Coding、Agent能力等等几乎前面覆盖了，除了没有多模态，在国内相比，几乎都是水桶级的。 当然，如果你有自己的偏好，那就按自己的来。 如果你有自己的API Key，想用自己的模型，WorkBuddy也支持接入外部的。 点击设置。 在模型页面里点添加模型。 只要是兼容OpenAI协议的API都能接。 说完模型，权限这一块，它提供了默认权限和完全访问权限两种，没啥特别的，跟其他的Agent一样，默认权限就是遇到高风险操作会先停下来问你。 我自己不管啥Agent，选的一般都是完全访问，因为每次弹框我一般也就是点确认，说实话也看不太懂那些提示，那还不如就别烦我，全交给它自己跑。 还可以使用技能和连接器，这个我们后面会详细展开。 右边的加号，可以上传文件，包括本地文件、腾讯文档以及知识库，这个比较好的一点事跟ima知识库全面打通了，如果你是ima的重度用户，那你一定会觉得非常香。 最下面还有一个选择工作空间。 工作空间，可以理解成项目文件夹。你可以选择当前任务要使用的目录，选择完成后，WorkBuddy会基于该目录读取和处理文件。 也可以直接开始任务，WorkBuddy会在默认目录中生成结果。 任务创建成功后，新任务会出现在左侧任务列表中。 如果一开始没选工作空间也没关系，任务完成后你也可以再存进工作空间。 保存后，能开启多个agent同时协作。 并且会存到空间的目录里。 同时，在你电脑里也会相应的出现一个新文件夹。 说到这里提醒一句，前期分类真的很重要，不然等后面任务堆多了，找起来是真的头疼。 大概的界面就是这样。 然后就是重点了，左上方的功能区，有助理、项目、专家、自动化、以及文件、知识库文档和灵感。 我们一个一个来介绍。 # 三. 专家和技能 点击左侧上方的专家。 顶部可以切换专家、技能、连接器三个页面。 这三个还是有些区别的。 先说专家，你可以把专家理解为，一个已经全面封装好的垂直Agent。 WorkBuddy里内置了100多个专业领域的AI专家。 进入专家中心，里面按行业分好了类，每个专家都有自己的能力卡片。 点击之后就进入对话了，用起来跟平时没什么区别，只是它现在换了一个专业视角的专家Agent在帮你干活，你直接说需求就行。 比如，一个微信小程序的专家，擅长的领域是小程序开发、微信生态、WXML开发，你想做个小程序，直接召唤它，关于微信开发所需要的行业知识、技能还有一些其他的东西，已经全部帮你封装好了。 你像前天刚高考完，WorkBuddy就上新了一个高考专家，能刷真题、换算一分一段、查院校专业。考生朋友们，接下来报志愿就能用上了。 也能看到我的资讯速递专家，一句话就能查到每天精选的AI动态，自动整理成中文简报。 大家可以自己去体验一下，我就不王婆卖瓜了。 专家是一个Agent帮你干活，专家团则是是一群Agent一起协作，这个肯定打大家都比较好理解了。 你把任务丢给专家团，团长自动帮你拆任务，分给不同的专家并行跑，跑完再整合结果交付。 比如一个软件开发的团队，会有交付总监作为主理人，负责统筹，底下有产品经理、架构师、工程师、QA工程师，一整条研发流水线全配齐了。 就很像当老板的感觉就你往那一坐，说一句帮我搞定，然后一群AI员工们就嗡嗡嗡地开始干了。 不过因为是多个专家同时跑，积分消耗大概是单个专家的3到5倍，毕竟多个Agent之间来回通信，还是挺贵的。 当然，你也可以自己创建专家，点右上角的我的专家进去。 再点击创建专家。 然后大白话告诉它你想做什么方向的专家就行。 如果你在某个领域有自己成熟的方法论和一些技能，完全可以把它封装成一个专家，以后反复调用，甚至分享给别人。 再来说技能。 技能这个东西大家就很好理解了，就是Skills。 WorkBuddy在这块，做出了一些国产特色，还是比较有意思的，他们做了一个完整的Skills市场，确实对于很多的用户都极度友好。 推荐里面是官方精选的一些技能，很多都是官方自己的。 当然这里面，也有我的Skill。 而Skillub里面全是大家做的各种Skill，基本上已经非常全了，热门的都有，想要啥你基本都能直接搜到。 套件就是把一组相关的技能打包在一起。 在Claude code以及codex里面就是插件的意思。 如果你也想自己做一个，点右上角的添加技能，选创建技能。 然后用大白话告诉它你想实现什么功能就行。 还有一个就是连接器，也就是大家常说的MCP。 一句话来解释，就是把WorkBuddy跟你日常在用的外部服务打通。 比如昨天很爆的瑞信咖啡的Skill，他们也有MCP版。 WorkBuddy在MCP这块最大的优势，就是能跟腾讯的整个生态无缝打通。 比如QQ邮箱，连接之后可以直接发送、搜索和整理你的邮件，还有腾讯会议、腾讯文档，都可以接进来。 还有能够看行情数据的通达信MCP，造福炒股的朋友们。 如果你是QQ邮箱用户，这个就太香了，操作也简单，点击QQ邮箱的MCP。 再来扫个码。 在手机端确认授权，就搞定了。 其他服务同理，按照提示一步步操作就行。 也支持右上角自定义连接器。 WorkBuddy在支持的技能生态这块，做的还是比较完整的，对国内的用户，确实体验相当的友好。 # 四. 修改设置 我猜你看到这里已经跃跃欲试了。 但接下来的设置环节，我还是非常推荐你跟着我走一遍，有些东西调好了，后面用起来会顺畅非常多。 头像点进去，打开设置页。 系统设置里面有两个开关，建议你可以打开。 一个是技能自动更新，这个很重要，因为WorkBuddy有Skills广场，所以其实生态是很完整的。打开之后你装的那些Skills有新版本了会自动升级，不用自己总是要去手动下载升级。 另一个是锁屏远程，这个跟Codex和Claude差不多，就是打开之后你电脑不会进入休眠状态了，免得出个门发现电脑休眠WorkBuddy直接躺了。 系统授权里的权限也可以点击去授权，都打开。 然后，把对话记忆打开。 它会从你们的对话中提取关键信息记下来，以后碰到相关的事会自动调出来用。 当你们的对话越多，它就越了解你的习惯和偏好。 如果之前你用过其他Agent，还能直接把那边的记忆导过来，搬家很方便。 接下来，在个性化设置里，配一下自定义指令。 自定义指令，之前在Codex和Claude Code教程里的也都说过，类似于最高等级的CLAUDE.md文档，整个Agent的最高级文档，你给Agent定下的顶层规矩。 这块给大家推荐一个非常通用的，适合大家的来自大神卡帕西的模板，可以直接复制粘贴用上。 减少常见LLM编码错误的行为准则。可根据需要与项目特定指令合并。 **权衡：**这些准则倾向于谨慎而非速度。对于简单任务，自行判断即可。 ## 1. 先思考再写代码 **不要假设。不要隐藏困惑。把权衡摆到台面上。** 在动手实现之前： - 明确说出你的假设。不确定就问。 - 如果存在多种理解方式，全部列出来——不要默默选一个。 - 如果有更简单的方案，说出来。该反驳就反驳。 - 如果有什么不清楚的，停下来。说明哪里让你困惑。提问。 ## 2. 简洁优先 **用最少的代码解决问题。不写投机性代码。** - 不加超出需求的功能。 - 一次性代码不搞抽象。 - 没人要求的"灵活性"和"可配置性"不要加。 - 不要为不可能出现的场景写错误处理。 - 如果你写了200行但50行就能搞定，重写。问自己一句："一个资深工程师会说这写复杂了吗？"如果是，简化。 ## 3. 精准修改** 只动必须动的地方。只清理自己制造的问题。**编辑已有代码时： - 不要顺手"改进"旁边的代码、注释或格式。 - 没坏的东西不要重构。- 匹配现有风格，即使你会用不同的写法。 - 如果注意到不相关的死代码，提一嘴就好——别删。当你的修改产生了孤立代码时： - 移除因你的改动而变成未使用的import、变量和函数。 检验标准：每一行改动都应该能直接追溯到用户的需求。 ## 4. 目标驱动执行 **定义成功标准。循环验证直到确认通过。**把任务转化为可验证的目标：- "加验证"→"为非法输入写测试，然后让测试通过"- "修这个bug"→"写一个能复现它的测试，然后让测试通过"- "重构X"→"确保重构前后测试都能通过"对于多步骤任务，列出简要计划：1. [步骤]→验证：[检查项]2. [步骤]→验证：[检查项]3. [步骤]→验证：[检查项] - 不要动原本就存在的死代码，除非被明确要求。 强成功标准让你能独立循环推进。弱标准（"让它能跑"）则需要不断澄清。 --- **这些准则起作用的标志是：**diff中不必要的改动更少了，因过度复杂化而返工更少了，澄清性问题出现在实现之前而不是犯错之后。 一切就绪，你终于可以开始，玩Agent了。 # 五. 办公任务 我们先给大家看个办公任务，WorkBuddy在办公这块确实花了不少心思。 点击办公模式。 选你电脑文件存放的文件夹，WorkBuddy能直接读取里面的文件。 或者直接点对话框右边的加号上传文件也行。 再选好模型后，输入提示词。 比如我让他帮我基于上周的公众号数据，生成一个报告，在周会中进行汇报，虽然我也不知道我要跟谁汇报。。。 旁边有个优化提示词的按钮，可以点一下让它帮你润色。 出来的效果长这样，变成了一个有结构化提示词，对于不像Opus 4.8这种级别的超强模型来说，喂一个结构化提示词进去，出来的效果确实会好不少，这个也是之前不少研究验证过的结论。 确认完就开始跑了，界面上能看到一个Todo清单，正在执行哪一步、接下来做什么，进度很清楚。 跑完的效果长这样。右侧边栏可以查看任务产出的文件和预览内容。 也能直接打开文件夹看生成的东西。 基本上，你在办公中能想到的跟办公有关的需求，无论是文档、还是数据、还是PPT啥的，你都可以让WorkBuddy来干，而且干的还不错。 # 六. 开发任务 除了通用的办公需求之外，我们接下来，再来做个好玩的开发向。 一起来搓一个小网页。 我们切到代码开发模式。 再点击网站开发。 我让它帮我做一个WorkBuddy的功能介绍网页，要包含所有的功能，好看且有设计感。 使用plan模式，优化提示词。 回答几个问题。 一会就做完了，中间的过程我就不截图了，反正都是它自己在做，我干别的事情也没再管。 右侧栏里能直接预览，嫌小的话也可以点击右上角在浏览器里打开看整体的效果。 怎么说呢。。。这个配色AI味有点重了，紫色看得我有点PTSD。 于是我用一个前端开发的Skill，让它重新优化了一版。 过程同样就不截图了，最后效果如下图，这版看着就舒服多了。 同样的，我们自己还有个我们自己的服务器管理的Skill，我们可以继续对话，来让WorkBuddy帮我们把这个小网页，调用我们的服务器Skill把它部署上线。 不过开发这块我得说句实在话，目前国产模型在代码能力上跟最顶尖的确实还有段距离，做小项目、搓个网页之类的问题不大，但真碰上复杂的大工程。 我极力推荐你，克服一切困难，想办法用上Claude Code或者Codex。 七. 远程控制 再来讲一个很实用的功能，远程控制。 远程控制跟Claude Code和Codex还有点不太一样，它是原生跟微信打通了，毕竟都是腾讯自己家的产品嘛。 当你不坐在电脑前，也能让WorkBuddy帮忙处理工作。 打开功能区里的助理功能。 点击旁边的设置。 在设置里，把这两个打开。 然后掏出手机微信扫上面这个码，打开小程序，授权登录。 连接成功后你就能看到左上角有个已连接。 手机端的小程序分为两种模式，一个是云端工作，一个是连接电脑。 云端工作，是指任务在云端沙箱跑，不需要你电脑开着。 连接电脑，则是远程操控你本地电脑干活，适合需要读取电脑里文件的任务。 举个实际的场景，比如我在外面，突然需要把电脑里一份文件发到财务的邮箱里。换做以前，我只能回去后发，还会耽误其他人的工作进度，但是现在手机上跟它说一声，就可以了。 不过，实现发送邮箱的前提是，我在一开始就配置好了qq邮箱的连接器。如果你还没有连接配置，也可以让它把电脑文件直接发到小程序的对话框里。 一会就发出去了。 财务那边也确实收到了。 除了小程序，还可以接微信的ClawBot插件，不过我个人体感，小程序上的体验会更好且更稳定。 而飞书、钉钉、QQ也都可以接助理，点击配置后按照流程来做就行。 # 写在最后 我一直觉得，对于绝大多数人来说，Agent的核心价值不是帮你写出最牛逼的代码，而是帮你把每天那些重复的、琐碎的、让你浑身难受的办公任务给自动化掉。 发个邮件、整理个数据、做个PPT、跑个简单的小网页。 这些事情，WorkBuddy已经完全能干了，而且干的还挺好。 我之前写Claude Code和Codex教程的时候，评论区最多的一类留言就是，「好是好，用不了啊」。这句话我看了几百遍，每次看到都觉得挺无奈的。 所以这次也算是给大家补上了一块拼图。 希望大家工作愉快。

译WorkBuddy是一款国内通用Agent产品，支持Windows和Mac，微信扫码登录，个人专业版58元/月。界面提供Ask/Plan/Craft三种工作模式和代码开发、日常办公、设计创意三个场景，内置DeepSeek V4 Pro、腾讯混元、GLM、Kimi等国产模型。专家中心有100多个垂直领域AI专家，支持专家团多Agent协作。技能市场（Skills）和MCP连接器可打通QQ邮箱、腾讯会议、腾讯文档等生态，也支持自建技能和连接器。上周五腾讯推出WorkBuddy企业版。

meng shao@shao__meng · 6月11日75

14天、5个人、Vibe Coding => MiMoCode ?! 国产 Coding Agent +1，基于 OpenCode fork 二次开发，保留其核心能力，并在其上叠加了记忆、上下文管理、子智能体编排、Goal 驱动自主循环、Compose 工作流，以及 Dream/Distill 自我进化机制。技术栈为 TypeScript + Bun。 和 MiMo 模型的关系：内置 MiMo Auto 限时免费通道（零配置），也支持小米 MiMo 平台 OAuth、Claude Code 认证迁移，以及任意 OpenAI 兼容 API。它是 MiMo-V2.5 系列模型在 Agent 场景下的 官方配套 Harness，模型能力与框架深度耦合。 https://github.com/XiaomiMiMo/MiMo-Code

译小米发布MiMo Code，一款基于OpenCode fork开发的Coding Agent。由5人团队在14天内通过Vibe Coding完成，保留OpenCode核心能力，叠加记忆、上下文管理、子智能体编排、Goal驱动自主循环、Compose工作流及Dream/Distill自我进化机制，技术栈为TypeScript+Bun。内置MiMo Auto限时免费通道（零配置），支持小米MiMo平台OAuth、Claude Code认证迁移及任意OpenAI兼容API。作为MiMo-V2.5系列模型的官方配套Harness，模型能力与框架深度耦合。已开源至GitHub。

meng shao@shao__meng · 6月11日62

再次强烈推荐「Agentic Engineering Patterns」 作者 @simonw 2026 年 2 月起撰写，每周约新增 1–2 章，目前仍在演进。文字由他本人撰写，示例与代码借助 LLM 辅助。 在线阅读： https://simonwillison.net/guides/agentic-engineering-patterns/ 核心目标：如何用好 Claude Code、Codex 这类能写代码、也能执行代码的 coding agent，拿到可靠、可维护的结果。 # 核心概念：Agentic Engineering ≠ Vibe Coding Vibe Coding vs Agentic Engineering · 定义来源：Karpathy 提出 vs Willison 提出的专业实践 · 适用人群：常与非程序员原型相关 vs 专业工程师放大既有能力 · 代码质量：未审查、原型级 vs 审查、测试、可上线 · 人的角色：几乎不参与代码理解 vs 定义问题、验证结果、持续改进 harness Agent 的定义： 在循环中调用工具以达成目标。Coding agent 的关键差异是能执行代码——没有执行能力，LLM 输出价值有限；有了执行，agent 才能迭代到"确实能跑"的软件。 人的工作并未消失，而是上移： · 决定写什么代码（问题空间有数十种解法与权衡） · 提供工具与足够细的规格 · 验证结果是否稳健可信 · 把经验写回指令与 harness（LLM 本身不会从错误中学习，但系统可以） # 全书最重要的一个判断 写代码变便宜了，写好代码并没有。 过去几十年，工程习惯都建立在"代码昂贵"之上： · 宏观： 大量设计、估算、排期，功能必须数倍覆盖开发成本 · 微观： 是否重构、写测试、补文档、做 debug UI——每个决定都受时间约束 Agent 把这个约束打碎。一个人还能并行跑多个 agent，同时实现、重构、测试、写文档。 但"好代码"仍有明确标准： · 能跑、且被证明能跑 · 解决对的问题 · 处理错误路径，不只 happy path · 简洁、可维护 · 有测试与合适文档 · 设计留出演进空间（YAGNI 与可扩展性的平衡） · 满足安全、可观测性等 non-functional 要求 新习惯： 当直觉说"不值得做"时，不妨开个异步 agent 试一下——最坏情况是浪费几分钟 token；很多过去"不划算"的改进，现在值得做。 # 五大原则层（Principles） 1. 定义边界 Agentic Engineering 是专业工程师用 coding agent（能写能跑）放大能力；不等于 vibe coding（不审代码的原型玩法）。人的核心工作：定目标、给工具、验结果、把经验写回 harness。 2. 接受新约束 写代码几乎免费，写好代码仍然贵。旧习惯（过度规划、跳过测试/文档/重构）要推翻；直觉说「不值得做」时，不妨开个异步 agent 试一下。 3. 囤积可复用解法 积累带可运行证明的代码片段（仓库、笔记、小工具）。最强用法：把两个已验证例子拼进 prompt，让 agent 组合出新方案；每个技巧人类只需解决一次。 4. 质量应上升，而非下降 技术债、命名混乱、大文件拆分等「简单但耗时」的清理，交给后台 agent 做，成本已低到可零容忍 code smell；用原型并行验证技术选型；任务结束做回顾，把有效做法写进指令（复合工程）。 5. 严守反模式 绝不提交自己没审过的 PR。合格标准：确信能跑、体量小、有上下文、描述自己读过、附测试证据。否则只是把活甩给 reviewer。 # 实操层：与 Agent 更好的协作 1. 先懂机制，再谈用法 Agent = LLM + 系统提示 + 工具循环。你不必背实现细节，但要清楚： · 对话越长越贵；agent 会尽量利用 token 缓存 · 模型无状态，每次重放上下文 · 能执行代码才是 coding agent 与普通 LLM 的分水岭 · Reasoning/Thinking 对调试复杂问题尤其有用 2. Git：大胆用，不必背 把 Git 当 agent 的「时间机器」和「安全网」： · 新会话恢复上下文：Review changes made today · 救场：Sort out this git mess for me · 找丢了的代码：Find and recover my code that does ... · 定位回归：Use git bisect to find when this bug was introduced · 修 commit / 抽库留历史：Undo last commit / 从新 repo 复制模块并保留 commit 历史 3. Subagent：省上下文，不是炫技 上下文有限，大任务要「分身」： · Explore：进陌生 repo 先摸清结构，汇总给主 agent · 并行：多文件独立改动可同时跑，可用更便宜模型 · 专家（审查 / 跑测 / 调试）：隐藏冗长输出，只回报结果 原则： 为省 token 而拆，不为拆而拆；主 agent 够用就别过度分工。 4. 测试：三层防线 ① TDD：先写测 → 确认失败 → 实现至通过 ② 建立测试意识：新会话先跑全套测试 ③ 手动验：python -c / curl / Playwright 真浏览器 ④ 留证：Showboat 记录命令与真实输出，防编造 5. 理解代码：还认知债 Agent 产出若成黑盒，会积累 认知债（类似技术债，拖慢后续决策）： · Linear walkthrough：线性导读，用 grep/cat 引用代码，禁止手抄 · Interactive explanation：在导读基础上做可暂停、可调速的动画演示 适用： 陌生代码、自己忘了细节的代码、vibe code 出来却没看过的代码。

译Simon Willison 撰写《Agentic Engineering Patterns》指南（2026年2月起连载），阐述专业工程师如何用 Claude Code、Codex 等 coding agent 获得可靠可维护结果。核心区分：Agentic Engineering ≠ Vibe Coding。关键判断：写代码变便宜了，写好代码并没有。五大原则：定义边界（人的工作：定目标、给工具、验结果、把经验写回 harness）、接受新约束、囤积可复用解法、质量应上升而非下降、严守反模式（绝不自审 PR）。实操：Git 作 agent 时间机器、Subagent 省上下文、三层测试防线、线性代码导读消除认知债。

meng shao@shao__meng · 6月11日69

Claude Fable 5 实现零传统编辑的 Launch 视频生产：Remotion + FFmpeg + Figma MCP 端到端实践 来自 Claude Code 核心开发者 @trq212 的又一次高质量分享：他全程未打开任何传统视频编辑软件，仅通过提示驱动 Claude Fable 5 生成代码、调用工具、迭代优化，最终产出 4K、3 分钟成品视频。 https://thariqs.github.io/cc-video-editing-deck/ # 核心流程与关键步骤（高度结构化、可复现） 原材料准备：17 个拍摄 take（约 25GB Sony S-Log3 4K 原片），分为 4 个场景（Intro、Thought Partner、Goals & Verification、Be More Ambitious）。 Step 01：转录与理解 · 一条完整提示启动整个流程：要求使用 ElevenLabs / Whisper（本地 M4 Max 运行）对所有视频进行逐词时间戳转录。 · Claude 生成 JSON 格式的详细转录，支持精确到帧的定位（即使 Whisper 误听名字如 “Thariq” 为 “Sark”，时间戳仍准确）。 Step 02-03：智能选片与剪辑决策 · Claude 作为子 agent 逐场景分析所有 take，挑选最佳版本（优先零 ums、完整脚本、干净结尾）。 · 输出 final-edit.json（EDL 编辑决策列表），包含每个 clip 的起止时间、候选 take、详细选片理由。 · 直接用 FFmpeg 执行 JSON，实现精确拼接（第一版可在几分钟内生成可观看的 2:50 粗剪）。Claude 还会自验证转录结果（“zero ums”）。 Step 04：颜色分级（Color Grading） · 从 S-Log3 平面原片出发，Claude 手写多个 .cube LUT（7 个自定义 LUT，如 neutral_cool_desat、warm_filmic 等）。 · 通过提示迭代生成示例，作者选择后应用 FFmpeg 编码。突出代理在专业视觉任务中的潜力（虽有色域专家指出可能存在细微 gamma/管理问题，但整体可用）。 Step 05-08：图形叠加与设计迭代（Remotion + Figma MCP） · 输入 11 张静态设计 PNG（interludes/overlays）。 · Claude 将 PNG 重构为 Remotion React 组件（JSX），每个文字、颜色、动画均为可提示参数。 · 定义全局 timing knobs（6 个关键帧参数）和 cue sheet（基于转录词时间戳精确对齐叠加，如在 “right” 一词出现帧上触发动画）。 · 通过 Figma MCP 导出为真实 Figma 文件，支持设计团队审阅/调整滑块。 · 设计反馈转回提示 → Claude 更新代码 → 重新渲染，实现高效 code <-> Figma 往返。 最终渲染：npx remotion render 生成 3840×2160@24fps、4334 帧、653MB 成品。 Claude 会先逐帧截图自审，再全渲染。整个过程在几天内完成（主要在 Jun 6-9），凌晨 6:24 交付。 底层架构（“The edit is text”） · 整个项目是一个代码仓库：转录 JSON、final-edit.json、LUT 文件、Remotion 组件、anim.tsx。 · 无时间线、无项目文件，一切可 diff、可 grep、可提示修改。 · 强调 agent 协作哲学：“Treat Claude like a thoughtful partner” — 给出清晰目标、验证方法，保持雄心。 · 结果：从 raw 文件夹到成品，agent 承担绝大部分“中间劳动”，作者主要提供 taste 和最终把关。

译Claude Fable 5 通过纯提示驱动，端到端生成 4K Launch 视频。从 17 个 Sony S-Log3 4K take（约 25GB）出发，流程包括：Whisper 逐词转录、Claude 作为子 agent 选片输出 JSON 编辑决策列表 (EDL)、FFmpeg 拼接粗剪、手写 7 个自定义 .cube LUT 颜色分级、通过 Remotion + Figma MCP 将 11 张设计 PNG 转为 React 组件并实现代码↔Figma 往返迭代。最终渲染 3840×2160@24fps、4334 帧、653MB 成品，全程未打开视频编辑器。

jason@jxnlco · 6月11日71

fun little trick called '$request-design-best-practices-from-anthropic-design-team' heres the prompt! 1. make a first pass 2. create a figma file 3. message the design team on slack to fix everything about the design 4. profit great video tho! we do something very similar! but i've been very impressed at fable's taste around sound design too

译开发者 @trq212 展示如何用 Fable 通过代码和工具调用完成其自身启动视频的编辑：调用转录服务、ffmpeg、调色、Figma MCP，制作 Remotion UI 并渲染，全程未手动操作视频编辑器。主推文作者 Jason Liu 幽默总结了一个“向 Anthropic 设计团队请求最佳实践”的流程，但对 Fable 的用法表示赞赏。

Thariq@trq212 · 6月11日56

Lots of people asked how I used Fable to edit its own launch video so I made a video about that! TLDR it wrote a lot of code &amp; tool calls to use transcription services, ffmpeg, do colorgrading, use the figma mcp, make remotion UI and render it. I didn't touch a video editor.

译很多人问我怎么用 Fable 编辑它自己的发布视频，所以我做了个视频来解释！ TLDR：它写了很多代码和工具调用，来使用转录服务、ffmpeg、做调色、使用 figma mcp、制作 remotion UI 并渲染。 我根本没碰视频编辑器。

Xiaomi MiMo@XiaomiMiMo · 6月11日79

🚀 MiMo Code V0.1 is now live and open-source！ More than an AI coding assistant in your terminal — it's the smartest coding partner you'll ever work with. Comes with MiMo V2.5, a multimodal model available free for a limited time, featuring a million-token context window—ready to use out of the box. ♾️ Infinite Context: Knowledge accumulates automatically, and with lossless compression, even million-line projects keep every critical detail intact—quality never drops. 🧠 Agent-Model Synergy: An Agent framework deeply optimized for MiMo, with a full closed loop of testing, review, and validation—so complex tasks get done in one pass. 📝 Compose Mode: Specs → Plans → Build → Report. Design first, code second—clear thinking, no rework. 🔄 Self-Evolving System: Every session is automatically reviewed, distilling experience and best practices—the more you use it, the smarter it gets. 🎙️ Voice Input: Powered by MiMo-V2.5-ASR — just speak instead of type, and your voice becomes the prompt for truly hands-free coding. 🔌 Claude Code Compatible: Automatically loads your existing skills, MCP servers and commands, and reuses your API configuration—zero-cost migration, no setup required. 🌐 Open & Flexible: MIT licensed, with support for leading model providers including Anthropic, OpenAI, DeepSeek, Kimi, GLM and more. Install in one line: Mac & Linux curl -fsSL https://code.xiaomimimo.com/install | bash (For the best experience，we recommand Mac user use it on iTerm or vscode terminal) Windows npm install -g @mimo-ai/cli 🔗 Learn more Website ↓ https://mimo.xiaomi.com/mimocode Blog ↓ https://mimo.xiaomi.com/zh/blog/mimo-code-long-horizon GitHub ↓ https://github.com/XiaomiMiMo/MiMo-Code

译小米推出开源终端 AI 编程助手 MiMo Code V0.1，附带限时免费使用的多模态模型 MiMo V2.5，支持百万 token 上下文窗口。核心特性包括：无限上下文（自动知识积累与无损压缩）、Agent-模型深度协同（测试-审查-验证闭环）、Compose 模式（规格→计划→构建→报告）、自进化系统、语音输入（基于 MiMo-V2.5-ASR）、兼容 Claude Code（零成本迁移），以及 MIT 许可、支持 Anthropic、OpenAI、DeepSeek、Kimi、GLM 等主流模型提供商。

宝玉@dotey · 6月11日62

Claude Design 有一个完整的 Agent 运行环境，如果把它跟 Claude Code 比较的话，只是它基于浏览器和虚拟机来构建的。它有45个工具，有24个内置skills。运行方式也是基于 Agentic Loop。 所以它就是一个完整的 Agent Harness。

译Claude Design 具备完整 Agent 运行环境，基于浏览器和虚拟机，内置 45 个工具和 24 个 skills，采用 Agentic Loop。有团队质疑其仅为单个 Agent，宝玉回应：它就是一个完整的 Agent Harness。

Claude@claudeai · 6月11日72

New from Code with Claude Tokyo: scheduled deployments and environment variables in vaults are in public beta in Claude Managed Agents, and dynamic workflows in Claude Code are generally available. Agents now run on a schedule, use your tools securely, and take on bigger jobs.

译Code with Claude Tokyo 新功能：定时部署和保险库中的环境变量已在 Claude Managed Agents 中进入公测，Claude Code 的动态工作流已正式可用。 Agent 现在可以按计划运行，安全使用你的工具，并承担更大的任务。