1. 项目概述当AI编码成为日常我们到底在烦恼什么如果你和我一样已经深度依赖AI助手比如Claude、ChatGPT来写TypeScript代码那你一定经历过下面这些让人血压飙升的时刻你满怀期待地丢过去一个复杂需求它给你生成了一段看起来“完美”的代码你兴冲冲地复制粘贴到项目里结果编辑器瞬间被一片红色波浪线淹没——类型错误、未定义的变量、不兼容的接口……你不得不像个侦探一样在AI生成的代码和自己项目的上下文之间来回切换手动修复这些“惊喜”。或者你让它帮你重构一个函数它确实照做了但生成的代码风格和你项目里已有的代码格格不入你又得花时间去统一缩进、命名规范。更别提那些需要结合多个文件上下文才能正确实现的逻辑AI往往因为“失忆”而给出片面的、甚至错误的方案。这就是当前AI编码的四大核心痛点上下文丢失、代码风格混乱、类型安全失控以及反馈循环低效。我们不是在否定AI的能力恰恰相反是因为它太有用了我们才迫切希望它能更好地融入我们的工作流而不是成为一个需要额外“伺候”的麻烦。最近TypeScript领域的知名开发者Matt Pocock分享了他的一套名为“Skill”的工作流在社区里引起了不小的反响。这套方法不是某个新工具而是一套结合了现有工具主要是Claude Code的最佳实践和思维模式。它精准地瞄准了上述痛点提供了一套可落地的解决方案。我花了一些时间深入研究并实践了这套工作流它彻底改变了我与AI协作编码的方式。这篇文章我就来为你深度拆解Matt Pocock的Skill工作流看看它是如何系统性地解决这四大痛点的并分享我在适配和实践过程中的一些关键细节和踩坑经验。2. Skill工作流核心设计思路从“问答”到“协作”在拆解具体方案之前我们必须先理解Skill工作流背后的核心哲学。传统的AI编码模式更像是一种“问答式”或“命令式”的交互我提问你回答我下指令你执行。这种模式将AI置于一个“黑盒”执行者的角色而开发者则扮演着“需求提出者”和“质量检验员”的双重角色负担很重。Skill工作流的核心转变在于它将AI从一个“代码生成器”提升为一个“具有上下文感知能力的编码协作者”。它的设计思路围绕着以下几个关键原则展开2.1 原则一赋予AI完整的项目上下文这是解决“上下文丢失”痛点的根本。AI生成的代码之所以经常出类型错误或逻辑偏差根本原因在于它对当前项目的模块结构、类型定义、依赖关系、配置文件如tsconfig.json一无所知它只是在基于一个非常狭窄的对话窗口进行“盲猜”。Skill工作流强调在开始任何有意义的编码任务前必须首先将AI“引入门”。这意味着需要将项目的关键上下文信息主动地、结构化地提供给AI。这不仅仅是上传一两个文件而是包括项目根配置package.json了解依赖和脚本、tsconfig.json理解TypeScript编译规则和路径映射。类型定义核心项目中关键的types.ts、interfaces.ts文件或者那些导出公共类型的入口文件。相关模块与当前任务直接相关的其他源代码文件。这样做的目的是为了让AI在生成代码时其“心智模型”能与你的项目现状对齐从源头上减少因信息不对称导致的错误。2.2 原则二建立清晰、一致的代码风格契约“代码风格混乱”往往导致生成的代码难以直接集成。Skill工作流认为代码风格不应该在每次对话中靠人工描述来约定而应该作为一种“自动化契约”存在。这主要通过利用你项目中已有的静态代码检查工具来实现最重要的是ESLint和Prettier。工作流的核心步骤之一是让AI在生成代码后主动运行这些工具来格式化代码。但Matt Pocock的洞见在于更进一步他建议将项目的ESLint配置文件如.eslintrc.js和Prettier配置文件如.prettierrc也作为上下文提供给AI。AI在理解了你的具体规则比如是使用单引号还是双引号尾随逗号的规则typescript-eslint的具体规则集之后能在生成代码的第一时间就做出更符合约定的风格选择从而大幅减少后续格式化的调整工作量。2.3 原则三将类型安全作为即时反馈环对于TypeScript项目而言类型错误是最高频的“惊喜”。Skill工作流将类型检查从“事后诸葛亮”变成了“实时教练”。其操作模式不是等代码都写完了复制到编辑器里再看一片红而是在AI生成代码的同一个环境中立即运行TypeScript编译器tsc或类型检查命令tsc --noEmit进行验证。如果发现类型错误这个反馈会立即返回给AI让它自行分析错误信息并修正代码。这个过程可以循环多次直到生成的代码能通过类型检查。这相当于为AI配备了一个“TypeScript结对编程伙伴”极大地提升了生成代码的可靠性和可用性。2.4 原则四构建可复用、可组合的“技能”Skill“Skill”这个名字本身就点明了精髓。与其每次都对AI进行冗长的、重复性的上下文灌输和规则说明不如将这些固定的操作流程封装成一个个可复用的“技能”。例如“创建一个新的React组件”可以是一个Skill“添加一个新的API端点类型”可以是另一个Skill。每个Skill本质上是一个包含了预设上下文、固定操作步骤和验收条件的模板或指令集。一旦定义好开发者只需要触发这个Skill并输入具体参数比如组件名、Props类型AI就能基于预设好的高质量工作流自动执行省去了大量重复沟通成本。这是将AI协作从“手工作坊”升级到“流水线”的关键。3. 核心工具链与配置详解Matt Pocock的Skill工作流主要围绕Claude特别是Claude Code设计但其理念可以迁移到其他具备类似能力的AI编码助手。下面我结合自己的实践详细拆解所需的工具和关键配置。3.1 核心AI平台Claude Code的优势与设置Claude Code或Claude桌面应用/API是这套工作流的首选原因有几个超长上下文窗口这是实现“完整项目上下文”原则的物理基础。Claude支持高达200K的上下文足以容纳中型项目的大量关键文件。强大的代码理解与生成能力在TypeScript和现代前端栈方面表现尤为出色。文件上传与处理能力可以方便地上传整个文件夹或多个文件为AI提供素材。实操设置要点使用桌面应用或Web版聊天界面对于探索和一次性任务直接使用聊天界面通过文件上传功能提供上下文。为复杂项目创建专属对话我习惯为每个正在活跃开发的项目创建一个独立的Claude对话。在这个对话里我会一次性上传项目骨架文件package.json,tsconfig.json,.eslintrc.js等并在对话开头用System Prompt或第一条消息明确“接下来所有讨论都基于已上传的[项目名]项目上下文。”这能有效建立对话的“长期记忆”。注意Token消耗虽然上下文长但上传大量文件会消耗Token。要有策略地上传优先上传配置文件、类型定义和当前任务密切相关的模块而不是整个src目录。3.2 辅助工具让AI能执行命令这是工作流能自动化的关键。我们需要让AI不仅能“看”到我们的代码还能在我们的开发环境中“动手操作”。终端Terminal访问这是运行tsc、npm run lint、npm run test等命令的前提。在Claude Code中这意味着需要开启其代码解释器Code Interpreter功能或类似的代码执行环境。Node.js与项目依赖确保AI执行的代码环境里已经安装了项目所需的Node.js版本和所有依赖通过npm install或yarn install。通常你需要先在AI的沙盒环境中初始化项目。注意在Claude Code的沙盒环境中执行npm install可能会比较慢且每次新会话环境可能重置。对于大型项目一种折中方案是提前准备好一个package-lock.json或yarn.lock并上传node_modules中核心依赖的d.ts文件不这太复杂了。更实际的建议是对于重度依赖本地类型检查的任务最佳实践仍然是在本地开发环境中运行工作流利用AI生成代码然后手动或通过脚本在本地终端执行检查命令再将结果反馈回AI。Matt Pocock演示的“全自动”流程在沙盒环境中对小型项目可行但对复杂项目“人机协同”的半自动流程更稳健。3.3 配置文件风格与规则的基石如前所述将配置文件作为上下文至关重要。你需要准备并上传tsconfig.json让AI了解你的目标ES版本、模块系统、路径别名paths、严格模式标志等。AI会根据这个配置来理解如何正确地导入模块和通过类型检查。.eslintrc.js/.eslintrc.json定义代码质量规则。上传这个能让AI在生成代码时避免明显的风格错误例如使用还是变量命名规范等。.prettierrc定义代码格式化规则。虽然Prettier通常事后运行但AI提前知道规则后生成的代码在格式上会更“顺眼”。一个关键技巧如果你的项目使用了像antfu/eslint-config这类流行的、规则集繁多的ESLint配置直接上传整个配置文件可能内容太多。一个有效的替代方案是在给AI的指令中直接引用它“本项目使用antfu/eslint-config规则集请遵循其TypeScript和React相关规则。” 然后在要求AI执行npm run lint时它自然会应用这些规则。4. 实战演练一个完整的Skill工作流案例让我们通过一个具体的场景来串联上述所有原则和工具。假设我们要在一个现有的Next.js TypeScript项目中添加一个新的API路由端点GET /api/users/[id]/posts用于获取某个用户的帖子列表。4.1 第一步初始化上下文与定义Skill首先在Claude中为这个项目创建一个新的对话或使用已有的项目对话。初始消息提供上下文我将基于已上传的[你的项目名]项目进行开发。以下是项目关键信息摘要 - 框架Next.js 14 (App Router) - 语言TypeScript - 数据库ORMPrisma - 代码风格已配置ESLint含typescript-eslint和Prettier。 - 相关文件已上传package.json, tsconfig.json, .eslintrc.js, prisma/schema.prisma (数据模型), app/api/users/[id]/route.ts (现有的用户详情端点)。 现在请执行一个名为“创建Next.js App Router API端点”的Skill。本次任务的具体参数如下 - 方法GET - 路径/api/users/[id]/posts - 功能描述根据URL中的用户ID从数据库查询该用户发布的所有帖子并按创建时间倒序返回。需要处理用户不存在的情况。 - 依赖需使用项目已有的Prisma客户端实例可从/lib/prisma导入。这条消息完成了多件事设定了对话背景项目类型。明确了已提供的上下文文件。触发了一个预定义的“Skill”——创建API端点并给出了具体参数。4.2 第二步AI生成代码与初步检查一个足够“聪明”的AI在拥有上下文的情况下应该会进行如下操作分析需求与上下文读取prisma/schema.prisma了解User和Post模型的结构及其关系。查看tsconfig.json中的paths确认/别名指向何处。参考已有的app/api/users/[id]/route.ts学习项目API路由的编写模式比如如何处理动态参数[id]如何组织响应。生成核心代码创建文件app/api/users/[id]/posts/route.ts并生成类似以下的代码import { NextRequest, NextResponse } from next/server; import prisma from /lib/prisma; export async function GET( request: NextRequest, { params }: { params: { id: string } } ) { try { const userId params.id; // 首先检查用户是否存在 const user await prisma.user.findUnique({ where: { id: userId }, }); if (!user) { return NextResponse.json({ error: User not found }, { status: 404 }); } // 查询该用户的所有帖子 const posts await prisma.post.findMany({ where: { authorId: userId }, orderBy: { createdAt: desc }, // 可以选择性地包含作者信息 include: { author: { select: { id: name: true, email: true } } }, }); return NextResponse.json(posts); } catch (error) { console.error(Failed to fetch user posts:, error); return NextResponse.json( { error: Internal server error }, { status: 500 } ); } }执行风格与类型检查自动化环节理想的工作流中AI接下来应该自动执行# 1. 用Prettier格式化刚生成的代码 npx prettier --write app/api/users/[id]/posts/route.ts # 2. 运行ESLint检查 npx eslint app/api/users/[id]/posts/route.ts --fix # 3. 运行TypeScript类型检查针对这个文件或整个项目 npx tsc --noEmit --project .然后AI会读取这些命令的输出。如果没有错误则继续如果有错误例如/lib/prisma路径在tsconfig.json中未正确配置或者prisma.post.findMany的include参数类型错误AI会分析错误信息修正代码并重新运行检查直到通过。4.3 第三步处理反馈与迭代优化在实际操作中AI可能无法一次性通过所有检查或者你可能对生成的代码有额外的要求。这时就进入了交互优化阶段。可能的反馈循环场景A类型错误。AI报告tsc发现错误Property name does not exist on type ...。AI会分析错误发现include语句中的select结构写错了修正为author: { select: { id: true, name: true, email: true } }然后重新运行检查。场景B功能增强。你觉得返回的数据字段太多想过滤一下。你可以直接提出“请修改查询只返回id、title、createdAt和excerpt字段。” AI会修改Prisma查询的select部分并可能再次运行检查以确保类型匹配。场景C风格微调。你希望错误日志更结构化。你可以说“请将console.error替换为项目里常用的logger.error并从/lib/logger导入。” AI会照做并更新导入语句。这个“生成 - 检查 - 反馈 - 修正”的循环就是Skill工作流提升代码质量的核心机制。它将原本需要开发者手动完成的琐碎检查工作部分自动化了。4.4 第四步验收与集成当代码通过所有自动化检查类型、风格并且功能符合你的要求后这个Skill任务就完成了。你可以让AI总结一下所做的更改然后将其提供的最终代码复制到你的本地项目中。此时由于AI生成的代码已经在“模拟环境”中通过了基于你项目配置的严格检查它集成到你本地代码库后引发冲突或错误的概率就大大降低了。你只需要运行一下项目的测试如果有的话就可以相对放心地提交代码。5. 构建你自己的可复用Skill库掌握了单次任务的流程后我们可以将其固化、模板化形成个人或团队的Skill库这才是效率产生质变的关键。5.1 如何定义一个Skill一个Skill通常包含以下几个部分你可以将其保存为一个Markdown文档或笔记Skill名称清晰的任务描述如“创建React组件TypeScript Tailwind CSS”。前置条件/上下文执行此Skill前需要提供给AI的文件和信息列表。必需文件tsconfig.json,.eslintrc.js,tailwind.config.js, 相关的全局类型定义。可选文件一个类似的组件作为示例。核心指令模板一个可复用的提示词模板其中包含变量占位符。请执行“创建React组件”Skill。 参数 - 组件名称{componentName} - 组件类型FC (函数组件) - 样式方案Tailwind CSS - Props类型{propsInterface} - 位置src/components/{componentName}.tsx 要求 1. 使用interface定义Props。 2. 导出命名的函数组件。 3. 遵循项目中的ESLint和Prettier配置。 4. 生成后请运行npx tsc --noEmit和npx eslint进行检查和修复。验收标准Skill完成后的输出应满足的条件例如“无TypeScript错误”、“ESLint检查通过”、“组件可通过import正常使用”。5.2 我的常用Skill示例以下是我为自己项目积累的几个Skill示例Skill 1: 创建工具函数Utility Function上下文tsconfig.json,lib/index.ts工具函数入口。指令模板“在src/lib/utils目录下创建一个名为{functionName}的工具函数。功能描述{description}。需包含JSDoc注释、完整的TypeScript类型定义并处理边界情况。创建后运行类型检查。”Skill 2: 添加Prisma模型查询扩展上下文prisma/schema.prisma,lib/prisma.ts。指令模板“在src/lib/prisma-extensions下为{ModelName}模型添加一个名为{extensionName}的Prisma客户端扩展。功能{具体功能如‘通过邮箱查找用户若不存在则创建’}。请使用prisma.$extends方法确保类型安全。完成后检查类型。”Skill 3: 编写单元测试Vitest Testing Library上下文vitest.config.ts,tsconfig.json, 待测试的源文件。指令模板“为文件{filePath}中的{functionOrComponentName}编写单元测试。测试文件位置{testFilePath}。使用Vitest和Testing Library。覆盖主要用例和边界情况。生成测试后请尝试运行npm run test:unit -- {testFilePath}看是否通过。”5.3 Skill的管理与分享你可以使用任何你喜欢的笔记工具如Notion、Obsidian来管理这些Skill模板。在团队中可以建立一个共享的文档或Wiki将这些标准化的工作流沉淀下来新成员也能快速上手保证团队代码风格和质量的统一。6. 常见问题、局限性与应对策略尽管Skill工作流强大但在实践中仍会遇到一些挑战。以下是我遇到的一些典型问题及解决方法。6.1 上下文依然不够“聪明”问题即使上传了tsconfig.jsonAI有时还是会生成错误的路径导入比如忽略了配置中的baseUrl或paths。对策在初始指令中明确强调。“请注意本项目tsconfig.json中配置了baseUrl: ‘./src’和路径别名/*所有导入请使用以/开头的绝对路径。”6.2 自动化命令执行失败问题在Claude Code的沙盒环境中运行npm run lint可能因为缺少某些依赖或全局包而失败。对策简化命令将复杂的npm run lint可能背后是eslint . --ext .ts,.tsx --fix拆解成更直接的命令如npx eslint specific-file.ts --fix。分步指导如果环境确实受限就放弃全自动。采用“半自动”模式让AI生成代码 - 你手动在本地终端运行检查命令 - 将错误信息粘贴回对话 - AI进行修正。提供错误日志当命令失败时要求AI查看错误输出并提供解决方案。有时AI能根据错误提示建议你先行安装某个缺失的包npm install -D types/node。6.3 生成的代码逻辑有缺陷问题AI通过了类型检查但业务逻辑可能存在边缘情况漏洞或者算法效率不高。对策这是AI的固有局限无法完全避免。Skill工作流解决的是“机械性错误”类型、风格而非“逻辑性错误”。因此开发者的代码审查Code Review环节仍然不可或缺。将AI视为一个强大的初级协作者它负责完成结构正确、类型安全的“草稿”而资深开发者负责审查其业务逻辑的合理性和最优性。6.4 对大型、复杂任务的支持有限问题对于需要同时修改多个相互关联文件的重构任务AI可能难以保持全局一致性。对策将大任务拆解成多个顺序执行的小Skill。例如“重构用户认证模块”可以拆解为1) 创建新的认证类型定义2) 创建认证上下文Provider组件3) 修改登录页面使用新上下文4) 修改受保护路由组件。按顺序执行并确保每个子任务通过检查后再进行下一个。6.5 成本与效率的权衡问题为每个小任务都执行完整的“上传上下文 - 生成 - 检查”循环前期可能感觉比直接手写代码更慢。对策这确实存在学习曲线和初期效率成本。但它的回报在于代码质量显著减少了低级错误和风格不一致。知识沉淀Skill模板是可复用的团队资产。专注度提升开发者可以将认知资源更多地集中在架构设计和复杂逻辑上而不是纠结于语法和格式。 对于非常简单的、闭着眼睛都能写对的代码比如一个简单的console.log当然不需要动用这套流程。它最适合用于那些有一定复杂度、容易出错、或需要遵循严格规范的编码任务。7. 进阶技巧将工作流集成到开发环境中为了更进一步我们可以探索将Skill工作流的理念与本地开发工具结合创造更流畅的体验。7.1 结合IDE插件一些IDE插件如Cursor、Windsurf、Claude for VS Code已经深度集成了AI能力。你可以利用这些插件的“项目感知”特性它们能自动将当前打开的文件或项目结构作为上下文提供给AI省去手动上传文件的步骤。你可以在插件中自定义一些“快捷指令”这些指令本质上就是封装好的Skill。7.2 使用脚本自动化上下文收集对于经常需要提供的标准上下文配置文件可以写一个简单的Shell脚本或Node脚本将它们打包成一个临时文件或直接生成一段包含其内容的提示词。#!/bin/bash # 脚本generate_context.sh echo “### 项目上下文 ###” echo “\\\json” cat package.json echo “\\\” echo “\\\json” cat tsconfig.json echo “\\\” # ... 可以继续cat其他配置文件运行这个脚本将输出直接复制到AI对话中可以快速建立基础上下文。7.3 与Git结合进行增量开发在进行功能开发时可以让AI基于某个Git分支或提交进行工作。指令可以是“基于当前feat/user-profile分支的代码实现以下功能……”。这样AI生成的代码会更有针对性减少与现有代码的冲突。完成AI辅助编码后你仍然需要用git diff仔细审查变更然后再提交。8. 总结与个人实践心得Matt Pocock的Skill工作流不是一个神奇的银弹而是一套极具实践智慧的“方法论”。它没有引入任何新工具而是重新组织了开发者与现有强大工具AI、TypeScript、Linter之间的关系。其核心价值在于它通过流程和规范将AI的“创造力”与机器的“严谨性”结合起来让前者在后者划定的安全边界内高效发挥。从我个人的实践来看这套工作流带来的最大改变是心理负担的减轻。我不再需要时刻担心AI生成的代码会破坏项目的类型安全或代码风格因为检查环节被前置并部分自动化了。我可以更放心地将一些模式固定、但容易出错的“模板代码”交给AI去生成而自己则专注于更核心的设计和逻辑问题。开始实践时建议从一个小的、定义明确的任务开始比如“为这个接口添加一个TypeScript类型定义”。严格按照“提供上下文 - 明确指令 - 要求检查”的步骤走一遍感受整个流程。然后将这个过程记录下来形成一个你自己的第一个Skill模板。随着积累的Skill越来越多你会发现自己与AI的协作会变得越来越顺畅越来越像与一位训练有素、熟知你项目所有规矩的搭档一起编程。最后要记住工具和流程始终是为人服务的。Skill工作流是提升效率和质量的利器但最终代码的所有权和责任仍然在开发者自己手中。保持批判性思维坚持代码审查将AI作为你能力的放大器而不是替代者这才是人机协同编码的长期之道。