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开发 #程序员 #异步聊技术

还在被 ESLint 卡到怀疑人生？这期聊聊尤雨溪团队 VoidZero 出品的 oxlint 和 oxfmt——同样的项目，ESLint 跑 1 分 43 秒，oxlint 21 秒搞定，50-100 倍提升不是吹的。 这期会聊到： � oxlint 到底比 ESLint 快多少（实测对比） � 为什么我不选 Biome？GritQL 插件系统真的劝退人，AI 都写不来 � oxlint 插件系统：兼容现有 ESLint 生态，还能用 JS 手写规则（让 Claude 帮你写都行） � lint 慢不只拖累你，还拖累 Claude Code / Codex 的迭代效率 现在该不该迁？除非你是 300 万行的祖传项目，否则建议直接换 摸鱼的时候点开听听，省下来的时间都是赚的 � 你的项目迁到 oxlint 了吗？踩过什么坑？评论区蹲一波交流～ — AsyncTalk｜异步聊技术 一档 Web 开发 + AI 的播客节目 #oxlint #oxfmt #ESLint #尤雨溪 #前端 #JavaScript #TypeScript

Prompt 工程的尽头，是「说人话」。 少一点： 复杂 role 冗长规则 八股结构 多一点： 清晰目标 简单表达 合理拆分任务 把 AI 当成一个实习生，而不是神或工具。 你怎么说，它就怎么做。 — 这期聊的是： � 如何更高效地和 AI 沟通，而不是“控制它” 欢迎交流你的使用方式 �

线上半夜出 bug,第一反应是看日志 → 结果发现日志啥也没说 � 这期 5 分钟讲清楚两个让你日志直接上档次的技巧: 1️⃣ JSON 结构化日志:让机器读得懂,让你查得飞快,告别 grep 大法2️⃣ 宽日志(Wide Events):一次请求一条日志,把上下文一次打全,排查效率拉满 学完这两招,on-call 不再哭,下班准点跑 �‍️ �️ AsyncTalk - 异步聊技术,既有趣又有料 #程序员 #后端开发 #编程技巧 #日志 #devops #observability #码农生活 #软件工程师 #后端 #编程 #logging #backend

凌晨三点，Sentry 又响了。 作为一个不想被 on-call 毁掉睡眠的打工人，我搓了套极简 harness，让 Claude Code 顶替我值班。 这期聊聊我是怎么把整条链路串起来的： 日志服务 + Sentry 通过 MCP 暴露给 Claude Code Claude Code 跑定时任务，自动拉报警、定位根因 改完代码跑测试、提 MR，丢回给我 review 我只需要点 approve（或者骂它两句让它重写） 不是什么重型 Agent 框架，就是几个 MCP server + 一点配置，但是真能跑。适合所有不想半夜爬起来看报错的开发者。 #Claude[话题]# #MCP[话题]# #AI编程[话题]# #AI自动化[话题]# #oncall[话题]# #程序员[话题]# #asynctalk[话题]# #Agent[话题]# #ai[话题]#