Advertise on podcast: AsyncTalk

Anthropic 新出的 Claude Haiku 5.5，价格比 DeepSeek V4.1 Flash 还便宜，Computer Use 跑分却高达 72.4%。 这期聊三点： ① 价格：输入 $0.10 / 百万 token，输出 $0.50（10 万 token 以内），比 DeepSeek 还低 ② 性能：同价位里相当能打，速度也比中高档模型快 ③ Computer Use：OSWorld 72.4%，远超同级别 GPT-6 Luna 的 48.9%，是 Sonnet 5.5 的 86%，价格只要 1/20 为什么便宜对 Computer Use 这么关键？模型操作电脑要不停地截图、找位置、点击、再截图，一个简单任务也要来回很多轮，成本很高。价格打下来，Personal Agent 就会接连出现，更多基础工作会被替代。 你怎么看 Haiku 5.5 和 Computer Use？评论区聊聊 � 章节 00:00 开场：比 DeepSeek 还便宜 00:39 三个亮点：价格、性能、Computer Use 01:11 跑分：Computer Use 72.4% 02:04 价格：$0.10 / 百万 token 02:30 为什么价格对 Computer Use 这么关键 03:40 Personal Agent 爆发 04:54 AI 怎么抢走工作 05:41 总结 BGM：“Bookworm” by Purrple Cat · Free Music Archive · CC BY 4.0 #ClaudeHaiku #ComputerUse #人工智能 #Claude #Anthropic #DeepSeek #AIAgent #大模型 #AI工具 #AsyncTalk

很多人觉得 Skills 火了之后 MCP 就凉了。但 MCP 0728 这次更新，我愿意叫它「MCP 2」�� MCP 1 的老毛病：有状态远程连接要一直维持 session，扩缩容和负载均衡都很难做。一发新版本，用户聊着聊着就断了，只能重开 session。� Skills + CLI 真的完美吗？· CLI 靠单词拼接，表达力不如自然语言· 必须有机器来跑（本地或云端 VM），成本高· CLI 是黑盒，npm 那种供应链攻击蔓延到 Skills 只是早晚的事· 一个命令是读还是写，全靠开发者自觉遵守语义 MCP 0728 改了什么它去掉了 session，变成像 HTTP 一样的无状态接口，每次请求带上 header 就行。→ 扩容和 load balance 又能按熟悉的方式做了→ 每个 tool 都分只读和写，权限好管，也方便审计→ 跑在远程 server 上，不碰你的电脑，更安全� 实战演示我用 ShellTime 和 Rawback 的 MCP server 演示：只读 tool 一键「Always allow」，写和删除单独授权；再让 Claude 直接分析我最近的 AI 使用数据。章节00:00 开场：MCP 2 来了00:23 MCP：AI 连接外部世界的入口01:11 一个比喻：脑子、手、技能和冰箱02:06 MCP 的老问题：有状态03:23 另一条路：Skills + CLI04:16 Skills 真的完美吗？07:47 回到主题：MCP 072809:12 实战：ShellTime MCP server11:20 MCP vs Skills11:38 你怎么看？有自己产品的朋友，真心建议自己实现一个 MCP server 试试～你觉得 MCP 0728 能 make MCP great again 吗？你站 MCP 还是 Skills？评论区聊聊 � #MCP #AI #AIAgent #ClaudeCode #Claude #Skills #大模型 #人工智能 #程序员 #技术分享 #后端开发 #AsyncTalk

