Computing Life

在上一篇文章里，我们介绍了用好 AI 的第一步是停止使用聊天框（比如 ChatGPT 和豆包），而转用 Codex，Claude Code，Cursor 这样的本地 AI 工具。 这篇文章发布以后，我们在社区和微信群里都得到了很多正面反馈。 但同时也发现了两个问题。

第一是来自非技术背景的同学。他们在安装了 Claude Code和 Cursor 这些工具之后，觉得这明显是一个用来写代码的工具。 很难想象怎么把这些工具用到自己的工作中去。 所以稍微尝试了一下就放弃了。另一种是有技术背景的程序员们。他们觉得我每天都已经在用 Claude Code 了，所以这个文章的方法和他们无关，非代码的任务还是继续使用聊天框。

这两个问题表面上看起来关系不大，但其实反映了一个简单却深刻的工作方式的变化。这个变化就是先外化（externalize），再执行。这篇文章就想把这个思维方式讲解清楚：外化是手段，复用是目的，Skill是载体。写Skill是一个人人都能做的简单的方法，可以让AI越用越好用，有效集成到每天的工作里去。但注意这个Skill不是网上常见的怎么用搜索引擎或者怎么发小红书的Skill，而是更贴近工作场景的Skill，比如怎么做好特定领域的调研，怎么写出没有AI味的文章等等。

先外化，再执行

我们绝大多数时候工作的流程是这样的。拿到一个任务， 复杂一些的可能会先在脑海中做个计划，简单的任务就直接上手做了。调研旅游攻略， 买个火车票，做一道菜。 没有人会先写个文档，介绍下面是我做西红柿炒鸡蛋的详细计划。我们就直接去切菜做菜了。大家唯一想着要外化或者说把怎么做这件事情写到文档里，是有分享需求的时候。比如这个城市特别好玩。我要把攻略写成一个帖子发在小红书上。或者我做的这道菜太牛逼了，我得把它写成菜谱发给朋友。

这是非常自然的一件事情。因为我们有记忆。下次再做的时候，自然而然就会想到之前的经历，以前踩过的坑。但像我们在上篇文章提到的，（绝大多数产品里）AI是没有记忆的。 你每次点新建聊天按钮以后，它拿到的就是一张白纸，上面写着你的prompt，然后它开始答题。它在第一次调研的时候踩过一个坑，如果我们不记录下来写成文档的话，它下次还会踩同样一个坑。 这个道理特别简单，但它是用好AI的关键。

换言之，外化是复用的前提。只有开始积累这些教训，积累好的方法，AI才能越来越聪明好用。这也是我们为什么说不要用云聊天框比如ChatGPT，而要用本地软件比如Codex的原因。本地才方便你把教训落盘成文档，下次跟AI说你先去读一下上次那个文件，它就不会犯同样的错了。这就是复用。

但这对我们大多数人来说是很难跨过的一个坎，因为这种先外化再执行的做事方法太奇怪了，和我们的生活完全不同。我买张火车票还得先做个计划？这不是脱裤子放屁嘛。但其实仔细想想，它很多时候反而是标准做法。比如我们雇一个家政来打扫卫生，我们会跟她仔细讲清楚。 油烟机背后容易漏掉，要仔细擦。马桶内外都要刷干净。虽然没有写成白纸黑字的文档，但这本质上也是把评价标准和做事方法外化了。 或者我们在工作中间带实习生的时候，也会手把手教很多实操的技巧和可能会踩的坑。这种时候我们已经潜移默化用上了先外化再执行的做事方法， 只是没有把它落盘到一个严格的文档里而已。

程序员是一个更好的例子。他们每天的工作100%都是先外化再执行。这是因为程序员没办法越过电脑直接微操CPU上手做事，而只能通过程序来控制电脑干活。程序天然就是一种外化，用最清晰直接的语言向电脑介绍了你怎么完成一个特定的任务。也正因为如此可以直接复用。所以程序员们特别习惯先外化再执行的方法论，在AI时代从Mindset的角度占了一个重要优势。（但同时也带来了一个枷锁，下面我们再聊）

外化是为了积累复用，积累的载体是文档/Skill

所以回到我们最开始介绍的问题。尤其是对不做软件开发的同学，在 Claude Code 这样的工具里使用AI最关键的不是写程序。或者说写程序既不是我们的目标产出，也不是我们关注的重点。 我们在用这些工具的时候，就应该像使用聊天框式的 app 一样，把同样的 prompt扔给它。比如“我明天想去西雅图玩。你帮我规划一下”，或者“这是我今天体检验血的报告，你帮我看看有没有什么问题”。 为了完成我们的任务，AI可能会写一些代码，但它只是用来完成任务的一个手段或环节而已。（一个题外话是，Codex/Claude/Cursor这些app现在都有桌面版了，界面也都非常类似和友好，不用死磕命令行黑框框了）

但如果只是把同样的 prompt搬到 Claude Code 里面问，虽然会有更好的体验，比如 AI可以直接读到你本地的体检报告单，但仍然做不到质变。AI能力的质变发生在长期的积累和复用上。比如我今天花了半小时终于把 AI 和公司邮箱连起来了，下一次再用就不用从头再配置，而是可以直接跟它说。“你去看一下我的邮箱，然后去做XXX”。这些积累和复用就需要外化。

