Skills 与延迟加载工具定义的 MCP，目前哪个更高效、稳定和可控？
编者按： 我们今天为大家带来的这篇文章，作者的核心观点是：相较于依赖复杂且高成本的动态 MCP 工具加载机制，以 Skills 为核心的能力摘要与自维护模式，在当前阶段反而更加高效、稳定且可控。文章系统梳理了延迟工具加载（deferred tool loading）的工程现实与限制，指出即便工具可以延后注入，对话级别的工具集合仍然是静态的，且发现机制高度依赖正则匹配，收益并不如预期。作者进一步深入分析了 MCP 在上下文占用、API 稳定性、缓存失效与推理轨迹丢失等方面带来的隐性成本，并结合 Sentry MCP、Playwright 等实践案例，说明为何将 MCP 转换为 Skills，反而能让 Agent 更好地发挥既有工具的能力。文章最后还探讨了 MCP 是否可能完全转化为 Skills 的可行性，并坦率指出当前协议与生态在稳定性与摘要机制上的不足。作者 | Armin Ronacher(作者为 Flask、Jinja2 等开源项目的创建者)编译 | 岳扬我正把所有的 MCP 都迁移到 Skills 上，包括之前还在使用的最后一个：Sentry MCP（译者注：Sentry 是流行的应用监控与错误追踪平台）。早前我就已经完全弃用 Playwright（译者注：由 Microsoft 开发的现代 Web 自动化测试和浏览器自动化框架），转向使用 Playwright Skill。过去一个月左右，关于使用“动态工具配置（dynamic tool loadouts）[1]”来推迟工具定义的加载的讨论一直不少。Anthropic 也在探索通过代码来串联 MCP 调用的思路，这一点我也尝试过[2]。我想分享一下自己在这方面的最新心得，以及为什么 Anthropic 提出的“延迟工具加载方案（deferred tool loading）”并未改变我对 MCP 的看法。或许这些内容对他人会有所帮助。01 什么是工具（Tool）？当 Agent 通过强化学习或其他方式接触到工具定义时，它会被鼓励在遇到适合使用该工具的场景时，通过特殊的 token 输出工具调用。实际上，工具定义只能出现在系统提示词（system prompt）中特定的工具定义 token 之间。从历史经验来看，这意味着我们无法在对话状态的中途动态发出新的工具定义。因此，唯一的现实选择是在对话开始时就将工具加载好。在智能体应用场景中，我们当然可以随时压缩对话状态，或更改系统消息中的工具定义。但这样做的后果是，我们会丢失推理轨迹（reasoning traces）以及缓存（cache）。以 Anthropic 为例，这将大幅增加对话成本：基本上就是从头开始，相比于缓存读取，需要支付完整的 token 费用，外加缓存写入成本。Anthropic 最近的一项创新是“延迟工具加载”（deferred tool loading）。我们仍然需要提前在系统提示词（system message）中声明工具，但这些工具不会在系统提示词发出时就注入到对话中，而是会稍后才出现。不过据我所知，这些工具定义在整个对话过程中仍必须是静态的 —— 也就是说，哪些工具可能存在，是在对话开始时就确定好的。 Anthropic 发现这些工具的方式，纯粹是通过正则表达式（regex）搜索实现的。02 与 Skills 的对比尽管带延迟加载的 MCP 感觉上应该表现更优，实际上却需要在 LLM API 端做不少工程化工作。而 Skills 系统完全不需要这些，至少从我的经验来看，其表现依然更胜一筹。Skills 实质上只是对现有能力及其说明文件位置的简短摘要。这些信息会被主动加载到上下文中。 因此，智能体能在系统上下文里（或上下文的其他位置）知晓自己具备哪些能力，并获知如何使用这些能力的“手册链接”。关键在于，Skills 并不会真正把工具定义加载到上下文中。 可用工具保持不变：bash 以及智能体已有的其他工具。Skills 所能提供的，只是如何更高效使用这些工具的技巧和方法。由于 Skills 主要教的是如何使用其他命令行工具和类似实用程序，因此组合与协调这些工具的基本方式其实并未改变。让 Claude 系列模型成为优秀工具调用者的强化学习机制，恰好能帮助处理这些新发现的工具。03 MCP 能否转换为 Skills？这自然引出了一个问题：既然 Skills 效果这么好，我能不能把 MCP 完全移出上下文，转而像 Anthropic 提议的那样，通过 CLI 来调用它？答案是：可以，但效果并不好。Peter Steinberger 的 mcporter[3] 就是其中一种方案。简单来说，它会读取 .mcp.json 文件，并将背后的 MCP 暴露为可调用的工具：npx mcporter call 'linear.create_comment(issueId: "ENG-123", body: "Looks good!")'确实，它看起来非常像一个 LLM 可以调用的命令行工具。但问题在于，LLM 根本不知道有哪些工具可用 —— 现在你得专门教它。于是你可能会想：那为什么不创建一些 Skills，来教 LLM 了解这些 MCP 呢？对我而言，这里的问题在于：MCP 服务器根本没有维持 API 稳定性的意愿。它们越来越倾向于将工具定义精简到极致，只为节省 token。 这种做法有其道理，但对 Skills 模式来说却适得其反。举个例子，Sentry MCP 服务器曾彻底将查询语法切换为自然语言。这对 Agent 来说是一次重大改进，但我之前关于如何使用它的建议反而成了障碍，而且我没能第一时间发现问题。这其实和 Anthropic 的“延迟工具加载方案”非常相似：上下文中完全没有任何关于该工具的信息，我们必须手动创建一份摘要。我们过去对 MCP 工具采用的预加载（eager loading）方式，如今陷入了一个尴尬的局面：描述既太长，不便预加载；又太短，无法真正教会 Agent 如何使用它们。 因此，至少从我的经验来看，你最终还是得为通过 mcporter 或类似方式暴露出来的 MCP 工具，手动维护这些 Skills 摘要。04 最省事的路线这让我得出了目前的结论：我倾向于选择最省事的方式，也就是让 Agent 自己以“Skills”的形式编写所需的工具。 这样做不仅耗时不多，最大的好处还在于工具基本处于我的掌控之中。每当它出问题或需要新增功能时，我就让 Agent 去调整它。Sentry MCP 就是个很好的例子 —— 我认为它可能是目前设计得最好的 MCP 之一，但我已经不再使用它了。一方面是因为一旦在上下文中立即加载它，就会直接消耗约 8k 个 token；另一方面，我也一直没能通过 mcporter 让它正常工作。现在我让 Claude 为我维护一个对应的 Skill。没错，这个 Skill 可能有不少 bug，也需要不断更新，但由于是 Agent 自己维护的，整体效果反而更好。当然，这一切很可能在未来发生变化。但就目前而言，手动维护的 Skills，以及让 Agent 自行编写工具，已成为我的首选方式。我推测，基于 MCP 的动态工具加载终将成为主流，但要实现这一点，可能还需要一系列协议层面的改进，以便引入类似 Skills 的摘要机制，以及为工具内置使用手册。 我也认为，MCP 如果能具备更强的协议稳定性，将大有裨益。目前 MCP 服务器随意更改工具描述的做法，与那些已经固化下来的调用方式（materialized calls）以及在 README 和技能文件中编写的外部工具说明很难兼容。END本期互动内容 🍻❓抛开现有方案，你理想中的AI工具调用范式应该长什么样？用一句话描述你最核心的需求。文中链接[1]https://www.anthropic.com/engineering/advanced-tool-use[2]https://lucumr.pocoo.org/2025/7/3/tools/[3]https://github.com/steipete/mcporter原文链接：https://lucumr.pocoo.org/2025/12/13/skills-vs-mcp/
[v0.1] 我把科研流程拆成了一堆 Skills，让 codex/cc 像打工人一样拉磨
github.com GitHub - WILLOSCAR/research-units-pipeline-skills: Research pipelines as semantic execution units:...Research pipelines as semantic execution units: each skill declares inputs/outputs, acceptance criteria, and guardrails. Evidence-first methodology prevents hollow writing through structured intermediate artifacts. 如果大家觉得有帮助，欢迎点个 star 支持一下。Motivation这个 project 的初衷，源于我读到的 Anthropic 的 skills 设计，对这种即插即用、可组合的范式产生了强烈兴趣，觉得在抽象层面非常优雅。由此引出了一个问题：能否像搭积木一样，通过编排 skills 来完成科研流程（好吧，我承认其实是懒癌犯了，想走捷径了，想把 codex 当成拉磨的驴 Agent 来用）？进一步来说，能否用 skills 的组合与调度，替代一部分原本依赖重型编码、耗时执行的复杂研究任务？在这一想法的驱动下，随着 skills 体系逐渐成形、效果开始显现，项目便沿着这个方向持续推进，逐步系统化地构建和打磨这套以 skills 为核心的 Pipeline。其核心理念是：将研究流程显式建模为可组合的语义单元（skills with contracts），使研究任务能够像软件工程一样实现可编排、可复用、可演化、可审计。System Designskills 层面一开始我先入为主地把 skills 理解成 “函数”，但后来发现它更接近于一个自包含的执行单元，skill 描述的不是 “怎么调用”，而是 “在什么条件下、以什么方式完成一件事，并如何判断它是否完成”，这里推荐看 anthropic 的官方 Github 或者 doc。What: 输入是什么，输出是什么（显式依赖）How: 怎么做，有哪些边界情况（notes + procedures）When done: 完成标准是什么（acceptance criteria）What NOT to do: 边界约束（guardrails，比如 NO PROSE）pipeline 层面在设计上对 skills 做了解耦 (不想重复造轮子了，另外改原子化组成的 Pipeline 只需增删改 skills)：不再为每一个研究任务编写一条固定流程，而是将研究过程拆解为一组原子化的 skills（如 retrieval、taxonomy、outline、evidence、writing、validation），再通过 UNITS.csv 显式描述它们的执行顺序与依赖关系。这样一来，不同类型的任务（survey、systematic review、tutorial）可以复用同一套 skills，仅通过不同的编排方式完成，流程本身不再与具体任务强绑定。整个流程被拆解成了 C0-C5 阶段，每一阶段有阶段性的产物（说多了都是泪，end2end 固然优雅，还是要保留中间产物便于回滚），会有隐式或者显示的规则 / 代码确保产物没有特别大的遗漏，在关键性节点引入确定性质量门（如 placeholder leakage、citation health、evidence binding 检查）用来兜底。同时这套 Pipeline 也可以高度个性化，个人比较倾向于设计 Pipeline 的时候让模型自己头脑风暴考虑怎么组合 skills，然后作为参考设计完整的 Pipeline，当然存在 garbage in garbage out 的风险，需要自己校正。具体实现配合 claude code 和 codex 开启了 self-loop 的开发（工具改变生活），抽象出一堆 skills，约束 Pipeline 渐进式执行Usage打开 terminal 开始指挥手下，启动 codex --sandbox workspace-write --ask-for-approval never （记得要把 sandbox 里面的 network 打开）[sandbox_workspace_write]network_access = true模拟 example你：给我写一个 agent 的 latex-survey ↓ [C0-C1] 检索 800+ 篇论文 → 去重到 150+ 核心集 arxiv 会补全 meta 信息 ↓ [C2] 构建 taxonomy + outline + mapping（NO PROSE）→ 停在 C2 等审批 你：C2 同意，继续 ↓ [C3-C4] 构建证据底座（paper notes + evidence packs + citations）（NO PROSE） ↓ [C5] 基于 evidence 开始写作 → 质量门检查 【如果 PASS】→ output/DRAFT.md + latex/main.pdf ✓ 【如果 FAIL】→ output/QUALITY_GATE.md 告诉你改哪个中间产物 你（如果 FAIL）：按报告修复对应文件（如 outline/evidence_drafts.jsonl），然后说"继续" → 从失败 unit 恢复执行，不需要全部重跑 示例产物（v0.1，包含完整中间产物）全在 example 里面该版本由 codex 中的 gpt-5.2-xhigh 运行约 2 小时 生成，过程中仅进行过 一次 human-in-the-loop（C2 阶段） 介入。路径：example/e2e-agent-survey-latex-verify-****时间戳/（pipeline：pipelines/arxiv-survey-latex.pipeline.md）。配置摘要：draft_profile: lite / evidence_mode: abstract / core_size: 220（详见 queries.md）。Limitation写作部分 self-loop 了 N 次，迭代思路是选取一些写的比较好的 survey，让 cc 或者 codex 学习下写作风格和结构，然后了解 workspace 中的实际产物分析和优秀 survey 的差距，把暴露出的问题和改进意见写到某个 md 里面，再根据改进意见头脑风暴，反向调整重构 skills 和 Pipeline写作还是门艺术活，高度依赖审美和经验，现在这套流程离从 0 到 1 写出顶会级别的描述还是有不少距离的，另一方面，写作技巧可能很难被精确的量化，目前更多是通过将其转化为 “受约束的优化问题”，给出正反例，给出一些引导性句子，杜绝一些模型的写作怪癖 / 特殊表达，这样的方式虽然提升了下限，也不可避免会落入俗套，模板化。Future work当然最终目标还是希望同时提高上下限，fighting，也希望能够加入一些可解释性。如果大家有好的建议，欢迎多多提出；趁着现在热情还没降下去，这个 repo 会持续更新，也欢迎点个 star 支持一下。 github.com GitHub - WILLOSCAR/research-units-pipeline-skills: Research pipelines as semantic execution units:...Research pipelines as semantic execution units: each skill declares inputs/outputs, acceptance criteria, and guardrails. Evidence-first methodology prevents hollow writing through structured intermediate artifacts. ReferenceGitHub - anthropics/skills: Public repository for Agent Skillshelloagents/Codex/Skills at main · hellowind777/helloagents · GitHubGitHub - renocrypt/latex-arxiv-SKILL: A .codex SKILL for issue-driven ML/AI arXiv review papers: scaffold LaTeX + verify BibTeX citations end-to-end.https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overviewTodo加入多 cli 协作，multi-agent design继续完善写作技巧📌 转载信息来源： https://linux.do/t/topic/1484525转载时间： 2026/1/19 18:06:18
自动同步 claude skills 到 codex、gemini、opencode
antigravity 也支持 skills 了，skills 逐渐成为大家的共识。随之而带的带来一个问题，每个工具的 skills 都是在自己的文件结构中去创建和 copy，而且 skills 也是可能需要优化和更新的，导致管理起来挺烦，所以想到基于主工具 claude code 来自动同步 skills 到其它各 ai 工具的想法。opencode 自身就会加载 claude code 的 skills，所以没必要同步Step 1准备好 fswatch，监听 ~/.claude/skills 的变化brew install fswatch Step 2准备一个 sync_skills.sh:#!/bin/bash fswatch -o ~/.claude/skills | while read f; do rsync -a --delete --exclude-from=～/.codex/skills/.exclude-list ~/.claude/skills/ ~/.codex/skills/ rsync -a --delete --exclude-from=～/.gemini/skills/.exclude-list ~/.claude/skills/ ~/.gemini/skills/ rsync -a --delete --exclude-from=～/.gemini/antigravity/skills/.exclude-list ~/.claude/skills/ ~/.gemini/antigravity/skills/ done 其中 --exclude-from 是为了在某些工具中想要排除一些 skills 的同步，比如有一些 skills 只能用于某个工具里，就可以创建一个.exclude-list 文件，把要排除的 skills 文件夹名丢进去，一行一个。Step 3如果想每次重启后自动运行，还可以创建一个 ~/Library/LaunchAgents/com.user.sync_claude_codex_skills.plist：里面的 xxx 换成自己的<?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"> <dict> <key>Label</key> <string>com.user.sync_claude_codex_skills</string> <key>ProgramArguments</key> <array> <string>/bin/bash</string> <string>/Users/xxx/sync_skills.sh</string> </array> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> <key>StandardOutPath</key> <string>/tmp/sync_skills.stdout</string> <key>StandardErrorPath</key> <string>/tmp/sync_skills.stderr</string> <key>EnvironmentVariables</key> <dict> <key>PATH</key> <string>/opt/homebrew/bin:/usr/local/bin:/bin:/usr/bin</string> </dict> </dict> </plist> 然后终端执行：launchctl load ~/Library/LaunchAgents/com.user.sync_claude_codex_skills.plist 📌 转载信息来源： https://linux.do/t/topic/1468794原作者： Terran_Wu转载时间： 2026/1/16 18:48:31
解决 Codex 在 Windows10 pwsh 下读写乱码问题（Skills 版）
之前一直没有体验 codex，最近空下来了，我来一个一个 cli 工具拷打一下，接入我真实的开发任务。一看这个 Codex 读写文件的原理我 TM 头的大了。他使用指令读取文件的时候，居然不携带我的 profile.ps1。网上那篇点击率贼高的文章没个用。我系统是Microsoft Windows 10 专业工作站版版本 10.0.19045 内部版本 19045powershell 版本：PS C:\Users\Administrator> $PSVersionTable Name Value ---- ----- PSVersion 5.1.19041.5965 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.19041.5965 CLRVersion 4.0. WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 原理也没什么好说的，就是 codex 调用工具的时候告诉他要用 utf8 读。好像直接使用编辑器贴 Skill 有问题我就留下个 git 链接吧。也不用点 Star，我很社恐…Zxyy-mo/Get-It-Done: 没什么大道理，全是自用的 LLM 实操小技巧。记录平时用 OpenAI 和 Claude 时比较顺手的提示词、Skills、插件配置，以及一些摸索出来的 Vibe Coding 瞎搞经验📌 转载信息来源： https://linux.do/t/topic/1463260原作者： wangziwen转载时间： 2026/1/15 18:18:01
github.com GitHub - comeonzhj/easy-skills: Skills 安装助手 - 一键安装 Claude Code，管理技能包Skills 安装助手 - 一键安装 Claude Code，管理技能包 缘起是受𝕏上某个大佬的启发（忘记名字了，只能匿名感谢）：要开发给小白用的工具。所以 Vibe-Coding 了这个帮用户快速安装 Claude Code 并管理技能包（Skills）的桌面应用程序。工具实现没啥难度，给 L 站大佬们一些启发。工具可以：一键安装 Claude Code：自动检测环境、安装依赖、配置 npm，适配国内网络环境模型配置：支持配置 API Key、自定义模型端点、选择模型提供商技能管理： 从文件夹或 ZIP 包导入技能选择安装到项目级或全局技能目录查看安装历史记录管理全局技能📌 转载信息来源： https://linux.do/t/topic/1442800原作者： comeonzhj转载时间： 2026/1/14 10:53:55
【个人工作流开源】Claude-Code-Multi-Agent 涵盖 300+ 超智能开发调优专家，完整的 Hooks 调优系统
Claude Code Multi-Agent让 Claude Code 拥有项目感知能力的智能开发框架更多详细的介绍内容与文档，请详见：Claude-Code-Multi-Agent/README.md at master · Prorise-cool/Claude-Code-Multi-Agent如果有功能上的疑问，请在 github 上提交 PR，此项目已内置 MCP因为是个人使用的工作流，开源出来如果有无法复现的情况请反馈给我及时优化，欢迎提交 PR，分享更多实用的 SKILLS 技能 这是什么？Claude Code Multi-Agent 是一个为 Claude Code 设计的智能开发框架，通过 Hooks 系统 在会话生命周期中自动执行智能操作，让 Claude Code 从 “通用聊天助手” 升级为 “懂你项目的专业开发伙伴”。核心定位这不是一个插件生态，而是一个 Claude Code 的专属工作空间你需要将仓库克隆后，将你的项目（或初始化项目）放在此文件夹中，即可享受智能 Hooks 定义以及 300+ Skills 方案。 解决了什么痛点？痛点 1：Claude Code 缺乏项目感知能力问题：Claude Code 默认不知道你的项目是什么类型、使用什么框架、有什么依赖。每次都需要你手动描述项目背景。解决：通过 Ollama 智能引擎 自动检测项目类型（Python/Node.js/Java 等）、识别框架（Django/FastAPI/React 等），并在会话启动时自动注入项目上下文。痛点 2：需要手动配置各种工具和提示词问题：每次使用 Claude Code 都需要：手动告诉它项目结构手动配置 Git 工作流手动编写提示词模板手动管理文档更新解决：零配置启动 - 克隆即用，所有配置通过 Hooks 自动完成。提示词模板化存储在 prompts.json，支持团队协作和版本控制。痛点 3：缺乏智能的意图分析和技能推荐问题：Claude Code 不知道什么时候该调用什么工具，也不知道有哪些可用的专家技能。解决：智能意图分析 - 自动判断任务复杂度，推荐合适的 MCP 工具（Sequential Thinking、Task Manager 等）和 Skills（后端专家、测试专家等）。痛点 4：文档维护繁琐且容易遗忘问题：代码改了，文档忘了更新。项目知识散落在聊天记录中，无法沉淀。解决：自动文档维护 - 每次代码修改后，强制提示更新 DEVELOPMENT.md、KNOWLEDGE.md、CHANGELOG.md，确保文档与代码同步。 核心优势所有判断逻辑通过本地部署 Ollama 完成，无需编写复杂的规则引擎。提示词模板化存储在 prompts.json，支持持续调优和版本控制。 300+ Skills 专家智能体会话启动时自动扫描并加载所有 Skills，包括：后端专家 (/backend-specialist) - Django、FastAPI、Spring Boot 等前端专家 (/frontend-specialist) - React、Vue、Next.js 等测试专家 (/testing-specialist) - 单元测试、集成测试、E2E 测试安全专家 (/security-specialist) - OWASP Top 10、安全审计架构专家 (/architecture-specialist) - 系统设计、微服务架构DevOps 专家 (/devops-specialist) - CI/CD、容器化、云部署… 还有更多 自动文档维护系统强制维护三个核心文档：DEVELOPMENT.md - 开发工作文档（任务状态、进度跟踪）KNOWLEDGE.md - 项目知识库（技术决策、代码模式）CHANGELOG.md - 变更日志（版本记录、功能变更）文档在会话启动时自动注入上下文，替代 Memory MCP，避免上下文爆炸。 Git 工作流智能集成自动检测 Git 仓库配置，提示分支策略（github-flow /git-flow），确保团队协作规范。 零配置启动基于 uv 的依赖管理，无需手动安装 Python 包。克隆项目 → 配置环境变量 → 启动 Claude Code，即可使用。 使用示例示例 1：自动项目检测场景：你打开了一个新的 Python 项目，想了解项目结构。操作：直接打开 Claude Code，系统会自动：检测项目类型（Python + FastAPI）识别框架和依赖加载相关 Skills（后端专家、测试专家等）初始化项目文档结果：Claude Code 立即了解你的项目，无需手动介绍。示例 2：调用专家 Skills场景：需要设计 RESTful API，但不确定最佳实践。操作：在 Claude Code 中输入：/backend-specialist 设计用户认证的 RESTful API 结果：Claude Code 以 “后端专家” 身份回答，参考 FastAPI/Django 最佳实践，提供：RESTful 资源设计HTTP 方法选择状态码定义请求 / 响应格式示例 3：智能意图分析场景：输入一个复杂任务：“实现用户登录功能”操作：系统自动分析意图，推荐：推荐工具：Sequential Thinking（复杂任务分解）推荐 Skills：/backend-specialist、/security-specialist执行计划：自动生成任务拆解建议结果：无需手动思考 “该用什么工具”，系统智能推荐。示例 4：自动文档维护场景：修改了 user_service.py，添加了新功能。操作：系统自动检测代码变更，强制提示更新：DEVELOPMENT.md - 记录开发进度KNOWLEDGE.md - 记录技术决策CHANGELOG.md - 记录变更历史结果：文档始终与代码同步，项目知识可沉淀。示例 5：Commands 工作流Commands 是预定义的工作流，通过 /command-name 触发：# 创建功能规格（从需求到实施计划） /kiro/spec 用户认证功能 # 执行完整的代理工作流 /agent-workflow 实现博客系统 # Git 提交（自动生成 Commit Message） /gh/commit Command 示例：/kiro/spec这个 Command 会引导你完成：需求收集：生成 EARS 格式的需求文档设计文档：创建架构设计和数据模型任务列表：拆解为可执行的开发任务所有文档自动保存到 .kiro/specs/{feature_name}/ 目录。 系统架构Hooks 工作原理本项目通过 Python Hooks 系统管理 Claude Code 的会话生命周期。每个 Hook 在特定事件触发时执行，通过 Ollama 进行智能决策。核心设计理念：文档驱动：强制维护三个核心文档（DEVELOPMENT.md、KNOWLEDGE.md、CHANGELOG.md），会话启动时自动读取并注入上下文配置化提示词：所有提示词模板存储在 .claude/hooks/prompts.json，用户可自由调整和优化去 Memory 中间层：不再依赖 Memory MCP，直接通过文档维护项目知识，避免上下文爆炸导致的指令失效Hook 触发时机会话启动SessionStart用户输入UserPromptSubmit工具调用PreToolUsePostToolUseNotificationPreCompactStop/SubagentStopHook 执行流程每个 Hook 通过 exit_code 控制后续操作：02Hook 触发执行脚本exit_code继续操作阻止操作返回 JSON更新系统消息返回值格式：{ "exit_code": 0, "message": "操作成功", "data": { "skills": ["backend-specialist", "testing-specialist"], "project_type": "Python", "framework": "FastAPI" } } exit_code=0：允许操作继续exit_code=2：阻止操作（如检测到危险命令）Hook 类型说明 Hook触发时机核心功能Ollama 作用 SessionStart会话启动项目初始化检测项目类型、推荐 SkillsUserPromptSubmit用户提交输入意图分析判断任务复杂度、优化提示词PreToolUse工具调用前权限检查评估操作风险PostToolUse工具调用后文档更新生成文档更新建议Stop会话结束清理资源-SubagentStop子代理停止子任务处理-PreCompact上下文压缩前信息保留识别重要上下文Notification系统通知消息处理- 核心 Hook 详解：1. SessionStart - 会话启动处理器这是最重要的 Hook，负责项目初始化：# .claude/hooks/handlers/session_start.py 的核心逻辑 # 1. 调用 Ollama 检测项目类型 project_info = ollama_client.detect_project_type() # 返回：{"type": "Python", "framework": "FastAPI", "version": "3.11"} # 2. 扫描 skills/ 目录 skills = scan_skills_directory() # 返回：["backend-specialist", "testing-specialist", ...] # 3. 初始化文档系统 document_manager.init_documents() # 创建：DEVELOPMENT.md, KNOWLEDGE.md, CHANGELOG.md # 4. 【核心改进】强制读取三个文档并注入上下文 development_content = read_file("project_document/DEVELOPMENT.md") knowledge_content = read_file("project_document/KNOWLEDGE.md") changelog_content = read_file("project_document/CHANGELOG.md") # 将这些内容注入到系统上下文中，替代 Memory MCP # 5. 检查 Git 配置 git_status = check_git_config() # 检查：.gitignore, 分支策略 2. UserPromptSubmit - 意图识别处理器分析用户输入，提供智能建议：# 用户输入："帮我实现用户登录功能" # Ollama 分析结果： { "intent": "feature_implementation", "complexity": "medium", "recommended_tools": ["Write", "Edit", "Bash"], "recommended_skills": ["backend-specialist", "security-specialist"], "suggested_plan": [ "1. 设计数据库表结构", "2. 实现认证逻辑", "3. 编写单元测试", "4. 添加安全防护" ] } 3. PostToolUse - 工具使用后处理器在每次代码修改后，强制 更新三个文档：# 检测到修改了 user_service.py # 【强制】必须更新以下文档： # 1. DEVELOPMENT.md - 记录开发进度和任务状态 # 2. KNOWLEDGE.md - 记录技术决策和代码模式 # 3. CHANGELOG.md - 记录变更历史 # 文档更新提示通过 prompts.json 配置，用户可自定义格式和要求 提示词配置化：所有提示词模板存储在 .claude/hooks/prompts.json，支持：自定义提示词内容和格式使用 {变量} 占位符动态替换按 Hook 类型分组管理便于持续调优和版本控制Skills 触发机制Skills 是本项目的 “专家团队”，每个 Skill 代表一个专业领域的智能体。Skills 加载流程Ollama 文件系统 Claude Code 用户 Ollama 文件系统 Claude Code 用户/backend-specialist 设计 API 读取 skills/backend-specialist/SKILL.md 返回 Skill 定义解析 YAML Frontmatter 结合 Skill 能力优化提示词返回优化后的系统提示注入系统上下文以专家身份执行任务Skill 目录结构.claude/skills/ ├── backend-specialist/ │ ├── SKILL.md # Skill 定义（必需） │ └── references/ # 参考文档（可选） │ ├── cursor_rules_django.md │ ├── cursor_rules_fastapi.md │ └── restful_best_practices.md ├── testing-specialist/ │ ├── SKILL.md │ └── references/ │ ├── pytest_guide.md │ └── test_patterns.md └── security-specialist/ ├── SKILL.md └── references/ ├── owasp_top10.md └── secure_coding.md 为什么需要 Ollama？Ollama 是本项目的 “大脑”，负责：项目类型检测：自动识别你的项目是 Python/Node.js/Java 等意图分析：理解用户输入，判断是简单查询还是复杂任务提示词优化：将模糊需求转化为清晰的执行计划技能推荐：根据任务类型推荐合适的 Skills没有 Ollama，系统会降级到基础模式（仅支持手动触发 Skills）。为什么需要 uv？uv 是 Rust 编写的超快 Python 包管理器，本项目用它来：自动管理 Python 环境：无需手动创建虚拟环境秒级安装依赖：比 pip 快 10-100 倍零配置运行 Hooks：uv run 自动处理依赖隔离为什么不用 pip？ uv 会自动创建隔离环境，避免污染全局 Python 环境，且速度快 10 倍以上。📌 转载信息来源： https://linux.do/t/topic/1443939转载时间： 2026/1/14 10:44:42
相信各位佬友现在已经或多或少使用过 skills 并且创建了更好用更合适的协助式 skills，今天我以我个人这几天在简单使用中来小小的总结一下 skills 和 commands（希望各位大佬批评指正 ）Skills 的使用：1. skills 的基本要素：首先 skills 分为用户级与项目级，两者的存放位置如下，仅需要把你想要下载的 skills 放在下面的目录中，cc 在每次对话开始前就会自动识别并加载用户级与项目级的 skills，并且可以用 /{skill-name} 的方式调用或者根据你的上下文内容自动调用 skills：用户级：~/.claude/skills/ 用户级的 skills 全局生效，可以在任何目录中调用用户级 skills项目级：<项目根目录>/.claude/skills/ 项目级 skills 仅在当前项目生效，适合针对该项目做专业的工作skills 的一般目录结构如下，以官方的 skill-creator 中的 SKILL.md 中的内容为例skill-name/ ├── SKILL.md（必需） │ ├── YAML frontmatter 元数据（必需） │ │ ├── name:（必需） │ │ └── description:（必需） │ └── Markdown 指令（必需） └── 捆绑资源（可选） ├── scripts/ # 可执行代码（Python/Bash 等） ├── references/ # 需要时加载到上下文的文档 └── assets/ # 用于输出的文件（模板、图标、字体等） 在官方的 skill-creator 中的 SKILL.md 中介绍了每个 skill 所需要的内容YAML frontmatter: Claude 会通过上下文中的内容匹配 description 中的应用场景来触发 skill，或者通过 /skillname {描述}l 来触发，需要简短并全面的描述整个 skill 的功能和应用场景。--- name: <skill-name> description: <简要说明技能功能>。当用户请求"<触发短语1>"、"<触发短语2>"、"<触发短语3>"，或涉及<相关领域/任务>时，使用此技能。 --- references/：在加载 skill 时会一并加载到上下文中来作为补充思考的参考资料，通常是执行一个 skill 中多个模式时的参考资料补充，也可以是每个模式具体的流程。scripts/：skill 可以包含脚本，可以变成一个主动触发的小型 MCP 服务，一些重复性或者规定格式文件生成工作可以以脚本的形式写在 skill 中，比如你可以让它读取数据库指定表并按照模板自动生成全后端的 CRUD 代码。assets/：静态的文件，图像、logo 等等，这个应该是写一些前端代码生成时用到的东西，目前我还没用到过。 skill-creator 的完整描述 --- name: skill-creator description: 创建高效技能的指南。当用户想要创建新技能（或更新现有技能）以扩展 Claude 的能力时，应使用此技能，包括专业知识、工作流程或工具集成。 license: 完整条款见 LICENSE.txt --- # 技能创建器 本技能提供创建高效技能的指导。 ## 关于技能 技能是模块化、自包含的软件包，通过提供专业知识、工作流程和工具来扩展 Claude 的能力。可以将它们视为特定领域或任务的"入职指南"——它们将 Claude 从通用代理转变为配备程序性知识的专业代理，而这些知识是任何模型都无法完全具备的。 ### 技能提供的内容 1. 专业工作流程 - 特定领域的多步骤程序 2. 工具集成 - 处理特定文件格式或 API 的指令 3. 领域专业知识 - 公司特定知识、数据模式、业务逻辑 4. 捆绑资源 - 用于复杂和重复任务的脚本、参考资料和资产 ## 核心原则 ### 简洁至上 上下文窗口是公共资源。技能与 Claude 所需的其他所有内容共享上下文窗口：系统提示、对话历史、其他技能的元数据以及实际的用户请求。 **默认假设：Claude 已经非常智能。** 只添加 Claude 尚不具备的上下文。对每条信息提出质疑："Claude 真的需要这个解释吗？"以及"这段内容值得消耗这些 token 吗？" 优先使用简洁的示例，而非冗长的解释。 ### 设置适当的自由度 根据任务的脆弱性和可变性匹配具体程度： **高自由度（基于文本的指令）**：当多种方法都有效、决策取决于上下文或启发式方法指导方案时使用。 **中等自由度（伪代码或带参数的脚本）**：当存在首选模式、可接受一定变化或配置影响行为时使用。 **低自由度（特定脚本，少量参数）**：当操作脆弱且容易出错、一致性至关重要或必须遵循特定顺序时使用。 将 Claude 想象为探索一条路径：悬崖边的窄桥需要特定的护栏（低自由度），而开阔的田野允许多条路线（高自由度）。 ### 技能的结构 每个技能由一个必需的 SKILL.md 文件和可选的捆绑资源组成： ``` skill-name/ ├── SKILL.md（必需） │ ├── YAML frontmatter 元数据（必需） │ │ ├── name:（必需） │ │ └── description:（必需） │ └── Markdown 指令（必需） └── 捆绑资源（可选） ├── scripts/ - 可执行代码（Python/Bash 等） ├── references/ - 需要时加载到上下文的文档 └── assets/ - 用于输出的文件（模板、图标、字体等） ``` #### SKILL.md（必需） 每个 SKILL.md 包含： - **Frontmatter**（YAML）：包含 `name` 和 `description` 字段。这是 Claude 用来判断何时使用技能的唯一字段，因此清晰全面地描述技能是什么以及何时应该使用它非常重要。 - **Body**（Markdown）：使用技能的指令和指导。仅在技能触发后加载（如果触发的话）。 #### 捆绑资源（可选） ##### 脚本（`scripts/`） 用于需要确定性可靠性或反复重写的任务的可执行代码（Python/Bash 等）。 - **何时包含**：当相同的代码被反复重写或需要确定性可靠性时 - **示例**：用于 PDF 旋转任务的 `scripts/rotate_pdf.py` - **优点**：节省 token、确定性、可以在不加载到上下文的情况下执行 - **注意**：脚本可能仍需要被 Claude 读取以进行修补或环境特定调整 ##### 参考资料（`references/`） 需要时加载到上下文中以指导 Claude 流程和思考的文档和参考材料。 - **何时包含**：用于 Claude 在工作时应参考的文档 - **示例**：用于财务模式的 `references/finance.md`、用于公司保密协议模板的 `references/mnda.md`、用于公司政策的 `references/policies.md`、用于 API 规范的 `references/api_docs.md` - **用例**：数据库模式、API 文档、领域知识、公司政策、详细工作流程指南 - **优点**：保持 SKILL.md 精简，仅在 Claude 确定需要时加载 - **最佳实践**：如果文件较大（>10k 词），在 SKILL.md 中包含 grep 搜索模式 - **避免重复**：信息应该存在于 SKILL.md 或参考文件中，而不是两者都有。除非信息确实是技能的核心，否则优先将详细信息放在参考文件中——这样可以保持 SKILL.md 精简，同时使信息可发现而不占用上下文窗口。仅在 SKILL.md 中保留基本的程序性指令和工作流程指导；将详细的参考材料、模式和示例移至参考文件。 ##### 资产（`assets/`） 不打算加载到上下文中，而是用于 Claude 产出的输出中的文件。 - **何时包含**：当技能需要将在最终输出中使用的文件时 - **示例**：用于品牌资产的 `assets/logo.png`、用于 PowerPoint 模板的 `assets/slides.pptx`、用于 HTML/React 样板的 `assets/frontend-template/`、用于排版的 `assets/font.ttf` - **用例**：模板、图像、图标、样板代码、字体、被复制或修改的示例文档 - **优点**：将输出资源与文档分离，使 Claude 能够使用文件而无需将其加载到上下文中 #### 技能中不应包含的内容 技能应仅包含直接支持其功能的必要文件。不要创建无关的文档或辅助文件，包括： - README.md - INSTALLATION_GUIDE.md - QUICK_REFERENCE.md - CHANGELOG.md - 等等 技能应仅包含 AI 代理完成手头工作所需的信息。它不应包含关于创建过程的辅助上下文、设置和测试程序、面向用户的文档等。创建额外的文档文件只会增加混乱和困惑。 ### 渐进式披露设计原则 技能使用三级加载系统来高效管理上下文： 1. **元数据（name + description）** - 始终在上下文中（约 100 词） 2. **SKILL.md body** - 当技能触发时（<5k 词） 3. **捆绑资源** - 根据 Claude 需要（无限制，因为脚本可以在不读入上下文窗口的情况下执行） #### 渐进式披露模式 将 SKILL.md body 保持在必要内容且不超过 500 行，以最小化上下文膨胀。接近此限制时将内容拆分到单独的文件中。当将内容拆分到其他文件时，非常重要的是从 SKILL.md 引用它们并清楚描述何时读取它们，以确保技能的读者知道它们的存在以及何时使用它们。 **关键原则：** 当技能支持多种变体、框架或选项时，仅在 SKILL.md 中保留核心工作流程和选择指导。将特定变体的详细信息（模式、示例、配置）移至单独的参考文件。 **模式 1：带参考资料的高级指南** ```markdown # PDF 处理 ## 快速开始 使用 pdfplumber 提取文本： [代码示例] ## 高级功能 - **表单填写**：完整指南见 [FORMS.md](FORMS.md) - **API 参考**：所有方法见 [REFERENCE.md](REFERENCE.md) - **示例**：常见模式见 [EXAMPLES.md](EXAMPLES.md) ``` Claude 仅在需要时加载 FORMS.md、REFERENCE.md 或 EXAMPLES.md。 **模式 2：领域特定组织** 对于具有多个领域的技能，按领域组织内容以避免加载不相关的上下文： ``` bigquery-skill/ ├── SKILL.md（概述和导航） └── reference/ ├── finance.md（收入、计费指标） ├── sales.md（商机、管道） ├── product.md（API 使用、功能） └── marketing.md（营销活动、归因） ``` 当用户询问销售指标时，Claude 只读取 sales.md。 类似地，对于支持多个框架或变体的技能，按变体组织： ``` cloud-deploy/ ├── SKILL.md（工作流程 + 提供商选择） └── references/ ├── aws.md（AWS 部署模式） ├── gcp.md（GCP 部署模式） └── azure.md（Azure 部署模式） ``` 当用户选择 AWS 时，Claude 只读取 aws.md。 **模式 3：条件性详情** 显示基本内容，链接到高级内容： ```markdown # DOCX 处理 ## 创建文档 使用 docx-js 创建新文档。见 [DOCX-JS.md](DOCX-JS.md)。 ## 编辑文档 对于简单编辑，直接修改 XML。 **对于修订跟踪**：见 [REDLINING.md](REDLINING.md) **对于 OOXML 详情**：见 [OOXML.md](OOXML.md) ``` Claude 仅在用户需要这些功能时读取 REDLINING.md 或 OOXML.md。 **重要指南：** - **避免深层嵌套引用** - 保持引用从 SKILL.md 只有一层深度。所有参考文件应直接从 SKILL.md 链接。 - **结构化较长的参考文件** - 对于超过 100 行的文件，在顶部包含目录，以便 Claude 在预览时可以看到完整范围。 ## 技能创建流程 技能创建包括以下步骤： 1. 通过具体示例理解技能 2. 规划可复用的技能内容（脚本、参考资料、资产） 3. 初始化技能（运行 init_skill.py） 4. 编辑技能（实现资源并编写 SKILL.md） 5. 打包技能（运行 package_skill.py） 6. 基于实际使用进行迭代 按顺序执行这些步骤，仅在有明确理由说明不适用时才跳过。 ### 步骤 1：通过具体示例理解技能 仅当技能的使用模式已经清楚理解时才跳过此步骤。即使在处理现有技能时，此步骤仍然有价值。 要创建有效的技能，需要清楚理解技能将如何使用的具体示例。这种理解可以来自直接的用户示例或经过用户反馈验证的生成示例。 例如，在构建图像编辑器技能时，相关问题包括： - "图像编辑器技能应该支持什么功能？编辑、旋转，还有其他吗？" - "你能给出一些这个技能将如何使用的示例吗？" - "我可以想象用户会要求'去除这张图片的红眼'或'旋转这张图片'。你还能想象这个技能的其他使用方式吗？" - "用户说什么应该触发这个技能？" 为避免让用户不知所措，避免在单条消息中问太多问题。从最重要的问题开始，根据需要跟进以获得更好的效果。 当对技能应支持的功能有清晰认识时，结束此步骤。 ### 步骤 2：规划可复用的技能内容 要将具体示例转化为有效的技能，通过以下方式分析每个示例： 1. 考虑如何从头开始执行示例 2. 识别在反复执行这些工作流程时哪些脚本、参考资料和资产会有帮助 示例：在构建 `pdf-editor` 技能以处理"帮我旋转这个 PDF"等查询时，分析显示： 1. 旋转 PDF 每次都需要重写相同的代码 2. 在技能中存储 `scripts/rotate_pdf.py` 脚本会有帮助 示例：在设计 `frontend-webapp-builder` 技能以处理"给我构建一个待办事项应用"或"给我构建一个跟踪步数的仪表板"等查询时，分析显示： 1. 编写前端 webapp 每次都需要相同的 HTML/React 样板 2. 在技能中存储包含样板 HTML/React 项目文件的 `assets/hello-world/` 模板会有帮助 示例：在构建 `big-query` 技能以处理"今天有多少用户登录？"等查询时，分析显示： 1. 查询 BigQuery 每次都需要重新发现表模式和关系 2. 在技能中存储记录表模式的 `references/schema.md` 文件会有帮助 要确定技能的内容，分析每个具体示例以创建要包含的可复用资源列表：脚本、参考资料和资产。 ### 步骤 3：初始化技能 此时，是时候实际创建技能了。 仅当正在开发的技能已经存在且需要迭代或打包时才跳过此步骤。在这种情况下，继续下一步。 从头创建新技能时，始终运行 `init_skill.py` 脚本。该脚本方便地生成一个新的模板技能目录，自动包含技能所需的一切，使技能创建过程更加高效和可靠。 用法： ```bash scripts/init_skill.py <skill-name> --path <output-directory> ``` 该脚本： - 在指定路径创建技能目录 - 生成带有正确 frontmatter 和 TODO 占位符的 SKILL.md 模板 - 创建示例资源目录：`scripts/`、`references/` 和 `assets/` - 在每个目录中添加可以自定义或删除的示例文件 初始化后，根据需要自定义或删除生成的 SKILL.md 和示例文件。 ### 步骤 4：编辑技能 在编辑（新生成或现有的）技能时，请记住技能是为另一个 Claude 实例使用而创建的。包含对 Claude 有益且非显而易见的信息。考虑什么程序性知识、领域特定细节或可复用资产将帮助另一个 Claude 实例更有效地执行这些任务。 #### 学习经过验证的设计模式 根据技能需求查阅这些有用的指南： - **多步骤流程**：见 references/workflows.md 了解顺序工作流程和条件逻辑 - **特定输出格式或质量标准**：见 references/output-patterns.md 了解模板和示例模式 这些文件包含有效技能设计的既定最佳实践。 #### 从可复用技能内容开始 要开始实现，从上面确定的可复用资源开始：`scripts/`、`references/` 和 `assets/` 文件。请注意，此步骤可能需要用户输入。例如，在实现 `brand-guidelines` 技能时，用户可能需要提供品牌资产或模板存储在 `assets/` 中，或文档存储在 `references/` 中。 添加的脚本必须通过实际运行来测试，以确保没有错误且输出符合预期。如果有许多类似的脚本，只需测试具有代表性的样本，以确保它们都能工作，同时平衡完成时间。 任何技能不需要的示例文件和目录都应删除。初始化脚本在 `scripts/`、`references/` 和 `assets/` 中创建示例文件以演示结构，但大多数技能不需要所有这些。 #### 更新 SKILL.md **写作指南：** 始终使用祈使句/不定式形式。 ##### Frontmatter 编写包含 `name` 和 `description` 的 YAML frontmatter： - `name`：技能名称 - `description`：这是技能的主要触发机制，帮助 Claude 理解何时使用该技能。 - 包括技能做什么以及何时使用它的具体触发器/上下文。 - 将所有"何时使用"信息放在这里 - 不要放在 body 中。body 仅在触发后加载，因此 body 中的"何时使用此技能"部分对 Claude 没有帮助。 - `docx` 技能的示例描述："全面的文档创建、编辑和分析，支持修订跟踪、批注、格式保留和文本提取。当 Claude 需要处理专业文档（.docx 文件）时使用，用于：(1) 创建新文档，(2) 修改或编辑内容，(3) 处理修订跟踪，(4) 添加批注，或任何其他文档任务" 不要在 YAML frontmatter 中包含任何其他字段。 ##### Body 编写使用技能及其捆绑资源的指令。 ### 步骤 5：打包技能 技能开发完成后，必须将其打包成可分发的 .skill 文件与用户共享。打包过程会自动先验证技能以确保它满足所有要求： ```bash scripts/package_skill.py <path/to/skill-folder> ``` 可选的输出目录指定： ```bash scripts/package_skill.py <path/to/skill-folder> ./dist ``` 打包脚本将： 1. **自动验证**技能，检查： - YAML frontmatter 格式和必需字段 - 技能命名约定和目录结构 - 描述的完整性和质量 - 文件组织和资源引用 2. 如果验证通过则**打包**技能，创建以技能命名的 .skill 文件（例如 `my-skill.skill`），包含所有文件并保持正确的目录结构以供分发。.skill 文件是带有 .skill 扩展名的 zip 文件。 如果验证失败，脚本将报告错误并退出而不创建包。修复任何验证错误并再次运行打包命令。 ### 步骤 6：迭代 测试技能后，用户可能会要求改进。这通常发生在使用技能后不久，对技能表现有新鲜的上下文。 **迭代工作流程：** 1. 在实际任务中使用技能 2. 注意困难或低效之处 3. 确定应如何更新 SKILL.md 或捆绑资源 4. 实施更改并再次测试 2. skill 的下载与快速创建你可以在各类网站上找到你相中的 skills，然后直接把他们下载下来放在你的用户级或者项目集的 skills/ 目录中就可以了，你也可以直接用 cc-switch 来下载用户级的 skills CC-Switch 下载 skills 一些 skills 网站（站内搜索 skills 就有很多分享的啦） 做了一个 claude skills 的导航站 SkillsHunt，持续监控并收录各种优质的 claude skillshttp://SkillsHunt.io 推荐你觉得好用的 skills ，让 claude 更加伟大！Agent Skills Marketplace - Claude、Codex 和 ChatGPT 技能 | SkillsMP — Agent Skills Marketplace - Claude, Codex & ChatGPT Skills | Skills CliProxyApi 反重力生图 skill, 支持 4K, claude code ,codex 可用 推荐你觉得好用的 skills ，让 claude 更加伟大！GitHub - huifer/skill-security-scan: skill-security-scan is a command-line tool designed to scan and detect security risks in Claude Skills. Before installing third-party Skills, use this tool for security review to effectively prevent malicious code from stealing data or compromising your system.之前有大佬分享的 skill 安全扫描项目 推荐你觉得好用的 skills ，让 claude 更加伟大！GitHub - OthmanAdi/planning-with-files: Claude Code skill implementing Manus-style persistent markdown planning — the workflow pattern behind the $2B acquisition. GitHub - anthropics/skills: Public repository for Agent Skills分享个今天看到 Skills 相关的网站等快速创建：首先安装官方的 skill-creator，这里需要注意的是 windows 的 cli 中默认编码是 GBK，所以可能会遇见脚本执行编码错误的情况，直接让 cc 帮你修复，也可以直接下载这个修复后的 skillskill-creator.zip安装好 skill-creator 后一定要重启 cc 让它加载好这个 skill，然后直接 /skill-creator 帮我创建一个项目级的{什么什么功能}的skill 然后 cc 就一顿操作猛如虎给你建好了，肯定少不了一顿改来改去的，所以一般都是拿现成的过来用。 创建好后的 skills 在正确加载后执行 /skills 命令是会显示的: 甚至还有一个 mcp-builder 可以帮你创建 mcp 服务，我就拿他创建了一个可以连接 mysql 的 mcp，还是挺方便的，总之我觉得 skills 可以理解为各种各样的插件，你缺什么功能了你就拿过来，还是挺有趣的。Commands 的使用1. commands 的基本介绍commands 可以理解为纯提示词版的 skills（貌似 cc 加载的时候也会把自定义的 commands 当作 skills 加载？调用 /skills 可以看到创建的 skills 和 commands）一般内容都是些工作流程的约束，比如项目分析、解释代码、审查代码等简单工作流程，也分为用户级与项目级，但是 cc 不会根据上下文来自动调用，而是需要手动调用 /{command-name} 阿巴阿巴用户级：~/.claude/commands/ 全局生效项目级：<项目根目录>/.claude/commands/commands 的目录结构（支持命名空间）：.claude/commands/ ├── code/ │ ├── explain-code.md # /code:explain-code │ └── review-code.md # /code:review-code └── analysis/ └── analyze-project.md # /analysis:analyze-project 正确加载后的样子 在 commands 中同样也会要求规定 YAML frontmatter--- description: "分析项目结构和技术栈" allowed-tools: ["read", "grep", "bash", "glob"] model: sonnet ---description：命令描述。allowed-tools：允许调用的工具。model：指定的模型。2. commands 的快速创建commands 的创建目前好像没有相应的 skills 支持（也可以使用 skill-creator 来创建一个 commands-builder ），但我们依然可以拜托万能 cc 帮我们创建，他自己知道 commands 的规则，直接让它创建一个项目级的分析代码commands 即可。貌似也可以在 commands 的工作流程中让其调用多个 skills 和 mcp 协作，实现一个完整的大型工作流程，这个我目前没试过，现在日常的代码工作应该够用了。 如果佬们想要体验更牛逼的协作功能可以体验一下站内大佬做的项目 【开源】CCG v1.7.24 : Claude Code 编排三 CLI 协作 | Codex + Gemini + Claude[开源] CCW（Claude-code-workflow）6.3.X 版本新增 skill-generator-- 使用 ccw 设计具有 spec 风味的 Skill以上就是我对于 skills 和 commands 的简单总结啦 ，大家快来鞭策我📌 转载信息来源： https://linux.do/t/topic/1444241原作者： MrChen-hero转载时间： 2026/1/14 10:37:26
应该也有人注意到，skills 和 commands 文件夹中的定义都会被追加到 / 命令列表中。将两者拆分开来的目的，就是为了在结构上保持清晰，便于后续维护与扩展。说到这里，我也顺便附上一个具体示例commands 文件夹下的 code-think.md description: “自动深度思考引擎。检测到复杂推理场景时自动启动思维链，无需手动调用。支持：架构设计、问题诊断、算法分析、代码审查、方案对比、系统重构。自动迭代直到得出结论。”usage: /code-think <FEATURE_DESCRIPTION>Codex Think - 自动深度思考引擎自动触发模式：检测到下列场景时，自动启动 Sequential Thinking 工具进行迭代推理。自动触发条件满足以下任一条件时自动启动：用户明确要求深度分析“分析一下…” “帮我思考…” “怎么设计…”“为什么…” “有什么问题…” “哪个好…”多步链式推理任务需要评估 3 个以上因素或方案需要验证假设或排除可能性需要权衡利弊复杂技术决策架构选型、技术栈对比性能 / 安全 / 可维护性权衡重构方案设计问题诊断场景Bug 根因分析性能瓶颈定位异常行为排查自动迭代流程检测到复杂场景 ← 调用 sequential-thinking (nextThoughtNeeded=true) ← 分析工具返回的思考内容 ← 判断：是否需要继续推理？ ← 是 → 调用 sequential-thinking (thoughtNumber+1) ← 循环直到 nextThoughtNeeded=false ← 输出最终结论 自动迭代协议初始调用thought: "开始分析：[用户问题]..." thoughtNumber: 1 totalThoughts: [初始估计，可动态调整] nextThoughtNeeded: true 继续迭代每次调用后，根据返回内容判断：需要继续 → nextThoughtNeeded: true，递增 thoughtNumber发现错误 → isRevision: true，标明 revisesThought需要分支 → 设置 branchFromThought 和 branchId需要更多步 → needsMoreThoughts: true，递增 totalThoughts得出结论 → nextThoughtNeeded: false迭代示例场景：用户问 “这个 API 设计有什么问题？”# 调用 1/5 thought: "分析目标：评估 API 设计的合理性和潜在问题..." nextThoughtNeeded: true # 调用 2/5 thought: "维度1：接口语义 - 检查 RESTful 规范..." nextThoughtNeeded: true # 调用 3/5 thought: "维度2：安全 - 认证/授权/输入校验..." nextThoughtNeeded: true # 调用 4/5 thought: "维度3：性能 - 分页/缓存/查询优化..." nextThoughtNeeded: true # 调用 5/5 thought: "综合结论：发现 3 个问题（无分页、缺少限流、返回字段冗余），修复建议..." nextThoughtNeeded: false # 输出最终结论给用户 典型工作流场景：系统架构设计Thought 1/8: 明确业务需求的核心约束... Thought 2/8: 识别关键模块与依赖关系... Thought 3/8: 评估技术栈选型的优劣势... Thought 4/8: [分支] 探索方案 A：单体架构 Thought 5/8: [分支] 探索方案 B：微服务架构 Thought 6/8: 对比两种方案的可扩展性... Thought 7/8: 验证方案选择的安全性... Thought 8/8: 综合结论：推荐方案及实施步骤 场景：性能问题诊断Thought 1/6: 复现问题并收集症状... Thought 2/6: 假设生成：可能是数据库查询慢... Thought 3/6: 验证假设：检查查询日志... Thought 4/6: [修正] 假设不成立，转向网络层面... Thought 5/6: 发现根本原因：N+1 查询... Thought 6/6: 设计修复方案... 输出规范思考结束后，提供：结论摘要 - 核心发现或决策推理路径 - 关键思考节点的串联行动建议 - 具体的下一步操作风险提示 - 潜在问题或不确定点skills 文件夹下的 code-think 模块的 SKILL.md name: codex-thinkdescription: “自动深度思考引擎。当检测到复杂推理场景时自动启动思维链，无需手动调用。支持：架构设计、问题诊断、算法分析、代码审查、方案对比、系统重构。自动迭代直到得出结论。”Codex Think - 自动深度思考引擎自动触发模式：当检测到以下场景时，自动启动 Sequential Thinking 工具进行迭代推理。自动触发条件满足以下任一条件时自动启动：用户明确要求深度分析“分析一下…”、“帮我思考…”、“怎么设计…”“为什么…”、“有什么问题…”、“哪个更好…”多步骤推理任务需要评估 3 个以上因素 / 方案需要验证假设或排除可能性需要权衡利弊复杂技术决策架构选型、技术栈对比性能 / 安全 / 可维护性权衡重构方案设计问题诊断场景Bug 根因分析性能瓶颈定位异常行为排查自动迭代流程检测到复杂场景 ↓ 调用 sequential-thinking (nextThoughtNeeded=true) ↓ 分析工具返回的思考内容 ↓ 判断：是否需要继续推理？ ↓ 是 ↓ 调用 sequential-thinking (thoughtNumber+1) ↓ 循环直到 nextThoughtNeeded=false ↓ 输出最终结论 自动迭代协议初始调用thought: "开始分析：[用户问题]..." thoughtNumber: 1 totalThoughts: [初始估计，可动态调整] nextThoughtNeeded: true 继续迭代每次调用后，根据返回内容判断：若需要继续 → nextThoughtNeeded: true，增加 thoughtNumber若发现错误 → isRevision: true，指定 revisesThought若需探索分支 → 设置 branchFromThought 和 branchId若需要更多步骤 → needsMoreThoughts: true，增加 totalThoughts若得出结论 → nextThoughtNeeded: false迭代示例场景：用户问 "这个 API 设计有什么问题？"# 调用 1/5 thought: "分析目标：评估 API 设计的合理性和潜在问题..." nextThoughtNeeded: true # 调用 2/5 thought: "维度1：接口语义 - 检查 RESTful 规范..." nextThoughtNeeded: true # 调用 3/5 thought: "维度2：安全性 - 认证/授权/输入验证..." nextThoughtNeeded: true # 调用 4/5 thought: "维度3：性能 - 分页/缓存/查询优化..." nextThoughtNeeded: true # 调用 5/5 thought: "综合结论：发现3个问题（无分页、缺少限流、返回字段冗余），修复建议..." nextThoughtNeeded: false # 输出最终结论给用户 典型工作流场景：系统架构设计Thought 1/8: 明确业务需求的核心约束... Thought 2/8: 识别关键模块与依赖关系... Thought 3/8: 评估技术栈选型的优劣势... Thought 4/8: [分支] 探索方案A：单体架构 Thought 5/8: [分支] 探索方案B：微服务架构 Thought 6/8: 对比两种方案的可扩展性... Thought 7/8: 验证方案选择的安全性... Thought 8/8: 综合结论：推荐方案及实施步骤 场景：性能问题诊断Thought 1/6: 复现问题并收集症状... Thought 2/6: 假设生成：可能是数据库查询慢... Thought 3/6: 验证假设：检查查询日志... Thought 4/6: [修正] 假设不成立，转向网络层面... Thought 5/6: 发现根本原因：N+1 查询... Thought 6/6: 设计修复方案... 输出规范思考结束后，提供：结论摘要 - 核心发现或决策推理路径 - 关键思考节点的串联行动建议 - 具体的下一步操作风险提示 - 潜在问题或不确定点他俩实际上作用都是同一个 只是为了举例说明开头说的 这是定义了一套规范 便于维护如果要使用当前的 任选其中一个也行claude.zip说到最后至少对于我是有一定可用性的 (使用它们能大大降低全局 token 的消耗 毕竟可以按需使用嘛至于 commands 通常只负责一个明确的动作，而 skills 则能包含更复杂、可复用的功能📌 转载信息来源： https://linux.do/t/topic/1427051转载时间： 2026/1/11 08:51:57
距离 Anthropic 发布 Skills 也过去将近两个月的时间了，其中 Anthropic 提到了一个术语渐进式披露 (Progressive Disclosure)，这到底是什么东西？解决了什么问题？其实在我的 Vibe Coding 流程中，我很少使用 MCP。因为我觉得 MCP 实现质量层次不齐，本质是上下文注入 (工具的本质也是上下文注入)，我不确定别人写的提示词会不会影响到我的工作流，干脆直接不用。现在的 MCP 实现基本上就是把所有的功能全都包装成工具暴露给 Agent (一个功能包装成一个工具，给定详细的描述，告诉 agent 在什么时候进行调用，参数格式是什么)，这就导致了现在的提示词爆炸。直到 Anthropic 发布了 Skills，研究了一下发现本质仍然是提示词注入。如果说 MCP 是提供了一套注入工具的规范，那么 Skills 所提倡的则是 “离经叛道”。Skills 给了一个 Markdown 文档用于描述该 skill 的用途和最佳用法，附带提供了一些脚本 (与 MCP 不同)。由于这些脚本直接在用户本地运行，存在极大的安全风险。如果用户不能对脚本代码进行 review，很容易造成数据泄露、感染病毒等严重安全性问题。相比于 MCP 提供一个标准化的接口，Skill 提供一系列的脚本文件，不同的 skill 可能拥有不同类型的脚本文件，比如有些脚本使用 node.js 实现，有些脚本使用 Python 实现，要使用这些脚本还需要用户安装对应的运行时和脚本所需要的依赖。这也是我说 “离经叛道” 的原因所在。这真的是最佳实践吗？关于渐进式披露，Anthropic 是这样描述的：渐进式披露是使代理技能灵活且可扩展的核心设计原则。就像一本组织良好的手册，从目录开始，然后是具体章节，最后是详细的附录一样，技能允许 Claude 仅在需要时加载信息：拥有文件系统和代码执行工具的智能体在执行特定任务时，无需将技能的全部内容读取到上下文窗口中。这意味着技能中可以包含的上下文信息量实际上是无限的。下图是使用 Skill 的上下文窗口变化我们真的需要这样去实现吗？在我们平时使用 CLI 工具时，一般的 CLI 工具都会带有一个 --help 参数，用于查看该工具的用法和说明，这不就是该工具的使用手册吗？比如：>npm --help npm <command> Usage: npm install install all the dependencies in your project npm install <foo> add the <foo> dependency to your project npm test run this project's tests npm run <foo> run the script named <foo> npm <command> -h quick help on <command> npm -l display usage info for all commands npm help <term> search for help on <term> npm help npm more involved overview All commands: access, adduser, audit, bugs, cache, ci, completion, config, dedupe, deprecate, diff, dist-tag, docs, doctor, edit, exec, explain, explore, find-dupes, fund, get, help, help-search, hook, init, install, install-ci-test, install-test, link, ll, login, logout, ls, org, outdated, owner, pack, ping, pkg, prefix, profile, prune, publish, query, rebuild, repo, restart, root, run-script, sbom, search, set, shrinkwrap, star, stars, start, stop, team, test, token, uninstall, unpublish, unstar, update, version, view, whoami Specify configs in the ini-formatted file: /Users/xxx/.npmrc or on the command line via: npm <command> --key=value More configuration info: npm help config Configuration fields: npm help 7 config 这份手册也不会返回所有的命令所有的用法，它只会返回它有哪些命令可以实现什么功能，对于命令的具体用法你仍然可以通过 --help 参数获得：>npm install --help Install a package Usage: npm install [<package-spec> ...] Options: [-S|--save|--no-save|--save-prod|--save-dev|--save-optional|--save-peer|--save-bundle] [-E|--save-exact] [-g|--global] [--install-strategy <hoisted|nested|shallow|linked>] [--legacy-bundling] [--global-style] [--omit <dev|optional|peer> [--omit <dev|optional|peer> ...]] [--include <prod|dev|optional|peer> [--include <prod|dev|optional|peer> ...]] [--strict-peer-deps] [--prefer-dedupe] [--no-package-lock] [--package-lock-only] [--foreground-scripts] [--ignore-scripts] [--no-audit] [--no-bin-links] [--no-fund] [--dry-run] [--cpu <cpu>] [--os <os>] [--libc <libc>] [-w|--workspace <workspace-name> [-w|--workspace <workspace-name> ...]] [-ws|--workspaces] [--include-workspace-root] [--install-links] aliases: add, i, in, ins, inst, insta, instal, isnt, isnta, isntal, isntall Run "npm help install" for more info 这是不是很像上面的渐进式披露的定义？我们是不是可以按照这种风格去实现一个 MCP 来实现无需 skill 的工具渐进式披露？我使用 Codex 将官方的 PDF Skill 转换成了一个 MCP，只暴露一个工具：{ "name": "mcp__pdf__pdf", "description": "Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. When Claude needs to fill in a PDF form or programmatically process, generate, or analyze PDF documents at scale.You need to pass in the --help parameter to obtain the usage of this tool first.", "input_schema": { "type": "object", "properties": { "params": { "$ref": "#/$defs/PdfCommandInput" } }, "required": [ "params" ], "$defs": { "PdfCommandInput": { "additionalProperties": false, "properties": { "argv": { "description": "Command tokens excluding the leading 'pdf' executable name", "items": { "type": "string" }, "title": "Argv", "type": "array" }, "command": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "description": "Optional command string; if set, it will be split like a shell", "title": "Command" } }, "title": "PdfCommandInput", "type": "object" } }, "title": "pdfArguments" } } 下面是使用该 MCP 的上下文窗口变化User: Extract all the text from test.pdf and write it into result.txt Agent: Tool(name="pdf", args=["--help"]) Tool: pdf - Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. When Claude needs to fill in a PDF form or programmatically process, generate, or analyze PDF documents at scale在使用之前你需要先传入--help参数以获取该工具的用法\n\nUsage:\n pdf [--help] <domain> <command> [options]\n\nDomains:\n forms Fill, extract, and validate PDF form fields.\n documents Create, merge, and split PDFs.\n text Extract text content from PDFs.\n tables Extract tables (heuristic, whitespace-based).\n images Render PDF pages to PNG images.\n\nRun `pdf <domain> --help` for domain help.\nRun `pdf <domain> <command> --help` for command help. Agent: Tool(name="pdf", args=["text", "--help"]) Tool: text - Extract text content from PDFs.\n\nUsage:\n pdf text <command> [options]\n\nCommands:\n extract Extract text content from a PDF.\n\nRun `pdf text <command> --help` for details. Agent: Tool(name="pdf", args=["text", "extract", "--help"]) Tool: usage: pdf text extract --pdf PDF_PATH [--pages PAGES] [--out OUTPUT_PATH]\n [--format {text,json}] [--overwrite]\n\nExtract text content from a PDF.\n\noptions:\n --pdf PDF_PATH Input PDF\n --pages PAGES Page selection like 1,3-5 or 'all' (default: all)\n --out OUTPUT_PATH Write extracted text to a file\n --format {text,json} Output format (default: text)\n --overwrite Overwrite output file if it exists\n Agent: Tool(name="pdf", args=["text", "extract", "--pdf", "test.pdf", "--out", "result.txt", "--overwrite"]) Tool: {"result": {"stdout": "xx","data": {"pdf_path": "test.pdf","page_count": 6,"pages": [xxx],"format": "text","output_path": "result.txt"}}} Agent: xxx 从上下文变化情况来看，完全实现了渐进式披露，该 MCP 代码开源 (代码完全由 codex 编写，只验证想法，未做任何审查): GitHub - musistudio/pdf-skill-mcp: pdf-skill-mcp如果你有什么想法也欢迎与我进行交流📌 转载信息来源： https://linux.do/t/topic/1427188原作者： musistudio转载时间： 2026/1/11 08:44:31
用 cc 结合 skill 弄了个 AI 编程导航站，有没有兴趣要源码和 skill 的
最近用 Claude Code 捣鼓了一个 AI 开发工具导航站，结合 Skills 来管理工具词条和博客内容。有没有人想要源码和 skill 的，免费送几个。