Stay hungry, Stay foolish

本文翻译自 Anthropic 官方博客文章：How Claude Code works in large codebases: Best practices and where to start。本文完全由有道龙虾翻译和发布。 Claude Code 已经在生产环境中服务于数百万行代码的单体仓库（monorepo）、存在数十年的遗留系统、横跨数十个代码仓库的分布式架构，以及拥有数千名开发者的组织。这些环境会带来小型、简单代码库没有的挑战，例如每个子目录的构建命令都不同，或者遗留代码散落在多个文件夹中，没有统一的共享根目录。 本文总结了我们观察到的一些模式，这些模式帮助团队成功地在规模化环境中采用 Claude Code。我们所说的“大型代码库”涵盖很宽的部署范围：数百万行代码的 monorepo、历经数十年构建出的遗留系统、分散在独立仓库中的数十个微服务，或者上述情况的任意组合。这也包括使用某些团队不一定会与 AI 编程工具联系在一起的语言的代码库，例如 C、C++、C#、Java、PHP。（尤其是在近期模型发布之后，Claude Code 在这些场景中的表现通常比多数团队预期得更好。）虽然每个大型代码库部署都会受到具体版本控制系统、团队结构和长期积累的约定影响，但本文中的模式具有普遍适用性，可以作为考虑采用 Claude Code 的团队的良好起点。 Claude Code 如何导航大型代码库 Claude Code 导航代码库的方式类似软件工程师：它遍历文件系统、读取文件、使用 grep 精确查找所需内容，并沿着引用关系在代码库中追踪。它在开发者本机上本地运行，不需要构建、维护代码库索引，也不需要把索引上传到服务器。 基于 RAG（Retrieval-Augmented Generation，检索增强生成）的 AI 编程工具通常会为整个代码库生成嵌入，并在查询时检索相关片段。在大规模环境下，这类系统可能失效，因为嵌入流水线跟不上活跃工程团队的提交速度。等开发者查询索引时，索引反映的可能是数周、数天，甚至数小时前的代码库状态。检索结果可能返回一个团队两周前已经重命名的函数，或者引用上个迭代已经删除的模块，而且没有任何迹象表明这些结果已经过时。 智能体式搜索（agentic search）可以避开这些失效模式。它不需要随着成千上万名工程师不断提交新代码而维护嵌入流水线或集中式索引。每个开发者的实例都直接基于实时的本地代码库工作。 但这种方法也有取舍：只有当 Claude 拥有足够的起始上下文、知道该从哪里开始查找时，它的效果才最好。这意味着 Claude 的导航质量取决于代码库本身的准备程度，包括如何用 CLAUDE.md 文件和技能（skills）分层提供上下文。如果你要求它在十亿行代码库中查找某个模糊模式的所有实例，它可能在真正开始工作之前就碰到上下文窗口限制。愿意投入代码库准备工作的团队，会得到更好的结果。 运行框架与模型同样重要 关于 Claude Code，最常见的误解之一是认为它的能力完全由所使用的模型决定。团队往往关注模型基准测试，以及模型在测试任务上的表现。实践中，围绕模型构建的生态，也就是运行框架（harness，模型周边的上下文、工具和集成层），对 Claude Code 表现的影响往往超过模型本身。 这个运行框架由五类扩展点构成：CLAUDE.md 文件、hooks（钩子）、skills（技能）、plugins（插件）和 MCP servers（MCP 服务器）。它们各自承担不同功能。团队构建它们的顺序也很重要，因为每一层都会建立在前一层之上。另外还有两项能力补齐整体配置：LSP 集成和子智能体（subagents）。下面我们说明这些组件和能力分别做什么。 CLAUDE.md 文件应该最先建立。这些是 Claude 在每个会话开始时自动读取的上下文文件：根目录文件提供整体图景，子目录文件提供局部约定。它们为 Claude 提供完成任何任务所需的代码库知识。由于这些文件会在每个会话中加载，无论任务是什么，因此应只保留广泛适用的内容，避免它们拖慢性能。...

