AsyncTalk

AsyncTalk
  • 3.0 (2)
  • Technology
  • Updated Semiweekly

和我们一起，把 web 开发带向下一个高度 AsyncTalk 是一档中文，面向对 web 开发感兴趣的朋友所录制的 Podcast 节目。 后续我们会讨论更多更为前沿，工程化的话题，感兴趣可以持续关注。 联系我们请发邮件至 async.talk@gmail.com 期待沟通。

  1. 5d ago

    Jev: 只回答是或否的模型，为什么火了？

    这期 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

  2. Sep 15

    TypeScript 7：十倍性能的升级之外，为什么选 Go？

    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

  3. Sep 2

    64个Claude: Bun 的 11 天重写

    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

  4. Aug 31

    Axiom 日志：哪 26 个人拿走了我的电影票？

    最近 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 自动分析生产环境，欢迎一起讨论。

  5. Jul 31

    YoooClaw：给 AI 一具身体

    当 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 助手的主流形态吗？

  6. Jul 16

    AI Agent 必备的 ChatSDK

    你肯定见过 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

  7. Jul 3

    react-call:弹框还能 await

    有没有遇到过这种场景:一个删除按钮,点下去得先弹个「确认删除吗?」,用户点确定才真的删。浏览器自带的 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

  8. Jun 24

    GraphQL:治好前后端联调内耗

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

See All (79)

Ratings & Reviews

3
out of 5
2 Ratings

About

和我们一起，把 web 开发带向下一个高度 AsyncTalk 是一档中文，面向对 web 开发感兴趣的朋友所录制的 Podcast 节目。 后续我们会讨论更多更为前沿，工程化的话题，感兴趣可以持续关注。 联系我们请发邮件至 async.talk@gmail.com 期待沟通。

Information

  • Creator
    AsyncTalk
  • Years Active
    2021 - 2026
  • Episodes
    79
  • Rating
    Clean
  • Copyright
    © AsyncTalk@喜马拉雅FM
  • Show Website
    AsyncTalk

You Might Also Like