蓝星玩家Oasis

AI 👽
机器人 🤖
Play in Public 👾

[宝玉 @dotey]

之所以研究 Claude Design，是因为最近摸索出一套不错的开发模式：

1. 先用 Claude Design 去设计 App 的 UI 和 UX，第一版本越简单越好。

Claude Design 交付的结果是 HTML + CSS + React + data.js，通过 CSS 一下就可以看清楚设计系统的颜色系统、尺寸规范，通过 React 可以看清楚组件结构，通过 data 可以知道数据结构什么样子。

这几个组合可比 figma 对于 AI 来说友好多了，尤其是 data.jsx，这是一般的设计 App 不会有的，但对开发特别重要的。

还有一个优势就是交付的结果都是文本格式的，可以一起提交到 git 做版本管理，用 git diff 就可以清楚的让 AI 知道设计稿修改了什么。

2. 把 Claude Design 生成设计稿交给 Claude Opus 4.8 去实现一个 MVP，第一个版本只实现 UI 功能，告诉它技术栈（比如 AppKit 而不是 SwiftUI），通过几个小版本的迭代，让它逐步完善。比如第一个版本只是主界面

之所以不用 GPT，是因为 Opus 在 UI 实现上比 GPT 好太多，同样的设计稿，GPT 实现的各种细节问题的，不能很好的遵守设计稿。

之所以不一下子实现太多功能，是因为功能越少 Agent 越容易聚焦，做出来效果越好。所以怎么拆分版本，也是用好 Coding Agent 的一种能力。

非 UI 的功能，用什么模型没有那么大差别，所以我也会用 Codex 配合非 UI 工作。

3. 每次生成一个版本，要让它可以运行，无论是 Agent 还是人都是需要即时反馈的，有了反馈才知道方向对不对，才知道下一步要做什么。

人在测试的时候，能发现各种问题，代码问题就让 Agent 去修改，UI 设计有问题不是马上修改代码，而是要去 Claude Design 去修改设计稿，设计稿修改完了，把设计稿下载回去，替换本地的设计稿文件。

设计稿替换后，让 Agent 去 git diff 分析一下变更，给它个截图，都不用多说它就知道怎么改了。

4. 版本稳定后继续新一轮迭代

当设计的功能做完之后，不一定是要马上去设计新的功能，而是可以重新审查一下实现的代码，重构优化一下。

比如我在第一版实现后，让 Opus 4.8 去做了性能分析，看性能问题在哪，然后告诉我当前用 NSScrollView，内容一多就内存暴涨，建议 NSTableView。

我心想这不应该是一开始就该考虑到的么！不管怎么样亡羊补牢也不算晚。

性能优化完就继续加功能，更新设计稿，让 Agent 参考新设计稿优化功能。

---

再回来说研究 Claude Design 的事，因为反复 Claude Design 修改，同步到本地，然后这一步让我后来很烦，因为需要在本地和 Claude Design 网页切换，还要导出下载到本地，解压缩替换。

于是我就想能不能在本地就可以重现 Claude Design 直接集成到本地 Agent，所以我去研究了 Claude Design，然后发现完全可以本地跑起来，只是本地 Agent 在工具调用上有些差异，以及不方便直接在设计稿上标记编辑。

上周正好 Codex 发布了直接调试 iOS 的功能，它带了标记修改的功能，然后我灵机一动，这不正好可以代替 Claude Design 的标记修改功能么。（图2）

问题是 GPT 5.5 模型设计能力不够，在 Codex 里面设计效果也不会好。

接着 Cursor 也发布了网页标记功能，这下正好，Cursor 里面可以用 Opus 4.8，做成 Skill 就可以本地运行了，还可以在 Cursor 内置浏览器中，直接标记、评论修改。

好在 Claude Code 的核心逻辑都在浏览器前端，他们在网页上做了个 Harness，这给了我分析的便利，耐心一点就可以分析出所有的 Prompt、内置 Skills、初始组件，再针对 Cursor 的工具做一些兼容就可以跑起来了。（图3）

测试对比了一下和在 Claude Design 上跑的效果差不多。（图4）

归根结底，还是 Claude Desktop 太拉胯了，Claude Design 本应该集成在 Claude Desktop 的，不然也不需要我这么折腾。

