Matt Pocock Skills 的使用
一分钟速览
mattpocock/skills既不是框架也不是包，而是把「如何使用 AI 开发软件」的最佳实践，写成 agent 可以执行的一组小而可组合、可任意修改的 Markdown 工作流文件；每个 skill 是一个SKILL.md（YAML 头name+description+ 正文），靠 Progressive Disclosure 按需加载，装几十个初始上下文也几乎为零。- 官方把 Skills 按 Getting Started → Main Flow → Shaping → Upkeep 四组组织；核心主流程（main build chain）是
grill-with-docs → to-spec → to-tickets → implement → code-review。 - 安装二选一、勿同时装：Claude Code 插件是只读订阅式；
npx skills@latest add mattpocock/skills是可编辑拷贝式。装完务必跑一次/setup-matt-pocock-skills。 - 一个 ticket ≈ 一个 fresh context window：每个 ticket 开新会话实现、做完 commit，避免上下文越来越长导致乱改。
- 它对 AI 编程的价值，是把 AI Coding 从「聊天式写代码」变成「工程流程式开发」（Understand → Decide → Document → Decompose → Implement → Verify → Review → Ship）。
1. 先理解：Skills 到底是什么？
如果你使用 Claude Code / Codex / Cursor 这类 Coding Agent，传统做法可能是：
你：
"帮我加一个支付功能"
AI：
开始写代码……Matt 的方法则是：
你
↓
AI 帮你搞清楚需求
↓
形成 Spec
↓
拆成 Tickets
↓
一个 Ticket 一个 Agent Session
↓
TDD 实现
↓
Code Review
↓
Commit所以这些 Skills 本质上是：
把"如何使用 AI 开发软件"的最佳实践，写成 Agent 可以执行的工作流。
这也是为什么它比普通 prompt 高一个层级。
2. 第一步：安装
目前官方提供两种比较直接的安装方式。
方式 A：整个 Skills 套件
npx skills@latest add mattpocock/skills官方文档目前仍然提供这个安装方式。（aihero.dev）
也可以只安装某个 Skill，例如：
npx skills@latest add mattpocock/skills --skill=implement或者：
npx skills@latest add mattpocock/skills --skill=to-spec官方每个 Skill 页面都提供对应的安装命令。（aihero.dev）
如果你使用 Claude Code，官方现在还提供 plugin 安装方式：
claude plugins install mattpocock-skills3. 安装以后，第一件事不是 /implement
这是非常重要的。
第一次进入一个项目，先：
/setup-matt-pocock-skills它相当于：
告诉 Matt 的 Skills：这个项目是什么、Issue Tracker 在哪里、项目的 Agent instructions 在哪里。
官方把它定义成"一次性的 repo setup"，其他 Skills 会依赖它。（aihero.dev）
它会建立类似：
docs/
agents/
issue-tracker.md
domain.md
...并把 Agent Skills 的相关规则接入项目真正使用的 instruction 文件。
所以我建议：
新项目
↓
/setup-matt-pocock-skills只做一次。
4. 然后才是最核心的 Main Flow
这是 Matt 整套方法的灵魂：
/grill-with-docs
↓
/to-spec
↓
/to-tickets
↓
/implement
↓
/code-review官方现在把它明确称为 main build chain。（aihero.dev）
下面一个一个说。
5. /grill-with-docs
它解决什么问题？
"我到底想做什么？"
假设你说：
我要做一个 SaaS，用户可以上传 PDF，然后 AI 分析 PDF。
你千万不要马上：
/implement而是：
/grill-with-docs然后 Agent 会开始反向拷问你。
比如它可能会问：
- PDF 最大允许多大？
➡️ 建议：限制 50MB。
- 用户上传后是否立即处理？
➡️ 建议：异步处理。
- 一个用户能否同时处理多个 PDF？
➡️ 建议：允许，但设置并发限制。
- PDF 是否永久保存？
➡️ 建议：保存 30 天。
- AI 分析失败怎么办？
...你回答。
它继续问。
关键：它不是普通聊天
grill-with-docs 有一个非常重要的特点：
它会把已经确定的 vocabulary / decisions 写进 repo。
比如：
CONTEXT.md里面可能慢慢形成：
## Glossary
Document
用户上传的原始 PDF。
Analysis
对 Document 执行 AI extraction 后产生的结构化结果。
Workspace
用户管理 Documents 的空间。以及一些重要决策 / ADR。
官方特别强调，它会在讨论过程中持续更新 CONTEXT.md，而不是最后一次性生成。（aihero.dev）
6. 为什么 Matt 非常重视这个？
因为 AI 最大的问题之一不是不会写代码。
而是：
它不知道你到底是什么意思。
比如你说：
"用户"
AI 可能理解成：
User = authentication account但你的业务可能实际上是：
User
↓
Organization
↓
Workspace
↓
Member如果概念没有统一，后面的代码会越来越乱。
所以：
grill-with-docs实际上是在建立：
Shared Mental Model
你和 AI 先把世界定义清楚。
7. /to-spec
当你已经把需求讨论清楚以后：
/to-spec它做的事情非常简单：
把刚才已经达成共识的内容变成正式 Spec。
注意：
/to-spec不是拿来继续讨论需求的。
官方明确说，它不会重新 interview 你，而是把已经决定好的内容综合成 Spec。（aihero.dev）
比如最后变成：
# PDF Analysis
## Goal
Users can upload PDF documents and receive
structured AI analysis.
## Requirements
- PDF <= 50MB
- PDF only
- async processing
- max 3 concurrent jobs
- analysis result persisted
- failed jobs retry 3 times
## Out of Scope
- DOCX
- real-time streaming
- multi-user collaboration这个 Out of Scope 很重要。
因为 AI 特别喜欢"自作主张"。
8. /to-tickets
然后：
/to-tickets它会把 Spec 拆成可以真正执行的 tickets。
例如：
Ticket #1
PDF upload
Ticket #2
Document persistence
Ticket #3
Analysis job
Ticket #4
AI extraction
Ticket #5
Result UI但 Matt 的方法有一个非常重要的区别：
不是按技术层拆。
不要：
Ticket 1: Database
Ticket 2: Backend
Ticket 3: Frontend
Ticket 4: Tests而是：
Ticket 1:
Upload PDF → save → display uploaded document
Ticket 2:
Start analysis → process → display status
Ticket 3:
Show analysis result → persist → retrieve也就是所谓的 tracer bullet / vertical slice。
一个 Ticket 应该能够穿过：
Database
↓
API
↓
Business logic
↓
UI
↓
Tests并且完成后就是一个可以 Demo 的完整行为。
官方对 to-tickets 的核心要求就是这种 vertical slice，而不是按 layer 切割。（aihero.dev）
9. 然后进入最爽的部分：/implement
现在你已经有：
Spec
↓
Ticket #1然后开一个全新的 Agent session：
/implement #1这点非常重要。
Matt 的设计理念是：
一个 ticket ≈ 一个 fresh context window。
为什么？
因为如果你让 AI：
连续工作 8 个小时
↓
上下文越来越长
↓
不断 compact
↓
忘记早期决定
↓
开始乱改质量会下降。
所以：
Ticket #1
↓
fresh context
↓
implement
↓
commit
Ticket #2
↓
fresh context
↓
implement
↓
commit官方现在就是这样设计的。（aihero.dev）
10. /implement 到底会干什么？
这个 Skill 很有意思。
它不是简单：
"把 Ticket 写成代码。"
它内部大致是：
Read ticket
↓
Understand seams
↓
TDD
↓
Write failing test
↓
Implement
↓
Typecheck
↓
Run tests
↓
Full test suite
↓
Code review
↓
Commit官方明确说明，implement 会：
- test-first
- 驱动 TDD
- 经常 typecheck
- 跑测试
- 最后跑完整 test suite
- 调用 code-review
- commit 当前 branch。（aihero.dev）
所以你可以把它理解成：
一个小型 AI Developer Agent。
11. /code-review
最后：
/code-review这是非常重要的一步。
Matt 的 Code Review 不是单纯：
"帮我看看代码有没有 bug。"
它会从两个维度看：
Axis 1：Standards
这个 repo 的代码规范是什么？
比如：
有没有违反 architecture？
有没有违反 coding standards？
有没有 code smell？
有没有重复代码？Axis 2：Spec
你到底有没有完成需求？
例如：
Spec:
PDF <= 50MB
Code:
没有检查文件大小那么：
代码可能很漂亮，但是 Spec review 直接 fail。
官方目前就是把 Standards 和 Spec 分成两个独立 review axis，并分别运行 sub-agent。（aihero.dev）
12. 还有一个特别有意思的 /ask-matt
如果你不知道：
"我现在到底应该用哪个 Skill？"
直接：
/ask-matt它相当于一个 Router。
例如：
我有一个 bug
→ diagnosing-bugs
我要做一个新 feature
→ grill-with-docs
需求已经确定
→ to-spec
Spec 已经有了
→ to-tickets
Ticket 已经有了
→ implement
代码已经写好了
→ code-review官方现在明确把 ask-matt 定位成整个 Skills 集合的 router。（aihero.dev）
13. 其他 Skills 是干什么的？
现在官方的 Skills 已经不只是主流程。
大致可以理解为：
🟢 Getting Started
/setup-matt-pocock-skills
/ask-matt🔵 Main Flow
/grill-with-docs
/to-spec
/to-tickets
/implement
/code-review🟣 Shaping
/wayfinder
/prototype
/research🟠 Upkeep
/improve-codebase-architecture
/diagnosing-bugs
/resolving-merge-conflicts官方当前 Skills Catalog 就是按这些阶段组织的。（aihero.dev）
14. /wayfinder 特别值得讲
如果项目特别大：
我要重构整个 billing system
你不能直接：
/implement因为这可能是：
50 files
20 decisions
10 dependencies
5 teams这种情况下：
/wayfinder它的目的就是：
先把大型工作的"决策地图"画出来。
类似：
Billing Refactor
│
├── Payment provider?
│ ├── Stripe
│ └── Adyen
│
├── Data migration?
│ ├── online
│ └── offline
│
├── API compatibility?
│
└── Rollout strategy?先解决这些关键决策。
然后才进入：
to-spec
↓
to-tickets
↓
implement所以它是大型项目的 shaping layer。
15. /prototype
这个也非常好用。
假设你不知道：
"这个技术方案到底能不能实现？"
不要花两天设计。
直接：
/prototype让 Agent：
快速写实验代码
↓
验证技术假设
↓
得到答案
↓
prototype 删除它的核心不是生产代码。
而是：
用代码回答设计问题。
官方把它定位为 "Answer a design question with code you then delete"。（aihero.dev）
16. /research
比如：
Stripe 最新 API 怎么实现这个功能？
或者：
Next.js 当前版本这个 API 怎么用？可以：
/research它的理念是：
让 Agent 去读 primary sources，而不是凭训练数据猜。
这对 AI Coding 非常重要。
因为：
LLM memory
≠
Current documentation17. /diagnosing-bugs
这个我也非常推荐。
普通 AI debugging：
"这里报错了，帮我修"
Agent：
try fix A
↓
不行
↓
try fix B
↓
不行
↓
try fix C
↓
好了问题是：
它可能只是碰巧修好了。
Matt 的思路是：
Reproduce
↓
Observe
↓
Hypothesis
↓
Test hypothesis
↓
Find root cause
↓
Fix
↓
Regression test也就是：
先诊断，再修。
18. 所以整个体系其实可以画成这样
IDEA
│
▼
┌────────────────┐
│ /grill-with-docs│
└────────────────┘
│
Shared Understanding
│
▼
/to-spec
│
SPEC
│
▼
/to-tickets
│
┌───────┼───────┐
▼ ▼ ▼
Ticket1 Ticket2 Ticket3
│ │ │
▼ ▼ ▼
/implement /implement /implement
│ │ │
▼ ▼ ▼
TDD TDD TDD
│ │ │
└───────┼───────┘
▼
/code-review
│
▼
COMMIT
│
▼
SHIP这就是 Matt 这套东西最核心的价值。
19. 最关键的一条原则
你一定要记住：
不要把这些 Skills 当成"更多 Prompt"。
它们真正改变的是：
普通 Vibe Coding：
Prompt
↓
Code
↓
Prompt
↓
Code
↓
Prompt
↓
CodeMatt Pocock：
Understand
↓
Decide
↓
Document
↓
Decompose
↓
Implement
↓
Verify
↓
Review
↓
Ship所以他的核心思想实际上是：
把 AI Coding 从"聊天式写代码"，变成"工程流程式开发"。
如果你现在就想用，我建议你这样开始
不要一上来安装 22 个然后全部玩一遍。
第一阶段只学 5 个：
/setup-matt-pocock-skills
↓
/grill-with-docs
↓
/to-spec
↓
/to-tickets
↓
/implement
↓
/code-review然后拿一个真实的小项目练。
例如：
"给我的 SaaS 增加邀请成员功能。"
你亲自完整跑一遍：
/grill-with-docs
↓
/to-spec
↓
/to-tickets
↓
/implement #1
↓
/implement #2
↓
/code-review跑完一次，你基本就会真正理解 Matt 的方法，而不是只知道这些命令是什么。
而且这里有一个非常值得进一步研究的问题：Matt 这套东西和 Superpowers、BMAD、OpenSpec 到底有什么本质区别。 它们表面上都在做 "Spec → Plan → Code → Review"，但背后的 Agent orchestration 思路其实差别很大。
to-spec 和 to-tickets 的使用意义
可以把它们理解成两个完全不同的动作：
/to-spec= 把"我要做什么"变成一份 AI 能准确执行的技术需求说明。
/to-tickets= 再把这份说明拆成一个个 AI 可以独立完成的小任务。
最简单的比喻：
你想盖一栋房子
↓
/to-spec
↓
建筑设计图纸
↓
/to-tickets
↓
施工任务清单
↓
/implement
↓
开始施工1. /to-spec 到底是什么？
Spec 是 Specification 的缩写。
可以翻译成：
规格说明 / 技术规格 / 功能规格
它回答的是：
"这个功能到底应该是什么样？"
而不是：
"程序员第一步应该写哪个文件？"
举个非常实际的例子
假设你告诉 AI：
我要给我的 SaaS 加一个"邀请团队成员"的功能。
这句话对人来说好像已经挺清楚。
但对 Coding Agent 来说，其实有大量未知信息：
谁可以邀请？
邀请谁？
邀请以后发生什么？
邀请邮件什么时候发？
邀请链接多久过期？
已经是成员的人怎么办？
邀请不存在的邮箱怎么办？
一个团队最多多少人？
被邀请的人没有账号怎么办？如果直接：
/implementAI 就必须自己猜。
这就是 Vibe Coding 很容易出问题的地方。
2. /to-spec 就是把这些"隐含问题"明确下来
在 Matt 的工作流里，通常前面会先：
/grill-with-docs让 AI 跟你讨论：
"谁能邀请？"
"邀请链接有效多久？"
"已有用户怎么办？"
"是否需要管理员权限？"你们讨论完以后，再：
/to-spec于是 AI 会把已经确定的东西整理成类似：
# Team Member Invitations
## Goal
Allow team admins to invite new members
to their workspace.
## Requirements
1. Only workspace admins can invite members.
2. Invitation is sent by email.
3. Invitation expires after 7 days.
4. Existing members cannot be invited again.
5. Invited users without an account can create one.
6. Invitation status can be:
- pending
- accepted
- expired
- revoked
## Acceptance Criteria
- Admin can enter an email address.
- System creates an invitation.
- Email is sent.
- Recipient can accept the invitation.
- Expired invitations cannot be accepted.
## Out of Scope
- Bulk invitations
- CSV import
- SSO这就是 Spec。
注意：
它不是代码。
它是在告诉 AI："你最终做出来的东西必须符合这个定义。"
1. 为什么 Spec 对 AI 特别重要？
因为 LLM 有一个天然问题：
它非常擅长填补空白。
这在人类聊天的时候是优点。
但在软件工程里面经常是灾难。
比如你说：
做一个邀请成员功能。
AI 会想：
那我需要：
JWT？
Redis？
Email queue？
Webhook？
新的 database table？
新的 API？
React modal？
Toast？
Rate limit？它可能全部给你做了。
但你真正想要的可能只是：
一个 email input + invitation table + email。
所以 Spec 的作用就是：
AI 的自由发挥空间
↓
限制
↓
明确的工程边界尤其重要的是：
Spec 不只是规定"做什么"，还规定"不做什么"。
例如：
Out of Scope:
- Google login
- Bulk invitation
- CSV upload这对 Agent 非常重要。
4. 那 /to-tickets 又是什么？
有了 Spec：
我要做 Team Invitation
但是这个功能还是太大。
你不能简单地让 Agent：
/implement因为它可能涉及：
Database
Email
API
Authentication
Business logic
Frontend
Tests所以需要：
/to-tickets它的意思就是：
把 Spec 拆成多个可以独立执行的工程任务。
5. 比如会拆成这样
原来的：
Team Member Invitation变成：
Ticket 1
Create invitation domain model
Ticket 2
Implement invitation creation API
Ticket 3
Send invitation email
Ticket 4
Accept invitation
Ticket 5
Build invitation UI但是 Matt 的方法还有一个很重要的特点：
不要简单按照技术层拆。
比如不要：
❌ Ticket 1: Database
❌ Ticket 2: Backend
❌ Ticket 3: Frontend
❌ Ticket 4: Tests这种拆法对于 AI Agent 并不好。
更好的方式是：
✅ Ticket 1:
Admin can invite a new member这个 Ticket 里面可能同时包含：
Database
+
API
+
Business Logic
+
UI
+
Tests也就是一个 vertical slice（垂直切片）。
6. 为什么要 Vertical Slice？
因为 AI Agent 最适合完成：
一个完整、边界清楚、可以验证的行为。
例如：
Ticket 1
Admin enters email
↓
POST /invitations
↓
Create invitation
↓
Send email
↓
Show success然后测试：
Given admin enters [email protected]
When invitation is submitted
Then:
- invitation is created
- email is sent
- UI shows success完成。
这时候 Ticket #1 就已经是一个完整的小功能。
7. 然后 Ticket #2
比如：
Ticket 2
Invitee clicks invitation link
↓
System validates invitation
↓
User accepts
↓
User becomes workspace member
↓
Invitation becomes accepted又是一个完整功能。
所以最终：
SPEC
│
├── Ticket 1
│ └── Admin sends invitation
│
├── Ticket 2
│ └── User accepts invitation
│
├── Ticket 3
│ └── Admin revokes invitation
│
└── Ticket 4
└── Expired invitation handling8. 所以两者的关系非常简单
你可以记这个：
SPEC
│
"我们要做什么？"
│
▼
┌──────────────┐
│ │
Ticket 1 Ticket 2
│ │
"做什么？" "做什么？"
│ │
▼ ▼
Agent Agent
│ │
▼ ▼
Code Code或者用产品经理的话：
/to-spec
Define the WHAT
我们到底要构建什么？
/to-tickets
Define the WORK
为了构建它，需要完成哪些独立的工作单元？9. 再往下才是 /implement
所以完整链条：
你的想法
↓
/grill-with-docs
↓
把模糊需求讨论清楚
↓
/to-spec
↓
形成正式 Spec
↓
/to-tickets
↓
拆成可执行 Tickets
↓
/implement
↓
一个 Ticket 一个 Ticket 实现
↓
/code-review
↓
检查是否符合 Spec这个顺序非常有意义。
/to-spec不是让 AI 写代码。
/to-tickets也不是让 AI 写代码。它们是在代码之前做两个不同层次的"思考"。
10. 用一个更容易理解的例子
假设你说：
"我要做一个类似 Notion 的 AI 笔记功能。"
直接 Vibe Coding：
你：
做一个 AI Note
AI：
好的！
[开始写 50 个文件]
😅Matt 的方式：
第一步
/grill-with-docs讨论：
Note 是什么？
AI 能做什么？
AI 是自动触发还是用户点击？
支持 Markdown 吗？
支持多人吗？
AI 能修改原文吗？
AI 修改前需要确认吗？第二步
/to-spec形成：
AI Note Spec
Goal:
用户可以让 AI 总结当前 Note。
Behavior:
- 用户点击 Summarize
- AI 读取当前 Note
- 生成 summary
- summary 显示在 sidebar
- 原文不修改
Out of Scope:
- AI 自动修改 Note
- 多人协作
- AI chat现在 AI 终于知道你到底要什么了。
第三步
/to-tickets拆成：
Ticket 1
Create note data model
Ticket 2
Implement summarize endpoint
Ticket 3
Connect AI provider
Ticket 4
Display summary in UI
Ticket 5
Handle loading/error states然后：
/implement Ticket 1
完成。
/implement Ticket 2
完成。
……最后：
/code-review检查：
"你写出来的东西，是不是 Spec 要求的东西？"
11. 你可以把它们理解成三个层次
这是我觉得最容易记住的方式：
所以：
Spec 是"蓝图"，Ticket 是"施工任务"，Implement 是"施工"。
这就是为什么我前面说，/to-spec → /to-tickets 是 Matt 方法里面最核心的一段。
如果你接下来想真正用这套方法，我建议下一步直接搞清楚一个更关键的问题：
一个好的 Spec 到底应该写哪些字段？
因为这决定了 AI 后面写出来的代码质量。我可以直接给你一个 Matt Pocock 风格的 Spec 模板，然后拿一个真实 SaaS 功能，从 grill → spec → tickets → implement 完整走一遍。
常见问题（FAQ）
mat pocock skills 到底是什么？
mattpocock/skills 既不是框架，也不是 npm 包，而是 Matt Pocock 把自己日常工程里真实使用的 agent skills 全部开源出来的一组可组合、可任意修改的 Markdown 工作流文件。每个 skill 是一个 SKILL.md 文件（YAML 头 name + description 加正文），采用 Progressive Disclosure 加载：会话启动时只读入 name/description，任务触发时才加载全文。
为什么写代码前非要先 /grill-with-docs 拷问？
因为 AI 最大的问题不是不会写代码，而是不明白你的真实意图。/grill-with-docs 会反向拷问你，同时把已确定的术语（vocabulary）与重要决策（ADR）持续写进 CONTEXT.md，逐步建立 Shared Mental Model——先把世界定义清楚，后面代码才不会越写越乱。
/to-spec 和 /to-tickets 有什么区别？
/to-spec 把"我要做什么"变成一份 AI 能准确执行的技术需求说明（Define the WHAT）；/to-tickets 再把它拆成一个个可独立执行、可验证的工程任务（Define the WORK）。用一个比喻：/to-spec 出建筑设计图纸，/to-tickets 出施工任务清单。
为什么一个 ticket 要开一个全新的会话？
Matt 的理念是「一个 ticket ≈ 一个 fresh context window」。如果让 AI 连续工作很久，上下文会越来越长、不断 compact、忘记早期决定，最终开始乱改。所以每个 ticket 都开新会话实现，完成后 commit。
Vertical slice（垂直切片）拆票是什么意思？
不要按技术层拆（如 Database / Backend / Frontend / Tests），而要按一个端到端、能独立部署验证的完整行为拆。比如 Ticket 1: Admin can invite a new member，它会同时包含数据库、API、业务逻辑、UI 与测试。完成一个 ticket 就是一个能直接 Demo 的完整功能。
两种安装方式该怎么选？
- Claude Code 插件：
claude plugins install mattpocock-skills，只读、订阅式，作者更新你自动同步。 - skills.sh（拷贝式）：
npx skills@latest add mattpocock/skills，把文件拷进项目随便改。
任选其一，不要同时装，否则每个 skill 会出现两份。装完务必勾选 setup-matt-pocock-skills，并在每个仓库跑一次 /setup-matt-pocock-skills。
user-invoked 和 model-invoked 有什么区别？
- User-invoked（如
/grill-me、/to-spec、/implement）：必须你打/xxx才会触发，负责编排流程。 - Model-invoked（如
tdd、diagnosing-bugs、code-review）：你手动调用，或 agent 判断任务匹配时自动触发，承载可复用纪律。
铁律：user-invoked 可以调用 model-invoked，但绝不能调用另一个 user-invoked。
装了几十个 skill 会把上下文占满吗？
不会。靠 Progressive Disclosure，会话开始时每个 skill 只把 name/description 读入内存，几乎零开销；只有当相关任务被触发时才加载全文。
它和 Superpowers、BMAD、OpenSpec 有什么本质区别？
表面上都在做「Spec → Plan → Code → Review」，但背后的 Agent orchestration 思路差别很大。mattpocock/skills 明确反对 GSD / BMAD / Spec-Kit 这类"接管流程"的框架，主张每个 skill 小而可组合、把流程控制权交回给你。对照路线可看本站另一篇 Superpowers Skills 的使用；如果对「Agent IDE 里的技能到底是什么」还不熟悉，建议先读 AI Agent IDE 入门与进阶。
本文首发于「Jason的AI实验室」：https://www.jasonailabtech.com/knowledge/ai-coding/matt-pocock-skills，站内还有更多 AI 编程助手与大模型开发的实操笔记。