skill 是 Agent 的长期记忆——工具是手，skill 是 know-how
上一讲结束，我们留了个尾巴：工具给了 Agent 一双”手”，可光有手不会干活——它还得知道”咱们这个团队是怎么做事的”：需求文档按什么格式写？原型按什么规范画？代码按什么标准出？这些 know-how，放哪？
这一讲的答案，学过 skill 课的大伙已经会抢答了。但没学过的大伙也完全跟得上——咱们会把必需的部分讲到自足，然后把更深的路指出来。这一讲是整个课程的枢纽：前面六讲的每一块，都要在这里拼起来。
问题一：know-how 放哪？塞进提示词里吗？
第一反应往往是：塞进系统提示词。三个规范往系统提示词里一扔，Agent 每次都看得到，多省事。
且慢，第 3 讲的内容还没忘吧？假设每个规范 2000 token，三个全常驻长下文，每轮调用白烧 6000 token——注意力被稀释，成本乘上轮数。而真实情况是：写需求这一步只需要需求规范，画原型这一步只需要原型规范。全塞进去，大部分都是无关的噪声。
那正确的姿势是什么？第 3 讲已经给过答案——按需加载。而 skill，正是”按需加载的知识包”的一种标准化实现：
第一层：元数据（常驻，几十个 token）
名字 + 一句话说明"什么时候该用它"
第二层：正文（触发后才载入）
这个 know-how 的完整写法
第三层：资源（用到才读）
模板、示例、checklist，存在文件里看出门道了吗？Agent 平时只看到每个 skill 的一句话元数据——”写需求文档时用我”。等它真要写需求了，才把需求规范的正文载进来；正文里的模板和示例，用到哪份读哪份。上下文里永远只有当前需要的那一份知识，稀缺预算花在刀刃上。
再和第 4 讲接一下：skill 就是 Agent 的长期记忆。它写在外部文件里，不占上下文；需要时按指针取回。前面说的”记忆不是模型的功能，是我们设计出来的结构”——skill 就是这个结构最成熟的形态。
学过 skill 课的童鞋，到这里终于可以把三层加载、按需加载、长期记忆三个词连成一条线了：它们从头到尾就是同一个思想。课程叫《Agent 设计实战》，地基其实早就打好了。（沈剑写第一门课的时候也没想到，那七课是在给 Agent 铺路——写课的人也被课程教育了。）
问题二：工具和 skill，怎么分工？
上一讲咱们给 Agent 造了手（工具），这一讲又给了它 know-how（skill）。这两者的边界在哪？一句话：
工具 = 手 动作能力：能读、能写、能跑命令
skill = know-how（经验诀窍） 做事方法：需求怎么写、代码怎么出、什么算好举个栗子。团队新来一位同事，咱们给他两样东西：一是工位权限——能访问代码库、能提 PR、能跑流水线，这是工具；二是团队文档——需求文档模板、代码规范、评审清单，这是 skill。只给权限不给文档，他能动手但不知道怎么做才对；只给文档不给权限，他知道该怎么做但什么也动不了。
落到咱们的设计上：第 6 讲的 read_spec 工具负责”能读到规范文件”，这一讲的规范 skill 负责”规范里写了什么、怎么用”。手负责拿得到，know-how 负责做得对——两个凑齐，Agent 才算正式上岗。
问题三：一个好 skill，怎么写出来？
怎么才能写出一个好 skill？skill 课用了七课才讲透。这里咱们来个速成版——三个要点公式：
要点一：description 是触发器，而不是摘要
它决定 Agent 什么时候想起用这个 skill
写给模型看的：什么时候用 + 用来干什么
要点二：正文是路由器，而不是知识仓库
别把全部知识堆进正文
正文只放主干，细节指向第三层资源
要点三：资源按需加载
模板、示例、checklist 都放文件里
用到哪份，读哪份拿”需求规范”这个 skill 示范一下骨架：
---
name: requirement-spec
description: 当需要撰写或评审需求文档时使用。
提供团队需求文档的结构规范、
字段要求和验收标准。
---
# 需求文档规范
## 必须包含的五个部分
（主干要求，10 行以内）
## 模板见 templates/requirement.md
## 常见缺陷清单见 references/checklist.md注意 description 的写法。不要写”这是一个需求规范”——那是摘要。要写”当需要撰写或评审需求文档时使用”——这才是触发器。Agent 靠这句话决定什么时候把它载进来。写错一个字，它可能永远想不起用这个 skill，或者什么时候都乱用。
想系统学透这套方法的你，移步第一门课《如何写好一个 Skill》——七课，从机制讲到评审，全部免费。这一讲咱们只取”三个要点”直接上手。
description 是写给模型看的，不是写给人看的——这话 skill 课说过，第 6 讲工具描述又应验一次，今天第三次。重要的事情，课程会反复让它应验。
落到 sdd-site-agent：三个规范就是三个 skill
现在，整个课程最爽的一步来了。回头看咱们的贯穿项目——sdd-site-agent 需要需求规范、原型规范、架构规范三类 know-how。用今天的框架看：
需求规范 → requirement-spec skill
触发：写需求文档时 资源：模板+缺陷清单
原型规范 → prototype-spec skill
触发：画原型时 资源：原型模板+组件库
架构规范 → architecture-spec skill
触发：出技术方案时 资源：架构模板+决策清单三个规范，就是三个 skill。用 skill 课的方法把它们写出来，sdd-site-agent 就拥有了”团队的全部 know-how”：写需求时载需求规范，出方案时载架构规范——每次只带当前步骤需要的那一份，上下文干净，输出对齐团队标准。
而且注意第 4 讲的呼应：这些 skill 文件就是 sdd-site-agent 的长期记忆资产——越攒越多，越用越值。它们不会随着对话结束而消失，它们是咱们团队的规范沉淀。
实操演练（约 25 分钟）
必做部分 + 一步加餐。做完必做部分，本讲的核心手感就到手了。
检验一下
①requirement-spec skill 完整版：frontmatter + 正文主干 + 至少一份资源文件（模板或缺陷清单）——sdd-site-agent 的第一个 skill，第 8 讲拆多 Agent 时它要上岗；
②prototype-spec 和 architecture-spec 的 description 初稿：各一条触发器式 description——三个 skill 齐整，第 8 讲才好分工。
你如果想深挖一层，读这个：Agent Skills 规范；想系统学透写法，移步第一门课：《如何写好一个 Skill》
三个要点公式在 skill 课里有七课的完整展开：机制、触发器、正文写法、骨架实操、资源迭代、综合评审、转授他人。全部免费。
但还有一个没解决的问题：一个 Agent 带着三个规范 skill 已经能干活了。可任务一大，让它一个人又写需求、又画原型、又出方案、又写代码，它还是会乱——什么时候该把这些角色拆给不同的 Agent？拆错了会怎么样？——第 8 讲，我们讲多 Agent 编排。
知其然，知其所以然。思路比结论更重要。