Claude Code Skill 体系实战：用 settings.json 骨架打通 Prompt 到 Workflow

1. 制造场景里，为什么 Prompt 越写越乱

如果你在制造、工艺、设备运维这类场景里用 Claude Code，大概率经历过这个阶段：一开始在对话框里写一段 Prompt，让它帮你校验工艺参数、生成点检表、分析异常日志，效果还不错。于是你把这段 Prompt 存进笔记，下次复制粘贴再用。再后来，团队里三个人各存了一版，参数阈值不一样，输出格式也不一样，同一个「设备异常分析」能给出三种结论。

问题不在于 Prompt 写得不好，而在于 Prompt 是「一次性对话」，它没有注册机制、没有触发条件、没有输入输出边界。你每次都得手动把上下文喂进去，还得祈祷模型这次记得住上次的判定标准。Claude Code 的 Skill 体系就是来解决这件事的：它把一段稳定的 Prompt 固化成可被自动加载、按需触发的「专项能力包」，让 Prompt 从「你每次要说的话」变成「团队共享的操作规程」。

这篇要交付的东西很具体：一份可复制的settings.json骨架，一套 Skill 注册与目录约定，以及验证 Skill 是否被正确加载、Agent 是否按预期触发的检查动作。适合已经在用 Claude Code、想把制造场景里的 Prompt 编排成 Workflow 的开发者。读完之后，你应该能自己写出第一个「工艺参数校验」Skill，并且知道它为什么没触发、怎么排查。

2. 先把 TaoToken 接入配好，再谈 Skill

Skill 的加载和触发依赖模型服务能正常响应，所以第一步是把接入层配稳。我用 TaoToken 作为统一入口，原因是它同时提供 Anthropic 兼容接口和模型对话能力，Claude Code 这类工具改一个base_url就能接上，不用在多个 Key 之间来回切。

官网入口在这里：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api （这个不加 UTM，直接填进配置）。

你需要先拿到 API Key，去控制台的 API Keys 页面创建：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite 。创建时建议按用途命名，比如claude-code-manufacturing，方便后面区分是哪个环境在用。

接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面写了 Anthropic 兼容端点的具体路径。Claude Code 走的是 Anthropic 协议，所以你要关注的是兼容层那部分，而不是 OpenAI 格式的/v1/chat/completions。

注意：Skill 本身是本地文件机制，不消耗额外调用；但 Skill 触发后执行的推理请求会走模型服务，所以 Key 的额度和并发要提前确认，避免 Skill 写好了却因为限流触发失败。

如果你后面要做长期编码或 Agent 编排，可以看 Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite ，它更适合持续性的工作流场景。单纯验证模型响应是否正常，用模型对话页面就够了：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 。

3. settings.json 骨架与 Skill 目录约定

Claude Code 的配置分两层：一层是settings.json，管权限、环境变量、模型接入；另一层是.claude/skills/目录，管 Skill 文件本身。很多人 Skill 不触发，不是文件写错了，而是settings.json里没把 Skill 目录纳入加载范围，或者权限没放开。

先看目录结构，这是整套体系的骨架：

your-project/ ├── .claude/ │ ├── settings.json │ └── skills/ │ ├── process-param-check/ │ │ └── SKILL.md │ ├── equipment-anomaly-analyze/ │ │ └── SKILL.md │ └── sop-update/ │ └── SKILL.md ├── CLAUDE.md └── src/

每个 Skill 是一个独立目录，目录名用短横线小写，里面放一个SKILL.md。注意是SKILL.md全大写，不是skill.md，大小写敏感的系统上写错就加载不到。

下面是settings.json的骨架，字段按用途分组，你可以直接复制后改路径：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的Key", "ANTHROPIC_MODEL": "claude-sonnet-4-20250514" }, "permissions": { "allow": [ "Read", "Glob", "Grep" ], "deny": [ "Bash(rm -rf:*)", "Bash(git push:*)" ] }, "skills": { "enabled": true, "directories": [ ".claude/skills" ], "autoLoad": true } }

几个关键点解释一下。env里的ANTHROPIC_BASE_URL指向 TaoToken 的 API 地址，不要带末尾斜杠，否则部分版本会拼出双斜杠导致 404。ANTHROPIC_MODEL填你实际要用的模型标识，不同模型对长上下文 Skill 的支持不一样，制造场景的日志分析往往上下文很长，选模型时留意窗口大小。

permissions.allow里我放了Read、Glob、Grep，因为 Skill 经常需要读取项目里的参数文件、日志文件。deny里挡掉危险命令，这是底线，Skill 再方便也不能让它自动执行破坏性操作。

skills这一段是核心。enabled打开 Skill 机制，directories声明 Skill 搜索路径，autoLoad决定启动时是否自动扫描。有些版本默认不自动加载，必须显式打开，这就是「Skill 写了但没反应」的头号原因。

提示：settings.json支持项目级和用户级两个位置。项目级放在.claude/settings.json，只对当前项目生效；用户级放在~/.claude/settings.json，全局生效。制造场景的 Skill 通常和具体产线、设备绑定，建议放项目级，避免污染其他项目。

4. 写一个能触发的制造场景 Skill