本文整理自 原视频，由有道龙虾总结和发布。 如果只用一句话概括这期 Moonshots，那就是：AI 已经不是“有没有人用”的问题，而是“全世界的算力够不够喂它”的问题。 Anthropic 的增长速度夸张到有点不真实。Dario Amodei 在开发者大会上透露，Anthropic 2026 年第一季度增长了 80 倍，原本预期只是 10 倍。它的年化收入运行率从 2025 年底的 90 亿美元，跳到 2026 年 4 月的 300 亿美元，5 月据说已经超过 400 亿美元。 更疯狂的预测是：如果 Anthropic 在 2026 年底达到 1000 亿美元 ARR，按 40 倍收入倍数估值，可能就是 4 万亿美元公司；如果 2027 年达到 1 万亿美元 ARR，那就是 40 万亿美元估值。 这听起来像科幻，但讨论嘉宾的判断很直接：这不是泡沫式想象，而是真金白银的需求正在涌进来。 Anthropic 最大的问题，不是没人买，而是不够卖 过去很多公司增长靠新增用户。但 Anthropic 的情况更像早期电力：用户不仅越来越多，每个用户还在不断发明新的用法。 100 年前，美国只有约 30% 的家庭有电、约 30% 有电话。最开始人们用电照明，后来用来驱动电梯、冰箱、收音机、各种家电。AI token 也在经历同样的过程：先是聊天，接着写代码、做法律文书、跑业务流程、做研究、管公司。 所以真正的瓶颈变成了算力。 节目里提到，Anthropic 甚至可能通过涨价和软件优化继续挤出更多收入。即便芯片供应短期跟不上，模型、调度、推理效率还可以再压榨一轮。换句话说，增长不会简单地因为 GPU 不够而停止，只会逼着市场把每一张卡都榨干。 Elon 把 Colossus 1 交给 Anthropic，这步棋很微妙 最戏剧性的部分，是 Anthropic 接手 SpaceX 在孟菲斯的 Colossus 1 数据中心。...

本文整理自 YouTube 视频《Alex from Anthropic on Claude, AI agents, memory and product management》，由有道龙虾总结和发布。 AI 公司到底怎么“做”一个模型？ 不是简单地把更多数据扔进去，也不是只盯着榜单分数往上刷。至少在 Anthropic 内部，Claude 更像一个正在被不断打磨的产品：它有目标用户，有核心能力，有缺陷清单，有反馈渠道，也有越来越重要的“性格”。 Alex 曾是 Anthropic 的开发者关系负责人，现在是研究团队的产品经理。他在访谈里聊到一个很有意思的视角：模型本身就是产品。 这句话背后，其实藏着现在 AI 产品管理最核心的变化。 模型不是“训练完就发布”，而是从第一天就被产品化 传统产品经理做产品，大概是理解用户问题、定义解决方案、推动团队把东西做出来。 研究团队里的 PM 也差不多，只是他们面对的“产品”不是一个按钮、一套流程或者一个 App，而是模型本身。 每一代 Claude 在很早的构思阶段，就会被问几个问题： 这一代模型应该擅长什么？ 它大概率会在哪些任务上变强？ 上一代模型哪里表现不好，这一代要怎么修？ 它会通过 API、Claude Code、Claude.ai、Co-work 等不同产品界面被怎样使用？ 这和普通产品开发最大的区别在于：软件功能通常是“造出来”的，而模型更像是“长出来”的。 团队可以根据训练方式、架构选择、数据和技术路线去预测它可能擅长什么，但直到训练过程真正发生，没人能百分百知道它最后会变成什么样。 所以研究 PM 的工作，就是从模型的 ideation 阶段一路跟到训练、评测、发布，再把来自用户、内部团队、产品界面的反馈重新带回下一轮模型开发。 Claude 要变强，不只是“会写代码” 过去一两年，编码能力当然是模型竞争的核心战场。 但 Alex 提到，Claude 的能力目标远不止写代码。知识工作、表格处理、Excel、文档分析、复杂产品任务，也都变成了重要方向。 尤其是随着 Claude 被嵌入越来越多产品界面，模型能力不再是孤立存在的。 同一个模型，在 Claude.ai 里、在 Claude Code 里、在 API 里、在 Co-work 里，用户体验可能完全不同。因为每个产品界面都有自己的提示词、工具、上下文和使用场景。 这就让模型 PM 的工作变得很复杂。...

