想快速用Skills打造工作流？分享我的7个方法
317
｜AI实战大佬手把手教你用Agent重构跨境运营全链路，点击报名
最近有朋友看我折腾 Claude Code 的 Skills 折腾得挺嗨，问我：
"你这一套工作流，到底怎么想出来的？有没有什么章法？"
说实话，我也是踩了许多坑之后，总结的方法论。
做过 RPA，搭过扣子，玩过 n8n，绕了一大圈，才在 Skills 这条路上稍微摸出了一点门道。
今天把我这段时间总结的 7 条铁律写出来。
00 动手之前先问三个问题
其实在这 7 条之前，我还想加一条更前置的——
任何一个工作流，在我决定用 Skills 搭之前，我都会先问自己三个问题。
第一问：这事儿有没有现成的服务？
这是最容易被跳过的一步。
我们做 Skills 久了，会有一种"我什么都能自己搭"的幻觉。
但很多时候，事情根本不需要自己搭。
下面我会举一个亚马逊抓取差评的例子——在准备自己写 skills 之前，应该先想的是：市面上有没有现成的 SaaS 已经在干这件事？
如果有，掏钱买一个账号，几十几百块一个月，省下来的是调试链路的时间。
能花钱解决的问题，就不要花时间解决。
这是第一优先级。
第二问：有没有别人写过类似的 Skill 可以拿来用？
如果没有现成的服务，再问第二个问题：
这个需求别人写过吗？有没有开源的 Skill 或者工作流可以拿过来用？
哪怕它只能解决我 50% 的场景，甚至只有 30%，也值得拿过来改。
因为它至少替我踩过一些坑。
我自己经常从零写 Skill，结果半路发现 GitHub 上早就有一个七八十分的版本了，然后浪费好几天时间，还没别人做得好。
第三问：如果都没有，先找方法论，再写 Skill
很多时候我们的顺序是：先动手写 Skill，边写边想标准。
结果就是 Skill 写了一半，发现自己根本不知道"好"的标准是什么——AI 产出什么都说不上对不对，只能靠感觉。
下面我也会举一个电商主图的例子。
如果我要做一个"生成电商主图"的 Skill，我的第一步不是打开 Claude Code 写 Skill。
我的第一步是 让 AI 去搜：
亚马逊 Best Seller 的主图长什么样？ 淘宝爆款的主图有什么共同点？ 构图、留白、文字、光影这些维度，行业里公认的好标准是什么？
……
先把方法论摸出来，再把方法论总结为 Skill。
这一步看起来慢，其实是最省时间的。
因为我们一旦知道了"好的主图长什么样"，Skill 该怎么写、该给 AI 什么约束、该怎么做质检，全都是水到渠成的事。
反过来，没有方法论就直接写 Skill，等于让 AI 替你定义"好"——而 AI 恰恰最不擅长这件事。
这三问适用于任何工作流，也适用于工作流里的任何一个重要节点
不只是整条 Skills 工作流要这么问。
工作流里的每一个关键节点，其实都可以再问一遍这三个问题。
要做配图 → 有没有现成的图库？ 没有 → 有没有别人写的 AI 配图 Skill？ 没有 → 好的配图标准是什么？ 要做排版 → 有没有现成的排版工具？ 没有 → 有没有别人的排版 Skill？ 没有 → 好的手机阅读排版长什么样？
每一个节点，都先走一遍"现成服务 → 现成 Skill → 方法论先行"这三问。
01 先拆解，拆到你能一步一步教人做
我发现大多数人搞不定工作流的第一个原因，不是工具不会用，是任务根本没拆开。
举个最近朋友的一个需求——追踪亚马逊某个关键词下的前 20 个链接 listing 的差评。
那么，很多人上来就可能是这么对 AI 说：
"帮我把 'yoga mat' 这个关键词下面所有差评收集下来，整理到表格里。"
然后就开始等结果。
然后结果一般是：
要么发现 ai 折腾了半天，只打开了亚马逊的前台，要么等半天等到一堆虚构的数据。
为什么会这样？
有很多原因，我们后面再说。
但是我想先说的是，首先这个流程就有问题，因为不够详细。
我的做法是先把这个事情先拆成一条清晰的动作链：
打开亚马逊前台网页链接 输入关键词 "yoga mat" 获取前两页所有 listing 链接 把链接记录到表格里 依次进入每一个 listing 抓取这条 listing 下面的差评 把差评写回对应的行
拆到这种程度，才是基本合格的。
拆解这件事，本质上第一不是为了给 AI 看，为了逼我们自己把"我到底要什么"想清楚。
拆解得越细，我们自己越知道自己要的是什么，这是第一点。
第二点是，AI 的产出也会更稳定。
我们可以把 AI 想象成是一个非常聪明的实习生。
如果你的指令很模糊，那它可能在一条错误的路上狂奔。
但如果你的指令越清晰，那么它就越能拿到让你满意的结果。
举个具体的的例子。
公司来了个清华的实习生，你跟他说好：给这个保温杯做一张漂亮的电商主图。
这句话本身就有问题。
因为，请问漂亮怎么定义？
如果漂亮都不能定义，都有巨大的歧义，那请问它做出来的图你作为 leader 会满意吗？
所以 AI 是一个放大器——你是清晰的，它放大清晰；
你是混乱的，它放大混乱。
拆解不是给 AI 看，是给自己看。
02 颗粒度是门艺术，不是越细越好
问题来了：拆是拆了，那每一步都是一个 Skill 吗？
这里是第二个坑，也是最容易走极端的地方。
有的人一个 Skill 把整个流程全包了——从打开亚马逊到写回表格，一个 SKILL.md 文件里塞 3000 行。
有的人又走到另一个极端——每一步都做成一个 Skill，一个简单的抓取任务被拆成 15 个 Skills。
两种都不对。
我的经验是：扣子或 n8n 里能作为一个完整节点的事情，差不多就是一个合理的 Skill。
一次登录亚马逊、拿一页 listing 链接——一个 Skill。
进一个 listing、把评价扒下来——一个 Skill。
把数据回写表格——一个 Skill。
为什么一定要有颗粒度的意识？
因为太粗和太细，都可能导致不同的死法：
太粗：Skill 里塞太多事情，描述写不准。
AI 根本判断不了什么时候该触发这个 Skill。就像你跟员工说"你负责所有事"，他大概率什么都做不好。
太细：Skill 一多，AI 光是读 Skill 列表就已经累了。
调度的成本比干活的成本还高，而且维护起来也很累。
一个 Skill 只干一件事，而且能被一句话说清楚——这才是合格的颗粒度。
一个节点 = 一个 Skill。
这是我目前跑下来最舒服的尺度。
03 最重要的一点：永远有"上下文脑容量"意识
这一条，我要单独拎出来讲。
因为它是真正决定你工作流能不能跑起来的天花板。
AI 的上下文窗口是有限的。
我们可以把它想成一个人的脑容量。
一个人再聪明，一次只能装下那么多事。
你在他脑子里塞的琐碎信息越多，他真正用来思考的空间就越少。
Skills 也是一样。
一个 Skills 工作流，如果环节太多、每个 Skill 都塞得满满的，AI 跑一次就要加载一堆说明。加载完之后，它用来"干活"的那点空间，可能就剩一小半了。
我以前写过一篇《提示词越长，AI 就越笨》，本质和这个很像。
"提示词越长越精确"——这是大多数人对 AI 最大的误解。
事实是：
前 200 字的权重，比后面所有内容加起来都高。
研究里提到过，提示词超过 500 字之后，AI 对关键指令的识别准确率会下降 30% 以上。
Skills 工作流也一样。
如果我们串 15 个 Skill 跑一次，AI 读完第一个 Skill 的时候，后面 14 个的细节它已经开始"忘"了。
等到最后一步执行的时候，它其实是在"大概记得"的状态下硬跑。
结果就是：偷懒、跳步骤、胡编数据。
所以我有一个很粗暴的经验：一次执行，4 到 5 个 Skill 是比较合理的上限。
再多，基本就得考虑用子代理（sub-agent）去分段处理。
现在的 Claude Code、Codex 都支持 Agent 协作。
我们可以让一个"父 Skill"调度若干个"子 Skill"，每个子 Skill 单独开一个窗口、带一份自己的干净脑容量去干活，干完之后只把结论丢回父 Skill。
这样主窗口的脑容量就不会被中间过程污染。
但哪怕有了子代理，你也不能松懈。
我们永远要带着这样一个问题在脑子里：
"这一步，AI 的脑子里还剩多少空间？"
同一个对话窗口，聊得越久，脑容量就被占得越满。
背景越堆越厚，AI 能真正思考的余地就越小。
到最后，它一定会偷懒。
因为 AI 永远是目标导向的——它要完成你交代的任务。脑容量不够了，它就会砍步骤、跳环节、甚至自己编造数据，只为了让那个"完成"被勾上。
脑容量够，它守规矩；脑容量不够，它就可能疯狂偷懒。
上下文被挤满，思考就没地方了。
04 想自动化，就必须加一道质检
上一条讲到 AI 会偷懒，所以就有了第四条：
任何一个你真正想自动化的工作流，都必须有专门的质检步骤。
Skills 工作流和 n8n、扣子不一样。
n8n 写错一个变量，整个流程直接报错停住——它至少会告诉我们，我坏了。
Skills 不会。
Skills 太聪明了，它会"自己想办法"。
想不出来的时候，它就会伪装成"想出来了"。
很多时候情况是这样的：
让它抓 20 条评价，它抓了 5 条真的，剩下 15 条是它自己"补"出来的； 让它写一篇文章，它中间有一段查不到资料，就自己脑补了一个"听起来很合理"的数据； 让它生成 9 张图，它发现其中一张 prompt 生成失败，就干脆复制了另一张充数。
所以一个完整的 Skills 工作流，一定要有一个独立的质检 Skill，专门负责校验上一步的输出是否合格。
内容类工作流要有文字质检；
配图类工作流要有图片质检；
数据类工作流要有数据回填校验。
我自己做公众号的那套工作流，从排版优化到新闻图取证、AI 配图、封面制作，中间专门插了一个"配图质检 Skill"——
它只干一件事：检查每张图和对应段落是否匹配、顺序是否正确、密度是否合理。
05 内容写作不可能 100% 自动化，最核心的是"活人感"
如果你想把内容自动化，那么不要追求 100% 自动化。
因为内容写作最核心的一件事是"活人感"——你得让读者感觉文字背后有一个真实的人。
但 AI 恰恰最没有"活人感"。
它非常擅长写出结构完整、逻辑自洽、语法正确的文字。
但它写不出：
今天早上被楼下猫吓到、
想起你爸当年一句话、
在回家路上突然改了主意的那种东西
……
那才是让一篇文章活起来的东西。
所以内容创作的正确目标不是"全自动"，而是"尽可能减少人工"。
这是两件完全不同的事。
全自动 = 我不参与，AI 全做。
减少人工 = 繁琐的、可标准化的部分交给 AI，真正需要人判断的环节我来做。
举例子，我一般交给 Skills 的事情包括：
文章排版优化 标题的备选 图片生成和质检 封面制作 发布流程 多平台分发
必须我自己来的事情包括：
观点本身 选题的判断 行文的节奏 那一两句让人转发的金句
06 调试工作流，先从最难的环节开始
很多时候我们搭工作流是这样的：
第一步 → 调通 → 开心
第二步 → 调通 → 开心
第三步 → 调通 → 开心
……
第 N 步 → 发现根本做不到 → 前面全白搭
非常可惜，所以现在我的顺序是：先从最难的环节开始。
回到亚马逊那个例子。
抓 listing 下面的评价——这是整条链路最难的一步。
因为评价需要加载、还要分页、还涉及到网页的反爬机制。
所以重点先测试一件事：
给 AI 一条现成的 listing 的网址，试下能不能把评价抓下来。
能——往上走一步：给关键词，能不能拿第一页的 listing 链接？
能——再往上走：能不能翻第二页？
最后才是把这些环节串起来。
07 电脑自动化只能打 30 分，浏览器自动化 50 分
最后一条，是我对现阶段 AI 跨平台能力边界的一个粗暴的判断。
最近一年，有太多自媒体文章宣传说：AI 已经能替我们操作电脑、操作浏览器了……
是能，但离具体做事情，还有不少的距离。
电脑自动化（直接操作你的桌面、点按钮、拖文件）——我觉得目前只有 30 分水平。
浏览器自动化（在浏览器上面操作，点击网页按钮、输入内容等）——我觉得只有 50 分。
为什么？
因为操作网页或者操作软件，每一个简单的步骤，背后都有非常复杂的与目标行为无关的代码。
而且当代码无法判断的时候，AI 也严重依赖截图确认。
而一张截图，占的上下文空间，相当于几千到几万个字。
那么就又回到了第三条：脑容量。
我们让 AI 自动操作电脑，它每一步都要读取大量无关的内容来判断现在的状态——
点一个按钮，大脑容量少了十分之一；
等页面加载好了，看一眼，大脑容量又少了十分之一；
确认一个字段填对了，再确认下，大脑又少了十分之一的容量
……
最后不过是填了几个数字，大脑已经要满了。
所以我现在的原则是：
能用 API 解决的，绝对不用浏览器自动化（还是亚马逊那个例子，其实最优先考虑的解决方案是看有没有现成的软件可以直接提供数据，那么我们只要用 AI 进行分析即可）； 能用浏览器自动化解决的，绝对不让它去操作电脑桌面； 能让它读文本的，绝对不让它截图。
文本驱动，永远优先于视觉驱动。
电脑自动化和浏览器自动化不是不能用，是要用在"刀刃"上——
当 90% 的步骤已经用文本搞定了，只剩 10% 必须点一下鼠标的时候，再让它去"动手"。
不能一上来就让 AI 满屏点来点去。
每截一次图，脑容量就少一截。
最后一句
写完这 7 条，再加上开头那三问，我自己也发现，它们其实都指向同一个东西——
对 AI 上下文的敬畏，以及对自己时间的敬畏。
Skills 工作流看起来是在设计流程、写文件、串步骤，但它本质上一直在回答一个问题：
这一步，我该怎么做，才不会把 AI 的脑子撑爆、也不会把我自己的时间浪费掉？
动手之前先问三问，是为了不在已经有答案的地方重复造轮子。
拆解，是为了让每一步信息密度可控。
颗粒度，是为了让调度成本可控。
上下文意识，是直接对准脑容量本身。
质检，是为了补偿脑容量不够时的偷懒。
活人感，是承认有些事永远留在人脑子里。
先调最难的，是为了让"脑容量预算"花在刀刃上。
30 分和 50 分，是在提醒我们：AI 也不是万能的，要理解它的上限。
部分配图由 AI 生成。
最近有朋友看我折腾 Claude Code 的 Skills 折腾得挺嗨，问我：
"你这一套工作流，到底怎么想出来的？有没有什么章法？"
说实话，我也是踩了许多坑之后，总结的方法论。
做过 RPA，搭过扣子，玩过 n8n，绕了一大圈，才在 Skills 这条路上稍微摸出了一点门道。
今天把我这段时间总结的 7 条铁律写出来。
00 动手之前先问三个问题
其实在这 7 条之前，我还想加一条更前置的——
任何一个工作流，在我决定用 Skills 搭之前，我都会先问自己三个问题。
第一问：这事儿有没有现成的服务？
这是最容易被跳过的一步。
我们做 Skills 久了，会有一种"我什么都能自己搭"的幻觉。
但很多时候，事情根本不需要自己搭。
下面我会举一个亚马逊抓取差评的例子——在准备自己写 skills 之前，应该先想的是：市面上有没有现成的 SaaS 已经在干这件事？
如果有，掏钱买一个账号，几十几百块一个月，省下来的是调试链路的时间。
能花钱解决的问题，就不要花时间解决。
这是第一优先级。
第二问：有没有别人写过类似的 Skill 可以拿来用？
如果没有现成的服务，再问第二个问题：
这个需求别人写过吗？有没有开源的 Skill 或者工作流可以拿过来用？
哪怕它只能解决我 50% 的场景，甚至只有 30%，也值得拿过来改。
因为它至少替我踩过一些坑。
我自己经常从零写 Skill，结果半路发现 GitHub 上早就有一个七八十分的版本了，然后浪费好几天时间，还没别人做得好。
第三问：如果都没有，先找方法论，再写 Skill
很多时候我们的顺序是：先动手写 Skill，边写边想标准。
结果就是 Skill 写了一半，发现自己根本不知道"好"的标准是什么——AI 产出什么都说不上对不对，只能靠感觉。
下面我也会举一个电商主图的例子。
如果我要做一个"生成电商主图"的 Skill，我的第一步不是打开 Claude Code 写 Skill。
我的第一步是 让 AI 去搜：
亚马逊 Best Seller 的主图长什么样？ 淘宝爆款的主图有什么共同点？ 构图、留白、文字、光影这些维度，行业里公认的好标准是什么？
……
先把方法论摸出来，再把方法论总结为 Skill。
这一步看起来慢，其实是最省时间的。
因为我们一旦知道了"好的主图长什么样"，Skill 该怎么写、该给 AI 什么约束、该怎么做质检，全都是水到渠成的事。
反过来，没有方法论就直接写 Skill，等于让 AI 替你定义"好"——而 AI 恰恰最不擅长这件事。
这三问适用于任何工作流，也适用于工作流里的任何一个重要节点
不只是整条 Skills 工作流要这么问。
工作流里的每一个关键节点，其实都可以再问一遍这三个问题。
要做配图 → 有没有现成的图库？ 没有 → 有没有别人写的 AI 配图 Skill？ 没有 → 好的配图标准是什么？ 要做排版 → 有没有现成的排版工具？ 没有 → 有没有别人的排版 Skill？ 没有 → 好的手机阅读排版长什么样？
每一个节点，都先走一遍"现成服务 → 现成 Skill → 方法论先行"这三问。
01 先拆解，拆到你能一步一步教人做
我发现大多数人搞不定工作流的第一个原因，不是工具不会用，是任务根本没拆开。
举个最近朋友的一个需求——追踪亚马逊某个关键词下的前 20 个链接 listing 的差评。
那么，很多人上来就可能是这么对 AI 说：
"帮我把 'yoga mat' 这个关键词下面所有差评收集下来，整理到表格里。"
然后就开始等结果。
然后结果一般是：
要么发现 ai 折腾了半天，只打开了亚马逊的前台，要么等半天等到一堆虚构的数据。
为什么会这样？
有很多原因，我们后面再说。
但是我想先说的是，首先这个流程就有问题，因为不够详细。
我的做法是先把这个事情先拆成一条清晰的动作链：
打开亚马逊前台网页链接 输入关键词 "yoga mat" 获取前两页所有 listing 链接 把链接记录到表格里 依次进入每一个 listing 抓取这条 listing 下面的差评 把差评写回对应的行
拆到这种程度，才是基本合格的。
拆解这件事，本质上第一不是为了给 AI 看，为了逼我们自己把"我到底要什么"想清楚。
拆解得越细，我们自己越知道自己要的是什么，这是第一点。
第二点是，AI 的产出也会更稳定。
我们可以把 AI 想象成是一个非常聪明的实习生。
如果你的指令很模糊，那它可能在一条错误的路上狂奔。
但如果你的指令越清晰，那么它就越能拿到让你满意的结果。
举个具体的的例子。
公司来了个清华的实习生，你跟他说好：给这个保温杯做一张漂亮的电商主图。
这句话本身就有问题。
因为，请问漂亮怎么定义？
如果漂亮都不能定义，都有巨大的歧义，那请问它做出来的图你作为 leader 会满意吗？
所以 AI 是一个放大器——你是清晰的，它放大清晰；
你是混乱的，它放大混乱。
拆解不是给 AI 看，是给自己看。
02 颗粒度是门艺术，不是越细越好
问题来了：拆是拆了，那每一步都是一个 Skill 吗？
这里是第二个坑，也是最容易走极端的地方。
有的人一个 Skill 把整个流程全包了——从打开亚马逊到写回表格，一个 SKILL.md 文件里塞 3000 行。
有的人又走到另一个极端——每一步都做成一个 Skill，一个简单的抓取任务被拆成 15 个 Skills。
两种都不对。
我的经验是：扣子或 n8n 里能作为一个完整节点的事情，差不多就是一个合理的 Skill。
一次登录亚马逊、拿一页 listing 链接——一个 Skill。
进一个 listing、把评价扒下来——一个 Skill。
把数据回写表格——一个 Skill。
为什么一定要有颗粒度的意识？
因为太粗和太细，都可能导致不同的死法：
太粗：Skill 里塞太多事情，描述写不准。
AI 根本判断不了什么时候该触发这个 Skill。就像你跟员工说"你负责所有事"，他大概率什么都做不好。
太细：Skill 一多，AI 光是读 Skill 列表就已经累了。
调度的成本比干活的成本还高，而且维护起来也很累。
一个 Skill 只干一件事，而且能被一句话说清楚——这才是合格的颗粒度。
一个节点 = 一个 Skill。
这是我目前跑下来最舒服的尺度。
03 最重要的一点：永远有"上下文脑容量"意识
这一条，我要单独拎出来讲。
因为它是真正决定你工作流能不能跑起来的天花板。
AI 的上下文窗口是有限的。
我们可以把它想成一个人的脑容量。
一个人再聪明，一次只能装下那么多事。
你在他脑子里塞的琐碎信息越多，他真正用来思考的空间就越少。
Skills 也是一样。
一个 Skills 工作流，如果环节太多、每个 Skill 都塞得满满的，AI 跑一次就要加载一堆说明。加载完之后，它用来"干活"的那点空间，可能就剩一小半了。
我以前写过一篇《提示词越长，AI 就越笨》，本质和这个很像。
"提示词越长越精确"——这是大多数人对 AI 最大的误解。
事实是：
前 200 字的权重，比后面所有内容加起来都高。
研究里提到过，提示词超过 500 字之后，AI 对关键指令的识别准确率会下降 30% 以上。
Skills 工作流也一样。
如果我们串 15 个 Skill 跑一次，AI 读完第一个 Skill 的时候，后面 14 个的细节它已经开始"忘"了。
等到最后一步执行的时候，它其实是在"大概记得"的状态下硬跑。
结果就是：偷懒、跳步骤、胡编数据。
所以我有一个很粗暴的经验：一次执行，4 到 5 个 Skill 是比较合理的上限。
再多，基本就得考虑用子代理（sub-agent）去分段处理。
现在的 Claude Code、Codex 都支持 Agent 协作。
我们可以让一个"父 Skill"调度若干个"子 Skill"，每个子 Skill 单独开一个窗口、带一份自己的干净脑容量去干活，干完之后只把结论丢回父 Skill。
这样主窗口的脑容量就不会被中间过程污染。
但哪怕有了子代理，你也不能松懈。
我们永远要带着这样一个问题在脑子里：
"这一步，AI 的脑子里还剩多少空间？"
同一个对话窗口，聊得越久，脑容量就被占得越满。
背景越堆越厚，AI 能真正思考的余地就越小。
到最后，它一定会偷懒。
因为 AI 永远是目标导向的——它要完成你交代的任务。脑容量不够了，它就会砍步骤、跳环节、甚至自己编造数据，只为了让那个"完成"被勾上。
脑容量够，它守规矩；脑容量不够，它就可能疯狂偷懒。
上下文被挤满，思考就没地方了。
04 想自动化，就必须加一道质检
上一条讲到 AI 会偷懒，所以就有了第四条：
任何一个你真正想自动化的工作流，都必须有专门的质检步骤。
Skills 工作流和 n8n、扣子不一样。
n8n 写错一个变量，整个流程直接报错停住——它至少会告诉我们，我坏了。
Skills 不会。
Skills 太聪明了，它会"自己想办法"。
想不出来的时候，它就会伪装成"想出来了"。
很多时候情况是这样的：
让它抓 20 条评价，它抓了 5 条真的，剩下 15 条是它自己"补"出来的； 让它写一篇文章，它中间有一段查不到资料，就自己脑补了一个"听起来很合理"的数据； 让它生成 9 张图，它发现其中一张 prompt 生成失败，就干脆复制了另一张充数。
所以一个完整的 Skills 工作流，一定要有一个独立的质检 Skill，专门负责校验上一步的输出是否合格。
内容类工作流要有文字质检；
配图类工作流要有图片质检；
数据类工作流要有数据回填校验。
我自己做公众号的那套工作流，从排版优化到新闻图取证、AI 配图、封面制作，中间专门插了一个"配图质检 Skill"——
它只干一件事：检查每张图和对应段落是否匹配、顺序是否正确、密度是否合理。
05 内容写作不可能 100% 自动化，最核心的是"活人感"
如果你想把内容自动化，那么不要追求 100% 自动化。
因为内容写作最核心的一件事是"活人感"——你得让读者感觉文字背后有一个真实的人。
但 AI 恰恰最没有"活人感"。
它非常擅长写出结构完整、逻辑自洽、语法正确的文字。
但它写不出：
今天早上被楼下猫吓到、
想起你爸当年一句话、
在回家路上突然改了主意的那种东西
……
那才是让一篇文章活起来的东西。
所以内容创作的正确目标不是"全自动"，而是"尽可能减少人工"。
这是两件完全不同的事。
全自动 = 我不参与，AI 全做。
减少人工 = 繁琐的、可标准化的部分交给 AI，真正需要人判断的环节我来做。
举例子，我一般交给 Skills 的事情包括：
文章排版优化 标题的备选 图片生成和质检 封面制作 发布流程 多平台分发
必须我自己来的事情包括：
观点本身 选题的判断 行文的节奏 那一两句让人转发的金句
06 调试工作流，先从最难的环节开始
很多时候我们搭工作流是这样的：
第一步 → 调通 → 开心
第二步 → 调通 → 开心
第三步 → 调通 → 开心
……
第 N 步 → 发现根本做不到 → 前面全白搭
非常可惜，所以现在我的顺序是：先从最难的环节开始。
回到亚马逊那个例子。
抓 listing 下面的评价——这是整条链路最难的一步。
因为评价需要加载、还要分页、还涉及到网页的反爬机制。
所以重点先测试一件事：
给 AI 一条现成的 listing 的网址，试下能不能把评价抓下来。
能——往上走一步：给关键词，能不能拿第一页的 listing 链接？
能——再往上走：能不能翻第二页？
最后才是把这些环节串起来。
07 电脑自动化只能打 30 分，浏览器自动化 50 分
最后一条，是我对现阶段 AI 跨平台能力边界的一个粗暴的判断。
最近一年，有太多自媒体文章宣传说：AI 已经能替我们操作电脑、操作浏览器了……
是能，但离具体做事情，还有不少的距离。
电脑自动化（直接操作你的桌面、点按钮、拖文件）——我觉得目前只有 30 分水平。
浏览器自动化（在浏览器上面操作，点击网页按钮、输入内容等）——我觉得只有 50 分。
为什么？
因为操作网页或者操作软件，每一个简单的步骤，背后都有非常复杂的与目标行为无关的代码。
而且当代码无法判断的时候，AI 也严重依赖截图确认。
而一张截图，占的上下文空间，相当于几千到几万个字。
那么就又回到了第三条：脑容量。
我们让 AI 自动操作电脑，它每一步都要读取大量无关的内容来判断现在的状态——
点一个按钮，大脑容量少了十分之一；
等页面加载好了，看一眼，大脑容量又少了十分之一；
确认一个字段填对了，再确认下，大脑又少了十分之一的容量
……
最后不过是填了几个数字，大脑已经要满了。
所以我现在的原则是：
能用 API 解决的，绝对不用浏览器自动化（还是亚马逊那个例子，其实最优先考虑的解决方案是看有没有现成的软件可以直接提供数据，那么我们只要用 AI 进行分析即可）； 能用浏览器自动化解决的，绝对不让它去操作电脑桌面； 能让它读文本的，绝对不让它截图。
文本驱动，永远优先于视觉驱动。
电脑自动化和浏览器自动化不是不能用，是要用在"刀刃"上——
当 90% 的步骤已经用文本搞定了，只剩 10% 必须点一下鼠标的时候，再让它去"动手"。
不能一上来就让 AI 满屏点来点去。
每截一次图，脑容量就少一截。
最后一句
写完这 7 条，再加上开头那三问，我自己也发现，它们其实都指向同一个东西——
对 AI 上下文的敬畏，以及对自己时间的敬畏。
Skills 工作流看起来是在设计流程、写文件、串步骤，但它本质上一直在回答一个问题：
这一步，我该怎么做，才不会把 AI 的脑子撑爆、也不会把我自己的时间浪费掉？
动手之前先问三问，是为了不在已经有答案的地方重复造轮子。
拆解，是为了让每一步信息密度可控。
颗粒度，是为了让调度成本可控。
上下文意识，是直接对准脑容量本身。
质检，是为了补偿脑容量不够时的偷懒。
活人感，是承认有些事永远留在人脑子里。
先调最难的，是为了让"脑容量预算"花在刀刃上。
30 分和 50 分，是在提醒我们：AI 也不是万能的，要理解它的上限。
部分配图由 AI 生成。
热门活动 
广东
04-17 周五
热门报告 
