AI协作实战：基于Git与Claude Design构建可复用技能库

1. 从“玩票”到“搞事”：我的AI协作技能进阶之路

大概半年前，我开始尝试把AI，特别是像Claude这样的对话模型，引入到我的日常工作和个人项目中。起初，它更像一个高级的“搜索引擎”或“语法纠错器”，帮我查查资料、润色一下邮件。但很快我就意识到，这种用法太浅了，简直是暴殄天物。真正的价值，在于把它从一个“问答机”变成一个“协作者”，一个能理解上下文、能执行复杂指令、甚至能主动提出方案的“数字伙伴”。这个过程，我称之为从“玩票”到“搞事”的转变。而最近，随着Anthropic官方推出的Claude Design的初步体验，以及我在一系列项目（尤其是涉及代码重构和版本控制）中的深度实践，我对“与AI协作”这件事有了全新的认知。这不仅仅是换了个工具，而是彻底改变了我的工作流和问题解决策略。

“搞事情”的核心，在于赋予AI明确的“技能”（Skill）和“上下文”（Context），让它在一个受控的、目标明确的框架内发挥创造力。这就像你带一个实习生，不能只丢给他一句话，而是需要给他项目背景、技术栈说明、代码规范、甚至是一些参考案例。Claude Design的出现，正是为了体系化地解决这个问题。它允许你通过结构化的方式定义复杂的任务流程，将多轮对话、代码生成、文件操作、逻辑判断等环节串联起来，形成一个可重复、可优化的“技能”。与此同时，无论你是处理一个陈年旧项目的代码重构，还是管理一个多人协作的Git仓库，版本控制（Git）都是确保一切操作可追溯、可回滚的生命线。没有良好的Git实践，和AI“搞事情”就变成了在流沙上盖楼，随时可能崩塌。

本文将分享我如何将Claude等AI工具深度整合到实际开发流程中，特别是结合Claude Design来构建可复用的技能，并严格依托Git进行版本控制，实现安全、高效的“人机协同”。我会从最基础的Git环境搭建与规范讲起，这是所有协作的基石；然后深入探讨如何为AI设计有效的“提示”（Prompt）和“技能”；接着，我会结合一个具体的“Blender插件网格重构”案例，展示Claude Design在复杂任务中的实战应用；最后，分享如何将这一切沉淀为团队资产。无论你是想优化个人工作流，还是计划在团队中推广AI协作，这些从踩坑中总结的经验，或许能帮你少走弯路。

2. 基石：无可妥协的版本控制与Git最佳实践

在和AI开始任何实质性“搞事情”之前，我们必须先打好地基。这个地基就是版本控制系统（Version Control System, VCS），而Git是当今无可争议的标准。很多人觉得Git只是用来“备份代码”或“多人合作”的，但在AI协作的语境下，它的意义远不止于此。Git是你与AI交互过程的“黑匣子”和“安全网”。每一次你让AI生成代码、修改配置、重构文件，都应该是一次独立的、可追溯的提交。这样，当AI的修改引入问题时，你可以瞬间回退；当你迭代出更好的提示词（Prompt）时，你可以对比不同版本AI的产出差异。

2.1 环境搭建：不仅仅是git install

首先，确保你有一个干净、标准的Git环境。对于Windows用户，我强烈推荐直接下载安装 Git for Windows ，它包含了Git Bash这个强大的命令行工具。安装过程有几个关键点需要注意：

• 安装路径：避免包含中文或空格的路径，例如C:\Program Files\Git是安全的。
• 默认编辑器选择：安装过程中会让你“Choosing the default editor used by Git”。这是一个容易被忽略但极其重要的选项。默认的Vim对于新手可能不太友好。我建议选择你熟悉的编辑器，比如Visual Studio Code。这样，当你遇到合并冲突或需要编辑提交信息时，会唤出你熟悉的VS Code界面，而不是令人困惑的Vim命令行。这能大幅降低操作门槛。
• 行尾转换配置：在“Configuring the line ending conversions”步骤，根据你的协作环境选择。如果项目是跨平台（Windows/macOS/Linux）的，选择“Checkout as-is, commit as-is”并配置.gitattributes文件是更专业的方式。但对于新手，选择“Checkout Windows-style, commit Unix-style”可以避免许多行尾符混乱的问题。