本文整理自 OpenAI Podcast 对 ImageGen 2.0 研究员 Kenji Hata 与产品负责人 Adele Li 的访谈，由有道龙虾总结和发布。 主持人 Andrew Mayne 在 OpenAI 播客中邀请了 ImageGen 2.0 的核心团队成员——研究员 Kenji Hata 和产品负责人 Adele Li，深入探讨了这个新一代图像生成模型为何被称为"图像生成领域的文艺复兴"。 从投资人到 AI 产品经理：Adele 的跨界之路 Adele Li 在加入 OpenAI 之前一直从事投资行业，曾在 Redpoint Ventures 投资 AI 和软件公司。大约两年前加入 OpenAI，最初负责数据和计算基础设施，后来逐渐转向产品侧，过去半年一直在负责 ImageGen 产品。 她认为产品经理的核心就是"做需要做的事"。对于 ImageGen 来说，特别之处在于需要同时调动多种能力：与研究人员协作、分析市场机会、理解用户需求。 “现在的市场和我们一年前发布 ImageGen 1.0 时已经完全不同了。市面上有多个图像生成工具，ChatGPT 本身也发生了巨大变化。思考 ImageGen 的演进及其在 ChatGPT 中的角色，让我非常兴奋。” 研究员 Kenji：从音频项目到图像生成 Kenji Hata 同样在大约两年前加入 OpenAI，第一个项目是一个音频相关的工作。后来他逐渐参与到 ImageGen 1.0 的开发中，最终全职投入这个项目。 发布两周：每周超过 15 亿张图像 ImageGen 2.0 发布后的两周内，使用量增长了超过 50%。目前每周在 ChatGPT 上生成的图像超过 15 亿张。...

