小白面对一堆 AI 工具,不知从哪开始学——不是努力不够,是地图缺失

上周有个粉丝问我：

“我是纯小白，只用过豆包、DeepSeek 这种对话类的工具。AI 工具太多了，都搞晕了，该怎么学？”

我想了一下，问题的难点不在于工具多。

难在他手里没有一张地图。

工具太多不是问题。不知道自己在哪、该往哪走，才是真正的卡点。

所以我画了下面这张图。

一、先把地图建起来

AI 工具大致分五类。不用一开始就全学，先知道大类在哪，知道自己现在用的是哪一类，就够了。

那个粉丝只接触过对话助手，这很正常，大多数人的起点都在这里。

但只停在对话助手，你对 AI 能做什么的判断，会有一个很大的盲区。

盲区就在第二行：Agent CLI。

这里先停一下，我要展开讲一件事——CLI 到底是什么，为什么它是这张地图里最值得理解的一块。

二、CLI 不是黑窗口，是通用执行层

很多人第一次看到 CLI（命令行界面），本能反应是：这不就是个黑窗口吗？

如果只把它理解成黑窗口，后面很多事都理解不通。

先对比一下 GUI 和 CLI 的本质区别。

GUI（图形界面）是什么

你每天用的软件大多是 GUI——微信、浏览器、飞书，通过按钮、菜单、窗口来操作。

GUI 的优点很明显：直观，门槛低，不容易出错。

但它有一个根本性的限制：你能做什么，基本被界面提前规定好了。

GUI 更像一间装修好的店。进去之后很容易上手，但店里卖什么、不卖什么，早就定死了。

CLI（命令行界面）是什么

CLI 不是点按钮，而是直接给系统下命令。

门槛高，但表达力远强于 GUI。因为它直接连接的是操作系统和真实工具：

CLI 更像一个总控制台。不好上手，但一旦会用，几乎什么都能接。

这里顺带说三个容易混淆的词：

CLI   → 命令行交互这种形态（最大一层）
Shell → 专门和操作系统交互的 CLI 程序（CLI 的子集）
Bash  → 一种 Shell（macOS 上更常见的是 zsh）

Bash 是一种 Shell，Shell 是 CLI 的一个子集。很多人把这三个词当同义词，并不准确。

CLI 的致命短板

但单独的 CLI 有一个非常明显的问题。

它几乎什么都能执行，但它自己不会想。

听不懂自然语言，不会理解你的真实目标，不会主动拆任务，你不给命令，什么都不会发生。

这就是为什么传统 CLI 很强，但一直没有直接变成通用 Agent。

CLI 有执行力，但没有理解力。

LLM 和 CLI 各自的短板，刚好互补

对话助手（大语言模型，LLM）很会理解，也很会生成——但如果没有工具，它本质上还是”会说话的大脑”。

它不能真正去读你电脑里的文件，不能执行系统命令，不能把工作流真正跑完。

所以：

单独的 LLM  → 有理解力，没有行动力
单独的 CLI  → 有行动力，没有理解力

当你把 LLM 接到 CLI 上，事情就变了。

它第一次同时具备了两种能力：

这就是通用 Agent 的雏形。不是因为它变得神秘，而是因为：

它第一次同时拥有了一个大脑和一双手。

Claude Code、Codex 不是”聊天机器人进了终端”，而是把通用推理能力接到了通用执行接口上。

这就是它们和普通对话助手有本质区别的地方。

三、Skill 才是 Agent 的灵魂

地图建起来了，Agent CLI 的原理也清楚了。

但我还想说一件更容易被忽略的事：用好 Agent 的上限，不在 Prompt，在 Skill。

很多人开始用 Agent CLI，第一个本能是写更好的 Prompt。这没错，Prompt 很重要，输入决定输出。

但只停在 Prompt，你得到的还是一次性成果。

举个例子。你今天为了分析一份广告报表，写了一段很精准的 Prompt。明天来一份新报表，你可能还要重新解释：背景是什么、目标是什么、要什么格式、有什么约束。

时间长了，你会发现很多工作在重复描述同一件事。

这就是 Prompt 的上限：每次解决这一次。

Skill 是什么

Skill 解决的是另一个问题：这类事以后都怎么做。

它不是一个神秘功能，说白了就是一个文件夹。这个文件夹里最重要的一定是 SKILL.md，其他文件（脚本、参考资料、模板）都是按需补充的。