安装完成后，打开Git Bash或终端，进行最小化的必要配置：

git config --global user.name "Your Name" git config --global user.email "your.email@example.com" git config --global core.autocrlf input # 对于macOS/Linux用户；Windows用户若之前未特殊处理，可保持默认或设为true git config --global init.defaultBranch main # 设置默认分支名为main

2.2 核心工作流：为AI协作量身定制的Git习惯

有了Git，下一步是建立适合AI协作的工作流。核心原则是：“一次AI对话，一次特性提交”。

1. 原子化提交（Atomic Commits）：不要在一次提交中混杂多个无关的修改。例如，如果你让AI帮你重构一个函数并顺带修复了某个拼写错误，这应该是两次提交。提交信息（Commit Message）要清晰描述AI执行的任务，例如feat: refactor calculateDiscount function with AI (Claude)或fix: correct typo in README via AI suggestion。这能让你在历史记录中清晰地看到每一次AI干预的边界和目的。

2. 特性分支（Feature Branching）：永远不要在main分支上直接让AI进行大刀阔斧的修改。为每一项任务创建一个新的分支。

   git checkout -b ai-refactor-blender-mesh

   在这个分支上，你可以放心地让AI尝试各种重构方案。如果效果不理想，直接丢弃这个分支即可，main分支毫发无损。

3. 提交前的人工审查（Human Review）：AI生成的代码或文案，必须经过你的仔细审查后才能提交。Git的git diff命令是你的好朋友。在git add之后、git commit之前，使用git diff --cached来审视所有将要被提交的更改。问自己：AI理解对了吗？生成的代码符合项目规范吗？有没有引入不安全的函数或冗余的逻辑？这个审查步骤是保证质量的关键，AI是协作者，不是决策者。

4. 规范的提交信息：采用类似Conventional Commits的格式（:）。这不仅是为了好看，更是为了未来可以通过工具自动生成更新日志（Changelog）。例如：

   • feat: add AI-powered mesh simplification to plugin
   • fix: resolve vertex index overflow issue identified by AI
   • docs: update API documentation generated by Claude

2.3 应对“疑难杂症”：回退、重置与储藏

和AI协作，难免会遇到“翻车”现场。比如AI根据一个模糊的指令，把整个项目结构改得面目全非。这时，Git的“时光机”功能就至关重要。

• 撤销工作区的修改：如果AI的修改还没被git add，你可以用git checkout --丢弃对某个文件的修改，或者用git restore .丢弃所有修改。
• 撤销暂存区的修改：如果已经git add了，但还没提交，可以用git reset HEAD将文件从暂存区移回工作区。
• 回退提交：如果已经提交了，但想撤销这次提交，同时保留工作区的修改（以便重新调整），使用git reset --soft HEAD~1。如果想彻底丢弃那次提交以及之后的所有工作，使用git reset --hard HEAD~1（慎用！）。
• 储藏（Stash）当前工作：如果你正在一个分支上基于AI的产出进行修改，突然需要切换到另一个分支处理紧急问题，可以用git stash把当前未提交的修改暂时储藏起来，处理完后再用git stash pop恢复。这能保持工作流的整洁。

注意：git reset --hard和git push --force是破坏性操作，在团队协作中应极度谨慎使用，最好只在个人特性分支上操作。对于已经推送到远程仓库的提交，更推荐使用git revert来创建一个新的、反向的提交以撤销更改，这样可以保留历史记录，避免给协作者带来麻烦。

3. 核心：从零散对话到结构化“技能”设计

