Posts for: #AI

Warp 文档站的 agent 工作流

Warp 是从终端起家的 AI 开发环境。2026 年 5 月,它把产品文档站 docs.warp.dev 的源代码开源了,仓库地址 github.com/warpdotdev/docs。这个仓库除了文档内容本身,还配了一整套用 AI agent 维护文档的工作流。

文档站基于 Astro 6 + Starlight,内容用 MDX 写在 src/content/docs/ 下。Node.js 22 起步,npm installnpm run dev 启动本地预览,端口 4321。“Ask AI” 按钮和 “Was this helpful?” 反馈是可选功能,需要在 .env 里填公开值。

下面分四块说明仓库里 agent 相关的结构。

.agents/ 目录

.agents/ 分四个子目录:

  • skills/25 个 skill。每个 skill 是一个子目录,里面至少有一个 SKILL.md 描述用途和执行步骤,部分含有 references/scripts/
  • rules/ — 通用规则,当前只有一个 oz-style-guidelines.md
  • templates/ — 不同类型文档页面的模板(quickstart、guide、procedural 等)。
  • references/ — 词汇表等参考资料。

25 个 skill 按用途分四类:

草稿生成(10 个)draft_quickstartdraft_guidedraft_proceduraldraft_conceptualdraft_referencedraft_faqdraft_troubleshootingdraft_feature_docdraft_docsmissing_docs。从空白页起一篇新文档时使用。

[阅读全文]

为下一代模型做产品

上次整理过 Lenny’s Podcast 那期 Boris Cherny 的中文版:编程已被"解决"之后的世界。这次是 Boris 在 Sequoia Capital 的另一场访谈(2026-05-04 发布,YouTube 24 分钟版),重叠不多,更聚焦在 Claude Code 起源、他现在的工作方式,以及组织和团队的变化。下面是我整理润色的中文版。

现场

主持人是 Sequoia 合伙人 Lauren Reeder。她介绍 Boris 时说:“整个软件开发似乎都压在他肩上。“她想聊三个方向:软件的未来、写代码的未来、大家以后应该把空闲时间花在什么事情上。

Lauren 顺带补了一个细节:Boris 一直是非常纯粹的工程师,写过《Programming TypeScript》。但她上次和 Boris 聊时,Boris 说自己 2026 年到目前为止,没有亲手写过一行代码。

Boris 反问现场使用 Claude Code 的方式。多数人主要用 CLI;桌面端用户也有一些;VS Code 或 JetBrains 插件用户相对较少。他自己现在反而主要在 iOS 上用。

Claude Code 是怎么开始的

Claude Code 很大程度上是"意外"做出来的。

Boris 在 2024 年底加入 Anthropic Labs。这是 Anthropic 内部的一个孵化器——非常小,像一个创新小组。这个小组后来做出了 Claude Code、MCP 和桌面 app。完成阶段性任务后团队一度解散,现在又重新聚在一起做第二轮,由 CPO Mike Krieger 带队(前 Instagram 联合创始人)。

[阅读全文]

把 AI 推广做成产品

来源:How I AI 频道访谈,主持人 Claire Vo,嘉宾 John Kim(Delight.ai)。视频 https://www.youtube.com/watch?v=uH39OZ-KnkY 。下面是我整理润色的中文版。

开场

John Kim 要展示两样东西。一个是公司内部的 AI token 使用排行榜——每个人会从 “AI newbie” 到 “AI god” 被分层。另一个叫 AI quests,用来推动全公司采用 AI。

John 想做的事情,是把 AI 变成 workforce 的一部分:给团队足够的信息、工具和基础设施,让员工自己去用 AI 的能力。

很多公司推 AI 时,员工听到的是"用更少的人做更多事"“你应该更快”。John 展示的另一种收益:让每个人都成为 builder,做出以前不会被排进路线图、但有创造力和客户价值的东西。

案例:营销团队两天做出能收款的周边商店

John 演示了 Delight 的 swag store,主题是 Big AaaS Energy(AaaS = Agent as a Service)。

整个商店由营销团队完成,没有工程团队支持。它接了 Stripe,能真的下单付款。两天上线。

