1. 为什么你的虚拟人总是“答不上来”很多开发者把代码仓库交给 AI 助手时会遇到一个尴尬场景问它“这个项目的鉴权逻辑在哪”它要么泛泛而谈要么直接编一个不存在的文件路径。原因不复杂——通用模型只见过公开语料没见过你仓库里的internal/auth/session.go更不知道你们团队为什么在 2023 年把 JWT 换成了 session cookie。Git 仓库蒸馏术要解决的就是这件事把仓库里的代码、提交历史、架构文档、ADR 决策记录压缩成一组结构化的“蒸馏产物”再注入到 OpenClaw 虚拟人的 memory 与 skills 里。虚拟人不是重新训练一个模型而是通过 persona人格、memory记忆、skills技能三要素把项目知识变成可检索、可触发的能力。这一篇是系列里的“临门一脚”。前面已经完成了蒸馏仓库 → 知识产物和虚拟人机制persona/memory/skills 三要素的铺垫现在要把两者接起来。适合谁看手上已经有至少一个活跃代码仓库想让虚拟人准确回答仓库内技术细节的开发者。读完之后你能拿到一套可复现的目录结构、注入脚本骨架以及一次真实的验证对话。我试过把一套 8 万行的 Go 微服务仓库蒸馏后注入虚拟人问它“订单超时补偿的定时任务在哪个包”它直接给出了internal/order/compensate/cron.go并解释了触发周期。下面把完整链路拆开讲。2. 蒸馏产物与 OpenClaw 虚拟人的映射关系2.1 八类产物对应三要素蒸馏阶段产出的知识产物不是随便堆进虚拟人的它们有明确的映射目标。文档类产物进 memory能力类产物进 skills图谱类产物作为机器可读的关系数据单独存放。蒸馏产物来源阶段映射目标说明仓库画像仓库扫描memory/project.md项目概览、技术栈、模块划分演进报告提交历史分析memory/history.md演进脉络、关键重构节点架构文档依赖与调用分析memory/architecture.md分层结构、核心链路知识摘要代码语义提取memory/knowledge.md核心概念、领域术语模式库代码模式挖掘skills/analyze.md模式识别能力决策记录ADR/注释提取memory/decisions.md技术选型与权衡知识图谱实体关系抽取memory/graph.json关系网络工具链方案构建脚本分析skills/run.md执行分析能力2.2 映射不是复制粘贴这里有个容易踩的坑直接把蒸馏出的 Markdown 原样丢进 memory 目录虚拟人检索时会被大段无关内容干扰。映射的本质是结构化转化——文档类产物要按 memory 的格式重排加上标题层级和索引锚点模式/工具类产物要转成“可执行的能力定义”而不是静态知识图谱类产物要保证 JSON 结构完整否则关联查询会断链。注意memory 文件不是越大越好。单个 memory 文件建议控制在 2000 行以内超出后检索命中率会下降应该拆成多个主题文件。3. 前置准备TaoToken 接入与目录初始化3.1 为什么需要 TaoTokenOpenClaw 虚拟人在回答问题时底层仍然要调用大模型来完成语义理解和生成。TaoToken 提供统一的模型接入层你不需要为每个模型单独维护一套鉴权逻辑。它的 API 地址是https://taotoken.net/api兼容主流模型调用格式虚拟人的 memory 检索结果会作为上下文拼进请求里。适合谁用已经在做 Agent、虚拟人、知识注入类项目需要稳定模型调用但不想被单一供应商绑定的开发者。拿到 API Key 之后OpenClaw 的模型配置指向 TaoToken 即可。3.2 获取 API Key 与初始化目录先到控制台创建 API Key然后初始化虚拟人目录结构。假设你的仓库叫order-service虚拟人命名为repo-guru# 创建虚拟人目录骨架 mkdir -p .openclaw/personas/repo-guru/{memory,skills} mkdir -p output # 蒸馏产物输出目录 # 目录结构确认 tree .openclaw/personas/repo-guru/ # .openclaw/personas/repo-guru/ # ├── memory/ # └── skills/API Key 建议通过环境变量注入不要硬编码进配置文件export TAOTOKEN_API_KEY你的_API_Key提示如果你还没有 Key可以到 TaoToken 控制台的 API Keys 页面创建接入文档里有完整的鉴权说明。4. 可复制配置注入脚本与技能绑定4.1 memory 注入脚本这个脚本把蒸馏产物按映射关系注入 memory 目录处理目录合并和 JSON 单独拷贝两种情况#!/usr/bin/env python3 # scripts/inject_memory.py # 将蒸馏产物注入虚拟人 memory import json import os import shutil def inject_memory(distill_dir, memory_dir): 将蒸馏产物注入 memory 目录 os.makedirs(memory_dir, exist_okTrue) # 产物 → memory 文件映射 mapping { repo-profile.md: project.md, # 仓库画像 → 项目概览 evolution-report.md: history.md, # 演进报告 → 演进脉络 architecture.md: architecture.md, # 架构文档 → 架构知识 knowledge-summary.md: knowledge.md, # 知识摘要 → 核心知识 adr/: decisions.md, # 决策记录 → 决策知识 } for src, dst in mapping.items(): src_path os.path.join(distill_dir, src) if os.path.isdir(src_path): merge_dir_to_file(src_path, os.path.join(memory_dir, dst)) elif os.path.exists(src_path): shutil.copy(src_path, os.path.join(memory_dir, dst)) print(f注入: {src} → {dst}) # 知识图谱单独处理JSON 格式 graph_src os.path.join(distill_dir, knowledge-graph.json) if os.path.exists(graph_src): shutil.copy(graph_src, os.path.join(memory_dir, graph.json)) print(注入: knowledge-graph.json → graph.json) def merge_dir_to_file(src_dir, dst_file): 将目录下多个文件合并为一个 memory 文件 with open(dst_file, w, encodingutf-8) as out: for fname in sorted(os.listdir(src_dir)): fpath os.path.join(src_dir, fname) if fname.endswith(.md): with open(fpath, encodingutf-8) as f: out.write(f.read() \n\n) print(f合并注入: {src_dir} → {dst_file}) if __name__ __main__: inject_memory(output/, .openclaw/personas/repo-guru/memory/)运行后 memory 目录结构如下.openclaw/personas/repo-guru/memory/ ├── project.md # 来自仓库画像 ├── history.md # 来自演进报告 ├── architecture.md # 来自架构文档 ├── knowledge.md # 来自知识摘要 ├── decisions.md # 来自 ADR 合并 └── graph.json # 来自知识图谱4.2 技能绑定配置技能不是文档而是“能力”。绑定分三步能力定义 → 触发规则 → 执行步骤。下面两个 YAML 分别对应模式分析和工具链执行# .openclaw/personas/repo-guru/skills/analyze.yaml # 技能代码模式分析来自模式库 name: analyze description: 分析代码是否符合项目既有模式 trigger: - 用户询问这段代码符合项目模式吗 - 用户询问应该用哪种模式实现 steps: - 从 memory/patterns.md 加载模式库 - 解析用户提供的代码片段 - 与模式库逐条比对 - 输出匹配的模式 差异说明 - 引用模式文档来源# .openclaw/personas/repo-guru/skills/run.yaml # 技能执行蒸馏分析来自工具链 name: run description: 对仓库执行蒸馏分析生成最新知识 trigger: - 用户询问仓库最近有什么变化 - 用户要求重新分析仓库 steps: - 调用蒸馏工具链make all - 读取最新产物 - 更新 memory 中对应文件 - 汇报更新内容4.3 技能绑定脚本如果模式库和工具链是目录形式用脚本批量生成技能配置#!/usr/bin/env python3 # scripts/bind_skills.py # 将模式库/工具链绑定为虚拟人技能 import os def bind_skills(distill_dir, skills_dir): 将蒸馏产物绑定为虚拟人技能 os.makedirs(skills_dir, exist_okTrue) patterns os.path.join(distill_dir, patterns/) if os.path.isdir(patterns): skill { name: analyze, description: 分析代码是否符合项目既有模式, trigger: [模式匹配, 代码审查], source: patterns/, steps: [加载模式库, 比对代码, 输出结果] } write_skill(skills_dir, analyze.yaml, skill) print(绑定技能: patterns/ → analyze) toolchain os.path.join(distill_dir, toolchain/) if os.path.isdir(toolchain): skill { name: run, description: 执行蒸馏分析更新知识, trigger: [重新分析, 仓库变化], source: toolchain/, steps: [执行工具链, 读取产物, 更新 memory] } write_skill(skills_dir, run.yaml, skill) print(绑定技能: toolchain/ → run) def write_skill(skills_dir, fname, skill): 写入技能配置YAML 格式 with open(os.path.join(skills_dir, fname), w, encodingutf-8) as f: for key, val in skill.items(): if isinstance(val, list): f.write(f{key}:\n) for item in val: f.write(f - {item}\n) else: f.write(f{key}: {val}\n) if __name__ __main__: bind_skills(output/, .openclaw/personas/repo-guru/skills/)4.4 完整配置结构注入和绑定完成后虚拟人配置长这样.openclaw/personas/repo-guru/ ├── persona.yaml # 人格来自项目定位 ├── memory/ # 记忆来自蒸馏产物 │ ├── project.md │ ├── history.md │ ├── architecture.md │ ├── knowledge.md │ ├── decisions.md │ └── graph.json └── skills/ # 技能来自模式库/工具链 ├── analyze.yaml └── run.yaml5. 验证请求一次可复现的对话5.1 配置完整性检查注入完成后先做静态检查确认目录和 YAML 语法没问题# 1. 验证目录完整性 tree .openclaw/personas/repo-guru/ # 2. 验证 YAML 语法 python -c import yaml, glob for f in glob.glob(.openclaw/**/*.yaml, recursiveTrue): yaml.safe_load(open(f)) print(fOK: {f}) # 3. 验证 memory 非空 find .openclaw/personas/repo-guru/memory/ -name *.md -size 0 | wc -l5.2 端到端对话验证用 OpenClaw 的 ask 命令发起真实提问观察虚拟人是否命中 memory 内容# 架构类问题应命中 architecture.md openclaw ask 项目架构是怎样的 # 模式类问题应触发 analyze 技能 openclaw ask 这段代码符合项目模式吗 # 演进类问题应命中 history.md openclaw ask 订单模块最近一次重构改了什么一次成功的验证对话应该具备三个特征回答里出现仓库内真实存在的文件路径或包名回答引用了 memory 中的具体内容而非泛泛而谈技能类问题触发了对应的 skills 配置。如果问“订单超时补偿的定时任务在哪个包”理想回答是internal/order/compensate/cron.go并说明触发周期来自decisions.md里的 ADR 记录。5.3 模型调用配置虚拟人底层调用模型时把 TaoToken 作为接入点。在 OpenClaw 的模型配置里指定 API 地址和 Key# .openclaw/config.yaml model: provider: taotoken base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY} model: claude-sonnet-4-20250514提示模型对话页面可以直接测试同一套 memory 上下文下的回答效果方便对比不同模型的检索命中率。6. 本篇常见错排查注入链路里最容易出问题的不是脚本本身而是产物格式和触发规则。下面这张表覆盖了大部分报错场景问题原因排查方法虚拟人回答“不知道”memory 未注入或格式错误检查 memory 文件是否非空、Markdown 标题层级是否规范虚拟人回答不准确知识图谱关联缺失检查 graph.json 是否完整、实体 ID 是否与 memory 对应技能不触发trigger 规则不匹配检查 skills 的 trigger 关键词是否覆盖用户实际问法回答风格不对persona 配置未生效检查 persona.yaml 是否被正确加载、路径是否写错注入脚本报 FileNotFound蒸馏产物目录名不一致确认 output/ 下产物文件名与 mapping 键完全一致YAML 解析失败缩进用了 TabYAML 只允许空格缩进统一用 2 空格如果技能不触发最直接的办法是把 trigger 关键词放宽比如把“模式匹配”改成“模式”“规范”“符合”三个词覆盖更多问法。如果 memory 检索命中率低检查单个文件是否超过 2000 行超了就按主题拆分。7. 下一步让虚拟人真正跑起来到这里蒸馏产物已经完成了到虚拟人能力的转化。映射关系清晰了注入脚本能跑了技能配置也绑定了验证对话能准确回答仓库内技术细节。接下来要做的是把虚拟人放进真实工作流——代码审查时让它比对模式库新人入职时让它回答架构问题重构前让它调出历史决策记录。如果你在接入过程中遇到模型调用报错先到 API Keys 页面确认 Key 状态再对照接入文档检查 base_url 和鉴权头。需要长期跑编码类 Agent 任务的话Coding Plan 的额度模型更适合高频调用场景。验证模型回答效果可以直接在模型对话里试不用每次都跑完整注入流程。