技能系统代表一种工程级思维方式。它把智能模型的灵活表达能力，与脚本和模板的稳定执行力组合成一套可复用、可扩展、可并行的自动化体系。技能并非一份说明文档，而是一整套可运行的能力容器。掌握这一结构，等于把重复劳动升级成持续产出的机器。
那些老程序员的傲慢让人笑掉大牙
有些写了十几年代码的老油条，一提起Skills技能系统就摆出一副高高在上的嘴脸，好像这是什么前沿实验室为了卖订阅服务而搞出来的新奇玩具。张嘴就是"老子写了十五年代码，不需要这些花里胡哨的东西"，要么就是"我 prompt 写得够好，用不着技能"，最离谱的是有人说"这不就是几个 markdown 文件嘛"。
这种心态简直短视到令人窒息。你确实可以靠手搓完成所有任务，这没问题，你厉害，你牛，你手工打造法拉利。
但这恰恰证明了你正在错过一个能让大语言模型发挥全部潜力的完美框架。
技能从来就不是什么 markdown 文件，技能是一整个文件夹体系。这个文件夹里面可以塞满各种子文件夹、脚本、模板，甚至嵌套其他技能。那个 skill.md 文件不过是给代理看的说明书而已，告诉它怎么探索这个文件夹、什么时候用什么工具、按什么顺序执行。
把技能说成"就是个 markdown 文件"，这跟说"GitHub 仓库就是个 README"一样愚蠢。README 告诉你怎么用里面的东西，整个文件夹才是真正的产品。
更妙的是，你的编程代理只会按需加载上下文，一步一步来， token 效率高到离谱。这种设计让确定性的脚本和非确定性的 AI 能力在同一个编排系统里和谐共处，你再也不用二选一了。
所以，虽然很多人写代码多年，形成一种肌肉记忆式的自信：键盘一敲，提示词一输，结果立刻出现，心里产生一种掌控感。这种状态很爽，也很熟练。
但是，工程型自信来自另一条路径：把一次成功流程沉淀成结构，让系统每一次运行都走同一条清晰路线。
前者依赖状态和手感，后者依赖结构和流程。
时间一长，差距自然拉开。
技能文件夹的底层逻辑彻底颠覆传统认知
让我把这个概念掰开了揉碎了讲给你听。技能系统的核心在于渐进式披露，代理只在需要的时候看到需要的东西。这就像是给 AI 戴上了战术目镜，而不是让它在信息海洋里瞎扑腾。传统的 prompt 工程是把所有上下文一次性塞进对话窗口，技能系统则是让代理像探险家一样，按照 skill.md 的指引逐步深入文件夹结构，每一步都有明确的目标和工具。
这种架构的牛逼之处在于它的递归性。一个技能可以启动子代理，这个子代理又能调用其他技能，那些技能还有自己的说明书、模板和脚本。每一层都是自包含的，但又设计得可以无缝插入到上一层。这就像是代码里的函数调用，每个技能都是一个带有清晰输入输出的函数，skill.md 是文档字符串，文件夹内容是具体实现。你可以像搭积木一样把它们组合成庞大的系统。
脚本负责那些需要绝对精确的工作：调用 API、操作文件、格式化数据。大语言模型负责那些需要灵活性的任务：写作、研究、综合信息、做创意决策。技能文件夹就是这两个世界的交汇点。那些理解这套玩法的人正在构建自动化系统，那些把技能当成"只是 markdown 文件"的人还在手工搬砖。手工搬砖不丢人，但别觉得自己因此就高人一等。
我的 Newsletter 自动化流水线实战演示
光说不练假把式，我给你看一个我亲手搭建的 workflow，它跑通了我的整个 Newsletter 发布流程。这不是什么理论推演，是我每周都在用的真家伙，每次运行都稳如老狗，输出质量完全一致。
整个流程从一个技能调用开始，我给代理三个新闻链接，这些是我要在财经 Newsletter 里报道的故事。第一步是获取价格数据，技能被激活后，首先运行一个脚本去调用 API，拉取过去七天的价格数据。这一步完全是确定性的，不需要大语言模型参与，就是文件夹里的一个脚本，老老实实执行命令，分毫不差。
第二步进入文章生成阶段，技能启动三个子代理，每个代理负责一个链接。每个子代理调用另一个技能，这是一个专门写博客的技能。这个二阶技能先去抓取故事内容，然后每个子代理执行三次相关的网络搜索来收集额外背景信息。文章使用二阶技能文件夹里的模板来撰写，格式统一，风格一致。
第三步是图片生成，文章写完后，系统调用另一个技能，这个技能再调用一个确定性脚本来生成博客封面图。所有文件都保存到各自的文件夹里。这一步完美展示了确定性与非确定性的结合，脚本负责精确地调用 Gemini API，大语言模型负责创作图片的提示词，各显神通。
第四步自动发布到 WordPress，又一个技能被调用，把内容自动发布到网站上。每个子代理返回文章摘要，以及文章文件和封面图的路径，这些信息回流到父代理。
第五步是 Newsletter 组装，回到父代理层面，Newsletter 代理使用三个子代理返回的文章来 craft 整个 Newsletter。Newsletter 使用技能文件夹里的特定模板撰写，总结文章内容，邀请读者访问 WordPress 阅读全文，而这些内容早就在前面的步骤里自动发布好了。
最后一步输出邮件，Newsletter 被写入文件，生成按照模板格式化的 HTML 邮件，直接可以审阅和发送。从三个 URL 到发布好的 WordPress 文章，再到可以直接塞进收件箱的 HTML 邮件，全程自动化，全程可重复。
这套系统的威力在于模块化与嵌套
让我们 zoom out 看看刚才发生了什么：十个技能协同工作，三个子代理并行运行，九个脚本处理确定性任务，四个模板确保输出一致，一个命令启动一切。所有这些文件夹都是独立封装的，以确定性的方式被调用。它们模块化，但又和谐统一。子代理调用更多技能，这些技能有自己的指令和模板，再调用更多技能，如此往复。
这个 workflow 复杂到飞起，但它是百分之百可重复的。可靠到每一次运行都能产出同样水准的输出，因为系统在 skill.md 里被一步步规划好了，告诉代理模板在哪里、什么时候调用子代理、子代理又如何调用其他技能，层层嵌套，井然有序。
关键在于嵌套机制：一个技能调用子代理，这个子代理调用另一个技能，那个技能有自己的说明书、模板、脚本。每一层自包含，但设计上又能插入到上一层。就像代码里的函数，每个技能都是带清晰输入输出的函数，skill.md 是文档字符串，文件夹内容是实现。你可以把它们组合成更大的系统。
嵌套这种设计方式与函数组合高度相似：输入明确，输出稳定，组合后形成更大的能力单元。
系统像乐高积木，拆开依然完整，拼装立刻升级。
脚本处理需要精确的工作，大语言模型处理需要灵活性的工作，技能文件夹让这两个世界相遇。Newsletter 例子只是其中一种模式，同样的架构适用于任何可重复的工作流：内容管道、代码生成、数据分析、报告构建、客户交付。任何你需要做超过一次的事情，都可以打包成技能，每次以同样的方式运行。
关于技能系统的深层思考与行业启示
这套方法论背后有一个更宏大的叙事。我们正处于软件工程范式转移的临界点，从手工编码转向编排自动化。技能文件夹是这个转型的基础设施，它解决了大语言模型上下文管理的根本难题。传统的做法是把所有可能用到的信息一次性塞进 prompt，这不仅浪费 token，还让模型难以聚焦。技能系统的渐进式披露让代理像人类专家一样，按需获取信息，保持清晰的思维链。
更重要的是，这套系统实现了确定性与创造性的完美分工。脚本负责边界清晰、逻辑严密的任务，大语言模型负责需要判断力和创造力的任务。这种分工不是简单的任务切分，而是在同一个工作流里动态调度。一个步骤可能是确定性脚本，下一步可能就是需要模型推理的决策点，再下一步又回到脚本执行。这种灵活性是传统的自动化工具无法比拟的。
对于那些还在嘲笑技能系统"只是 markdown 文件"的开发者，我只能说你们正在错过一个时代。你们可以继续保持手工打造一切的自豪感，但当你的竞争对手已经用十个技能、三个子代理、九个脚本构建起全自动的内容工厂时，你的手工精雕细琢就变成了效率的绊脚石。这不是关于谁更聪明的问题，这是关于谁更愿意拥抱新工具的问题。
技能系统的真正威力在于它的可组合性和可复用性。
一旦你构建了一个写博客的技能，你可以在无数个 workflow 里复用它。一旦你有了一个生成图片的技能，它可以被 Newsletter 流程调用，也可以被社交媒体发布流程调用。这种复用不是简单的代码复制，而是通过 skill.md 定义的清晰接口实现的真正模块化。
每个技能都是一个黑盒，输入明确，输出规范，内部实现可以不断迭代优化，而不影响调用它的其他组件。
理解技能体系的人，注意力自然转向系统建设。每一次重复任务，都有机会被封装成技能。内容生产、代码生成、数据分析、报告交付，都能沿用同一套结构。效率提升来自结构积累，而非临场发挥。
手工完成代表技巧，系统运行代表层级跃迁。
结语：欢迎来到自动化俱乐部
这不是什么遥不可及的科幻场景，这是现在就能落地的工程实践。
技能文件夹给了你构建复杂自动化系统的脚手架，渐进式披露解决了上下文管理的痛点，嵌套调用实现了真正的模块化组合。
那些理解这套玩法的人正在构建系统，那些 dismiss轻视 技能的人还在手工搬砖。看看那个 Newsletter pipeline 的视频，从 URL 到发布的 WordPress 文章再到收件箱就绪的 HTML 邮件，全程十个技能、三个子代理、九个脚本、四个模板，全自动，全可重复。
独特性评价：这篇内容的价值在于它把一个看似简单的技能文件夹概念，通过具体的 Newsletter 自动化案例，展示出了惊人的工程深度。特别是关于"确定性脚本与非确定性 AI 能力融合"的论述，触及了当前 AI 工程化的核心矛盾。