1. 从“superpowers”这个标题说起它到底是什么为什么突然火了第一次看到“superpowers”这个词是在一个开发者社群里。有人发了一张截图里面列了一长串以“superpowers”开头的技能名称底下配文是“装上这个感觉自己的工具链突然多了十几个外挂”。当时我的第一反应是又是一个营销概念吧但点进去仔细看完之后我改变了看法。“superpowers”本质上是一套技能skills集合与调用机制。它不是某个具体的软件也不是某个单一的库而是一种把零散能力打包成可复用模块的思路。你可以把它理解成一个“技能仓库”——里面存放着各种预先定义好的能力单元每个单元负责一件事比如代码审查、文档生成、数据处理、自动化测试等等。当你需要某个能力时不需要从头写直接引入对应的技能就行。这个词之所以在近期被频繁搜索核心原因有三个。第一工具链碎片化已经到了让人头疼的地步每个人手里都有一堆脚本、配置、小工具但彼此之间没有统一的组织方式用的时候找不到找到了又忘了怎么用。第二复用成本太高同一个功能在不同项目里反复实现浪费了大量时间。第三“superpowers”提供了一种轻量级的组织方案不需要大动干戈重构就能把现有能力串起来。这篇文章适合谁看如果你手里有一堆零散脚本不知道怎么管理如果你经常在不同项目之间复制粘贴同样的代码如果你听说过“skills”但不知道从哪下手那这篇内容就是为你准备的。我会从整体设计思路讲起然后拆解核心细节接着给出完整的实操过程最后把我踩过的坑和排查技巧一并分享出来。全程不绕弯子直接说人话。2. 整体设计与思路拆解为什么是“技能”而不是“工具”2.1 核心思路把能力单元化而不是把工具集中化很多人第一次接触“superpowers”时会下意识地把它当成一个“工具箱”——以为装上一个东西所有功能就都有了。但实际用下来会发现它的设计哲学恰恰相反它不是把工具集中到一起而是把能力拆成独立的单元。这两者的区别很关键。工具箱的思路是“我有一把瑞士军刀什么都能干”但问题是刀片越多单个刀片就越薄用起来反而别扭。而技能单元的思路是“我有一排专用工具每个只干一件事但干得特别好”。当你需要拧螺丝时拿螺丝刀需要剪线时拿剪线钳。每个技能都是独立的可以单独引入、单独替换、单独升级。这种设计带来的最大好处是组合自由。你可以根据项目需要只引入相关的技能不会被迫接受一堆用不上的东西。比如你只做数据处理那就只引入数据相关的技能你只做前端开发那就只引入前端相关的技能。每个技能之间通过标准接口通信互不干扰。另一个好处是维护成本低。如果某个技能出了问题你只需要修那一个不会影响其他技能。如果某个技能过时了直接替换掉就行不需要动整个系统。这种“高内聚、低耦合”的思路在软件工程里是老生常谈但真正落实到日常工具管理上能做到的人并不多。2.2 方案选型为什么不用插件体系或宏系统你可能会问插件体系和宏系统也能实现类似效果为什么非要搞一套“技能”机制这个问题我当初也想过后来实际对比之后发现差异主要在三个方面。第一插件体系通常绑定特定宿主。比如某个编辑器的插件只能在这个编辑器里用换个环境就废了。而技能是宿主无关的只要环境支持标准调用方式就能用。这意味着你可以在命令行里用也可以在脚本里用还可以在自动化流程里用。第二宏系统偏向代码生成适合处理重复性代码模式但不适合封装完整的工作流程。一个技能可以包含多个步骤、多个判断、多个输出而宏通常只做文本替换或简单展开。技能更像是一个“小函数”有输入、有处理、有输出逻辑可以很复杂。第三技能的可发现性更好。插件和宏通常藏在配置文件或代码注释里新人来了根本不知道有哪些可用。而技能有统一的命名规范和目录结构看一眼就知道有哪些能力可用每个能力叫什么、干什么用。这种“自描述”特性对团队协作来说非常重要。我自己的选型逻辑很简单如果一件事需要重复做三次以上就把它封装成技能。这个阈值不是拍脑袋定的而是根据实际经验来的。做一次两次直接手写更快做三次以上封装带来的收益就开始超过成本了。而且封装之后下次再遇到类似需求直接调用就行不用重新想逻辑。2.3 适用场景与边界什么情况下该用什么情况下不该用“superpowers”不是银弹它有明确的适用场景。根据我的使用经验以下情况特别适合多项目并行开发不同项目之间有很多共通能力比如日志处理、配置读取、数据校验。把这些封装成技能每个项目按需引入避免重复实现。团队协作新人入职时不需要逐个了解每个脚本的用法直接看技能列表就知道有哪些能力可用学习成本大幅降低。自动化流程把多个步骤串成一个技能一键执行减少手动操作带来的错误。快速原型验证需要快速验证某个想法时直接组合现有技能不用从零开始写。但以下情况就不太适合一次性任务只做一次的事情封装成本远大于收益直接写就行。高度定制化逻辑如果每个项目的需求差异极大封装出来的技能复用率很低反而增加维护负担。性能极度敏感的场景技能调用会引入一层间接性虽然开销很小但在极端性能要求下可能成为瓶颈。提示判断是否该封装成技能有一个简单的标准——如果你发现自己在不同地方写了三遍以上相似的逻辑那就该封装了。如果只写了一遍先放着等第二次出现时再考虑。3. 核心细节解析与实操要点技能到底长什么样3.1 技能的基本结构一个技能包含哪些部分一个标准的技能通常由四个部分组成元信息、输入定义、处理逻辑、输出定义。这四个部分缺一不可少了任何一个技能就不完整调用时容易出问题。元信息包括技能名称、版本号、描述、作者、依赖项。名称要唯一且见名知意比如“format-json”就比“util-01”好得多。版本号建议遵循语义化版本规范方便后续升级管理。描述要写清楚这个技能干什么、适合什么场景、有什么限制。依赖项列出这个技能运行所需的其他技能或外部库。输入定义描述技能需要哪些参数每个参数的类型、是否必填、默认值、取值范围。这一步很多人会偷懒觉得“我自己知道就行”但一旦要给别人用或者过几个月自己回头看没有清晰的输入定义就会很痛苦。我吃过这个亏后来强制自己每个技能都必须写完整的输入定义。处理逻辑是技能的核心包含具体的执行步骤。这部分可以是一段代码也可以是一系列操作指令。关键是要保证逻辑清晰、边界条件处理完整、错误情况有兜底。输出定义描述技能返回什么结果包括返回值的类型、格式、可能的错误码。输出定义和输入定义一样重要但更容易被忽略。我见过太多技能因为输出格式不统一导致调用方需要写一堆适配代码完全失去了封装的意义。3.2 技能命名规范怎么起名才能一眼看懂命名这件事看起来简单实际上非常影响后续使用体验。我总结了几条实用规则用动词开头技能是“做一件事”的所以名称应该体现动作。比如“parse-config”比“config-parser”更直观“send-notification”比“notification-sender”更清楚。用连字符分隔不要用下划线或驼峰连字符在命令行和文件系统中兼容性最好输入也最方便。控制长度名称不要太长一般控制在两到四个单词之间。太短容易歧义太长记不住。避免缩写除非是行业通用缩写如“json”“http”否则不要自己造缩写。你以为“fmt”是格式化别人可能以为是“format”也可能是“firmware”。保持一致性同一类技能用相同的前缀或后缀。比如所有数据处理技能都以“data-”开头所有通知技能都以“notify-”结尾。我自己的技能列表里命名最差的几个后来都被我重命名了。比如早期有个技能叫“helper”完全不知道干什么用的后来改成“validate-email”才清楚。还有一个叫“do-stuff”现在想起来都觉得好笑。命名花的时间后面会以十倍百倍的效率还回来。3.3 技能引入方式怎么把技能装进你的环境引入技能的方式取决于你使用的具体环境。常见的有三种本地目录引入、包管理器引入、远程仓库引入。本地目录引入最简单把技能文件夹放到指定目录下环境启动时自动扫描加载。这种方式适合自己开发的私有技能修改后立即生效不需要额外操作。缺点是跨机器同步麻烦需要手动拷贝或通过版本控制管理。包管理器引入适合公开分享的技能。把技能发布到包仓库其他人通过包管理器安装。这种方式版本管理清晰依赖自动解析升级方便。缺点是需要维护发布流程对私有技能不太友好。远程仓库引入介于两者之间技能放在远程仓库里通过配置引用。这种方式适合团队内部共享既能集中管理又能保持一定的灵活性。缺点是需要网络连接首次加载可能较慢。我自己的做法是核心通用技能走包管理器团队专用技能走远程仓库个人实验性技能放本地目录。这样既保证了通用能力的稳定性又保留了个人探索的空间。注意不管用哪种引入方式都要确保技能之间的依赖关系被正确解析。如果技能A依赖技能B引入A时必须同时引入B否则运行时会报错。建议在技能的元信息里明确声明依赖引入时自动检查。3.4 技能调用方式怎么触发一个技能调用技能的方式通常有两种命令行调用和代码内调用。命令行调用适合手动执行或脚本编排。基本格式是“技能名称 参数”。比如“format-json --input data.json --indent 2”。这种方式直观、易调试适合交互式使用。代码内调用适合集成到程序流程中。通过导入技能模块调用对应的函数或方法。比如在Python里“from skills import format_json”然后“format_json(data, indent2)”。这种方式灵活、可编程适合自动化流程。两种方式各有优劣实际使用中经常混用。我的习惯是调试阶段用命令行确认没问题后改成代码内调用。这样既能快速验证又能保证最终集成的稳定性。调用时需要注意参数传递的格式。有些技能接受位置参数有些只接受关键字参数有些支持两者。调用前最好看一眼技能的输入定义避免传错格式导致报错。我遇到过好几次因为参数顺序搞反结果输出完全不对的情况排查了半天才发现是调用方式的问题。4. 实操过程与核心环节实现从零搭建一套技能体系4.1 环境准备搭建技能运行的基础环境在开始之前需要先确认基础环境是否就绪。不同技术栈的环境要求不同但核心要素是相似的运行时环境、目录结构、配置文件。运行时环境取决于你用的语言和框架。如果是Python需要Python 3.8以上版本如果是Node.js需要Node 14以上。版本不要太老否则可能缺少必要的语言特性。我建议用版本管理工具如pyenv或nvm来管理运行时版本避免不同项目之间互相干扰。目录结构建议统一规划。我的做法是在项目根目录下建一个“skills”文件夹里面按类别分子目录。比如“skills/data/”放数据处理技能“skills/network/”放网络相关技能“skills/format/”放格式化技能。每个技能一个子目录目录名就是技能名。这种结构清晰直观找起来方便。配置文件通常是一个JSON或YAML文件放在项目根目录下命名为“skills.config.json”或类似。里面配置技能搜索路径、默认参数、启用状态等。配置文件不要写得太复杂保持可读性方便手动修改。{ skillPaths: [./skills, ./shared-skills], defaultTimeout: 30, enabledSkills: [format-json, validate-email, send-notification], logLevel: info }这个配置示例里skillPaths指定了技能搜索路径defaultTimeout设置了默认超时时间enabledSkills列出了启用的技能logLevel控制日志级别。实际使用时可以根据需要增减字段。4.2 创建第一个技能从最简单的开始不要一上来就搞复杂的技能先从最简单的开始跑通整个流程再说。我选的第一个技能是“format-json”功能很简单读取JSON文件格式化后输出。创建技能目录“skills/format/format-json/”在里面新建三个文件skill.json元信息、index.py处理逻辑、README.md说明文档。skill.json内容如下{ name: format-json, version: 1.0.0, description: 读取JSON文件并格式化输出, author: your-name, dependencies: [], inputs: { input: { type: string, required: true, description: 输入文件路径 }, indent: { type: integer, required: false, default: 2, description: 缩进空格数 } }, outputs: { type: string, description: 格式化后的JSON字符串 } }index.py内容如下import json import sys def format_json(input_path, indent2): with open(input_path, r, encodingutf-8) as f: data json.load(f) return json.dumps(data, indentindent, ensure_asciiFalse) if __name__ __main__: input_path sys.argv[1] indent int(sys.argv[2]) if len(sys.argv) 2 else 2 result format_json(input_path, indent) print(result)这个技能虽然简单但包含了完整结构元信息、输入定义、处理逻辑、输出定义。跑通之后再照着这个模板创建其他技能就快了。4.3 技能注册与加载让环境认识你的技能创建完技能文件后需要让环境知道这个技能存在。注册方式取决于你的环境实现。如果是自己写的加载器通常是在启动时扫描技能目录读取每个技能的skill.json注册到技能注册表中。注册表可以是一个内存中的字典键是技能名值是技能对象。加载时遍历skillPaths下的所有子目录找到skill.json就注册。如果技能名重复后加载的覆盖先加载的或者报错提示冲突。我建议报错提示避免意外覆盖。加载时机有两种启动时全量加载和按需懒加载。全量加载启动慢但调用时快懒加载启动快但首次调用有延迟。技能数量少的时候差别不大技能多了之后建议懒加载。我的做法是常用技能全量加载不常用的懒加载。加载完成后可以通过一个“list-skills”命令查看所有已注册的技能。这个命令很实用相当于技能目录随时可以查看有哪些能力可用。我经常用它来提醒自己有哪些技能可以复用避免重复造轮子。4.4 技能组合与编排把多个技能串起来单个技能能力有限真正的威力在于组合。比如一个“处理用户数据”的流程可能需要“读取CSV”“校验字段”“格式化输出”“发送通知”四个技能串联。组合方式有两种脚本编排和流程定义。脚本编排就是写一个脚本按顺序调用各个技能。这种方式灵活适合逻辑复杂的场景。流程定义是用配置文件描述技能之间的依赖关系由执行引擎自动调度。这种方式声明式适合标准化流程。我通常先用脚本编排跑通流程确认没问题后再考虑是否转成流程定义。因为脚本编排调试方便改起来快流程定义虽然优雅但调试麻烦改一行要重新加载整个流程。组合时要注意技能之间的数据传递。上一个技能的输出格式必须匹配下一个技能的输入要求。如果格式不一致需要加一个转换步骤。我吃过这个亏两个技能单独跑都没问题串起来就报错排查半天发现是输出格式差了一个字段名。提示技能组合时建议在每个步骤之间加日志输出记录输入和输出。这样出问题时能快速定位是哪个环节出的错。日志不用太详细记录关键字段就行。4.5 技能版本管理与升级怎么保证不破坏现有流程技能一旦被多个流程引用升级就要谨慎。直接改现有技能可能导致依赖它的流程崩溃。我的做法是遵循语义化版本并且保留旧版本一段时间。具体来说修改技能时如果是修bug版本号加patch位如1.0.0到1.0.1如果是加功能但兼容旧用法加minor位如1.0.0到1.1.0如果是不兼容的改动加major位如1.0.0到2.0.0。major升级时旧版本保留在目录里新流程用新版本旧流程继续用旧版本等所有流程都迁移完再删除旧版本。这种策略虽然看起来麻烦但能避免“升级一个技能崩掉十个流程”的惨剧。我早期没注意这个问题直接改了一个常用技能的输出格式结果三个项目同时报错花了半天才修复。从那以后我就严格按版本管理来了。5. 常见问题与排查技巧实录我踩过的坑和解决方案5.1 技能加载失败为什么环境找不到我的技能这是最常见的问题表现是调用技能时提示“skill not found”。原因通常有三个路径不对、文件缺失、权限问题。路径不对是最常见的。检查skillPaths配置是否正确技能目录是否在搜索路径下。注意相对路径和绝对路径的区别相对路径是相对于当前工作目录不是相对于配置文件。我建议统一用绝对路径避免歧义。文件缺失也经常发生。检查技能目录下是否有skill.json文件名大小写是否正确。有些系统区分大小写Skill.json和skill.json是不同的文件。另外检查skill.json格式是否合法用JSON校验工具验证一下。权限问题在Linux和macOS上比较常见。检查技能目录和文件的读权限确保运行环境的用户有权限访问。如果是Docker环境还要检查挂载路径是否正确。排查步骤可以按这个顺序来先确认路径存在再确认文件存在再确认格式合法最后确认权限足够。大部分问题在前两步就能定位。5.2 技能执行报错参数传对了为什么还出错参数传对了但执行报错通常是因为环境依赖缺失或版本不匹配。技能可能依赖某个外部库但环境里没装或者装的是不兼容的版本。排查方法是先看错误信息通常会提示缺少哪个模块或哪个函数不存在。然后检查技能的依赖声明确认所有依赖都已安装。如果依赖已安装但版本不对用包管理器查看实际版本和技能要求的版本对比。还有一种情况是运行时环境差异。比如技能在Python 3.9上开发但运行环境是Python 3.7某些语法或库特性不支持。这种情况下要么升级运行环境要么修改技能代码兼容旧版本。我遇到过一次比较隐蔽的问题技能在本地跑得好好的部署到服务器就报错。排查后发现是服务器上的时区设置不同导致时间相关的逻辑出错。这种问题不看日志根本想不到所以日志一定要记录足够的信息包括环境变量、时区、编码等。5.3 技能输出不符合预期结果不对但没报错这种问题最让人头疼因为没有任何错误提示但结果就是不对。常见原因有输入数据格式变化、边界条件未处理、逻辑分支遗漏。输入数据格式变化是最常见的。比如上游技能改了输出格式下游技能没跟着改结果解析出错但没抛异常只是返回了错误的结果。解决方法是在技能入口处加数据校验格式不对直接报错不要静默处理。边界条件未处理也很常见。比如空输入、超长输入、特殊字符输入这些情况如果没考虑就可能产生意外结果。我的习惯是每个技能都加边界测试至少测空值、极值、异常值三种情况。逻辑分支遗漏通常是因为需求变化后没同步更新。比如原来只处理两种类型后来加了第三种但技能代码没改。解决方法是定期review技能逻辑对照最新需求检查是否有遗漏。5.4 技能性能问题为什么执行越来越慢技能执行变慢通常有三个原因数据量增长、依赖服务变慢、资源泄漏。数据量增长是正常现象但如果增长到影响体验就需要优化。优化方向包括加缓存、分批处理、并行执行。加缓存适合重复计算多的场景分批处理适合大数据量场景并行执行适合独立任务多的场景。依赖服务变慢需要排查外部服务。比如技能依赖某个APIAPI响应变慢导致技能整体变慢。这种情况下要么加超时和重试机制要么找替代方案。资源泄漏比较隐蔽通常是文件句柄或数据库连接没释放。表现是技能刚开始跑得快跑一段时间后越来越慢。解决方法是确保所有资源在使用后都被释放用try-finally或上下文管理器来管理。5.5 常见问题速查表问题现象可能原因排查方法解决方案提示skill not found路径错误、文件缺失、权限不足检查路径、文件、权限修正路径、补全文件、调整权限执行报错缺少模块依赖未安装或版本不匹配检查依赖声明和实际版本安装依赖、升级或降级版本输出结果不对但无报错输入格式变化、边界未处理加数据校验、加边界测试修正格式、补充边界逻辑执行越来越慢数据量增长、资源泄漏监控数据量和资源使用加缓存、分批、释放资源技能之间数据传递失败输出输入格式不匹配对比上下游格式定义加转换步骤或统一格式5.6 独家避坑技巧那些文档里不会写的东西技巧一技能不要做得太“聪明”。我早期喜欢把技能做得功能很全一个技能处理多种情况。结果发现调用方很难用因为不知道当前情况会走哪个分支。后来改成“一个技能只做一件事”调用方自己判断用哪个技能反而更清晰。技巧二技能名称里不要带版本号。有人喜欢把版本号写在技能名里比如“format-json-v2”。这样做的后果是升级时所有调用方都要改名字。正确做法是技能名不变版本号放在元信息里通过配置或参数指定用哪个版本。技巧三技能文档要写“不做什么”。大部分文档只写技能能做什么但“不做什么”同样重要。比如“format-json”不支持XML输入这个信息如果不写调用方可能传XML进来然后报错。明确边界能减少很多沟通成本。技巧四技能测试要覆盖异常路径。正常路径的测试大家都会写但异常路径的测试经常被忽略。比如输入文件不存在、输入格式错误、网络超时等情况这些才是最容易出问题的地方。我的做法是每个技能至少写三个异常测试用例。技巧五技能日志要带上下文。光记录“执行失败”没用要记录“哪个技能、什么参数、什么时间、什么环境”下失败。这样排查时才能快速定位。我习惯在日志里加一个trace ID串联整个流程的所有步骤出问题时能一路追下去。6. 技能体系的扩展与维护怎么让它持续好用6.1 技能库的定期清理与重构技能库用久了会积累很多“僵尸技能”——没人调用、功能重复、已经过时。这些技能不清理会拖慢加载速度增加维护负担还会让技能列表变得混乱。我的做法是每季度做一次技能审计。审计内容包括统计每个技能的调用次数、检查是否有功能重复的技能、确认是否有技能依赖已废弃的库。调用次数为零的技能标记为“待观察”连续两个季度为零的直接归档或删除。功能重复的技能合并成一个依赖废弃库的技能要么升级依赖要么替换实现。审计时还要检查技能的文档是否更新。很多技能代码改了但文档没改导致文档和实际行为不一致。这种问题比没有文档更糟糕因为会误导使用者。我的习惯是改代码时必须同步改文档把这条写进技能开发的检查清单里。6.2 技能共享与团队协作团队里共享技能最大的挑战不是技术而是约定和沟通。每个人对技能的理解不同命名习惯不同质量要求不同如果不统一共享出来的技能反而增加混乱。我的经验是制定一份技能开发规范内容包括命名规则、目录结构、元信息格式、文档模板、测试要求。规范不用太长一页纸就够但必须强制执行。新技能提交时按规范逐项检查不符合的退回修改。共享方式建议用内部仓库加版本管理。技能放在内部仓库里通过版本号管理变更。团队成员按需引入引入时指定版本号避免自动升级带来的意外。如果某个技能需要修改走正常的代码审查流程确保改动经过审核。沟通方面建议建一个技能变更通知渠道。技能有重大变更时在渠道里通知所有使用者说明变更内容、影响范围、迁移建议。这样使用者能提前准备避免突然崩溃。6.3 技能体系的长期演进思路技能体系不是一成不变的需要随着需求变化而演进。演进方向通常有三个从少到多、从粗到细、从散到合。从少到多是指技能数量增长。初期可能只有几个技能随着使用深入会发现更多可以封装的场景技能数量自然增长。这个阶段要注意控制质量不要为了数量而数量。从粗到细是指技能粒度变细。初期技能可能比较粗一个技能干好几件事。用久了会发现某些部分经常单独使用这时候就该拆成更细的技能。拆分的标准是“是否经常单独使用”如果是就拆。从散到合是指技能之间形成体系。初期技能之间可能没什么关联各自独立。随着数量增多会发现某些技能经常一起使用这时候可以考虑把它们组织成一个“技能组”或“技能包”提供更高层的抽象。我自己的技能体系经历了这三个阶段。最开始只有五六个技能后来增长到三十多个然后拆分成更细的五十多个最后合并成几个技能组。这个过程不是刻意设计的而是随着使用自然演进的。关键是保持观察发现模式后及时调整。6.4 技能体系的监控与度量要让技能体系持续好用需要一些基本的监控和度量。我关注的核心指标有三个调用成功率、平均执行时间、复用率。调用成功率反映技能稳定性。如果某个技能成功率明显低于其他说明有问题需要排查。我设置了一个阈值低于95%成功率的技能会触发告警提醒我去检查。平均执行时间反映技能性能。如果某个技能执行时间突然变长可能是数据量增长或依赖服务变慢。我会定期看这个指标发现异常及时优化。复用率反映技能价值。如果某个技能只有一个人用可能是个性化需求如果很多人用说明是通用能力。复用率高的技能优先维护复用率低的考虑归档。这些指标不需要很复杂的监控系统简单的日志统计就够了。我一开始用脚本每天统计一次后来改成实时统计但核心逻辑没变。关键是持续关注而不是收集了数据却不看。7. 我个人的实操体会与建议这套技能体系我用了一年多最大的感受是前期投入的时间后面会加倍还回来。刚开始封装技能时觉得麻烦觉得直接写更快。但用了三个月后新项目启动时直接组合现有技能半天就能搭出原型而以前至少要两三天。这种效率提升是实实在在的。另一个体会是不要追求完美先跑起来再说。我早期总想把技能设计得很完美结果花了很多时间在纠结命名、结构、接口上实际写出来的技能却没几个。后来改变策略先写一个能用的版本用起来之后再迭代优化。事实证明很多设计问题只有在使用中才会暴露空想是想不出来的。还有一点技能文档比技能代码更重要。代码写得好但没文档别人不知道怎么用等于白写。文档写得好但代码一般别人至少能用起来后续再优化。我的做法是文档先行先写清楚这个技能干什么、怎么用、有什么限制然后再写代码实现。最后分享一个小技巧给技能加一个“试运行”模式。调用时加一个参数技能只输出将要执行的操作不实际执行。这个模式在调试组合流程时特别有用能快速确认每一步的输入输出是否符合预期避免实际执行后才发现问题。我几乎所有技能都加了这个模式用起来非常顺手。这套体系还在持续演进中后面可能会加入更多自动化能力比如自动检测可封装的重复逻辑、自动生成技能文档、自动推荐技能组合。但核心思路不会变把能力单元化按需组合持续维护。只要这个思路在具体实现方式可以灵活调整。 
长河君 · 2026/10/15 13:34:59 · 阅读 1.2k Superpowers技能体系实战：从零搭建可复用的技能调用机制
1. 从“superpowers”这个标题说起它到底是什么为什么突然火了第一次看到“superpowers”这个词是在一个开发者社群里。有人发了一张截图里面列了一长串以“superpowers”开头的技能名称底下配文是“装上这个感觉自己的工具链突然多了十几个外挂”。当时我的第一反应是又是一个营销概念吧但点进去仔细看完之后我改变了看法。“superpowers”本质上是一套技能skills集合与调用机制。它不是某个具体的软件也不是某个单一的库而是一种把零散能力打包成可复用模块的思路。你可以把它理解成一个“技能仓库”——里面存放着各种预先定义好的能力单元每个单元负责一件事比如代码审查、文档生成、数据处理、自动化测试等等。当你需要某个能力时不需要从头写直接引入对应的技能就行。这个词之所以在近期被频繁搜索核心原因有三个。第一工具链碎片化已经到了让人头疼的地步每个人手里都有一堆脚本、配置、小工具但彼此之间没有统一的组织方式用的时候找不到找到了又忘了怎么用。第二复用成本太高同一个功能在不同项目里反复实现浪费了大量时间。第三“superpowers”提供了一种轻量级的组织方案不需要大动干戈重构就能把现有能力串起来。这篇文章适合谁看如果你手里有一堆零散脚本不知道怎么管理如果你经常在不同项目之间复制粘贴同样的代码如果你听说过“skills”但不知道从哪下手那这篇内容就是为你准备的。我会从整体设计思路讲起然后拆解核心细节接着给出完整的实操过程最后把我踩过的坑和排查技巧一并分享出来。全程不绕弯子直接说人话。2. 整体设计与思路拆解为什么是“技能”而不是“工具”2.1 核心思路把能力单元化而不是把工具集中化很多人第一次接触“superpowers”时会下意识地把它当成一个“工具箱”——以为装上一个东西所有功能就都有了。但实际用下来会发现它的设计哲学恰恰相反它不是把工具集中到一起而是把能力拆成独立的单元。这两者的区别很关键。工具箱的思路是“我有一把瑞士军刀什么都能干”但问题是刀片越多单个刀片就越薄用起来反而别扭。而技能单元的思路是“我有一排专用工具每个只干一件事但干得特别好”。当你需要拧螺丝时拿螺丝刀需要剪线时拿剪线钳。每个技能都是独立的可以单独引入、单独替换、单独升级。这种设计带来的最大好处是组合自由。你可以根据项目需要只引入相关的技能不会被迫接受一堆用不上的东西。比如你只做数据处理那就只引入数据相关的技能你只做前端开发那就只引入前端相关的技能。每个技能之间通过标准接口通信互不干扰。另一个好处是维护成本低。如果某个技能出了问题你只需要修那一个不会影响其他技能。如果某个技能过时了直接替换掉就行不需要动整个系统。这种“高内聚、低耦合”的思路在软件工程里是老生常谈但真正落实到日常工具管理上能做到的人并不多。2.2 方案选型为什么不用插件体系或宏系统你可能会问插件体系和宏系统也能实现类似效果为什么非要搞一套“技能”机制这个问题我当初也想过后来实际对比之后发现差异主要在三个方面。第一插件体系通常绑定特定宿主。比如某个编辑器的插件只能在这个编辑器里用换个环境就废了。而技能是宿主无关的只要环境支持标准调用方式就能用。这意味着你可以在命令行里用也可以在脚本里用还可以在自动化流程里用。第二宏系统偏向代码生成适合处理重复性代码模式但不适合封装完整的工作流程。一个技能可以包含多个步骤、多个判断、多个输出而宏通常只做文本替换或简单展开。技能更像是一个“小函数”有输入、有处理、有输出逻辑可以很复杂。第三技能的可发现性更好。插件和宏通常藏在配置文件或代码注释里新人来了根本不知道有哪些可用。而技能有统一的命名规范和目录结构看一眼就知道有哪些能力可用每个能力叫什么、干什么用。这种“自描述”特性对团队协作来说非常重要。我自己的选型逻辑很简单如果一件事需要重复做三次以上就把它封装成技能。这个阈值不是拍脑袋定的而是根据实际经验来的。做一次两次直接手写更快做三次以上封装带来的收益就开始超过成本了。而且封装之后下次再遇到类似需求直接调用就行不用重新想逻辑。2.3 适用场景与边界什么情况下该用什么情况下不该用“superpowers”不是银弹它有明确的适用场景。根据我的使用经验以下情况特别适合多项目并行开发不同项目之间有很多共通能力比如日志处理、配置读取、数据校验。把这些封装成技能每个项目按需引入避免重复实现。团队协作新人入职时不需要逐个了解每个脚本的用法直接看技能列表就知道有哪些能力可用学习成本大幅降低。自动化流程把多个步骤串成一个技能一键执行减少手动操作带来的错误。快速原型验证需要快速验证某个想法时直接组合现有技能不用从零开始写。但以下情况就不太适合一次性任务只做一次的事情封装成本远大于收益直接写就行。高度定制化逻辑如果每个项目的需求差异极大封装出来的技能复用率很低反而增加维护负担。性能极度敏感的场景技能调用会引入一层间接性虽然开销很小但在极端性能要求下可能成为瓶颈。提示判断是否该封装成技能有一个简单的标准——如果你发现自己在不同地方写了三遍以上相似的逻辑那就该封装了。如果只写了一遍先放着等第二次出现时再考虑。3. 核心细节解析与实操要点技能到底长什么样3.1 技能的基本结构一个技能包含哪些部分一个标准的技能通常由四个部分组成元信息、输入定义、处理逻辑、输出定义。这四个部分缺一不可少了任何一个技能就不完整调用时容易出问题。元信息包括技能名称、版本号、描述、作者、依赖项。名称要唯一且见名知意比如“format-json”就比“util-01”好得多。版本号建议遵循语义化版本规范方便后续升级管理。描述要写清楚这个技能干什么、适合什么场景、有什么限制。依赖项列出这个技能运行所需的其他技能或外部库。输入定义描述技能需要哪些参数每个参数的类型、是否必填、默认值、取值范围。这一步很多人会偷懒觉得“我自己知道就行”但一旦要给别人用或者过几个月自己回头看没有清晰的输入定义就会很痛苦。我吃过这个亏后来强制自己每个技能都必须写完整的输入定义。处理逻辑是技能的核心包含具体的执行步骤。这部分可以是一段代码也可以是一系列操作指令。关键是要保证逻辑清晰、边界条件处理完整、错误情况有兜底。输出定义描述技能返回什么结果包括返回值的类型、格式、可能的错误码。输出定义和输入定义一样重要但更容易被忽略。我见过太多技能因为输出格式不统一导致调用方需要写一堆适配代码完全失去了封装的意义。3.2 技能命名规范怎么起名才能一眼看懂命名这件事看起来简单实际上非常影响后续使用体验。我总结了几条实用规则用动词开头技能是“做一件事”的所以名称应该体现动作。比如“parse-config”比“config-parser”更直观“send-notification”比“notification-sender”更清楚。用连字符分隔不要用下划线或驼峰连字符在命令行和文件系统中兼容性最好输入也最方便。控制长度名称不要太长一般控制在两到四个单词之间。太短容易歧义太长记不住。避免缩写除非是行业通用缩写如“json”“http”否则不要自己造缩写。你以为“fmt”是格式化别人可能以为是“format”也可能是“firmware”。保持一致性同一类技能用相同的前缀或后缀。比如所有数据处理技能都以“data-”开头所有通知技能都以“notify-”结尾。我自己的技能列表里命名最差的几个后来都被我重命名了。比如早期有个技能叫“helper”完全不知道干什么用的后来改成“validate-email”才清楚。还有一个叫“do-stuff”现在想起来都觉得好笑。命名花的时间后面会以十倍百倍的效率还回来。3.3 技能引入方式怎么把技能装进你的环境引入技能的方式取决于你使用的具体环境。常见的有三种本地目录引入、包管理器引入、远程仓库引入。本地目录引入最简单把技能文件夹放到指定目录下环境启动时自动扫描加载。这种方式适合自己开发的私有技能修改后立即生效不需要额外操作。缺点是跨机器同步麻烦需要手动拷贝或通过版本控制管理。包管理器引入适合公开分享的技能。把技能发布到包仓库其他人通过包管理器安装。这种方式版本管理清晰依赖自动解析升级方便。缺点是需要维护发布流程对私有技能不太友好。远程仓库引入介于两者之间技能放在远程仓库里通过配置引用。这种方式适合团队内部共享既能集中管理又能保持一定的灵活性。缺点是需要网络连接首次加载可能较慢。我自己的做法是核心通用技能走包管理器团队专用技能走远程仓库个人实验性技能放本地目录。这样既保证了通用能力的稳定性又保留了个人探索的空间。注意不管用哪种引入方式都要确保技能之间的依赖关系被正确解析。如果技能A依赖技能B引入A时必须同时引入B否则运行时会报错。建议在技能的元信息里明确声明依赖引入时自动检查。3.4 技能调用方式怎么触发一个技能调用技能的方式通常有两种命令行调用和代码内调用。命令行调用适合手动执行或脚本编排。基本格式是“技能名称 参数”。比如“format-json --input data.json --indent 2”。这种方式直观、易调试适合交互式使用。代码内调用适合集成到程序流程中。通过导入技能模块调用对应的函数或方法。比如在Python里“from skills import format_json”然后“format_json(data, indent2)”。这种方式灵活、可编程适合自动化流程。两种方式各有优劣实际使用中经常混用。我的习惯是调试阶段用命令行确认没问题后改成代码内调用。这样既能快速验证又能保证最终集成的稳定性。调用时需要注意参数传递的格式。有些技能接受位置参数有些只接受关键字参数有些支持两者。调用前最好看一眼技能的输入定义避免传错格式导致报错。我遇到过好几次因为参数顺序搞反结果输出完全不对的情况排查了半天才发现是调用方式的问题。4. 实操过程与核心环节实现从零搭建一套技能体系4.1 环境准备搭建技能运行的基础环境在开始之前需要先确认基础环境是否就绪。不同技术栈的环境要求不同但核心要素是相似的运行时环境、目录结构、配置文件。运行时环境取决于你用的语言和框架。如果是Python需要Python 3.8以上版本如果是Node.js需要Node 14以上。版本不要太老否则可能缺少必要的语言特性。我建议用版本管理工具如pyenv或nvm来管理运行时版本避免不同项目之间互相干扰。目录结构建议统一规划。我的做法是在项目根目录下建一个“skills”文件夹里面按类别分子目录。比如“skills/data/”放数据处理技能“skills/network/”放网络相关技能“skills/format/”放格式化技能。每个技能一个子目录目录名就是技能名。这种结构清晰直观找起来方便。配置文件通常是一个JSON或YAML文件放在项目根目录下命名为“skills.config.json”或类似。里面配置技能搜索路径、默认参数、启用状态等。配置文件不要写得太复杂保持可读性方便手动修改。{ skillPaths: [./skills, ./shared-skills], defaultTimeout: 30, enabledSkills: [format-json, validate-email, send-notification], logLevel: info }这个配置示例里skillPaths指定了技能搜索路径defaultTimeout设置了默认超时时间enabledSkills列出了启用的技能logLevel控制日志级别。实际使用时可以根据需要增减字段。4.2 创建第一个技能从最简单的开始不要一上来就搞复杂的技能先从最简单的开始跑通整个流程再说。我选的第一个技能是“format-json”功能很简单读取JSON文件格式化后输出。创建技能目录“skills/format/format-json/”在里面新建三个文件skill.json元信息、index.py处理逻辑、README.md说明文档。skill.json内容如下{ name: format-json, version: 1.0.0, description: 读取JSON文件并格式化输出, author: your-name, dependencies: [], inputs: { input: { type: string, required: true, description: 输入文件路径 }, indent: { type: integer, required: false, default: 2, description: 缩进空格数 } }, outputs: { type: string, description: 格式化后的JSON字符串 } }index.py内容如下import json import sys def format_json(input_path, indent2): with open(input_path, r, encodingutf-8) as f: data json.load(f) return json.dumps(data, indentindent, ensure_asciiFalse) if __name__ __main__: input_path sys.argv[1] indent int(sys.argv[2]) if len(sys.argv) 2 else 2 result format_json(input_path, indent) print(result)这个技能虽然简单但包含了完整结构元信息、输入定义、处理逻辑、输出定义。跑通之后再照着这个模板创建其他技能就快了。4.3 技能注册与加载让环境认识你的技能创建完技能文件后需要让环境知道这个技能存在。注册方式取决于你的环境实现。如果是自己写的加载器通常是在启动时扫描技能目录读取每个技能的skill.json注册到技能注册表中。注册表可以是一个内存中的字典键是技能名值是技能对象。加载时遍历skillPaths下的所有子目录找到skill.json就注册。如果技能名重复后加载的覆盖先加载的或者报错提示冲突。我建议报错提示避免意外覆盖。加载时机有两种启动时全量加载和按需懒加载。全量加载启动慢但调用时快懒加载启动快但首次调用有延迟。技能数量少的时候差别不大技能多了之后建议懒加载。我的做法是常用技能全量加载不常用的懒加载。加载完成后可以通过一个“list-skills”命令查看所有已注册的技能。这个命令很实用相当于技能目录随时可以查看有哪些能力可用。我经常用它来提醒自己有哪些技能可以复用避免重复造轮子。4.4 技能组合与编排把多个技能串起来单个技能能力有限真正的威力在于组合。比如一个“处理用户数据”的流程可能需要“读取CSV”“校验字段”“格式化输出”“发送通知”四个技能串联。组合方式有两种脚本编排和流程定义。脚本编排就是写一个脚本按顺序调用各个技能。这种方式灵活适合逻辑复杂的场景。流程定义是用配置文件描述技能之间的依赖关系由执行引擎自动调度。这种方式声明式适合标准化流程。我通常先用脚本编排跑通流程确认没问题后再考虑是否转成流程定义。因为脚本编排调试方便改起来快流程定义虽然优雅但调试麻烦改一行要重新加载整个流程。组合时要注意技能之间的数据传递。上一个技能的输出格式必须匹配下一个技能的输入要求。如果格式不一致需要加一个转换步骤。我吃过这个亏两个技能单独跑都没问题串起来就报错排查半天发现是输出格式差了一个字段名。提示技能组合时建议在每个步骤之间加日志输出记录输入和输出。这样出问题时能快速定位是哪个环节出的错。日志不用太详细记录关键字段就行。4.5 技能版本管理与升级怎么保证不破坏现有流程技能一旦被多个流程引用升级就要谨慎。直接改现有技能可能导致依赖它的流程崩溃。我的做法是遵循语义化版本并且保留旧版本一段时间。具体来说修改技能时如果是修bug版本号加patch位如1.0.0到1.0.1如果是加功能但兼容旧用法加minor位如1.0.0到1.1.0如果是不兼容的改动加major位如1.0.0到2.0.0。major升级时旧版本保留在目录里新流程用新版本旧流程继续用旧版本等所有流程都迁移完再删除旧版本。这种策略虽然看起来麻烦但能避免“升级一个技能崩掉十个流程”的惨剧。我早期没注意这个问题直接改了一个常用技能的输出格式结果三个项目同时报错花了半天才修复。从那以后我就严格按版本管理来了。5. 常见问题与排查技巧实录我踩过的坑和解决方案5.1 技能加载失败为什么环境找不到我的技能这是最常见的问题表现是调用技能时提示“skill not found”。原因通常有三个路径不对、文件缺失、权限问题。路径不对是最常见的。检查skillPaths配置是否正确技能目录是否在搜索路径下。注意相对路径和绝对路径的区别相对路径是相对于当前工作目录不是相对于配置文件。我建议统一用绝对路径避免歧义。文件缺失也经常发生。检查技能目录下是否有skill.json文件名大小写是否正确。有些系统区分大小写Skill.json和skill.json是不同的文件。另外检查skill.json格式是否合法用JSON校验工具验证一下。权限问题在Linux和macOS上比较常见。检查技能目录和文件的读权限确保运行环境的用户有权限访问。如果是Docker环境还要检查挂载路径是否正确。排查步骤可以按这个顺序来先确认路径存在再确认文件存在再确认格式合法最后确认权限足够。大部分问题在前两步就能定位。5.2 技能执行报错参数传对了为什么还出错参数传对了但执行报错通常是因为环境依赖缺失或版本不匹配。技能可能依赖某个外部库但环境里没装或者装的是不兼容的版本。排查方法是先看错误信息通常会提示缺少哪个模块或哪个函数不存在。然后检查技能的依赖声明确认所有依赖都已安装。如果依赖已安装但版本不对用包管理器查看实际版本和技能要求的版本对比。还有一种情况是运行时环境差异。比如技能在Python 3.9上开发但运行环境是Python 3.7某些语法或库特性不支持。这种情况下要么升级运行环境要么修改技能代码兼容旧版本。我遇到过一次比较隐蔽的问题技能在本地跑得好好的部署到服务器就报错。排查后发现是服务器上的时区设置不同导致时间相关的逻辑出错。这种问题不看日志根本想不到所以日志一定要记录足够的信息包括环境变量、时区、编码等。5.3 技能输出不符合预期结果不对但没报错这种问题最让人头疼因为没有任何错误提示但结果就是不对。常见原因有输入数据格式变化、边界条件未处理、逻辑分支遗漏。输入数据格式变化是最常见的。比如上游技能改了输出格式下游技能没跟着改结果解析出错但没抛异常只是返回了错误的结果。解决方法是在技能入口处加数据校验格式不对直接报错不要静默处理。边界条件未处理也很常见。比如空输入、超长输入、特殊字符输入这些情况如果没考虑就可能产生意外结果。我的习惯是每个技能都加边界测试至少测空值、极值、异常值三种情况。逻辑分支遗漏通常是因为需求变化后没同步更新。比如原来只处理两种类型后来加了第三种但技能代码没改。解决方法是定期review技能逻辑对照最新需求检查是否有遗漏。5.4 技能性能问题为什么执行越来越慢技能执行变慢通常有三个原因数据量增长、依赖服务变慢、资源泄漏。数据量增长是正常现象但如果增长到影响体验就需要优化。优化方向包括加缓存、分批处理、并行执行。加缓存适合重复计算多的场景分批处理适合大数据量场景并行执行适合独立任务多的场景。依赖服务变慢需要排查外部服务。比如技能依赖某个APIAPI响应变慢导致技能整体变慢。这种情况下要么加超时和重试机制要么找替代方案。资源泄漏比较隐蔽通常是文件句柄或数据库连接没释放。表现是技能刚开始跑得快跑一段时间后越来越慢。解决方法是确保所有资源在使用后都被释放用try-finally或上下文管理器来管理。5.5 常见问题速查表问题现象可能原因排查方法解决方案提示skill not found路径错误、文件缺失、权限不足检查路径、文件、权限修正路径、补全文件、调整权限执行报错缺少模块依赖未安装或版本不匹配检查依赖声明和实际版本安装依赖、升级或降级版本输出结果不对但无报错输入格式变化、边界未处理加数据校验、加边界测试修正格式、补充边界逻辑执行越来越慢数据量增长、资源泄漏监控数据量和资源使用加缓存、分批、释放资源技能之间数据传递失败输出输入格式不匹配对比上下游格式定义加转换步骤或统一格式5.6 独家避坑技巧那些文档里不会写的东西技巧一技能不要做得太“聪明”。我早期喜欢把技能做得功能很全一个技能处理多种情况。结果发现调用方很难用因为不知道当前情况会走哪个分支。后来改成“一个技能只做一件事”调用方自己判断用哪个技能反而更清晰。技巧二技能名称里不要带版本号。有人喜欢把版本号写在技能名里比如“format-json-v2”。这样做的后果是升级时所有调用方都要改名字。正确做法是技能名不变版本号放在元信息里通过配置或参数指定用哪个版本。技巧三技能文档要写“不做什么”。大部分文档只写技能能做什么但“不做什么”同样重要。比如“format-json”不支持XML输入这个信息如果不写调用方可能传XML进来然后报错。明确边界能减少很多沟通成本。技巧四技能测试要覆盖异常路径。正常路径的测试大家都会写但异常路径的测试经常被忽略。比如输入文件不存在、输入格式错误、网络超时等情况这些才是最容易出问题的地方。我的做法是每个技能至少写三个异常测试用例。技巧五技能日志要带上下文。光记录“执行失败”没用要记录“哪个技能、什么参数、什么时间、什么环境”下失败。这样排查时才能快速定位。我习惯在日志里加一个trace ID串联整个流程的所有步骤出问题时能一路追下去。6. 技能体系的扩展与维护怎么让它持续好用6.1 技能库的定期清理与重构技能库用久了会积累很多“僵尸技能”——没人调用、功能重复、已经过时。这些技能不清理会拖慢加载速度增加维护负担还会让技能列表变得混乱。我的做法是每季度做一次技能审计。审计内容包括统计每个技能的调用次数、检查是否有功能重复的技能、确认是否有技能依赖已废弃的库。调用次数为零的技能标记为“待观察”连续两个季度为零的直接归档或删除。功能重复的技能合并成一个依赖废弃库的技能要么升级依赖要么替换实现。审计时还要检查技能的文档是否更新。很多技能代码改了但文档没改导致文档和实际行为不一致。这种问题比没有文档更糟糕因为会误导使用者。我的习惯是改代码时必须同步改文档把这条写进技能开发的检查清单里。6.2 技能共享与团队协作团队里共享技能最大的挑战不是技术而是约定和沟通。每个人对技能的理解不同命名习惯不同质量要求不同如果不统一共享出来的技能反而增加混乱。我的经验是制定一份技能开发规范内容包括命名规则、目录结构、元信息格式、文档模板、测试要求。规范不用太长一页纸就够但必须强制执行。新技能提交时按规范逐项检查不符合的退回修改。共享方式建议用内部仓库加版本管理。技能放在内部仓库里通过版本号管理变更。团队成员按需引入引入时指定版本号避免自动升级带来的意外。如果某个技能需要修改走正常的代码审查流程确保改动经过审核。沟通方面建议建一个技能变更通知渠道。技能有重大变更时在渠道里通知所有使用者说明变更内容、影响范围、迁移建议。这样使用者能提前准备避免突然崩溃。6.3 技能体系的长期演进思路技能体系不是一成不变的需要随着需求变化而演进。演进方向通常有三个从少到多、从粗到细、从散到合。从少到多是指技能数量增长。初期可能只有几个技能随着使用深入会发现更多可以封装的场景技能数量自然增长。这个阶段要注意控制质量不要为了数量而数量。从粗到细是指技能粒度变细。初期技能可能比较粗一个技能干好几件事。用久了会发现某些部分经常单独使用这时候就该拆成更细的技能。拆分的标准是“是否经常单独使用”如果是就拆。从散到合是指技能之间形成体系。初期技能之间可能没什么关联各自独立。随着数量增多会发现某些技能经常一起使用这时候可以考虑把它们组织成一个“技能组”或“技能包”提供更高层的抽象。我自己的技能体系经历了这三个阶段。最开始只有五六个技能后来增长到三十多个然后拆分成更细的五十多个最后合并成几个技能组。这个过程不是刻意设计的而是随着使用自然演进的。关键是保持观察发现模式后及时调整。6.4 技能体系的监控与度量要让技能体系持续好用需要一些基本的监控和度量。我关注的核心指标有三个调用成功率、平均执行时间、复用率。调用成功率反映技能稳定性。如果某个技能成功率明显低于其他说明有问题需要排查。我设置了一个阈值低于95%成功率的技能会触发告警提醒我去检查。平均执行时间反映技能性能。如果某个技能执行时间突然变长可能是数据量增长或依赖服务变慢。我会定期看这个指标发现异常及时优化。复用率反映技能价值。如果某个技能只有一个人用可能是个性化需求如果很多人用说明是通用能力。复用率高的技能优先维护复用率低的考虑归档。这些指标不需要很复杂的监控系统简单的日志统计就够了。我一开始用脚本每天统计一次后来改成实时统计但核心逻辑没变。关键是持续关注而不是收集了数据却不看。7. 我个人的实操体会与建议这套技能体系我用了一年多最大的感受是前期投入的时间后面会加倍还回来。刚开始封装技能时觉得麻烦觉得直接写更快。但用了三个月后新项目启动时直接组合现有技能半天就能搭出原型而以前至少要两三天。这种效率提升是实实在在的。另一个体会是不要追求完美先跑起来再说。我早期总想把技能设计得很完美结果花了很多时间在纠结命名、结构、接口上实际写出来的技能却没几个。后来改变策略先写一个能用的版本用起来之后再迭代优化。事实证明很多设计问题只有在使用中才会暴露空想是想不出来的。还有一点技能文档比技能代码更重要。代码写得好但没文档别人不知道怎么用等于白写。文档写得好但代码一般别人至少能用起来后续再优化。我的做法是文档先行先写清楚这个技能干什么、怎么用、有什么限制然后再写代码实现。最后分享一个小技巧给技能加一个“试运行”模式。调用时加一个参数技能只输出将要执行的操作不实际执行。这个模式在调试组合流程时特别有用能快速确认每一步的输入输出是否符合预期避免实际执行后才发现问题。我几乎所有技能都加了这个模式用起来非常顺手。这套体系还在持续演进中后面可能会加入更多自动化能力比如自动检测可封装的重复逻辑、自动生成技能文档、自动推荐技能组合。但核心思路不会变把能力单元化按需组合持续维护。只要这个思路在具体实现方式可以灵活调整。