推文

/grill-with-docs 的威力： 「当一个潜在的 steward 能够认领他们已经承诺过的 spark 时，橙色的接受按钮跑到了页面太靠下的位置，被导航栏给遮住了」 一套与 agent 共同打磨的共享语言，意味着你能用精确无歧义的词汇来描述需求。 【引用 @Brian_Mosley_UK】：@mattpocockuk 刚刚用了 /grill-with-docs……「用 grill me with docs skill 帮我检查这里的术语——当一个潜在的 steward 能够认领他们已承诺的 spark 时，橙色的接受按钮跑到了页面太靠下的位置，被导航栏给遮住了。」

感觉得重新在 YouTube 频道上讲一讲 Effect 了。 用它做 TypeScript 后端，开发体验（AX）真没有比这更好的了。 一旦从这个视角看进去，就会上瘾。

长 skill 对我来说是个大红旗： - 难以审计（进而难以信任） - 难以编辑（文字越多，维护越难） - 运行成本高（文字越多，token 越多） 我认为 skill 越短越好

今日所学： DX：Developer Experience（开发者体验） AX：Agent Experience（Agent 体验） AX 是个很棒的概念，正好描述了我一直在思考的东西——agent 在你的 codebase 里能表现多好。架构是否合理、反馈循环是否顺畅、信息是否容易发现。 太喜欢这个词了。

听起来很熟悉 喜欢伟大和平庸的大脑有时会想到一处 （Martin 当然是那个伟大的） [引用 @martinfowler]: 新文章：当我需要给 LLM 喂大量 context 时，我可以自己写，也可以让 LLM 来访谈我。

用 /grill-with-docs（以及共享语言）最痛苦的一件事，就是你突然意识到自己一直在用错误的词。 DDD 的朋友们，你们会不会专门做一次重构，只是为了统一改掉某个名字？ 我的情况：我有个功能是把视频分成若干段，我叫它 ClipSections，但显然应该叫 Chapters。 现在我在和其他工具集成，它们全都叫 chapters，这就更明显了。 值得重构吗？

/improve-codebase-architecture 即将支持输出 HTML 这太棒了，感谢 @trq212

对于那些问如何用 /prototype 测试纯逻辑的人，这是个很好的例子。 它给这位用户构建了一个交互式 TUI： [引用 @MrSanders]：我在测试 @mattpocockuk 的 /prototype skill，这真的是 game changer。我一直喜欢正确地测试——不是写测试用例，而是直接使用我生产的代码，这是个很棒的方式！这个 skill 在这里生成了一个 TUI 来测试逻辑。

/grill-me 是我有史以来最受欢迎的 skill。 每天会收到 5-10 条消息，说它改变了大家的工作流。 但……我已经不再用它来审查代码了。这是改进后的版本：[链接]

Anthropic 给我们提供了「专属月度额度」（dedicated monthly credit） 实际效果是将 Claude Code 的 AFK 使用限制降低了约 5-20 倍 它如何影响你：[链接]

正在直播，做一个关于 Anthropic 砍掉程序化调用方式的视频

这终于是我们一直在等的清晰说法。 但这是一杯毒酒。这是一次伪装成「月度奖励」的 claude -p 用量十倍削减。 Anthropic 正在劝退一切程序化用途。这也无可厚非——没有补贴能永远持续。 但现在是时候去试试 Codex 了。 [引用 @ClaudeDevs]: 从 6 月 15 日起，付费 Claude 套餐用户可以领取一个专用的月度程序化用量额度。 该额度覆盖： - Claude Agent SDK - claude -p - Claude Code GitHub Actions - 基于 Agent SDK 构建的第三方应用

规划阶段做原型，是新版的「不犯错误」。 而且它真的有效。

Jan，我和你有同样的疑虑。当我在规划阶段遇到「未知的未知」时，我会 /handoff 到一个 /prototype session，尝试把它们逼出来。 如果还是不行，我就直接实现一个能跑的版本，再从那里出发。 人们一听到「spec」这个词，脑子里立刻冒出「瀑布式开发」。我不明白为什么，真的很蠢。 事实是：AI 和你自己都能从更快的迭代周期中获益。 **反馈的速率就是你的速度上限。提高你收到反馈的频率。**

本周两个新 skill！ - /handoff 把当前 session 压缩成一个 markdown 文件 - /prototype 帮你快速原型化任何东西——UI 或后端 还有一堆其他更新。changelog 在这里：https://t.co/MsINZhsocy

我刚试了一个流程，非常顺畅： 1. /grill-with-docs，围绕一段新 UI 展开讨论 2. AI 问了一个我没法直接回答、必须先做原型才能知道的问题 3. /prototype 4. 在原型上反复迭代，不计 token 地烧，直到找到一个好的状态 5. /rewind 回到那个问题，选「summarize」（Claude Code 的功能），让它「总结我们从原型过程中学到了什么」 6. 继续 grilling session，同时保留原型成果 非常丝滑