当然不折腾下我也没机会学习 Claude Design 优秀的设计，真的很棒，接下来会系列更新我的学习心得。

推荐去试试最终的 Skill，让你本地就可以跑 Claude Design：
https://t.co/d2EaYV6q7j

[DeepSeek @deepseek_ai]

🚀 DeepSeek-V4 Preview is officially live & open-sourced! Welcome to the era of cost-effective 1M context length.

🔹 DeepSeek-V4-Pro: 1.6T total / 49B active params. Performance rivaling the world's top closed-source models.
🔹 DeepSeek-V4-Flash: 284B total / 13B active params. Your fast, efficient, and economical choice.

Try it now at https://t.co/GCdiMzk1Dl via Expert Mode / Instant Mode. API is updated & available today!

📄 Tech Report: https://t.co/drlDrxkYtp
🤗 Open Weights: https://t.co/T13Y8i7SDM

1/n

[Thariq @trq212]

https://t.co/45C3gKydTK

[松果先森 @songguoxiansen]

微软开源了语音AI模型：VibeVoice，目前已27K的Star了

主要包括3个模型：

1、VibeVoice-ASR-7B：文本转语音 (TTS) 模型。
VibeVoice-ASR是一个统一的语音转文本模型，可一次性处理60分钟的长音频，生成包含“谁（说话人）”、“何时（时间戳）”和“什么（内容）”的结构化转录，并支持自定义热词。

2、VibeVoice-TTS-1.5B：自动语音识别 (ASR) 模型。
90分钟长篇语音生成、支持在一次对话中最多4个不同的说话人、生成富有表现力听起来自然的语音

3、VibeVoice-Realtime-0.5B：实时文本转语音 (TTS) 模型。
实时TTS（延迟约300毫秒）、可长篇语音生成（约10分钟）

有人还用VibeVoice-ASR做了一个语音输入法：Vibing。
亲测识别速度和准确率还行，macOS和Windows可用。

[Matt Dancho (Business Science) @mdancho84]

OpenAI, Google, and Anthropic just published guides on:

• Prompt engineering
• Building agents
• AI in business
• 601 AI use cases

9 of the best guides you can't miss:

[GitHubDaily @GitHub_Daily]

Mac 电脑用久之后，系统缓存、应用残留文件堆积如山，磁盘空间莫名其妙就满，想清理又怕误删系统文件。

在 GitHub 上找到 MacOptimizer 这款实用的开源工具，专为 macOS 设计的系统优化助手，界面简洁直观，功能相当强大。

提供八大核心模块，涵盖系统监控、应用卸载、垃圾清理、大文件查找等常用功能，开箱即用。

GitHub：https://t.co/GdzYBzujNy

应用卸载不仅能移除应用本体，还会自动扫描偏好设置、缓存、日志等八类残留文件，支持选择性删除或一键清空。

另外还内置了文件管理器，可以直接浏览整个磁盘目录，支持显示隐藏文件、终端集成等功能，日常管理文件也挺方便。

项目提供 DMG 安装包，也支持 Homebrew 一键安装，适配 Apple Silicon 和 Intel 芯片，值得尝试一下。

[AIGCLINK @aigclink]

英伟达最新开源的一款ASR：Nemotron Speech ASR，专攻低延迟实时语音智能体场景，多人同时对话不爆延迟

单句最终转录锁定只需24ms，端到端全程<500ms，长语音不会累加等待时间

核心是其在FastConformer架构里加了一套缓存感知机制，已经算过的语音特征全部缓存在显存，不再二次编码

新音频只算增量，帧级复用。好比说，以前每翻一页书都要把前面几页重读一遍，现在直接夹书签只读新段落

延迟模式可动态配置，80、160、560毫秒、1.12 秒等，无需重新训练，可根据应用需求灵活选择来平衡延迟和WER

基于Nemotron Speech ASR还给了一个AI语音助手构建示例，LLM用的Nemotron 3 Nano 30B，TTS是Magpie

在此配置下，Nemotron Speech ASR实现了最终转录的中位时间为24毫秒，且不受话语长度影响，长音频片段与短音频片段一样可以快速完成转录

#ASR #NemotronSpeechASR #AI语音助手

[流氓兔🐰 @LiumangtuCrypto]

Google现在免费提供AI培训。

10门课程。面向商业。有证书。

这是完整列表。