这期 AsyncTalk 聊一个前几天突然火起来的模型：TypeSafe 发布的 Jev。它不聊天、不写长文，只回答简单的问题：是或否、多选一、打分。端到端 70–500 毫秒返回，输入每百万 token 0.042 美元，输出免费。我们从程序员最熟悉的 if 讲起：· 让大模型做一个「是或否」的判断，要定输出结构、解析 JSON、按 token 计费，又慢又贵· 纯代码的 if 又理解不了用户意图· Jev 正好卡在两者中间然后聊它在 AI Agent 里的用法：意图识别、「这是不是 TypeScript 文件」这类判断、每一步的快速校验。现场实测了几个问题（苹果能不能吃、该不该买沪深 300、今天要不要出去玩）。最后说说它的局限：快、便宜，但不一定更准，同样会有幻觉。你怎么看这种「快速决断」的模型？欢迎在评论区聊聊。⏱ 章节00:00 开场：一个“没什么智力”的模型为什么火了？00:19 Jev 是什么01:05 程序员最重要的语句：if01:22 让大模型做 if，贵在哪？02:09 Jev 的位置02:38 Agent 里的大量 if03:38 实测 Jev04:41 它足够可靠吗？05:21 试一试 & 你怎么看� 数据来源片中延迟、成本、准确率数据来自 TypeSafe 公布的 System One 基准，引自：· DataCamp：https://www.datacamp.com/blog/system-one-models-jev· RuntimeWire：https://runtimewire.com/article/typesafe-jev-system-one-ai-model-early-access· NYU Shanghai RITS：https://rits.shanghai.nyu.edu/ai/typesafe-jev-system-one-model� AsyncTalk · 主播 AnnatarHe#Jev #TypeSafe #AI #大模型 #AIAgent #程序员 #编程 #人工智能 #AI工具 #科技播客 #AsyncTalk

TypeScript 7 终于来了。 这次最直观的变化不是新语法，而是 Go 重写之后带来的性能提升：VS Code 的类型检查从 78 秒降到 7.5 秒；我自己的一个 58 万行 TypeScript 项目，也从大约 14 秒降到了 3 秒左右。 但这期我更想聊的是另一个问题： 为什么 TypeScript 选择了 Go，而不是 Rust？ 从 TS7 的实际升级体验出发，聊聊大型项目里的类型检查和编辑器性能，也聊聊 Go、Rust 在性能、复杂度、可读性和长期维护上的取舍。 我自己写了七八年 Go，也实际用 Rust 写过一些项目。相比“Rust 重写一切”，我越来越觉得：工程技术选型追求的从来不只是极致性能，而是在性能、开发效率和可维护性之间找到平衡。 所以，TypeScript 团队这次选 Go，你怎么看？ #TypeScript #TypeScript7 #Go语言 #Rust #前端开发 #编程语言 #技术选型 #软件工程 #程序员 #开发者 #Web开发 #AsyncTalk

Bun 1.4 发布了。作者 Jarred 说这是"变化最小的一个版本"——对用户来说确实是，但整个 runtime 底层已经从 Zig 换成了 Rust。11 天，峰值 64 个 Claude 同时在同一个仓库里干活，53 万行 Zig 全量翻译成 Rust，API 账单约 16.5 万美金。放在 AI 之前，这种项目只有一个结局：不做。这期挑了原文里我觉得最有意思的几点聊：· 为什么非要换 Rust —— JavaScriptCore 是带 GC 的，Zig 是手动管内存，两个混在一起，光 use-after-free 和内存泄漏就够喝一壶· 对抗性 review —— 写代码的 Claude 和挑刺的 Claude 上下文完全隔离，reviewer 只拿到 diff，并且被要求"默认这段代码是错的"· 翻车现场 —— 64 个实例互相 git stash、把编译不过的函数偷偷 stub 掉、写注释写到把磁盘 IOPS 打满· 编译器报错反而是 AI 最好的反馈信号，一万六千个 error 就是一个天然的任务队列· 最关键的一条：AI 犯错的时候，要改的不是那段代码，是你的 rules以及所有人都想问的那个问题：我自己的项目能不能也这么重写？我的答案是别。Bun 有百万级断言的测试用例兜底，一行写错立刻有几十个 case 报警；而我们写的业务代码，覆盖率能到 50% 都算凤毛麟角，很多逻辑你去问产品经理，他自己都说不清预期是什么。没有验证手段的重写，跟 100 倍杠杆做空纳指有什么区别。AI 改变的是重写这件事的成本结构，不是正确性的判定标准。原文很值得自己读一遍，对你搭自己的 harness 帮助很大。有不同看法欢迎评论区聊。#Bun # Rust #AI编程 #Claude #ClaudeCode  #Agent #前端  #JavaScript  #Nodejs  #程序员 #AsyncTalk

