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 协同产生“1+1>2”的效果。这个过程，远比单纯调教一个 Prompt 要复杂和深刻得多。接下来，我将结合实战，拆解从构思一个 Skill 到让它在你团队中“活”起来并持续进化的完整路径。

2. 核心思路：Skill 的本质与 Harness 的定位

在动手写第一行 Skill 配置之前，我们必须先统一思想：Skill 到底是什么？它和普通的 Prompt 模板或代码片段有本质区别。

2.1 Skill 的三层结构：意图、上下文与约束

一个成熟的 Skill，绝不是一个加强版的 system 提示词。我认为它应该包含三个紧密耦合的层次：

  1. 意图层 ：这是 Skill 的“灵魂”。它明确定义了这个 Skill 要解决什么问题，其输入和输出是什么。例如，“生成 React 组件单元测试”是一个意图，“重构冗长函数以符合 SOLID 原则”是另一个意图。意图描述必须精准、无歧义，最好能用一两个简单的用户故事（User Story）来定义。比如：“作为开发者，当我选中一个 React 函数组件时，我希望 Skill 能为我生成覆盖其主要渲染逻辑和 Props 变化的 Jest 测试用例。”

  2. 上下文层 ：这是 Skill 的“眼睛和耳朵”。它决定了 Claude Code 在执行该 Skill 时，能“看到”哪些信息。这包括：

    • 文件上下文 ：是只看到当前文件，还是需要看到相关的导入文件、类型定义文件、测试文件范例？
    • 项目上下文 ：是否需要读取 package.json 、 tsconfig.json 或项目的目录结构来理解技术栈和配置？
    • 对话历史 ：是否参考本次会话中之前关于此代码块的讨论？
    • 外部知识 ：是否需要通过 RAG 检索项目文档、API 手册或特定的设计规范？ Harness 12 强化了上下文管理的粒度，允许 Skill 作者精细地控制上下文的摄入范围、优先级和格式化方式，避免无关信息干扰核心任务。

  3. 约束与策略层 ：这是 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。

  1. 建立测试用例集 ：在 examples/ 目录下，为每个典型场景创建 JSON 文件。文件应包含输入（匹配 input_schema ）和期望的输出代码片段。 
    // examples/debounce.json
{
  "input": {
    "function_name": "useDebounce",
    "description": "创建一个防抖函数，常用于搜索框输入。返回一个经过防抖处理的 ref 值。",
    "options": { "is_ref_returned": true }
  },
  "expected_output_snippet": "export function useDebounce<T>(value: Ref<T>, delay = 300) { ... }" // 关键部分
}
  2. 使用 Harness 的测试模式 ：大多数 Harness 框架都提供了 CLI 或 UI 工具来运行这些测试用例，对比实际输出与期望输出，计算匹配度或进行语义相似度比较。
  3. 人工审查与修正 ：对于未通过的测试，分析是提示词不清晰、上下文不足还是约束太强。反复调整提示词和配置，直到在测试集上达到满意的通过率。

避坑技巧 ：测试时，不要只追求代码功能正确，更要关注 代码风格 和 非功能性需求 。例如，生成的函数是否易于测试？是否有清晰的错误处理？这些在长期维护中至关重要，必须在 Skill 设计阶段就通过约束和示例加以引导。

4.2 部署与收集反馈：让 Skill 在真实场景中运行

将 Skill 部署到团队的共享 Harness 实例中。鼓励团队成员在日常工作中使用。关键在于建立 低摩擦的反馈机制 。

  • 内置反馈按钮 ：配置 Harness，在 Skill 生成的代码旁显示“👍 采纳”、“✏️ 需修改”、“👎 不适用”等快速反馈按钮。
  • 记录修正内容 ：当用户选择“✏️ 需修改”并亲自修改了代码后，Harness 可以（在用户授权后）记录下原始的 AI 输出和用户最终采纳的版本。这个“差异”是极其宝贵的训练数据，它直接反映了 Skill 的不足和用户的真实偏好。
  • 关联上下文快照 ：收集反馈时，必须同时保存触发此次 Skill 的完整上下文（输入 Schema、相关文件、对话历史）。这样你才能复现问题，而不是凭空猜测。

4.3 数据分析与迭代演化：从数据中学习

定期（比如每周）查看 Skill 的使用数据面板：

  • 使用频率 ：哪些 Skill 最受欢迎？哪些无人问津？无人问津的可能是因为需求不痛、触发词难记，还是效果不好？
  • 采纳率 ：这是核心指标。直接生成的代码被“👍 采纳”的比例是多少？如果采纳率低于 60%，说明 Skill 质量有待大幅提升。
  • 平均修改时间 ：从生成到用户修改后采纳，平均花了多久？修改时间过长，可能意味着生成的代码离“可用”差距太大。
  • 常见修改模式 ：通过分析“差异”数据，你能发现模式。例如，用户总是在生成的函数开头添加特定的导入语句，或者总是修改某个命名约定。这说明你的 Skill 遗漏了项目的通用模式。

