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 接入配好再谈 SkillSkill 的加载和触发依赖模型服务能正常响应所以第一步是把接入层配稳。我用 TaoToken 作为统一入口原因是它同时提供 Anthropic 兼容接口和模型对话能力Claude Code 这类工具改一个base_url就能接上不用在多个 Key 之间来回切。官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 这个不加 UTM直接填进配置。你需要先拿到 API Key去控制台的 API Keys 页面创建https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。创建时建议按用途命名比如claude-code-manufacturing方便后面区分是哪个环境在用。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面写了 Anthropic 兼容端点的具体路径。Claude Code 走的是 Anthropic 协议所以你要关注的是兼容层那部分而不是 OpenAI 格式的/v1/chat/completions。注意Skill 本身是本地文件机制不消耗额外调用但 Skill 触发后执行的推理请求会走模型服务所以 Key 的额度和并发要提前确认避免 Skill 写好了却因为限流触发失败。如果你后面要做长期编码或 Agent 编排可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 它更适合持续性的工作流场景。单纯验证模型响应是否正常用模型对话页面就够了https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。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 体系的问题大多集中在加载和触发两个环节下面按现象列排查路径。现象可能原因排查动作Skill 列表为空skills.enabled为 false检查 settings.json 开关Skill 列表为空目录路径写错用 ls 确认 SKILL.md 存在Skill 不触发description 缺触发词补关键词后重启触发但输出乱正文指令不具体补量化判定和输出格式请求 401API Key 无效重新在控制台生成请求 404base_url 带末尾斜杠去掉斜杠重试请求超时上下文过长或限流拆分输入或检查额度401 和 404 这两类去 API Keys 页面重新确认 Key 状态https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。如果 Key 没问题再看接入文档里的端点路径是否和你填的一致https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。还有一个隐蔽问题多个 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_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。它面向持续编码和 Agent 场景比按次调用更适合流水线式的编排。最后给一个实用建议Skill 不要一次写太多先把最高频的那一个写扎实跑通加载、触发、执行、闭环四步再复制这套结构扩展。我见过太多人一口气写了八个 Skill结果触发词互相打架最后全废。一个能稳定触发的 Skill胜过八个躺在目录里没人调用的文件。