还记得刚用 Claude Code 那会我很容易把各种规则都往CLAUDE.md里塞。代码风格目录约定测试命令这些放进去没问题。可后来一些代码审查 checklist、PR 总结流程、UI 验收步骤也开始往里面堆。这时候问题就来了。这些流程确实有用但它们不是每一轮任务都要用。每次带上的话会增加很多无用的信息反而会干扰模型的判断。这类内容就别继续塞进CLAUDE.md了。如果你总是在对话里复制同一段 instructions、checklist 或多步骤流程或者CLAUDE.md的某一节已经像操作手册就可以把它拆出来。差别主要在加载方式上。CLAUDE.md通常会在会话开始时作为持久上下文加载Skill 平时只暴露名称和描述真正命中时才加载完整内容。长参考材料、检查清单、脚本说明不用一开始就挤进上下文。这篇文章主要讲 Claude Code Skills 的技术实现和运行方式。我会参考社区源码分析材料看实现细节但当前用法以官方文档和 changelog 为准。如果你想先系统了解 Agent Skills 和 Prompt、MCP、Function Calling 的区别可以看我之前写的 Agent Skills 是什么和 Prompt、MCP 到底差在哪[1]。如果更关心有哪些现成 Skill 值得装可以直接看 AI 编程必备 Skills 推荐TDD、代码审查、网页自动化与 MCP 实战[2]。Skills 解决了什么问题先看CLAUDE.md和 Skill 的分工。CLAUDE.md适合放每轮都要用到的项目事实和长期规则比如代码风格、目录约定、常用命令、架构说明。Skill 适合放有明确触发场景的流程。它们需要被复用但不需要每次都跟着会话启动。最典型的是这些一套代码审查 checklist一套排查线上问题的步骤一个生成 PR 总结的流程一个只在改 UI 时才需要的设计规范一个只在写测试时才用到的 TDD 工作流。它们的共同点是步骤固定、篇幅不短但只在特定任务里出现。如果全部写进CLAUDE.md启动时就会变成额外的上下文成本越堆越重。你可以把 Skill 理解成一份按需打开的操作手册平时只让 Claude 知道有这项能力真用到的时候再把完整说明拿出来。Skill 和 Prompt、MCP、Function Calling 对比CLAUDE.md则反过来。官方建议把它留给每轮都要知道的内容比如构建命令、项目约定、目录结构以及必须一直遵守的规则。如果一段内容已经是多步骤流程或者只影响代码库里的某个局部就更适合移到 Skill 或 path-scoped rule。真到项目里拆的时候我一般不会先纠结名字而是先看这段内容到底卡在哪。如果卡在“规则每轮都要生效”那更像CLAUDE.md的问题。如果卡在“一段流程反复复制”那更像 Skill 的问题。如果卡在“任务太长完整过程会挤占主会话上下文”才考虑 Subagent。如果卡在“团队里每个人都要装一套”再考虑 Plugin。我用了一张表格总结了一下上面提到的概念机制主要解决的问题CLAUDE.md常驻项目规则和长期约定Skill只有特定任务才会用到的流程和清单Subagent把长任务或支线任务委派给另一个 AgentPlugin分发 Skills、Agents、Hooks、MCP 等扩展能力Claude Code 里的 Skill 可以理解成“prompt-based command”。自定义命令这块也已经并到 Skills 体系里了。现在.claude/commands/deploy.md和.claude/skills/deploy/SKILL.md都能创建/deploy旧的.claude/commands/不用马上迁移仍然兼容。Subagent 解决的是“谁来做”Skill 解决的是“怎么做”。Plugin 负责分发。一个 Plugin 可以带 Skills、Agents、Hooks 和 MCP Servers。企业或团队如果要统一发放能力Plugin 会比单独复制 Skill 文件更适合。如果项目里同时有CLAUDE.md、AGENTS.md、局部规则、SPEC 和 Skills也可以按这个思路拆常驻规则放在规则文件里可复用流程交给 Skill本次任务的验收标准放到 SPEC。CLAUDE.md 与其他规则文件怎么分工适合变成 Skill 的内容通常有几个特点经常复用有明确触发场景步骤比较固定内容比较长不适合常驻上下文最好还能配 supporting files 或脚本例如scripts/、references/、templates/。代码审查、TDD、PR 总结、数据库变更检查、UI 验收、日志排查都属于这类任务。不适合做成 Skill 的是项目里永远要遵守的硬规则。比如“所有 Java 代码使用 Google Java Style”这种更适合放CLAUDE.md或项目规则里。关于CLAUDE.md的详细介绍和最佳实践可以参考我写的这篇 CLAUDE.md 最佳实践该写什么、不该写什么、项目变大后怎么拆[3]。SKILL.md怎么写一个文件系统 Skill 通常是这样的目录结构.claude/skills/ pr-summary/ SKILL.md scripts/ collect-pr-info.sh references/ review-checklist.mdSKILL.md由两部分组成YAML frontmatter描述名字、触发条件、工具权限、模型、执行上下文等元数据。Markdown body真正发给 Claude 的操作说明。一个最小例子---name: pr-summarydescription: Summarize a pull request and list key risksallowed-tools: Bash(gh *)---Read the pull request diff and comments, then summarize:1. Main changes2. Risky files3. Missing tests4. Suggested follow-up当你执行/pr-summaryClaude Code 会把这个 Skill 渲染成 prompt再交给模型。源码里的parseSkillFrontmatterFields()支持的字段比较多常见字段可以先看下面这些字段作用name展示名目录名通常决定命令名description给模型判断何时使用when_to_use更细的触发说明allowed-tools预批准该 Skill 可用的工具model指定模型别名effort指定推理/努力等级user-invocable是否允许用户通过/skill-name直接调用disable-model-invocation禁止模型自动调用只允许用户手动调用paths条件触发路径context支持fork让 Skill 在子代理上下文中运行agent绑定指定 Agentshell指定动态上下文命令使用 bash 或 powershell这里别一上来就把字段全堆上。大多数 Skill 只需要description、allowed-tools和正文说明。字段越多维护成本越高。这里有几个字段容易混字段更适合解决什么问题allowed-tools收窄当前 Skill 可以直接使用的工具范围context: fork让长流程、调研类、审查类任务在 fork 上下文里跑agent指定由哪个 Agent 执行这个 Skill例如context: forkagent: Exploreallowed-tools: Bash(gh *)这类配置适合 PR 总结、模块审查、文档汇总这类任务。主会话不一定要背完整过程只拿结果就够。Skills 还支持参数替换。最简单的是$ARGUMENTS---name: fix-issuedescription: Fix a GitHub issuedisable-model-invocation: true---Fix GitHub issue \$ARGUMENTS following our coding standards.执行/fix-issue 123Claude 收到的内容里$ARGUMENTS会被替换成123。如果要按位置取参数可以用$ARGUMENTS[0]也可以用短写$0Migrate the $0 component from $1 to \$2.执行/migrate-component SearchBar React Vue$0、$1、$2会分别替换成SearchBar、React、Vue。Claude Code 怎么发现 SkillsClaude Code 会从多个来源加载 Skills。常见位置包括~/.claude/skills/.claude/skills/用户级 Skills 放在~/.claude/skills/所有项目都能用。项目级 Skills 放在项目的.claude/skills/适合和团队共享。项目里的 .claude/skills 目录示例从源码看Skills 目录采用的是skill-name/SKILL.md也就是说/skills/目录下单独一个.md文件不是标准 Skill 格式目录里要有SKILL.md。Claude Code 的 Skill 来源大致可以分几类类型来源说明用户级 Skills~/.claude/skills/个人长期复用项目级 Skills.claude/skills/项目或团队共享Managed Skills管理策略目录组织统一下发Bundled SkillsClaude Code 内置例如/code-review、/debug、/loop等Plugin Skills插件提供跟随 plugin 安装和启用MCP SkillsMCP Server 映射能力来自 MCP ServerClaude Code 包含一些 bundled skills比如/code-review、/batch、/debug、/loop和/claude-api。它们和普通内置命令不一样属于 prompt-based skill。Claude Code 官方文档中的 Bundled skills 说明嵌套.claude/skills目录也要留意。v2.1.178 后嵌套.claude/skills目录在处理对应文件时也会加载。发生名称冲突时嵌套 Skill 会以dir:name的形式出现避免覆盖外层同名 Skill。这和项目规则的思路接近越靠近当前工作目录的配置越能表达局部上下文。不过不建议滥用嵌套 Skills。只有当子目录确实有独立工作流时才拆比如frontend/.claude/skills/ui-review/SKILL.mdbackend/.claude/skills/api-contract-check/SKILL.mddocs/.claude/skills/article-review/SKILL.md如果只是为了分类普通目录和文件名就够了。旧版.claude/commands/仍然兼容。源码里也能看到 legacy commands loader如果旧命令目录里存在SKILL.md会按 Skill 方式处理否则继续按 Markdown command 加载。官方文档里已经写明custom commands 已经合并进 Skills但已有.claude/commands/文件会继续工作。新写能力时建议直接用.claude/skills/name/SKILL.md。Skill 被调用后发生什么Skill 平时不会把完整正文塞进上下文。Claude Code 主要通过 Skill 的名称、描述、when_to_use等 frontmatter 信息让模型知道有哪些能力可用。源码里还有一个estimateSkillFrontmatterTokens()只估算 name、description、whenToUse 的 token因为完整内容只在调用时加载。当用户执行/skill-name或者模型判断某个 Skill 适合当前任务时Claude Code 才会调用getPromptForCommand()把 Skill body 渲染出来。这也是 Skills 比长CLAUDE.md更省上下文的主要原因。Agent 执行链路Skill 被调用后Claude Code 会先拿到 Markdown body然后依次做几件事展开参数比如$ARGUMENTS、$0。替换${CLAUDE_SKILL_DIR}。替换${CLAUDE_SESSION_ID}。如果不是 MCP 来源再执行内嵌 shell 命令。返回最终 prompt 给模型。createSkillCommand()里对应的实现就是getPromptForCommand()。它会等到真正调用时才处理不会在启动阶段把所有 Skill 都渲染好。Skill 可以带 supporting files比如脚本、参考文档、模板。目录结构可以是my-skill/ SKILL.md scripts/ references/ templates/如果正文里需要引用脚本路径可以用${CLAUDE_SKILL_DIR}Run this helper:!${CLAUDE_SKILL_DIR}/scripts/collect-context.sh这样 Skill 移动目录后也不容易坏。不过支持文件不应该全量塞进正文。更好的写法是在SKILL.md里告诉 Claude 什么时候读取哪个文件。用得到再读用不到就别进上下文。这就是渐进式披露先让模型知道“有这个能力”命中后再读正文正文里只放流程骨架真正长的材料继续放到 supporting files。渐进式披露三层模型所以SKILL.md不适合写成超长 README。正文里优先写什么时候用、按什么顺序做、哪些情况别做、失败怎么兜底长清单、模板和脚本说明放到references/、templates/、scripts/里。SKILL.md 正文最好控制在 500 行以内CLAUDE.md和 Skill 的区别也可以回到加载策略上理解内容更适合放哪里项目编码规范CLAUDE.md目录结构说明CLAUDE.md代码审查流程SkillPR 总结流程SkillUI 验收 checklistSkill线上故障排查脚本Skill supporting files不要把 Skill 当成另一个更长的CLAUDE.md。Skill 的价值在于按需加载而不是换个目录继续堆规则。动态上下文和安全限制Skills 支持动态上下文注入语法是当前 Git 状态!git status --short也支持代码块形式!git log --oneline -5这些命令会在 Skill 内容发送给 Claude 之前执行。命令输出会替换原来的占位符模型看到的是最终结果不是命令本身。官方文档里也强调这是 preprocessing。Claude 只看到渲染后的 prompt。它和 Claude 调用 Bash 的区别很大。Claude 调用 Bash是模型在 agent loop 里决定使用工具。它会产生一次工具调用工具结果进入对话历史。Skill 里的动态命令是 prompt 预处理。命令先执行输出被塞进 Skill prompt。模型不会看到“我要执行这条命令”的过程。适合放在动态上下文里的内容通常是稳定、只读、低风险的上下文采集比如git status --shortgit diff --name-onlygh pr view --comments项目自带的只读脚本不要把会修改文件、提交代码、删除资源的命令写进动态上下文。动态上下文应该负责“收集材料”不负责“执行改动”。MCP 来源的 Skill 更特殊。源码里的判断条件是loadedFrom ! mcp时才执行内嵌 shell。MCP Skill 来自远程 MCP Server不一定可信。如果允许远程服务器返回一个带动态命令的 Skill再在本机执行就会变成远程代码执行风险。所以 MCP 来源的 Skill 会跳过内嵌 shell。文件系统、本地项目、受信任来源的 Skill 才能走这条预处理链路。同时即使是本地 Skill命令执行前也会走同一套工具权限检查。allowed-tools可以给当前 Skill 放行一部分命令但不是无条件执行。第三方 Skill 也要按这个思路检查。安装前至少看一遍SKILL.md、scripts/、references/确认里面没有危险命令、异常脚本或过宽权限。安装 Skill等于把一套流程交给 Agent 执行来源不清楚时别急着让它进项目。企业环境里官方 settings 文档有一个和治理相关的配置strictPluginOnlyCustomization。它可以限制 skills、agents、hooks、MCP servers 的来源。比如设置{ strictPluginOnlyCustomization: [skills, hooks]}被锁定后用户级和项目级来源会被跳过只加载 plugin 提供的、managed settings 提供的或者内置的能力。这类配置适合团队或企业环境。个人项目一般用不上但如果公司要统一管理 AI 编程工具的扩展来源就不能只靠口头约定。Skills 怎么和 Agent 配合Skill 可以跑在 Subagent 里。官方文档里有“Run skills in a subagent”相关说明Skill frontmatter 也支持context: fork和agent。例如一个 PR 总结 Skill可以让 Explore agent 在 fork 上下文里跑context: forkagent: Exploreallowed-tools: Bash(gh *)这样主会话不用自己背完整 PR diff、评论和文件列表只拿总结结果。context: fork适合三类场景Skill 过程很长Skill 需要读很多文件或外部信息主会话只关心结果不关心完整过程。比如生成 PR 风险摘要、对一个模块做只读审查、汇总文档和 issue、生成迁移计划都可以考虑 fork。不适合放到 fork 里的是那些必须和主会话持续互动的任务。比如你正在手动调整某个核心设计Skill 每一步都要你确认那就不要 fork 出去。Agent Teams 也会带来额外上下文开销。官方成本文档提醒过teammates 会自动加载CLAUDE.md、MCP servers 和 Skills。也就是说Agent Teams 不是只多了几个 prompt每个 teammate 都有自己的启动开销。这并不代表不要用 Skills而是要控制 Skill 描述和触发范围description写清楚不要让模型误触发长内容放 supporting files不要全塞SKILL.md用disable-model-invocation限制只允许手动调用的 Skill大型团队项目用strictPluginOnlyCustomization控制来源。Skill 的设计目标是按需加载。如果描述太泛、触发太频繁它就会从“节省上下文”变成“额外开销”。实际项目里我一般按下面这个规则拆内容放哪里每轮都要遵守的规则CLAUDE.md特定路径下才生效的规则.claude/rules/或带paths的 Skill可复用操作流程Skill长参考材料Skill supporting files搜索、审查、验证支线Subagent多角色协作任务Agent Teams举个例子你要做一次后端接口重构。CLAUDE.md里放项目编码规范和测试命令api-contract-checkSkill 里放接口兼容性检查流程code-reviewSkill 里放审查 checklist搜索旧调用方交给 Subagent如果前端、后端、测试要并行推进再考虑 Agent Teams。这样拆的好处是规则、流程、执行者各自清楚。别把所有东西都塞进主会话也别为了显得高级到处开 Agent。总结我更愿意把 Skill 当成一种按需加载的操作手册。每轮都要遵守的继续放规则文件只有特定任务才会用到的流程拆成 Skill流程里很长的 checklist、模板和脚本说明再继续拆到 supporting files。判断标准也很简单如果你已经开始反复复制同一段提示词或者CLAUDE.md里某一节长到读起来像手册那它大概率该变成 Skill 了。反过来如果只是代码风格、测试命令、目录约定这类每轮都要遵守的硬规则就别为了用 Skill 而写 Skill。放在CLAUDE.md里反而更直接。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
还记得刚用 Claude Code 那会我很容易把各种规则都往CLAUDE.md里塞。代码风格目录约定测试命令这些放进去没问题。可后来一些代码审查 checklist、PR 总结流程、UI 验收步骤也开始往里面堆。这时候问题就来了。这些流程确实有用但它们不是每一轮任务都要用。每次带上的话会增加很多无用的信息反而会干扰模型的判断。这类内容就别继续塞进CLAUDE.md了。如果你总是在对话里复制同一段 instructions、checklist 或多步骤流程或者CLAUDE.md的某一节已经像操作手册就可以把它拆出来。差别主要在加载方式上。CLAUDE.md通常会在会话开始时作为持久上下文加载Skill 平时只暴露名称和描述真正命中时才加载完整内容。长参考材料、检查清单、脚本说明不用一开始就挤进上下文。这篇文章主要讲 Claude Code Skills 的技术实现和运行方式。我会参考社区源码分析材料看实现细节但当前用法以官方文档和 changelog 为准。如果你想先系统了解 Agent Skills 和 Prompt、MCP、Function Calling 的区别可以看我之前写的 Agent Skills 是什么和 Prompt、MCP 到底差在哪[1]。如果更关心有哪些现成 Skill 值得装可以直接看 AI 编程必备 Skills 推荐TDD、代码审查、网页自动化与 MCP 实战[2]。Skills 解决了什么问题先看CLAUDE.md和 Skill 的分工。CLAUDE.md适合放每轮都要用到的项目事实和长期规则比如代码风格、目录约定、常用命令、架构说明。Skill 适合放有明确触发场景的流程。它们需要被复用但不需要每次都跟着会话启动。最典型的是这些一套代码审查 checklist一套排查线上问题的步骤一个生成 PR 总结的流程一个只在改 UI 时才需要的设计规范一个只在写测试时才用到的 TDD 工作流。它们的共同点是步骤固定、篇幅不短但只在特定任务里出现。如果全部写进CLAUDE.md启动时就会变成额外的上下文成本越堆越重。你可以把 Skill 理解成一份按需打开的操作手册平时只让 Claude 知道有这项能力真用到的时候再把完整说明拿出来。Skill 和 Prompt、MCP、Function Calling 对比CLAUDE.md则反过来。官方建议把它留给每轮都要知道的内容比如构建命令、项目约定、目录结构以及必须一直遵守的规则。如果一段内容已经是多步骤流程或者只影响代码库里的某个局部就更适合移到 Skill 或 path-scoped rule。真到项目里拆的时候我一般不会先纠结名字而是先看这段内容到底卡在哪。如果卡在“规则每轮都要生效”那更像CLAUDE.md的问题。如果卡在“一段流程反复复制”那更像 Skill 的问题。如果卡在“任务太长完整过程会挤占主会话上下文”才考虑 Subagent。如果卡在“团队里每个人都要装一套”再考虑 Plugin。我用了一张表格总结了一下上面提到的概念机制主要解决的问题CLAUDE.md常驻项目规则和长期约定Skill只有特定任务才会用到的流程和清单Subagent把长任务或支线任务委派给另一个 AgentPlugin分发 Skills、Agents、Hooks、MCP 等扩展能力Claude Code 里的 Skill 可以理解成“prompt-based command”。自定义命令这块也已经并到 Skills 体系里了。现在.claude/commands/deploy.md和.claude/skills/deploy/SKILL.md都能创建/deploy旧的.claude/commands/不用马上迁移仍然兼容。Subagent 解决的是“谁来做”Skill 解决的是“怎么做”。Plugin 负责分发。一个 Plugin 可以带 Skills、Agents、Hooks 和 MCP Servers。企业或团队如果要统一发放能力Plugin 会比单独复制 Skill 文件更适合。如果项目里同时有CLAUDE.md、AGENTS.md、局部规则、SPEC 和 Skills也可以按这个思路拆常驻规则放在规则文件里可复用流程交给 Skill本次任务的验收标准放到 SPEC。CLAUDE.md 与其他规则文件怎么分工适合变成 Skill 的内容通常有几个特点经常复用有明确触发场景步骤比较固定内容比较长不适合常驻上下文最好还能配 supporting files 或脚本例如scripts/、references/、templates/。代码审查、TDD、PR 总结、数据库变更检查、UI 验收、日志排查都属于这类任务。不适合做成 Skill 的是项目里永远要遵守的硬规则。比如“所有 Java 代码使用 Google Java Style”这种更适合放CLAUDE.md或项目规则里。关于CLAUDE.md的详细介绍和最佳实践可以参考我写的这篇 CLAUDE.md 最佳实践该写什么、不该写什么、项目变大后怎么拆[3]。SKILL.md怎么写一个文件系统 Skill 通常是这样的目录结构.claude/skills/ pr-summary/ SKILL.md scripts/ collect-pr-info.sh references/ review-checklist.mdSKILL.md由两部分组成YAML frontmatter描述名字、触发条件、工具权限、模型、执行上下文等元数据。Markdown body真正发给 Claude 的操作说明。一个最小例子---name: pr-summarydescription: Summarize a pull request and list key risksallowed-tools: Bash(gh *)---Read the pull request diff and comments, then summarize:1. Main changes2. Risky files3. Missing tests4. Suggested follow-up当你执行/pr-summaryClaude Code 会把这个 Skill 渲染成 prompt再交给模型。源码里的parseSkillFrontmatterFields()支持的字段比较多常见字段可以先看下面这些字段作用name展示名目录名通常决定命令名description给模型判断何时使用when_to_use更细的触发说明allowed-tools预批准该 Skill 可用的工具model指定模型别名effort指定推理/努力等级user-invocable是否允许用户通过/skill-name直接调用disable-model-invocation禁止模型自动调用只允许用户手动调用paths条件触发路径context支持fork让 Skill 在子代理上下文中运行agent绑定指定 Agentshell指定动态上下文命令使用 bash 或 powershell这里别一上来就把字段全堆上。大多数 Skill 只需要description、allowed-tools和正文说明。字段越多维护成本越高。这里有几个字段容易混字段更适合解决什么问题allowed-tools收窄当前 Skill 可以直接使用的工具范围context: fork让长流程、调研类、审查类任务在 fork 上下文里跑agent指定由哪个 Agent 执行这个 Skill例如context: forkagent: Exploreallowed-tools: Bash(gh *)这类配置适合 PR 总结、模块审查、文档汇总这类任务。主会话不一定要背完整过程只拿结果就够。Skills 还支持参数替换。最简单的是$ARGUMENTS---name: fix-issuedescription: Fix a GitHub issuedisable-model-invocation: true---Fix GitHub issue \$ARGUMENTS following our coding standards.执行/fix-issue 123Claude 收到的内容里$ARGUMENTS会被替换成123。如果要按位置取参数可以用$ARGUMENTS[0]也可以用短写$0Migrate the $0 component from $1 to \$2.执行/migrate-component SearchBar React Vue$0、$1、$2会分别替换成SearchBar、React、Vue。Claude Code 怎么发现 SkillsClaude Code 会从多个来源加载 Skills。常见位置包括~/.claude/skills/.claude/skills/用户级 Skills 放在~/.claude/skills/所有项目都能用。项目级 Skills 放在项目的.claude/skills/适合和团队共享。项目里的 .claude/skills 目录示例从源码看Skills 目录采用的是skill-name/SKILL.md也就是说/skills/目录下单独一个.md文件不是标准 Skill 格式目录里要有SKILL.md。Claude Code 的 Skill 来源大致可以分几类类型来源说明用户级 Skills~/.claude/skills/个人长期复用项目级 Skills.claude/skills/项目或团队共享Managed Skills管理策略目录组织统一下发Bundled SkillsClaude Code 内置例如/code-review、/debug、/loop等Plugin Skills插件提供跟随 plugin 安装和启用MCP SkillsMCP Server 映射能力来自 MCP ServerClaude Code 包含一些 bundled skills比如/code-review、/batch、/debug、/loop和/claude-api。它们和普通内置命令不一样属于 prompt-based skill。Claude Code 官方文档中的 Bundled skills 说明嵌套.claude/skills目录也要留意。v2.1.178 后嵌套.claude/skills目录在处理对应文件时也会加载。发生名称冲突时嵌套 Skill 会以dir:name的形式出现避免覆盖外层同名 Skill。这和项目规则的思路接近越靠近当前工作目录的配置越能表达局部上下文。不过不建议滥用嵌套 Skills。只有当子目录确实有独立工作流时才拆比如frontend/.claude/skills/ui-review/SKILL.mdbackend/.claude/skills/api-contract-check/SKILL.mddocs/.claude/skills/article-review/SKILL.md如果只是为了分类普通目录和文件名就够了。旧版.claude/commands/仍然兼容。源码里也能看到 legacy commands loader如果旧命令目录里存在SKILL.md会按 Skill 方式处理否则继续按 Markdown command 加载。官方文档里已经写明custom commands 已经合并进 Skills但已有.claude/commands/文件会继续工作。新写能力时建议直接用.claude/skills/name/SKILL.md。Skill 被调用后发生什么Skill 平时不会把完整正文塞进上下文。Claude Code 主要通过 Skill 的名称、描述、when_to_use等 frontmatter 信息让模型知道有哪些能力可用。源码里还有一个estimateSkillFrontmatterTokens()只估算 name、description、whenToUse 的 token因为完整内容只在调用时加载。当用户执行/skill-name或者模型判断某个 Skill 适合当前任务时Claude Code 才会调用getPromptForCommand()把 Skill body 渲染出来。这也是 Skills 比长CLAUDE.md更省上下文的主要原因。Agent 执行链路Skill 被调用后Claude Code 会先拿到 Markdown body然后依次做几件事展开参数比如$ARGUMENTS、$0。替换${CLAUDE_SKILL_DIR}。替换${CLAUDE_SESSION_ID}。如果不是 MCP 来源再执行内嵌 shell 命令。返回最终 prompt 给模型。createSkillCommand()里对应的实现就是getPromptForCommand()。它会等到真正调用时才处理不会在启动阶段把所有 Skill 都渲染好。Skill 可以带 supporting files比如脚本、参考文档、模板。目录结构可以是my-skill/ SKILL.md scripts/ references/ templates/如果正文里需要引用脚本路径可以用${CLAUDE_SKILL_DIR}Run this helper:!${CLAUDE_SKILL_DIR}/scripts/collect-context.sh这样 Skill 移动目录后也不容易坏。不过支持文件不应该全量塞进正文。更好的写法是在SKILL.md里告诉 Claude 什么时候读取哪个文件。用得到再读用不到就别进上下文。这就是渐进式披露先让模型知道“有这个能力”命中后再读正文正文里只放流程骨架真正长的材料继续放到 supporting files。渐进式披露三层模型所以SKILL.md不适合写成超长 README。正文里优先写什么时候用、按什么顺序做、哪些情况别做、失败怎么兜底长清单、模板和脚本说明放到references/、templates/、scripts/里。SKILL.md 正文最好控制在 500 行以内CLAUDE.md和 Skill 的区别也可以回到加载策略上理解内容更适合放哪里项目编码规范CLAUDE.md目录结构说明CLAUDE.md代码审查流程SkillPR 总结流程SkillUI 验收 checklistSkill线上故障排查脚本Skill supporting files不要把 Skill 当成另一个更长的CLAUDE.md。Skill 的价值在于按需加载而不是换个目录继续堆规则。动态上下文和安全限制Skills 支持动态上下文注入语法是当前 Git 状态!git status --short也支持代码块形式!git log --oneline -5这些命令会在 Skill 内容发送给 Claude 之前执行。命令输出会替换原来的占位符模型看到的是最终结果不是命令本身。官方文档里也强调这是 preprocessing。Claude 只看到渲染后的 prompt。它和 Claude 调用 Bash 的区别很大。Claude 调用 Bash是模型在 agent loop 里决定使用工具。它会产生一次工具调用工具结果进入对话历史。Skill 里的动态命令是 prompt 预处理。命令先执行输出被塞进 Skill prompt。模型不会看到“我要执行这条命令”的过程。适合放在动态上下文里的内容通常是稳定、只读、低风险的上下文采集比如git status --shortgit diff --name-onlygh pr view --comments项目自带的只读脚本不要把会修改文件、提交代码、删除资源的命令写进动态上下文。动态上下文应该负责“收集材料”不负责“执行改动”。MCP 来源的 Skill 更特殊。源码里的判断条件是loadedFrom ! mcp时才执行内嵌 shell。MCP Skill 来自远程 MCP Server不一定可信。如果允许远程服务器返回一个带动态命令的 Skill再在本机执行就会变成远程代码执行风险。所以 MCP 来源的 Skill 会跳过内嵌 shell。文件系统、本地项目、受信任来源的 Skill 才能走这条预处理链路。同时即使是本地 Skill命令执行前也会走同一套工具权限检查。allowed-tools可以给当前 Skill 放行一部分命令但不是无条件执行。第三方 Skill 也要按这个思路检查。安装前至少看一遍SKILL.md、scripts/、references/确认里面没有危险命令、异常脚本或过宽权限。安装 Skill等于把一套流程交给 Agent 执行来源不清楚时别急着让它进项目。企业环境里官方 settings 文档有一个和治理相关的配置strictPluginOnlyCustomization。它可以限制 skills、agents、hooks、MCP servers 的来源。比如设置{ strictPluginOnlyCustomization: [skills, hooks]}被锁定后用户级和项目级来源会被跳过只加载 plugin 提供的、managed settings 提供的或者内置的能力。这类配置适合团队或企业环境。个人项目一般用不上但如果公司要统一管理 AI 编程工具的扩展来源就不能只靠口头约定。Skills 怎么和 Agent 配合Skill 可以跑在 Subagent 里。官方文档里有“Run skills in a subagent”相关说明Skill frontmatter 也支持context: fork和agent。例如一个 PR 总结 Skill可以让 Explore agent 在 fork 上下文里跑context: forkagent: Exploreallowed-tools: Bash(gh *)这样主会话不用自己背完整 PR diff、评论和文件列表只拿总结结果。context: fork适合三类场景Skill 过程很长Skill 需要读很多文件或外部信息主会话只关心结果不关心完整过程。比如生成 PR 风险摘要、对一个模块做只读审查、汇总文档和 issue、生成迁移计划都可以考虑 fork。不适合放到 fork 里的是那些必须和主会话持续互动的任务。比如你正在手动调整某个核心设计Skill 每一步都要你确认那就不要 fork 出去。Agent Teams 也会带来额外上下文开销。官方成本文档提醒过teammates 会自动加载CLAUDE.md、MCP servers 和 Skills。也就是说Agent Teams 不是只多了几个 prompt每个 teammate 都有自己的启动开销。这并不代表不要用 Skills而是要控制 Skill 描述和触发范围description写清楚不要让模型误触发长内容放 supporting files不要全塞SKILL.md用disable-model-invocation限制只允许手动调用的 Skill大型团队项目用strictPluginOnlyCustomization控制来源。Skill 的设计目标是按需加载。如果描述太泛、触发太频繁它就会从“节省上下文”变成“额外开销”。实际项目里我一般按下面这个规则拆内容放哪里每轮都要遵守的规则CLAUDE.md特定路径下才生效的规则.claude/rules/或带paths的 Skill可复用操作流程Skill长参考材料Skill supporting files搜索、审查、验证支线Subagent多角色协作任务Agent Teams举个例子你要做一次后端接口重构。CLAUDE.md里放项目编码规范和测试命令api-contract-checkSkill 里放接口兼容性检查流程code-reviewSkill 里放审查 checklist搜索旧调用方交给 Subagent如果前端、后端、测试要并行推进再考虑 Agent Teams。这样拆的好处是规则、流程、执行者各自清楚。别把所有东西都塞进主会话也别为了显得高级到处开 Agent。总结我更愿意把 Skill 当成一种按需加载的操作手册。每轮都要遵守的继续放规则文件只有特定任务才会用到的流程拆成 Skill流程里很长的 checklist、模板和脚本说明再继续拆到 supporting files。判断标准也很简单如果你已经开始反复复制同一段提示词或者CLAUDE.md里某一节长到读起来像手册那它大概率该变成 Skill 了。反过来如果只是代码风格、测试命令、目录约定这类每轮都要遵守的硬规则就别为了用 Skill 而写 Skill。放在CLAUDE.md里反而更直接。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