最近 Harness 成了 AI 圈的热门话题，但当我们讨论 AI Agent 如何真正完成任务时，我觉得有一个经常被忽略的问题：AI 怎么知道生产环境到底发生了什么？#Axiom #日志 #AI编程 #MCP #Harness #DeepSeekHarness #ClaudeCode #CodingAgent #AI智能体 #可观测性 #DevOps #程序员 #asynctalk这期我想聊聊我最近一直在用的日志服务 Axiom。从传统的日志查询，到 Dataset、Dashboard 和 Monitor，Axiom 本身已经是一个相当不错的日志平台。但真正让我觉得它有意思的，是它提供的 MCP Server。当日志系统接入 MCP 之后，Coding Agent 就不只是写代码了。它可以直接分析生产日志、查找错误、定位问题，甚至结合代码自动修复 Bug、补充日志。进一步想象一下：让 Agent 定期检查生产环境的日志 → 发现异常 → 分析代码 → 尝试修复 → 提交 PR。日志不再只是给开发者 Debug 的工具，而开始成为 AI Agent 了解真实生产环境的一扇窗口。视频里也简单聊到了我最近在关注的 Superlog，以及我对「Harness + MCP + 可观测性」这条路线的一些想法。如果你有更好的日志管理方案，或者已经在尝试让 AI Agent 自动分析生产环境，欢迎一起讨论。

当 AI Agent 不再只存在于聊天框里，它会变成什么？ 本期体验一款很有意思的软硬件结合产品——YoooClaw。它像一个吸附在手机背面的“小型 AI 硬件”，可以通过语音直接向 OpenClaw 下达任务，还能读取并总结手机通知、通过 RGB 灯带反馈重要消息，以及录制对话、识别不同发言者并生成会议总结。 它还支持切换 DeepSeek、GLM 5.2 等不同模型。但比具体功能更值得讨论的，是 YoooClaw 所代表的产品方向： 模型可以替换，App 和 Agent 框架也可以替换，但持续积累的个人上下文、稳定存在的硬件入口，以及从信息感知到任务执行的完整闭环，可能才是 AI 时代真正的护城河。 某种意义上，YoooClaw 就是在尝试给 OpenClaw 一具真实的“身体”。 当然，目前的产品仍然存在不少问题：任务结果展示不够完善、系统推送和定时任务尚未形成完整闭环，位置等上下文也没有得到充分利用。更重要的是，当一个设备能够读取通知、录制音频并长期积累个人信息时，隐私和数据安全将成为无法回避的问题。 这期视频会聊到： YoooClaw 如何通过硬件与 OpenClaw 交互• AI 通知总结与 Apple Intelligence 的体验差异• 录音、发言人识别和会议总结• 为什么持续积累的 Context 如此重要• 硬件入口为什么可能成为 AI 产品的商业护城河• YoooClaw 当前的产品缺陷与隐私风险 你认为这种软硬件结合的 AI Agent，会成为下一代个人 AI 助手的主流形态吗？

你肯定见过 OpenClaw 这种 AI Agent——挂在服务器上,你在聊天框 @ 它一句,它就自己动手把活办了:查资料、改文件、跑脚本……不只是会聊天,而是真能动手干活,也就是现在常说的 agentic。那要自己做一个这样的 agent,是不是得把每个平台的 API 和 webhook 都单独研究一遍、写一堆胶水代码?这期聊 Vercel 开源的 ChatSDK——可以把它理解成「AI Agent 的对话接入层」。它把 Slack、Microsoft Teams、Discord、Telegram、GitHub、WhatsApp… 十多个平台的机器人逻辑统一了起来:你只写一套 TypeScript 代码,在一个 onNewMention 回调里 subscribe 再 post,你的 agent 就能在所有平台上跑起来。视频里会带你看:· ChatSDK 的三个核心概念——Chat、Adapter、State· 怎么用一个 callback 统一处理各平台的 webhook,把"接入层"这件最烦的事交出去· 从"在 GitHub 里 @ 一下机器人帮你改个颜色"出发,一路扩展到 Slack 等更多平台· 内置 AI streaming、和 AI SDK 打通,接你自己的 agent 逻辑很顺· 聊天状态怎么持久化(memory / Redis);社区还有飞书等国内平台的 adapter一句话:在 ChatSDK 的帮助下,"造一个属于自己的 OpenClaw、把你的 AI Agent 放进各个聊天软件"已经变成挺简单的一件事了。你会想拿它做个什么样的 agent?或者你已经在搭什么有意思的功能了?评论区聊聊 �—— AsyncTalk 异步聊技术,既有趣又有料,我们下期见#ChatSDK #AIAgent #AI机器人 #Vercel #OpenClaw #TypeScript #asynctalk