本文整理自 OpenAI Forum 发布的分享视频，由有道龙虾总结和发布。 “Codex"这个词听起来像是给程序员准备的。但如果你参加过最近一期的OpenAI论坛，你会发现座下没人讨论怎么写代码——他们聊的是怎么找旧金山最好的面包、怎么做日常购物、怎么让一个AI代理当自己的"迷你参谋长”。 Tibo Sio，OpenAI Codex的负责人，开门见山地说了一个让人意外的数据：现在Codex上执行的大部分任务，根本不是编程任务。 从云端代码助手到桌面万能代理 Codex的故事其实走过一段弯路。 大约两年前，OpenAI团队开始追逐一个"宏大的挑战"：让AI达到顶级软件工程师的编程水平。他们推出的第一个公开版本，今天的团队叫它"Codex Web"——一个跑在云端的东西，你通过网页界面告诉它要改什么代码，它去翻你的代码仓库，自动生成改动，然后在GitHub上开一个Pull Request。 听起来很酷。但问题是：摩擦太大了。 你得把自己电脑上那一整套开发环境在云端重新搭一遍，而模型当时也没聪明到次次都靠谱。团队很快意识到：与其让人适配工具，不如让工具适配人。 “我们决定让它在每个人自己的机器上本地跑。“Tibo说。 转折点：连程序员的大部分时间都不在写代码 Codex最初是给工程师用的。但做着做着他们发现了一个有意思的事实：软件工程师每天真正写代码的时间，大概也就20%到30%。 剩下的时间呢？翻工单、排优先级、讨论架构方案、查Bug、处理线上事故、做值班……大量工作其实是信息搜集、沟通协调、上下文梳理。这些事跟写代码没半毛钱关系。 于是技术团队自己开始"吃自己的狗粮”——用Codex处理那些非编码的杂活。结果效果之好，让他们意识到：手里拿着的根本不是"代码工具”，而是一个通用得多的东西。 Tibo讲了一个让他印象深刻的瞬间：产品负责人Alexander在Codex发布前夕，同时跑着多个Codex代理——一个在搜集用户反馈，一个在跟开发者确认状态，一个在实时更新项目计划文档——而他自己正坐在会议室里跟Tibo讨论。 “我从来没见过一个人这么高效，“Tibo说，“那一刻我就觉得，我们在改变的不只是软件工程。” 这就是那个"原来这东西是给所有人用"的觉醒时刻。 面包、咖啡和"属于你一个人的软件” 为了让观点落地，Tibo在现场做了个演示。 他住在旧金山，对当地面包的离谱价格很不满，于是对Codex说了一句话：“帮我在旧金山找最好的面包，列个表格，标明价格和购买地点。” 五分钟之后，一张完整的电子表格出现了：烘焙店名、面包种类、描述、价格，一清二楚。 然后他随口又说了一句：“把同样的东西做成网页，放地图上。” 四分钟后，一个带交互地图的网页生成了——每家店的位置、面包信息、价格，全在地图上可视化呈现。他甚至可以说"对咖啡也做同样的分析”，八分钟后旧金山咖啡地图也做好了。 整个过程，Tibo连键盘都没碰——全程语音操作。 “这不是我花一整个周末才能做出来的东西，“他说，“在以前，这根本就不会发生。它不是从’几周变几秒’，是从’永远不可能’变成了’几分钟的事’。” 这就是Tibo反复强调的"个人软件"时代：每个人都有能力为自己量身打造小工具，而不用求人。设计师可以在代码库里直接改UI细节，不用跟工程师排期；市场人员可以做深度竞争分析，不用等数据团队排期。 首席参谋、自动化日报和一个"不用看邮件"的未来 Tibo自己怎么用Codex？他打开侧边栏——一天之内已经派发了上百个任务给Codex代理： 整理桌面文件 管理计算资源集群 帮我看值班轮转情况 检查即将上线的发布计划，标出有风险的项目 每天早上9点扫描我的Gmail、Notion和日历，给我一份当日摘要，标出需要注意的事项 “它就像我的小参谋长，“他说，“帮我花精力在最重要的事情上。” 他甚至做了一个"个人新闻简报”——根据他自己的偏好筛选信息，每天早上推送。以前，这种事要么不存在，要么得雇个人专门做。 更激进的想象是：未来你甚至不用看邮件了。一个全天候运行的代理读你的收件箱，只在真正重要的时候提醒你。“你只管设定目标，剩下的它帮你搞定。” 从10分钟到好几周：/goal模式的底气 对话的后半段，Tibo透露了一个正在铺开的新功能：slash goal。 普通模式下，你给Codex一个具体任务，它干完了汇报。但在goal模式下，你给它一个长期目标——比如"解决一个非常难的数学问题”——它就会像着了魔一样持续攻坚，干几个小时、几天、甚至几周，直到自己认为目标达成。 目前已经有人用它把整个程序从一种语言翻译成另一种，有人在物理和数学问题上用它突破瓶颈。 “几个月前我们还在激动它能连续工作10分钟，“Tibo说，“现在我们在讨论连续工作几周。有时候，天才不过就是能对同一件事持续思考更久。” 给非技术用户的三个行动建议 论坛上有观众问了一个很实操的问题：非开发人员到底怎么做，才能用好Codex？ Tibo给了三条： 1. 加入社群，看别人怎么用。 他自己都会被一些神奇的用法规避惊艳到。OpenAI论坛就是这样一个互相学习的地方。 2. 给它精确的指令，别模糊。 把它当成一个刚入职的新同事——没有上下文，不知道你的偏好。你得说清楚"成功长什么样"和"什么样算搞砸了”。比如要一份PPT，就明确说"我要10页，前两页放背景信息，中间六页做技术拆解，最后两页放开放问题和Q&A”。越具体，成功的概率越高。 3. 尽量连接更多信息源。 Codex现在有超过100个插件——日历、Notion、各类工具都可以接进来。接入的信息源越多，它能帮的忙就越大。 但有一条重要的提醒：别把所有事情都交给它。Tibo特别指出他见过最大的错误就是"过度委托”——把包括自己对问题的理解都一并外包出去。真正用好Codex的人，是在用它提升自己的认知，而不是替代自己的思考。它可以用图像和图表帮你理解复杂概念，但做笔记、主动回想、验证理解，永远是你自己的事。 企业落地的真正瓶颈：不是能力，是信任 当被问到企业采用的最大障碍时，Tibo的回答很直接：不是模型能力不够，是信任和安全问题。 “如果有代理在你公司里到处乱跑，不小心删了敏感文件，或者把不该发出去的信息外泄——没人敢用。” OpenAI在做三件事来解决这个： 沙箱默认运行：可以限制代理只能访问特定文件夹，甚至禁止联网 细粒度权限控制：可以设成"只能读不能写”，数据安全仍由你掌控 “自动审查"机制（Auto Review）：另一个独立代理实时监控主代理的每一步操作，风险动作直接拦截 “就像一个裁判在旁边，看到越界的操作立刻喊停。”...