[Greg Brockman @gdb]

Introducing ChatGPT Health: https://t.co/HnzAoH6UtV

[歸藏(guizang.ai) @op7418]

Skywork 上线了视频 Agent 能力，他们这个流程有意思

你可以从第一个分镜开始，左边生成之后，将生成的视频和音频素材发到右边的视频编辑器里面去进行编辑。

支持使用主流的视频模型和能力，文生、图生、首尾帧都有，另外支持生成音乐和语音。

我用首尾帧做了一条香水广告的演示，还不错。

也上线了一些特效模版，你可以不用管提示词直接复用。

而且会员从昨天（0106）开始会有为期七天的无限使用优惠，只要你是会员就可以一直用。

最近有需求的朋友们可以看看，说不定这几天直接回本了。

[Google Antigravity @antigravity]

Turning "To-Dos" into "Done."

Ask Antigravity to create Jira tickets directly from your code. No tab switching, no manual entry, just AI-powered project management.

Back to actual coding. ☕️

[AI Will @FinanceYF5]

Andrej Karpathy 直接展示如何通过提示在 30 分钟内构建应用。

[马天翼 @fkysly]

Anthropic 官方最新推出了《Claude Code in Action》实战课程，总共10节课程：从理解 Claude Code 代码助手的工作原理开始，然后介绍如何安装配置、上下文管理、代码变更以及使用高级功能，如 MCP 服务器、GitHub 集成和钩子实现。

[Boris Cherny @bcherny]

I'm Boris and I created Claude Code. Lots of people have asked how I use Claude Code, so I wanted to show off my setup a bit.

My setup might be surprisingly vanilla! Claude Code works great out of the box, so I personally don't customize it much. There is no one correct way to use Claude Code: we intentionally build it in a way that you can use it, customize it, and hack it however you like. Each person on the Claude Code team uses it very differently.

So, here goes.

[蓝星玩家Oasis @BlueStarOasis]

这个版本最喜欢的更新是可以控制GPT输出内容的长度，只需要短回答却得到一大段输出的体验有时候还是很糟糕的。

[OpenAI @OpenAI]

GPT-5.1 in ChatGPT is rolling out to all users this week.

It’s smarter, more reliable, and a lot more conversational.

https://t.co/SA1Q1GPyxV

[宝玉 @dotey]

Every 的一篇博文，记录了他们内部 6 位工程师日常是怎么使用 AI 的，可以学习借鉴一下。这 6 个人都很厉害，撑起了 4 款 AI 产品、一个咨询业务，还有一个 10 万多读者的订阅每日更新。

第 1 位 —— 走在实验前沿：Yash Poojary, Sparkle 总经理

Yash 是 Sparkle 产品的负责人，他同时开两台电脑，一台跑 Claude Code，一台跑 Codex，然后给它们下达同一个任务，看它俩谁干得又快又好。

Yash 说，在五个月前，他得先把设计图（Figma）截图，再粘贴到 Claude 里，让它“看图写代码”。现在用上了 Figma MCP 集成，Claude 可以直接读取 Figma 的设计源文件——包括颜色、间距、组件这些。

Yash 不仅在用AI，他还在优化和AI的配合。比如，他把一天切成两半：
- 上午：专注执行。 这时候只用自己最熟的AI工具（Claude 和 Codex），绝不玩新东西，保证产出。
- 下午：自由探索。 这时候才开始测试各种新出的AI应用和功能。

他很清楚 AI 既是生产力工具，也是个“时间黑洞”。他用严格的时间管理，给自己建立了“防护栏”，防止自己沉迷于“调教AI”而忘了真正的工作。

第 2 位 —— 编排闭环：Kieran Klaassen, Cora 总经理

Kieran 负责 Cora 产品，他的风格是““谋定而后动””。

他的工作流核心就两个字：计划。

他会根据功能的大小，制定三种不同级别的编程计划。他会用一个叫 “Context 7 MCP” 的工具，先把最新的、最准确的官方文档和代码喂给AI，确保AI不是在“凭空想象”或用过时的知识来制定计划。

等Claude Code 交出一个完美的计划后，他再把计划发到 GitHub，然后在云端让 Coding Agent（主要是Claude Code）去执行这个计划。AI写完代码后，他会再启动一个““审查””命令，让AI自己先检查一遍，然后他再上手。