有没有遇到过这种场景:一个删除按钮,点下去得先弹个「确认删除吗?」,用户点确定才真的删。浏览器自带的 window.confirm 是能用,但又丑、又几乎不能定制——位置、颜色、甚至标题都改不了。于是你只好自己写组件、用 React Portal 挂载、再手动管理 DOM 的显隐和生命周期,挺折腾的。这期聊聊 react-call 这个小而美的库。核心思路一句话:把你自定义的 React 组件变成「可以 await 的函数」。用 createCallable 包一层,就能在调用方直接 await xxx.call(...),像调用异步函数一样拿到用户的操作结果。视频里会过一遍:· 从 window.confirm 的痛点切入,为什么手写 Portal 很烦· createCallable 的基本用法(call / Title / action 几个字段)· 用 bottom sheet 写的实战例子· 支持同时弹出多个实例(比如一连串 Toast)· 和 react-query mutation 的配合:接口失败时弹框依然保留· 自带 skills,对 AI 编程也很友好你平时都怎么处理这类弹框、或者异步交互逻辑?评论区聊聊~ #React #前端开发 #TypeScript #Web开发 #编程 #react-call #asynctalk

前后端怎么交互?大多数人第一反应都是 REST + HTTP。但接口越写越多、前后端对同一个字段理解对不齐、类型全靠猜——这些坑你大概率都踩过。这期我们聊 GraphQL:一门出道十多年、却始终没真正普及的技术,为什么在 AI 时代反而值得重新认识。我们从 REST 的痛点出发,讲清楚 GraphQL 的强类型 schema 如何统一前后端协作、如何让缓存更聪明,以及为什么强类型对 AI 写代码是一个巨大的红利。当然,GraphQL 不是银弹。我们也会聊它真实的坑:n+1 问题、缓存思维的转变、HTTP 状态码、以及什么项目压根不该上 GraphQL。如果你在做一个中大型项目,或者想让 AI 帮你写出更靠谱的代码,这期也许能给你一些新思路。欢迎在评论区聊聊你对 GraphQL 的看法,记得关注 AsyncTalk 异步聊技术。 #GraphQL #api #全栈开发 #后端开发 #AI #程序员 #asynctalk

Swagger + Hey API 自动生成请求代码,告别手写 interface在前后端协作中,RESTful 接口缺乏强类型约束,常常带来一系列联调成本:前端遇到read from undefined,排查后发现是后端返回的数据结构缺失;约定好的字段类型被悄然变更(例如 int32 改为 int64 纳秒);字段命名、大小写、enum 取值、是否可选等细节需要反复确认,既影响效率,也容易引入缺陷。 GraphQL、tRPC 能够从根本上解决这类问题,但对既有项目而言改造成本接近重写,新项目也存在不小的学习成本,在实际工程中往往难以落地。 本期介绍一种更具可行性的渐进式方案:由后端提供规范的swagger.json,前端借助 Hey API 根据该契约自动生成请求代码。生成结果不仅覆盖请求发送,还可包含 response body 校验(可选启用 zod)、react-query 的查询代码与 key,并在编译期完成类型检查,从而尽早暴露问题、清晰划分前后端的责任边界。 该方案的另一项优势在于对 AI 与 CI 的友好度:数据结构固定后,AI 无需再推测接口的返回结构与路径细节,生成代码更准确;契约稳定也使 CI 中的类型检查、lint 与测试更加可靠。 它对后端实现与整体架构几乎没有侵入——开发方式仅从调用手写的 HTTP 接口,转为调用 Hey API 生成的接口。需要强调的前提是:后端提供的 swagger 必须准确,这仍依赖团队之间充分而严谨的沟通。 欢迎在评论区分享你的团队是如何管理前后端接口契约的。 #前端开发 #TypeScript #Swagger #HeyAPI #前后端联调 #AI编程 #asynctalk

