Aklman · Library

05 / 第五章

沉淀 · Skills.

每周粘贴同一段 prompt,就是 Skill 该出场的信号。这一章给你一份完整的 SKILL.md,从头写到尾、可以直接抄走:一个替你审周报的技能。写完再让内置 xlsx 交出一份真 Excel —— 你早就有这个能力,只是从没让它交文件。

MD海报

每周粘贴同一段 prompt —— 同样的开场、同样的格式要求、同样的「记得加上这几条」—— 就是一个 Skill 该出场的信号。 上一章你把「这件事的背景」钉进了 Project。这一章搬走剩下那部分:「这类事怎么做」。写完之后,你不用再想起要交代什么 —— 一句话触发,它自己知道步骤、格式和验收标准。

I

Skill 是按需加载的方法.

Project 钉的是上下文,Skill 钉的是方法。 一个 Skill 是个文件夹:一份用 Markdown 写的说明(这类事怎么做)、可选的脚本、可选的参考资源。2注 2Anthropic Engineering · Equipping agents for the real world with Agent Skills —— Skill 是指令、脚本与资源的文件夹,靠渐进式披露按需加载,只在用得上时才读进上下文;写好一个 Skill 的关键是把示例当指令用,并把 name 与 description 写清「做什么 + 什么时候用」。关键在「按需加载」:Claude 先扫一眼每个 Skill 的简介,判断这次用不用得上,只把相关那份读进来 —— 所以你可以攒几十个 Skill,而不会把上下文撑爆。2注 2Anthropic Engineering · Equipping agents for the real world with Agent Skills —— Skill 是指令、脚本与资源的文件夹,靠渐进式披露按需加载,只在用得上时才读进上下文;写好一个 Skill 的关键是把示例当指令用,并把 name 与 description 写清「做什么 + 什么时候用」。 一共四类,先认清你在跟哪一类打交道:Anthropic 内置的(Excel / Word / PowerPoint / PDF,相关任务自动触发)、你自建的(这一章要写的)、组织下发的(Team / Enterprise 的管理者推给全组织)、以及合作方技能(Notion、Figma、Atlassian 这些,从技能目录里装)。全档开放,连 Free 都有;运行需要 code execution 是打开的。1注 1Claude 帮助中心 · 什么是 Skills —— Skill 是 Claude 按需加载的指令/脚本/资源文件夹;对 Free / Pro / Max / Team / Enterprise 全档开放,另有 Claude Code beta 与开启了 code execution 的 API 用户;运行需要 code execution 打开。共四类:Anthropic 内置(Excel / Word / PowerPoint / PDF)、自建、组织下发、以及来自技能目录的合作方技能(Notion、Figma、Atlassian 等)。用 Markdown 写说明即可创建,简单的无需写代码。截至 2026-08。 在哪管:账号设置里的技能一栏开关,或从输入框的 + 菜单浏览技能目录。先装你真用得上的两三个,别把目录里的全开了 —— Skill 太多,触发判断也会变迟钝。

II

动手:写完一个 SKILL.md.

做自己的 Skill 不用写代码 —— 用 Markdown 写一份说明就是一个 Skill。 官方就两条要诀。一,示例即指令:与其用形容词描述你想要什么,不如塞一两个「长这样」的成品例子进去 —— 它照着样例学,比照着描述读准得多。2注 2Anthropic Engineering · Equipping agents for the real world with Agent Skills —— Skill 是指令、脚本与资源的文件夹,靠渐进式披露按需加载,只在用得上时才读进上下文;写好一个 Skill 的关键是把示例当指令用,并把 name 与 description 写清「做什么 + 什么时候用」。二,把 namedescription 写清「做什么 + 什么时候用」(用第三人称),因为 Claude 就靠这两行判断这次该不该触发它。2注 2Anthropic Engineering · Equipping agents for the real world with Agent Skills —— Skill 是指令、脚本与资源的文件夹,靠渐进式披露按需加载,只在用得上时才读进上下文;写好一个 Skill 的关键是把示例当指令用,并把 name 与 description 写清「做什么 + 什么时候用」。第二条被低估得最厉害:大部分「我写的 Skill 没生效」,是 description 写坏了,不是正文写坏了。 下面这份是完整的、可以直接抄走的一个 Skill —— 一个替你审周报的技能。它不做花活,只做一件你每周都要做的事:
SKILL.md
---
name: review-weekly-report
description: Reviews a draft weekly work report before the user sends it,
  checking for vague claims, missing numbers, and buried blockers. Use when
  the user shares a weekly update, status report, or standup summary and
  asks for a check, a review, or feedback before sending.
