我的AI订阅与工具矩阵:从“工具堆砌”到“个人智能操作系统”

这两年，很多人都在不断加购 AI 工具：这个开会员，那个买额度，桌面上一排 App，终端里一串 CLI。表面上能力越来越强，实际上却常常陷入同一个问题： 工具越来越多，但工作流并没有真正变强。

我自己的思路，是不再把 AI 订阅当成一个个孤立的“单点神器”，而是把它们放进一个分工清晰、可以长期运转的系统里。当这些角色被理顺之后，AI 工具就不再只是零散的订阅，而开始变成一套真正嵌入日常工作流的个人智能操作系统（Personal AI OS）。

这套系统的核心逻辑是：订阅层提供燃料，衔接层打开接口，执行层完成转化，补位层负责全时守护。

一、订阅层：我的“能力燃料库”

我的核心订阅有三项，另外配置了两类执行层资源。它们的价值不在于名气有多大，而在于是否具备真正的不可替代性。

1. 情报层：Super Grok

在我的体系里，Super Grok 更像是一个外部信息雷达。 我最看重它的，是搜索能力以及它对 X 生态的贴近度。它负责“向外看”，追踪海外 AI、开发者社区和热点议题的变化。围绕我长期关注的方向，它可以帮我快速捕捉线索，沉淀为日报或周报。所以，Grok 在我的工作流里不是用来深度生产的，而是高质量输入的起点。

2. 研究层：Gemini Pro × NotebookLM

如果说 Grok 负责把外部世界的变化带进来，那么 Gemini Pro 和 NotebookLM 负责的，就是把这些信息以及我已有的资料，转化成可以被理解、被组织的认知资产。 很多知识工作真正的难点，不是信息太少，而是资料太多、太散、太难消化。NotebookLM 的价值，就在于它更适合围绕“我自己的资料”展开工作：把积累的 PDF、报告、网页和笔记，从“存过”变成“理解过”，再变成“可提问、可组合”的研究基础。它们共同构成了我的“知识消化系统”。

3. 推理与代码层：ChatGPT Plus

ChatGPT Plus 在我的矩阵里，承担的是高强度推理与复杂代码生成的角色。如果说 Grok 偏向“看见外部”，Gemini 偏向“接通生态”，那么 ChatGPT Plus 就是复杂任务的攻坚层。

4. 执行层资源：方舟与百炼

除了三项核心订阅，我还配置了两类偏执行侧的资源：

• 字节方舟 Coding Plan Lite
  
  ：主要为本地基础任务持续供能。
• 阿里百炼 Coding Plan Lite
  
  ：主要驱动云端节点长期在线。

二、衔接层：从“网页订阅”到“接口红利”

这是整个矩阵真正运转起来的隐秘线索。 很多人购买 AI 订阅，主要是为了解锁网页端的聊天框；但在我的工作流里，订阅更重要的价值，在于它是把模型能力接入本地执行层的通行证。

1. Gemini Pro 的意义：打通 Google AI Studio 与 Nano Banana

对我来说，订阅 Gemini Pro 的核心红利，是让我拥有了 Gemini CLI 和 Google AI Studio 中的充足 API 额度。 一旦有了这个额度，事情就变了。这不仅支撑了 Gemini CLI 在本地的高频调用，更是驱动“非网页端 Nano Banana”（Google 最强生图扩展）的唯一凭证。它让我把原本停留在网页里的多模态能力，真正变成了命令行里可以被随意编排的代码节点。

2. ChatGPT Plus 的意义：获取 Codex 的顶尖算力

同样地，我订阅 ChatGPT Plus 的核心原因，是为了获得比较充足的 Codex 调用额度。这让顶级的代码思考能力能够直接注入我的本地工具（OpenCode），参与我每天要处理的复杂工程环境。

3. 算力路由与成本控制：为什么有了 Codex 还要买 Coding Plan？

既然已经有了顶级的 Codex，为什么还要额外配置字节和阿里两条资源？答案是：算力路由（Routing）。 Codex 能力极强，但GPT-5.4额度宝贵。如果把所有日常任务都交给它跑，极其奢侈且浪费。因此我设置了多 Agent 的路由模式：

• 高难度攻坚
  
  ：复杂的代码重构、深层逻辑推演，自动路由给 Codex。
• 基础任务
  
  ：日常轻量总结、思考、写作、查询等工作，路由给方舟或百炼 Coding Plan。 让最聪明的脑子处理最难的问题，让最具性价比的模型承担基础执行。这才是成熟系统的算力分发机制。

三、执行层：本地 CLI 才是生产力真正落地的地方

带着上述的接口凭证，我在本地部署了两套分工明确的 CLI 代理，它们共同管理我的 Obsidian 笔记仓库（我长期思考与内容创作的核心现场）：

1. OpenCode CLI：重型生产力入口

• 接入
  
  ：Codex 与方舟 Coding Plan。
• Skill 定位
  
  ：思考、写作、复杂 Coding。
• 作用
  
  ：它偏向结构化、工程化的工作。它的意义是把高质量代码能力和本地环境结合，是我当前最重要的本地主力入口。

2. Gemini CLI：命令行里的生态中枢

• 接入
  
  ：Google AI Studio API。
• Skill 定位
  
  ：生图（Nano Banana）与 Google Workspace 和 Notebook LM生态联动。
• 作用
  
  ：它更像“连接器”。负责连接 Google 生态中的文档处理，并在命令行里直接执行高质量的多模态生成任务。

四、补位层：OpenClaw 作为 AFK 云端分身

除了本地工作流，我还保留了一套云端节点：OpenClaw。它部署在阿里云轻量应用服务器上，接入阿里百炼 Coding Plan。

在我的矩阵里，它承担的不是主力前台，而是 AFK（Away From Keyboard，离开键盘）场景下的补位角色：

1. 知识库镜像
   
   ：云端同步了本地 Obsidian 仓库的镜像。当我离开电脑时，仍可通过移动端接入它，将其作为随身知识库继续工作。
2. 主动提醒与摘要
   
   ：例如负责重要邮件 Thread 的自动总结提醒，以及碎片化对话的轻量处理。 它就是我的“云端分身”，填补了本地主工作流在移动端的空白，确保了思考的连续性。

五、数据地基：长期可用的系统离不开底层稳定

很多 AI 工具最后沦为玩具，是因为没有稳定的底层资产支撑：

1. MySQL RDS（结构化数据底座）
   
   ：我在接入 AI 之前就长期部署的基础设施。它负责重要数据的存储与处理，让各类 AI 的自动化、归档、提醒有了可持续依附的事实底座。
2. OSS（知识资产的稳定存放层）
   
   ：作为 Obsidian 的图床。它解决了一个看似很小却极致命的问题——避免笔记迁移、设备切换导致图片链接失效。引用链一旦稳定，知识体系才具备长期积累的价值。

结语：形成协同，而不是单打独斗

回头看，一套好的 AI 矩阵，重点从来不是工具越多越好，而是每个模块是否各司其职：

• Grok
  
   负责向外看（情报感知）
• NotebookLM
  
   负责向内化（资料消化）
• OpenCode
  
   负责干重活（本地攻坚）
• Gemini
  
   负责连生态（链路与生图）
• Zed
  
   负责统调度（统一操作台）
• OpenClaw
  
   负责守全时（云端补位）