对 Kieran 来说，AI 不是一个“黑匣子”，而是一个必须在他制定的蓝图内严格执行的“施工队”

第 3 位 —— 化繁为简，拆解里程碑：Danny Aziz, Spiral 总经理

Danny 负责 Spiral 产品，他可能是这群人里最硬核的一位。

他的主战场不在花哨的图形界面，而是在一个叫 “Droid” 的命令行工具里。这个工具能让他同时调用 OpenAI 和 Anthropic 的模型。

他的工作流是：
1. 用 GPT-5 Codex 做大的任务：搭建复杂功能的框架。
2. 用 Claude 做小的任务：优化和打磨代码细节。

Danny 最有价值的一个做法是，他会在““规划阶段””花大量时间跟AI对话，让AI帮他推演一个决策可能带来的第二层、第三层后果”。

举个例子：“我要加这个新功能，但你帮我分析一下，它会不会因为从数据库拿数据的方式，导致整个App变慢？”

他用AI来辅助自己做更高维度的“架构思考”，而不仅仅是写几行代码。

> “我不再用 Cursor 了，”他说，“我已经好几个月没打开过它了。”取而代之的是，他的主界面是 Warp，可以在上面分割屏幕、快速切换任务。在它背后，他用 Zed ——一个轻量、快速的代码编辑器——来审阅计划文件和特定的代码片段。

第 4 位 —— 让流程成为唯一的“事实来源”：Naveen Naidu, Monologue 总经理

Naveen 负责 Monologue 产品，他是个“程控”。他的信条是：“如果一个任务没录入 Linear (项目管理工具)，那它就不存在。”

他把所有需求和Bug都先在 Linear 里归档，然后再启动AI。他也有两套流程：
- 小Bug：直接从 Linear 复制粘贴问题描述，扔进 Codex Cloud 让AI去跑。
- 大功能：在本地写一个详细的 https://t.co/1aLAUFxX5j (计划文档)，把它作为和AI沟通的“唯一事实蓝图”，在命令行里一步步推进。

最有意思的是，他深度使用自己开发的产品 Monologue (一个语音转文字工具) 来口述需求、写文档、给AI下指令。这简直是““用自己造的锤子，来修自己的房子””。

他还有一套严格的审查标准：AI 自动审查 -> 自己人工对比代码 -> 查看Sentry（错误监控工具）的日志，确保Bug真的被修复了。

第 5 位 —— 钻研打磨，精益求精：Andrey Galko, 工程主管

Andrey 是工程主管，他代表了另一种工程师：不爱折腾。

他不喜欢追逐“闪亮的新玩具”。他之前一直用 Cursor (一个AI代码编辑器)，觉得体验最好。但后来因为 Cursor 改了定价，他一周就把免费额度用完了，这才“被迫”换工具。

他换到了 Codex。他认为以前的 OpenAI 模型写的代码很“懒”，经常跳步骤，不如 Claude 好用。但现在的 GPT-5 Codex 已经进化得非常强，连以前 Claude 的强项——用户界面(UI)——都能搞定了。

第 6 位 —— 极致的专注：Nityesh Agarwal, Cora 工程师

Nityesh 是 Cora 的工程师，他的风格和第一位 Yash 截然相反。他追求极致的专注。他的装备极简（一台MacBook Air），他的工具也极简：只用 Claude Code。

但他用 Claude Code 的方式很特别：
1. 他会花好几个小时，先和 Claude 一起研究、制定一个巨详细的计划。
2. 一旦开始编码，他就待在一个终端窗口里，“像老鹰一样””盯着 Claude 输出的每一行代码，手指就悬在 Escape 键上，一旦发现不对，立刻中断它。

最近，他甚至故意频繁地打断AI，强迫AI向他解释“你为什么要这么写？”。

他承认，这样做效率变低了，但带来了两个巨大的好处：
1. AI 胡说八道（hallucinate）的次数变少了。
2. 他感觉自己的开发技能也在这个盘问 AI 的过程中变强了。

他意识到，自己已经对 Claude 产生了依赖，这让他很脆弱。前阵子 Claude 宕机了两天，他试了别的工具，都感觉不顺手。所以，他现在逼着自己和AI一起思考，而不是纯粹依赖AI。

---