如果用普通的思路来看“把 AI 和公司邮箱连起来”这件事，它的结果就是 AI 下载了收件箱里的邮件。邮件下载完毕，这件事就结束了。但如果用外化和复用的角度来看，这件事的产出远不止于这一次下载到的几封邮件。 我们可以积累一个指南性质的文档，下次AI只要看了这个文档就可以顺利地从公司邮箱中下载邮件。 比如这个文档可能会说：“我们要用Outlook，不要用Mac默认客户端，我们先给它这个用户名，然后手机会弹窗，我们打开app刷一下脸。就可以下载邮件了。” 当我们有了这个文档以后， 我们给AI的prompt 就可以变成：“你去看一下connect_mail.md这个文档。然后同步一下邮件。“ 在阅读文档以后，AI就知道去遵循这些指令，跳过所有的陷阱，顺利完成任务。这里第一次探索如何连接邮箱并且写文档的过程就是外化，而AI第二次用这个文档来完成任务的过程就是复用。

注意上面这个例子里，我们积累和复用的载体不是代码，而是知识或者说文档。 这个文档可以是技术性的，比如怎么连接Outlook，更多的时候是非技术的。比如调研的方法（用google用中英文双语关键字多搜搜），思考的方式（写完以后开一个杠精AI来找逻辑漏洞），写文章的惯例（会议简报要控制在一页以内），甚至老板的喜好（配色用浅蓝色，不要出现绝对化的用词）。当这些抽象的东西都可以复用以后，我们可以想象一个长期调教后的AI可以组合完成非常复杂的任务。 比如从公司的 wiki 里做调研，结合网络搜索，来完成邮箱里老板布置的任务，最终写一个符合公司规范的 PPT。我们就专心做最后的审核和方向上的指点就好。这种能力是原生豆包/ChatGPT无法比拟的。但一切的前提都是，我们用AI执行任务，不仅要抓执行结果，而且要把它怎么做这样的任务的心得/知识沉淀到文档里。

这里就要提一下技术人员/程序员很容易陷入的一个陷阱，就是认为只有代码才是积累和复用的载体。这和他们对”先外化再执行“的熟练程度是一脉相承的。 在软件工程师每天的工作里，虽然他们的工作都需要先把思路外化成程序再让电脑执行，但这同时也带来了一种肌肉记忆，就是如果我们要复用一个东西，这个东西首先得变成代码的形式，构成了“AI就是用来写代码的”这种错误印象。所以在面对代码以外的知识资产的积累和复用上，程序员和非程序员其实站在同一个起跑线上。 甚至他们受到固有经验的影响，接受文档复用比代码复用更重要这一点反而更难。

总之，使用 Claude code 这样的工具写代码确实很有用，但如果只用它写代码，就暴殄天物了。它更大的潜力是做一个通用的 AI 工具，在软件开发的领域之外用外化和积累自动化各种智能任务。只是 Claude code恰好也擅长写代码而已。这是程序员尤其需要注意克服的思维盲区。

怎么用，写和组织Skill

在上面的讨论里，我们一直用文档做例子来描述用 AI 过程中沉淀下来的知识。但在实际应用里，它可以以更丰富多样的形式出现。这个形式和目前网上流行的 Skill 很类似。我们这里也沿用Skill这个现成的概念。或者说，使用AI积累的关键，就是写好Skill。

但有一点要注意，很多厂商比如 Anthropic 和 OpenAI 在设计具体产品的时候，一大目标是把我们锁定在他们的平台上。比如它会要求我们用特定的格式（YAML文件）来写 Skill。但实际上，AI 是非常灵活和强大的。Skill 的核心不是格式本身，而是内容。一个写得很烂的 Skill，哪怕用 Anthropic 特定的格式写出来，它在Claude上也不会work。关键还是我们用自然语言向 AI 描述我们想要什么结果、要注意哪些东西。只要这个内容写到了，哪怕我们不用特定的格式，不走专门的步骤来安装 Skill，甚至它不叫 Skill 这个名字，我们仍然能够自如顺利地使用 AI。

具体地说，一个好的 Skill 需要包含三个关键要素。第一，我们需要向 AI 交代最终想要的东西，要满足什么条件，换言之就是成功标准。注意，这里面最关键的是对最终状态的描述，而不是给 AI 一个事无巨细的 SOP 让它跟着做。这个和我们向下属交代任务也非常类似。比如我们跟家政阿姨说怎么打扫的时候，只会让她知道油烟机不论正面反面油污要擦干净。而不会给她列个单子第一步用什么清洁剂怎么用力，第二步用什么顺序擦哪里。这样微操又累效果又不好。AI 也是一样。很多时候给AI如何做的细节反而是一种阻碍。更好的方法是告诉它我想要什么，至于怎么做，是它自己去搞清楚。这种写提示词的方法叫 prompt for enablement。

