Posts for: #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 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，一个把代码仓库索引成知识图谱、再通过 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 工具用透，再去看新工具。

刷到一个小工具，叫 Tritree。

打开它不是给你一个空白框让你写提示词，而是 AI 一次给三个方向不同的稿子，你点一个，它接着长出下一轮三个。没选的折叠成树枝留在画布上，想回去看随时回得去。本地跑，SQLite 存数据，没登录没订阅。

作者用它写了一条微博，三轮，每轮点一下，就出来了。

The Hacker News 报道了一起 npm 供应链攻击：Bitwarden CLI 的 npm 包（@bitwarden/cli）2026.4.0 版本被植入恶意代码，藏在包内的 bw1.js 文件里。

感染窗口从 4 月 22 日 ET 时间下午 5:57 到 7:30，约 1.5 小时，估计 334 次下载。被怀疑是更大规模 Checkmarx 供应链攻击的一部分，归因到 “Shai-Hulud: The Third Coming” 这一波。

攻击路径

攻击者拿下了 Bitwarden CI/CD 流水线里一个被入侵的 GitHub Action（checkmarx/ast-github-action），通过 preinstall 钩子在用户 npm install 时执行恶意代码。

据安全研究员 Adnan Khan 说，这可能是首次使用 npm Trusted Publishing 的包遭到入侵。

恶意代码偷什么

• 本地开发凭证：GitHub / npm tokens、.ssh 密钥、.env 文件、shell 历史
• 云端密钥：GitHub Actions 环境变量、CI/CD secrets、多云凭证
• AI 编码工具配置：Claude、Kiro、Cursor、Codex CLI、Aider 的认证配置
• 自传播：偷到 GitHub token 后注入恶意 Actions workflow，用偷到的 npm 凭证向下游包发布恶意版本，蠕虫式扩散
• 数据外泄走 AES-256-GCM 加密发到伪装域名 audit.checkmarx[.]cx，失败后以 GitHub commit 作为 fallback

有一个细节：如果系统 locale 是俄罗斯，恶意代码自动退出。这一行为与原始 Checkmarx 攻击不一致。

翻译自 YC 合伙人 Diana 的演讲：How To Build A Company With AI From The Ground Up，2026 年 2 月。我按自己的语感重新整理了一遍，方便中文读者读起来不卡。

我是 Diana，YC 的合伙人。

过去几个月我看清了一件事：AI 不只是让软件造得更快，也不只是让某些工作流自动化。它正在从根本上改变创业公司应该怎么跑——什么人留下、什么岗位消失、什么产品现在能造出来。

这一期我要讲创始人应该怎么思考"AI 原生公司"——团队该有什么角色、内部该用什么具体做法，让你立刻就能跑得更快。

AI 不是工具，是操作系统

现在大多数人聊 AI 都还停留在"提高生产力"这一层：让工程师更高效、给现有流程接个 AI 助手、多发几个功能。

这个框架完全错过了正在发生的事。

我们看到的不是"效率提升"，是全新的能力：今天一个对的人加上 AI 工具，能做出过去要一整个团队才能做、或者根本做不出来的东西。

把 AI 想成"新能力"，对创始人意味着什么？

往大了说：AI 不应该是你公司在用的工具，应该是你公司运行的操作系统。每一个工作流、每一个决策、每一个流程，都应该流经一个持续学习、持续改进的智能层。

具体一点：你公司里每一个重要流程，都应该被一个智能闭环包住。闭环捕捉信息、把信息喂回智能系统、让流程随时间变得更好。

开环还是闭环？

学过控制论的人对这两个词不陌生。

• 开环：被控制的系统没有反馈。在过去，公司基本都是开环——你拍板、你执行，但不一定系统性地测量结果、不一定把结果回写到流程里。开环本质就是有损的。
• 闭环：自我调节。系统持续监测自己的输出、持续调整流程，让结果越来越接近目标。闭环在"准确性"和"稳定性"上极强。

有了能自我改进的智能体，你的公司就该按闭环来跑。

让公司对 AI 可查询

要让闭环跑起来，你得让整个公司可被查询。换句话说，整个组织对 AI 是可读的。每一个重要的动作都要产生一份可被读取的记录，让公司中央的智能层能从中学习、能用来自我改进。

具体怎么做：

• 所有会议都用 AI 记录下来
• 减少私聊和邮件，把智能体嵌入所有沟通渠道
• 自建仪表盘把公司里的所有数据接进去：营收、销售、工程、招聘、运营——全部
• 给智能体同时接入：项目工单系统、所有工程聊天频道、所有客户反馈（来自邮件或客服系统）、代码仓库、文档系统里的高层计划、销售电话录音、每日站会

我举个具体例子。工程管理和迭代规划。

如果你的智能体能同时访问：你的工单、所有工程频道、来自邮件和客服系统的所有反馈、代码仓库、文档里的高层计划、销售电话录音、每日站会——那它就能告诉你上一轮迭代实际交付了什么、是不是真的满足客户需求。

更进一步：在拥有"上线了什么、什么成了、什么没成"的完整可见性之后，智能体可以往前看，给工程师提出远比拍脑袋更可预测、更准确、更跟得上节奏的下一轮迭代计划。

那种被各级经理塞水状态汇报、信息一路衰减的日子，过去了。