看来每个人用 AI 的方式都不一样，但也有一些共同点：

1. 重点不在“写代码”，而在“做规划”

没有人真正的是在“Vibe Coding”，没有说写个提示词就完事了的，都是在 AI 干活前反复的讨论，直到清楚了再动手

2. 上下文很重要

Yash 用 Context 7 MCP 的工具，确保 AI 在写代码时，能自动去查阅最新、最官方的“技术文档”。这就避免了 AI 用过时的知识（比如一个老版本的函数）来写新代码。还会用 Figma MCP，读取 Figma 的原始设计数据，让 AI 可以直接拿到准确的颜色、间距等信息

3. 工程师的角色在进化

工程师已经不再是单纯写代码，还要做计划、写提示词、审查 AI 生成的代码

4. 专注

这个问题其实我也有感触，AI 让人更难专注了，在等 AI 结果的时候去做点其他事，很快就把任务忘记了；或者 AI 工具太多，每个新 AI 工具都去试试太费时间了。像 Yash 那样，一半时间专注交付，一半时间探索。

原文：Inside the AI Workflows of Every’s Six Engineers
https://t.co/xqTMIAxTVj

[Google Gemini @GeminiApp]

Ready to learn a few new Gemini tricks and treats?

Then don’t miss our next Discord event featuring Google DeepMind superstar @DynamicWebPaige happening Wednesday (10/29) at 11am PT. She’ll share impressive use cases and unique insights into the technical magic of Gemini.

Join the Gemini Discord and RSVP here: https://t.co/IAYiy1ZOzh

[Elon Musk @elonmusk]

https://t.co/op5s4ZikGJ is fully open source, so anyone can use it for anything at no cost

[宝玉 @dotey]

研究 Vibe Coding 都能写论文了，来自中科院、杜克大学等的这篇《基于大语言模型的Vibe Coding综述》，还是花了点功夫把 Vibe Coding 相关的论文、信息梳理了一遍，有一些值得看的内容。

【一】
首先是对 Vibe Coding 的定义，这篇论文把 Vibe Coding 描述成一个“三方关系” （参考图1）：

1. 人类开发者：不再是代码的直接创作者，更像是需求的提出者、方向的把控者和最终质量的仲裁者 。你的主要工作是清晰地表达意图，并判断 AI 做出来的东西“对不对”。

2. 软件项目：不再仅仅是代码库，而是一个包含代码、数据、文档、领域知识等各种信息的“上下文空间” 。AI 需要从这里获取信息来理解任务。

3. 编程智能体 (AI)：负责具体的编码、修改、调试工作，它听从人类的指令，并受项目上下文的约束 。

论文也提到了 Vibe Coding 带来的问题：经验丰富的开发者在使用高级AI工具时，完成任务的时间反而增加了19% ！

【二】
为什么经验丰富的开发者 Vibe Coding 时间更长？不完全是模型能力不够，还有其他原因：

1. 系统性的上下文工程 (Context Engineering)：你得知道怎么把项目信息（代码库、文档、规范）有效地“喂”给 AI 。AI 不是凭空写代码，它需要知道你的项目是怎么回事 。光会写漂亮的提示词 (Prompt) 是不够的，管理上下文信息才是核心技术 。

2. 反馈循环 (Feedback Loops)：不能简单地把活儿全丢给 AI。怎么提要求？怎么给反馈？什么时候该介入？这些协作方式直接影响效率和质量 。

3. 基础设施 (Infrastructure)：你需要能安全执行 AI 代码的“沙盒” ，能跟 AI 流畅对话、共享项目信息的交互界面 ，甚至需要能自动化测试、部署 AI 代码的平台 。没有这些基础设施，AI 就是“带镣铐跳舞” 。

【三】
五种 Vibe Coding 开发模式 ：

1. 无约束自动化 (UAM)：完全放手让 AI 干，你只看最终结果 。速度快，风险高，适合做一次性原型或小工具 。有点像软件工程里的“快速应用开发”（RAD） 。

2. 迭代式对话协作 (ICCM)：你和 AI 像结对编程一样 ，AI 写，你审，反复沟通迭代 。质量有保障，但需要你深度参与 。

3. 规划驱动 (PDM)：你先做好设计、定好规范（比如写好技术文档、规则文件、实施计划） ，然后指导 AI 按计划执行 。有点像传统的“瀑布模型” ，但 AI 的快速迭代让它更灵活 。