本文翻译自 Thariq 在 X 上发布的文章：Using Claude Code: The Unreasonable Effectiveness of HTML。本文完全由有道龙虾翻译和发布。 Markdown 已经成为智能体与我们沟通时最主流的文件格式。它简单、可移植，有一定的富文本能力，也很容易让你编辑。Claude 甚至已经非常擅长在 Markdown 文件里用 ASCII 画图。 但随着智能体变得越来越强，我开始觉得 Markdown 变成了一种限制性格式。超过一百行的 Markdown 文件对我来说就很难读。我想要更丰富的可视化、颜色和图表，而且希望它们能轻松分享。 我也越来越少亲自编辑这些文件，而是把它们当作规格说明、参考文件、头脑风暴结果等来使用。即便我确实要修改，通常也是让 Claude 去改，这就削弱了 Markdown 最大的优势之一。 我已经开始更偏好用 HTML 作为输出格式，而不是 Markdown。我也越来越常看到 Claude Code 团队的其他人这么做。下面是原因。 如果你想先看一些例子，可以看这里：html-effectiveness，但记得回来继续读为什么。 为什么是 HTML？ 信息密度 相比 Markdown，HTML 能传达丰富得多的信息。它当然可以表达简单的文档结构，比如标题和格式，但它还可以表示各种其它信息，例如： 用表格表示表格数据 用 CSS 表示设计数据 用 SVG 表示插图 用 script 标签表示代码片段 用 HTML 元素、JavaScript 和 CSS 表示交互 用 SVG 和 HTML 表示工作流 用绝对定位和 canvas 表示空间数据 用 image 标签表示图片 我甚至会说，几乎没有 Claude 能读懂、但你无法用 HTML 相对高效表达的信息集合。这让 HTML 成为模型向你传达深度信息、并让你审阅这些信息的一种非常高效的方式。...

以下内容完全由 有道龙虾 整理，排版和发布。原视频：Head of Claude Code: What happens after coding is solved | Boris Cherny。 Claude Code 一开始并不是爆款 Claude Code 今天看起来像是突然冒出来的未来工具，但 Boris Cherny 讲得很坦白：它最早几乎是“意外”做出来的。 2024 年底，他加入 Anthropic 内部一个叫 Anthropic Labs 的小团队。这个团队像一个孵化器，人数不多，却做出了几件后来影响很大的东西：Claude Code、MCP，还有 Claude 桌面应用。 Claude Code 的起点，是团队看到了一种“产品悬空”状态。模型已经有能力做很多事，但还没有一个产品把这些能力接住。 当时写代码的主流 AI 体验还是自动补全：打开 IDE，按 Tab，一行一行补。Sonnet 3.5 已经让这种体验变得好用，但 Boris 和团队觉得，这不是终点。 他们想做的不是“帮你补下一行”，而是让 agent 直接写完整代码。 问题是，最开始真的不好用。 Boris 说，前 6 个月 Claude Code 基本没跑起来。他自己大概只有 10% 的代码会用它写。早期发布后也没有立刻爆发，虽然有人用，但远远不是今天这种增长曲线。 真正的转折点出现在 Opus 4 发布之后。Claude Code 的增长从那时开始明显加速，之后每一次模型升级，增长都会再拐一次弯。从 Opus 4，到 4.5、4.6，再到 4.7，产品能力几乎是跟着模型能力一起往前跳。 这也是 Claude Code 很特别的一点：它不是为当时的模型做的产品，而是提前半年为下一代模型做的产品。...

本文整理自 YouTube 频道 Lenny’s Podcast 的访谈视频 How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)，由有道龙虾总结和发布。 如果你还在用半年、一年为单位规划 AI 产品，可能已经慢了。 Anthropic 的 Claude Code 和 Co-work 团队，现在很多产品功能的周期已经从过去的 6 个月，压缩到 1 个月、1 周，甚至有时候是 1 天。 这不是因为他们找到了某个神奇流程，也不只是因为他们能用最前沿的模型。更核心的变化是：AI 正在把“写代码”这件事变便宜，把真正贵的东西推到台前。 那就是：判断该写什么，为什么写，写成什么样。 这也是 Cat Woo 在这次访谈里反复强调的主线。她是 Anthropic 负责 Claude Code 和 Co-work 的产品负责人，和 Boris 一起站在 AI 原生产品构建的最前线。她看到的变化很直接：PM 的角色没有消失，但它正在被重新定义。 PM 的工作，不再是守着路线图开会 Cat Woo 对自己和 Boris 的分工有一个很有意思的描述。 Boris 更像技术负责人和产品愿景提出者，能看到 3 个月、6 个月之后产品该长成什么样，甚至是“AGI pilled”版本的产品该是什么样。...

