这次我们聊的不是某个模型或一键包而是一套能让整个技术团队统一用上 AI 的工作方法。Matt Pocock 提出的“让整个团队用上 AI Skills 的 7 步工作法”要解决的问题很实在团队里有人已经把 AI 用得飞起有人还在复制粘贴 GPT 的回答最后出来的代码风格、文档质量、审批流程完全对不上。比起每人各自摸索更值得做的是把 AI 能力沉淀成团队级的技能包再通过一套固定流程推广到全组。先说结论这套方法不挑模型不依赖特定显卡也不需要本地部署强大的推理服务。它核心是把“提示词 工具脚本 任务流程”封装成一个可复用的 Skill技能然后像管理代码一样管理这些技能。对技术团队来说这套工作法的价值在于把个人经验变成组织资产把 AI 的输出从“一次性问答”升级成“可复用、可评测、可迭代的工程交付物”。这篇文章会按 CSDN 读者的习惯把 7 步工作法拆开讲清楚每一步该做什么、需要什么工具、有哪些可以直接抄的模板和脚本、团队落地时最容易踩哪些坑。如果你正在带团队做 AI 提效或者想把个人的 AI 工作流固化下来这篇可以直接收藏。1. 核心能力速览能力项说明方法名称Matt Pocock 的 AI Skills 7 步工作法适用对象技术团队、研发小组、AI 提效负责人核心思想把 AI 提示词、工具脚本、验证流程封装成团队可复用的 Skills硬件要求无特殊硬件要求使用云端 AI API 或现有本地模型均可启动方式通过代码仓库 Prompt 文件 Python 脚本来管理 Skill主要功能统一 AI 提示词规范、批量执行任务、接口化调用、效果度量是否支持 API支持Skill 可通过 API 服务暴露给内部工具是否支持批量任务支持可按任务队列批量调用适合场景代码生成、Code Review、文档编写、日志分析、测试用例生成不适合场景需要私有化大模型训练或超高实时性响应的场景从表格可以看出这套方法的核心并不是某个 AI 工具本身而是一套工程化的管理流程。它不关心你用的是 ChatGPT、Claude、Gemini还是本地部署的开源模型只要团队能统一调用接口就能套用这套流程。2. 适用场景与使用边界2.1 适合谁用先说适合的技术团队类型后端、前端、全栈研发团队希望让 AI 参与代码生成和审查。测试团队希望用 AI 批量生成测试用例、分析失败日志。文档维护团队需要把零散的 AI 问答整理成带版本的产品文档。技术 Leader 或 AI 提效负责人希望用一套可复制的流程推动团队 AI 使用率。这套方法最典型的场景是团队已经有人在使用 AI 编程助手但使用方式混乱、提示词不统一、输出质量忽高忽低。通过 7 步工作法把常用的提示词和流程固化成版本化的 Skill 文件让每个成员都能在几分钟内加载并执行同时保留必要的校验环节。2.2 不适合什么场景不适合对实时性要求极高的生产环境直接调用例如每秒上千次的请求因为 AI API 的延迟和成本不可控。不适合处理高度敏感的秘密数据除非你使用内部私有化部署模型否则数据可能经过第三方服务。不适合作为唯一的质量把关手段AI 生成的代码和文档必须经过人工 review。2.3 使用边界与合规提醒团队在使用 AI Skills 时必须注意三个底线第一不要把未脱敏的用户隐私数据、内部代码、商业机密直接发给外部 AI 服务。可以先用脱敏脚本处理或者选择内部部署模型。第二AI 生成的内容可能包含不准确、过时或带有版权争议的信息。尤其涉及代码、文案、创意内容时务必确认授权和版权归属。第三不要用 AI 完全替代人工决策。这位工作法强调的是“人机协作”不是“全自动无人化”。3. 环境准备与前置条件这一章介绍团队落地 AI Skills 之前需要准备的环境和工具。由于方法不依赖特定硬件下面给出的是通用清单。3.1 团队账号与 API 权限至少一个可统一计费、集中管理的 AI 服务账号例如 OpenAI、Anthropic、或云厂商的模型服务。为团队成员生成 API Key注意把 Key 的权限控制在“可调用”级别不要暴露 Secret Key。如果使用内部私有化模型则准备模型服务地址和认证信息。3.2 代码仓库与工具链建议为 Skills 建一个独立的 Git 仓库用来存放提示词模板、脚本、说明文档和示例。每个 Skill 一个目录结构如下skills/ ├── code-review/ │ ├── SKILL.md │ ├── prompt.md │ ├── validate.py │ └── examples/ ├── test-generator/ │ ├── SKILL.md │ ├── prompt.md │ └── examples/ └── doc-writer/ ├── SKILL.md ├── prompt.md └── examples/其中SKILL.md是技能描述文件prompt.md是提示词模板validate.py是验证脚本的示例examples/存放输入输出样例。3.3 语言与运行环境Python 3.9 用来写批量调用脚本。git用于版本管理。可选的jq或yq用来处理 JSON/YAML 配置。团队中的每位成员需要安装代码编辑器比如 VS Code并可以运行 Python 脚本不强制但在做 Skill 调试时更高效。3.4 环境检查清单# 检查 Python 版本 python --version # 检查 git 版本 git --version # 检查 API Key 是否已配置以环境变量的形式 echo $AI_API_KEY如果这些命令都能正常执行环境就算准备好了。注意真实项目中的 API Key 建议通过环境变量注入不要写死在 Git 仓库中。4. 安装部署与启动方式这里的“安装部署”不是部署一个大型软件而是搭建 Skills 管理的基础框架。下面介绍两种常见的启动路径命令行模式与 API 服务模式。4.1 命令行模式最小化运行把 Skills 仓库 clone 到本地然后安装项目依赖如果使用requirements.txt。git clone https://your-git-host/team-skills.git cd team-skills python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate pip install -r requirements.txt然后通过一个统一的入口脚本调用 Skill例如python run_skill.py --skill code-review --input ./target_file.py注意这个run_skill.py脚本并不存在于所有项目中需要团队根据自身情况创建。这里提供的是一个通用模板思路具体路径和参数需要自己实现。4.2 API 服务模式Team 共享当团队需要让多个成员或多个工具同时调用 Skills 时可以封装成一个轻量 HTTP 服务。这里给出一个基于 Flask 的示例只做演示from flask import Flask, request, jsonify from pathlib import Path import subprocess app Flask(__name__) app.route(/skill/skill_name, methods[POST]) def run_skill(skill_name): data request.get_json() input_text data.get(input) # 在这里调用你的实际技能脚本这里仅示意 # 真实场景中应该把 input_text 传给 skill 的 prompt 模板 result {skill: skill_name, output: generated output} return jsonify(result) if __name__ __main__: app.run(host0.0.0.0, port8000)启动方式python api_server.py启动后团队内其他工具可以通过 HTTP 调用这个服务实现“技能即服务”。5. 七步工作法详解这一章是文章的核心。Matt Pocock 的这套 7 步工作法我根据技术团队的实践做了一些工程化落地拆解每个步骤都包含目标、操作、模板和注意事项。5.1 第一步盘点现有 AI 使用场景目标知道团队成员目前在哪些地方使用 AI哪些场景有复用价值。操作在团队内部发一份简短的问卷列出常见任务代码生成、代码解释、代码审查、单元测试编写、Bug 分析、文档写作、日志分析、需求拆解等。让大家把自己常用的提示词原样贴出来附上“效果还行”和“效果差”的示例。收集后按任务类型聚类挑出出现频率最高的 58 个场景作为首批 Skills 候选。示例表格场景出现次数当前提示词是谁写的是否容易模板化代码审查103人各自不同较容易单元测试生成82人容易日志错误分析61人中等注意事项不要追求大而全一开始最多选 5 个场景。否则推广和迭代的压力会很大。5.2 第二步提炼高分提示词模板目标从团队成员的提示词中抽取最高质量的一组去重、去噪、结构化。操作从收集到的高分提示词中找出共同的关键指令例如“你是资深前端工程师”“遵循项目的代码风格”“先给出变更点再给出完整代码”。把提示词拆成固定部分和可变部分。固定部分写进prompt.md可变部分用占位符表示。为每个技能写一个简短的SKILL.md说明这个技能输入什么、输出什么、使用限制是什么。示例prompt.md代码审查技能# 角色 你是本项目的资深代码审查专家熟悉 Python 和类型安全开发。 # 任务 请审查下面传入的代码输出如下格式 1. 问题列表按严重程度排序。 2. 每个问题包含文件位置、行号、问题描述、修改建议。 3. 如果未发现严重问题请给出可选的优化建议。 # 输入 CODE_BLOCK {{ code }} /CODE_BLOCK # 输出要求 - 使用 Markdown 列表。 - 中文描述问题。 - 建议必须是可操作的不要只说“优化代码”。SKILL.md可以写成# 技能名称code-review ## 功能 对指定代码进行静态审查输出按严重程度排序的问题列表。 ## 输入参数 - code: 字符串需要审查的代码内容。 ## 输出 - 问题列表Markdown 格式。 ## 适用场景 - 合并前初步审查。 - 历史代码质量评估。 ## 不适用场景 - 不适合需要执行上下文的内存泄漏检测。注意事项提示词不是越长越好重要的是把输出格式定清楚。给模型一个可预期的输出结构后续才能实现自动化处理。5.3 第三步建立 Skills 代码仓库目标让所有技能版本化、可 review、可回滚。操作在 Git 仓库下按前面提到的目录结构组织每个 Skill。每个 Skill 至少包含SKILL.md、prompt.md和至少一个示例。代码仓库使用 Git Flow 或 GitHub Flow 管理新增或修改 Skill 必须经过 Pull Request 和评审。示例初始化命令mkdir -p skills/code-review/examples touch skills/code-review/SKILL.md touch skills/code-review/prompt.md git add . git commit -m feat: add code-review skill git push origin main注意事项这里把提示词当成代码来管理是这套方法最有价值的一步。很多团队管理不好 AI Skills就是因为技能改了一版后没有历史记录无法对比效果。5.4 第四步封装为可调用的函数或脚本目标让每个 Skill 可以被命令行或 API 调用而不仅仅是在聊天窗口里复制粘贴。操作为每个 Skill 写一个 Python 脚本读取输入、渲染提示词、调用模型 API、解析输出。统一的输入输出格式可以先定为 JSON便于后续做批量任务。示例run_code_review.pyimport os import json import requests def load_prompt_template(path): with open(path, r, encodingutf-8) as f: return f.read() def run_skill_with_code(skill_name, code_content, api_keyNone): prompt_template load_prompt_template(f./skills/{skill_name}/prompt.md) prompt prompt_template.replace({{ code }}, code_content) headers { Content-Type: application/json, Authorization: fBearer {api_key or os.getenv(AI_API_KEY)} } payload { model: your-model-name, # 需要替换为实际模型名 messages: [{role: user, content: prompt}], temperature: 0.2 } response requests.post(https://api.example.com/v1/chat/completions, headersheaders, jsonpayload, timeout120) return response.json()[choices][0][message][content] if __name__ __main__: skill code-review code open(./examples/sample.py, encodingutf-8).read() result run_skill_with_code(skill, code) print(result)这里的 API 地址、模型名、鉴权方式都需要按实际使用的服务替换。脚本核心在于渲染提示词和解析输出而不是绑定某一套接口。注意事项封装成脚本后单个成员使用 Skills 时就不再需要去考虑提示词格式只要提供输入文件即可。5.5 第五步设计评测样例与回归测试目标让技能升级时输出质量不会退化。操作为每个 Skill 准备 35 组固定输入和“可接受输出”标准。例如代码审查技能准备一份包含已知 Bug 的代码期望审查结果必须命中至少 3 个关键 Bug。在每次修改 prompt 后运行这些固定样例记录通过率。可以做一个简单的eval.py自动比对输出是否包含关键关键词。示例eval.py的核心逻辑def evaluate_output(output, expected_keywords): missing [kw for kw in expected_keywords if kw not in output] return len(missing) 0, missing # 示例 expected [未捕获异常, 内存泄漏, 参数校验] ok, missing evaluate_output(model_output, expected) print(Pass if ok else fMissing: {missing})注意事项评测样例不追求完美只要能防止大家在优化一个方面时破坏另一个方面。初期有 3 个样例就足够了。5.6 第六步团队培训和文档化目标让所有成员会用、愿意用、能反馈。操作写一个 README放在仓库根目录说明如何安装依赖、如何运行某个技能、遇到问题找谁。组织一次 1 小时的分享会演示一个 Skill 从输入文件到输出结果的完整过程。建立反馈渠道可以是 Issues、表格或者群里一个固定的消息格式例如“技能名code-review问题输出格式错误”。README 示例# Team AI Skills ## 快速开始 1. 安装依赖pip install -r requirements.txt 2. 查看示例python run_skill.py --skill code-review --input examples/sample.py 3. 更多技能~/skills/ 目录下查看 ## 如何新增技能 1. 创建目录 skills/your-skill/ 2. 编写 SKILL.md 和 prompt.md 3. 添加示例 4. 提交 PR ## 联系方式 - 维护人xxx - 反馈issues注意事项很多团队失败在培训和文档环节因为文档写得太技术化或者没有明确负责人。最低要求是每个新成员加入后能在 10 分钟内通过 README 跑通一个技能。5.7 第七步收集反馈、迭代和度量目标让 Skills 持续优化并统计使用价值。操作每次调用脚本时自动记录使用了哪个技能、输入字符数、输出字符数、耗时、模型名。这些日志可以帮助你评估成本和效果。定期例如每两周review 一次使用率最高的技能看输出是否符合预期。引入一个简单的“好评/差评”机制让用户在使用后标记结果是否有用把标记结果写入日志。示例日志记录字段{ skill: code-review, timestamp: 2025-01-01T10:00:00Z, input_chars: 1500, output_chars: 800, duration_ms: 4500, model: gpt-4o-mini, user_feedback: useful }注意事项度量的目的不是考核成员而是判断哪个技能值得继续投入。一个技能如果连续一个月使用率极低就可以考虑下架如果使用率高但在反馈中经常出现质量问题就要回头优化 prompt 或调整模型参数。6. 功能测试与效果验证6.1 功能测试基础流程团队在写完一个新的 Skill 后需要按固定流程验证用示例输入跑一次确认脚本能正常运行。人工检查输出内容是否与预期格式一致。运行评测样例看关键点是否命中。使用一个真实项目文件做一次 test run检查是否有意外输出。让另一位同事独立使用一次收集体验反馈。6.2 效果验证指标指标说明如何得到成功率输出格式符合 Skill 要求的比例人工抽检或脚本校验采纳率成员实际采纳 AI 输出的比例主观反馈或按钮统计时间节省完成相同任务所需时间对比前后计时覆盖率团队中使用过至少一个 Skill 的人数比例日志统问题回归率评测样例中失败的新版本数量自动评估6.3 预期结果与判断标准以代码审查技能为例一个成功的测试应该是输入一段包含明显空指针风险、未捕获异常、缺少边界检查的代码。输出列表中至少包含上述 3 个问题。每个问题都带有文件位置可以精确到函数名、严重程度和修改建议。输出总时长不超过 60 秒取决于模型接口速度。没有出现与代码无关的废话。如果输出质量不稳定优先调整 prompt 中的角色定位和输出格式而不是换模型。7. 接口 API 与批量任务7.1 为团队提供 API 服务当团队规模扩大后建议把 Skills 封装成统一的 HTTP API 服务让前端工具、CI/CD 流程、内部平台都能调用。下面是一个通用 Python FastAPI 示例仅说明方法需按项目调整。from fastapi import FastAPI, HTTPException from pydantic import BaseModel import subprocess import json app FastAPI() class SkillRequest(BaseModel): skill: str input_data: str app.post(/run_skill) def run_skill(req: SkillRequest): # 技术上的安全考虑这里应该使用白名单方式不能直接拼接路径 allowed_skills [code-review, test-generator, doc-writer] if req.skill not in allowed_skills: raise HTTPException(status_code400, detailunknown skill) # 实际项目中在这里调用对应的 Python 模块 # 例如 run_code_review(req.input_data) result {skill: req.skill, output: 模拟输出} return result启动uvicorn api_server:app --host 0.0.0.0 --port 8000团队内部可以通过curl测试curl -X POST http://127.0.0.1:8000/run_skill \ -H Content-Type: application/json \ -d {skill: code-review, input_data: print(\hello\)}7.2 批量任务处理批量任务的核心思路是把待处理文件目录、技能名称、输出路径放在一个任务清单里依次调用 API把结果写入指定目录。import os import json import requests from pathlib import Path def batch_run_skill(skill_name, input_dir, output_dir): Path(output_dir).mkdir(parentsTrue, exist_okTrue) for file_path in Path(input_dir).glob(*.py): content file_path.read_text(encodingutf-8) resp requests.post( http://127.0.0.1:8000/run_skill, json{skill: skill_name, input_data: content}, timeout120 ) result resp.json() out_file Path(output_dir) / f{file_path.stem}_review.md out_file.write_text(result[output], encodingutf-8) print(fProcessed {file_path.name} - {out_file.name})批量任务建议加上重试机制和错误日志。例如retry_times 3 while retry_times 0: try: resp requests.post(...) resp.raise_for_status() break except Exception as e: print(fError: {e}, retry left: {retry_times}) retry_times - 1 time.sleep(2)7.3 安全与权限开放 API 服务后必须做三件基础的事在内网网段部署不要直接暴露到公网。加一个简单的 Token 认证例如请求头中校验X-API-Key。限制请求大小避免一次传入超大代码文件导致模型接口超时。8. 资源占用与性能观察这一章讨论的是团队使用 AI Skills 时的成本与性能不涉及本地显存但同样需要“观察、度量、优化”。8.1 Token 消耗与成本每个 Skill 调用都会消耗 Token。高效果的核心是减少不必要的长提示词同时控制输出长度。建议每次调用在日志中记录输入 Token输出 Token预估费用按模型单价计算这样团队可以清楚看到哪个技能跑得最贵、哪个技能用的人最多。8.2 响应时间响应时间取决于所选模型的接口速度和网络环境。团队内部可以先测试几种不同规格的模型在同样 prompt 下的延时。若使用同一个模型可以通过减小max_tokens、降低temperature对速度影响不大以及精简 prompt 来缩短响应时间。8.3 如何降低消耗在 prompt 中尽量去掉冗余描述。重用相同的输入输出模板减少模型理解成本。使用缓存如果两个任务的输入完全相同直接返回上一次的结果。对不需要“创造性”的场景使用更低规格的模型。8.4 避免接口超时批量任务中经常会遇到个别文件内容过长导致超时。解决方案有拆分子任务比如代码审查时按函数或文件拆分。增加超时时间同时确保 API 服务端没有并发上限。将大文件做摘要后输入。这些策略需要在实战中反复调整没有固定公式。9. 常见问题与排查方法问题现象可能原因排查方式解决方案运行脚本报环境变量缺失AI_API_KEY未设置echo $AI_API_KEY在.env文件或 CI 中配置密钥同一个 Skill 输出结果差异大模型不稳定或 prompt 中未明确输出格式运行多次对照输入降低temperature强制输出 JSON批量任务跑一半报错某条请求超时或返回异常查看日志中的错误响应增加重试机制并记录失败文件成员反馈 Skills 太难用文档太简单或命令行参数不友好让新成员独立跑一遍重写 README增加示例视频或图文新版本 Skill 效果退货提示词修改导致关键点丢失运行评测样例对比回滚 prompt做 A/B 测试API 服务无法访问端口被占用或服务未启动检查进程、端口杀死旧进程或更换端口输出内容包含敏感信息输入源本身包含未脱敏数据检查日志中的输入内容增加输入脱敏步骤禁止日志记录完整输入团队成员不主动使用缺乏激励和示范观察使用数据、访谈设置内部案例分享把使用 Skills 纳入绩效加分项排查问题时先看日志再复现输入最后检查 prompt 版本。尽量在每一步都留下可追踪的信息。10. 最佳实践与使用建议这套工作法要真正在团队中落地建议遵循下面几个工程化原则。10.1 先做小闭环再扩张第一周只需要做一个 Skill选定一个高频且容易评测的场景比如“Python 代码审查”。让 3 个核心成员一起用起来跑通“输入文件 - 脚本调用 - 输出报告”的完整链路。稳定后再复制到其它场景。10.2 把 Skills 当作代码来治理提示词、验证脚本、示例、文档都要纳入 Git 管理。任何修改都必须走 MR/PR 流程。给 Skills 打标签或版本号例如v1.2.0在文档中记录每次变更的原因。这能避免“改一个词破坏所有输出”的情况。10.3 建立输入输出缓存层如果同一份代码被多次审查可以使用 MD5 哈希做缓存。对input求哈希如果结果存在直接返回上次的输出。这能大幅降低成本和延迟尤其在模型 API 价格较高时。10.4 注意隐私与版权不要将公司的私有代码、未公开设计文档、用户数据直接作为调用输入除非你有明确的合规授权。建议在调用前用脱敏工具替换变量名、路径、产品名称。输出内容若用于发布或商用必须人工复核并注明 AI 参与。10.5 保持人工最终决策权AI Skills 可以大幅提效但无法替代专业判断。尤其是在代码审查中AI 可能遗漏细微业务逻辑错误也可能给出“看起来正确但不应采纳”的建议。所以团队流程中要保留人工 review 环节不能让“AI 审查通过”成为合并的充分条件。11. 总结与下一步Matt Pocock 的这套 7 步工作法本质上是在解决团队中“个人会用 AI”和“团队用好 AI”之间的落差。它没有引入复杂的模型训练或高成本硬件而是把大家早已熟悉的 Git 工作流、脚本封装、评测回归套用到 AI Skills 管理上。对于广大的技术团队来说这套方法的最大价值是可复制、可度量、可迭代。最值得先做的一件事拉上团队里的 23 个同事选定一个高频场景比如代码审查按 7 步流程跑通一个 Skill。先不要纠结是不是用了最好的模型先把输入输出格式和评测样例固定下来再慢慢优化 prompt。最容易踩的坑有两个一个是想一开始就做很多技能另一个是重要迭代不记录历史版本。这两个坑都容易让项目快速失去信任需要特别注意。如果你正在带团队做 AI 提效建议先把这个仓库建起来哪怕里面的 Skill 只有一个是可用的。后续可以逐步扩展代码解释、测试生成、日志分析、需求拆解等场景。当 Skills 数量足够多时还可以考虑加入技能路由和统一网关把这套工作流真正做成一站式 AI 工程平台。
团队AI提效：AI Skills 7步工作法，把提示词变成可复用工程资产
这次我们聊的不是某个模型或一键包而是一套能让整个技术团队统一用上 AI 的工作方法。Matt Pocock 提出的“让整个团队用上 AI Skills 的 7 步工作法”要解决的问题很实在团队里有人已经把 AI 用得飞起有人还在复制粘贴 GPT 的回答最后出来的代码风格、文档质量、审批流程完全对不上。比起每人各自摸索更值得做的是把 AI 能力沉淀成团队级的技能包再通过一套固定流程推广到全组。先说结论这套方法不挑模型不依赖特定显卡也不需要本地部署强大的推理服务。它核心是把“提示词 工具脚本 任务流程”封装成一个可复用的 Skill技能然后像管理代码一样管理这些技能。对技术团队来说这套工作法的价值在于把个人经验变成组织资产把 AI 的输出从“一次性问答”升级成“可复用、可评测、可迭代的工程交付物”。这篇文章会按 CSDN 读者的习惯把 7 步工作法拆开讲清楚每一步该做什么、需要什么工具、有哪些可以直接抄的模板和脚本、团队落地时最容易踩哪些坑。如果你正在带团队做 AI 提效或者想把个人的 AI 工作流固化下来这篇可以直接收藏。1. 核心能力速览能力项说明方法名称Matt Pocock 的 AI Skills 7 步工作法适用对象技术团队、研发小组、AI 提效负责人核心思想把 AI 提示词、工具脚本、验证流程封装成团队可复用的 Skills硬件要求无特殊硬件要求使用云端 AI API 或现有本地模型均可启动方式通过代码仓库 Prompt 文件 Python 脚本来管理 Skill主要功能统一 AI 提示词规范、批量执行任务、接口化调用、效果度量是否支持 API支持Skill 可通过 API 服务暴露给内部工具是否支持批量任务支持可按任务队列批量调用适合场景代码生成、Code Review、文档编写、日志分析、测试用例生成不适合场景需要私有化大模型训练或超高实时性响应的场景从表格可以看出这套方法的核心并不是某个 AI 工具本身而是一套工程化的管理流程。它不关心你用的是 ChatGPT、Claude、Gemini还是本地部署的开源模型只要团队能统一调用接口就能套用这套流程。2. 适用场景与使用边界2.1 适合谁用先说适合的技术团队类型后端、前端、全栈研发团队希望让 AI 参与代码生成和审查。测试团队希望用 AI 批量生成测试用例、分析失败日志。文档维护团队需要把零散的 AI 问答整理成带版本的产品文档。技术 Leader 或 AI 提效负责人希望用一套可复制的流程推动团队 AI 使用率。这套方法最典型的场景是团队已经有人在使用 AI 编程助手但使用方式混乱、提示词不统一、输出质量忽高忽低。通过 7 步工作法把常用的提示词和流程固化成版本化的 Skill 文件让每个成员都能在几分钟内加载并执行同时保留必要的校验环节。2.2 不适合什么场景不适合对实时性要求极高的生产环境直接调用例如每秒上千次的请求因为 AI API 的延迟和成本不可控。不适合处理高度敏感的秘密数据除非你使用内部私有化部署模型否则数据可能经过第三方服务。不适合作为唯一的质量把关手段AI 生成的代码和文档必须经过人工 review。2.3 使用边界与合规提醒团队在使用 AI Skills 时必须注意三个底线第一不要把未脱敏的用户隐私数据、内部代码、商业机密直接发给外部 AI 服务。可以先用脱敏脚本处理或者选择内部部署模型。第二AI 生成的内容可能包含不准确、过时或带有版权争议的信息。尤其涉及代码、文案、创意内容时务必确认授权和版权归属。第三不要用 AI 完全替代人工决策。这位工作法强调的是“人机协作”不是“全自动无人化”。3. 环境准备与前置条件这一章介绍团队落地 AI Skills 之前需要准备的环境和工具。由于方法不依赖特定硬件下面给出的是通用清单。3.1 团队账号与 API 权限至少一个可统一计费、集中管理的 AI 服务账号例如 OpenAI、Anthropic、或云厂商的模型服务。为团队成员生成 API Key注意把 Key 的权限控制在“可调用”级别不要暴露 Secret Key。如果使用内部私有化模型则准备模型服务地址和认证信息。3.2 代码仓库与工具链建议为 Skills 建一个独立的 Git 仓库用来存放提示词模板、脚本、说明文档和示例。每个 Skill 一个目录结构如下skills/ ├── code-review/ │ ├── SKILL.md │ ├── prompt.md │ ├── validate.py │ └── examples/ ├── test-generator/ │ ├── SKILL.md │ ├── prompt.md │ └── examples/ └── doc-writer/ ├── SKILL.md ├── prompt.md └── examples/其中SKILL.md是技能描述文件prompt.md是提示词模板validate.py是验证脚本的示例examples/存放输入输出样例。3.3 语言与运行环境Python 3.9 用来写批量调用脚本。git用于版本管理。可选的jq或yq用来处理 JSON/YAML 配置。团队中的每位成员需要安装代码编辑器比如 VS Code并可以运行 Python 脚本不强制但在做 Skill 调试时更高效。3.4 环境检查清单# 检查 Python 版本 python --version # 检查 git 版本 git --version # 检查 API Key 是否已配置以环境变量的形式 echo $AI_API_KEY如果这些命令都能正常执行环境就算准备好了。注意真实项目中的 API Key 建议通过环境变量注入不要写死在 Git 仓库中。4. 安装部署与启动方式这里的“安装部署”不是部署一个大型软件而是搭建 Skills 管理的基础框架。下面介绍两种常见的启动路径命令行模式与 API 服务模式。4.1 命令行模式最小化运行把 Skills 仓库 clone 到本地然后安装项目依赖如果使用requirements.txt。git clone https://your-git-host/team-skills.git cd team-skills python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate pip install -r requirements.txt然后通过一个统一的入口脚本调用 Skill例如python run_skill.py --skill code-review --input ./target_file.py注意这个run_skill.py脚本并不存在于所有项目中需要团队根据自身情况创建。这里提供的是一个通用模板思路具体路径和参数需要自己实现。4.2 API 服务模式Team 共享当团队需要让多个成员或多个工具同时调用 Skills 时可以封装成一个轻量 HTTP 服务。这里给出一个基于 Flask 的示例只做演示from flask import Flask, request, jsonify from pathlib import Path import subprocess app Flask(__name__) app.route(/skill/skill_name, methods[POST]) def run_skill(skill_name): data request.get_json() input_text data.get(input) # 在这里调用你的实际技能脚本这里仅示意 # 真实场景中应该把 input_text 传给 skill 的 prompt 模板 result {skill: skill_name, output: generated output} return jsonify(result) if __name__ __main__: app.run(host0.0.0.0, port8000)启动方式python api_server.py启动后团队内其他工具可以通过 HTTP 调用这个服务实现“技能即服务”。5. 七步工作法详解这一章是文章的核心。Matt Pocock 的这套 7 步工作法我根据技术团队的实践做了一些工程化落地拆解每个步骤都包含目标、操作、模板和注意事项。5.1 第一步盘点现有 AI 使用场景目标知道团队成员目前在哪些地方使用 AI哪些场景有复用价值。操作在团队内部发一份简短的问卷列出常见任务代码生成、代码解释、代码审查、单元测试编写、Bug 分析、文档写作、日志分析、需求拆解等。让大家把自己常用的提示词原样贴出来附上“效果还行”和“效果差”的示例。收集后按任务类型聚类挑出出现频率最高的 58 个场景作为首批 Skills 候选。示例表格场景出现次数当前提示词是谁写的是否容易模板化代码审查103人各自不同较容易单元测试生成82人容易日志错误分析61人中等注意事项不要追求大而全一开始最多选 5 个场景。否则推广和迭代的压力会很大。5.2 第二步提炼高分提示词模板目标从团队成员的提示词中抽取最高质量的一组去重、去噪、结构化。操作从收集到的高分提示词中找出共同的关键指令例如“你是资深前端工程师”“遵循项目的代码风格”“先给出变更点再给出完整代码”。把提示词拆成固定部分和可变部分。固定部分写进prompt.md可变部分用占位符表示。为每个技能写一个简短的SKILL.md说明这个技能输入什么、输出什么、使用限制是什么。示例prompt.md代码审查技能# 角色 你是本项目的资深代码审查专家熟悉 Python 和类型安全开发。 # 任务 请审查下面传入的代码输出如下格式 1. 问题列表按严重程度排序。 2. 每个问题包含文件位置、行号、问题描述、修改建议。 3. 如果未发现严重问题请给出可选的优化建议。 # 输入 CODE_BLOCK {{ code }} /CODE_BLOCK # 输出要求 - 使用 Markdown 列表。 - 中文描述问题。 - 建议必须是可操作的不要只说“优化代码”。SKILL.md可以写成# 技能名称code-review ## 功能 对指定代码进行静态审查输出按严重程度排序的问题列表。 ## 输入参数 - code: 字符串需要审查的代码内容。 ## 输出 - 问题列表Markdown 格式。 ## 适用场景 - 合并前初步审查。 - 历史代码质量评估。 ## 不适用场景 - 不适合需要执行上下文的内存泄漏检测。注意事项提示词不是越长越好重要的是把输出格式定清楚。给模型一个可预期的输出结构后续才能实现自动化处理。5.3 第三步建立 Skills 代码仓库目标让所有技能版本化、可 review、可回滚。操作在 Git 仓库下按前面提到的目录结构组织每个 Skill。每个 Skill 至少包含SKILL.md、prompt.md和至少一个示例。代码仓库使用 Git Flow 或 GitHub Flow 管理新增或修改 Skill 必须经过 Pull Request 和评审。示例初始化命令mkdir -p skills/code-review/examples touch skills/code-review/SKILL.md touch skills/code-review/prompt.md git add . git commit -m feat: add code-review skill git push origin main注意事项这里把提示词当成代码来管理是这套方法最有价值的一步。很多团队管理不好 AI Skills就是因为技能改了一版后没有历史记录无法对比效果。5.4 第四步封装为可调用的函数或脚本目标让每个 Skill 可以被命令行或 API 调用而不仅仅是在聊天窗口里复制粘贴。操作为每个 Skill 写一个 Python 脚本读取输入、渲染提示词、调用模型 API、解析输出。统一的输入输出格式可以先定为 JSON便于后续做批量任务。示例run_code_review.pyimport os import json import requests def load_prompt_template(path): with open(path, r, encodingutf-8) as f: return f.read() def run_skill_with_code(skill_name, code_content, api_keyNone): prompt_template load_prompt_template(f./skills/{skill_name}/prompt.md) prompt prompt_template.replace({{ code }}, code_content) headers { Content-Type: application/json, Authorization: fBearer {api_key or os.getenv(AI_API_KEY)} } payload { model: your-model-name, # 需要替换为实际模型名 messages: [{role: user, content: prompt}], temperature: 0.2 } response requests.post(https://api.example.com/v1/chat/completions, headersheaders, jsonpayload, timeout120) return response.json()[choices][0][message][content] if __name__ __main__: skill code-review code open(./examples/sample.py, encodingutf-8).read() result run_skill_with_code(skill, code) print(result)这里的 API 地址、模型名、鉴权方式都需要按实际使用的服务替换。脚本核心在于渲染提示词和解析输出而不是绑定某一套接口。注意事项封装成脚本后单个成员使用 Skills 时就不再需要去考虑提示词格式只要提供输入文件即可。5.5 第五步设计评测样例与回归测试目标让技能升级时输出质量不会退化。操作为每个 Skill 准备 35 组固定输入和“可接受输出”标准。例如代码审查技能准备一份包含已知 Bug 的代码期望审查结果必须命中至少 3 个关键 Bug。在每次修改 prompt 后运行这些固定样例记录通过率。可以做一个简单的eval.py自动比对输出是否包含关键关键词。示例eval.py的核心逻辑def evaluate_output(output, expected_keywords): missing [kw for kw in expected_keywords if kw not in output] return len(missing) 0, missing # 示例 expected [未捕获异常, 内存泄漏, 参数校验] ok, missing evaluate_output(model_output, expected) print(Pass if ok else fMissing: {missing})注意事项评测样例不追求完美只要能防止大家在优化一个方面时破坏另一个方面。初期有 3 个样例就足够了。5.6 第六步团队培训和文档化目标让所有成员会用、愿意用、能反馈。操作写一个 README放在仓库根目录说明如何安装依赖、如何运行某个技能、遇到问题找谁。组织一次 1 小时的分享会演示一个 Skill 从输入文件到输出结果的完整过程。建立反馈渠道可以是 Issues、表格或者群里一个固定的消息格式例如“技能名code-review问题输出格式错误”。README 示例# Team AI Skills ## 快速开始 1. 安装依赖pip install -r requirements.txt 2. 查看示例python run_skill.py --skill code-review --input examples/sample.py 3. 更多技能~/skills/ 目录下查看 ## 如何新增技能 1. 创建目录 skills/your-skill/ 2. 编写 SKILL.md 和 prompt.md 3. 添加示例 4. 提交 PR ## 联系方式 - 维护人xxx - 反馈issues注意事项很多团队失败在培训和文档环节因为文档写得太技术化或者没有明确负责人。最低要求是每个新成员加入后能在 10 分钟内通过 README 跑通一个技能。5.7 第七步收集反馈、迭代和度量目标让 Skills 持续优化并统计使用价值。操作每次调用脚本时自动记录使用了哪个技能、输入字符数、输出字符数、耗时、模型名。这些日志可以帮助你评估成本和效果。定期例如每两周review 一次使用率最高的技能看输出是否符合预期。引入一个简单的“好评/差评”机制让用户在使用后标记结果是否有用把标记结果写入日志。示例日志记录字段{ skill: code-review, timestamp: 2025-01-01T10:00:00Z, input_chars: 1500, output_chars: 800, duration_ms: 4500, model: gpt-4o-mini, user_feedback: useful }注意事项度量的目的不是考核成员而是判断哪个技能值得继续投入。一个技能如果连续一个月使用率极低就可以考虑下架如果使用率高但在反馈中经常出现质量问题就要回头优化 prompt 或调整模型参数。6. 功能测试与效果验证6.1 功能测试基础流程团队在写完一个新的 Skill 后需要按固定流程验证用示例输入跑一次确认脚本能正常运行。人工检查输出内容是否与预期格式一致。运行评测样例看关键点是否命中。使用一个真实项目文件做一次 test run检查是否有意外输出。让另一位同事独立使用一次收集体验反馈。6.2 效果验证指标指标说明如何得到成功率输出格式符合 Skill 要求的比例人工抽检或脚本校验采纳率成员实际采纳 AI 输出的比例主观反馈或按钮统计时间节省完成相同任务所需时间对比前后计时覆盖率团队中使用过至少一个 Skill 的人数比例日志统问题回归率评测样例中失败的新版本数量自动评估6.3 预期结果与判断标准以代码审查技能为例一个成功的测试应该是输入一段包含明显空指针风险、未捕获异常、缺少边界检查的代码。输出列表中至少包含上述 3 个问题。每个问题都带有文件位置可以精确到函数名、严重程度和修改建议。输出总时长不超过 60 秒取决于模型接口速度。没有出现与代码无关的废话。如果输出质量不稳定优先调整 prompt 中的角色定位和输出格式而不是换模型。7. 接口 API 与批量任务7.1 为团队提供 API 服务当团队规模扩大后建议把 Skills 封装成统一的 HTTP API 服务让前端工具、CI/CD 流程、内部平台都能调用。下面是一个通用 Python FastAPI 示例仅说明方法需按项目调整。from fastapi import FastAPI, HTTPException from pydantic import BaseModel import subprocess import json app FastAPI() class SkillRequest(BaseModel): skill: str input_data: str app.post(/run_skill) def run_skill(req: SkillRequest): # 技术上的安全考虑这里应该使用白名单方式不能直接拼接路径 allowed_skills [code-review, test-generator, doc-writer] if req.skill not in allowed_skills: raise HTTPException(status_code400, detailunknown skill) # 实际项目中在这里调用对应的 Python 模块 # 例如 run_code_review(req.input_data) result {skill: req.skill, output: 模拟输出} return result启动uvicorn api_server:app --host 0.0.0.0 --port 8000团队内部可以通过curl测试curl -X POST http://127.0.0.1:8000/run_skill \ -H Content-Type: application/json \ -d {skill: code-review, input_data: print(\hello\)}7.2 批量任务处理批量任务的核心思路是把待处理文件目录、技能名称、输出路径放在一个任务清单里依次调用 API把结果写入指定目录。import os import json import requests from pathlib import Path def batch_run_skill(skill_name, input_dir, output_dir): Path(output_dir).mkdir(parentsTrue, exist_okTrue) for file_path in Path(input_dir).glob(*.py): content file_path.read_text(encodingutf-8) resp requests.post( http://127.0.0.1:8000/run_skill, json{skill: skill_name, input_data: content}, timeout120 ) result resp.json() out_file Path(output_dir) / f{file_path.stem}_review.md out_file.write_text(result[output], encodingutf-8) print(fProcessed {file_path.name} - {out_file.name})批量任务建议加上重试机制和错误日志。例如retry_times 3 while retry_times 0: try: resp requests.post(...) resp.raise_for_status() break except Exception as e: print(fError: {e}, retry left: {retry_times}) retry_times - 1 time.sleep(2)7.3 安全与权限开放 API 服务后必须做三件基础的事在内网网段部署不要直接暴露到公网。加一个简单的 Token 认证例如请求头中校验X-API-Key。限制请求大小避免一次传入超大代码文件导致模型接口超时。8. 资源占用与性能观察这一章讨论的是团队使用 AI Skills 时的成本与性能不涉及本地显存但同样需要“观察、度量、优化”。8.1 Token 消耗与成本每个 Skill 调用都会消耗 Token。高效果的核心是减少不必要的长提示词同时控制输出长度。建议每次调用在日志中记录输入 Token输出 Token预估费用按模型单价计算这样团队可以清楚看到哪个技能跑得最贵、哪个技能用的人最多。8.2 响应时间响应时间取决于所选模型的接口速度和网络环境。团队内部可以先测试几种不同规格的模型在同样 prompt 下的延时。若使用同一个模型可以通过减小max_tokens、降低temperature对速度影响不大以及精简 prompt 来缩短响应时间。8.3 如何降低消耗在 prompt 中尽量去掉冗余描述。重用相同的输入输出模板减少模型理解成本。使用缓存如果两个任务的输入完全相同直接返回上一次的结果。对不需要“创造性”的场景使用更低规格的模型。8.4 避免接口超时批量任务中经常会遇到个别文件内容过长导致超时。解决方案有拆分子任务比如代码审查时按函数或文件拆分。增加超时时间同时确保 API 服务端没有并发上限。将大文件做摘要后输入。这些策略需要在实战中反复调整没有固定公式。9. 常见问题与排查方法问题现象可能原因排查方式解决方案运行脚本报环境变量缺失AI_API_KEY未设置echo $AI_API_KEY在.env文件或 CI 中配置密钥同一个 Skill 输出结果差异大模型不稳定或 prompt 中未明确输出格式运行多次对照输入降低temperature强制输出 JSON批量任务跑一半报错某条请求超时或返回异常查看日志中的错误响应增加重试机制并记录失败文件成员反馈 Skills 太难用文档太简单或命令行参数不友好让新成员独立跑一遍重写 README增加示例视频或图文新版本 Skill 效果退货提示词修改导致关键点丢失运行评测样例对比回滚 prompt做 A/B 测试API 服务无法访问端口被占用或服务未启动检查进程、端口杀死旧进程或更换端口输出内容包含敏感信息输入源本身包含未脱敏数据检查日志中的输入内容增加输入脱敏步骤禁止日志记录完整输入团队成员不主动使用缺乏激励和示范观察使用数据、访谈设置内部案例分享把使用 Skills 纳入绩效加分项排查问题时先看日志再复现输入最后检查 prompt 版本。尽量在每一步都留下可追踪的信息。10. 最佳实践与使用建议这套工作法要真正在团队中落地建议遵循下面几个工程化原则。10.1 先做小闭环再扩张第一周只需要做一个 Skill选定一个高频且容易评测的场景比如“Python 代码审查”。让 3 个核心成员一起用起来跑通“输入文件 - 脚本调用 - 输出报告”的完整链路。稳定后再复制到其它场景。10.2 把 Skills 当作代码来治理提示词、验证脚本、示例、文档都要纳入 Git 管理。任何修改都必须走 MR/PR 流程。给 Skills 打标签或版本号例如v1.2.0在文档中记录每次变更的原因。这能避免“改一个词破坏所有输出”的情况。10.3 建立输入输出缓存层如果同一份代码被多次审查可以使用 MD5 哈希做缓存。对input求哈希如果结果存在直接返回上次的输出。这能大幅降低成本和延迟尤其在模型 API 价格较高时。10.4 注意隐私与版权不要将公司的私有代码、未公开设计文档、用户数据直接作为调用输入除非你有明确的合规授权。建议在调用前用脱敏工具替换变量名、路径、产品名称。输出内容若用于发布或商用必须人工复核并注明 AI 参与。10.5 保持人工最终决策权AI Skills 可以大幅提效但无法替代专业判断。尤其是在代码审查中AI 可能遗漏细微业务逻辑错误也可能给出“看起来正确但不应采纳”的建议。所以团队流程中要保留人工 review 环节不能让“AI 审查通过”成为合并的充分条件。11. 总结与下一步Matt Pocock 的这套 7 步工作法本质上是在解决团队中“个人会用 AI”和“团队用好 AI”之间的落差。它没有引入复杂的模型训练或高成本硬件而是把大家早已熟悉的 Git 工作流、脚本封装、评测回归套用到 AI Skills 管理上。对于广大的技术团队来说这套方法的最大价值是可复制、可度量、可迭代。最值得先做的一件事拉上团队里的 23 个同事选定一个高频场景比如代码审查按 7 步流程跑通一个 Skill。先不要纠结是不是用了最好的模型先把输入输出格式和评测样例固定下来再慢慢优化 prompt。最容易踩的坑有两个一个是想一开始就做很多技能另一个是重要迭代不记录历史版本。这两个坑都容易让项目快速失去信任需要特别注意。如果你正在带团队做 AI 提效建议先把这个仓库建起来哪怕里面的 Skill 只有一个是可用的。后续可以逐步扩展代码解释、测试生成、日志分析、需求拆解等场景。当 Skills 数量足够多时还可以考虑加入技能路由和统一网关把这套工作流真正做成一站式 AI 工程平台。