掌握了Git这个“安全绳”后，我们就可以更放心地与AI进行深度协作了。但直接与基础对话模型聊天，效率是低下的。你需要在每次对话中重复描述项目背景、技术栈、代码风格，这就像每次开会都要重新介绍一遍所有参会人员。“技能”（Skill）的概念，就是为了解决这个问题。它本质上是一组精心设计的、可复用的提示词（Prompt）、上下文（Context）和任务流程（Workflow）的集合。

3.1 理解“技能”与“知识”的鸿沟

在开始设计技能前，必须厘清一个关键概念：把技能当知识，是最大的坑。这是我在学习任何新工具（包括AI）时的深刻体会。知识（Knowledge）是关于“是什么”和“为什么”的信息，比如Git的命令列表、Blender的API文档。技能（Skill）则是关于“如何做”和“在什么情况下做”的能力，比如“如何用Git优雅地解决一个合并冲突”、“如何根据一个模糊的需求用Blender Python API生成一个特定类型的网格”。

很多人看了无数Git教程（知识），但一遇到实际冲突还是手足无措，就是因为缺乏对应的“技能”。AI也是如此。你可以喂给它海量的项目文档（知识），但如果你不能通过提示词引导它应用这些知识去解决具体问题（技能），它的输出就会流于表面、泛泛而谈。Claude Design等工具的出现，正是为了将“技能”结构化、流程化、可执行化。

3.2 构建一个基础技能：代码审查助手

让我们从一个简单的技能开始：创建一个“Python代码审查助手”。这个技能的目标是，当我写了一段Python代码后，能自动获得关于代码风格、潜在bug、性能问题和安全漏洞的审查意见。

一个糟糕的提示词可能是：“检查一下这段代码。”这太模糊了。一个结构化的技能应该包含以下要素：

1. 角色定义（Role）：明确告诉AI它扮演的角色。

   “你是一个经验丰富的Python高级开发工程师，专注于编写高效、整洁、安全的代码。你熟悉PEP 8规范，对常见的Python反模式和安全漏洞有深刻理解。”

2. 上下文与约束（Context & Constraints）：给出具体的审查范围和标准。

   “我将给你一段Python代码。请你从以下维度进行审查，并按优先级列出发现的问题：

   1. 语法与风格：是否符合PEP 8？命名是否清晰？有无冗余代码？
   2. 潜在缺陷：有无可能的运行时错误（如KeyError、TypeError）？边界条件处理是否完备？
   3. 性能问题：有无低效的循环或数据结构使用？算法复杂度是否可以优化？
   4. 安全问题：有无代码注入、不安全反序列化等风险？ 请为每个问题提供：1) 问题描述，2) 代码位置，3) 严重等级（高/中/低），4) 修改建议及示例代码。”

3. 输入输出格式（Input/Output Format）：规定交互的格式。

   “我的输入将是：[代码片段]。你的输出请严格使用以下Markdown格式：

   代码审查报告

   文件：[文件名]概述：[总体评价]问题列表：

   1. [严重等级] - [问题类型]
      • 位置：第X行
      • 描述：[详细描述]
      • 建议：[修改建议]”

4. 示例（Few-shot Learning）：提供一两个正反面例子，让AI更好地理解你的期望。

   “例如，对于代码data = eval(user_input)，你应当指出这是一个高风险的安全问题，建议使用ast.literal_eval或更安全的解析方法。”

将以上要素组合成一个完整的提示词模板，保存下来（比如叫code_review_python.md），这就是一个最基础的、可复用的“技能”。每次需要审查代码时，你只需要填入具体的代码片段，AI就能基于这个框架给出高质量、结构化的反馈。这比每次临时组织语言要高效和稳定得多。

3.3 进阶：多步骤工作流与Claude Design初探

简单的单轮问答技能能解决很多问题，但更复杂的任务往往需要多轮交互、条件判断和外部工具调用。这就是Claude Design这类工具发力的地方。它允许你将对话流程可视化、模块化。

