Posts for: #AI

看了一下 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 的状态管理和控制。