骨架搭好后，写第一个 Skill。以「工艺参数校验」为例，SKILL.md的内容结构决定了它能不能被正确触发。触发靠的是文件头部的元信息，执行靠的是正文指令。

--- name: process-param-check description: 校验制造工艺参数是否在合格区间内，输入参数表，输出异常项与建议。当用户提到工艺参数、参数校验、参数超限、合格区间时触发。 --- # 工艺参数校验 ## 触发条件 - 用户提供工艺参数表（CSV/Markdown/表格） - 用户询问某参数是否合格 - 用户要求批量校验参数区间 ## 输入 - 参数表文件，包含列：参数名、实测值、下限、上限、单位 - 可选：工艺标准编号 ## 执行步骤 1. 读取参数表，逐行比对实测值与上下限 2. 判定规则： - 实测值 < 下限 或 > 上限 → 异常 - 实测值在上下限 ±5% 内 → 预警 - 其余 → 合格 3. 对异常项，按超出幅度排序，幅度 = |实测值 - 最近边界| / 区间宽度 4. 输出 Markdown 表格，列：参数名、实测值、区间、判定、超出幅度 ## 输出格式 | 参数名 | 实测值 | 区间 | 判定 | 超出幅度 | |--------|--------|------|------|----------| | 温度 | 245 | 220-240 | 异常 | 20.8% | ## 判定标准 - 异常：超出上下限 - 预警：边界 ±5% 内 - 合格：其余情况 ## 闭环动作 异常项超过 3 个时，提示生成工单草稿，包含参数名、实测值、建议复查项。

这份 Skill 里有几个设计细节值得说。description里塞了触发关键词，Claude Code 在对话时靠这段描述判断该不该加载这个 Skill，关键词越贴近你日常说法，触发越准。判定标准写成了量化规则，±5%这种数字比「接近边界」这种描述可靠得多，模型不会自由发挥。闭环动作让输出能直接驱动下一步，而不是停在屏幕上。

写完保存到.claude/skills/process-param-check/SKILL.md，重启 Claude Code 会话让它重新扫描。

5. 验证 Skill 被加载、Agent 按预期触发

Skill 写完不代表生效，必须验证。分三步查：加载、触发、执行。

第一步，确认 Skill 被扫描到。在 Claude Code 里输入斜杠命令查看可用 Skill 列表，或者直接问它「当前有哪些 Skill 可用」。如果列表里没有process-param-check，说明加载失败，回到settings.json检查directories路径和autoLoad开关。

第二步，验证触发。用一句贴近description的话测试，比如「帮我校验这份工艺参数表，看看有没有超限的」。如果模型没有调用 Skill 而是直接回答，通常是description里的触发词和你的说法对不上。把你说的话补进description的触发条件里，再试。

第三步，验证执行结果。喂一份带异常值的参数表，看输出是不是严格按你定义的表格格式，判定列有没有出现「异常」「预警」「合格」三种值。如果格式跑偏，说明正文指令不够具体，把输出格式再写死一点。

# 快速检查 Skill 文件是否在正确位置 ls -la .claude/skills/*/SKILL.md # 检查 settings.json 是否是合法 JSON python3 -m json.tool .claude/settings.json > /dev/null && echo "JSON OK"

这两条命令能挡掉大部分低级错误：文件放错目录、JSON 多了个逗号。我踩过的坑里，有一半是settings.json里skills字段拼成了skill，单复数写错，加载直接静默失败，没有任何报错。

注意：修改settings.json后必须重启会话，热加载在部分版本不生效。如果你改了配置发现没变化，先重启再排查。

6. 常见报错与排查清单

Skill 体系的问题大多集中在加载和触发两个环节，下面按现象列排查路径。

401 和 404 这两类，去 API Keys 页面重新确认 Key 状态：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite 。如果 Key 没问题，再看接入文档里的端点路径是否和你填的一致：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。

还有一个隐蔽问题：多个 Skill 的description触发词重叠，模型不知道该调哪个。制造场景里「参数校验」和「异常分析」很容易撞词。解决办法是让触发条件互斥，参数校验管「区间比对」，异常分析管「根因推断」，在 description 里把边界划清楚。

7. 从 Skill 到 Workflow 的编排思路

单个 Skill 跑通后，真正的价值在组合。制造场景的典型链路是：点检 Skill 读取设备数据 → 参数校验 Skill 判定异常 → 异常分析 Skill 推断根因 → SOP 更新 Skill 生成修订草稿。这四个 Skill 各自独立，通过对话串联成 Workflow。

串联时要注意上下文传递。每个 Skill 的输出格式要能被下一个 Skill 的输入接住，比如参数校验输出 Markdown 表格，异常分析就要能读 Markdown 表格。格式约定统一了，Workflow 才顺。

如果你要把这条链路做成长期运行的 Agent，用 Coding Plan 会更合适：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。它面向持续编码和 Agent 场景，比按次调用更适合流水线式的编排。

最后给一个实用建议：Skill 不要一次写太多，先把最高频的那一个写扎实，跑通加载、触发、执行、闭环四步，再复制这套结构扩展。我见过太多人一口气写了八个 Skill，结果触发词互相打架，最后全废。一个能稳定触发的 Skill，胜过八个躺在目录里没人调用的文件。