以“处理用户反馈并生成开发任务”这个虚拟场景为例，一个基础的Claude Design工作流可能包含以下节点：

1. 输入节点：接收用户提交的一段模糊反馈文本（如：“这个按钮点了没反应，而且页面很卡。”）。
2. 分析节点（Claude）：第一个技能。提示词定义为：“你是一名产品经理。请分析用户反馈，将其拆解为：a) 核心问题， b) 可能的原因， c) 影响的用户场景。输出为结构化JSON。”
3. 判断节点：根据分析节点输出的JSON中的“可能的原因”字段，进行路由。如果包含“前端性能”，则流向节点4；如果包含“后端API”，则流向节点5；如果两者都有，则并行触发。
4. 前端任务生成节点（Claude）：第二个技能。提示词为：“你是一名前端技术专家。根据以下问题描述和原因，编写一个具体的、可执行的开发任务（User Story），包括标题、描述、验收标准（AC）和初步的技术实现思路。” 这个节点的输入来自节点2的输出。
5. 后端任务生成节点（Claude）：类似节点4，但专注于后端。
6. 汇总节点（Claude）：将生成的前端和后端任务汇总，格式化为标准的Jira或GitHub Issue模板。
7. 输出节点：输出最终的任务卡片。

在这个流程中，Claude Design负责调度：它将用户输入传递给“分析技能”，解析结果，根据条件决定下一步调用哪个“任务生成技能”，最后将结果汇总。你作为设计者，只需要定义好每个“技能节点”的提示词和节点之间的连接逻辑。一旦设计完成，这个工作流就可以一键运行，将一段模糊的反馈自动转化为几条清晰、可分配的开发任务。

初体验感受：Claude Design的界面直观，拖拽式构建流程降低了设计复杂技能的门槛。它最大的价值在于将“与AI的协作”从临时的、艺术性的提示词编写，变成了可工程化、可迭代、可团队共享的“技能流水线”。当然，目前它可能对复杂逻辑的判断和外部API的集成支持还在演进中，但作为构建标准化AI辅助流程的起点，它已经展现出巨大潜力。这不仅仅是“用AI”，而是开始“设计AI的工作方式”。

4. 实战：AI辅助的Blender插件网格重构案例

理论说得再多，不如一个真实案例来得透彻。假设我有一个旧的Blender插件，它用于生成一些基础几何体，但代码冗长、网格生成效率低下，且不支持新的GPU渲染API。我的目标是重构它。我将结合Git、结构化提示词和设计思维，来完成这项任务。

4.1 项目初始化与现状分析

首先，在Git中为这个重构任务创建独立分支：

git clone cd old-blender-addon git checkout -b refactor-mesh-generation

接下来，我需要让AI理解现状。我准备了一个“项目分析”技能，其提示词核心如下：

角色：你是一名资深的Blender Python API专家和软件架构师。任务：分析给定的Blender插件代码，目标是后续进行重构和性能优化。请提供以下分析：

1. 架构概述：插件的主要功能、入口点、模块划分。
2. 网格生成逻辑：找出所有创建和修改bpy.types.Mesh对象的函数。用表格列出它们，包括函数名、输入参数、输出、以及可能存在的性能瓶颈（如大量循环、逐顶点操作）。
3. 代码异味：指出不符合Pythonic风格或Blender最佳实践的地方，例如：过长的函数、重复代码、硬编码的魔法数字、错误的API使用（如直接操作bpy.data而不用bpy.ops或上下文管理器）。
4. 依赖与兼容性：检查代码中是否有已弃用（Deprecated）的API，并指出其替代方案。评估其对Blender 3.0+版本的兼容性。
5. 重构建议优先级：基于以上分析，给出一个高、中、低优先级的重构任务列表。

我将插件的主要.py文件内容粘贴给AI。AI返回了一份详细报告，其中指出：

