夜雨聆风Ch 5 讲了 SKILL.md 的"主说明书"怎么写。但 Skill 真正强大的是它的"配件库"——第 3 层辅助资源。一个 2KB 的 SKILL.md + 5 个 1KB 的辅助资源,比一个 7KB 的 SKILL.md 效果好得多。
辅助资源是 Skill 的"装备"——SKILL.md 是"主说明书",辅助资源是"工具箱"。用得对,LLM 产出质量飞跃;用得不对,反而拖累 Skill。
这一章讲 4 类资源的设计原则:模板(6.1)→ 参考(6.2)→ 脚本(6.3)→ 清单(6.4)。每类都有正例、反例和"过度配件"的反模式。
6.1 模板资源
6.1.1 模板的本质
模板是 Skill 的"填空题"——把产出的格式、字段、样式固定下来,LLM 只需往里填内容,不用管格式。
模板解决的问题:
- 格式一致
:不同人/不同次执行,产出格式完全一样 - 结构完整
:每个字段都有,不会漏 - 风格统一
:符合组织/团队的风格要求
💡
模板的 3 大作用
模板的 3 大作用:
- 降低 LLM 思考成本
——LLM 不用想"格式长啥样",只需填内容 - 保证质量底线
——模板强制关键字段存在,产出不会"漏" - 统一组织风格
——所有 Skill 产出符合组织规范
没有模板的 Skill,产出质量波动大;有模板的 Skill,产出稳定。
6.1.2 模板的 3 大要素
一个好的模板包含 3 大要素:
- 占位符(Placeholder)
:标记"这里填什么"——用 {{xxx}}或<占位>表示 - 填写说明(Fill Instructions)
:说明每个占位符应该填什么、怎么填 - 格式示例(Example)
:展示一个填好的例子,让 LLM 知道"好的产出长什么样"
6.1.3 模板的 4 条设计原则
原则 1:占位符明确,不要有歧义
✅ 好的占位符 {{参与人列表}}:用逗号分隔,如"张三,李四,王五" {{决议 1}}:用"决议 N: ..."格式,N 从 1 开始 {{行动项 1}}:用"[负责人] 在 [截止时间] 前 [行动]"格式 ❌ 不好的占位符 {{人}} {{事}} {{时间}} (LLM 不知道填啥,自由发挥)原则 2:填写说明要具体
✅ 好的填写说明 {{参与人列表}}:从会议记录中识别所有出现的姓名(忽略"主持人""记录人"等职位词),按发言顺序排列,逗号分隔。 ❌ 不好的填写说明 {{参与人列表}}:填写参与人。 (说明太粗,LLM 不知道"主持人"算不算)原则 3:格式示例要真实
✅ 好的示例 会议纪要:2024-12-15 项目例会 参与人:张三,李四,王五 议题:1) 项目进度 2) 下周计划 决议:1. 周三完成 API 对接 行动项: - 李四 在 2024-12-18 前 完成用户模块 API - 王五 在 2024-12-20 前 修复 P0 bug ❌ 不好的示例 参与人:XX 议题:YY 决议:ZZ (占位符没替换,无参考价值)原则 4:模板不嵌复杂逻辑
✅ 好的模板(纯静态) # {{标题}} **参与人**:{{参与人}} **日期**:{{日期}} ❌ 不好的模板(嵌逻辑) # {{if 多个议题}}多个议题{{else}}单议题{{end}} (模板不是程序,LLM 不该处理模板逻辑)💬
模板的「3 不」原则
模板的"3 不":
- 不嵌逻辑
——模板是结构,不是程序 - 不嵌 CSS/样式
——样式交给渲染层,模板只管结构 - 不嵌数据
——数据是动态填的,模板只占位
3 个"不"保证模板"静态、可读、可填"。
6.1.4 模板的 4 种粒度
不同任务需要不同粒度的模板:
| 整体模板 | ||
| 片段模板 | ||
| 字段模板 | ||
| 样式模板 |
💡
粒度选择的 3 个判断
粒度选择的 3 个判断:
- 任务复杂度
:复杂任务用整体模板;简单任务用字段模板 - 灵活性需求
:需要灵活就用片段模板;严格就用整体模板 - 维护成本
:粒度越细,模板越多,维护成本越高
经验法则:从整体模板开始,需要灵活时拆为片段。
6.1.5 模板的工程化建议
3 条工程化建议:
- 模板文件独立
:不嵌在 SKILL.md 里,放 templates/目录 - 模板版本化
:模板改了要改版本号,记录变更 - 模板有 README
:说明每个模板的用途、用法、适用场景
skill: meeting-minutes-organizer/ ├── SKILL.md ├── templates/ │ ├── README.md # 模板说明 │ ├── full-template.md # 整体模板 │ ├── action-item.md # 行动项片段 │ └── attendee.md # 参与人字段 ├── references/ └── tests/6.2 参考资源
6.2.1 参考的本质
参考是 Skill 的"字典"——把 Skill 用到的术语、规范、最佳实践放在一起,LLM 需要时查阅。
参考解决的问题:
- 术语统一
:不同人用不同的词,参考规定标准词 - 规范引用
:Skill 引用规范条款,不用全文抄 - 示例参考
:展示"标准产出"长什么样
💡
参考的 3 大作用
参考的 3 大作用:
- 降低 SKILL.md 长度
——详细规范放参考,SKILL.md 只引用 - 保持术语一致
——参考是"术语表",LLM 必查 - 沉淀组织知识
——规范条款集中管理,Skill 引用
没有参考,SKILL.md 会无限膨胀;有参考,SKILL.md 保持精炼。
6.2.2 参考的 4 类
类型 1:术语表(Glossary)
# 术语表 | 标准术语 | 同义词/反义词 | 备注 | |---|---|---| | 客户 | 用户、顾客 | 文档统一用"客户" | | 工程改造 | 工程变更、改建 | 文档统一用"工程改造" | | 配置项 | CI、Configuration Item | 文档统一用"配置项" |类型 2:规范引用(Standards Reference)
# SQL 规范引用 ## 命名规范(详见 sql-naming-conventions.md) - 字段名:snake_case - 表名:复数 - 关键字:大写 ## 索引规范(详见 index-best-practices.md) - 主键必须建索引 - WHERE/JOIN 字段建索引 - 行数 > 10 万的表必须有 LIMIT类型 3:示例参考(Example Reference)
# 优秀产出示例 ## 优秀 SQL 示例sql
SELECT id, user_name
FROM users
WHERE status = 'active'
LIMIT 100;
## 不好的 SQL 示例sql
select id,user_name from users where status='active';
类型 4:边界说明(Edge Case Reference)
# 边界情况 ## 边界 1:空输入 - 行为:返回"输入为空,请提供会议记录" - 不报错,优雅退出 ## 边界 2:超长输入(> 10000 字) - 行为:分段处理,每段 5000 字 - 警告:超长输入可能影响准确性 ## 边界 3:多语言混合 - 行为:优先识别主要语言,其他语言作为补充💬
4 类参考的优先级
4 类参考的优先级:术语表 > 规范引用 > 示例参考 > 边界说明。
- 术语表
:最高频用,LLM 几乎每次都要查 - 规范引用
:Skill 引用规范条款时用 - 示例参考
:LLM 产出格式参考 - 边界说明
:出问题才查
优先级高的放更显眼位置,LLM 容易找到。
6.2.3 参考的 4 条设计原则
原则 1:结构化,不要散文
✅ 好的参考(表格化) | 场景 | 标准术语 | 禁用术语 | |---|---|---| | 客户沟通 | 客户 | 用户、顾客 | | 系统设计 | 配置项 | CI、Configuration Item | ❌ 不好的参考(散文) "在文档中,我们一般用客户这个词,而不是用户。用户这个词在新员工中经常被误用,但根据我们的命名规范,应该用客户..." (信息淹没在文字里)原则 2:可搜索
✅ 好的参考(标题明确) ## SQL 命名规范 ## SQL 索引规范 ## SQL 性能规范 ❌ 不好的参考(标题模糊) ## 关于 SQL 的那些事 (LLM 不知道里面有什么)原则 3:不重复 SKILL.md
✅ 好的参考(详细) ## SQL 完整命名规范(50 条) 1. 字段名:snake_case 2. 表名:复数 ... (50 条) ❌ 不好的参考(简短重复) ## SQL 命名规范:请按 SKILL.md 中的规则。 (等于没说)原则 4:可独立读
✅ 好的参考(自包含) 本参考详细列出 SQL 命名规范,即使不读 SKILL.md 也能用。 ❌ 不好的参考(依赖 SKILL.md) (配合 SKILL.md 看,本参考才有意义)6.2.4 参考的工程组织
skill: sql-reviewer/ ├── SKILL.md ├── references/ │ ├── README.md # 参考索引 │ ├── sql-naming-conventions.md # 命名规范 │ ├── sql-index-best-practices.md # 索引规范 │ ├── sql-security-checklist.md # 安全清单 │ ├── sql-injection-patterns.md # 注入模式 │ └── example-outputs.md # 优秀/差产出示例组织原则:
- 一个主题一个文件
:命名规范、索引规范分文件 - README 做目录
:LLM 知道"哪个文件讲什么" - 文件名清晰
: sql-naming-conventions.md而不是naming.md
6.3 脚本资源
6.3.1 脚本的本质
脚本是 Skill 的"自动化工具"——把重复的、可程序化的任务用代码完成,LLM 只需调用脚本。
脚本解决的问题:
- 效率
:重复任务自动化,LLM 不需重复推理 - 准确性
:程序化处理比 LLM 处理更准(数据计算、格式转换) - 可观测
:脚本执行有日志,易调试
💡
脚本的 3 大作用
脚本的 3 大作用:
- 节省 Token
——LLM 调脚本,不需把代码放上下文 - 保证准确性
——数学计算、字符串处理用程序,不用 LLM 推理 - 支持复杂任务
——LLM 单独做不了的事,脚本可以做
没有脚本,LLM 做所有事;有脚本,LLM 只做"判断"+"调用"。
6.3.2 脚本的 4 种类型
类型 1:数据处理脚本
# scripts/extract_actions.py # 提取会议记录中的行动项 def extract_actions(meeting_text): # 用正则匹配"[负责人] 在 [截止] 前 [行动]"模式 pattern = r'\[?(\w+)\]? 在 (\d{4}-\d{2}-\d{2}) 前 (.+?)(?=。|$)' matches = re.findall(pattern, meeting_text) return [{'owner': m[0], 'deadline': m[1], 'action': m[2]} for m in matches]类型 2:格式转换脚本
# scripts/md_to_docx.py # Markdown 转 Word def md_to_docx(md_content, output_path): # 用 python-docx 转换 doc = Document() # ... (转换逻辑) doc.save(output_path)类型 3:校验脚本
# scripts/check_naming.py # 检查 SQL 命名是否合规 def check_naming(sql): issues = [] # 检查字段名 snake_case if re.search(r'[A-Z]\w+', sql): issues.append('字段名包含大写,应使用 snake_case') return issues类型 4:计算/统计脚本
# scripts/calc_metrics.py # 计算周报关键指标 def calc_metrics(week_data): return { 'completed_tasks': sum(1 for t in week_data if t['status'] == 'done'), 'pending_tasks': sum(1 for t in week_data if t['status'] == 'pending'), 'completion_rate': ..., }💬
脚本的 4 种选择
4 种脚本的选择:
- 数据处理
:LLM 不擅长(易错) - 格式转换
:LLM 也能做但慢 - 校验
:程序化检查更准 - 计算/统计
:LLM 推理慢且易错
能用脚本的,不要让 LLM 做。
6.3.3 脚本的 4 条设计原则
原则 1:独立可运行
✅ 好的脚本 if __name__ == '__main__': import sys input_file = sys.argv[1] with open(input_file) as f: data = f.read() result = process(data) print(result) ❌ 不好的脚本(必须 import Skill 才能用) from skill.utils import process if __name__ == '__main__': process(input)原则 2:参数化,不硬编码
✅ 好的脚本 def extract_actions(text, pattern=r'...'): return re.findall(pattern, text) ❌ 不好的脚本 text = "今天的会议讨论了..." pattern = r'...' def extract_actions(): return re.findall(pattern, text)原则 3:有错误处理
✅ 好的脚本 def parse_sql(sql): try: return sqlparse.parse(sql) except Exception as e: return [{'error': str(e), 'sql': sql}] ❌ 不好的脚本 def parse_sql(sql): return sqlparse.parse(sql) # 报错就崩原则 4:输出可解析
✅ 好的脚本(输出 JSON) {"actions": [{"owner": "张三", "deadline": "2024-12-18", "action": "完成 API"}]} ❌ 不好的脚本(输出自然语言) "找到了 3 个行动项,分别是张三在 12月18日完成 API..." (LLM 解析难)⚠️
脚本的 3 个反模式
脚本的 3 个反模式:
- 嵌业务逻辑到 LLM
:能用脚本的不用脚本,LLM 自由发挥 - 脚本太复杂
:脚本做了 Skill 的活,LLM 不知道做什么 - 脚本无测试
:脚本跑挂,LLM 不知怎么用
好的脚本 = 单一职责 + 独立可跑 + 有错误处理 + 输出可解析。
6.3.4 脚本与 LLM 的协作
脚本和 LLM 的关系是互补:
LLM 决策 ──调用──> 脚本执行 ↑ │ └────── 返回结果 ←────┘协作模式:
- LLM 调用脚本
:LLM 决定"调用哪个脚本、传什么参数" - 脚本执行
:脚本按参数执行,返回结构化结果 - LLM 处理结果
:LLM 读脚本输出,继续下一步
💡
LLM 调脚本的 3 个要点
LLM 调用脚本的 3 个要点:
- SKILL.md 写明调用方式
——用什么参数、返回什么 - 脚本位置明确
——LLM 知道去哪找 - 失败有 fallback
——脚本跑挂时,LLM 知道怎么办
3 个要点让 LLM-脚本协作顺畅。
6.4 检查清单资源
6.4.1 清单的本质
清单是 Skill 的"质量门禁"——一组检查项,LLM 产出后自检,确保质量。
清单解决的问题:
- 完整性
:不漏关键字段/章节 - 准确性
:关键信息不偏离 - 规范性
:符合组织/团队标准
💡
清单的 3 大作用
清单的 3 大作用:
- 保证完整性
——清单强制所有必填项都有 - 保证一致性
——所有 Skill 产出符合同一标准 - 降低 LLM 失误
——LLM 自由发挥易漏,清单是约束
没有清单,LLM 产出看运气;有清单,LLM 产出有底线。
6.4.2 清单的 4 种类型
类型 1:必填字段清单
# 会议纪要必填字段 - [ ] 参与人(≥ 1 人) - [ ] 议题(≥ 1 个) - [ ] 决议(每个议题 0-N 个) - [ ] 行动项(每个含负责人+截止时间) - [ ] 下次会议时间(选填)类型 2:质量检查清单
# SQL 审查质量清单 - [ ] 语法无错误(sqlfluff parse 通过) - [ ] 命名符合规范(snake_case、复数) - [ ] 主键/外键已声明 - [ ] WHERE/JOIN 字段已建索引 - [ ] 无 SELECT * - [ ] 大表查询有 LIMIT - [ ] 无 SQL 注入风险 - [ ] 无明文密码/未脱敏信息类型 3:边界检查清单
# SQL 审查边界清单 - [ ] 输入是 SQL 语句(不是其他文本) - [ ] SQL 长度 < 10000 字 - [ ] 不含跨方言特殊语法(如 Oracle CONNECT BY) - [ ] 不含敏感数据(如密码、身份证)类型 4:产出格式清单
# 会议纪要格式清单 - [ ] Markdown 格式 - [ ] 标题用 # 开头 - [ ] 参与人用 "姓名(角色)" 格式 - [ ] 行动项用 "[负责人] 在 [截止] 前 [行动]" 格式 - [ ] 决议用 "决议 N: ..." 编号 - [ ] 字数 500-2000 字💬
4 类清单的优先级
4 类清单的优先级:
- 必填字段清单
:必须 100% 满足 - 质量检查清单
:满足 80%+ 即合格 - 边界检查清单
:违反则报错 - 产出格式清单
:满足 90%+ 即合格
优先级不同,LLM 处理时权重不同。
6.4.3 清单的 4 条设计原则
原则 1:可验证,不可"主观"
✅ 好的清单项 - [ ] 参与人数量 ≥ 1 - [ ] 每个行动项含截止时间 - [ ] 字数 500-2000 ❌ 不好的清单项 - [ ] 参与人列表合理 - [ ] 行动项描述清楚 - [ ] 整体质量好 (LLM 不知道"合理"是什么标准)原则 2:可勾选,不要"思考"
✅ 好的清单(用 checkbox) - [ ] 检查项 1 - [ ] 检查项 2 - [ ] 检查项 3 ❌ 不好的清单(用问句) - 是否包含参与人? - 行动项是否含截止时间? (LLM 看到"是否"会觉得"可选",checkbox 强制必做)原则 3:嵌入 SKILL.md 必读
清单不是独立的——它要在 SKILL.md 里被引用,成为 LLM 必做的一步。
# SKILL.md 中的引用 ## 操作步骤 1. 提取参与人 2. 提取议题 3. 提取决议 4. 提取行动项 5. **按 [清单] 自检,所有必填项都有** ← 引用清单 6. 输出结构化纪要 ## 资源索引 - `checklist.md` — 必填字段清单原则 4:清单本身要精简
✅ 好的清单(< 30 项) - 10 个必填字段 - 10 个质量检查 - 5 个边界检查 - 5 个格式要求 = 30 项,可控 ❌ 不好的清单(> 100 项) - 所有可能的检查都列上 (LLM 看到 100+ 项会跳过)⚠️
清单的 3 个反模式
清单的 3 个反模式:
- 清单太多
:> 30 项 LLM 跳过,等于没有 - 清单太虚
:"内容合理"——LLM 不知道什么算"合理" - 清单无引用
:清单独立放着,SKILL.md 不引用——LLM 不知道要用
好的清单 = 10-30 项 + 可验证 + SKILL.md 必引用。
6.4.4 清单的"自检并报告"指令模式
最有效的清单使用模式:LLM 产出后,先自检,再报告。
## SKILL.md 操作步骤(包含清单) 1. 提取参与人 2. 提取议题 3. 提取决议 4. 提取行动项 5. 输出结构化纪要 6. **自检**:按 [清单] 逐项检查,所有必填项都有 7. **报告**:自检通过则输出"自检通过";不通过则报告缺什么💡
自检并报告的 3 大价值
自检并报告的 3 大价值:
- LLM 必须做自检
——清单不是"参考",是"必做" - 报告让用户知道质量
——用户知道这次产出"全过/有缺" - 失败可补救
——LLM 报告缺什么,可以补做
3 个价值让清单从"文档"变成"工具"。
6.4.5 清单的 4 个工程化建议
- 清单独立文件
: checklist.md而非嵌在 SKILL.md - 清单分类
:必填/质量/边界/格式分小节 - 清单版本化
:清单改了,改版本号 - 清单有测试
:用真实任务测试清单是否合理
6.5 4 类资源的工程组合
6.5.1 资源组合的 3 种模式
| 文档型 Skill | ||
| 审查型 Skill | ||
| 分析型 Skill |
6.5.2 一个完整 Skill 的资源清单示例
以"会议纪要整理"Skill 为例:
skill: meeting-minutes-organizer/ ├── SKILL.md # 主说明书(1-3 KB) ├── templates/ │ ├── README.md # 模板说明 │ ├── full-template.md # 整体模板 │ ├── action-item-format.md # 行动项格式 │ └── attendee-format.md # 参与人格式 ├── references/ │ ├── README.md │ ├── terminology.md # 术语表 │ ├── meeting-types.md # 会议类型说明 │ └── example-outputs.md # 优秀/差产出示例 ├── scripts/ │ ├── extract_actions.py # 行动项提取脚本 │ ├── extract_decisions.py # 决议提取脚本 │ └── check_completeness.py # 完整性校验脚本 └── checklist.md # 必填/质量/边界/格式清单资源组织原则:
- 目录分类
:templates / references / scripts / checklist.md - 每个目录有 README
:LLM 知道里面有什么 - 资源有版本
:Skill 改版本,资源跟着改
💡
资源组织的 3 个原则
资源组织的 3 个原则:
- 按类型分目录
——templates / references / scripts - 每个目录有 README
——LLM 知道在哪查什么 - 资源不重复
——SKILL.md 不重复资源内容,只引用
3 个原则让 Skill 资源清晰、可维护、可扩展。
6.6 「过度配件」的反模式
6.6.1 什么是「过度配件」
过度配件:辅助资源太多/太杂/太重,反而拖累 Skill。 3 种典型过度配件:
- 数量过多
:一个 Skill 配 20+ 个资源文件 - 内容过载
:单个资源 50+ KB,加载耗时 - 重复冗余
:资源内容重复,LLM 不知用哪个
⚠️
过度配件的 3 大危害
过度配件的 3 大危害:
- 上下文压力
——LLM 读资源耗 Token,主任务资源被挤 - 维护成本
——资源多,改一个要改一堆 - 选择困难
——LLM 不知道用哪个资源
好的 Skill = 资源少而精,而不是多而杂。
6.6.2 数量过多的反例
# ❌ 反例:一个 Skill 配 20+ 资源 skill: meeting-minutes-organizer/ ├── SKILL.md ├── templates/ │ ├── template-v1.md # 旧版本,已废弃 │ ├── template-v2.md # 当前版本 │ ├── template-v3.md # 试用版 │ ├── template-v3-final.md # 最终版 │ ├── template-v3-final-2.md # 修订版 │ ├── ... (10 个模板文件) ├── references/ │ ├── references-v1.md │ ├── references-v2.md │ ├── ... (5 个) ├── scripts/ │ ├── scripts-v1.py │ ├── ... (5 个脚本)问题:LLM 看到一堆"v1/v2/v3/final/2",不知道用哪个。维护者看到一堆旧版本,不敢删。 正例:当前版本 1 份,旧版本归档——只留 1 个 template.md,旧版进 _archive/(LLM 不读)。
6.6.3 内容过载的反例
# ❌ 反例:SQL 规范参考 50 KB # SQL 完整规范 ## 命名规范(200 条) 1. 字段名:snake_case 2. 字段名长度 < 30 字符 3. 表名:复数 4. 表名长度 < 30 字符 5. 主键命名:表名_id ... (200 条) ## 索引规范(150 条) 1. 主键必须建索引 2. 外键必须建索引 ... (150 条) ## 性能规范(200 条) 1. 避免 SELECT * ... (200 条)问题:50 KB 资源,LLM 加载耗大量 Token,但实际常用的就 20-30 条。 正例:核心 20-30 条 + 详细规范外置——SKILL.md 引用的"核心规范" 20-30 条,完整版 200 条放外置文档(LLM 不自动加载,需要时再读)。
6.6.4 重复冗余的反例
# ❌ 反例:3 个文件说同一件事 templates/template.md: "参与人格式:姓名(角色)" references/format.md: "参与人格式:姓名(角色)" checklist.md: "参与人格式:姓名(角色)"问题:3 个文件说同一件事,LLM 不知道哪个权威。改一个要改 3 个。 正例:单一来源——SKILL.md 引用 references/format.md 一处,其他文件不重复。
💡
避免过度配件的 4 条原则
避免过度配件的 4 条原则:
- 资源数量控制
——一个 Skill 配 5-10 个资源,不要超过 15 - 资源大小控制
——单个资源 < 10 KB - 单一来源
——同一信息只在一处定义 - 旧版本归档
——用 _archive/ 目录管理旧版,LLM 不读
4 条原则让 Skill 资源"少而精"。
本章小结
这一章讲了 Skill 第 3 层辅助资源的完整设计方法:
- 6.1 模板资源
:模板 = 占位符 + 填写说明 + 格式示例,4 条原则(明确/具体/真实/不嵌逻辑) - 6.2 参考资源
:4 类(术语表/规范引用/示例参考/边界说明),结构化、可搜索、不重复 SKILL.md - 6.3 脚本资源
:4 种类型(数据处理/格式转换/校验/计算),独立可跑 + 参数化 + 有错误处理 + 输出可解析 - 6.4 清单资源
:4 种类型(必填/质量/边界/格式),可验证 + 可勾选 + SKILL.md 必引用 + "自检并报告"指令 - 6.5 工程组合
:文档型 = 模板+清单;审查型 = 清单+参考;分析型 = 脚本+清单+模板 - 6.6 过度配件
:3 大危害(上下文/维护/选择),4 条避免原则(数量/大小/单一/归档)
核心记住 4 句话:
- 辅助资源是 Skill 的"装备"
——SKILL.md 是主说明书,资源是工具箱 - 4 类资源各有分工
——模板填空、参考查规范、脚本自动化、清单守底线 - "自检并报告"是最有效的清单使用模式
——清单从"文档"变成"工具" - 少而精 > 多而杂
——一个 Skill 配 5-10 个资源,不要超过 15
下一章 [第 7 章 多 Skill 怎么编排才不打架](/skills/07-多Skill编排),我们进入"组合"——多个 Skill 怎么协同工作,3 种组合模式(并行/串行/嵌套)+ Skill 与工具/RAG 的协同 + 3 层架构(通用层/领域层/场景层)。