基于数据的迭代 ：

  1. 提示词优化 ：如果发现 AI 总在某个地方犯错（比如错误处理方式），就在 system.md 或 few_shot.md 中增加明确的指导和正面示例。
  2. 上下文增强 ：如果发现 Skill 因为不了解项目的某个工具库而生成错误代码，就在 context_spec.yaml 中添加对该库主要 API 文档的引用。
  3. 约束调整 ：如果某个代码风格约束（如强制单引号）导致用户频繁修改，考虑放宽这个约束，或者使其可配置。
  4. 创建 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 中配置一个链式调用：

  1. 触发 ：用户对 UserProfile.vue 文件执行此工作流。
  2. Skill 1：单元测试生成 ：接收该组件文件，生成 Jest/Vitest 测试文件。
  3. Skill 2：代码审查 ：接收原始组件和生成的测试，进行基础代码质量审查。
  4. Skill 3：A11y 检查 ：接收组件代码，根据 WCAG 标准生成潜在的可访问性问题列表。
  5. 汇总输出 ：Harness 将三个 Skill 的结果整理成一份报告，呈现给用户。

这种编排将多个原子能力串联成一个高阶的、价值更大的复合能力，极大地提升了开发效率和质量保障的自动化程度。

5.2 团队 Skill 管理策略

  • 中心化仓库 ：在内部 Git 仓库建立 team-skills 项目，每个 Skill 一个目录，方便版本管理和协作改进。
  • 分级与分类 ：对 Skills 进行分类（如“前端”、“后端”、“测试”、“DevOps”）和分级（如“官方推荐”、“实验性”、“已废弃”）。
  • 文档与示例 ：每个 Skill 必须包含清晰的 README.md ，说明其意图、输入格式、使用示例和已知限制。
  • 负责人制度 ：每个 Skill 应有明确的负责人（或团队），负责其维护、问题解答和基于反馈的迭代。

5.3 个人 Skill 选型与“技能栈”构建

面对社区海量的 Skills（如网络热词中提到的测试用例生成、TDD、代码审查、UI设计、渗透测试等），个人该如何选择？

我建议采取“核心-扩展”策略来构建你的“AI 编程技能栈”：

  1. 核心基础层（必装） ：解决你 80% 日常重复工作的 Skills。

    • 代码生成类 ：针对你主力语言和框架的组件/函数生成 Skill。
    • 代码转换/重构类 ：如“代码风格统一”、“语言版本迁移”（如 JS 转 TS）、“设计模式应用”。
    • 测试类 ：单元测试、集成测试生成 Skill。
    • 文档类 ：自动生成 JSDoc/TSDoc、更新 README 。

  2. 效率增强层（选装） ：针对特定场景，能大幅提升效率的 Skills。

    • 领域特定 ：如果你做数据分析，可以找“Pandas 操作生成”；如果做游戏，可以找“GSAP 动画技能”。
    • 代码审查 ：集成 ESLint、Stylelint 等规则，进行自动化静态检查并提出改进建议。
    • 需求澄清 ：将模糊的自然语言需求，转化为清晰的技术任务清单（类似 Product Manager Skills 的功能）。

  3. 探索实验层 ：关注社区热门、前沿的 Skills（如“逆向分析”、“Vibe Coding”），偶尔尝试，了解 AI 能力的边界，或许能发现意想不到的用法。

安装建议 ：不要一次性安装几十个 Skills。先从核心层开始，每个 Skill 都花时间阅读其文档，用几个例子测试，理解其能力和局限。确保你安装的每一个 Skill，你都知道在什么情况下该用它，以及如何用它。否则，过多的 Skills 只会造成干扰，降低效率。

Claude Code 配合 Harness 和 Skills，正在将 AI 编程从一个“黑盒魔法”变成一个可工程化、可定制、可演化的“白盒系统”。掌握从编写到演化 Skills 的能力，意味着你不仅能使用 AI，更能 塑造和培养 专属于你和你的团队的 AI 能力。这不再是简单的工具使用，而是人机协同模式下，一种全新的、更高维度的“元编程”能力。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

DeepSeek API涨价500%！Agent框架同步开源

avatar 亚马逊云科技技术品牌专区
cover

DeepSeek 又放大招！开源 AI Agent 框架 Harness：一切皆插件

avatar 亚马逊云科技技术品牌专区
cover

Agent Run 的状态机：别把智能体交给 LLM 自己管

avatar 亚马逊云科技技术品牌专区