• 核心的create_custom_mesh函数有超过200行，内部嵌套了多层循环用于计算顶点和面。
• 大量使用了bpy.ops.mesh在编辑模式下进行操作，这在脚本中效率较低。
• 存在多处直接计算法线而非使用mesh.calc_normals()。
• 顶点数据是逐个添加的，未能利用mesh.vertices.foreach_set进行批量操作，这是一个高优先级的性能瓶颈。

这份报告为我指明了重构的主攻方向。我将这份AI生成的分析报告保存为ANALYSIS.md，并提交到Git仓库，作为本次重构的“设计依据”。

git add ANALYSIS.md git commit -m “docs: add initial AI-powered code analysis report”

4.2 分步重构：性能优化与API更新

根据AI的分析，我决定首先攻击最大的性能瓶颈：顶点数据的批量处理。我设计了一个“网格生成优化”技能：

角色：你是Blender性能优化专家。上下文：以下函数通过循环逐个添加顶点和面来创建网格，效率低下。请将其重构为使用NumPy数组（如果环境允许）或至少使用foreach_set/foreach_get进行批量数据操作。同时，确保使用mesh.calc_normals()自动计算法线。要求：

1. 保持函数的输入输出接口不变。
2. 在关键修改处添加注释，解释为何这样修改能提升性能。
3. 提供重构前后的性能对比思路（例如，可以建议使用timeit模块在顶点数大于10000时进行测量）。原始代码：[附上create_custom_mesh函数片段]

AI返回了重构后的代码。关键改动是将逐顶点添加的循环：

for i in range(num_verts): vert = complex_calculation(i) # 假设是某个计算 mesh.vertices[i].co = vert

替换为批量操作：

import numpy as np vert_array = np.zeros((num_verts, 3), dtype=np.float32) for i in range(num_verts): vert_array[i] = complex_calculation(i) mesh.vertices.foreach_set("co", vert_array.ravel()) mesh.calc_normals() # 一次性计算法线

我将新代码替换旧代码，并在一个单独的性能测试脚本中验证。确认功能正常且性能显著提升后，我进行提交：

git add . git commit -m “perf: refactor mesh vertex creation to use batch operation with foreach_set”

接下来，处理已弃用的API。我使用另一个技能：“Blender API更新助手”，让AI扫描整个代码库，找出所有bpy.ops.*在脚本模式下的使用，并建议替换为对bpy.data.meshes和bmesh模块的直接操作。这个过程是迭代式的，每修改一个文件或一个模块，都运行插件测试功能，并通过Git提交，确保每一步都是可控的。

4.3 利用Claude Design串联复杂重构流程

对于更复杂的重构，比如将插件的面板UI从旧的bpy.types.Panel迁移到新的bpy.types.Panel（假设有API变化），或者整合资产浏览器（Asset Browser），手动一步步操作和提示会很繁琐。这时，我可以构思一个Claude Design工作流：

1. 输入：整个插件的__init__.py和所有操作符（Operator）类文件。
2. 节点1：UI分析：一个Claude技能，专门识别所有UI相关的类（Panel, Menu, Operator）及其属性。
3. 节点2：迁移规则应用：另一个Claude技能，其提示词内置了从旧API到新API的映射规则（例如，bl_category如何迁移到新的分类系统）。它接收节点1的输出，生成迁移后的代码草稿。
4. 节点3：代码整合与冲突检测：这个节点可以是一个简单的Python脚本（作为外部工具被Claude Design调用），它尝试将迁移后的UI代码替换回原文件，并利用git diff或抽象语法树（AST）分析工具，检测是否有语法错误或与未修改部分的冲突。
5. 节点4：人工审查点：Claude Design可以在此暂停，将生成的差异（diff）输出给我审查。我确认无误后，手动触发继续。
6. 节点5：生成测试用例：最后一个Claude技能，根据新的UI结构，为我生成一些简单的Python脚本，用于测试各个按钮和面板功能是否正常。