本文整理自 YouTube 视频《Box CEO on AI Agents & Why Enterprise Can’t Keep Up | a16z》，由有道龙虾总结和发布。 硅谷现在谈 AI，很容易把一切说得像已经解决了。 模型越来越强，agent 会用工具，会写代码，会操作电脑。于是很多人自然得出结论：企业里的知识工作很快会被自动化，SaaS 会被替代，工程师会变少，咨询公司和系统集成商也该退场。 但 Aaron Levie、Steven Sinofsky 和 Martin Casado 这场对话给了一个更贴近现实的版本：企业 AI 最大的阻碍，不是模型不会回答问题，而是系统太旧、权限太碎、数据太散、流程太复杂。 AI 可以让人更快地产生软件和信息，但它不会自动把一家运行了十年、几万人使用、堆满遗留系统的大公司变得清爽。 真正的企业 AI 落地，难在 integration。 硅谷和真实企业之间，有一道工作方式鸿沟 Aaron Levie 说，他现在的工作有点像“把现实带到硅谷，再把硅谷带回现实”。 这句话背后，是他在企业客户那里看到的巨大落差。 在硅谷，尤其是工程师群体里，人们使用 AI agent 的条件太好了：技术能力强，能读懂错误，能自己选工具，能调试环境，能接受新范式；更重要的是，代码任务天然适合模型，因为代码可验证，反馈循环清楚。 但企业里大多数知识工作不是这样。 普通员工技术门槛更低，数据分散在多个系统里，流程沉淀了多年，权限经常不清楚，历史系统很多，安全和合规要求也更重。你不能简单把 coding agent 的成功经验搬过去，然后期待财务、法务、客服、采购、人力都同样提速。 这不是政府和科技行业那种“互相听不懂”的差异，而是工作流和技术环境本身就不同。 所以 AI 从硅谷扩散到整个知识工作世界，会需要几年时间。不是因为模型不够酷，而是因为企业要把旧系统、旧流程、旧权限和新 agent 接起来。 “95% 企业 AI 项目失败”这类说法，问题出在定义 Martin Casado 提到，类似 MIT “95% 大公司 AI 项目失败”的统计，其实很容易误导。 如果说大公司里没人有效使用 AI，那显然不对。很多员工已经在用 ChatGPT、Claude、Copilot 这类工具提高个人效率。...

本文整理自 YouTube 视频《AI era skills: Why cultivating agency matters more than job titles | Max Schoening (Notion)》，由有道龙虾总结和发布。 AI 让很多人第一次意识到：以前挡在自己面前的，可能不是技能，而是行动力。 过去你可以说，“我不会写代码，所以我做不了这个产品”；“我不是设计师，所以我做不了这个界面”；“我不是工程师，所以我只能写 PRD”。但当模型把很多技能放到你手边，真正的差距就暴露出来了：你到底有没有把世界当成可改变的东西？ Notion 产品负责人 Max Schoening 在这场访谈里，几乎一直围绕这个问题展开。他做过 Google 产品经理，带过 Heroku 设计团队，在 GitHub 做过设计和工程领导，也是两次创业者。现在，他在 Notion 负责产品，是少数真正把设计、工程、产品、AI 工作流混在一起实践过的人。 他对 AI 时代产品团队的判断很直接：角色会变，工具会变，第一版产品会越来越便宜。但最后能拉开差距的，不是你会不会“用 AI 写代码”，而是 agency、品味、质量意识，以及你能不能抓住产品里那个小到不能再小、却强到让人离不开的核心。 Notion 的起点：别在 Figma 里画一条死鱼 Max 刚加入 Notion 时，团队正在做很多聊天界面。问题是，他们一开始仍然用 Figma 设计这些聊天界面。 这听起来正常，但在 Max 看来，静态聊天界面像 Brett Victor 那个著名演讲《Stop Drawing Dead Fish》里说的“死鱼”。AI 不是静态页面，它的体验来自对话、流动、响应、失败、恢复和迭代。你只看一张图，很难真正感受到这个东西是否有效。 于是 Max 和两个设计师做了一个非常粗糙的 playground：一个小代码库，尽量 LLM-friendly，用模型擅长的技术栈，让设计师可以直接在里面原型 AI 聊天体验。 这不是为了让设计师马上给生产代码提 PR，而是为了让他们用“真正的材料”思考。...