4. 测试驱动 (TDM)：你先写好测试用例，定义清楚“怎样算对” ，然后让 AI 去写能通过测试的代码 。用机器验证代替人眼审查 。这是传统“测试驱动开发”（TDD）的应用 。

5. 上下文增强 (CEM)：这不是一个独立流程，而是一种“增强插件” 。通过检索增强生成（RAG）、代码库索引等技术，让 AI 能更好地理解项目现有情况，生成更贴合项目风格和规范的代码 。它可以与其他四种模式结合使用 。

【四】
Vibe Coding 的最佳实践——把 Agent 当员工而不是工具

很多一直把 AI 当成一个“超级自动补全”，一个更聪明的 Stack Overflow，我们把它当成一个“工具”，而实际上，它是一个智能体（Agent）。

“工具”和“Agent”的区别是什么？

- 工具（比如锤子、编译器）：它帮你完成你正在做的事。你100%掌控它。
- Agent（比如一个初级程序员）：它能自主完成任务。你需要给它分配任务、给它“记忆”（上下文）、给它权限，并对它进行“管理”和“审查”。

如果试图用“使用工具”的方式，去“管理一个员工”，结果就是会带来两个极端：

- 一个极端是盲目接受：AI 写的代码，语法漂亮，看着很对。你“Vibe”一下，直接提交。结果生产环境崩了。你大骂“模型产生了幻觉”，而真正的问题是，你跳过了必要的检查环节： 代码审查、自动化测试。

- 一个极端是过度怀疑：你根本不信它，它写的每一行你都要重写，这同样影响效率。

这特别像那些管理水平不怎么样的 Engineering Manager：要么对员工（AI）完全放任不管，要么事必躬亲地为管理。

最佳实践是在关键节点设置检查站，自动化验证流程，但在过程中放权。就像一个新员工入职，你不会直接让他们在生产环境上更新代码，而是会有配套的流程和环节保障。

【五】
开发者的角色正在发生根本性转变。你不再仅仅是代码的生产者，你的核心工作变成了：

1. 意图阐述与提示工程：把复杂需求翻译成 AI 能理解的清晰指令 。

2. 上下文管理：精心挑选和组织信息（API 文档、代码片段、设计规范），喂给 AI，限制它的“自由发挥”，确保方向正确 。

3. 系统级调试：当 AI 生成的系统出问题时，重点不再是逐行 GDB，而是从系统行为层面去推测、定位问题，然后引导 AI 去修复 。

4. 架构监督：AI 负责实现细节，你得把握整体架构，确保项目的概念完整性和长远健康 。

5. 质量验证与治理：设计测试用例，利用自动化工具验证 AI 的输出，管理 AI 的权限，追踪代码来源 。

简单说，你的价值从“写好代码”变成了“用好 AI 来写好代码”。这不仅仅是技能的增加，更是一种思维模式的彻底转变 。

【六】
Vibe Coding 带来的挑战：安全、可靠性、监管，以及……我们自己

1. 代码可靠性和安全性：AI 可能从训练数据里学到并复现各种 Bug 和安全漏洞 。只看“Vibe”不看代码，无异于“盲驾” 。我们需要新的自动化工具和流程来实时监控、验证 AI 生成的代码 。手动代码审查根本跟不上 AI 的产出速度 。

3. 大规模监管：当 AI 智能体能自主修改、部署代码时，如何有效监督它们？如何防止一个错误像病毒一样扩散？如何追踪责任？ 。现有的管理和审计方法都过时了 。我们需要能与 AI 能力同步扩展的监管架构 。

3. 人的因素：开发者需要转变思维模式 ，学习新技能 。团队协作方式需要调整 。更重要的是，如何建立对 AI 恰当的信任度——既不盲从也不过度怀疑 ？

4. 教育脱节：现在的计算机教育体系，有教你怎么“指挥”AI 写代码、怎么设计 AI 的工作流、怎么评估 AI 的风险吗？很少 。人才培养的速度，远远落后于技术发展的速度 。

论文地址：https://t.co/yq0Pr2gD6W

[Jay A @jay_azhang]

https://t.co/fahwCyMzRw

This is a fresh round that started today at 6:04pm EST

First trades executing now