---
 
# Review a weekly report
 
You are reviewing a draft, not rewriting it. The user is about to send
this to their manager or their team.
 
## Steps
 
1. Sort every line into one of three buckets: Progress, Blocker, Next.
   A line that fits none of the three is filler — say so.
2. For each Progress line, check it carries a number or a verifiable
   fact. "Improved onboarding" is not a claim; "onboarding drop-off
   28% -> 19%" is.
3. Find the blockers. Blockers hidden inside a Progress sentence are
   the single most common defect — pull them out and list them
   separately.
4. Check the Next section is committed, not aspirational. "Look into
   X" is aspirational; "ship X behind a flag by Thursday" is committed.
 
## Output
 
Return exactly two things, in this order:
 
1. A short list of specific problems, each quoting the offending line.
2. The rewritten report.
 
Do not add praise. Do not add a summary of what you did.
 
## Like this
 
<example>
Draft line: "Made good progress on the search redesign, though we hit
some issues with the index."
 
Problem: two defects in one line — an unmeasured claim, and a blocker
buried inside a progress sentence.
 
Rewrite:
- Progress: search redesign 70% done; first-paint latency 1.2s -> 0.4s.
- Blocker: index rebuild fails on records older than 2024; blocked
  since Tuesday, need a decision on backfill vs drop.
</example>
 
## When not to use this
 
If the user asks you to *write* the report rather than review a draft,
this skill does not apply. Say so and write it normally.

全文照抄即可。四段结构:frontmatter 决定它什么时候触发,步骤决定它怎么做,示例决定它做成什么样,最后一段决定它什么时候该闭嘴。

01

挑那段你粘到第三遍的 prompt

翻历史,找出你至少每周粘一次、结构基本不变的那段。粘第三遍是分界线:一次两次是巧合,第三次是流程。
02

先写 description,写「什么时候用」而不是「这是什么」

照上面那份的写法:一句话说它做什么,然后「Use when 用户……」列出触发场景,用你真会说的那些话(「帮我看看这份周报」「发之前给点意见」)。这一步花的十分钟,回报比正文高。
03

正文写步骤,不写原则

「保持专业」是原则,没用;「每条进展必须带一个数字或可核实的事实」是步骤,有用。原则它已经会了,步骤它不知道 —— 你的 Skill 的全部价值就在步骤里。
04

塞一个真例子,用你自己的烂句子

从你上一份周报里挑一句真的写得含糊的,连同你会怎么改,一起写进 example。虚构的例子会教出虚构的标准。
05

装上,然后用一句自然话试触发

别说「用 review-weekly-report 技能」—— 那是作弊。就说你平时会说的那句。它没触发,回去改 description 的「Use when」,不要改正文。

III

动手:让内置技能交一份真文件.

