欢迎来到本教程的最后一个实战项目：项目 D：团队可复用技能包（Skills）。

在前面的实战中，我们手写了 Prompt，封装了工具，甚至搭了状态机。但这些代码都“死死地”长在你的电脑里。
如果公司里有 50 个开发人员，每个人都要做 Code Review（代码审查）。难道每个人都要去写一遍审查的 Prompt 和跑脚本的逻辑吗？

这显然违背了软件工程“不重复造轮子（DRY）”的原则。
在 AI 时代，我们如何把一个高手的经验，打包成全团队都能用的“即插即用”组件？这就是 Skills（技能包） 的核心价值。

---

1. 痛点：被锁在脑子里的 SOP

每个团队都有自己的 SOP（标准作业程序）。
比如你们团队的 Code Review 规范：

1. 必须检查有没有写中文注释。
2. 必须检查有没有把数据库密码硬编码在代码里。
3. 必须运行 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，把检查逻辑删了，怎么办？
下一篇，我们将进入：《技能治理：版本、禁用回滚与共享策略》。