GitHub Actions + Claude 代码审查 + 自动发布,从 push 到上线全流程拆给你看写完代码 git push 上去之后,到真正上线之前,中间到底发生了什么?这期我直接打开自己项目的 GitHub Actions,把整条 CI 流水线扒开给你看。从 push、用 GitHub CLI 开 PR,到 Claude Code 自动 review 帮我抓空指针、codecov 盯测试覆盖率,再到 Release Please 按语义化 commit 自动生成版本、打 tag、构建 Docker image——全流程串一遍,一个环节都不跳。Runner 配合 GitHub Actions 本身慷慨的免费额度,轻量项目基本能零成本跑起一整套 CI。性能 OK 不算顶,但够用,关键是省钱。如果你有更顺手的环节或者觉得哪里还能优化,评论区聊聊,也欢迎甩给我更好的玩法。

万物皆可 CLI 的时代（尤其 AI 起来之后），怎么写一个好用的命令行工具？这期聊点不一样的——不碰 C/Go/Rust，直接用 TypeScript + Bun 也能整一个能发给用户的 CLI。从 bun init 起步，命令解析交给 citty，界面渲染用 Ink（对，就是用 React 写 TUI），最后 bun build --compile 一把打成单文件。57 兆是大了点，但是它能用（doge）。最折磨人的签名 + 公证怎么办？goreleaser 从 2.6 开始把 bun 当一等公民支持，checksum、changelog、打包、公证、Homebrew 分发全给你包圆了。顺带提一句：Mac 开发者证书 99 刀一年，这钱是真省不掉。下期预告：怎么把这整套编译流程自动化掉。你写过 / 用过哪些有意思的 CLI？评论区聊聊～ #CLI #命令行工具 #TypeScript #Bun #Ink #goreleaser #前端开发 #程序员 #开发工具 #ClaudeCode #AsyncTalk

AI 输出 Markdown 你是不是已经看腻了？来自 Anthropic 的 Thariq 最近写了篇文章，提出一个挺有意思的观点：HTML 正在取代 Markdown,成为大模型更好的表达语言。这期我们聊聊: 为什么 Markdown 一开始成了 AI 的默认输出格式 Markdown 的天花板:code diff、依赖图、design token 全都"压扁"了 HTML 怎么把可读性拉满,代价是 token 爆炸 用 Claude Code 实测:让它用 HTML 解释 async task 流程,架构图、时序图、代码片段一气呵成 我心中的"隐藏大佬"——MDX:Markdown 的强化版,该用文字用文字,该用组件上组件简单说:Markdown 没过气,只是角色变了。你怎么看 AI 时代的输出格式?有没有更好的方案?评论区聊聊�#HTML #Markdown #MDX #AI编程 #大模型 #LLM #ClaudeCode #Anthropic #前端开发 #程序员 #AI工具 #异步聊技术 #AsyncTalk #开发者 #编程

UI 组件库聊了十几年,但 AI 时代的最优解可能和过去完全不一样。 这期从两个流派的设计哲学讲起:AntD 派回答的是「怎么更快交付」——在过去十年它确实是最优解,30 秒上手、生态成熟、文档齐全,帮我们解决了无数业务问题;ShadCN 派回答的是「怎么做对的事情」——把 UI 库从 dependency 变成你自己的代码,语义化和 RSC 友好都更上一层。 然后是我自己的答案:在 AI 时代,让 AI 帮你撸一个真正属于你项目的 UI 库,可能才是最适合大多数场景的选择。品牌一致、性能可控、演进自由,成本只比 AntD 高一点点。 章节:  00:00 开场  00:09 UI 组件的两个时代  01:42 AntD 派 vs ShadCN 派的根本区别  02:13 AntD 的优势与它在新时代遇到的挑战  07:25 传统 UI 库的本质:实用主义  07:51 ShadCN 的核心理念:你 own 这些代码  09:53 两派对比小结  10:17 我的方案:用 AI 自己撸 UI 库  12:36 不同项目场景的选型建议  13:23 下一个十年 你是哪一派?评论区聊聊你的选择~ 关注【异步聊技术 AsyncTalk】,每期聊点有趣又有料的技术。 #前端开发 #AntDesign #shadcn #React #Tailwind #AI编程 #ClaudeCode #web开发 #程序员 #异步聊技术