1. Skill 加载后步骤跑偏先用 TaoToken 固定 Key、Base URL 和模型入口你在 Claude Code 里加载 SKILL.md 后Agent 还是把提审自查输出写成散文——问题常常不在 Skill 文本而在 Key、Base URL 和模型入口没固定。TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentskill_align_output先拿 KeyBase URL 设为 https://taotoken.net/api 。很多“步骤跑偏”并不是模型不听话而是settings.json里ANTHROPIC_BASE_URL还指向旧地址或者 Codex 的config.toml里model_provider没切导致 Skill 里写死的步骤被另一套模型行为覆盖。下面按“小程序提审自查”这个高频场景把 Skill 骨架、输出格式模板、Claude Code / Codex / CC Switch 配置和排障步骤拆开。目标很明确让 Agent 按固定清单自检交付格式稳定返工越少Token 越省。先明确一个边界Skill 不是新模型也不是换皮聊天框。它更像给 Agent 用的可加载专项说明书把适用场景、步骤、禁止事项、输出格式绑在一起。模型负责推理Agent 负责调工具和推进任务Skill 负责把某类活固化成可复用流程。三层里任何一层配置漂了最终输出都会漂。小程序提审自查这种任务最怕的不是“不会做”而是“做完不按格式说”于是你还要花一轮对话把缺失的复现步骤、影响范围、下一轮修改项问回来。把格式前置到 Skill 里才能减少这种往返。1.1 先拿到可用的 Key 和 Base URL到 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentskill_align_output注册并创建 KeyKey 占位符统一写成YOUR_API_KEY。Base URL 在工具配置里统一用https://taotoken.net/api注意Base URL 不加 UTM。UTM 只用于官网入口和文末 deep link不要把查询参数塞进ANTHROPIC_BASE_URL或config.toml的base_url否则部分客户端会把整串当成路径出现 404 或鉴权失败。1.2 为什么“跑偏”经常从配置开始Claude Code 读的是ANTHROPIC_*环境变量和~/.claude/settings.jsonCodex 读的是~/.codex/config.toml和对应的 provider 环境变量。两套配置不能混。最常见的错误是在 Claude Code 里配了 TaoToken换到 Codex 时把ANTHROPIC_*原样复制过去结果 Codex 根本不认这些变量模型请求仍然走旧通道Skill 里的步骤自然被另一种默认行为接管。还有一种情况Key 没加载成功客户端静默降级到缓存或旧配置表面看是 Skill 输出不齐实际是请求根本没到目标入口。所以排障顺序应该是先确认 Key 和 Base URL 生效再检查 Skill 触发和输出约束最后才调模型参数。不要反过来先改提示词否则会在错误的地基上反复装修。2. 把“说明书”写进 SKILL.md四个字段决定 Agent 会不会自由发挥Skill 常见形态很朴素一个文件夹里面一份SKILL.md。不要先死记某家编辑器的目录规范先建立心智看到SKILL.md就把它当成这份技能的说明书首页。四个字段够用名称、触发、步骤、输出。少一个Agent 就多一分自由发挥空间。2.1 名称和触发别让 Skill 抢触发或漏触发名称要能一眼看出用途比如mini-program-review-selfcheck。触发词不要写得太宽泛。只写“检查”“优化”这类词Agent 可能在你只想改文案时也加载提审自查 Skill导致步骤串台。建议触发词绑定具体场景提审自查、发布前检查、小程序验收。这样只有你明确要做发布前核对时Skill 才被拉起来。2.2 步骤每一步都要有完成定义步骤不是愿望清单。每一步都要能回答“怎样算做完”。比如“真机走主路径”必须拆成新建、查看、编辑、删除、异常返回。每一步记录现象、复现步骤、发生页面、是否阻塞提审。没有完成定义的步骤Agent 会用“已检查”三个字交差你无法验收。2.3 禁止事项把最容易跑偏的动作写死禁止事项至少包括没有验证就写“已通过”顺手改无关页面用“感觉差不多”代替清单把输出写成散文连接生产库、Oracle 或线上数据库。需要核对数据时由读者在本地只读副本执行 SQL 或命令再把脱敏结果贴给 Agent。不要让 Agent 直连生产库也不要让 Skill 里出现自动执行线上写操作的权限。2.4 输出格式这一格是本文重点输出格式必须硬约束。不要写“尽量按以下格式”要写“必须输出三块标题不可改名、不可合并”。三块分别是已通过、未通过、建议下一轮只改。未通过每条必须附复现步骤、影响范围、是否阻塞提审。建议下一轮只改最多三条按优先级排序。输出前还要自检三块是否齐全、未通过是否每条都有复现、建议是否超过三条、是否误报已通过。下面给一份可直接抄的SKILL.md骨架。场景换成你自己的小程序项目名即可。--- name: mini-program-review-selfcheck description: 小程序提审前的固定清单自查输出三块已通过、未通过、建议下一轮只改 triggers: - 提审自查 - 发布前检查 - 小程序验收 --- # 小程序提审自查 Skill ## 适用场景 用于工具类小程序 MVP 提审前自查能记、能看、能删改不做电商、社交、复杂账号体系。 ## 步骤 1. 列出本轮范围页面、入口、数据流、权限。 2. 按主路径走一遍新建、查看、编辑、删除、异常返回。 3. 记录每个失败项现象、复现步骤、发生页面、是否阻塞提审。 4. 只改失败项不扩展范围。 5. 提审前核对名称、类目、隐私说明、截图是否与真实功能一致。 ## 禁止 - 没有验证就写“已通过”。 - 顺手改与失败项无关的页面。 - 连接生产库、Oracle 或线上数据库需要数据核对时由读者在本地只读副本执行 SQL 或命令。 - 把“感觉差不多”当作验收结论。 - 输出散文式总结必须按下方格式。 ## 输出格式 必须输出三块标题不可改名、不可合并 ### 已通过 - 条目名称证据/路径 ### 未通过 - 现象 - 复现步骤 - 影响范围 - 是否阻塞提审 ### 建议下一轮只改 - 最多 3 条按优先级排序 ## 自检 输出前检查三块是否齐全未通过是否每条都有复现步骤建议下一轮只改是否超过 3 条是否误报已通过。这份骨架不是完整安装包。真要给 Agent 自动加载还要按你使用的编辑器或 CLI 当期文档把它放到能识别的 Skill 目录或注册入口。规则变了说明书也要跟着改。3. 小程序提审自查 Skill 模板固定清单 已通过/未通过/下一轮只改小程序提审自查特别适合做成 Skill因为它的验收标准相对固定而且返工成本高。名称、类目、隐私说明、截图、主路径每一样都要真实一致。没有固定清单时你每次都要重新口述“怎样算过”Agent 也会每次用不同粒度回答。有 Skill 后你更像在验收而不是当人形说明书。3.1 固定清单建议把清单拆成五类功能范围能记、能看、能删改不做电商、社交、复杂账号体系。主路径新建、查看、编辑、删除、异常返回。异常状态白屏、无响应、错文案、空状态、网络失败。提审材料名称、类目、隐私说明、截图、版本描述。权限与数据不申请无关权限不直连生产库本地只读核对。每一类都要有“已通过”或“未通过”的结论。无法验证的条目不能写“已通过”必须写“待验证”并放进未通过。这样 Agent 就不能用模糊话术蒙混。3.2 输出格式模板Markdown 三块式让 Agent 默认输出 Markdown结构如下### 已通过 - 新建笔记真机主路径通过 - 空列表状态有空状态文案 ### 未通过 - 现象删除后列表未刷新 - 复现步骤1. 新建笔记 2. 返回列表 3. 删除 4. 观察列表 - 影响范围删除主路径 - 是否阻塞提审是 - 证据录屏 note-delete-01 ### 建议下一轮只改 - 修复删除后列表刷新 - 核对空状态文案与类目描述一致三块标题不可改名。不要用“通过项”“问题项”“优化建议”替代否则后续你写脚本做汇总时还要做映射。格式固定后你可以直接把输出贴进提审前检查表也可以让另一个 Agent 做二次校验。3.3 JSON 版本适合程序化汇总如果你要把多轮自查结果汇总可以让 Skill 输出 JSON。注意只允许一种主格式不要同时输出 Markdown 和 JSON否则上下文会变长Token 也浪费。JSON 模板如下{ passed: [ {item: 新建笔记, evidence: 真机主路径通过} ], failed: [ { symptom: 删除后列表未刷新, repro: [新建笔记, 返回列表, 删除, 观察列表], scope: 删除主路径, blocking_review: true } ], next_round_only: [修复删除后列表刷新] }在 Skill 里写清楚默认 Markdown只有显式要求“输出 JSON”时才用 JSON。这样 Agent 不会每次自由选择格式。3.4 让 Agent 不自由发挥的四句话可以原样写进 Skill 的约束区输出前先自检三块是否齐全缺一块就重写。未通过条目必须附复现步骤没有复现步骤视为无效输出。建议下一轮只改最多三条超过三条按优先级截断。无法验证的条目不得写入已通过必须写待验证并归入未通过。这四句话比“请严格遵守格式”更有效因为它们给了可检查的条件。4. Claude Code、Codex 与 CC Switch三套配置别串线配置串线是“步骤跑偏”的隐蔽原因。下面分别给 Claude Code 和 Codex 的可复制配置。再次强调不要把ANTHROPIC_*套到 Codex也不要把 Codex 的config.toml直接塞进 Claude Code。4.1 Claude Codesettings.json 与 ANTHROPIC_*Claude Code 常用~/.claude/settings.json。把 Base URL 指到 TaoTokenKey 用占位符替换。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY, ANTHROPIC_MODEL: your-model-name } }如果你的 Claude Code 版本要求使用ANTHROPIC_AUTH_TOKEN按当期文档替换对应变量不要同时保留两个冲突的 Key。模型名以 TaoToken 控制台展示为准。配置后重启终端再运行一次最小任务确认请求能返回。4.2 Codexconfig.toml 独立 providerCodex 使用~/.codex/config.toml。provider 名称可以自定义但base_url必须是https://taotoken.net/api环境变量名要和下面一致。model your-model-name model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在终端里设置export TAOTOKEN_API_KEYYOUR_API_KEYWindows PowerShell 可以用$env:TAOTOKEN_API_KEYYOUR_API_KEY模型名和wire_api以 TaoToken 控制台与 Codex 当期文档为准。关键点Codex 不要再读ANTHROPIC_*否则会出现“配置看起来对请求仍走旧通道”的情况。4.3 CC Switch 三件套配置文件、环境变量、Key 别名多环境切换时建议按“CC Switch 三件套”管理组件作用放什么不要放什么配置文件持久化供应商Claude Codesettings.jsonCodexconfig.toml不要把ANTHROPIC_*混写进 Codex环境变量运行时注入 KeyANTHROPIC_API_KEY/TAOTOKEN_API_KEY不要把 Key 提交到 GitKey 别名/Profile区分 dev、review、release不同 Key 或不同模型名不要让 Agent 自动改全局 Key切换环境时一次只改一层先切配置文件里的 provider再切环境变量最后跑最小任务验证。不要同时改三处否则排障时无法定位是哪一层生效。5. 让输出格式不漂移模板、校验和 Token 账本Skill 写好后仍可能因为上下文过长、日志太多、任务边界模糊而漂移。解决办法不是反复口述而是把格式校验变成 Skill 的一部分。5.1 输出前自检在 Skill 末尾加一段自检逻辑## 输出前自检 1. 是否输出三块已通过、未通过、建议下一轮只改。 2. 未通过是否每条都有复现步骤、影响范围、是否阻塞提审。 3. 建议下一轮只改是否超过 3 条。 4. 是否有无法验证却写成已通过的条目。 以上任意一项不满足重写后再输出。这段自检不会让模型变聪明但能显著减少格式缺失。5.2 用最小样例校准新 Skill 第一次使用时先给一个最小样例不要直接跑完整项目。比如任务对“随手记一笔”做提审前自查。 范围新建、列表、删除。 请按 Skill 输出三块。看输出是否三块齐全、未通过是否有复现。格式对了再扩大到完整清单。格式不对先改 Skill不要改模型。5.3 Token 账本返工越少省得越多固定输出格式的直接收益是减少往返。没有格式时常见流程是Agent 输出一段总结你追问“未通过有哪些”再追问“复现步骤”再追问“下一轮改什么”。每一轮追问都会把之前的上下文重新带入Token 消耗不是线性的而是随对话长度累积。格式固化后一次交付三块下一轮只改列表里的条目上下文更短返工更少。这不是玄学。你只要记录两次同类任务一次自由输出一次 Skill 固定格式。对比轮数和每轮输入长度就能看到差距。重点不是追求极限省 Token而是把省下的额度留给真正需要推理的排障环节。6. 排障清单从 Base URL 到触发词逐项核对当 Agent 仍然跑偏按下面顺序核对不要跳步。6.1 网络与 Base URL先确认 TaoToken 入口可达curl -I https://taotoken.net/api如果这里不通先检查网络和代理设置不要继续改 Skill。注意 Base URL 不加 UTM保持https://taotoken.net/api。6.2 环境变量是否串线用下面命令脱敏查看env | grep -E ANTHROPIC|TAOTOKEN|OPENAI | sed s/\(KEY\).*/\1***/PowerShellGet-ChildItem Env: | Where-Object { $_.Name -match ANTHROPIC|TAOTOKEN|OPENAI } | ForEach-Object { $($_.Name)*** }重点看Claude Code 是否读ANTHROPIC_*Codex 是否读TAOTOKEN_API_KEY有没有旧 Key 覆盖新 Key。6.3 配置文件的 provider 是否生效Claude Code 检查settings.json的ANTHROPIC_BASE_URLCodex 检查config.toml的model_provider和[model_providers.taotoken]。改完重启终端再跑最小任务。不要只改一处就下结论。6.4 Skill 触发是否太宽如果 Agent 在无关任务里也加载提审自查 Skill说明触发词太宽。把检查、优化这类词收窄只保留提审自查、发布前检查、小程序验收。6.5 输出格式是否被长上下文冲掉如果前面有大量日志、代码片段后面的格式约束可能被稀释。把 Skill 的输出格式放在最后一段并在任务末尾再重复一句“必须按三块输出未通过附复现步骤。”这比只在开头写一次更稳。6.6 权限是否留了一手Skill 不等于可以乱删库、乱提权、直连生产库。重要操作由你本地确认。需要查数据时在本地只读副本执行 SQL 或命令把脱敏结果贴给 Agent。不要让 Agent 连接 Oracle 或线上生产库。这条要写进 Skill 的禁止事项。7. 把高频自查固化成 Skill从模型对话到 Coding Plan 的上手路径如果你还没有 Key建议按这条路径走先模型对话验证输出格式再上 Coding Plan然后创建 Key最后按 Claude Code 文档完成配置。每一步都只解决一个变量排障会轻松很多。模型对话入口 https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentskill_align_outputCoding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentskill_align_output创建 API Key https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentskill_align_outputClaude Code 文档 https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentskill_align_output官网入口 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentskill_align_output把 Base URL 固定为https://taotoken.net/api把 Key 占位符替换为YOUR_API_KEY再把本文的SKILL.md骨架放进你的 Agent 能加载的目录。下一次提审自查时不要再从零口述直接触发 Skill让 Agent 按“已通过、未通过、建议下一轮只改”三块交付。你验收清单而不是反复当人形说明书。