从 CLI 到 Agent：我当前在用的 AI 工具形态
过去一段时间里，我越来越明显地感觉到，AI 对我来说已经不再只是一个“问答工具”，而是开始进入实际工作流。
所以这篇文章想讲的，并不是单个工具本身有多强，而是：
这些工具是怎么在我的日常工作里接起来，逐步把一个想法变成结果的。
从这个角度看，AI 已经不只是一个独立的软件，而更像是一组可以彼此协同的工作入口。
一、为什么需要从“形态”来理解 AI 工具？
有的是写代码（Zed、Claude Code、Codex Cli、OpenCode）
有的是能“自动做事”的 Agent（Claude App、Codex App、Z Code）
还有一类工具直接嵌入在 Terminal 里（Warp）
也有专门处理本地数据和 OCR 的本地模型（Qwen3.5）
还有直接生成页面的工具（Google Stitch、）
也有 AI 语音输入工具（Flow keyboard）
因此，更合理的方式不是硬分“上下层”，而是先看它们分别属于什么形态：
同样是 AI 工具，不同产品往往代表的是不同的工作入口和使用方式
二、我当前在用的七种 AI 工具形态
1️⃣ IDE：面向代码工作流的图形界面（Zed）
如果从 coder 的实际使用出发，IDE + AI 的核心作用并不是某种独立的“更高层能力”，而是提供一种更自然的代码工作界面。
以 diff 的形式审阅改动，并决定 accept、reject 或继续修改
AI coding agent 的一种工作入口
它的优势主要在于图形化、编辑器内工作流，以及很多开发者已经习惯这种交互方式。尤其是在代码修改阶段，IDE 往往更强调“先审阅，再接受”的交互，这一点和很多 CLI 工具直接落盘修改的体验不太一样。
2️⃣ CLI：面向终端工作流的代码代理（Claude Code / Codex Cli / OpenCode）
对 coder 来说，CLI + AI 和 IDE + AI 在核心能力上其实高度重叠：
因此它和 IDE 的差别，更多不是“本质能力不同”，而是工作方式不同。
往往也更容易接入 skill、本地工具链和自动化流程
所以更准确地说，CLI 并不只是“执行层”，而是：
AI coding agent 的另一种工作入口，而且更贴近系统操作本身
如果说 IDE 偏向编辑器工作流，那么 CLI 偏向终端工作流；两者更多是使用偏好不同，而不是能力层级不同。
3️⃣ Agent App：CLI agent 的托管与远程化（Claude App / Codex App / Z Code）
如果说 CLI 解决的是“在本机终端里执行任务”，那么 Agent App 更像是在此基础上，提供一个可持续运行、可管理、可远程接入的承载环境。
为 remote control、dispatch 这类能力提供产品形态
从这个角度看，Claude App、Codex App 这一类产品，并不只是“聊天窗口升级版”，也不只是简单把 CLI 搬进 GUI。
把本地 agent 工作流，变成一个可以托管、连接和远程控制的系统入口
这也是它和纯 CLI 的关键区别之一。CLI 更像“本地直接操作”，而 Agent App 更像“带会话状态和远程能力的 agent 容器”。
4️⃣ Terminal 内置 AI：用自然语言处理环境和运维问题（Warp）
这一类工具更贴近日常 terminal 使用场景。它的重点不是写代码本身，而是让你直接用自然语言去完成原本要手动排查的环境、运维和命令行问题。
比如你在 terminal 里运行 Python、Node 或其他工具时出现版本错误，很多时候不需要自己一层层查资料，而是可以直接让这类工具去 debug，并尝试把问题修好。
给 terminal 加上一层可直接协作的 AI 运维助手
相比 IDE 或 CLI coding agent，这类工具更偏向系统环境本身，而不是代码文件本身。
5️⃣ 本地模型：本地数据处理与 OCR（Qwen3.5）
我现在对本地模型的使用，主要不是追求“最强推理”，而是把它当作一个稳定的数据处理工具。
因为像 Qwen3.5 这样的多模态模型本身支持图片输入，所以很多原本需要人工打开、检查、确认的文件，现在都可以直接交给模型先做一轮判断。
这一类本地模型最大的优势其实不是能力本身，而是数据安全：
适合身份证、证件、表单这类不适合直接上传到云端的内容
一个本地可控的 AI 数据处理和文档识别工具
6️⃣ 页面生成工具：直接把想法变成页面（Google Stitch / paper.design）
这一类工具更偏向界面和页面生成，而不是传统意义上的写代码。
用 Google Stitch 直接语音对话，快速生成网站页面
用通过 CLI + MCP 去控制 Paper app 创建页面
如果说 IDE、CLI 更偏向开发过程，那么这一类工具更像是：
把页面设计和界面生成进一步产品化了
7️⃣ AI 语音输入：先把话说出来，再交给模型整理（Flow keyboard）
Flow keyboard 对我来说，不只是一个普通的语音输入软件。
但 AI 语音输入不一样。它会在你说完一段话之后，先用一个小模型对内容做一次整理，例如：
这带来的好处是，你在和电脑沟通时，不需要强迫自己一开始就说得非常完整、非常顺。
你只需要先把想法尽可能说出来，再让 AI 帮你把这些内容压缩成更关键、更可执行的表达，然后再喂给后面的 AI 工具。
位于人与 AI 之间的一层“表达整理器”，先优化输入，再提高后续协作效率。
三、这些工具在我的工作流里是怎么使用的
如果只讨论工具形态，内容仍然会比较抽象。真正更有价值的，是把它们放进具体工作流里，看看它们分别在哪类任务上最有效。
1️⃣ 看到一个开源项目时，先让 Agent 帮我把它跑起来（Codex App）
比如我最近在 GitHub 上看到一个项目，说可以通过 WiFi 信号检测人体位置和心率。
在 Codex App 里创建这个项目，并连接到对应文件夹
让它把依赖、环境和运行报错一路 debug 到可以正常启动
这类场景里，Agent 最大的价值并不是“解释项目”，而是：
先把项目从源码状态推进到可运行状态，再决定是否继续研究。
2️⃣ 日常开发中，我越来越把编程变成“自然语言编程”（Codex / Cloud App）
在正常编程时，我现在主要会使用 Codex 或 Cloud App 这类 co-worker 工具。
对我来说，它们最重要的价值，已经不只是补全代码，而是把编程过程逐渐变成一种“自然语言编程”。
很多时候，我并不会自己从头去写实现，而是直接用自然语言描述：
在这种工作方式下，我更像是在负责需求表达、方向判断和结果审阅，而把相当一部分具体实现交给 AI 去完成。
3️⃣ 写文章、整理文档、转 PPT 时，我更倾向于用 Claude App（Claude App）
如果任务是写文章、整理文档，或者把内容进一步转成 PPT，我通常会优先使用 Claude 原生的 co-work app。
所以在纯文字工作这件事上，我会更偏向 Claude，而不是让 coding agent 去承担并不擅长的任务。
4️⃣ 涉及服务器修改时，我会直接使用 CLI 工具（Claude Code / Codex Cli / OpenCode）
CLI 工具我现在仍然会经常使用，尤其是在服务器环境里。
有时候我不会选择 Warp 那种方式，因为如果在 Warp 里用 AI 去 debug 服务器问题，使用次数是有限制的。
这时我通常会直接打开一个 CLI 工具，让它去完成我想在服务器端通过命令行修改的内容。
所以在服务器和命令行环境里，CLI 依然是非常高效的一种工作方式。
5️⃣ 面对已有项目时，我会先初始化，再让 CLI 参与 UI 重设计（CLI / MCP / Page Papers）
CLI 还有一个很重要的使用场景，就是进入一个已经存在的项目。
虽然这个项目对我来说已经很熟，但对 AI 来说，它依然是一个新项目。
在这一步完成之后，我才会继续让它基于现有项目做更多事情，例如：
在这个过程中，还可以通过 MCP 去调用 Page Papers，在那边完成部分 UI 设计，再把设计结果拿回项目里复用。
所以对我来说，这已经不是单独使用某一个工具，而是：
CLI、MCP 和页面设计工具在同一个项目里协同工作。
6️⃣ 遇到线上问题或反馈时，我会在 Zed 里做问题归因和 bug 排查（Zed）
还有一种我经常使用的方式，是把 Zed 直接打开到某个项目里，用它来协助排查具体问题。
比如别人告诉我，这套系统里某个地方可能存在 bug，我通常会把对方描述的问题原封不动地复制给 Zed 里的 agent，让它先去判断：
因为是在 Zed 里完成这一步，代码和项目结构都可以直接看到，所以排查过程会更直接，也更容易定位问题来源。
一般情况下，我会先让 AI 帮我解释这个问题可能是怎么产生的。即使它给出的不是最终结论，也通常能提供一个大致方向，告诉我接下来应该优先往哪里看。
一个结合代码上下文来做问题归因和调试分析的工作界面。
7️⃣ 写文章时，我会先口述，再让 AI 补全并直接回写到 Notion（Flow keyboard / Codex App / MCP / Notion）
我会先用 Flow keyboard 把自己想表达的内容口述出来，不要求一开始就组织得非常完整，只要先把核心想法说出来即可。
接下来，我会把这些内容交给 Codex App，让它基于我的原始表达去做补全、整理和结构化。
在这一步完成之后，它还可以通过 MCP 直接修改 Notion，让 Notion 成为这篇文章最终的落点。
也就是说，这篇文章并不是一次性写出来的，而是会经过几层 AI 的协作：
这种方式的好处在于，文章不是静态生成一次就结束了，而是可以继续联动调整。
比如我后来觉得少了一个工具，让它去改第一部分时，它往往也可以连带把第二部分、第三部分一起统一调整。
把一个粗略想法，通过多层 AI 协作，逐步变成一篇可以持续演化的文章。
四、结语
写到这里，我越来越确定一件事：对我来说，AI 工具真正有价值的地方，不是把它们当成一个个单独的软件去看，而是把它们放进连续的工作流程里。
先用 Flow keyboard 把想法快速说出来
再用 Codex、Claude 或其他 agent 把内容补全、改写、执行
需要时接入 CLI、MCP、Notion、页面设计工具或本地模型
最后把结果真正落到代码、文档、页面或者数据处理结果上
在这个过程中，不同工具分别承担不同角色，但它们的价值并不在于各自独立存在，而在于能不能互相衔接。
所以对我来说，AI 带来的最大变化不是“多了几个新工具”，而是：
我开始可以把表达、编程、调试、写作和交付，放进同一条由 AI 参与的工作链路里。
夜雨聆风
