Claude Code Skill 实用价值与自用场景示例
应该也有人注意到，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-think
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: 设计修复方案... 输出规范
思考结束后，提供：
- 结论摘要 - 核心发现或决策
- 推理路径 - 关键思考节点的串联
- 行动建议 - 具体的下一步操作
- 风险提示 - 潜在问题或不确定点
他俩实际上作用都是同一个 只是为了举例说明开头说的 这是定义了一套规范 便于维护
如果要使用当前的 任选其中一个也行
说到最后
- 至少对于我是有一定可用性的 (使用它们能大大降低全局 token 的消耗 毕竟可以按需使用嘛
- 至于 commands 通常只负责一个明确的动作，而 skills 则能包含更复杂、可复用的功能