遇见高中生你有没有算过，一天里有多少次在终端里输入同样的指令，向 AI 助手重复解释同一个项目的背景，再把同样的需求用不同的措辞发给不同的工具？我之前统计过自己一周的工作流，发现最消耗心力的根本不是写代码，而是"把脑子里已经想清楚的事，重新翻译给工具听"。OpenCode、Claude Code、VS Code 这三样工具单独拿出来都很能打，但各用各的，就变成了三套割裂的对话流。直到我把"技能"这个概念引入工作流，把高频动作沉淀成可复用的资产，才真正从这种重复里解放出来。
这篇文章我会完整拆解这套"技能资产化"的打法：OpenCode 和 Claude Code 各自的技能机制怎么用，VS Code 怎么作为统一入口把两者串起来，以及我在落地过程中踩过的坑和做出的取舍。适合正在用终端型 AI 编程助手、但对重复劳动开始感到厌烦的开发者，尤其是团队里想统一 AI 工作流的同学。
1. 重复劳动的真实成本：为什么非要有"技能"这层抽象
1.1 日常编码中的高频重复场景
先说我自己的真实情况。我同时维护几个项目，每个项目的技术栈、目录结构、代码规范都不一样。每天打开编辑器之后，我会让 AI 助手帮我做这些事：审查新写的代码、生成 commit message、补充单元测试、跑一遍 lint 并修复问题、把需求拆成任务清单。听起来都是小事，但问题在于——每换一个项目，每换一次会话，我都要把这些背景重新说一遍。
"这个项目用的是 pnpm 和 monorepo，后端是 FastAPI，测试放在 tests/ 目录下……"这种话我一天要打好几遍。有时候换了一个终端工具，连说话的方式都要调整。后来我意识到，这不只是"麻烦"的问题，而是我的时间和注意力被大量地消耗在了"沟通成本"上，真正用在思考和决策上的时间反而被挤占了。
1.2 交互式 AI 助手的短板：上下文每次都从零开始
无论是 OpenCode 还是 Claude Code，底层都是大语言模型驱动的对话式代理。它们的会话（session）是有状态的，但项目与项目之间、会话与会话之间，是完全没有记忆的。今天你跟 Claude Code 详细介绍了项目的架构，明天新开会话，它照样一无所知。OpenCode 也一样，你昨天给它定义的代码风格偏好，今天它还是会问"这个项目有什么特殊要求吗"。
这种"每次从零开始"的本质原因，是大模型本身不持久化任何项目知识。会话上下文更像是工作内存，关掉就清空。想让 AI 稳定地按照你的标准干活，唯一可持续的方式，就是把那些"你反复交代的内容"从聊天里抽出来，变成一个独立的、结构化的、可被工具自动加载的文件。这就是技能（skill）机制存在的意义。
1.3 "技能"的本质：把多步操作封装成声明式资产
技能这个词听起来玄乎，其实本质很简单：就像你把一长串 git 命令写成一个 shell alias 一样，你把一段复杂的、多步骤的 AI 工作流写成一个 Markdown 文件，告诉模型"当用户请求这件事时，请按这个流程执行"。它不是一个提示词模板，而是一份"操作手册"。
区别在哪里？提示词模板是你复制给 AI 的一段话，它依赖你还记得去复制；技能是放在固定目录下的一个文件，只要用户触发对应关键词，模型自动加载相关背景、步骤和标准。技能把你的经验沉淀成了资产——它不随会话消失，可以跨工具复用，可以提交到 Git 仓库里跟团队共享。这才是"从重复中解放"的真正含义：你只写一次，之后反复调用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三款工具的角色分工：OpenCode、Claude Code 与 VS Code 各管哪一段
2.1 OpenCode：轻量、模型无关的终端助理
OpenCode 是一个开源的终端 AI 编程代理，跟 Claude Code 定位类似，但有一个关键区别：它不绑定特定模型。你可以让它接 Anthropic 的模型，也可以接 OpenAI、Google 的模型，甚至可以通过配置接上本地跑的 Ollama 模型。这个特性让它在实际落地中非常灵活——尤其是在某些模型服务不稳定或不可用的时候，OpenCode 可以作为替补方案顶上。
OpenCode 对技能机制的支持也做得比较早。它会在你进入一个项目时扫描技能文件，并在合适的时候自动调用。因为它本身是开源的，社区里已经有不少人开始把自己团队的规范写成 OpenCode