夜雨聆风天天纠结用哪个 AI？
六大 AI 工具，别再比谁强
先找任务瓶颈再选
执行 · 判断 · 读图 · 出稿 · 复用 · 在线
六大工具决策表 · 实战分工与调度
📦 3 Parts + Conclusion
👉 滑动
PART 01
任务触发词
一眼选对
PART 02
六大决策表
定位与边界
PART 03
三条分界线
混选破局
PART ///
写在最后
瓶颈即选择
开头金句
六个 AI 工具摆在面前，每次都要重新想用哪个。这套方法就是让选择变成条件反射。
📋 一句话摘要
选 AI 工具别比谁强，先找任务瓶颈——执行、判断、读图、出稿、复用、在线，再定主责与协作。
你手上有 Codex、Hermes、Claude Code、Antigravity、WorkBuddy、OpenClaw 六个 AI 工具，每个都有自己擅长的一摊。麻烦不在于谁更强，在于每次接到任务，你还要花三分钟想“这次该用谁”。
这三分钟浪费的不是时间，是切换成本。你在这个工具里试了一半，觉得不对劲，换一个再来。上下文丢了，思路断了，最后哪个都没用好。
这份决策表做的事很简单：把工具选择压缩成几个问题。先看任务瓶颈是什么，再看默认该用谁，最后决定要不要协作。看完之后，任务在脑子里冒出来的瞬间，你手上应该已经打开了正确的工具。
〇
PART
任务触发词与快速判断
QUICK ROUTING
常见任务的默认选择
快速判断卡
做日常/跑 SOP ➔ 打开 Hermes；干活/写代码/处理数据 ➔ 打开 Codex；看大图/读扫描件 ➔ 备用 Antigravity；修排版/做美工 ➔ 备用 WorkBuddy。
一
PART
六大工具决策表
SIX TOOL MATRIX
一张表看全六个工具：底座模型、一句话定位、核心优势、使用边界、适用场景，以及最容易混选的工具与分界。
二
PART
Hermes 的协调机制
COORDINATION HUB
为什么需要 Hermes 协调工具？
单独用 Codex、Antigravity 和 WorkBuddy 的时候，你自己在工具之间做搬运工：从这边复制一段文字，到那边粘贴，再跑回来对照。Hermes 做的事是把“什么时候叫谁、先叫谁、结果怎么接回来”沉淀成固定流程。你下次想再做一遍，一句话就够了。
Hermes 如何协调 3 个 Agent
┌───────────────────────────┐
│ Hermes (大脑 & 中枢) │
└─────────────┬─────────────┘
│
┌─────────────────────────┼─────────────────────────┐
▼ ▼ ▼
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
│ 1. 逻辑层 │ │ 2. 物理层 │ │ 3. 数据层 │
│ Skill SOP 规则引擎 │ │ MCP / CLI / API 接口│ │ JSON 结构化数据总线 │
└─────────────────────┘ └─────────────────────┘ └─────────────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
▼ ▼ ▼
┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────────┐
│ Codex (主力执行) │ │ Antigravity (备用研究)│ │ WorkBuddy (备用交付) │
│ 写代码 / 跑数据脚本 │ │ 搜网页 / 读扫描件PDF │ │ 导出 PPT / Word 汇报 │
└───────────────────────┘ └───────────────────────┘ └───────────────────────┘
逻辑层（Skill SOP 规则引擎）
Hermes 内部的 Skill 是一套结构化的 SKILL.md 指令库，明确规定了任务拆解步骤，如“第一步调用 Antigravity 抓素材 → 第二步调用 Codex 清洗 → 第三步调用 WorkBuddy 出排版”。
物理层（MCP 协议与 Shell/CLI 命令）
Hermes 通过 MCP（Model Context Protocol）或本地 Shell 命令在后台拉起 Codex 脚本、Antigravity 网页抓取工具或 WorkBuddy 排版服务。
数据层（JSON 结构化数据总线）
跨 Agent 传递数据时使用标准的 JSON / Markdown 协议，消除二义性，确保数据无损传递。
— Hermes 通过规则、接口和数据完成工具调度
三
PART
三条主要分界线
THREE BOUNDARIES
分界线 1：Codex 与 Claude Code 的不同
这两个工具常被简化为“GPT 编程”和“Claude 编程”的比较，但这种概括很难真的帮你做选择。
Codex 回答的是：“怎么把这件工程做完？” 关注任务推进：扫描 300 个文件 → 修改 47 个 → 跑脚本 → 修错误 → 测试 → Git diff → 输出结果。
Claude Code 回答的是：“这件事情到底应该怎么做？” 关注复杂判断：为什么这个架构三个月后一定出问题？为什么这段代码偶发死锁？Codex 做的方案有没有隐藏风险？
实践规则：
执行问题 → **Codex**
认知难题 → **Claude**
最佳组合：**Claude 定方案 → Codex 施工**
分界线 2：Hermes 与 OpenClaw，先看证据再看功能
这两个工具最容易被拿来比“谁更像总控台”。但你真正需要做的，不是功能对比，而是先分清一件事：谁已经进入你的真实工作流，谁还停留在网上的描述。
Hermes 已经有明确定位：它最值钱的是把你的经验沉淀成 Skill，并承担任务路由、流程复用、上下文衔接这层工作。它更像你的工具操作系统，决定这次先叫谁、结果怎么接回、哪些流程值得长期固化。
问题来了 → Hermes 判断类型 → 分发给 Codex / WorkBuddy / Antigravity → 收回结果 → 下次沉淀成 Skill
OpenClaw 当前只能算候选能力。远程、常驻、Cron、Gateway，这些描述听起来成立，但你还没亲测闭环。它现在不是“已确认的中枢”，而是“等出现无人值守和远程访问需求时再验证的基础设施候选”。
现阶段结论：Hermes 是主工作流里的大脑；OpenClaw 是未来可能验证的自动化基础设施。两者不是同一优先级。
分界线 3：Codex 与 WorkBuddy，先看文件角色
把它们概括为“Codex 写代码、WorkBuddy 办公”不够准确。
核心问题是：“这个文件到底是什么角色？”
同样是“处理 Excel”，两个例子：
找出 Excel 数据异常，写程序每天自动检查 → **Codex**
分析 Excel，帮我做一份经营汇报 PPT → **WorkBuddy**
— 三个问题划清容易混选的工具边界
四
PART
按任务瓶颈选择工具
BOTTLENECK FIRST
工具功能会逐渐重叠，但任务瓶颈不会自动消失。这是整篇决策表的底层逻辑。
选择工具时，与其看功能清单，不如先问：
先问自己
我现在最大的瓶颈究竟是执行规模、认知难度、多模态研读、交付物生产、重复教学，还是持续在线？
— 先识别任务卡点，再选择工具
五
PART
IT 项目管理与内容创作场景的工具分配
SCENARIO ROUTING
适用范围：本节基于杨杰在 IT 项目管理（数据治理、售前）和内容创作中的实际任务设计。
工作角色
角色与工具分配矩阵
IT 项目管理场景
内容创作场景
高频组合工作流
工作流 1：项目方案从 0 到交付
原始需求/参考材料
↓
Claude Code ← "分析需求、识别风险、定技术路线"
↓
Codex ← "根据方案框架，批量生成各章节内容与自动化工程文件"
↓
WorkBuddy (备用) ← "当视觉排版不理想时，进行格式化美化"
↓
Hermes ← "记住这个流程，下次同类项目一键调用"
工作流 2：一条视频 → 跨平台内容矩阵
视频文件
↓
Hermes Skill ← "转录→清洗→结构化笔记→Obsidian"
↓
Claude Code ← "从笔记提炼公众号长文核心观点"
↓
Claude Code ← "从长文拆解出短视频脚本 ×3"
↓
WorkBuddy (备用) ← "排版公众号文章 + 配图"
↓
OpenClaw (待验证) ← "定时分发到各平台"
工作流 3：每日 AI 助理
早上 8:00
OpenClaw Cron (待验证) ← "拉取飞书今日日程 + 待办任务，推送摘要到手机"
工作中
Hermes ← "所有飞书操作（查文档、批审批、搜消息）"
Codex / Claude ← "按任务类型路由（见上方矩阵）"
晚上 20:00
Hermes ← "处理今日新增的学习材料（视频/文章→Obsidian）"
工具投入优先级
Hermes 优先建设的 Skill
上表的时间收益（视频转录到笔记约 45 分钟、飞书日程待办摘要约 15 分钟、周报生成约 60 分钟）目前都是估算。下一步记录实际耗时、人工复核时间和失败次数，再决定哪些 Skill 值得长期维护。
— 项目管理与内容创作采用不同的工具接力
六
PART
Codex 与 WorkBuddy：分工与协同
CODEX × WORKBUDDY
如何区分 Codex 与 WorkBuddy
实际场景举例
七
PART
常见组合的分界与协同
PAIRWISE RULES
常见组合速查
八
PART
模型差异与使用边界
MODEL BOUNDARIES
模型不同不是频繁切换工具的理由。分工依据应该是任务瓶颈：Codex 负责工程执行，Hermes 负责流程沉淀，Antigravity 用于多模态材料研读，WorkBuddy 负责需要时的交付物美化。
九
PART
Antigravity：研究前哨，非精确结论工具
RESEARCH OUTPOST
已确认事实：编程不可用；政策金额提取出现过 10 倍数字失真 的错误；数字和金额不能直接用于拍板决策，应回到原始材料核验。
适用方向：作为外部多模态与素材抓取前哨——读超长扫描件 PDF、看大图、搜网页，归拢公开素材。
使用方式：先用 Antigravity 去网上摸全公开信息与图文素材，再把关键数字和条款交还给您或 Hermes/Codex 做交叉复核与落地。
十
PART
六个 Agent 的分工：先找任务瓶颈
FINAL MATRIX
选择 AI Agent 时，先识别任务卡点，再定主责与协作，并把未验证结论留在复核环节。
面对一项复杂工作，最容易掉进的坑是先比较“哪个 Agent 更强”。功能表看得越多，越容易在工具之间来回切换，结果上下文丢失、思路断裂。真正卡住任务的，不是工具够不够好，而是执行规模、判断难度、资料获取、交付呈现、重复教学或持续在线中的某一项。
本文的选择方法很简单：先找瓶颈，再指定主责，最后判断是否需要协作与复核。结合项目方案、数据治理、飞书协作和知识沉淀中的使用记录，这六个工具更适合站在任务链的不同位置，而不是相互替代。
先找瓶颈，再确定主责工具
一项工作可能同时经过几段。比如处理扫描版招标文件，先要读材料，再识别风险，然后生成核对表，最后做成汇报。此时可以让多个 Agent 接力，但每一段都要有明确主责。六个工具同时“想一想”，通常只会增加搬运、核对和上下文损耗。
优先比较容易混选的工具
两两比较有一个前提：同一句任务交给两个 Agent 都说得通，用户确实可能选错。按这个标准，不必把六个工具硬凑成十五组对比，只需抓住下面这些分界问题。
其他组合更适合看成上下游协作。Antigravity 负责资料前端，OpenClaw 解决运行方式，两者并不竞争；WorkBuddy 负责交付呈现，OpenClaw 负责持续在线，也没有必要直接比较。
复杂任务按环节接力
工具分工放进真实工作流后才会清楚。下面三类场景的共同原则是：先指定每一段的主责，再规定什么必须回到原始材料、实际数据或专业责任人复核。
投入顺序要跟着证据走
投入顺序不是能力排名，而是当前证据的结果。Codex 的实战验证最充分；Hermes、Antigravity 和 WorkBuddy 已有部分验证，其中 Antigravity 曾把政策金额提取错 10 倍；Claude Code 和 OpenClaw 仍需继续验证。合同、合规、重大技术决策和精确数字，都不能只依赖任一 Agent 的回答
— 先找瓶颈，再定主责、协作与复核
///
PART
写在最后：下次接到任务时
CONCLUSION
先问自己一个问题：当前最大的瓶颈是执行规模、判断难度、资料获取、交付呈现、重复教学，还是持续在线？
明确了瓶颈，再确定主责工具、协作方式和复核点。功能会逐渐趋同，但任务瓶颈不会自己消失。分工分清楚了，你就不用天天在工具之间来回切。
证据边界：本文沿用当前的实战记录。产品底层模型、版本和能力会变化，不能只凭名称选型；Antigravity、WorkBuddy、Claude Code、OpenClaw 涉及的待验证能力，应在进入关键业务前完成针对性测试。
我是 杨杰，8 年职场实践，分享技术转型、项目管理、数据治理与 AI 实战经验。
既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。
THANKS FOR READING