第二个要素是，在这个过程中会踩什么坑、犯什么错误。这个是积累经验中最直接能看到改进的地方。在家政阿姨的例子里，就是油烟机别只看正面，背面也有很多油污别忘了擦。在AI里，比如 Claude 写作的时候老用破折号，我们就可以在这里加一句：写作的时候注意不要用破折号。或者我在调研的过程中发现，Tavily 这个搜索引擎的质量比 Google 还好，我就会在这里加一句：你做搜索的时候优先使用 Tavily。注意在写作过程中，我们要只把 AI真正犯过错的东西放进来，而不要事先去猜 AI可能会犯什么错。这是因为现在的 AI 都非常聪明了。犯错的概率其实不高。如果我们在这里写一大堆它可能犯，但实际上并不会犯的错误，反而是一种干扰。

第三个要素则是一些确定性的工具。比如AI怎么跟 Google 通信，给它一个关键字，它返回搜索的结果。这个东西是定死的，不需要每次都重复去现场探索。而完全可以给 AI 一个现成的工具，说你就用这个工具去拿到搜索结果。这个具体工具可以有很多形式，比如飞书有 CLI，跟着它的指令让 Codex 能调用到它就可以。Tavily有 MCP，在 Codex 里面把它加入 MCP 的配置就好。Gmail有Connector，在 Codex 的 connector 页面启用并且连接 Gmail 邮箱就好。对于这些都不支持的工具，比如微信聊天记录的读取。我们可以让 AI 上网搜索，或者自己写一个 CLI或者 MCP 出来。这里面工具的具体形式都不重要。关键是它把一个不需要太多智能，但需要反复执行的动作。让 AI 可以可靠地直接调用，而不是每次都从头摸索怎么办。

因此，当我们用本地的 AI 工具完成任务的时候，沉淀的过程特别简单。就在已有的 prompt 之外额外加一句“你把它写成一个 Skill “就可以。你可能已经注意到了，上面的prompt并没有具体跟它描述一个 Skill 要包含哪三个要素，怎么去写。这是因为这本身就是一个现成的复用的例子。我已经帮你沉淀好了，写了一个如何写 Skill 的 Skill。你只要把这个网址贴给 AI，或者放在本地让它能读到，它就知道怎么去写 Skill。比如对前面连接邮箱的例子，我们的 prompt 就可以是：“帮我探索一下如何连上公司的邮箱，并且根据<替换成前面的网址>，在成功之后把它写成一个 Skill，方便我下次复用。” 这样当 AI 做完探索工作以后，它就会自主地总结经验教训，或者更新上次写好的文档，来让以后的 AI 可以完成这样的任务。

事实上，我正好也写了一个针对 Outlook 的 Skill，分享在 GitHub 上。大家也可以去看一下这个 Skill 的结构，看看我们是怎么向描述成功标准的，我们给它提供了什么工具，这些工具是怎么帮它完成一些确定性的任务的。

当我们开始积累 Skill 之后，很快我们就会遇到一个问题，就是怎么组织 Skill。这个也非常简单。Skill 的核心就是一系列的自然语言文档，只要让 AI 能读到那个文档和调用相关的工具，这个 Skill 就可以被 AI 用起来。

我组织的方式是这样：把所有的 Skill 放到一个单独的 Skills 文件夹下面，然后新建一个 index.md，描述什么情况下应该具体去看哪个 Skill。这里是一个例子。然后把这个文件的路径放到 AGENTs.md 或者 CLAUDE.md 里面就好。这两个文件比较特殊，Codex 每次新建一个对话的时候都会自动加载 AGENTs.md 里面的内容。比如我们给了个prompt，“帮我用Skill同步outlook邮件” Codex 首先根据我们的AGENTs.md 自动加载的内容找到并且去读取我们的 Skills/index.md，然后根据这个index.md的内容找到 Outlook 相关的 Skill，进一步读取Skill文件，再遵循Skill 文件的指示，去调用我们的命令行抓取邮件。整个流程说穿了就是AI像人一样一步步读文档，根据文档指示干活，没有复杂的代码和发现机制，也不用被各个厂商的特定格式绑架。

用好AI关键在Skill的积累

归根结底，Skill可以让 AI 能够有效地复用和积累它在工作过程中学到的知识。我们在实际工作的过程中要有一个新的意识：知识类的智能工作也是可以复用和自动化的。如果我们发现自己做某个任务做了两三次，或者预见未来会重复做这个任务的话，一个很好的方法就是先写 Skill，再让 AI 照着 Skill 去执行。而且这个写作的过程并不会拖慢我们的速度——我们完全可以在之前给 AI 的 prompt 后面加一句：“根据写 Skill 的 Skill，先写一个 Skill 出来，然后照着它做。做完了以后根据学到的知识更新 Skill 文档”，就可以了。

这种先外化再执行的习惯，会从根本上改变我们手上 AI 进化的效率，从而让我们可以把更多的事情交给AI做，我们专心做真正需要判断的脑力活。

PS：我也整理和开放了十几个我积累的Skill：[github]，大家可以直接使用，也可以做参考看看写Skill的基本方法。