别再死磕长提示词了！把AI重复劳动变成“可维护技能”才是真正的效率飞跃

我曾经以为，提升AI生产力的下一次飞跃，来自于写出更好的提示词。

更长、更精确的提示词。包含角色定义、语气规则、示例、约束条件和输出格式的提示词。

但在读完一本关于“AI智能体技能”的书后，我发现这种思路格局太小了。

真正的瓶颈，不是我没能把一次任务解释清楚，而是我一遍又一遍地解释同一类任务：我希望文章怎么排版、我怎么审查代码、我怎么准备App Store的发布说明、我怎么生成配图、我在发布前怎么检查草稿。

到某个阶段，“使用AI”不知不觉变成了“手动管理AI”。

这本书最有用的观点很简单：

AI生产力不来自于把每个提示词写得更长，而是来自于把重复工作变成可执行、可维护、可测试的“技能”。

这改变了我对AI工作的看法。

技能不是提示词

提示词是一次对话里的临时指令。

技能是给智能体的一份可复用的操作手册。

这个区别听起来不大，但当你每天都在用AI时，差别就非常明显了。提示词告诉模型你现在想要什么；技能告诉智能体这一类工作每次应该怎么做：

• 什么时候启动
• 该看什么输入信息
• 跟着哪些步骤走
• 该调用哪些工具或脚本
• 要产出什么结果
• 绝对不能发生什么
• 在哪里必须停下来，请人类来做决定

最后一点特别重要。

我们的目标不是把人类从工作里踢出去，而是停止把人类的注意力浪费在相同的低级指令上。

对我来说，最明显的候选技能都不是什么稀奇玩意：

• 一个写作风格技能
• 一个代码审查技能
• 一个iOS发布检查清单技能
• 一个App Store发布说明技能
• 一个读书笔记技能
• 一个每周复盘技能

这些不是我做不了的任务，而是我一直在重复相同标准、偏好、注意事项和检查步骤的任务。

这种重复，才是真正的成本。

实用的分工：判断、苦力与工作流

书里最清晰的一个区分是这样的：

• 提示词负责“做判断”（语义判断）
• 脚本负责“干苦力”（确定性机械操作）
• 技能负责“当总指挥”（编排整个工作流）

这听起来理所当然，但很多AI工作流失败，就是因为给模型安排了错误的岗位。

比如，让模型决定一篇文章哪里需要配图，这是合理的。但让模型可靠地去重命名文件、验证图片尺寸、切分长文档或计算表格数值，通常是灾难。

那些是确定性的苦力活，应该交给脚本或严格的工具来干。

模型更适合做判断：

• 选择文章的切入点
• 找出草稿的薄弱环节
• 对比两个架构方案
• 解释一个权衡利弊
• 把粗糙的素材变成清晰的语言

技能则凌驾于两者之上。它说：当这类任务出现时，用模型做判断，用脚本干苦力，并保留需要人类做决定的检查点。

这比把所有东西塞进一个巨型提示词要靠谱得多。

上下文是工作台，不是杂物间

大模型的上下文窗口越来越大，这就很诱惑人把所有东西一股脑扔进对话里。

风格指南、历史聊天、示例、模板、API文档、草稿、个人偏好，全塞进去。

但这本书提倡相反的纪律：在正确的时间，加载正确的材料。

技能就该这么设计。主技能文件不应该变成杂物间，它应该只包含核心工作流：

• 触发条件
• 输入和输出
• 主要步骤
• 硬性约束
• 失败模式
• 只在需要时才加载的参考文件索引

长长的模板、例子、API笔记和风格样本，应该放在单独的参考文件里。

这不仅是为了省点Token，更是为了集中注意力。你塞进上下文的无关材料越多，模型就越容易漏掉那条真正重要的规则。

上下文应该像一个干净的工作台：当前任务需要的工具才摆上去。

好的工作流绝不是全自动

AI自动化最危险的版本，就是看起来很高效，因为它删掉了所有暂停。

给智能体素材，让它选角度，让它写草稿，让它润色，让它配图，让它发布。

这看起来像生产力大赢，但通常这只是把最重要的决定外包出去了。

更好的工作流更有选择性。

对于写作，我希望AI这么做：

• 分析素材
• 提出几个切入点
• 停下
• 让我选角度
• 按这个角度起草
• 按我的标准修改
• 准备各平台的版本

这个停顿不是阻力，而是核心价值。

开发也一样。AI可以提实现方案、写测试、扫回归Bug、写发布说明。但架构决策、产品权衡和发布决定，依然需要人类拍板。

AI可以做准备工作，它不该悄悄夺走判断权。

技能需要工程化，不是花架子

一个有用的技能，应该被当成一个小软件产品，而不是一个聪明的笔记。

这意味着它有生命周期：

• 定义真实问题
• 搭建最简可用版本
• 在真实任务上跑
• 记录失败模式
• 加上测试或例子
• 文件太长就重构
• 随着工作变化持续改进

一个技能最有用的部分，往往不是优雅的工作流，而是“避坑指南”部分。

那是你记录反复出洋相的地方：

• 智能体忘了读参考模板
• 输出听起来太假大空
• 脚本处理了错误的文件路径
• 模型重写了它应该保留的段落
• 任务在发布前需要人工确认

这就是把个人经验变成系统记忆的地方。

如果同一个错误发生两次，它大概就该写进技能里。如果同一个任务发生三次，它大概就该变成一个技能了。

安全边界是设计的一部分

当技能能读文件、写文件、调脚本、联网或发布内容时，它就变得严肃了。

这时候，它们不仅是提示词，而是操作工具。

所以安全规则必须从一开始就设计好：

• 限制技能能读写的位置
• 没确认前别干破坏性操作
• 覆盖重要文件前先备份
• 发布流程先用假数据测试
• 共享技能前删掉本地路径、密码和个人假设
• 运行第三方技能前先检查它们的脚本

这不是疑神疑鬼，这是基本的工程卫生。

智能体越能干，边界就必须划得越明。

我打算先试什么

这本书让这个想法足够具体，我可以把它变成每周习惯。

这周，我会先从三个小技能开始。

第一：一个写作风格技能。

不是长篇大论。只需一个角色、三个风格原则、一个简短的禁用词列表，和几个“好文章”的例子。

第二：一个iOS或App发布检查清单技能。

第一版只需覆盖版本号、发布说明、截图、隐私文本，以及提交前最后的人工确认。

第三：给现有技能加“避坑指南”。

拿出最近三个让你失望的AI输出，把每个失败变成一条具体规则。不要只为一个例子打补丁，要捕捉模式。

还有一个值得立刻跑的小实验：

拿一份你想写成文章的素材。不要让AI直接写文章。只让它做两件事：分析素材，提出三个切入点。然后停下，自己选角度。

如果最终文章变好了，那这个人工检查点就值回票价了。

核心转变

这本书并没有让我想更多地使用AI。

它让我想更少地手动管理AI。

这才是真正的转变：从临时指令到可复用工作流；从提示词堆砌到经验工程化；从要求AI记住我的偏好，到把这些偏好写进一个可以维护的系统里。

更好的提示词依然重要。

但真正的复利回报，来自于提示词不再是一次性指令，而是变成技能的一部分的时候。