Posts for: #AI

刷到一个小工具，叫 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 项目。