目录一、一个技能长什么样二、预装的 26 个技能三、技能是怎么加载的四、在对话里调用技能五、写一个自己的技能六、它做不到的地方小结用 AI 写代码久了总有几套做法要反复交代review 时看哪几个维度提交信息按什么格式写改数据库要成对写迁移。每次都贴一大段提示词很烦。全写进规则文件里又太长每一轮都在占上下文。WES Code 的技能Skill就是为这个准备的把一类任务的做法写成一份SKILL.md。平时系统提示词里只放一份技能索引真正用到时才加载全文。这篇讲技能长什么样、预装了哪些、怎么加载、怎么调用、怎么写自己的以及它做不到的地方。一、一个技能长什么样技能就是一份 Markdown 操作手册告诉 AI 某一类任务该怎么做。它不增加新工具只规定做法。下面是预装技能code-review文件开头的 frontmatter原样照搬---name:code-reviewversion:1.0.0min_engine:1.0.0description:Review diffs for correctness, security, maintainability with graded findings. Use when reviewing PRs or code changes.operators:-read-execcapabilities:-cap.reviewer.methodologymetadata:enabled:trueexecution_mode:guidedtags:[code-review,defect-detection,quality,best-practices]---几个字段里最要紧的是description。它会出现在技能索引里AI 靠它判断这个任务该不该用这个技能。所以预装技能的描述都写成「做什么 什么时候用」Use when reviewing PRs or code changes。frontmatter 下面才是正文具体步骤、检查项、要避开的坑。二、预装的 26 个技能WES Code 预装了 26 个编程技能按用途分成几组分组技能什么时候用产品增量wescode-retrieval、wescode-execution检索代码、执行验证命令时和引擎的基础技能一起生效产品增量issue-investigation你报了一个 bug产品增量context-calibration第一次接触一个工作区重度方法论performance-optimization做性能优化先测再改重度方法论refactoring大规模重命名、迁移逐步改、逐步编译重度方法论integration-audit、legacy-navigation、code-audit-discipline审查接线、读遗留代码、大范围审计标准编程test-engineering写测试红绿重构标准编程security-audit安全审计标准编程code-review、code-review-dispatch审查 diff 和 PR标准编程debug-methodology运行时崩溃、下断点标准编程documentation-engineering、pattern-consistency、autonomous-workflow写文档、对齐同包写法、自主推进任务轻量参考database-design、clean-code、ui-engineering、cicd-deployment、git-workflow、system-design、requirements-analysis改表结构、实现和重构、写前端组件、配 CI、Git 操作、架构设计、需求分析平台能力split-changes、pr-guardian拆分大变更、守护 PR冲突、评论、CI另外还有 7 个引擎内置的基础技能比如检索、执行、记忆策略、计划。这几个是只读的不能改也不能卸。在 WES Code 左侧的「技能」里打开技能管理页「已安装」里能看到全部技能每个都能单独启用或禁用。三、技能是怎么加载的常驻的只有索引系统提示词里只有一份available_skills索引每个技能一条名字、来源、位置和描述。没写描述的取正文开头 250 个字符。索引的格式是这样的channel、location的值随安装位置不同这里省略available_skillsskillnamecode-reviewchannel…location…Review diffs for correctness, security, maintainability with graded findings. Use when reviewing PRs or code changes./skill!-- 其余技能每个一条 --/available_skills索引最后跟着一句固定的提示Before using a skill, callskill(actionview, nameskill-name)to load its full instructions.也就是说AI 决定要用某个技能时先调用skill工具把全文读进来再照着做。这次调用的参数是{action:view,name:code-review}skill工具一共四个动作view读全文search按关键词找技能edit改技能的正文或描述disable停用。比如找和测试有关的技能{action:search,query:test}索引也有上限索引默认预算 20000 token超过 15000 会换成精简写法最多列 100 个技能。装得再多也不会把系统提示词撑爆。为什么这样设计全文不常驻没用到的技能就不占上下文。索引放在系统提示词里、轮与轮之间基本不变对提示词缓存也友好。四、在对话里调用技能让 AI 自己判断大多数时候不用管。你说「帮我 review 一下这次改动」AI 看到索引里code-review的描述就会去加载它。用 /技能名 直接点名想指定用哪个技能就在消息里写/技能名/code-review 看一下 internal/order 这次的改动按严重程度列出问题WES Code 会把你这条消息里的/code-review展开成这个技能的全文跟着这条消息一起发给模型不改动系统提示词。一条消息里写多个/技能名也行重复的只算一次。五、写一个自己的技能在技能工作台里新建在技能管理页点「新建技能」会打开「技能工作台」创建和编辑自定义技能写完点「保存」。每个技能是一个目录里面必须有一份SKILL.md还可以放技能要用到的脚本team-commit/ ├── SKILL.md # 必须有frontmatter 正文 └── scripts/ # 可选技能里要调用的脚本照着预装技能的格式写就行。比如把团队的提交规范写成一个技能--- name: team-commit version: 1.0.0 min_engine: 1.0.0 description: 按团队规范写提交信息。用户要求提交代码或生成 commit message 时使用。 metadata: enabled: true tags: [git, commit] --- # 团队提交规范 - 标题格式type(scope): summarytype 只用 feat / fix / refactor / docs / test / chore - summary 用中文不超过 50 个字结尾不加句号 - 改了表结构的提交正文第一行写清迁移文件名 - 一个提交只做一件事顺手改的格式和重命名单独提交之后说「把这次改动提交了」或者直接写/team-commitAI 就会按这份规范来。规矩多、步骤多的场景更适合写成技能。比如数据库迁移--- name: db-migration version: 1.0.0 min_engine: 1.0.0 description: 写数据库迁移时的检查规则。新增或修改表结构、编写迁移文件时使用。 metadata: enabled: true tags: [database, migration] --- # 数据库迁移规则 1. 迁移文件成对写每个 up 都要有对应的 downdown 要能把 up 完全撤回 2. 加列默认允许为空或者给默认值不在大表上一次性加非空列 3. 删列分两步先发一个版本停止读写这一列下一个版本再删 4. 写完在本地依次跑 up、down、up三次都成功才算完成写好描述描述决定 AI 什么时候想起它。写成「做什么 什么时候用」比只写一个名词管用得多。按项目隔离自定义技能存在本机数据目录下这个工作区自己的目录里。A 项目里写的技能B 项目里没有。六、它做不到的地方不增加工具技能只能教 AI 怎么用已有的工具不能给它新能力引擎内置的 7 个只读不能改也不能卸全文不常驻AI 没加载的技能就不生效。描述写得含糊它可能想不起来用索引有上限技能太多时索引会换成精简写法不跨项目每个工作区的技能是分开的小结技能是一份SKILL.md写的是一类任务的做法系统提示词里只放索引用到时才加载全文索引默认预算 20000 token最多列 100 个让 AI 自己判断或者用/技能名直接点名在技能工作台里新建描述写成「做什么 什么时候用」文中的技能系统是 WES Code 里的功能官网是 weisyn.com。你们团队最想写成技能的是哪一套做法欢迎评论区聊聊。觉得有用的朋友欢迎点赞、收藏、关注后面会继续分享 AI 编程的实战经验。
目录一、一个技能长什么样二、预装的 26 个技能三、技能是怎么加载的四、在对话里调用技能五、写一个自己的技能六、它做不到的地方小结用 AI 写代码久了总有几套做法要反复交代review 时看哪几个维度提交信息按什么格式写改数据库要成对写迁移。每次都贴一大段提示词很烦。全写进规则文件里又太长每一轮都在占上下文。WES Code 的技能Skill就是为这个准备的把一类任务的做法写成一份SKILL.md。平时系统提示词里只放一份技能索引真正用到时才加载全文。这篇讲技能长什么样、预装了哪些、怎么加载、怎么调用、怎么写自己的以及它做不到的地方。一、一个技能长什么样技能就是一份 Markdown 操作手册告诉 AI 某一类任务该怎么做。它不增加新工具只规定做法。下面是预装技能code-review文件开头的 frontmatter原样照搬---name:code-reviewversion:1.0.0min_engine:1.0.0description:Review diffs for correctness, security, maintainability with graded findings. Use when reviewing PRs or code changes.operators:-read-execcapabilities:-cap.reviewer.methodologymetadata:enabled:trueexecution_mode:guidedtags:[code-review,defect-detection,quality,best-practices]---几个字段里最要紧的是description。它会出现在技能索引里AI 靠它判断这个任务该不该用这个技能。所以预装技能的描述都写成「做什么 什么时候用」Use when reviewing PRs or code changes。frontmatter 下面才是正文具体步骤、检查项、要避开的坑。二、预装的 26 个技能WES Code 预装了 26 个编程技能按用途分成几组分组技能什么时候用产品增量wescode-retrieval、wescode-execution检索代码、执行验证命令时和引擎的基础技能一起生效产品增量issue-investigation你报了一个 bug产品增量context-calibration第一次接触一个工作区重度方法论performance-optimization做性能优化先测再改重度方法论refactoring大规模重命名、迁移逐步改、逐步编译重度方法论integration-audit、legacy-navigation、code-audit-discipline审查接线、读遗留代码、大范围审计标准编程test-engineering写测试红绿重构标准编程security-audit安全审计标准编程code-review、code-review-dispatch审查 diff 和 PR标准编程debug-methodology运行时崩溃、下断点标准编程documentation-engineering、pattern-consistency、autonomous-workflow写文档、对齐同包写法、自主推进任务轻量参考database-design、clean-code、ui-engineering、cicd-deployment、git-workflow、system-design、requirements-analysis改表结构、实现和重构、写前端组件、配 CI、Git 操作、架构设计、需求分析平台能力split-changes、pr-guardian拆分大变更、守护 PR冲突、评论、CI另外还有 7 个引擎内置的基础技能比如检索、执行、记忆策略、计划。这几个是只读的不能改也不能卸。在 WES Code 左侧的「技能」里打开技能管理页「已安装」里能看到全部技能每个都能单独启用或禁用。三、技能是怎么加载的常驻的只有索引系统提示词里只有一份available_skills索引每个技能一条名字、来源、位置和描述。没写描述的取正文开头 250 个字符。索引的格式是这样的channel、location的值随安装位置不同这里省略available_skillsskillnamecode-reviewchannel…location…Review diffs for correctness, security, maintainability with graded findings. Use when reviewing PRs or code changes./skill!-- 其余技能每个一条 --/available_skills索引最后跟着一句固定的提示Before using a skill, callskill(actionview, nameskill-name)to load its full instructions.也就是说AI 决定要用某个技能时先调用skill工具把全文读进来再照着做。这次调用的参数是{action:view,name:code-review}skill工具一共四个动作view读全文search按关键词找技能edit改技能的正文或描述disable停用。比如找和测试有关的技能{action:search,query:test}索引也有上限索引默认预算 20000 token超过 15000 会换成精简写法最多列 100 个技能。装得再多也不会把系统提示词撑爆。为什么这样设计全文不常驻没用到的技能就不占上下文。索引放在系统提示词里、轮与轮之间基本不变对提示词缓存也友好。四、在对话里调用技能让 AI 自己判断大多数时候不用管。你说「帮我 review 一下这次改动」AI 看到索引里code-review的描述就会去加载它。用 /技能名 直接点名想指定用哪个技能就在消息里写/技能名/code-review 看一下 internal/order 这次的改动按严重程度列出问题WES Code 会把你这条消息里的/code-review展开成这个技能的全文跟着这条消息一起发给模型不改动系统提示词。一条消息里写多个/技能名也行重复的只算一次。五、写一个自己的技能在技能工作台里新建在技能管理页点「新建技能」会打开「技能工作台」创建和编辑自定义技能写完点「保存」。每个技能是一个目录里面必须有一份SKILL.md还可以放技能要用到的脚本team-commit/ ├── SKILL.md # 必须有frontmatter 正文 └── scripts/ # 可选技能里要调用的脚本照着预装技能的格式写就行。比如把团队的提交规范写成一个技能--- name: team-commit version: 1.0.0 min_engine: 1.0.0 description: 按团队规范写提交信息。用户要求提交代码或生成 commit message 时使用。 metadata: enabled: true tags: [git, commit] --- # 团队提交规范 - 标题格式type(scope): summarytype 只用 feat / fix / refactor / docs / test / chore - summary 用中文不超过 50 个字结尾不加句号 - 改了表结构的提交正文第一行写清迁移文件名 - 一个提交只做一件事顺手改的格式和重命名单独提交之后说「把这次改动提交了」或者直接写/team-commitAI 就会按这份规范来。规矩多、步骤多的场景更适合写成技能。比如数据库迁移--- name: db-migration version: 1.0.0 min_engine: 1.0.0 description: 写数据库迁移时的检查规则。新增或修改表结构、编写迁移文件时使用。 metadata: enabled: true tags: [database, migration] --- # 数据库迁移规则 1. 迁移文件成对写每个 up 都要有对应的 downdown 要能把 up 完全撤回 2. 加列默认允许为空或者给默认值不在大表上一次性加非空列 3. 删列分两步先发一个版本停止读写这一列下一个版本再删 4. 写完在本地依次跑 up、down、up三次都成功才算完成写好描述描述决定 AI 什么时候想起它。写成「做什么 什么时候用」比只写一个名词管用得多。按项目隔离自定义技能存在本机数据目录下这个工作区自己的目录里。A 项目里写的技能B 项目里没有。六、它做不到的地方不增加工具技能只能教 AI 怎么用已有的工具不能给它新能力引擎内置的 7 个只读不能改也不能卸全文不常驻AI 没加载的技能就不生效。描述写得含糊它可能想不起来用索引有上限技能太多时索引会换成精简写法不跨项目每个工作区的技能是分开的小结技能是一份SKILL.md写的是一类任务的做法系统提示词里只放索引用到时才加载全文索引默认预算 20000 token最多列 100 个让 AI 自己判断或者用/技能名直接点名在技能工作台里新建描述写成「做什么 什么时候用」文中的技能系统是 WES Code 里的功能官网是 weisyn.com。你们团队最想写成技能的是哪一套做法欢迎评论区聊聊。觉得有用的朋友欢迎点赞、收藏、关注后面会继续分享 AI 编程的实战经验。
