1. 项目概述从“写代码”到“演化技能”的范式转变如果你还在把 Claude Code 当成一个更聪明的代码补全工具那可能就有点“大材小用”了。最近几个月围绕 Claude Code 的讨论焦点已经从“怎么写一段函数”彻底转向了“如何构建和演化一套可复用的 Skills”。这不仅仅是功能的叠加而是一种开发范式的根本性迁移。Claude Code Harness 12 的发布以及社区里铺天盖地的 Skills 推荐、安装教程和排行榜都在指向一个核心事实AI 编程的竞争已经从模型能力的比拼进化到了“技能工程”体系的构建。简单来说Skills 就是为 Claude Code 这个“大脑”安装的“应用程序”或“插件包”。一个 Skill 封装了特定的任务理解、上下文处理逻辑和代码生成策略。比如一个“测试用例生成 Skill”不仅知道要写测试还深谙你项目中 Jest、Vitest 或 Pytest 的惯用模式甚至能根据你的代码风格生成匹配的断言语句。而“Harness”你可以理解为 Skills 的“运行时环境”和“管理框架”它负责调度、组合不同的 Skills并确保它们能在正确的上下文、遵循正确的约束下工作。Harness 12 的迭代重点就在于优化了 Skills 的编写、调试和演化的全链路体验。所以“Skills 从编写到演化”这个标题精准地概括了当前高阶玩家们的核心工作流第一步是“编写”即如何从零开始将一个模糊的需求如“帮我做代码审查”转化为一个稳定、可靠的 Skill第二步是“演化”即这个 Skill 如何在真实、复杂的项目中使用反馈数据不断自我改进适应不同的代码库和团队规范甚至与其他 Skills 协同产生“112”的效果。这个过程远比单纯调教一个 Prompt 要复杂和深刻得多。接下来我将结合实战拆解从构思一个 Skill 到让它在你团队中“活”起来并持续进化的完整路径。2. 核心思路Skill 的本质与 Harness 的定位在动手写第一行 Skill 配置之前我们必须先统一思想Skill 到底是什么它和普通的 Prompt 模板或代码片段有本质区别。2.1 Skill 的三层结构意图、上下文与约束一个成熟的 Skill绝不是一个加强版的system提示词。我认为它应该包含三个紧密耦合的层次意图层这是 Skill 的“灵魂”。它明确定义了这个 Skill 要解决什么问题其输入和输出是什么。例如“生成 React 组件单元测试”是一个意图“重构冗长函数以符合 SOLID 原则”是另一个意图。意图描述必须精准、无歧义最好能用一两个简单的用户故事User Story来定义。比如“作为开发者当我选中一个 React 函数组件时我希望 Skill 能为我生成覆盖其主要渲染逻辑和 Props 变化的 Jest 测试用例。”上下文层这是 Skill 的“眼睛和耳朵”。它决定了 Claude Code 在执行该 Skill 时能“看到”哪些信息。这包括文件上下文是只看到当前文件还是需要看到相关的导入文件、类型定义文件、测试文件范例项目上下文是否需要读取package.json、tsconfig.json或项目的目录结构来理解技术栈和配置对话历史是否参考本次会话中之前关于此代码块的讨论外部知识是否需要通过 RAG 检索项目文档、API 手册或特定的设计规范 Harness 12 强化了上下文管理的粒度允许 Skill 作者精细地控制上下文的摄入范围、优先级和格式化方式避免无关信息干扰核心任务。约束与策略层这是 Skill 的“行为准则”。它规定了代码生成必须遵守的规则。这比简单的“代码风格”要求深入得多架构约束例如“新生成的函数必须是无副作用的纯函数”“不允许使用any类型”。安全约束例如“生成的 SQL 查询必须使用参数化绑定禁止字符串拼接”。性能约束例如“循环体内的操作时间复杂度必须为 O(1)”。生成策略例如“优先使用递归而非迭代”“优先返回Result类型而非抛出异常”。 这些约束通常通过结构化、机器可读的规则配置在 Harness 中而不仅仅是写在自然语言提示里这能显著提高 AI 遵循的准确性和一致性。2.2 Harness 12从“执行器”到“演化工坊”Harness 早期版本更像一个管道把用户输入、上下文和 Skill 打包发给模型。Harness 12 的定位发生了关键转变它开始承担起 Skill 生命周期管理的职责。组合与编排支持 Skills 的链式调用Chain或并行执行Parallel。例如一个“需求澄清”Skill 的输出可以作为“TDD 测试驱动开发”Skill 的输入而“代码生成”和“代码审查”Skill 可以并行运行对比结果。反馈闭环这是“演化”的核心。Harness 12 可以更便捷地收集用户对 Skill 输出结果的反馈如“采纳”、“修改后采纳”、“拒绝”并将这些反馈与当时的输入上下文关联起来形成训练数据。A/B 测试与版本管理你可以为同一个意图部署多个不同版本的 Skill例如一个激进重构版一个保守优化版让 Harness 在后台进行小流量 A/B 测试根据采纳率等指标自动选择最优版本实现 Skill 的灰度发布与滚动更新。可观测性提供了更详细的日志和指标让你能看清一个 Skill 被调用的频率、耗时、token 消耗以及最终输出结果的采纳率为优化提供数据支撑。理解了这些我们就能明白编写 Skill 是在定义“原子能力”而配置 Harness 是在设计“能力如何被组织、评估和进化”。两者结合才能构建出真正适应你团队、具有生命力的 AI 编程辅助体系。3. 实战编写你的第一个定制化 Skill理论说再多不如动手。我们以一个实际且高频的需求为例为一个前端项目编写一个“Vue 3 Composition API 工具函数生成” Skill。这个 Skill 的意图是当开发者描述一个工具函数的功能时如“一个防抖函数”能自动生成符合项目规范、类型完备、可直接复用的 Vue 3 Composition API 代码。3.1 环境准备与项目结构首先确保你使用的是支持 Harness 12 的 Claude Code 环境通常是桌面版或特定插件。Skill 的物理形态通常是一个目录里面包含配置文件、示例和可能的工具脚本。一个典型的 Skill 目录结构如下vue3-composable-generator/ ├── skill.yaml # Skill 的核心元数据与配置 ├── prompts/ # 提示词模板目录 │ ├── system.md # 系统角色定义 │ ├── user.md # 用户输入模板 │ └── few_shot.md # 少样本示例 ├── examples/ # 示例输入输出对用于测试和演示 │ ├── debounce.json │ └── useLocalStorage.json ├── constraints/ # 约束规则文件如 ESLint 规则子集 │ └── vue3-composable.eslint.yaml └── context_spec.yaml # 定义 Skill 所需的上下文信息3.2 核心配置解析skill.yaml与提示词工程skill.yaml是这个 Skill 的“身份证”和“说明书”。我们来看关键部分# skill.yaml name: vue3-composable-generator version: 1.0.0 description: 生成符合项目规范的 Vue 3 Composition API 工具函数。 author: YourName tags: [vue, frontend, utility, typescript] # 定义意图触发器 triggers: - type: command pattern: /gen-composable - type: natural_language patterns: [生成一个vue3组合式函数, 写一个composable用于] # 定义输入模式 input_schema: type: object properties: function_name: type: string description: 组合式函数的名称如 useDebounce description: type: string description: 功能的详细描述 options: type: object properties: is_ref_returned: { type: boolean } # ... 其他可配置项 required: [function_name, description] # 关联的提示词和上下文文件 prompts: system: prompts/system.md user_template: prompts/user.md few_shot: prompts/few_shot.md context: context_spec.yaml constraints: constraints/vue3-composable.eslint.yaml关键点解析triggers定义了如何触发这个 Skill。除了命令模式自然语言模式能让交互更自然。这里的模式要具体避免误触发。input_schema极其重要。它用 JSON Schema 定义了 Skill 需要的结构化输入。这强制用户在调用时必须提供清晰、完整的信息避免了模糊的需求描述是提升 Skill 输出质量的第一步。Harness 会据此生成一个输入表单或引导对话。接下来是提示词。system.md定义了 Skill 的“人格”和核心任务# prompts/system.md 你是一个专注于 Vue 3 开发的专家。你的任务是根据用户提供的详细描述生成高质量、类型安全、可复用的 Vue 3 Composition API 函数。 **核心原则** 1. 严格使用 script setup 语法和 Composition API。 2. 优先使用 ref 和 computed仅在必要时使用 reactive。 3. 函数必须具有完整的 TypeScript 类型定义包括参数、返回值和泛型。 4. 遵循 Vue 3 的最佳实践如正确的生命周期钩子使用、副作用清理。 5. 生成的代码必须可直接复制到 .vue 文件或 .ts 文件中使用。 **输出格式** 请直接输出完整的函数代码并附上简要的使用示例注释。不要输出任何解释性文字。user.md则是一个模板用于将input_schema接收到的结构化数据转化为给模型的自然语言指令# prompts/user.md 请生成一个名为 {{function_name}} 的 Vue 3 Composition API 函数。 函数功能描述{{description}} {% if options %} 额外要求 - 是否返回 ref{{options.is_ref_returned}} {% endif %} 请确保代码符合上述所有原则。实操心得在system提示中把“不要输出解释性文字”作为强制要求能极大提升输出结果的“即用性”。否则AI 总会附带一段说明你每次都要手动删除体验很差。另外user模板中使用{{variable}}的插值语法能确保输入信息被准确、格式化地传递。3.3 上下文与约束让 Skill 更懂你的项目context_spec.yaml定义了 Skill 执行时需要“看到”的背景信息。对于这个 Skill我们可能希望它参考项目里已有的 composable 的写法风格。# context_spec.yaml sources: - type: file_pattern patterns: - src/composables/**/*.ts - src/composables/**/*.vue purpose: 参考现有组合式函数的代码风格和工具库使用习惯 max_tokens: 2000 - type: file path: package.json purpose: 了解项目依赖的 Vue 和工具库版本constraints/vue3-composable.eslint.yaml则可以嵌入一组具体的代码规则。Harness 可以在生成后或生成过程中用这些规则对输出进行校验或引导。# 约束示例 (简化) rules: - rule: no-console level: error - rule: prefer-ref description: 在组合式函数中优先返回 ref 而非 reactive 对象除非有明确理由。 - custom_rule: pattern: any message: 禁止使用 any 类型必须使用明确的类型或泛型。通过组合精准的意图定义Schema、专业的角色提示System Prompt、项目特定的上下文和严格的代码约束你的 Skill 就不再是一个通用的代码生成器而是一个深刻理解你团队技术栈和编码规范的“虚拟专家”。4. 进阶Skill 的调试、评估与迭代演化写完 Skill 的初版只是开始。如何确保它好用并让它越用越好才是“演化”的精髓。4.1 调试与单元测试为 Skill 建立质量防线不要盲目相信第一次生成的提示词就能 work。你需要像测试普通软件一样测试你的 Skill。建立测试用例集在examples/目录下为每个典型场景创建 JSON 文件。文件应包含输入匹配input_schema和期望的输出代码片段。// examples/debounce.json { input: { function_name: useDebounce, description: 创建一个防抖函数常用于搜索框输入。返回一个经过防抖处理的 ref 值。, options: { is_ref_returned: true } }, expected_output_snippet: export function useDebounceT(value: RefT, delay 300) { ... } // 关键部分 }使用 Harness 的测试模式大多数 Harness 框架都提供了 CLI 或 UI 工具来运行这些测试用例对比实际输出与期望输出计算匹配度或进行语义相似度比较。人工审查与修正对于未通过的测试分析是提示词不清晰、上下文不足还是约束太强。反复调整提示词和配置直到在测试集上达到满意的通过率。避坑技巧测试时不要只追求代码功能正确更要关注代码风格和非功能性需求。例如生成的函数是否易于测试是否有清晰的错误处理这些在长期维护中至关重要必须在 Skill 设计阶段就通过约束和示例加以引导。4.2 部署与收集反馈让 Skill 在真实场景中运行将 Skill 部署到团队的共享 Harness 实例中。鼓励团队成员在日常工作中使用。关键在于建立低摩擦的反馈机制。内置反馈按钮配置 Harness在 Skill 生成的代码旁显示“ 采纳”、“✏️ 需修改”、“ 不适用”等快速反馈按钮。记录修正内容当用户选择“✏️ 需修改”并亲自修改了代码后Harness 可以在用户授权后记录下原始的 AI 输出和用户最终采纳的版本。这个“差异”是极其宝贵的训练数据它直接反映了 Skill 的不足和用户的真实偏好。关联上下文快照收集反馈时必须同时保存触发此次 Skill 的完整上下文输入 Schema、相关文件、对话历史。这样你才能复现问题而不是凭空猜测。4.3 数据分析与迭代演化从数据中学习定期比如每周查看 Skill 的使用数据面板使用频率哪些 Skill 最受欢迎哪些无人问津无人问津的可能是因为需求不痛、触发词难记还是效果不好采纳率这是核心指标。直接生成的代码被“ 采纳”的比例是多少如果采纳率低于 60%说明 Skill 质量有待大幅提升。平均修改时间从生成到用户修改后采纳平均花了多久修改时间过长可能意味着生成的代码离“可用”差距太大。常见修改模式通过分析“差异”数据你能发现模式。例如用户总是在生成的函数开头添加特定的导入语句或者总是修改某个命名约定。这说明你的 Skill 遗漏了项目的通用模式。基于数据的迭代提示词优化如果发现 AI 总在某个地方犯错比如错误处理方式就在system.md或few_shot.md中增加明确的指导和正面示例。上下文增强如果发现 Skill 因为不了解项目的某个工具库而生成错误代码就在context_spec.yaml中添加对该库主要 API 文档的引用。约束调整如果某个代码风格约束如强制单引号导致用户频繁修改考虑放宽这个约束或者使其可配置。创建 Skill 变体对于同一个“生成工具函数”的意图你可能会发现团队内部有“简洁派”和“稳健派”两种风格需求。这时可以基于同一个input_schema创建两个 Skill 变体vue3-composable-concise和vue3-composable-robust使用不同的system提示词一个强调简洁一个强调错误处理和日志。通过 A/B 测试观察哪个变体的采纳率更高或者让用户自行选择。这个过程——编写 → 部署 → 收集反馈 → 分析数据 → 优化迭代——就构成了 Skill 的“演化循环”。一个优秀的 Skill 不是一蹴而就的而是在真实开发环境的反馈中不断打磨、适应最终成为团队不可或缺的“标准操作程序”。5. 高阶模式Skill 的组合、管理与选型建议当个人或团队积累了十几个甚至几十个 Skills 后如何管理和使用它们就成了新问题。5.1 Skill 的组合与工作流编排Harness 的强大之处在于能让 Skills 像乐高一样组合。假设我们有一个需求“为这个新写的UserProfile.vue组件生成单元测试并检查其可访问性a11y。”你可以手动依次运行两个 Skill但更高效的方式是创建一个“组件上线检查”工作流在 Harness 中配置一个链式调用触发用户对UserProfile.vue文件执行此工作流。Skill 1单元测试生成接收该组件文件生成 Jest/Vitest 测试文件。Skill 2代码审查接收原始组件和生成的测试进行基础代码质量审查。Skill 3A11y 检查接收组件代码根据 WCAG 标准生成潜在的可访问性问题列表。汇总输出Harness 将三个 Skill 的结果整理成一份报告呈现给用户。这种编排将多个原子能力串联成一个高阶的、价值更大的复合能力极大地提升了开发效率和质量保障的自动化程度。5.2 团队 Skill 管理策略中心化仓库在内部 Git 仓库建立team-skills项目每个 Skill 一个目录方便版本管理和协作改进。分级与分类对 Skills 进行分类如“前端”、“后端”、“测试”、“DevOps”和分级如“官方推荐”、“实验性”、“已废弃”。文档与示例每个 Skill 必须包含清晰的README.md说明其意图、输入格式、使用示例和已知限制。负责人制度每个 Skill 应有明确的负责人或团队负责其维护、问题解答和基于反馈的迭代。5.3 个人 Skill 选型与“技能栈”构建面对社区海量的 Skills如网络热词中提到的测试用例生成、TDD、代码审查、UI设计、渗透测试等个人该如何选择我建议采取“核心-扩展”策略来构建你的“AI 编程技能栈”核心基础层必装解决你80%日常重复工作的 Skills。代码生成类针对你主力语言和框架的组件/函数生成 Skill。代码转换/重构类如“代码风格统一”、“语言版本迁移”如 JS 转 TS、“设计模式应用”。测试类单元测试、集成测试生成 Skill。文档类自动生成 JSDoc/TSDoc、更新README。效率增强层选装针对特定场景能大幅提升效率的 Skills。领域特定如果你做数据分析可以找“Pandas 操作生成”如果做游戏可以找“GSAP 动画技能”。代码审查集成 ESLint、Stylelint 等规则进行自动化静态检查并提出改进建议。需求澄清将模糊的自然语言需求转化为清晰的技术任务清单类似 Product Manager Skills 的功能。探索实验层关注社区热门、前沿的 Skills如“逆向分析”、“Vibe Coding”偶尔尝试了解 AI 能力的边界或许能发现意想不到的用法。安装建议不要一次性安装几十个 Skills。先从核心层开始每个 Skill 都花时间阅读其文档用几个例子测试理解其能力和局限。确保你安装的每一个 Skill你都知道在什么情况下该用它以及如何用它。否则过多的 Skills 只会造成干扰降低效率。Claude Code 配合 Harness 和 Skills正在将 AI 编程从一个“黑盒魔法”变成一个可工程化、可定制、可演化的“白盒系统”。掌握从编写到演化 Skills 的能力意味着你不仅能使用 AI更能塑造和培养专属于你和你的团队的 AI 能力。这不再是简单的工具使用而是人机协同模式下一种全新的、更高维度的“元编程”能力。 
长河君 · 2026/8/12 9:44:16 · 阅读 1.2k Claude Code技能工程实战：从编写到演化的AI编程范式
1. 项目概述从“写代码”到“演化技能”的范式转变如果你还在把 Claude Code 当成一个更聪明的代码补全工具那可能就有点“大材小用”了。最近几个月围绕 Claude Code 的讨论焦点已经从“怎么写一段函数”彻底转向了“如何构建和演化一套可复用的 Skills”。这不仅仅是功能的叠加而是一种开发范式的根本性迁移。Claude Code Harness 12 的发布以及社区里铺天盖地的 Skills 推荐、安装教程和排行榜都在指向一个核心事实AI 编程的竞争已经从模型能力的比拼进化到了“技能工程”体系的构建。简单来说Skills 就是为 Claude Code 这个“大脑”安装的“应用程序”或“插件包”。一个 Skill 封装了特定的任务理解、上下文处理逻辑和代码生成策略。比如一个“测试用例生成 Skill”不仅知道要写测试还深谙你项目中 Jest、Vitest 或 Pytest 的惯用模式甚至能根据你的代码风格生成匹配的断言语句。而“Harness”你可以理解为 Skills 的“运行时环境”和“管理框架”它负责调度、组合不同的 Skills并确保它们能在正确的上下文、遵循正确的约束下工作。Harness 12 的迭代重点就在于优化了 Skills 的编写、调试和演化的全链路体验。所以“Skills 从编写到演化”这个标题精准地概括了当前高阶玩家们的核心工作流第一步是“编写”即如何从零开始将一个模糊的需求如“帮我做代码审查”转化为一个稳定、可靠的 Skill第二步是“演化”即这个 Skill 如何在真实、复杂的项目中使用反馈数据不断自我改进适应不同的代码库和团队规范甚至与其他 Skills 协同产生“112”的效果。这个过程远比单纯调教一个 Prompt 要复杂和深刻得多。接下来我将结合实战拆解从构思一个 Skill 到让它在你团队中“活”起来并持续进化的完整路径。2. 核心思路Skill 的本质与 Harness 的定位在动手写第一行 Skill 配置之前我们必须先统一思想Skill 到底是什么它和普通的 Prompt 模板或代码片段有本质区别。2.1 Skill 的三层结构意图、上下文与约束一个成熟的 Skill绝不是一个加强版的system提示词。我认为它应该包含三个紧密耦合的层次意图层这是 Skill 的“灵魂”。它明确定义了这个 Skill 要解决什么问题其输入和输出是什么。例如“生成 React 组件单元测试”是一个意图“重构冗长函数以符合 SOLID 原则”是另一个意图。意图描述必须精准、无歧义最好能用一两个简单的用户故事User Story来定义。比如“作为开发者当我选中一个 React 函数组件时我希望 Skill 能为我生成覆盖其主要渲染逻辑和 Props 变化的 Jest 测试用例。”上下文层这是 Skill 的“眼睛和耳朵”。它决定了 Claude Code 在执行该 Skill 时能“看到”哪些信息。这包括文件上下文是只看到当前文件还是需要看到相关的导入文件、类型定义文件、测试文件范例项目上下文是否需要读取package.json、tsconfig.json或项目的目录结构来理解技术栈和配置对话历史是否参考本次会话中之前关于此代码块的讨论外部知识是否需要通过 RAG 检索项目文档、API 手册或特定的设计规范 Harness 12 强化了上下文管理的粒度允许 Skill 作者精细地控制上下文的摄入范围、优先级和格式化方式避免无关信息干扰核心任务。约束与策略层这是 Skill 的“行为准则”。它规定了代码生成必须遵守的规则。这比简单的“代码风格”要求深入得多架构约束例如“新生成的函数必须是无副作用的纯函数”“不允许使用any类型”。安全约束例如“生成的 SQL 查询必须使用参数化绑定禁止字符串拼接”。性能约束例如“循环体内的操作时间复杂度必须为 O(1)”。生成策略例如“优先使用递归而非迭代”“优先返回Result类型而非抛出异常”。 这些约束通常通过结构化、机器可读的规则配置在 Harness 中而不仅仅是写在自然语言提示里这能显著提高 AI 遵循的准确性和一致性。2.2 Harness 12从“执行器”到“演化工坊”Harness 早期版本更像一个管道把用户输入、上下文和 Skill 打包发给模型。Harness 12 的定位发生了关键转变它开始承担起 Skill 生命周期管理的职责。组合与编排支持 Skills 的链式调用Chain或并行执行Parallel。例如一个“需求澄清”Skill 的输出可以作为“TDD 测试驱动开发”Skill 的输入而“代码生成”和“代码审查”Skill 可以并行运行对比结果。反馈闭环这是“演化”的核心。Harness 12 可以更便捷地收集用户对 Skill 输出结果的反馈如“采纳”、“修改后采纳”、“拒绝”并将这些反馈与当时的输入上下文关联起来形成训练数据。A/B 测试与版本管理你可以为同一个意图部署多个不同版本的 Skill例如一个激进重构版一个保守优化版让 Harness 在后台进行小流量 A/B 测试根据采纳率等指标自动选择最优版本实现 Skill 的灰度发布与滚动更新。可观测性提供了更详细的日志和指标让你能看清一个 Skill 被调用的频率、耗时、token 消耗以及最终输出结果的采纳率为优化提供数据支撑。理解了这些我们就能明白编写 Skill 是在定义“原子能力”而配置 Harness 是在设计“能力如何被组织、评估和进化”。两者结合才能构建出真正适应你团队、具有生命力的 AI 编程辅助体系。3. 实战编写你的第一个定制化 Skill理论说再多不如动手。我们以一个实际且高频的需求为例为一个前端项目编写一个“Vue 3 Composition API 工具函数生成” Skill。这个 Skill 的意图是当开发者描述一个工具函数的功能时如“一个防抖函数”能自动生成符合项目规范、类型完备、可直接复用的 Vue 3 Composition API 代码。3.1 环境准备与项目结构首先确保你使用的是支持 Harness 12 的 Claude Code 环境通常是桌面版或特定插件。Skill 的物理形态通常是一个目录里面包含配置文件、示例和可能的工具脚本。一个典型的 Skill 目录结构如下vue3-composable-generator/ ├── skill.yaml # Skill 的核心元数据与配置 ├── prompts/ # 提示词模板目录 │ ├── system.md # 系统角色定义 │ ├── user.md # 用户输入模板 │ └── few_shot.md # 少样本示例 ├── examples/ # 示例输入输出对用于测试和演示 │ ├── debounce.json │ └── useLocalStorage.json ├── constraints/ # 约束规则文件如 ESLint 规则子集 │ └── vue3-composable.eslint.yaml └── context_spec.yaml # 定义 Skill 所需的上下文信息3.2 核心配置解析skill.yaml与提示词工程skill.yaml是这个 Skill 的“身份证”和“说明书”。我们来看关键部分# skill.yaml name: vue3-composable-generator version: 1.0.0 description: 生成符合项目规范的 Vue 3 Composition API 工具函数。 author: YourName tags: [vue, frontend, utility, typescript] # 定义意图触发器 triggers: - type: command pattern: /gen-composable - type: natural_language patterns: [生成一个vue3组合式函数, 写一个composable用于] # 定义输入模式 input_schema: type: object properties: function_name: type: string description: 组合式函数的名称如 useDebounce description: type: string description: 功能的详细描述 options: type: object properties: is_ref_returned: { type: boolean } # ... 其他可配置项 required: [function_name, description] # 关联的提示词和上下文文件 prompts: system: prompts/system.md user_template: prompts/user.md few_shot: prompts/few_shot.md context: context_spec.yaml constraints: constraints/vue3-composable.eslint.yaml关键点解析triggers定义了如何触发这个 Skill。除了命令模式自然语言模式能让交互更自然。这里的模式要具体避免误触发。input_schema极其重要。它用 JSON Schema 定义了 Skill 需要的结构化输入。这强制用户在调用时必须提供清晰、完整的信息避免了模糊的需求描述是提升 Skill 输出质量的第一步。Harness 会据此生成一个输入表单或引导对话。接下来是提示词。system.md定义了 Skill 的“人格”和核心任务# prompts/system.md 你是一个专注于 Vue 3 开发的专家。你的任务是根据用户提供的详细描述生成高质量、类型安全、可复用的 Vue 3 Composition API 函数。 **核心原则** 1. 严格使用 script setup 语法和 Composition API。 2. 优先使用 ref 和 computed仅在必要时使用 reactive。 3. 函数必须具有完整的 TypeScript 类型定义包括参数、返回值和泛型。 4. 遵循 Vue 3 的最佳实践如正确的生命周期钩子使用、副作用清理。 5. 生成的代码必须可直接复制到 .vue 文件或 .ts 文件中使用。 **输出格式** 请直接输出完整的函数代码并附上简要的使用示例注释。不要输出任何解释性文字。user.md则是一个模板用于将input_schema接收到的结构化数据转化为给模型的自然语言指令# prompts/user.md 请生成一个名为 {{function_name}} 的 Vue 3 Composition API 函数。 函数功能描述{{description}} {% if options %} 额外要求 - 是否返回 ref{{options.is_ref_returned}} {% endif %} 请确保代码符合上述所有原则。实操心得在system提示中把“不要输出解释性文字”作为强制要求能极大提升输出结果的“即用性”。否则AI 总会附带一段说明你每次都要手动删除体验很差。另外user模板中使用{{variable}}的插值语法能确保输入信息被准确、格式化地传递。3.3 上下文与约束让 Skill 更懂你的项目context_spec.yaml定义了 Skill 执行时需要“看到”的背景信息。对于这个 Skill我们可能希望它参考项目里已有的 composable 的写法风格。# context_spec.yaml sources: - type: file_pattern patterns: - src/composables/**/*.ts - src/composables/**/*.vue purpose: 参考现有组合式函数的代码风格和工具库使用习惯 max_tokens: 2000 - type: file path: package.json purpose: 了解项目依赖的 Vue 和工具库版本constraints/vue3-composable.eslint.yaml则可以嵌入一组具体的代码规则。Harness 可以在生成后或生成过程中用这些规则对输出进行校验或引导。# 约束示例 (简化) rules: - rule: no-console level: error - rule: prefer-ref description: 在组合式函数中优先返回 ref 而非 reactive 对象除非有明确理由。 - custom_rule: pattern: any message: 禁止使用 any 类型必须使用明确的类型或泛型。通过组合精准的意图定义Schema、专业的角色提示System Prompt、项目特定的上下文和严格的代码约束你的 Skill 就不再是一个通用的代码生成器而是一个深刻理解你团队技术栈和编码规范的“虚拟专家”。4. 进阶Skill 的调试、评估与迭代演化写完 Skill 的初版只是开始。如何确保它好用并让它越用越好才是“演化”的精髓。4.1 调试与单元测试为 Skill 建立质量防线不要盲目相信第一次生成的提示词就能 work。你需要像测试普通软件一样测试你的 Skill。建立测试用例集在examples/目录下为每个典型场景创建 JSON 文件。文件应包含输入匹配input_schema和期望的输出代码片段。// examples/debounce.json { input: { function_name: useDebounce, description: 创建一个防抖函数常用于搜索框输入。返回一个经过防抖处理的 ref 值。, options: { is_ref_returned: true } }, expected_output_snippet: export function useDebounceT(value: RefT, delay 300) { ... } // 关键部分 }使用 Harness 的测试模式大多数 Harness 框架都提供了 CLI 或 UI 工具来运行这些测试用例对比实际输出与期望输出计算匹配度或进行语义相似度比较。人工审查与修正对于未通过的测试分析是提示词不清晰、上下文不足还是约束太强。反复调整提示词和配置直到在测试集上达到满意的通过率。避坑技巧测试时不要只追求代码功能正确更要关注代码风格和非功能性需求。例如生成的函数是否易于测试是否有清晰的错误处理这些在长期维护中至关重要必须在 Skill 设计阶段就通过约束和示例加以引导。4.2 部署与收集反馈让 Skill 在真实场景中运行将 Skill 部署到团队的共享 Harness 实例中。鼓励团队成员在日常工作中使用。关键在于建立低摩擦的反馈机制。内置反馈按钮配置 Harness在 Skill 生成的代码旁显示“ 采纳”、“✏️ 需修改”、“ 不适用”等快速反馈按钮。记录修正内容当用户选择“✏️ 需修改”并亲自修改了代码后Harness 可以在用户授权后记录下原始的 AI 输出和用户最终采纳的版本。这个“差异”是极其宝贵的训练数据它直接反映了 Skill 的不足和用户的真实偏好。关联上下文快照收集反馈时必须同时保存触发此次 Skill 的完整上下文输入 Schema、相关文件、对话历史。这样你才能复现问题而不是凭空猜测。4.3 数据分析与迭代演化从数据中学习定期比如每周查看 Skill 的使用数据面板使用频率哪些 Skill 最受欢迎哪些无人问津无人问津的可能是因为需求不痛、触发词难记还是效果不好采纳率这是核心指标。直接生成的代码被“ 采纳”的比例是多少如果采纳率低于 60%说明 Skill 质量有待大幅提升。平均修改时间从生成到用户修改后采纳平均花了多久修改时间过长可能意味着生成的代码离“可用”差距太大。常见修改模式通过分析“差异”数据你能发现模式。例如用户总是在生成的函数开头添加特定的导入语句或者总是修改某个命名约定。这说明你的 Skill 遗漏了项目的通用模式。基于数据的迭代提示词优化如果发现 AI 总在某个地方犯错比如错误处理方式就在system.md或few_shot.md中增加明确的指导和正面示例。上下文增强如果发现 Skill 因为不了解项目的某个工具库而生成错误代码就在context_spec.yaml中添加对该库主要 API 文档的引用。约束调整如果某个代码风格约束如强制单引号导致用户频繁修改考虑放宽这个约束或者使其可配置。创建 Skill 变体对于同一个“生成工具函数”的意图你可能会发现团队内部有“简洁派”和“稳健派”两种风格需求。这时可以基于同一个input_schema创建两个 Skill 变体vue3-composable-concise和vue3-composable-robust使用不同的system提示词一个强调简洁一个强调错误处理和日志。通过 A/B 测试观察哪个变体的采纳率更高或者让用户自行选择。这个过程——编写 → 部署 → 收集反馈 → 分析数据 → 优化迭代——就构成了 Skill 的“演化循环”。一个优秀的 Skill 不是一蹴而就的而是在真实开发环境的反馈中不断打磨、适应最终成为团队不可或缺的“标准操作程序”。5. 高阶模式Skill 的组合、管理与选型建议当个人或团队积累了十几个甚至几十个 Skills 后如何管理和使用它们就成了新问题。5.1 Skill 的组合与工作流编排Harness 的强大之处在于能让 Skills 像乐高一样组合。假设我们有一个需求“为这个新写的UserProfile.vue组件生成单元测试并检查其可访问性a11y。”你可以手动依次运行两个 Skill但更高效的方式是创建一个“组件上线检查”工作流在 Harness 中配置一个链式调用触发用户对UserProfile.vue文件执行此工作流。Skill 1单元测试生成接收该组件文件生成 Jest/Vitest 测试文件。Skill 2代码审查接收原始组件和生成的测试进行基础代码质量审查。Skill 3A11y 检查接收组件代码根据 WCAG 标准生成潜在的可访问性问题列表。汇总输出Harness 将三个 Skill 的结果整理成一份报告呈现给用户。这种编排将多个原子能力串联成一个高阶的、价值更大的复合能力极大地提升了开发效率和质量保障的自动化程度。5.2 团队 Skill 管理策略中心化仓库在内部 Git 仓库建立team-skills项目每个 Skill 一个目录方便版本管理和协作改进。分级与分类对 Skills 进行分类如“前端”、“后端”、“测试”、“DevOps”和分级如“官方推荐”、“实验性”、“已废弃”。文档与示例每个 Skill 必须包含清晰的README.md说明其意图、输入格式、使用示例和已知限制。负责人制度每个 Skill 应有明确的负责人或团队负责其维护、问题解答和基于反馈的迭代。5.3 个人 Skill 选型与“技能栈”构建面对社区海量的 Skills如网络热词中提到的测试用例生成、TDD、代码审查、UI设计、渗透测试等个人该如何选择我建议采取“核心-扩展”策略来构建你的“AI 编程技能栈”核心基础层必装解决你80%日常重复工作的 Skills。代码生成类针对你主力语言和框架的组件/函数生成 Skill。代码转换/重构类如“代码风格统一”、“语言版本迁移”如 JS 转 TS、“设计模式应用”。测试类单元测试、集成测试生成 Skill。文档类自动生成 JSDoc/TSDoc、更新README。效率增强层选装针对特定场景能大幅提升效率的 Skills。领域特定如果你做数据分析可以找“Pandas 操作生成”如果做游戏可以找“GSAP 动画技能”。代码审查集成 ESLint、Stylelint 等规则进行自动化静态检查并提出改进建议。需求澄清将模糊的自然语言需求转化为清晰的技术任务清单类似 Product Manager Skills 的功能。探索实验层关注社区热门、前沿的 Skills如“逆向分析”、“Vibe Coding”偶尔尝试了解 AI 能力的边界或许能发现意想不到的用法。安装建议不要一次性安装几十个 Skills。先从核心层开始每个 Skill 都花时间阅读其文档用几个例子测试理解其能力和局限。确保你安装的每一个 Skill你都知道在什么情况下该用它以及如何用它。否则过多的 Skills 只会造成干扰降低效率。Claude Code 配合 Harness 和 Skills正在将 AI 编程从一个“黑盒魔法”变成一个可工程化、可定制、可演化的“白盒系统”。掌握从编写到演化 Skills 的能力意味着你不仅能使用 AI更能塑造和培养专属于你和你的团队的 AI 能力。这不再是简单的工具使用而是人机协同模式下一种全新的、更高维度的“元编程”能力。