★ FEATURED ARTICLE 1. 从“superpowers”这个热词说起它到底指什么最近一段时间“superpowers”这个词在技术社区和效率工具圈子里被反复提及很多人第一次看到它的时候会以为是某个超级英雄题材的游戏或者影视衍生品但实际上它在当下的语境里指的是一套围绕 AI 编程助手构建的技能扩展体系。简单来说它让原本只会“聊天”的 AI 助手变成能够按照预设流程、调用特定技能、完成复杂工程任务的“超级助手”。这个概念的流行本质上反映了大家对 AI 工具的一个共同诉求我不想每次都从头解释我要干什么我希望它自带一套“肌肉记忆”知道在什么场景下该用什么招式。“superpowers”这个词本身是“超级能力”的意思放在这个语境下非常贴切。它不是一个单独的软件也不是一个插件市场而更像是一套技能包的组织规范。你可以把它理解成给 AI 助手装上了一本“武功秘籍”里面分门别类地写好了各种招式的使用条件、操作步骤和注意事项。当你的需求触发某个条件时助手就会自动翻到那一页按照秘籍上的流程来执行。这就是为什么很多人搜“superpowers 具体使用”“有哪些 skills”“怎么引入这些技能”的原因——大家真正关心的是这套东西到底包含什么、怎么装、装完怎么用。我最初接触这个概念的时候也是带着一堆疑问。网上关于它的资料比较零散有的讲概念有的贴配置但很少有人把“为什么这样设计”“实际用起来是什么体验”“哪些坑必须提前知道”讲清楚。所以这篇文章我打算从从业者的视角把 superpowers 这套体系拆开来讲包括它的核心构成、技能的分类逻辑、引入的具体操作、以及我在实际使用中踩过的坑和总结出来的经验。无论你是刚听说这个词的新手还是已经尝试过但没跑通的同行应该都能从下面这些内容里找到对你有用的部分。2. superpowers 的核心构成技能包、触发机制与执行流程2.1 技能包不是代码库而是“行为说明书”很多人第一次接触 superpowers 的时候会下意识地把它当成一个代码库或者依赖包觉得安装完就自动生效了。这个理解偏差会导致后面一系列操作都走偏。实际上superpowers 的核心单元是技能描述文件通常以 Markdown 或者类似的纯文本格式存在。每个文件描述了一个具体的技能内容包括这个技能解决什么问题、在什么条件下触发、执行时需要遵循哪些步骤、有哪些注意事项和边界条件。这种设计思路其实很聪明。因为 AI 助手本身是一个通用模型它的知识面很广但缺乏针对特定工作流的“纪律性”。你让它写代码它可能会写但写法可能不符合你的项目规范你让它排查问题它可能会给出一堆可能性但不会按照从现象到根因的逻辑链条一步步推进。技能包的作用就是给模型套上一个“行为模板”让它在特定场景下按照预设的流程来思考和输出。这就像给一个聪明的实习生一本详细的操作手册他本来就会干活有了手册之后干得更规范、更符合团队要求。从文件结构上看一个典型的技能包通常包含以下几个部分技能名称和标识、适用场景描述、前置条件检查、执行步骤列表、预期输出格式、异常处理建议。有些设计得比较完善的技能包还会包含示例输入和示例输出方便使用者快速理解这个技能的实际效果。这些内容全部用自然语言描述不需要编写复杂的代码逻辑这也是它门槛低、易扩展的原因。2.2 触发机制什么时候该调用哪个技能技能包本身是静态的真正让它“活”起来的是触发机制。superpowers 的触发逻辑通常有两种模式一种是显式触发也就是你在对话中明确提到某个技能的名称或者相关关键词助手就会加载对应的技能描述并按照它来执行另一种是隐式触发助手根据你当前的任务类型、上下文信息自动判断应该调用哪个技能。显式触发比较好理解比如你说“用代码审查技能帮我看看这段代码”助手就会去加载代码审查相关的技能包。隐式触发则更考验技能描述文件的质量因为助手需要从你的自然语言中推断出意图。举个例子如果你说“这段代码跑起来报错了帮我看看”一个设计良好的技能体系应该能识别出这是一个“问题排查”场景从而自动加载排查相关的技能而不是直接给你一堆可能的错误原因。我在实际使用中发现隐式触发的准确率很大程度上取决于技能描述文件里“适用场景”这一栏写得好不好。如果描述太宽泛比如“适用于所有编程问题”那助手就很容易在不该调用的时候调用如果描述太窄又会导致该调用的时候识别不出来。所以如果你要自己写技能包这一栏一定要反复打磨用具体的场景关键词来界定边界。2.3 执行流程从加载技能到输出结果当一个技能被触发之后superpowers 的执行流程大致分为四个阶段。第一阶段是技能加载助手读取技能描述文件理解这个技能的目标和约束条件。第二阶段是上下文收集助手会根据技能描述里要求的信息向你确认或者从当前对话中提取必要的参数比如代码片段、错误信息、项目背景等。第三阶段是按步骤执行助手严格按照技能描述里的步骤列表来推进每一步的输出都会作为下一步的输入。第四阶段是结果输出与校验助手按照技能描述里规定的格式输出结果并对照异常处理建议检查是否有遗漏或偏差。这个流程看起来简单但实际用起来的时候第二阶段和第三阶段是最容易出问题的。上下文收集阶段如果技能描述里没有明确要求某些关键信息助手可能会基于假设来执行导致结果偏离预期。按步骤执行阶段如果步骤描述不够具体助手可能会“跳步”或者“合并步骤”尤其是在处理复杂任务的时候。我的经验是技能描述文件里的步骤要尽量原子化每一步只做一件事并且明确写出这一步的输入和输出是什么。这样虽然文件会变长但执行起来的稳定性会高很多。3. 技能分类详解常见 skills 有哪些、分别解决什么问题3.1 代码生成与重构类技能这是 superpowers 体系里最基础也最常用的一类技能。代码生成类技能的核心价值不是让 AI 从零写出一大段代码而是让它在特定约束下生成符合项目规范的代码。比如你有一个技能叫“生成 RESTful 接口”它的描述文件里会明确规定使用什么框架、遵循什么命名规范、错误处理用什么模式、返回值结构是什么样。当你触发这个技能并给出接口的业务逻辑描述时助手就会按照这些约束来生成代码而不是自由发挥。重构类技能则更偏向于对已有代码的改造。常见的技能包括“提取函数”“消除重复代码”“优化循环结构”“替换过时 API”等。这类技能的关键在于安全边界的设定。因为重构涉及到修改现有代码如果助手改错了地方或者引入了新的问题后果可能比不重构还严重。所以一个合格的重构技能描述里必须包含“修改前先备份”“每次只改一个点”“改完必须给出 diff”“说明修改理由”这些约束条件。我在实际使用中会额外加一条重构后的代码必须能通过原有的测试用例如果项目没有测试用例那就先补测试再重构。这类技能的另一个常见问题是过度重构。助手有时候会“好心办坏事”把你没要求改的地方也顺手改了。比如你只是让它提取一个函数它顺便把变量名也改了、把注释也重写了。这在团队协作中是很危险的因为会让代码审查变得困难。所以我在技能描述里会明确写一条“只修改与当前任务直接相关的代码不得改动其他部分。”这条约束看起来简单但能省掉很多麻烦。3.2 问题排查与调试类技能排查类技能是我个人认为 superpowers 体系里价值最高的一类。因为排查问题这件事最考验的不是知识储备而是逻辑纪律。人类工程师排查问题的时候容易跳步、容易凭直觉下结论、容易忽略边界条件。而一个设计良好的排查技能可以强制助手按照“复现问题→收集信息→提出假设→验证假设→定位根因→给出修复方案”这个流程来走每一步都有明确的输入输出要求。常见的排查技能包括“空指针排查”“性能瓶颈定位”“接口超时分析”“内存泄漏检测”等。每个技能描述里会列出该类型问题的常见原因清单、需要收集的关键信息、验证手段和对应的修复策略。比如“接口超时分析”这个技能会要求助手先确认超时发生的环节是网络层、应用层还是数据库层然后分别给出每个环节的排查命令和判断标准。我在使用这类技能的时候最大的体会是技能描述里的“常见原因清单”要尽量全面但“验证手段”要尽量具体。原因清单全面是为了避免遗漏可能性验证手段具体是为了让助手能真正执行验证而不是停留在“可能是这个原因”的猜测层面。举个例子如果怀疑是数据库慢查询导致的超时验证手段应该具体到“执行 EXPLAIN 分析查询计划检查是否命中索引检查扫描行数是否超过阈值”而不是笼统地说“检查数据库性能”。3.3 文档撰写与知识整理类技能这类技能解决的是“把零散信息变成结构化文档”的问题。常见的技能包括“生成 API 文档”“编写 README”“整理会议纪要”“输出技术方案”等。这类技能的核心挑战在于信息完整性和格式一致性。助手需要从对话历史、代码注释、配置文件等多个来源提取信息然后按照统一的模板组织成文档。一个设计良好的文档技能会在描述文件里明确规定文档的章节结构、每个章节必须包含的信息点、以及信息缺失时的处理方式。比如“生成 API 文档”这个技能会要求每个接口必须包含接口路径、请求方法、请求参数含类型和是否必填、响应结构、错误码列表、调用示例。如果某个信息在上下文中找不到助手应该明确标注“待补充”而不是自己编一个。我在实际使用中发现这类技能最容易出现的问题是信息幻觉。助手为了让文档看起来完整会自己“脑补”一些不存在的信息。比如你给它一个接口的代码它生成的文档里可能会多出几个你没定义过的错误码。所以在技能描述里一定要加一条硬性约束“所有信息必须来源于提供的上下文不得自行推断或补充。”如果确实需要补充必须明确标注“建议补充”并说明理由。3.4 工作流自动化类技能这类技能偏向于把多个操作步骤串联起来形成一个可重复执行的流程。比如“提交代码前的检查清单”这个技能会依次执行运行代码格式化工具、运行静态检查、运行单元测试、检查提交信息格式、生成变更日志。每一步都有明确的通过标准任何一步不通过就中断流程并给出修复建议。这类技能的价值在于一致性。人工执行这些步骤的时候可能会因为赶时间而跳过某一步或者因为疏忽而漏掉某个检查项。而技能包一旦定义好每次触发都会完整执行不会偷懒。我在团队里推广这类技能的时候最受欢迎的就是“发布前检查”和“代码审查准备”这两个。前者确保每次发布都经过同样的质量关卡后者确保提交审查的代码已经经过了自检减少了审查者的负担。不过这类技能也有一个明显的限制它只能执行那些可以通过文本指令完成的操作。如果某个步骤需要点击图形界面、需要人工判断、或者需要访问外部系统技能包就只能给出操作指引而无法自动执行。所以在设计这类技能的时候要明确区分“可自动执行”和“需人工执行”的步骤并在描述文件里标注清楚。4. 引入 superpowers 的完整操作路径4.1 环境准备在什么平台上用、需要什么前置条件superpowers 本身不是一个独立运行的软件它需要依附在一个支持技能加载机制的 AI 助手平台上。目前常见的支持方式有两种一种是通过平台自带的技能管理功能来引入另一种是通过配置文件或者目录结构来手动加载。具体用哪种方式取决于你使用的平台和工具链。在开始引入之前你需要确认几个前置条件。第一你的 AI 助手平台是否支持自定义技能或者类似的功能。有些平台把这个功能叫做“自定义指令”“工作流模板”“知识库”名字不同但本质类似。第二你是否有权限修改配置文件或者添加技能文件。如果是团队共用的环境可能需要管理员权限。第三你打算引入的技能包来源是否可靠。网上流传的技能包质量参差不齐有些描述文件写得很粗糙引入之后反而会干扰助手的正常判断。我个人的建议是不要一上来就引入一大堆技能包。先从一两个最常用的场景开始比如代码审查或者问题排查跑通了之后再逐步扩展。这样一方面可以控制风险另一方面也能让你更清楚地了解每个技能的实际效果方便后续调整。4.2 获取技能包的几种途径目前获取 superpowers 技能包主要有三种途径。第一种是官方或社区维护的技能仓库这类仓库通常会按照技能类别分目录存放每个技能一个文件附带使用说明和示例。第二种是自己编写根据你的实际工作流把常用的操作步骤整理成技能描述文件。第三种是从现有工作流中提取比如你团队已经有一套代码审查清单可以直接把它改写成技能描述文件的格式。对于新手来说我建议先从第一种途径开始找几个成熟的技能包来体验一下效果。在挑选的时候重点看几个指标技能描述是否具体、步骤是否原子化、是否有明确的边界条件、是否有示例输入输出。如果一个技能包的描述文件只有寥寥几行那大概率效果不会太好。另外要注意技能包的更新时间和适用平台版本太老的技能包可能和新版平台不兼容。自己编写技能包的时候有一个很实用的技巧先记录后整理。也就是说你先在日常工作中把自己执行某个任务的完整过程记录下来包括每一步的操作、判断依据、注意事项然后再把这些记录整理成结构化的技能描述文件。这样写出来的技能包最贴合你的实际需求也最容易落地。4.3 安装与配置的具体步骤安装 superpowers 技能包的具体操作根据平台不同会有差异但大体流程是相似的。下面我以最常见的“目录加载”方式为例说明一下完整的操作步骤。第一步找到平台的技能目录。这个目录通常在你的用户配置文件夹下或者项目根目录下的某个隐藏文件夹里。具体位置可以查阅平台的官方文档或者在设置界面里找“技能管理”“扩展配置”之类的选项。第二步把技能包文件放入指定目录。每个技能包通常是一个独立的 Markdown 文件文件名就是技能标识。有些平台支持子目录分类你可以按照“代码类”“排查类”“文档类”这样的结构来组织。第三步配置触发关键词。在技能描述文件的开头部分通常会有一个“触发条件”或者“适用场景”的字段你需要在这里填写能让你自然联想到这个技能的关键词。比如代码审查技能可以填“审查”“review”“检查代码”等。第四步重启或刷新助手。大部分平台在修改技能目录后需要重新加载才能生效。刷新之后你可以用一个简单的测试指令来验证技能是否被正确加载比如直接说出技能名称看助手是否能识别并按照技能描述来响应。第五步验证执行效果。用一个真实的场景来测试观察助手的输出是否符合技能描述里的预期。如果不符合检查技能描述文件是否有歧义或者触发条件是否设置得太宽泛。注意在修改任何配置文件之前先备份原始文件。技能加载失败有时候会导致助手行为异常有备份可以快速回滚。4.4 验证技能是否生效的实用方法技能引入之后怎么确认它真的生效了我常用的方法有三个。第一个是直接点名法在对话中明确说出技能名称比如“请使用代码审查技能”然后观察助手的回复是否按照技能描述里的步骤来组织。如果助手只是泛泛而谈没有体现出技能描述里的结构化流程那说明技能没有被正确加载。第二个是场景触发法不说技能名称而是描述一个该技能应该覆盖的场景看助手是否会主动调用对应的技能。比如你贴一段有问题的代码说“帮我看看这里有什么问题”如果代码审查技能生效了助手应该会按照审查清单逐项检查而不是直接给一个笼统的评价。第三个是对比法在引入技能前后用同样的输入测试助手对比输出的差异。如果引入技能后输出变得更结构化、更符合你的预期那说明技能在起作用。如果输出没有明显变化可能是技能描述文件写得不够具体或者触发条件没有匹配上。我在实际使用中还发现一个细节有些平台会缓存技能加载结果修改技能文件后需要清除缓存才能生效。如果你确认文件放对了位置但技能就是不生效可以试试清除缓存或者重启平台。5. 实际使用中的坑与应对经验5.1 技能冲突多个技能同时被触发怎么办这是我在使用初期遇到的最头疼的问题。当你引入了多个技能之后有时候一个输入会同时匹配多个技能的触发条件导致助手不知道该按哪个技能来执行最后输出一个“四不像”的结果。比如你贴了一段代码说“帮我优化一下”代码优化技能和代码审查技能可能同时被触发一个想改代码一个想提意见结果助手两边都做了一点但两边都没做透。解决这个问题的核心思路是明确优先级。在技能描述文件里可以设置一个“优先级”字段数值高的技能优先触发。或者在触发条件里写得更精确一些避免和其他技能的关键词重叠。比如代码优化技能的触发条件可以写成“优化性能”“提升效率”“减少耗时”而代码审查技能的触发条件写成“检查问题”“审查代码”“找 bug”这样重叠度就降低了。另一个实用的做法是显式指定。当你发现助手在多个技能之间摇摆的时候直接在输入里点名你要用哪个技能。虽然这样少了一点“自动”的便利但能保证执行路径的确定性。我在处理复杂任务的时候通常会先显式指定技能等流程跑顺了再尝试隐式触发。5.2 技能描述太笼统导致的“自由发挥”技能描述文件写得太笼统是导致助手“自由发挥”的主要原因。比如一个技能描述里只写了“帮助用户排查代码问题”没有规定排查步骤、没有列出常见原因、没有说明输出格式那助手就会按照自己的理解来执行结果可能和你期望的完全不一样。我踩过的一个典型坑是写了一个“生成单元测试”的技能描述里只说了“为指定函数生成单元测试”没有规定测试框架、没有要求覆盖边界条件、没有说明 mock 的使用规则。结果助手生成的测试用例用的是它自己习惯的框架和项目里用的完全不一样而且只覆盖了正常路径边界条件一个都没测。后来我把这个技能描述重写了增加了以下约束使用项目指定的测试框架、必须覆盖正常路径和至少三个边界条件、外部依赖必须 mock、每个测试用例必须有明确的断言、测试函数命名遵循项目规范。改完之后生成的测试用例质量明显提升基本可以直接用。所以我的经验是技能描述文件的详细程度直接决定了执行结果的稳定性。宁可写长一点、细一点也不要留太多“自行判断”的空间。5.3 技能加载失败时的排查思路技能加载失败的表现有很多种助手完全不响应技能名称、响应了但行为不符合技能描述、或者直接报错。排查的时候我通常按照以下顺序来定位问题。先检查文件位置和格式。确认技能文件放在了正确的目录下文件扩展名是平台支持的格式文件编码没有乱码。有些平台对文件名有要求比如只能用英文和数字不能有空格和特殊字符。再检查文件内容。确认技能描述文件的语法符合平台要求比如字段名称是否正确、缩进是否规范、是否有未闭合的代码块。一个很隐蔽的问题是文件里包含了平台不支持的字符或者格式导致解析失败但又不报错。然后检查触发条件。确认你输入的指令是否真的匹配了技能描述里的触发条件。有时候你以为自己说的是“审查代码”但技能描述里写的触发词是“代码审查”顺序不一样可能就匹配不上。最后检查平台版本。有些技能包是针对特定版本写的平台升级后字段格式变了旧技能包可能就无法加载。这种情况要么更新技能包要么手动调整字段格式。5.4 性能与上下文长度的平衡引入大量技能包之后一个容易被忽视的问题是上下文长度。每个技能描述文件都会占用一定的上下文空间当技能数量多了之后助手可用于处理实际任务的上下文就变少了。表现就是助手开始“忘记”前面的对话内容或者对复杂任务的处理能力下降。我的应对策略是按需加载。不要把所有的技能包都放在默认加载目录里而是分成“常用”和“备用”两组。常用的技能包保持加载状态备用的技能包放在另一个目录里需要的时候再手动引入。这样既能保证常用技能的响应速度又不会过度占用上下文。另一个策略是精简技能描述。在保证关键约束不丢失的前提下尽量用简洁的语言描述。比如“必须覆盖正常路径和至少三个边界条件”可以简化为“覆盖正常路径3个边界条件”意思一样但字数少了很多。对于步骤描述能用列表就不用段落能用关键词就不用长句。6. 进阶玩法自定义技能与组合技6.1 从零写一个技能包的完整模板当你熟悉了现有技能包之后下一步自然是写自己的技能包。下面我给出一个通用的技能描述模板你可以根据实际需求调整。# 技能名称XXX ## 适用场景 描述这个技能在什么情况下使用列出触发关键词。 ## 前置条件 列出执行这个技能之前必须满足的条件比如需要提供代码片段、需要确认项目框架等。 ## 执行步骤 1. 第一步具体操作输入是什么输出是什么。 2. 第二步具体操作输入是什么输出是什么。 3. 第三步具体操作输入是什么输出是什么。 ## 输出格式 规定输出的结构比如先给结论再给理由或者按照表格形式呈现。 ## 边界条件 列出不适用的情况以及遇到这些情况时的处理方式。 ## 示例 给出一个输入和对应的输出示例。这个模板看起来简单但每个字段都有讲究。“适用场景”决定了技能什么时候被触发“前置条件”避免了信息不足时的盲目执行“执行步骤”是核心“输出格式”保证了结果的一致性“边界条件”防止了误用“示例”则帮助使用者快速理解技能的效果。写技能包的时候我建议先写步骤再写其他。因为步骤是技能的核心逻辑其他字段都是围绕步骤来服务的。先把步骤理清楚再根据步骤的需要来补充前置条件、输出格式和边界条件这样写出来的技能包逻辑最顺。6.2 把多个技能串成工作流单个技能解决的是单点问题而实际工作中很多任务是多个技能的串联。比如“提交代码”这个任务实际上包含了代码审查、格式化、运行测试、生成提交信息等多个子任务。你可以为每个子任务写一个技能然后再写一个“总控”技能按照顺序调用这些子技能。总控技能的描述文件里核心内容是调用顺序和传递规则。比如先调用代码审查技能如果审查通过则调用格式化技能格式化完成后调用测试技能测试通过后调用提交信息生成技能。每个子技能的输出作为下一个子技能的输入任何一个环节失败就中断流程并给出修复建议。这种组合技的威力在于可重复性。一旦定义好每次提交代码都会按照同样的流程执行不会因为人为疏忽而跳过某个环节。我在团队里推广这套组合技之后代码提交的规范性明显提升因为大家都知道流程是固定的偷懒也偷不掉。6.3 根据团队规范定制技能包每个团队都有自己的编码规范、审查标准、发布流程。把这些规范固化到技能包里是 superpowers 最有价值的应用场景之一。比如你们团队规定所有接口必须返回统一的错误码格式那就可以写一个“接口错误码检查”技能在代码审查阶段自动检查是否符合规范。定制技能包的关键是把隐性知识显性化。很多团队规范是口口相传的新人来了要花很长时间才能摸清楚。把这些规范写成技能描述文件一方面可以让 AI 助手按照规范来执行另一方面也是很好的团队知识沉淀。新人通过阅读技能包就能快速了解团队的做事方式。我在定制技能包的时候会先收集团队里最常见的“返工原因”。比如代码审查时最常被指出的问题、测试时最常遗漏的场景、发布时最容易出错的步骤。然后针对每个返工原因写一个检查技能在对应的环节自动执行。这样技能包就不是凭空想出来的而是从实际痛点中长出来的落地效果最好。7. 关于 superpowers 的几个常见误解7.1 它不是“装上就变强”的魔法很多人对 superpowers 的期待是装上一堆技能包AI 助手就自动变成专家了。实际用下来会发现技能包的作用是约束和引导而不是注入知识。助手本身的知识储备决定了它能做什么技能包决定了它怎么做。如果助手本身对某个领域不了解再详细的技能描述也帮不上忙。所以正确的预期是superpowers 让一个“还不错的助手”变成“符合你工作流的助手”而不是让一个“普通助手”变成“专家助手”。它的价值在于规范化和一致性而不是能力提升。7.2 技能包不是越多越好我见过有人一口气引入了三四十个技能包结果助手变得非常“神经质”动不动就触发某个技能输出一堆格式化的内容反而影响了正常对话。技能包的数量和效果不是正比关系关键在于每个技能包是否真的被用到。我的建议是保持常用技能包在五个以内最多不超过十个。其他的放在备用目录里需要的时候再临时引入。定期清理那些一个月都没用过的技能包保持技能集的精简。7.3 它不能替代人的判断技能包可以规范流程但不能替代人的判断。尤其是在排查问题、代码审查、方案设计这些需要经验和直觉的场景技能包提供的是“检查清单”和“思考框架”最终的判断还是要靠人来做。我见过有人完全依赖技能包的输出来做决策结果在技能包没有覆盖到的边界情况下出了问题。正确的用法是把技能包当作一个“不会偷懒的助手”它帮你执行那些重复性的、有固定流程的步骤让你有更多精力去处理那些需要创造力和判断力的部分。人和技能包的关系是协作不是替代。8. 我个人的使用体会与后续扩展方向用了一段时间的 superpowers 之后我最大的感受是它改变了我对 AI 助手的期待方式。以前我期待它“什么都知道”现在我期待它“知道在什么场景下该怎么做”。这个转变让我的使用体验好了很多因为我不再纠结于它偶尔的知识盲区而是专注于把工作流定义清楚让它按照流程来执行。如果要说有什么遗憾的话就是目前技能包的编写还是偏手工需要人工整理步骤和约束条件。我后续想尝试的方向是把日常工作中的操作日志自动提取成技能描述文件的草稿然后再人工精修。这样可以把编写技能包的成本降下来让更多重复性的工作流能够被固化下来。另外我也在尝试把技能包和项目文档打通。比如技能描述文件里引用的规范直接链接到项目文档的对应章节这样规范更新的时候技能包也能同步更新避免了两边不一致的问题。这个方向还在摸索中等跑通了再单独写一篇来分享。最后分享一个小技巧如果你不确定某个技能包是否适合你的场景先用一个真实的、但不太重要的任务来测试。比如用一段废弃的代码来测试代码审查技能用一个测试环境的接口来测试排查技能。这样即使技能包效果不好也不会造成实际损失。等确认效果之后再应用到正式的工作流里。
阅读完成 · 觉得有帮助？
