AI Bridge

Product Hunters，大家好 👋

我开发 AI Bridge 是为了解决我自己遇到的几个问题。自从 Claude Code 和 Codex 出现后，我几乎只在终端里工作。除了偶尔需要修改 .env 文件外，我已经基本不用 VS Code 了：我的整个工作流都变成了在终端中与智能体协作，调查代码并审批改动。

Cursor 掀起的这场变革几乎与我无关。公司给我提供了 Cursor 订阅，但我几乎没怎么用过；我从来不觉得自己需要查看整个代码库。如果我需要找某个东西，就让 AI 帮我找到，并在终端中打开对应文件。如果我需要修改代码，就让 AI 完成修改，然后由我检查并批准。

💡 后来，一位朋友给我展示了一个智能体管理工具，我的思路豁然开朗：让智能体更容易管理确实是个好方向，但那个工具的实现方式并不适合我的工作流。也正是那时，我开始开发 AI Bridge。

😩 我遇到的痛点

需要 managing 一堆终端窗口。我希望前端和设计工作能单独放在一个会话中，不要让数据库查询、集群检查或同事临时提出的支持请求污染会话上下文。我想按照部门或职能对公司内的智能体进行分组，同时在同一个应用中使用我的个人项目和咨询业务。

🛠 AI Bridge 为我带来的能力

🗂 按智能体承担的工作，而不是代码库，对我的智能体（实际运行的 CLI）进行分组，同时仍然保持终端式界面。

🗄 让我直接与数据库对话并查看数据。以前，我得让智能体执行查询，却没有办法直观查看结果，除非打开 phpMyAdmin 或 Postico。

☸️ 直接连接 Kubernetes 集群：我可以看到 Pod 的更新情况，检查 External Secrets、Argo 或 Flux 是否已同步，或者以可视化方式浏览集群。AI 可以快速检查集群健康状况，但经验丰富的工程师借助优秀的可视化工具也能做到，而且对我来说，这比再询问另一个智能体更高效。

💬 将智能体连接到 Slack 频道。当同事向我询问 DevOps 或平台相关的问题时，请求会进入 AI Bridge，由我审批。智能体会使用我授予的权限从终端中运行，而回复发回 Slack 前也需要经过我的批准。

🔲 在我需要熟悉的 zsh 和其他终端体验时提供 Grid，同时还具备上述所有功能。

🔁 在不同电脑之间迁移 Claude Code 和 Codex 会话：两台笔记本电脑都安装 AI Bridge 后，我可以在一台电脑上导出会话，再在另一台电脑上导入。

👋 关于我

过去几年，我先后担任过云技术负责人、首席工程师和工程总监，目前经营自己的咨询业务，帮助客户处理基础设施、自动化、合规和内部工具等问题。如果你的工作横跨全栈、云端、产品和支持等領域，你会发现 AI Bridge 很有用。

我每天都在自己的工作中使用它，也很想听听大家希望它下一步支持什么。