1. 从“老王离职”说起为什么需要 OLLEAGUE.SKILL 做知识蒸馏团队里总有一两个“老王”。他审代码时能一眼看出接口改动的兼容性风险线上出故障时能判断该不该立刻升级给新人讲技术取舍时三句话就能说清。问题是这些判断力没有写进任何一本手册而是散在代码评审意见、工作群聊天、事故复盘、设计文档和邮件里。人一走文件还在但“他当时是怎么判断的”基本就断了。普通 RAG 能帮你把相关文档找出来但它回答的是“资料在哪里”。你问“这个 API 改动能不能过”它可能把老王过去三条评审意见原文贴给你却不会告诉你老王通常按什么规则下结论。普通 Persona Prompt 又容易只学到语气模型会说“这个问题要谨慎”但没学会真正的判断标准而且规则来源不明、错了不好改、没法回滚。OLLEAGUE.SKILL 想解决的就是这件事把异构的人类活动痕迹蒸馏成 AI Agent 可以调用、同时人能检查和修改的 Skill 包。它和经典模型蒸馏不一样不是把大模型压成小模型而是把文档、聊天、评审记录整理成 Markdown、JSON 和元数据文件。适合谁需要把专家经验沉淀为 Agent 可调用 Skill 的开发者、平台工程师、技术团队负责人。这篇就按可跟做的路径从蒸馏模板、目录结构到验证脚本走一遍并用 TaoToken 统一 Key 完成生成与回归测试。2. TaoToken 前置统一 Key 调用模型完成 Skill 生成做知识蒸馏时最烦的是模型调用层不统一。生成 work.md 用一个模型跑回归测试换另一个Key 和 Base URL 到处散落脚本里硬编码一堆环境变量。我试过把调用层收敛到 TaoToken一个 Key 走完生成和验证脚本可复现性会好很多。TaoToken 在这里的角色是统一的模型调用入口。你可以在官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 了解整体能力实际调用走 API 地址 https://taotoken.net/api。对 OLLEAGUE.SKILL 流程来说它解决的是“蒸馏流水线里模型调用不统一”的问题痕迹接入后要提炼能力轨和行为轨生成 work.md、persona.md再跑回归测试这些步骤都可以用同一个 Key 和 Base URL。先拿 Key。进入 API Keys 页面创建建议按项目命名比如colleague-skill-distill方便后面区分生成和测试用途。拿到 Key 后不要写进代码放环境变量export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api模型 ID 怎么选蒸馏阶段需要理解长文档、提炼规则选上下文长、指令跟随稳的模型回归测试阶段可以用同一个模型保证一致性也可以换一个做交叉验证。具体可用模型 ID 以模型对话页面和控制台里的列表为准不要凭记忆写死。你可以先在模型对话里试一段评审记录看它能不能把“三条具体意见”压成“一条可复用规则”再决定用哪个。这里有个容易踩的坑把 Base URL 写成带/v1或结尾斜杠的变体。统一用https://taotoken.net/apiOpenAI 兼容的客户端一般会自动补路径。如果你用 Claude Code 或 Codex 这类宿主配置项名称不同但三件套不变Base URL、API Key、Model ID。缺任何一个都会在调用时报错后面第 5 节会对照真实报错讲。3. 可复制配置Skill 目录结构与蒸馏模板这一节给可直接复制的配置。先定目录结构OLLEAGUE.SKILL 的 Skill 包建议这样组织skill/ ├── SKILL.md ├── work.md ├── persona.md ├── work_skill.md ├── persona_skill.md ├── manifest.json └── meta.jsonwork.md和persona.md是可编辑源文件分别保存能力轨和有界行为轨SKILL.md是 Agent 完整入口work_skill.md和persona_skill.md是仅调用能力或仅调用行为的入口manifest.json管安装分发meta.json管版本和来源。蒸馏模板我建议固定成三段式喂给模型时直接套你是知识蒸馏器。输入是某位专家的活动痕迹片段。 请输出两部分 A. 能力轨把具体案例提炼成可复用的判断规则格式为“触发条件 - 检查项 - 决策”。 B. 行为轨提炼表达与互动约束格式为“场景 - 应做 - 不应做”。 约束 1. 每条规则必须能追溯到输入中的至少一处证据 2. 不要模仿语气不要声称是本人 3. 信息不足时标注“不确定”不要编造。work.md的产物长这样# 工作能力 ## API 评审流程 1. 检查向后兼容性。 2. 检查字段语义是否变化。 3. 检查是否提供迁移方案。 4. 检查失败后能否回滚。 ## 决策启发式 - 公共接口变更优先考虑已有调用方。 - 高风险变更必须提供回滚方案。 - 信息不足时不应直接批准上线。persona.md的产物# 有界行为规则 ## 表达方式 - 先指出最高风险再解释细节。 - 使用直接、简洁的语言。 ## 互动规则 - 反对方案时必须说明理由。 - 不确定时明确标注不确定性。manifest.json要写全入口和兼容运行时{ name: wang-api-reviewer, artifacts: [SKILL.md, work.md, persona.md, work_skill.md, persona_skill.md], entrypoints: { full: SKILL.md, work_only: work_skill.md, persona_only: persona_skill.md }, compatible_runtimes: [Codex, Claude Code], commands: [/review-api] }meta.json管生命周期{ schema_version: 3, preset: colleague, source_context: authorized workplace materials, lifecycle: { version: 3, correction_count: 2, updated_at: 2026-08-16 }, provenance: { source_types: [design_docs, code_reviews, incident_reports] } }如果你用 Codexauth.json里要写全三件套缺一不可{ base_url: https://taotoken.net/api, api_key: sk-你的key, model: 你的模型ID }Cline MCP 或 CC Switch 场景同理配置项名字不同但 Base URL、Key、Model ID 三件套必须齐全。把上面这些文件放进skill/目录蒸馏流水线的输入输出就固定下来了。4. 验证请求跑通生成与回归测试脚本配置齐了要验证。先写一个最小生成脚本把痕迹片段喂给模型产出 work.md 和 persona.md。用 Python 举例走 OpenAI 兼容接口import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) DISTILL_PROMPT 你是知识蒸馏器。输入是专家的活动痕迹片段。 请输出两部分 A. 能力轨把具体案例提炼成可复用的判断规则格式为“触发条件 - 检查项 - 决策”。 B. 行为轨提炼表达与互动约束格式为“场景 - 应做 - 不应做”。 约束每条规则必须能追溯到输入证据不要模仿语气信息不足标注不确定。 def distill(traces: str) - str: resp client.chat.completions.create( modelos.environ.get(TAOTOKEN_MODEL, 你的模型ID), messages[ {role: system, content: DISTILL_PROMPT}, {role: user, content: traces}, ], temperature0.2, ) return resp.choices[0].message.content if __name__ __main__: sample 评审意见1这个接口修改后无法向后兼容。 评审意见2字段一旦被外部依赖就不能随意改变语义。 评审意见3涉及公共接口时必须提供迁移方案。 print(distill(sample))跑之前确认环境变量export TAOTOKEN_MODEL你的模型ID python distill.py成功的话你会看到模型把三条具体意见压成类似“审查公共 API 变更时检查向后兼容性、字段语义稳定性以及迁移方案”的规则。这就是能力轨的雏形。接着写回归测试脚本验证 Skill 包可复现。思路是准备一组固定问题每次生成新版本后跑一遍比对关键判断是否稳定import json CASES [ {input: 把用户表的 phone 字段类型从 varchar 改成 int, expect_contains: [兼容, 迁移]}, {input: 给内部接口新增一个可选参数, expect_contains: [兼容]}, ] def run_regression(skill_text: str) - dict: passed, failed 0, 0 for case in CASES: answer call_with_skill(skill_text, case[input]) if all(k in answer for k in case[expect_contains]): passed 1 else: failed 1 return {passed: passed, failed: failed} def call_with_skill(skill_text: str, user_input: str) - str: resp client.chat.completions.create( modelos.environ[TAOTOKEN_MODEL], messages[ {role: system, content: skill_text}, {role: user, content: user_input}, ], temperature0.1, ) return resp.choices[0].message.content if __name__ __main__: with open(skill/SKILL.md, encodingutf-8) as f: skill_text f.read() print(json.dumps(run_regression(skill_text), ensure_asciiFalse))实测下来回归用例不用多5 到 10 条覆盖高频判断就够。关键是每次改 work.md 后都跑一遍把结果记进 meta.json 的 correction_count 和 version这样 Skill 才可迭代、可回滚。5. 本篇常见错排查401、local proxy failed 与 reading choices蒸馏流程跑不通多数卡在调用层。下面按真实报错对照排查。401 Unauthorized。最常见原因是 Key 没读到或写错。检查echo $TAOTOKEN_API_KEY是否有值脚本里是否用了os.environ而不是硬编码。如果你在 Codex 的auth.json里配置确认api_key字段名正确且没有多余空格。还有一种情况是 Key 被撤销或过期去 API Keys 页面重新生成一个。local proxy failed / connection refused。这类报错通常指向 Base URL 或本地网络配置。先确认TAOTOKEN_BASE_URL是https://taotoken.net/api不要带/v1或结尾斜杠。如果你在本地起了转发工具检查端口是否和配置一致。注意不要使用任何非官方的网络中转方式统一走官方 API 地址最稳。reading choices of undefined。这个报错说明响应结构里没有choices通常是请求根本没成功返回的是错误对象。打印完整响应体看error.messageresp client.chat.completions.create(...) print(resp.model_dump())常见原因是 Model ID 写错。模型 ID 必须和控制台或模型对话页面里列出的完全一致大小写、连字符都不能差。另一个原因是 messages 格式不对比如 system 和 user 角色写反或缺失。OAuth / 认证失败。如果你用 Claude Code 或类似宿主报 OAuth 相关错误说明宿主自己的认证层没配好。这时候不要混用宿主的登录态和 API Key明确用 Base URL Key Model ID 三件套覆盖。CC Switch 场景下检查切换的配置项是否完整Cline MCP 场景下检查 MCP server 的环境变量是否传进去了。生成结果不稳定。同一段痕迹两次生成规则不一样先把 temperature 降到 0.1 到 0.2再固定模型 ID。如果还飘说明输入痕迹太杂先做证据整理和范围约束把私人内容、无关聊天剔除再喂给蒸馏模板。排障时建议按“Key - Base URL - Model ID - 请求体”的顺序查一层层排除比乱改代码快。6. 把 Skill 用起来从生成到长期迭代Skill 包生成完接下来是接入和迭代。如果你只是验证模型能不能完成蒸馏去模型对话页面手动试几轮最快改模板、换模型都直观。如果你要把这套流程固化到项目里长期跑尤其是团队多人协作、需要版本管理和回归测试走 Coding Plan 更合适调用配额和项目管理都更清晰。接入文档里有各宿主的具体配置示例包括 Claude Code、Codex、Cline MCP 的完整字段。建议先照着文档把三件套配好再跑第 4 节的验证脚本。生成新版本后把 work.md 的改动、回归测试结果、correction_count 一起更新到 meta.json这样每次迭代都有记录出问题能回滚到上一个版本。一个实用技巧把蒸馏模板和回归用例一起放进 GitSkill 包目录也纳入版本控制。每次专家给了新反馈先改 work.md 或 persona.md再跑回归通过了才升 version。这样“老王是怎么判断的”就不再只存在他脑子里而是变成可检查、可调用、可迭代的文件。