别让大模型替你做小事：从"Token 焦虑"到用 AI 沉淀自己的工具库

行业洞察 · 深度使用 AI 之后的思考

深度用了一段时间 AI 之后，我开始觉得有些地方不对劲。

不是 AI 不好用，而是我用它的方式有问题。

我把越来越多的事情直接扔给大模型：整理一段文字、转换一个格式、处理一个重复的任务……每次打开对话框，输入需求，等待输出，复制结果。看起来很高效，但有一天我突然意识到：这些事情，我已经做了不知道多少遍了。每一遍都要重新跟 AI 解释一遍需求，每一遍都要消耗一批 Token，每一遍都在从头开始。

这不叫高效，这叫低水平重复。

Token 焦虑，是真实存在的

先说一个很多人不愿意承认的事：用 AI 是有成本的，而且这个成本正在上涨。

不是单价在涨——实际上大模型的每个 Token 单价这两年一直在降。但有一件更糟糕的事情发生了：我们消耗的 Token 数量在爆炸式增长。

当 AI 从一个聊天工具变成一个智能体，每次调用从单次问答变成多步推理、工具调用、上下文维护，Token 的消耗量可能是以前的十倍甚至百倍。订阅制的"无限使用"套餐开始出现限制，API 调用的账单开始变得不那么好看。

与此同时，市场上的 AI 产品越来越多——每个垂直场景都有自己的 Agent 产品，每个都要开通会员，每个都在消耗你的时间和钱包。面对这种局面，很多人陷入了一种无力感：到底要订哪几个？哪些值得长期用？哪些用完一次就没必要再碰？

这种焦虑，我觉得根源不在于 AI 太贵，而在于我们还没想清楚：大模型应该用来做什么，不应该用来做什么。

一个关键的认知转变

我自己经历了一个认知上的转变，大概是这样的：

之前的用法： 遇到一个任务 → 打开 AI → 描述需求 → 得到结果 → 关闭对话。下次遇到同样的任务，重复一遍。

现在的用法： 遇到一个频繁出现的任务 → 打开 AI → 让它帮我把这件事做成一个脚本或者 Skill → 以后直接运行脚本，或者让 AI 调用 Skill，不再从头描述需求。

区别是什么？

前者在消耗 AI，后者在用 AI 沉淀资产。

顶级大模型真正值得用的地方，不是帮你把一件事做完，而是帮你把一类事情自动化。一旦自动化落地了，这件事就不再需要大模型介入了——或者只需要轻量模型以极低的成本维持运转。

什么情况适合沉淀成 Python 脚本

脚本适合的场景有一个共同特征：输入输出格式固定，规则明确，不需要"理解"，只需要"执行"。

举几个具体的例子：

文件批量处理类：每周需要把一堆 Excel 表格里的数据按照固定格式汇总成一张表；每次收到供应商发来的报价单需要提取特定字段；每天需要把日志文件里的错误记录整理出来。这类任务，规则是固定的，数据格式是固定的，完全没有必要每次都让大模型去"理解"然后输出——写一个 Python 脚本，一行命令搞定，速度更快，成本几乎为零。

格式转换类：把 Markdown 转成特定格式的 HTML；把一堆截图里的文字批量提取出来；把录音文件批量转成文字。这些任务有成熟的 Python 库可以处理，大模型在这里纯属大材小用。

定时自动化类：每天早上自动抓取某个网站的数据存入表格；每周自动生成一份固定格式的周报草稿；定时清理某个目录下的临时文件。这类任务的特点是触发条件明确、执行逻辑固定，用脚本 + 定时任务就能解决，根本不需要 AI 参与。

判断标准只有一个： 如果你能用一段固定的规则把这个任务描述清楚，那它就应该是一个脚本，而不是一个 AI 对话。

什么情况适合沉淀成 Skill

Skill 适合的场景和脚本不同——它针对的是那些需要 AI 的语言理解能力，但又有固定的操作流程和输出规范的任务。

简单说：脚本是"不需要 AI 的事情自动化"，Skill 是"需要 AI 但不需要每次从头解释的事情标准化"。

具体来说，适合沉淀成 Skill 的场景包括：

有固定风格和规范的内容创作：比如你的博客文章有固定的结构要求、语气要求、禁忌词要求。与其每次都在对话里重新描述这些规范，不如把它们沉淀成一个 Skill——AI 调用这个 Skill 的时候，自动就知道该怎么写。

有标准流程的分析任务：比如你每次做竞品分析都遵循同一套框架；每次做需求评审都按照同样的维度检查；每次 Code Review 都关注同样的几个质量点。这类任务有固定的"思考路径"，把这个路径文档化，就是一个 Skill。

需要专业知识但又频繁调用的场景：比如你在某个垂直领域有大量的专业知识积累——产品规范、行业术语、业务流程。把这些知识整理成结构化的 Skill 文档，AI 在处理相关任务时就可以直接调用，不需要每次都通过对话把上下文喂给它。

Skill 的核心价值在于：把你的经验和规范变成 AI 可以随时调用的"记忆"，而不是每次都依赖对话窗口里的上下文。

用 AI 生成这两样东西，本身就是最好的用法

说到这里可能有人会想：我又不会写 Python，怎么做脚本？

这恰恰是重点：用大模型帮你生成脚本和 Skill，然后脱离大模型独立运行——这才是顶级大模型最划算的用法。

你描述一个需求，让 AI 帮你写一个处理脚本，调试好，以后直接运行，不再需要 AI。这一次的 Token 消耗，换来的是这类任务永久的自动化。

你把自己的博客写作规范、产品分析框架、内容标准整理成文档，让 AI 帮你把它结构化成一个 Skill 文件。以后每次写作或分析，AI 直接调用这个 Skill，不需要你在对话里重新解释一遍。

一次投入，长期复用。这才是 Token 花得值的地方。

我的一个简单判断框架

每次遇到一个想交给 AI 的任务，我现在会先问自己三个问题：

这件事我会反复遇到吗？ 如果只做一次，直接用 AI 对话就好；如果会反复遇到，就值得自动化。

这件事需要 AI 的理解能力，还是只需要执行？ 需要理解——考虑做成 Skill；只需要执行——考虑做成脚本。

这件事的输入输出规则是固定的吗？ 完全固定——脚本；有规则但需要灵活判断——Skill；完全开放——直接对话。

这个框架不复杂，但它帮我把大量原本在重复消耗 Token 的任务，变成了一次性的自动化投入。

最后说一句

我们现在处于一个有点奇怪的阶段：AI 工具多到用不完，Token 成本不低也不高，每个人都在摸索怎么用才最合适。

我自己摸索出来的结论是：大模型的价值不在于帮你把一件事做完，而在于帮你想清楚这件事该怎么做，然后把"怎么做"固化下来——变成脚本，变成 Skill，变成不再需要大模型介入的自动化流程。

用 AI 用到最后，应该是越来越少地依赖 AI，而不是越来越多。