my-skill/
  ├── SKILL.md         ← 必有，最重要
  ├── scripts/         ← 可选，可执行脚本
  ├── references/      ← 可选，参考资料
  └── assets/          ← 可选，模板和资源

SKILL.md 里要有两层内容：顶部的元数据（frontmatter）和后面的说明正文。

最小结构长这样：

---
name: my-skill
description: 当用户需要处理 PDF、提取表格、填写表单时使用这个 Skill
---

# My Skill

这里写这项能力是干什么的、什么时候该用、具体怎么做。

name 和 description，哪个更重要

name 是这个 Skill 的短名字，拿来当标识，更像函数名，不像文章标题。

但真正关键的是 description。

Agent 启动时，不会一口气把所有 Skill 的完整内容都读进来，那太费资源。它会先只加载每个 Skill 的 name 和 description，靠这两段内容判断”这个 Skill 什么时候可能有用”。只有任务匹配了，才会把完整的 SKILL.md 读进上下文来执行。

这意味着什么？

description 承担了触发责任。

如果 description 写得太空，比如只写”Helps with PDFs”，Agent 在面对一个 PDF 处理任务时，很可能根本不知道该调用它。

如果 description 写得清楚，比如”当用户需要处理 PDF、提取表格、填写表单、合并文件时使用这个 Skill”，触发概率就会高很多。

所以：

为什么 Skill 比 Prompt 更接近资产

你把反复要做的事封装成 Skill 之后：

对比 Prompt：Prompt 更像你这次下单时说的话，用完即止。Skill 更像你把”这类事怎么做”写成了标准操作，越用越顺手。

Prompt → 临时发挥，解决这一次
Skill  → 长期资产，解决这一类

会调用工具，只说明 Agent 有手。

会沉淀 Skill，才说明它开始形成工作系统。

这也是为什么我后来把学习路径的重心，放在了能不能逐步建立自己的 Skill 库，而不是能不能用更多工具。

四、最短上手路径

回到那个粉丝的问题——该怎么学？

顺序比广度重要。

第一步：先用最强模型

优先把 ChatGPT 用起来。目前第一梯队主要是 GPT（OpenAI）和 Claude（Anthropic），如果只能选一条主线，优先走 ChatGPT + Codex，原因是稳定、不容易封号。工具差一档，认知会差很多。

第二步：把对话助手用顺

先学会把任务说清楚。能稳定让 AI 做分析、总结、改写、拆方案，这一步很值，别急着碰自动化。

第三步：理解 CLI 是什么

不必马上熟练，但要知道通用 Agent 的能力为什么长在 CLI 这条线上。这是后面理解 Agent CLI 的前提。

第四步：接触 Agent CLI

等你对模型和任务表达有感觉了，再上 Agent CLI。推荐优先试 Codex——第一梯队模型 + Agent 形态，最适合后面建 Skill 路线。

第五步：把重复任务沉淀成 Skill

这是最容易被跳过、长期价值最大的一步。今天做成一件事不算掌握，能把它固定成可反复调用的方法，才开始复利。

第六步：用 Markdown 沉淀资产

Skill、方法、记录，尽量用 Markdown 落下来。它不被任何平台锁死，能备份、能迁移、能让不同 Agent 反复调用。

Skill 的火也把 Obsidian 带火了，因为 Obsidian 原本就是管理本地的 markdown 文件，和 Agent Skill 天然适配，而它的双链接功能，也非常适合大模型把知识关联起来，形成知识网络。

回到那个粉丝的问题。

他现在在第一步，这没问题。

豆包、DeepSeek 是很好的起点，对话助手本来就是这张地图的基础层。

卡住的人，大多不是起点不对，而是不知道这张地图长什么样，也不知道下一步该往哪走。

现在你有地图了。

顺序走下去，不用全都会，一步一步来。

后记

这篇文章是在和 Claude（AI 助手）协作下完成的。素材来自我整理的 AI 工具入门文档，我提供了方向和真实案例，AI 完成了结构和文字。

这类协作是我探索的一个工作方式——过程产出内容，内容验证方法。

「100天 Build in Public」Day 19

我是画伞，独立创业者，在探索 AI 工具链和产品变现的路上。

公众号记录真实的过程，不优化人设，不表演努力。