我自己带过工程团队，现在又在多家 YC 公司里看到这件事——这是个颠覆性变化。过去需要持续协调才能维持的东西，默认就变得可读、可查询。我看到的团队里，有些把迭代时间砍掉了一半，相同时间内做的事接近 10 倍。

herdr 是一个给 AI coding agent 用的终端工作区管理器。

它自己也有 workspace、tab、pane，能分屏、切换、恢复 session。只看这一层，它很像 tmux。

它和 tmux 的区别，在另一层。

tmux 管的是终端会话。herdr 除了管会话，还会识别 pane 里跑的是不是 agent，再把状态标出来。README 里列出的状态有四类：working、blocked、done、idle。

比如同时开几个 pane：

• 一个 pane 跑 Claude Code
• 一个 pane 跑 Codex
• 一个 pane 跑开发服务器
• 一个 pane 看日志

tmux 可以把这些 pane 摆好，也可以后台挂着。herdr 额外做的是：识别哪个 pane 里在跑 agent，哪个 agent 在忙，哪个在等输入，哪个已经停下来。

它判断状态主要靠两种方式。

第一种，看前台进程和终端输出。

第二种，接工具自己的 hook 或 plugin。文档里已经写明支持给 Claude Code、Codex、pi、OpenCode 装集成，这样状态报告会更直接。

除了给人看，herdr 还有本地 socket API。agent 自己也可以调用这些接口，比如：

• 新开 workspace
• 新开 tab
• 分一个 pane
• 读另一个 pane 的输出
• 往另一个 pane 发命令
• 等另一个 agent 完成

所以它不只是“把几个终端摆在一起”，还多了一层对 agent 的状态管理和控制。

我维护着一个叫 context 的个人上下文系统：一份中心 markdown，分发到 Claude Code、Codex CLI、Gemini CLI、OpenClaw 的配置路径里，保证同一个"我"在各个工具之间一致。

这个系统每天自动扫当天的对话，把我说过的偏好、决策、踩坑提炼到 OBSERVATIONS.md。问题是——它只懂 Claude Code 一家的 JSONL 格式。我同时还在用 Codex、Gemini、OpenCode，这些对话历史全都被扔在一边。

每家 AI 助手的对话都存在本地，但格式各家不同。Claude 用 JSONL，Codex 也用 JSONL 但 schema 不一样；Gemini 用整块 JSON；OpenCode 用 SQLite，message 和 part 分两张表；Cline 和 Cursor 藏在 VSCode 扩展的 globalStorage 里；Aider 干脆写在项目目录的 markdown 里。

自己从零逆向这些格式，不是我想干的活。

在 GitHub 上撞见 jhlee0409/claude-code-history-viewer，简称 CCHV。本意是个桌面历史查看器——七家 AI 助手的对话在一个界面里翻。我对桌面 app 本身不感兴趣，但它的 Rust 源码里有一个 providers/ 目录：七个文件，每家一个解析模块。每家的存储路径它替我找好了，每种格式的 schema 它替我逆向完了。

让 AI 把这部分代码翻成 Python，挪进 context 项目。

GitHub 上有个项目叫 agency-agents（https://github.com/msitarzewski/agency-agents），184 个 AI agent 人格档案，分二十多个部门：工程、设计、营销、销售、财务、产品、项目管理、测试、支持、空间计算。每个档案是一个 markdown，写清楚这个 agent 的身份、工作流、交付物和成功指标。一行命令可以装到 Claude Code、Copilot、Cursor、Gemini CLI、Aider、Windsurf、Kimi Code 等十来个工具里。

同类项目不少，大多是"程序员的 Claude Code subagent 合集"。agency-agents 的不一样在两点。

一是跨工具。一套档案通过 scripts/convert.sh 生成适配各家工具的格式，不绑死在 Claude Code。这是硬工程活，大多数对手不做。

二是真的把中文互联网生态当作一级公民来写。小红书、公众号、抖音、知乎、B站、百度、微博、快手、私域（企微）、直播电商、淘系拼多多、跨境电商，还有小程序开发、飞书开发——每个平台一个专属档案。英文圈的 agent 仓库基本不碰这块。

让 AI 抽读了一遍中文生态的 13 个档案，质量良莠不齐。对这个项目的态度也简单：别整包用，挑着用。

CLIProxyAPI 是一个 Go 写的本地代理服务器。它把 Gemini CLI、OpenAI Codex、Claude Code 这些需要 OAuth 登录的 CLI 工具，包装成 OpenAI / Gemini / Claude / Codex 兼容的 API 端点。

装上之后，Raycast、IDE 插件、自己写的脚本都能当成标准 API 来调用，不必再走官方 CLI。支持流式和非流式响应、函数调用、多模态输入、多账号轮询负载均衡，也能把 OpenRouter 这类上游 OpenAI 兼容服务接进来。配套有 Go SDK 和管理 API。

这类工具踩在各家 TOS 的灰线上。OpenAI 和 Anthropic 都明确禁止把订阅席位用作 API 式访问或转售，多账号池化、高频率轮询、不像真人的行为画像都是风控识别的信号。最近 Claude Code 订阅号被封得比较多，原因是拿订阅额度对外跑 API 流量。Gemini 相对宽松，AI Studio Build 大规模轮询也在收紧。自用一两个号本地接客户端风险不大，池化多号对外服务就是另一回事。

项目的赞助商里挂了六七家 API 中转服务商，都是做 Claude Code / Codex / Gemini 官方渠道代理的。