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.emailexample.com git config --global core.autocrlf input # 对于macOS/Linux用户Windows用户若之前未特殊处理可保持默认或设为true git config --global init.defaultBranch main # 设置默认分支名为main2.2 核心工作流为AI协作量身定制的Git习惯有了Git下一步是建立适合AI协作的工作流。核心原则是“一次AI对话一次特性提交”。原子化提交Atomic Commits不要在一次提交中混杂多个无关的修改。例如如果你让AI帮你重构一个函数并顺带修复了某个拼写错误这应该是两次提交。提交信息Commit Message要清晰描述AI执行的任务例如feat: refactor calculateDiscount function with AI (Claude)或fix: correct typo in README via AI suggestion。这能让你在历史记录中清晰地看到每一次AI干预的边界和目的。特性分支Feature Branching永远不要在main分支上直接让AI进行大刀阔斧的修改。为每一项任务创建一个新的分支。git checkout -b ai-refactor-blender-mesh在这个分支上你可以放心地让AI尝试各种重构方案。如果效果不理想直接丢弃这个分支即可main分支毫发无损。提交前的人工审查Human ReviewAI生成的代码或文案必须经过你的仔细审查后才能提交。Git的git diff命令是你的好朋友。在git add之后、git commit之前使用git diff --cached来审视所有将要被提交的更改。问自己AI理解对了吗生成的代码符合项目规范吗有没有引入不安全的函数或冗余的逻辑这个审查步骤是保证质量的关键AI是协作者不是决策者。规范的提交信息采用类似Conventional Commits的格式:。这不仅是为了好看更是为了未来可以通过工具自动生成更新日志Changelog。例如feat: add AI-powered mesh simplification to pluginfix: resolve vertex index overflow issue identified by AIdocs: update API documentation generated by Claude2.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、性能问题和安全漏洞的审查意见。一个糟糕的提示词可能是“检查一下这段代码。”这太模糊了。一个结构化的技能应该包含以下要素角色定义Role明确告诉AI它扮演的角色。“你是一个经验丰富的Python高级开发工程师专注于编写高效、整洁、安全的代码。你熟悉PEP 8规范对常见的Python反模式和安全漏洞有深刻理解。”上下文与约束Context Constraints给出具体的审查范围和标准。“我将给你一段Python代码。请你从以下维度进行审查并按优先级列出发现的问题语法与风格是否符合PEP 8命名是否清晰有无冗余代码潜在缺陷有无可能的运行时错误如KeyError、TypeError边界条件处理是否完备性能问题有无低效的循环或数据结构使用算法复杂度是否可以优化安全问题有无代码注入、不安全反序列化等风险 请为每个问题提供1) 问题描述2) 代码位置3) 严重等级高/中/低4) 修改建议及示例代码。”输入输出格式Input/Output Format规定交互的格式。“我的输入将是[代码片段]。你的输出请严格使用以下Markdown格式代码审查报告文件[文件名]概述[总体评价]问题列表[严重等级] - [问题类型]位置第X行描述[详细描述]建议[修改建议]”示例Few-shot Learning提供一两个正反面例子让AI更好地理解你的期望。“例如对于代码data eval(user_input)你应当指出这是一个高风险的安全问题建议使用ast.literal_eval或更安全的解析方法。”将以上要素组合成一个完整的提示词模板保存下来比如叫code_review_python.md这就是一个最基础的、可复用的“技能”。每次需要审查代码时你只需要填入具体的代码片段AI就能基于这个框架给出高质量、结构化的反馈。这比每次临时组织语言要高效和稳定得多。3.3 进阶多步骤工作流与Claude Design初探简单的单轮问答技能能解决很多问题但更复杂的任务往往需要多轮交互、条件判断和外部工具调用。这就是Claude Design这类工具发力的地方。它允许你将对话流程可视化、模块化。以“处理用户反馈并生成开发任务”这个虚拟场景为例一个基础的Claude Design工作流可能包含以下节点输入节点接收用户提交的一段模糊反馈文本如“这个按钮点了没反应而且页面很卡。”。分析节点Claude第一个技能。提示词定义为“你是一名产品经理。请分析用户反馈将其拆解为a) 核心问题 b) 可能的原因 c) 影响的用户场景。输出为结构化JSON。”判断节点根据分析节点输出的JSON中的“可能的原因”字段进行路由。如果包含“前端性能”则流向节点4如果包含“后端API”则流向节点5如果两者都有则并行触发。前端任务生成节点Claude第二个技能。提示词为“你是一名前端技术专家。根据以下问题描述和原因编写一个具体的、可执行的开发任务User Story包括标题、描述、验收标准AC和初步的技术实现思路。” 这个节点的输入来自节点2的输出。后端任务生成节点Claude类似节点4但专注于后端。汇总节点Claude将生成的前端和后端任务汇总格式化为标准的Jira或GitHub Issue模板。输出节点输出最终的任务卡片。在这个流程中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插件代码目标是后续进行重构和性能优化。请提供以下分析架构概述插件的主要功能、入口点、模块划分。网格生成逻辑找出所有创建和修改bpy.types.Mesh对象的函数。用表格列出它们包括函数名、输入参数、输出、以及可能存在的性能瓶颈如大量循环、逐顶点操作。代码异味指出不符合Pythonic风格或Blender最佳实践的地方例如过长的函数、重复代码、硬编码的魔法数字、错误的API使用如直接操作bpy.data而不用bpy.ops或上下文管理器。依赖与兼容性检查代码中是否有已弃用Deprecated的API并指出其替代方案。评估其对Blender 3.0版本的兼容性。重构建议优先级基于以上分析给出一个高、中、低优先级的重构任务列表。我将插件的主要.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()自动计算法线。要求保持函数的输入输出接口不变。在关键修改处添加注释解释为何这样修改能提升性能。提供重构前后的性能对比思路例如可以建议使用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), dtypenp.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工作流输入整个插件的__init__.py和所有操作符Operator类文件。节点1UI分析一个Claude技能专门识别所有UI相关的类Panel, Menu, Operator及其属性。节点2迁移规则应用另一个Claude技能其提示词内置了从旧API到新API的映射规则例如bl_category如何迁移到新的分类系统。它接收节点1的输出生成迁移后的代码草稿。节点3代码整合与冲突检测这个节点可以是一个简单的Python脚本作为外部工具被Claude Design调用它尝试将迁移后的UI代码替换回原文件并利用git diff或抽象语法树AST分析工具检测是否有语法错误或与未修改部分的冲突。节点4人工审查点Claude Design可以在此暂停将生成的差异diff输出给我审查。我确认无误后手动触发继续。节点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 技能库的使用与迭代文化建立库只是开始关键在于培养使用和迭代的文化。“先查库后提问”当成员需要AI协助完成某项任务时应首先在技能库中搜索是否有现成的模板。这能保证输出质量的一致性。“贡献优于抱怨”如果发现某个技能效果不好或者有了更好的提示词设计鼓励成员直接修改文件并提交PR而不是私下抱怨。可以在PR描述中附上新旧提示词的对比测试结果。定期复盘与优化在团队周会或技术分享中可以设立一个“AI技能优化”环节。分享近期使用某个技能的成功案例或失败教训共同讨论如何改进提示词或工作流设计。与CI/CD集成进阶对于一些高度重复且标准化的任务可以考虑将AI技能集成到持续集成管道中。例如在代码提交时自动运行“代码审查助手”技能并将审查结果以评论形式发布到合并请求中。这需要借助AI服务的API如Anthropic API和一些脚本编写。5.3 度量与规避风险在推广AI技能库的同时也需要建立度量机制和风险意识。效果度量不要盲目相信AI。对于代码生成类技能可以跟踪引入后代码评审的通过率、缺陷率的變化。对于文案类技能可以进行A/B测试。安全与合规技能库中必须明确禁止用于生成恶意代码、进行安全攻击、或产生不当内容。所有技能尤其是涉及处理公司内部数据的都应经过安全审查。保持主导权反复强调AI是强大的“副驾驶”Copilot但“飞行员”永远是人类。任何AI生成的代码、设计、文案都必须经过负责人的最终审查和批准。技能库的存在是为了提升“副驾驶”的水平而不是取代“飞行员”。通过构建这样一个活的、不断进化的AI技能库团队不仅能将AI的效用最大化还能在协作中形成统一的方法论将个人的“魔法”变成团队的“标准操作程序”。这或许才是“和AI一起搞事情”所能带来的、最深远的组织层面的变革。