太多人纠结于 token 总量 而正确的指标应该是每个 token 带来的价值

这太酷了，我要立刻试试 [引用 @trq212]：用 Claude Code：HTML 的惊人有效性

AI 让我开始痴迷于语言 把抽象的业务流程命名出来，在让 AI 和你的工作方式对齐这件事上，威力惊人 我不会随机刷 X 找课程素材或社交内容的灵感 我从 X 频道里用特定格式（hooks 和 bricks）捕捉笔记 这种简洁让和 AI 沟通快很多，也帮助你思考更清晰

我最近做了一次很火的演讲，@swyx 让我整理一下经验——给未来的 AIE 演讲者和想学习的人参考。 我其实非常适合做这件事，因为我做了 6 年声乐教练。我不只是自己做过无数次演讲，还教过很多人怎么演讲。 下面是我在准备和做演讲时会想到的事情。这些适用于任何要展示 PPT 的场景，也适用于大多数线下交流。 **流畅与崩溃** 做演讲时我想得最多的是「紧张感」。紧张感是一种身体上的收缩，会干扰声音——肋间肌、颈部肌肉、喉部周围的肌肉收紧。 紧张感不等于焦虑。焦虑是怯场、被注视的感觉。怯场只能靠重复来治愈：做越来越大的演讲，它就会消失。我做演讲时几乎没有焦虑，因为我总能想到自己做过更大的场子。 焦虑会催生紧张感。你越紧张，身体就越僵；声音开始卡顿，呼吸崩塌，手开始抖，脸僵住，声音变成单调。这就是「崩溃」——演讲的失败状态。 它的对立面是「流畅」——一种声音和身体无摩擦协同的整合状态。不是毫不费力——我做演讲时心率通常很高——但是一种没有紧张和焦虑的状态。 **呼吸** 紧张感是一个身体问题：错误的肌肉用力过度，正确的肌肉完全没在工作。 这表现为锁骨式呼吸——从胸部上方和肩部主导的呼吸方式，是最自然的「紧张呼吸」，也是崩溃的温床。锁骨式呼吸越多，你越紧张，越焦虑。 讽刺的是，「深呼吸几下」这个建议可能适得其反——如果你呼吸方式不对，你会立刻锁骨呼吸，开始崩溃。 解法是腹式呼吸：吸气时放松腹部，让膈肌下降。这是我教每一个学生的第一件事。这种呼吸完全没有紧张感，从外面看你只是显得非常放松。你可以在台上用它来减少身体紧张、防止崩溃。这是一切的基础。 **目标** 大多数演讲者——我见过的 95% 的技术演讲者——并没有把演讲对准听众。他们根本没有在想听众。 这有两种表现：一是「打过了」，他们在对着练习时脑子里想象的那个虚构听众说话，对着空气，对着整个世界。这会显得声音洪亮、表演感强、却空洞。 二是「向内说」，他们在默背下一句台词，监控自己的表现。这通常源于焦虑，但不总是——就算放松的演讲者也会这样。这会显得疏离。 对准房间。实时读取听众，随时调整。校准到他们的能量水平。考虑他们可能在想什么。忽略外面的世界，专注这个房间。向外看，不向内看。 **幻灯片** 幻灯片被过度重视了，但也值得谈谈。 演讲应该以演讲者为主导，而非以幻灯片为主导。幻灯片是用来支撑你的，用来强调你的观点，提示你下一步去哪。如果幻灯片就是演讲本身，演讲者只是在旁白，那演讲者来干嘛的？ 幻灯片要精简：每张幻灯片信息量要少——一个短语、一句引言、一张图。听众快速看完，注意力回到你身上。堆满的幻灯片会把注意力从你身上夺走。 保持节奏，不要快速翻过一堆幻灯片——什么都留不下来。给每张幻灯片、每个观点留时间沉淀。 **总结** 焦虑只能靠重复来治愈。但紧张感才是演讲者的战场。用腹式呼吸修复它，注意自己什么时候开始锁骨呼吸。流畅，不要崩溃。 把演讲对准房间，而不是你自己或整个世界。始终把听众放在心里。演讲者主导，而非幻灯片主导。用精简的幻灯片，把节奏放慢。

/handoff 可能是我最喜欢的新 skill [视频]

我越来越多地用原型替代计划，输出越来越好 谁能想到，低保真原型居然比满篇 spec 文档效果更好呢 哦对，整个行业 20 年前就知道了 别因为旧金山某人把它做成一个「模式」（mode）就去逆势而行 --- 引用 @thdxr：我从不做计划，我讨厌看 markdown，我不想读 markdown 文件。我的方式是让它直接改代码，然后看代码哪里不对，再继续 prompt