你要的常常不是一段文字表格,是一份真的 Excel。 Claude 内置了四个文档技能:Excel、Word、PowerPoint、PDF,相关任务会自动触发。4注 4Claude 帮助中心 · 什么是 Skills —— Anthropic 内置的文档技能覆盖 Excel、Word、PowerPoint 与 PDF,相关任务会自动触发,直接交出文件。截至 2026-08。让它做一份带公式的 Excel、一套 PPT、一份排好版的 Word,它直接给你文件,而不是一段你还得自己誊进表格的文本。这是网页用户最容易忽略、却最省事的一类能力 —— 你早就有这个技能,只是从没让它交文件。
提示词让它交一份能算的 Excel
把下面这些数据做成一个 .xlsx 文件给我下载,不要在回答里画表格。
数据:<把你的原始数据贴这里,乱一点没关系>
结构:第一个 sheet 是明细,第二个 sheet 是按<某个维度>的汇总。
合计和占比用真的公式算(SUM / SUMIF 之类),别把结果硬写成数字 —— 我改一行明细,汇总要跟着变。
表头加粗冻结首行;金额列保留两位小数。
做完告诉我你用了哪些公式,我要抽查一格。
把下面这些数据做成一个 .xlsx 文件给我下载,不要在回答里画表格。
数据:(粘贴的 60 行报销明细,含日期、供应商、类别、金额、是否含税)
结构:第一个 sheet 是明细,第二个 sheet 是按供应商的汇总。
合计和占比用真的公式算(SUM / SUMIF 之类),别把结果硬写成数字 —— 我改一行明细,汇总要跟着变。
表头加粗冻结首行;金额列保留两位小数。
做完告诉我你用了哪些公式,我要抽查一格。
最后那句「我要抽查一格」不是客套 —— 打开文件,点一下汇总里的某个合计,看编辑栏里是公式还是一个死数字。是死数字的,回去说一句「用公式重做」。这一次抽查,会决定你以后信不信它交的表。

IV

换个域,写哪个 Skill.

写一个「出题官」:给它一段你刚学完的材料,它按固定难度梯度出五道题(两道回忆、两道应用、一道反例),并且不给答案,等你答完再批。description 的触发场景写成「用户贴了一段学习材料并说想自测 / 检验掌握程度」。这个 Skill 的价值全在「不给答案」那一句 —— 没有它,它每次都会好心地把答案一起给你。
写一个「引用体检」:给它一段带引用的草稿,它逐条检查每个引述是否真的支持它挂着的那句话、日期够不够新、有没有把二手转述当一手源。输出固定成一张三列表(结论 / 引用 / 判定:支持 / 部分支持 / 不支持)。这个 Skill 和第 9 章的核对清单是同一件事的两种形态 —— 那边是手动过一遍,这边是把它固化。
写一个「改稿」:把口语化草稿改成能发出去的文案。步骤写死三条(删客套与重复、被动改主动、长句拆短),example 里放一组你真的改过的前后对照。这一类最适合固化,因为标准最稳定 —— 你的品牌词表半年不会变,而你每周都要改三五段稿。
本章给的那个「审周报」就是这一栏的样板。变体:一个「会议纪要转待办」的 Skill(每条待办必须有负责人和日期,没有的标出来问),或一个「复盘体检」(检查每条结论是否指向一个可改的动作,而不是一句感慨)。这一类 Skill 的共同价值:它替你做那件你最不想做的事 —— 挑同事写的东西的毛病。

四个能直接落成 SKILL.md 的候选。共同点:都是「审查 / 转换」类,不是「创作」类 —— 有明确验收标准的流程才值得固化,创作类固化了只会把你的风格冻在今天。

V

边界:什么不该做成 Skill.

一段重复的活值不值得做成 Skill,过一遍这五问 —— 三个「是」就动手:
还在频繁改的流程
别急着固化,否则你维护 Skill 的时间比省下的还多。等它连着三周没变,再写。
创作类
「写一篇有洞见的文章」做不成 Skill —— 没有验收标准的流程,固化下来只是把今天的你冻住。审查类、转换类才是甜区。
装太多
Skill 太多,触发判断会变迟钝 —— 它每次都要扫一遍所有简介。先只留你真在用的两三个,用顺了再加。
description 写成「这是什么」
最常见的失败。「一个专业的周报助手」永远不会被触发;「当用户分享周报草稿并要求 review 时用」才会。触发靠的是场景,不是名头。

VI

收束 · 本章验收.

到这里,你有了三件资产:一段全局指令、一个 Project、一个 Skill。它们都在替你省「说明」的功夫。下一章换个方向 —— 省「搬运」的功夫。

粘第三遍同一段 prompt, 就该把它变成 Skill.

Paste the same prompt a third time, and it should become a Skill.

Aklman Library

讨论

讨论.

评论区初始化中…