1. 从 spec-driven-development 没反应说起先把宿主模型入口接对装完 agent-skills 后我第一次在 Codex 里输入 spec-driven-development 没有任何反应切到 Claude Code 又找不到 /spec。排查下来不是 Skill 没装好而是宿主模型入口、适配层和路由没有对齐。我先把模型入口接到 TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_route再把 Base URL https://taotoken.net/api 填进宿主配置才让 using-agent-skills 正常判断该调哪个 Skill。这篇不是 agent-skills 的新闻复述而是一份尝鲜记录如何用 using-agent-skills 做任务路由、如何把 25 个 Skill 变成可执行清单、如何记录 Token 消耗、如何用 TaoToken 的 Base URL 跑通 Claude Code / Codex / CC Switch。最后你能拿到三样东西路由判断表、Skill 清单、调用记录模板。先明确一点using-agent-skills 不负责实现它负责判断。它看的是当前任务处于哪个阶段、缺什么信息、风险在哪、需要什么证据然后告诉你该调用 interview-me、spec-driven-development、planning-and-task-breakdown、test-driven-development、debugging、security-hardening 等 Skill 中的哪一个或哪几个。只有路由正确后面的 Token 才不是乱烧。准备工作很简单去 TaoToken 官网注册并创建 API Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_route把 Key 保存到本地环境变量不要写进要提交的仓库。Base URL 固定为 https://taotoken.net/api注意这个地址不加 UTM 参数UTM 只用于官网和文档入口。接下来分别配置 Claude Code、Codex 和 CC Switch。2. TaoToken 接入三套配置Claude Code、Codex、CC Switch 不要混用2.1 Claude Codesettings.json 或 ANTHROPIC_* 环境变量Claude Code 读取的是 Anthropic 风格变量配置时用 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN。可以在~/.claude/settings.json写{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-5 } }如果不想改文件也可以在启动前导出export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELclaude-sonnet-4-5检查是否生效claude --version env | grep ANTHROPIC注意不要把 ANTHROPIC_* 这套变量套到 CodexCodex 不读它们。2.2 Codexconfig.toml 用 TAOTOKEN_API_KEYCodex 走自己的config.toml。在~/.codex/config.toml中增加 providermodel gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses然后在 shell 里设置export TAOTOKEN_API_KEYYOUR_API_KEY这里不要写 ANTHROPIC_AUTH_TOKEN也不要用 ANTHROPIC_BASE_URL。Codex 需要较新的 CLI 才支持原生插件式 Skill 调用安装 agent-skills 后重开会话再用 spec-driven-development 这类名称触发。如果 没反应先确认 Codex 版本和会话是否重启再看 config.toml 是否被正确读取。2.3 CC Switch 三件套Base URL、API Key、模型名如果你用 CC Switch 管理多个供应商核心就是三件套Base URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY模型名Claude Code 选 claude-sonnet-4-5Codex 选 gpt-5-codex在 CC Switch 里新增一个 Provider名称写 TaoToken把三件套填进去然后切换当前宿主使用的 Provider。切换后重启 Claude Code 或 Codex 会话。如果出现 401先查 Key如果出现 404先查 Base URL 是否多写了/v1或路径如果命令能跑但 Skill 不触发查宿主适配层和 Skill 安装目录而不是先改 Base URL。统一检查表宿主配置文件/入口关键字段不要混用Claude Codesettings.json / 环境变量ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN不要把 ANTHROPIC_* 给 CodexCodexconfig.tomlmodel_providers.taotoken.base_url、env_key不要用 ANTHROPIC_AUTH_TOKENCC SwitchProvider 面板Base URL、API Key、模型名三件套要成套切换3. using-agent-skills 怎么判断一张路由表把 25 个 Skill 串起来using-agent-skills 的职责是路由不是执行。它通常先问四个问题当前处于定义、计划、实现、验证、审查、发布中的哪一段已知信息够不够这次改动最可能坏在哪里完成后拿什么证据证明没跑偏。回答完再输出 Skill 调用顺序。下面这张表可以作为尝鲜时的路由判断表。实际名称以你本地skills/目录和 SKILL.md 为准但判断逻辑可以直接用。触发信号路由结论建议调用 Skill停止条件需要的证据需求只有一句话边界不清先不要实现interview-me能列出用户、场景、反例、不做清单问题清单与回答需求能说清但缺规格先固定契约spec-driven-development接口、数据、验收标准可写进 SPECSPEC 文档任务跨多个模块先拆小planning-and-task-breakdown每个子任务可独立验证任务列表与依赖准备改实现先写失败测试test-driven-developmentRed-Green-Refactor 走完失败与通过测试输出有可复现 Bug先复现再修debugging复现步骤稳定修复后有防护复现记录、回归测试接口要新增或变更先定契约api-design请求、响应、错误码、版本策略明确接口文档与示例前端状态复杂先理状态与交互frontend-engineering状态、可访问性、边界状态覆盖组件测试或截图涉及鉴权、输入、密钥先做威胁建模security-hardening风险项有处理或明确接受安全检查清单页面/接口变慢先测量再改performance-optimization有基线、改动、复测对比profile 与对比数据要接流水线先稳定构建ci-cd构建、测试、发布步骤可重复流水线日志上线后要定位问题先补可观测性observability日志、指标、追踪能回答故障问题仪表盘或查询结果准备合并进入审查code-review、test-review、security-review、web-performance-review风险项有结论审查记录准备发布做发布检查ship发布清单、回滚方案、负责人明确发布说明这张表的作用不是把 25 个 Skill 背下来而是让 using-agent-skills 每次都按同一套维度输出路由。你可以把这张表当作人工复核如果 Agent 直接跳到 test-driven-development 而没有先走 spec-driven-development就要问它为什么。需要强调路由本身也会消耗 Token。但这段 Token 花得值因为它阻止模型在错误需求上生成大段实现。真正的浪费不是路由而是跳过路由直接产出不可验收的代码。4. 25 个 Skill 清单与调用记录把“用了哪个”变成可追溯安装 agent-skills 后不要只看 README 的列表。建议在项目根目录做三件事列出实际安装的 Skill抽取每个 SKILL.md 的适用时机和停止条件为每次任务建一条调用记录。命令示例npx skills list npx skills add using-agent-skills npx skills add spec-driven-development npx skills add planning-and-task-breakdown npx skills add test-driven-development如果已经整仓克隆也可以直接查看ls skills/ find skills -maxdepth 2 -name SKILL.md | sort生成 Skill 清单时可以用这个 Markdown 模板| Skill | 阶段 | 适用时机 | 停止条件 | 依赖的 references | | --- | --- | --- | --- | --- | | using-agent-skills | 路由 | 不知道该调哪个 Skill | 输出调用顺序与证据清单 | 无 | | interview-me | 定义 | 需求模糊 | 边界和反例明确 | 需求检查清单 | | spec-driven-development | 定义 | 需求可写但缺规格 | SPEC 可验收 | 规格模板 | | planning-and-task-breakdown | 计划 | 任务大、跨模块 | 子任务可独立验证 | 任务拆解清单 | | test-driven-development | 验证 | 准备改实现 | 失败测试转通过 | 测试清单 | | debugging | 验证 | 有可复现 Bug | 复现稳定且有回归 | 调试清单 | | api-design | 实现 | 接口新增/变更 | 契约明确 | 接口检查清单 | | frontend-engineering | 实现 | 前端状态复杂 | 边界状态覆盖 | 前端清单 | | security-hardening | 审查 | 涉及鉴权/输入/密钥 | 风险有结论 | 安全清单 | | performance-optimization | 验证 | 性能下降 | 基线-改动-复测 | 性能清单 | | ci-cd | 发布 | 接流水线 | 构建发布可重复 | CI 清单 | | observability | 发布 | 上线排障 | 日志指标追踪可用 | 可观测性清单 | | code-review | 审查 | 准备合并 | 审查意见闭环 | 评审清单 | | ship | 发布 | 准备上线 | 发布与回滚明确 | 发布清单 |注意这里只列了尝鲜最常碰到的 Skill仓库里的 25 个以你本地实际目录为准。不要为了凑清单去猜名称直接find出来的最可靠。调用记录模板| 时间 | 任务 | using-agent-skills 路由结论 | 实际调用 Skill | Token 消耗关注点 | 产出证据 | 人工确认 | | --- | --- | --- | --- | --- | --- | --- | | 2026-xx-xx | 订单查询加分页 | 规格→计划→测试→性能→审查 | spec-driven-development、planning-and-task-breakdown、test-driven-development、performance-optimization、code-review | 路由提示词、测试输出、profile | SPEC.md、任务列表、测试日志、profile | 接口契约、分页边界、SQL 本地执行 |Token 消耗关注点不要只写“用了多少”要写“花在哪”。例如路由提示词占多少、每个 Skill 的上下文多大、测试输出是否被完整塞回模型、重复总结是否造成浪费。这样你才能优化而不是单纯压缩上下文。5. 实操让 using-agent-skills 跑一次完整路由以“给已有订单查询接口增加分页”为例尝鲜流程如下。第一步不写实现只让路由 Skill 判断。提示词可以这样你现在只做路由不写实现。 读取 skills/using-agent-skills/SKILL.md。 任务给已有订单查询接口增加分页默认 20 条支持 page 和 page_size。 现状接口已有缺少分页数据库是本地测试库SQL 由我本地执行。 请输出 1. 当前处于哪个阶段 2. 应调用的 Skill 列表与顺序 3. 每个 Skill 的停止条件 4. 每个 Skill 需要产出的证据 5. 哪些步骤必须人工确认第二步检查路由结果。一个合理输出可能是1. 阶段定义与计划优先。 2. 调用顺序 spec-driven-development planning-and-task-breakdown test-driven-development performance-optimization code-review 3. 停止条件 spec分页参数、默认值、边界、错误响应明确。 plan拆成接口契约、查询改造、测试、性能验证。 tdd先有失败测试再实现到通过。 performance有基线、改动、复测对比。 review风险项有结论。 4. 证据SPEC、任务列表、失败/通过测试输出、profile、审查记录。 5. 人工确认接口契约、分页边界、SQL 在本地执行。第三步按顺序调用 Skill。每次调用只把必要上下文交给模型当前 SPEC、当前任务、上次测试输出。不要把整个仓库和所有历史日志一次性塞进去。第四步保存证据。测试输出、profile 结果、审查意见都写入调用记录。第五步人工确认。尤其是接口契约、SQL、合并前差异和安全检查。Skill 能要求 Agent 给证据但不能替代人的最终判断。这里再给一个 Codex/Claude Code 通用的验证清单# 1. 确认宿主模型入口 claude --version codex --version # 2. 确认 Skill 目录 ls skills/using-agent-skills/SKILL.md ls skills/spec-driven-development/SKILL.md # 3. 确认调用记录目录 mkdir -p .agent-recordsSQL 和数据库命令由读者在本地测试库执行不要让 Agent 直连生产库也不要通过 MCP 或 Agent 去操作 Oracle/生产数据库。6. 排障references 丢失、Codex 版本、VS Code Copilot 命令差异常见问题一单装一个 Skill 后SKILL.md 里引用references/下的检查清单但打开路径不存在。原因是npx skills add name往往只复制skills/name/目录不会带上仓库根目录的共享references/。解决方式有三种整仓克隆把需要的检查清单复制到对应 Skill 的references/或者改用能保留共享目录的集成方式。遇到“找不到 checklist”的报错时先查目录结构不要先怀疑模型。常见问题二在 Codex 里输入spec-driven-development没反应。先确认 Codex CLI 版本是否支持原生插件重开会话再确认 Skill 是否安装到了 Codex 能扫描的目录。README 中的斜杠命令/spec、/plan、/build、/test、/review、/ship主要由特定适配层提供不是所有宿主都一模一样。VS Code 版 GitHub Copilot 里找不到/spec就是典型情况CLI 和 VS Code 的安装方式、调用入口不同。不要因为一个宿主没有斜杠命令就认为 Skill 没装成功。常见问题三改了 Base URL 后宿主仍然报鉴权失败。按宿主分开查Claude Code查ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN是否生效。Codex查config.toml的base_url和env_key对应环境变量不要看 ANTHROPIC_*。CC Switch查三件套是否成套特别是模型名是否和宿主匹配。常见问题四路由 Skill 没有按预期调用具体 Skill。检查两件事提示词是否明确要求“只做路由不写实现”SKILL.md 是否被完整读取。你可以要求 Agent 在输出路由后再列出它读取了哪些文件。如果它没有读取using-agent-skills/SKILL.md那它只是在凭训练记忆猜。7. 把 Token 花在路由和证据上下一步这样接入agent-skills 的价值不在于多装几个 Skill而在于让 Agent 先判断任务该走哪条工程路径再消耗 Token 执行。using-agent-skills 是入口25 个 Skill 是步骤SKILL.md 里的停止条件和验收要求是约束references/ 和 evals/ 是补充证据。你要留下的不是一段“看起来能跑”的代码而是路由判断表、Skill 清单和调用记录。接入顺序建议去 TaoToken 官网创建 API Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_route把 Base URLhttps://taotoken.net/api填入 Claude Code 或 Codex安装 using-agent-skills 和第一批具体 Skill用本文的路由表跑一次真实任务把每次调用写入.agent-records/合并前人工确认测试输出、代码差异和安全检查。如果你还没有 Key可以先从模型对话验证接口再决定是否进入 Coding Plan。文末入口按这个顺序走模型对话https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_routeCoding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_route创建 API Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_routeClaude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_route建议顺序模型对话 → Coding Plan → 创建 API Key → 按 Claude Code 文档完成宿主配置。先把 Base URL 接对再让 using-agent-skills 决定 Token 花在哪个 Skill 上。 using-agent-skills 判断任务路由，Base URL 交给 TaoToken 跑 25 个 Skill
1. 从 spec-driven-development 没反应说起先把宿主模型入口接对装完 agent-skills 后我第一次在 Codex 里输入 spec-driven-development 没有任何反应切到 Claude Code 又找不到 /spec。排查下来不是 Skill 没装好而是宿主模型入口、适配层和路由没有对齐。我先把模型入口接到 TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_route再把 Base URL https://taotoken.net/api 填进宿主配置才让 using-agent-skills 正常判断该调哪个 Skill。这篇不是 agent-skills 的新闻复述而是一份尝鲜记录如何用 using-agent-skills 做任务路由、如何把 25 个 Skill 变成可执行清单、如何记录 Token 消耗、如何用 TaoToken 的 Base URL 跑通 Claude Code / Codex / CC Switch。最后你能拿到三样东西路由判断表、Skill 清单、调用记录模板。先明确一点using-agent-skills 不负责实现它负责判断。它看的是当前任务处于哪个阶段、缺什么信息、风险在哪、需要什么证据然后告诉你该调用 interview-me、spec-driven-development、planning-and-task-breakdown、test-driven-development、debugging、security-hardening 等 Skill 中的哪一个或哪几个。只有路由正确后面的 Token 才不是乱烧。准备工作很简单去 TaoToken 官网注册并创建 API Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_route把 Key 保存到本地环境变量不要写进要提交的仓库。Base URL 固定为 https://taotoken.net/api注意这个地址不加 UTM 参数UTM 只用于官网和文档入口。接下来分别配置 Claude Code、Codex 和 CC Switch。2. TaoToken 接入三套配置Claude Code、Codex、CC Switch 不要混用2.1 Claude Codesettings.json 或 ANTHROPIC_* 环境变量Claude Code 读取的是 Anthropic 风格变量配置时用 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN。可以在~/.claude/settings.json写{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-5 } }如果不想改文件也可以在启动前导出export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELclaude-sonnet-4-5检查是否生效claude --version env | grep ANTHROPIC注意不要把 ANTHROPIC_* 这套变量套到 CodexCodex 不读它们。2.2 Codexconfig.toml 用 TAOTOKEN_API_KEYCodex 走自己的config.toml。在~/.codex/config.toml中增加 providermodel gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses然后在 shell 里设置export TAOTOKEN_API_KEYYOUR_API_KEY这里不要写 ANTHROPIC_AUTH_TOKEN也不要用 ANTHROPIC_BASE_URL。Codex 需要较新的 CLI 才支持原生插件式 Skill 调用安装 agent-skills 后重开会话再用 spec-driven-development 这类名称触发。如果 没反应先确认 Codex 版本和会话是否重启再看 config.toml 是否被正确读取。2.3 CC Switch 三件套Base URL、API Key、模型名如果你用 CC Switch 管理多个供应商核心就是三件套Base URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY模型名Claude Code 选 claude-sonnet-4-5Codex 选 gpt-5-codex在 CC Switch 里新增一个 Provider名称写 TaoToken把三件套填进去然后切换当前宿主使用的 Provider。切换后重启 Claude Code 或 Codex 会话。如果出现 401先查 Key如果出现 404先查 Base URL 是否多写了/v1或路径如果命令能跑但 Skill 不触发查宿主适配层和 Skill 安装目录而不是先改 Base URL。统一检查表宿主配置文件/入口关键字段不要混用Claude Codesettings.json / 环境变量ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN不要把 ANTHROPIC_* 给 CodexCodexconfig.tomlmodel_providers.taotoken.base_url、env_key不要用 ANTHROPIC_AUTH_TOKENCC SwitchProvider 面板Base URL、API Key、模型名三件套要成套切换3. using-agent-skills 怎么判断一张路由表把 25 个 Skill 串起来using-agent-skills 的职责是路由不是执行。它通常先问四个问题当前处于定义、计划、实现、验证、审查、发布中的哪一段已知信息够不够这次改动最可能坏在哪里完成后拿什么证据证明没跑偏。回答完再输出 Skill 调用顺序。下面这张表可以作为尝鲜时的路由判断表。实际名称以你本地skills/目录和 SKILL.md 为准但判断逻辑可以直接用。触发信号路由结论建议调用 Skill停止条件需要的证据需求只有一句话边界不清先不要实现interview-me能列出用户、场景、反例、不做清单问题清单与回答需求能说清但缺规格先固定契约spec-driven-development接口、数据、验收标准可写进 SPECSPEC 文档任务跨多个模块先拆小planning-and-task-breakdown每个子任务可独立验证任务列表与依赖准备改实现先写失败测试test-driven-developmentRed-Green-Refactor 走完失败与通过测试输出有可复现 Bug先复现再修debugging复现步骤稳定修复后有防护复现记录、回归测试接口要新增或变更先定契约api-design请求、响应、错误码、版本策略明确接口文档与示例前端状态复杂先理状态与交互frontend-engineering状态、可访问性、边界状态覆盖组件测试或截图涉及鉴权、输入、密钥先做威胁建模security-hardening风险项有处理或明确接受安全检查清单页面/接口变慢先测量再改performance-optimization有基线、改动、复测对比profile 与对比数据要接流水线先稳定构建ci-cd构建、测试、发布步骤可重复流水线日志上线后要定位问题先补可观测性observability日志、指标、追踪能回答故障问题仪表盘或查询结果准备合并进入审查code-review、test-review、security-review、web-performance-review风险项有结论审查记录准备发布做发布检查ship发布清单、回滚方案、负责人明确发布说明这张表的作用不是把 25 个 Skill 背下来而是让 using-agent-skills 每次都按同一套维度输出路由。你可以把这张表当作人工复核如果 Agent 直接跳到 test-driven-development 而没有先走 spec-driven-development就要问它为什么。需要强调路由本身也会消耗 Token。但这段 Token 花得值因为它阻止模型在错误需求上生成大段实现。真正的浪费不是路由而是跳过路由直接产出不可验收的代码。4. 25 个 Skill 清单与调用记录把“用了哪个”变成可追溯安装 agent-skills 后不要只看 README 的列表。建议在项目根目录做三件事列出实际安装的 Skill抽取每个 SKILL.md 的适用时机和停止条件为每次任务建一条调用记录。命令示例npx skills list npx skills add using-agent-skills npx skills add spec-driven-development npx skills add planning-and-task-breakdown npx skills add test-driven-development如果已经整仓克隆也可以直接查看ls skills/ find skills -maxdepth 2 -name SKILL.md | sort生成 Skill 清单时可以用这个 Markdown 模板| Skill | 阶段 | 适用时机 | 停止条件 | 依赖的 references | | --- | --- | --- | --- | --- | | using-agent-skills | 路由 | 不知道该调哪个 Skill | 输出调用顺序与证据清单 | 无 | | interview-me | 定义 | 需求模糊 | 边界和反例明确 | 需求检查清单 | | spec-driven-development | 定义 | 需求可写但缺规格 | SPEC 可验收 | 规格模板 | | planning-and-task-breakdown | 计划 | 任务大、跨模块 | 子任务可独立验证 | 任务拆解清单 | | test-driven-development | 验证 | 准备改实现 | 失败测试转通过 | 测试清单 | | debugging | 验证 | 有可复现 Bug | 复现稳定且有回归 | 调试清单 | | api-design | 实现 | 接口新增/变更 | 契约明确 | 接口检查清单 | | frontend-engineering | 实现 | 前端状态复杂 | 边界状态覆盖 | 前端清单 | | security-hardening | 审查 | 涉及鉴权/输入/密钥 | 风险有结论 | 安全清单 | | performance-optimization | 验证 | 性能下降 | 基线-改动-复测 | 性能清单 | | ci-cd | 发布 | 接流水线 | 构建发布可重复 | CI 清单 | | observability | 发布 | 上线排障 | 日志指标追踪可用 | 可观测性清单 | | code-review | 审查 | 准备合并 | 审查意见闭环 | 评审清单 | | ship | 发布 | 准备上线 | 发布与回滚明确 | 发布清单 |注意这里只列了尝鲜最常碰到的 Skill仓库里的 25 个以你本地实际目录为准。不要为了凑清单去猜名称直接find出来的最可靠。调用记录模板| 时间 | 任务 | using-agent-skills 路由结论 | 实际调用 Skill | Token 消耗关注点 | 产出证据 | 人工确认 | | --- | --- | --- | --- | --- | --- | --- | | 2026-xx-xx | 订单查询加分页 | 规格→计划→测试→性能→审查 | spec-driven-development、planning-and-task-breakdown、test-driven-development、performance-optimization、code-review | 路由提示词、测试输出、profile | SPEC.md、任务列表、测试日志、profile | 接口契约、分页边界、SQL 本地执行 |Token 消耗关注点不要只写“用了多少”要写“花在哪”。例如路由提示词占多少、每个 Skill 的上下文多大、测试输出是否被完整塞回模型、重复总结是否造成浪费。这样你才能优化而不是单纯压缩上下文。5. 实操让 using-agent-skills 跑一次完整路由以“给已有订单查询接口增加分页”为例尝鲜流程如下。第一步不写实现只让路由 Skill 判断。提示词可以这样你现在只做路由不写实现。 读取 skills/using-agent-skills/SKILL.md。 任务给已有订单查询接口增加分页默认 20 条支持 page 和 page_size。 现状接口已有缺少分页数据库是本地测试库SQL 由我本地执行。 请输出 1. 当前处于哪个阶段 2. 应调用的 Skill 列表与顺序 3. 每个 Skill 的停止条件 4. 每个 Skill 需要产出的证据 5. 哪些步骤必须人工确认第二步检查路由结果。一个合理输出可能是1. 阶段定义与计划优先。 2. 调用顺序 spec-driven-development planning-and-task-breakdown test-driven-development performance-optimization code-review 3. 停止条件 spec分页参数、默认值、边界、错误响应明确。 plan拆成接口契约、查询改造、测试、性能验证。 tdd先有失败测试再实现到通过。 performance有基线、改动、复测对比。 review风险项有结论。 4. 证据SPEC、任务列表、失败/通过测试输出、profile、审查记录。 5. 人工确认接口契约、分页边界、SQL 在本地执行。第三步按顺序调用 Skill。每次调用只把必要上下文交给模型当前 SPEC、当前任务、上次测试输出。不要把整个仓库和所有历史日志一次性塞进去。第四步保存证据。测试输出、profile 结果、审查意见都写入调用记录。第五步人工确认。尤其是接口契约、SQL、合并前差异和安全检查。Skill 能要求 Agent 给证据但不能替代人的最终判断。这里再给一个 Codex/Claude Code 通用的验证清单# 1. 确认宿主模型入口 claude --version codex --version # 2. 确认 Skill 目录 ls skills/using-agent-skills/SKILL.md ls skills/spec-driven-development/SKILL.md # 3. 确认调用记录目录 mkdir -p .agent-recordsSQL 和数据库命令由读者在本地测试库执行不要让 Agent 直连生产库也不要通过 MCP 或 Agent 去操作 Oracle/生产数据库。6. 排障references 丢失、Codex 版本、VS Code Copilot 命令差异常见问题一单装一个 Skill 后SKILL.md 里引用references/下的检查清单但打开路径不存在。原因是npx skills add name往往只复制skills/name/目录不会带上仓库根目录的共享references/。解决方式有三种整仓克隆把需要的检查清单复制到对应 Skill 的references/或者改用能保留共享目录的集成方式。遇到“找不到 checklist”的报错时先查目录结构不要先怀疑模型。常见问题二在 Codex 里输入spec-driven-development没反应。先确认 Codex CLI 版本是否支持原生插件重开会话再确认 Skill 是否安装到了 Codex 能扫描的目录。README 中的斜杠命令/spec、/plan、/build、/test、/review、/ship主要由特定适配层提供不是所有宿主都一模一样。VS Code 版 GitHub Copilot 里找不到/spec就是典型情况CLI 和 VS Code 的安装方式、调用入口不同。不要因为一个宿主没有斜杠命令就认为 Skill 没装成功。常见问题三改了 Base URL 后宿主仍然报鉴权失败。按宿主分开查Claude Code查ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN是否生效。Codex查config.toml的base_url和env_key对应环境变量不要看 ANTHROPIC_*。CC Switch查三件套是否成套特别是模型名是否和宿主匹配。常见问题四路由 Skill 没有按预期调用具体 Skill。检查两件事提示词是否明确要求“只做路由不写实现”SKILL.md 是否被完整读取。你可以要求 Agent 在输出路由后再列出它读取了哪些文件。如果它没有读取using-agent-skills/SKILL.md那它只是在凭训练记忆猜。7. 把 Token 花在路由和证据上下一步这样接入agent-skills 的价值不在于多装几个 Skill而在于让 Agent 先判断任务该走哪条工程路径再消耗 Token 执行。using-agent-skills 是入口25 个 Skill 是步骤SKILL.md 里的停止条件和验收要求是约束references/ 和 evals/ 是补充证据。你要留下的不是一段“看起来能跑”的代码而是路由判断表、Skill 清单和调用记录。接入顺序建议去 TaoToken 官网创建 API Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_route把 Base URLhttps://taotoken.net/api填入 Claude Code 或 Codex安装 using-agent-skills 和第一批具体 Skill用本文的路由表跑一次真实任务把每次调用写入.agent-records/合并前人工确认测试输出、代码差异和安全检查。如果你还没有 Key可以先从模型对话验证接口再决定是否进入 Coding Plan。文末入口按这个顺序走模型对话https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_routeCoding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_route创建 API Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_routeClaude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentusing_agent_skills_route建议顺序模型对话 → Coding Plan → 创建 API Key → 按 Claude Code 文档完成宿主配置。先把 Base URL 接对再让 using-agent-skills 决定 Token 花在哪个 Skill 上。