欢迎来到本教程的最后一个实战项目项目 D团队可复用技能包Skills。在前面的实战中我们手写了 Prompt封装了工具甚至搭了状态机。但这些代码都“死死地”长在你的电脑里。如果公司里有 50 个开发人员每个人都要做 Code Review代码审查。难道每个人都要去写一遍审查的 Prompt 和跑脚本的逻辑吗这显然违背了软件工程“不重复造轮子DRY”的原则。在 AI 时代我们如何把一个高手的经验打包成全团队都能用的“即插即用”组件这就是Skills技能包的核心价值。1. 痛点被锁在脑子里的 SOP每个团队都有自己的 SOP标准作业程序。比如你们团队的 Code Review 规范必须检查有没有写中文注释。必须检查有没有把数据库密码硬编码在代码里。必须运行npm run lint且不能有 Warning。以前这些规范写在 Wiki 里新员工从来不看全靠老员工“口口相传”或者在提 PR 时破口大骂。现在我们要把这些 SOP 变成强制机器执行的 Skill。2. 怎么写 Skill把 Prompt 和工具绑在一起一个 Skill本质上就是一份**“带有执行步骤和工具约束的超强 Prompt”**。在 IDE 助手如 Trae / Cursor或团队的 Agent 平台上一个标准的 Skill 通常以一个目录的形式存在。目录里有两个核心文件SKILL.md或.prompt这是大脑规定了步骤。manifest.json这是配置声明了这个技能需要用到哪些 MCP 工具。3. 本篇产出3 个高频技能的最小实现SOP 模板为了让你立刻上手我们为你准备了 3 个开发团队最高频使用的 Skill 模板。你可以直接在团队内部创建这三个技能。技能一Code Review 技能包 (Team-Code-Review)适用场景提交代码前让 AI 按照团队规范自动挑错。SKILL.md# 目标 你现在是本团队的资深代码审查员。请对我指定的代码文件进行 Review。 # 执行步骤必须严格遵守顺序 1. **静态扫描**调用 run_lint 工具扫描目标文件如果报错直接停止审查并要求我修改。 2. **规范核对**检查代码是否满足以下团队规范 - 变量命名必须使用小驼峰 (camelCase)。 - 所有超过 20 行的函数必须有块级注释。 - 绝对不允许出现 console.log。 3. **输出报告**按照 [行号] - [问题级别] - [修改建议] 的格式输出你的审查报告。技能二智能 Debug 技能包 (Auto-Debug-Helper)适用场景终端报错时不再像无头苍蝇一样乱试按步骤排查。SKILL.md# 目标 你是一个冷静的排障专家。遇到报错时请按以下 SOP 进行排查切勿盲目修改代码。 # 排查 SOP 1. **环境确认**调用 get_env 工具检查当前的 Node/Python 版本是否与 package.json/requirements.txt 要求一致。 2. **日志截取**调用 read_log 工具只读取最近 100 行报错日志提取出核心的 Error Code。 3. **依赖检查**检查该错误是否由第三方依赖升级导致。 4. **行动**在给出修改建议前必须先告诉我“根因Root Cause”是什么。技能三单测生成技能包 (Generate-Unit-Test)适用场景写完业务代码后自动补全枯燥的测试用例。SKILL.md# 目标 根据提供的业务代码生成高覆盖率的单元测试文件。 # 约束与规范 - 必须使用 pytest (Python) 或 Jest (JS) 框架。 - 每个被测函数必须至少包含 3 个测试用例 1. 正常路径 (Happy Path) 测试。 2. 边界值 (Edge Case) 测试如输入 null、空字符串或极大值。 3. 异常抛出 (Exception) 测试。 - **自动验证**生成测试代码后调用 run_test 工具跑一遍。如果测试未通过你需要自己修改测试代码直到全绿为止。总结与复盘Skill 是团队知识沉淀的终极形态。以前沉淀在 Wiki 里的死文档现在变成了能自己干活的活代码。写 Skill 的核心不是教大模型写代码而是教它**“先干什么后干什么哪些红线不能碰”**即团队 SOP。把 Code Review、Debug 和写单测这种高频且繁琐的工作做成 Skill能让团队的开发效率瞬间提升一倍。下一步路线提示你写好了这 3 个绝妙的 Skill准备发给全团队的 50 个人用。但如果明天公司规定“所有的 Code Review 必须加上安全漏洞扫描”你该怎么让这 50 个人的 Skill 同时更新如果有人偷偷改了你写的 Skill把检查逻辑删了怎么办下一篇我们将进入《技能治理版本、禁用回滚与共享策略》。