这次我们不聊某个具体的模型或一键包而是聊一个更偏向团队工程化的话题怎么把 ChatGPT / Copilot 这类工具里的AI Skills自定义技能从“个人玩具”变成“团队生产力”。这个主题来自 Matt Pocock 分享的《让整个团队用上 AI Skills 的 7 步工作法》。Matt Pocock 是前端圈比较熟悉的开发者也是 TypeScript 教学领域的高产作者。他在这套方法里解决的核心问题不是“某个 AI 功能怎么调”而是一个团队里有 10 个、50 个甚至更多开发者时怎么让每个人都稳定、规范、高效地用上 AI Skills而不是各写各的提示词各踩各的坑。这篇文章会把这套 7 步工作法拆开结合团队落地场景讲清楚每一步做什么、产出什么、重点验证什么。如果你正准备在团队里推 AI 编程辅助或者想把手里的 AI Skills 从“自己能用”升级成“团队都能用”这篇文章可以直接收藏。1. AI Skills 7 步工作法核心内容速览先给一个整体规格表方便快速判断这套方法适不适合你。维度说明方法论类型团队级 AI 工具落地工作流不是具体软件核心目标让 AI Skills 从个人经验沉淀为团队标准能力适用对象技术团队负责人、前端/后端 Leader、内部工具开发者前置条件团队已在使用 ChatGPT / Copilot 等支持自定义指令的 AI 工具核心步骤识别场景 → 编写 Skill → 内部测试 → 小范围试点 → 推广 → 度量 → 迭代主要产物AI Skill 文件、使用文档、测试用例、团队规范技术门槛低不需要深度算法知识需要一定 Prompt 工程能力是否需要写代码部分步骤需要比如批量测试脚本、接口集成是否支持批量任务方法论层面支持具体取决于承载 AI 工具的能力适合团队规模3 人以上即可开始适合 10 到 100 人团队这套工作法的核心不是“教 AI 怎么做”而是“教团队怎么把 AI 用法标准化”。2. 这套工作法解决什么问题先说问题再看方法。很多团队引入 AI 编程工具后实际状态是一部分人用得很溜一部分人基本不用还有一部分人乱用。具体表现通常有这几类提示词全在个人聊天记录里换个人就完全不知道别人是怎么写的。同一类任务不同成员给出的 Prompt 风格差异很大输出质量忽高忽低。AI 生成的代码风格不统一Review 成本反而上升。新人来了之后不知道项目里有哪些 AI 辅助能力也不知道怎么用。没有人维护 AI 相关的规范工具版本一更新原来的 Prompt 就失效。Matt Pocock 的 7 步工作法本质上就是把AI Skills 当成团队内部开源项目来运营。每一步都有明确的输入、产出和检查点。这套方法不适合谁如果团队只有你一个人用 AI或者大家只是偶尔拿 AI 问几个问题不需要上这么重的方法论。另外如果团队当前连代码规范、Review 流程都没有先把基础工程规范补上再考虑 AI Skills 团队化。3. 前期准备在进入 7 步之前先把基础铺好。3.1 统一 AI 工具底座AI Skills 的载体是具体的 AI 工具。ChatGPT 有自定义指令Custom Instructions / GPTsGitHub Copilot 有自定义指令文件.github/copilot-instructions.mdCline、Cursor 等工具也支持类似能力。团队层面要先定一个底线用哪个工具承载 AI Skills谁来维护配置放在哪里。一个比较稳妥的做法是把 Skills 定义文件放到 Git 仓库里和代码一起管理。这样每次修改都有记录Review 和回滚都方便。3.2 确认 AI 工具支持自定义指令不同工具的配置方式差异较大ChatGPT 团队的 Skills 可以放在工作区团队成员可见。GitHub Copilot 通过.github/copilot-instructions.md定义编码规范类指令。Cursor 通过.cursor/rules/目录定义项目级规则。其他工具可能支持AGENTS.md这类通用规则文件。在第一步先确认你用的工具支持哪种格式团队能不能共用。3.3 建立 AI Skill 目录规范建议在仓库里建一个统一目录.ai-skills/ ├── README.md ├── code-review.md ├── test-generation.md ├── refactoring.md ├── docs-writing.md └── examples/每个 Skill 一个 Markdown 文件文件名即功能名内容包含用途、触发条件、输入要求、输出格式、示例。3.4 准备测试素材每个 Skill 都要有最小测试用例。比如代码审查 Skill准备一段有明显问题的代码测试生成 Skill准备一个待覆盖的模块。这部分后面单独说。4. 七步工作法详细拆解这是本文的核心。下面把 Matt Pocock 的 7 步工作法展开每一步都说明做什么、产出什么、怎么验证。第 1 步识别高频重复场景不要一开始就想做一个“万能 AI”先把团队里高频、重复、有明确输出标准的任务列出来。典型场景举例Pull Request 代码审查第一轮筛选。为新模块生成单元测试骨架。把业务需求描述改写成用户故事。生成接口文档初稿。把一段混乱代码按项目规范格式化。根据 Git Diff 生成 Release Notes。选择标准有三个频率够高每周至少出现一次。结果可验证AI 输出有明确对错标准不是开放式闲聊。错误成本可控AI 生成的内容即使有偏差人工也能快速修正。输出物一张场景清单表格按频率和收益排序选出前 3 到 5 个作为首批 Skill。第 2 步编写 Skill 初稿写 Skill 不是写普通 Prompt。它需要包含固定结构让 AI 在不同输入下保持稳定输出。以一个“代码审查 Skill”为例推荐的结构是# Skill: 代码审查 ## 触发条件 当用户要求对一段代码进行审查时启用。 ## 输入要求 - 代码片段或仓库路径 - 编程语言 - 审查重点可选安全性、性能、可读性 ## 工作流程 1. 先整体阅读代码概括功能。 2. 按 优先级从高到低 输出问题列表。 3. 每个问题包含位置、类型、严重程度、修改建议。 4. 最后给出总体评价。 ## 输出格式 使用 Markdown 列表格式如下 - **[严重/中等/建议] 问题描述** - 位置文件:行号 - 原因... - 建议...这个 Skill 的价值在于把输出结构固定下来。不管谁来触发AI 返回的格式基本一致后续人工处理就很快。第 3 步用测试用例迭代写好的 Skill 必须测试。测试维度包括简单输入是否可靠。复杂输入是否崩溃。同一输入多次运行输出是否稳定。边界输入空内容、超长内容、混合语言表现如何。这里可以配合脚本做一个简单的自动化测试。核心逻辑是把测试输入喂给 Skill然后用规则检查输出是否包含关键字段。import requests API_URL http://127.0.0.1:11434/api/chat # 这里以 Ollama 为例实际按团队工具调整 MODEL your-model-name SKILL_FILE ./.ai-skills/code-review.md SYSTEM_PROMPT open(SKILL_FILE, encodingutf-8).read() test_cases [ {name: 简单函数, prompt: 审查以下代码\ndef add(a, b):\n return ab\n}, {name: 空代码, prompt: 审查以下代码\n}, {name: SQL注入风险, prompt: 审查以下代码\nquery f\SELECT * FROM users WHERE id {user_id}\\n}, ] for case in test_cases: response requests.post(API_URL, json{ model: MODEL, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: case[prompt]} ], stream: False }, timeout120) result response.json()[message][content] # 简单校验输出是否包含关键结构 has_output 位置 in result or 严重 in result or 建议 in result print(f{case[name]}: {通过 if has_output else 失败})注意实际运行时需要把API_URL、MODEL和SYSTEM_PROMPT替换成团队实际使用的工具配置。这一步的目的是把 Skill 测试从“手动复制粘贴”升级成“脚本批量验证”。第 4 步小范围试点Skill 初稿通过基础测试后不要立刻全员推广。先找 2 到 3 个愿意反馈的同事试用一到两周。试点阶段重点收集三类反馈输出格式是否符合预期。有没有频繁出错的情况。使用门槛是不是够低。这里容易出现一个坑写 Skill 的人觉得很好用其他人用起来完全不对。原因是写 Skill 的人默认语境太多比如默认“项目规范”指什么默认“模块”指什么。小范围试点的作用就是把这些隐含假设暴露出来然后在文档里补清楚。第 5 步推广与培训试点通过后把 Skill 的使用方式写成一页纸文档内容包括这个 Skill 能做什么不能做什么。怎么触发。输入要求。输出格式。常见失败场景和解决方案。推广时不要一次推太多一次推 1 到 2 个效果最好。太多 Skill 放出来团队根本记不住最后变成一个没人用的文档目录。第 6 步度量效果AI Skills 不能只凭感觉说“好用”要放到流程里看数据。可以度量的指标包括PR Review 平均耗时是否下降。单元测试覆盖率是否提升。文档产出时间是否缩短。Skill 触发次数工具日志里可以统计。成员反馈的满意度。度量不一定需要复杂平台。最简单的方式是在 Skill 输出里加一行“由 AI Skills 生成”的标记然后按周统计使用次数。或者让团队在 PR 描述里勾选“使用了 AI Skill”后台汇总即可。重点不是指标多精确而是让价值变得可观察。第 7 步迭代维护AI 工具迭代很快模型能力也在涨。Skill 本质上是一段指令文本需要跟随业务变化持续维护。建议节奏每月评审一次所有 Skill删除无人使用或效果差的。每次模型版本升级后重新跑一遍测试用例。新成员加入时把 Skill 文档纳入新人培训清单。每次业务规范变更同步更新相关 Skill。5. 单个 AI Skill 的编写规范与示例上面第 2 步只给了一个基础示例。这里补充一个更完整的编写规范适合团队统一使用。5.1 Skill 文件元信息每个 Skill 文件建议包含以下元信息name: code-review version: 1.0.0 owner: frontend-team last_updated: 2025-06-01 trigger: 用户要求审查代码 / PR 提交时这一部分不是给 AI 看的是给人看的。目的是让团队成员快速知道这个 Skill 归谁管、什么时候更新过。5.2 编写一个好 Skill 的关键给 AI 设边界。告诉它不要做什么比告诉它要做什么更重要。比如“不要重写整段代码只给出变更建议”。给出少量高质量示例。一个 Skill 里放 1 到 2 个输入输出示例比写 10 条模糊规则有效得多。明确输出格式。如果希望 AI 输出 JSON 供后续程序处理那就把 JSON Schema 写清楚。{ skill: code-review, result: [ { severity: error | warning | suggestion, location: file:line, description: 问题描述, suggestion: 修改建议 } ], summary: 总体评价 }写清触发条件。团队使用同一个模型时触发条件模糊会导致该触发时不触发不该触发时乱触发。6. 团队推广中的批量任务与自动化AI Skills 的团队化不只是写文档还要考虑怎么和现有 CI/CD 流程结合。一个比较现实的场景是每次 PR 自动触发代码审查 Skill把结果作为 Review 的辅助材料。大致流程如下# 伪代码演示 CI 集成逻辑 # 1. 获取 PR 的代码变更 # 2. 读取 code-review.md 作为 system prompt # 3. 把 diff 内容发给 AI 模型 # 4. 把返回结果写入 PR 评论或 Markdown 文件这属于批量任务的范畴。核心思路是Human 负责审核和决策AI Skills 负责固定模板化的初筛和整理。另外一个批量场景是文档生成。比如一个仓库里有 20 个 API 接口写一个 Skill 专门负责根据代码生成接口文档然后循环调用可以一次性产出 20 份文档初稿。批量调用的通用模板如下import glob import os # 批量处理场景示例 file_list glob.glob(./src/**/*.ts, recursiveTrue) for file_path in file_list: with open(file_path, encodingutf-8) as f: content f.read() # 这里调用 AI 工具接口传入 Skill 和文件内容 # 将返回结果写入 output 目录 output_path os.path.join(./outputs, os.path.basename(file_path) .md) # 写入逻辑省略 print(fProcessed: {file_path})需要提醒的是批量任务要控制并发避免触发工具限流。建议加一个简单的重试机制import time def call_with_retry(func, max_retries3, delay5): for attempt in range(max_retries): try: return func() except Exception as e: print(fAttempt {attempt 1} failed: {e}) time.sleep(delay) raise RuntimeError(All attempts failed)7. 落地 AI Skills 的常见问题与排查方法问题现象可能原因排查方式解决方案Skill 文档写了但没人用推广不到位文档太长入口不好找查看仓库访问量询问团队成员精简一页纸说明入口放到 README 首页每月在组会演示一次同一个 Skill 输出质量不稳定模型版本波动或 Skill 指令太模糊固定模型版本重新测试检查指令是否有歧义细化输出格式增加示例锁定模型版本Skill 对代码规范理解不对Skill 中未附带项目规范检查 Skill 输入里是否包含项目规范文件在 Skill 工作流程中加入“先读取项目规范文件”步骤批量调用被限流并发太高查看工具日志中的限流错误增加延时降低并发加入重试机制团队成员自定义修改后互相覆盖Skill 由一个人写同时被多人直接改查看 Git 提交记录建立单一负责人机制其他人通过 PR 提交修改模型对 Skill 中的指令理解不完整Skill 内容过长尝试简化指令观察哪段丢失拆分 Skill或把长说明移到示例中新人不知道 Skill 存在的意义缺少价值说明检查文档是否有“为什么用”部分在文档开头加一段 ROI 说明搭配示例演示输出格式带无关内容指令里没限制要严格 JSON检查输出尾部是否有解释文字在指令里加“只输出 JSON不要任何解释”团队用不同 AI 工具Skill 不通用各工具指令格式差异大检查是否有通用格式优先选择支持标准 Markdown 指令格式的工具或做格式转换脚本8. 合规与安全边界团队落地 AI Skills有几点必须注意。代码审查场景不要投喂敏感数据。有些团队使用云端 AI 服务直接把包含密钥、客户信息、未公开业务逻辑的代码发给模型会带来泄密风险。核心业务代码要么用私有化部署模型要么先做脱敏。Skill 中不要写入任何账号密码、内网地址、内部系统路径。Skill 文件在团队仓库里能访问仓库的人都可能看到。AI 生成代码仍需走完整 Review 流程。Skill 只能辅助生成初稿不能替代人工审查。尤其是涉及权限、支付、数据导出的代码必须人工重点核查。版权合规。不要让 AI Skills 生成大段可能涉及版权问题的代码或文案。生成内容如果需要对外发布建议先做版权评估。授权边界。如果 Skill 涉及到人脸、声音、商标等素材必须确认团队拥有合法使用授权。9. 团队 AI Skills 落地最佳实践清单综合 Matt Pocock 的方法和团队落地经验整理一份可以直接照抄的清单先定工具底座确认所有成员使用同一套支持自定义指令的 AI 工具。先选 1 到 2 个高频场景试点不要一次铺开。Skill 文件纳入 Git 管理有负责人、有版本号。每个 Skill 至少搭配 2 个测试输入覆盖正常和异常情况。设置固定输出格式包括可直接解析的 JSON 选项。国庆实测验证小规模试用至少 1 周再推广原文此处是“国庆实测”实际应为“先小范围实测”。推广时配一页纸说明控制在 15 分钟内能看懂。建立周度或月度的使用数据汇总。每月清理一次无人使用的 Skill防止文档垃圾。模型升级后重新跑一遍测试用例及时调整指令。Skill 编写过程中把项目规范文件显式引入避免模型自行推断。批量调用时必须控制并发增加重试机制记录失败日志。合规检查纳入 Skill 发布流程敏感数据、版权素材、内部信息都要排查。定期向团队收集使用反馈优先迭代被吐槽最多的点。不要把 AI Skills 当成银弹它解决的是重复劳动问题不是业务判断问题。10. 总结Matt Pocock 这套 7 步工作法核心价值不是教你怎么写一条更好的 Prompt而是把 AI 工具使用从个人行为变成团队制度。回到最初的问题怎么让整个团队用上 AI Skills答案是识别高频场景、写结构化 Skill、用测试用例迭代、小范围试点、推广、度量、迭代维护。整个过程像运营一个内部开源项目而不是发一篇文章让大家自己看。最值得先试的场景我建议是 PR 代码审查初筛和单测生成。这两个场景频率高、边界清晰、效果容易量化。最容易踩的坑是第 4 步跳太快——没有小范围试点就直接全员推广最后大概率变成“文档写了没人看”。后续如果你想继续深入可以考虑这三个方向把 Skill 接入 CI 流程实现 PR 自动初筛。把 Skill 从单体 Prompt 升级为多步 Agent 流程。在团队内部建立 Skill 贡献和评审制度让每个人都有机会提交自己的场景。建议收藏备用下个迭代周期就可以在团队里先跑一轮。