05 · 手把手写第一个 Skill

这一章从头做一个能用的 Skill：把会议纪要那条提示词打包起来。跟着做，二十分钟。

用的材料就是入门篇 08 章那条已经跑通的提示词——这不是巧合，这就是正确的顺序：先用 Prompt 跑通，再打包。

第 1 步 · 把提示词拆成"变的"和"不变的"

把你调好的那条提示词摊开，两支笔圈：

你是一位专业的项目助理。请把下面这段零散的会议记录，整理成一份结构清晰的会议纪要。
└────────────────────── 不变 ──────────────────────┘

背景：这是我方与客户「明远地产」就"会员小程序改版"项目的一次沟通会…
      └──────────────── 变（每次的项目不同）────────────────┘

请按以下三块输出：
一、关键结论 / 已定事项
二、待办事项（每条标出：事项、负责人、截止时间）
三、遗留 / 待确认问题
└────────────────────── 不变 ──────────────────────┘

只能基于我给的内容整理，不要编造…人名一律沿用原记录里的称呼…
└────────────────────── 不变 ──────────────────────┘

会议记录如下：【粘贴】
                └── 变 ──┘

不变的部分 → 进 Skill。变的部分 → 留给你每次说。

结果：整个 Skill 里不会出现"明远地产"，只会出现"用户提供的背景"。

第 2 步 · 写触发描述

先列出你和同事真会说的话：

"帮我把这个会议记录理一下"
"整理成纪要"
"这段转写你看看能不能理出待办"
"把刚才会上定的事列一下"

抽关键词：会议记录、纪要、转写、待办、会上定的事。塞进去：

name: meeting-notes
description: 把零散的会议记录整理成结构化纪要，输出「关键结论」
  「带责任人和截止时间的待办」「遗留 / 待确认问题」三块。当用户提供会议记录、
  会议草稿、录音转写稿，或要求整理纪要、提取会议待办、梳理会上定的事时使用。
  仅用于会议类材料。

写完做一遍 04 章那个自测。

第 3 步 · 写正文

# 会议纪要整理

## 流程

1. 通读材料，把内容分成三类：**已定的事**、**要办的事**、**还没定的事**。
2. 按下面的模板输出。
3. 输出后对照末尾的检查清单自查一遍，不满足的改掉再交，不要展示自查过程。

## 输出模板

严格按此结构，方括号内替换为实际内容：

```
## [客户或项目名]｜[会议类型] 纪要

**日期**：[原文有则填，没有填「待确认」]　**参会**：[列出，顿号分隔，无则填「待确认」]

### 一、关键结论 / 已定事项
1. [一句话一条，动词开头，写清"定了什么"]

### 二、待办事项
| 事项 | 负责人 | 截止时间 |
| --- | --- | --- |
| [事项，写成能直接派活的一句话] | [原文称呼，或「待确认」] | [原文时间，或「待确认」] |

### 三、遗留 / 待确认问题
1. [还没定的事，一句话一条]
```

## 规则

- 只使用用户提供的材料，不引入任何外部信息。
- 人名沿用原文称呼（"刘总监""王工"），**不要补全为全名**。
- 日期、金额、数字照抄原文，不推算、不换算。
- 负责人或截止时间不明确的，填「待确认」，**不要根据常理猜填**。
- 材料中前后矛盾的内容，两条都保留并标注「原文冲突」，不要替用户选一个。
- 跑题内容不写进纪要；但若其中含承诺或风险（如"预算可能收紧"），
  归入第三块「遗留」。
- 输出纯粹的纪要，不要开场白、不要结尾总结。

## 示例

**输入（片段）**：
"…刘总监说 banner 要能后台自己换…积分商城想加秒杀但规则没定，下周对…
权限按门店分，王工你跟进一下…"

**输出（片段）**：

### 一、关键结论 / 已定事项
1. 首页 banner 改为后台可自行更换。

### 二、待办事项
| 事项 | 负责人 | 截止时间 |
| --- | --- | --- |
| 数据报表权限分级（各门店仅看本店） | 王工 | 待确认 |

### 三、遗留 / 待确认问题
1. 积分商城秒杀规则未定，待客户内部对齐（客户称下周反馈）。

**注意示例中的两处**：负责人"王工"沿用原文没有补全；截止时间原文没写，
填了「待确认」而不是猜一个日期。

## 检查清单

- [ ] 三个章节齐全，标题与模板一致
- [ ] 全文无材料之外的人名全称、日期、金额
- [ ] 每条待办都有负责人与截止（或明确的「待确认」）
- [ ] 未定的事没有被写进第一块
- [ ] 无开场白、无结尾总结

注意示例那一段的写法

示例后面那句"注意示例中的两处"很关键——给例子的同时把规律点破，比只给例子稳定得多。这是提示词篇 03 章讲过的。

第 4 步 · 存到它能被找到的地方

存法各家不同（09 章有完整对照），最常见的三种：

场景	怎么存
命令行 / IDE 里的编码工具	建一个文件夹放进去。个人用的通常在用户目录下的技能目录，项目共享的放项目里的技能目录，跟代码一起提交
网页版 AI 产品	在设置里上传（通常是打包成 zip），或者用它的"智能体 / 自定义应用"功能把这段内容贴进去
企业内部平台	建一个"应用 / 助手"，把正文贴进说明框

先在你最常用的那个工具上落一份就行，别一开始就想着全平台同步。

第 5 步 · 测三次

不要用你调提示词时那份材料测——那份它已经"见过"了。换三份新的：

用例	看什么
1. 正常触发	说一句"帮我把这段会议记录理一下"+ 一份新材料。它有没有自己想起来用这个 Skill？没有就回去改 description
2. 缺信息	一份没写负责人和时间的记录。有没有填「待确认」而不是猜？
3. 不该触发	说"帮我写个周报"+ 一段工作流水。它有没有错误地套上纪要模板？套了就加排除条款

三个都过，这个 Skill 就能用了。三个用例的详细做法见 07 章。

第 6 步 · 用两周，然后改

真正的完善发生在使用中。用的时候留意三件事，随手记下来：

1. 哪次它没被触发（你不得不手动说"用那个纪要的规矩"）→ 改 description
2. 哪条规矩它总是忘（比如老是补全人名）→ 那条写得不够硬，或者位置太靠后
3. 哪条规矩其实多余（从来没起过作用）→ 删掉，正文越短越好

两周后按这三条改一版，你的第一个 Skill 就成熟了。

常见的第一次翻车

三个新手最容易犯的

把"这次的材料"写进了 Skill。 Skill 里出现具体客户名、具体项目——下次做另一个项目的纪要，它会把上个客户的信息带进来。

description 只写了"整理会议纪要"。 于是你说"帮我理一下这段会议内容"，它没反应——你说的话里没有"纪要"两个字。

规矩写了十五条。 太长，中间那几条基本不生效。挑最重要的五到八条，剩下的删掉或者移到附件。

下一步

06 · 进阶：原型转 PRD Skill —— 带流程、模板和自查回路的复杂 Skill 长什么样。