这个设计将重构这个复杂任务分解成了分析、转换、验证、测试等多个自动化或半自动化的步骤，而我作为主导者，只需要在关键节点进行审核和决策。这大大提升了重构的效率和可靠性。

5. 沉淀与协作：构建团队内部的AI技能库

个人技能的提升是第一步，但更大的价值在于团队共享。如果每个成员都在重复编写类似的提示词，或者用不同的方式与AI协作，就会造成巨大的效率浪费和结果的不一致。因此，我们需要将验证有效的“技能”和“工作流”沉淀下来，形成团队的“AI技能库”。

5.1 技能库的载体与形式

• 版本化的提示词库：在团队的Git仓库中（如GitLab、GitHub）创建一个/ai_skills目录。里面按照用途分类存放Markdown文件，例如：

  • /ai_skills/code_review/python.md
  • /ai_skills/refactoring/blender_api_migration.md
  • /ai_skills/writing/tech_blog_outline.md
  • /ai_skills/design/figma_component_spec.md每个文件都是一个结构化的提示词模板，包含角色、上下文、约束、示例等要素。通过Git管理，可以追溯技能的迭代历史，团队成员也可以提交合并请求（Merge Request）来改进共享技能。

• Claude Design工作流共享：如果团队使用Claude Design，可以将设计好的工作流导出为配置文件（如果是支持的格式），同样存入版本库。新成员 onboarding 时，可以直接导入这些工作流，快速获得一套标准化的AI辅助流程。

• “技能卡”文档：为每个重要技能创建一个简短的说明文档，放在团队Wiki或Notion中。文档应包括：技能名称、用途、适用场景、输入输出示例、使用注意事项、以及指向版本库中具体提示词文件的链接。

5.2 技能库的使用与迭代文化

建立库只是开始，关键在于培养使用和迭代的文化。

1. “先查库，后提问”：当成员需要AI协助完成某项任务时，应首先在技能库中搜索是否有现成的模板。这能保证输出质量的一致性。
2. “贡献优于抱怨”：如果发现某个技能效果不好，或者有了更好的提示词设计，鼓励成员直接修改文件并提交PR，而不是私下抱怨。可以在PR描述中附上新旧提示词的对比测试结果。
3. 定期复盘与优化：在团队周会或技术分享中，可以设立一个“AI技能优化”环节。分享近期使用某个技能的成功案例或失败教训，共同讨论如何改进提示词或工作流设计。
4. 与CI/CD集成（进阶）：对于一些高度重复且标准化的任务，可以考虑将AI技能集成到持续集成管道中。例如，在代码提交时，自动运行“代码审查助手”技能，并将审查结果以评论形式发布到合并请求中。这需要借助AI服务的API（如Anthropic API）和一些脚本编写。

5.3 度量与规避风险

在推广AI技能库的同时，也需要建立度量机制和风险意识。

• 效果度量：不要盲目相信AI。对于代码生成类技能，可以跟踪引入后代码评审的通过率、缺陷率的變化。对于文案类技能，可以进行A/B测试。
• 安全与合规：技能库中必须明确禁止用于生成恶意代码、进行安全攻击、或产生不当内容。所有技能，尤其是涉及处理公司内部数据的，都应经过安全审查。
• 保持主导权：反复强调，AI是强大的“副驾驶”（Copilot），但“飞行员”永远是人类。任何AI生成的代码、设计、文案，都必须经过负责人的最终审查和批准。技能库的存在是为了提升“副驾驶”的水平，而不是取代“飞行员”。

通过构建这样一个活的、不断进化的AI技能库，团队不仅能将AI的效用最大化，还能在协作中形成统一的方法论，将个人的“魔法”变成团队的“标准操作程序”。这或许才是“和AI一起搞事情”所能带来的、最深远的组织层面的变革。