今天在工作台上搞的：一个 /review skill - 对照原始需求 spec 检查 - 对照编码规范检查 - 提出代码修改建议（这是当然的） - 提出对生成这段代码的 agent loop 本身的改进建议

这基本上和我用了一段时间的自制工作流一样： 1. 创建一个 /prototype-ui skill 2. 给它指令，生成多个风格迥异的设计方案 3. 加一个切换组件，让你在方案间来回预览 搞定 [引用 @adamwathan]：快速 demo——无论用什么技术栈，都能生成多个设计方案供选择

不知道大家在大惊小怪什么。Anthropic 的订阅使用规则非常简单： Claude Code = 允许 Claude 在线平台 = 允许 Agent SDK 在个人软件中运行 = 允许……差不多？ Agent SDK 在商业软件中运行 = 不允许 Claude Code 在 CI 中运行 = ?? 好吧，也许没那么简单…… Agent SDK 在 CI 中运行 = ?? claude -p 在 CI 中运行 = ?? claude -p 在个人软件中运行 = 允许 claude -p 在开源软件中运行（但跑在我自己电脑上）= ?? claude -p 在我启动的分布式沙箱中运行 = ?? 分发依赖 claude -p 的开源软件，并附上如何用自己订阅使用的文档 = ?? 其他一千种边缘情况 = ?? 说清楚：我从未在任何开发者工具上，经历过如此令人沮丧的基础使用条款不明确问题。 我三周前亲自问过，收到的只有一再拖延。最近 @bcherny 的公告对澄清问题毫无帮助。 说这些话的时候，我刚发布了一门 Claude Code 课程——我的利益完全与支持 Anthropic 一致。

这里有些混淆，让我澄清一下。 - 我不用 plan mode - 但我仍然大量规划，用我自己的 skills：/grill-me、/write-a-prd，然后 /prd-to-issues - 烂计划 = 烂输出 引用的原推： 我也不再用 plan mode 了。 它太急于生成计划，通常一个问题都不问。 规划的意义是和 LLM 对齐，不是生成一份你不读的文档。 /grill-me 一把梭。

我对 AI 最大的疲惫感来自「沟通疲劳」。 实现速度已经快得离谱，但描述需求依然很慢。 强行提速只会让人精疲力竭。

今天的有趣任务：构建一个 AI SDK 风格的 API，用于在容器中运行不同的 agent。 很快 Codex 就能程序化地 review Claude Code 的工作了。 Sandcastle 越来越有模有样了。

感觉在 AI 时代，单个中大型项目的最优开发团队规模大约是 3 人。 1 人是不可持续的——某人休假时开发就得暂停。 2 人勉强可以，但「巴士因子」风险依然很高。 3 人刚刚好。 每天团队负责管理 AFK agent（离线自主运行的 agent）的任务队列，讨论需求、架构，review 代码，优化反馈循环，共享知识。 可能有些开发者同时参与多个团队。

每次 LLM 跟我说什么，我都会默认它在胡说，除非它引用了某个来源做了确认。 而我认识的非开发者里，没有一个人有这种本能。

Sandcastle 现在可以： - 查看 issue backlog - 在不同 worktree 的沙箱中并行启动 N 个 Claude 实例，各自处理一个 issue - 将所有 worktree 的代码合并回目标分支 - 全程本地运行 只需要 Docker 和 TypeScript

我们无法消灭会议，但可以消灭手动编码： 1. 和开发同事/领域专家开会，生成会议录音转写 2. 从转写内容生成会议纪要 3. 将纪要传给 coding agent，创建任务 ticket 4. 将 ticket 传给 AFK agent，生成代码 5. 开下一个会，循环往复

好不容易让并行执行在 Sandcastle 里跑通了 一口气同时发了五个 Opus 触发 rate limit

在 AI 横行的代码库中避免认知债务的好建议： 设计接口，委托实现

这不只是 prompt 的一部分—— 而是 **最重要的部分** 【转引 @kentcdodds】你现有的代码库，就是 prompt 的一部分。

正在开发一个用 TypeScript 编排本地沙箱化 coding agent 的工具： - 运行于 Docker 容器中隔离沙箱 - 完全离线：沙箱中的 commit 会 patch 回宿主机 - 用 TypeScript 构建复杂工作流 - 支持 Claude、Codex、OpenCode 它叫 Sandcastle

Claude Code 尝试改进了 /init…… 效果有提升吗？

我的 'grill-me' skill 火了。mattpocock/skills 已达到 9K stars，引用推文也在持续传播。 这是我写过的最实用的 skill，甚至在编码之外我也在用它。