商店里有 “My AaaS is bigger than your SaaS”、“Context window I carry a lot” 这类周边。还藏了一个 Konami code 彩蛋(上上下下左右左右 BA),引导到 5 月 7 日在旧金山的 Delight Spark 大会。

[阅读全文]

browser-use 团队又出了一个东西,叫 bux

browser-use 团队最近又放了一个新项目:bux,全名 Browser Use Box。

它解决的问题很具体:现在所有 AI 助手都绑在你设备上,合上电脑就死。bux 把 Claude Code 加一个真实 Chromium 浏览器,再加一个 Telegram 机器人,打包成一条安装脚本,扔到任何一台 5 美元的 VPS 上跑起来。

跑起来之后是什么效果?早上你在地铁上发一条 Telegram,“看看今天未读邮件,回那条 LinkedIn 消息说不感兴趣”,下班前活已经干完了。机器一直开着,账号一直登着,不用你守在电脑前。

三个细节我觉得做得对。

第一,用真实 Chromium,不是 headless 浏览器。Cookie、登录态都持久化在服务器上,账号一直在线。

第二,遇到验证码、2FA、登录墙的时候不硬刚。它会生成一个实时页面 URL 推给你,你点开手动过验证,AI 接着干。大多数自动化工具死在这一步——硬刚就被风控、被封号。bux 直接承认这件事 AI 做不了,让人来。

第三,整个架构就三个 systemd 服务:Telegram 机器人收消息,喂给 Claude,调浏览器。状态全在 /home/bux 一个目录里,重启不丢。打开看一眼就知道每个零件在哪。

安装是一条 curl 命令,三分钟从空白 VPS 到能用。

browser-use 主项目 GitHub 6 万多 star,bux 又是 Claude Code 加 Telegram 加云端浏览器一条龙打包好。这个团队战斗力真的强。

GitNexus 这类工具,大概率不需要

看了一下 GitNexus,一个把代码仓库索引成知识图谱、再通过 MCP 喂给 Claude Code / Cursor / Codex 的工具。

它解决的是一个具体的人的具体问题:写大型项目的工程师,让 AI 帮忙改代码时,经常遇到 AI 改了 A 函数、没注意到 B、C、D 也调用它。一次小改动,跑起来三处崩。

为什么会这样?AI 不是不会读代码,是不知道该读哪些。Context window 再大,AI 自己也不会主动把整个仓库塞进去,成本太高。grep 能找调用方,但要 AI 自己想到去 grep,还得来回跑好几轮。调用链一深,就漏。

GitNexus 的做法是预先把每个函数、每条依赖、每条调用链都建好图。AI 要改一个函数,先查图:谁调用我、我调用谁、改了会炸到哪里。一次查询出结果,不用反复读文件。

但我的判断是,大多数人不需要装这类工具。

过去半年 Claude Code、Cursor、Codex 这批 AI coding 工具进步得很快。grep、glob、Read 这些基础工具调度得很熟,subagent 可以预先装"探索代码"的 SOP,写好一份 CLAUDE.md 把架构地图、关键模块、依赖关系交代清楚,AI 漏改调用方的事故已经少了很多。原本 GitNexus 想解决的痛,AI 工具自己在解决。

什么时候才值得试?我的顺序是这样:

先调 AI 工具本身。CLAUDE.md 写清楚架构地图、关键模块、依赖关系,subagent 装好探索代码的 SOP,每次改代码前要求 AI 先列出受影响的调用方。这些都是免费的,先做。

做完还在频繁踩坑,再考虑 GitNexus 这类工具。频繁是多频繁?一周两三次都不够,得是改代码的过程里反复出事故、CLAUDE.md 怎么写都救不回来,才值得多装一个工具。

大多数人不会走到这一步。痛感真到那个程度,往往不是 AI 工具的问题,是项目本身的复杂度已经超出了人脑+AI 配合的舒适区。那时候装 GitNexus 也只是缓解,不是根治。

所以结论很简单:先把手上的 AI coding 工具用透,再去看新工具。

[阅读全文]