1. 从手工填 Word 到 /learn 沉淀 RD 技能研发文档自动化的真实痛点如果你所在团队每年都要申报研发项目RD大概率经历过这样的场景一份固定格式的 Word 表格从「立项目的」到「核心技术」再到「创新点」每个格子都要手写写完还要反复调整排版。项目一多文档就成了纯体力活。更麻烦的是这些内容其实高度重复——同一个技术方向换个项目名、换段时间、换批研发人员核心逻辑几乎一样但每次都得从头敲一遍。Hermes 的/learn命令解决的正是这个问题。它能把你手头任意来源的资料——一个目录、一个 URL、一段笔记甚至你刚刚在终端里跑完的整套工作流——蒸馏成一份标准化的 Hermes 技能Skill也就是一份符合SKILL.md规范的结构化文档。之后每次需要写 RD 文档时加载这个技能Hermes 就会按你沉淀好的模板和章节顺序自动分析代码仓库、归纳技术点、生成文档。这篇文章面向两类人一是被 RD 申报文档反复折磨的研发同学二是想把团队重复性文档工作交给可复用技能流程的技术负责人。我会从零梳理/learn的学习路径给出可复制的技能定义配置、调用步骤以及文档生成的验证动作。全程基于真实操作不编造命令不堆砌概念。先说清楚/learn到底能做什么。它本质上是一个「知识蒸馏器」你告诉它学什么它调用自身工具去收集材料本地文件用read_file/search_files远程 URL 用web_fetch对话中的工作流靠 agent 记忆然后按 Hermes 的SKILL.md规范写出一篇技能文档包含不超过 60 字的描述、标准章节顺序、Hermes 工具调用框架。它不会编造命令所有内容都来自你提供的真实材料。这个命令支持多种输入方式也能在多个入口使用CLI、消息网关Telegram / Discord / Slack 等、TUI以及 Dashboard 的 Skills 页面。对 RD 申报这种有固定格式的重复性工作你只需要让 agent 学习一次 Word 模板或历史文档之后每次申报时加载该技能就能自动生成文档省去大量人工排版和文字工作。我试过用一套历史 RD 文档喂给/learn生成的技能文档结构比我手工整理的还规整。下面把完整流程拆开讲你可以直接跟着做。2. TaoToken 前置准备给 Hermes 接上稳定的模型调用通道在跑/learn之前得先确保 Hermes 能正常调用大模型。Hermes 本身是 agent 框架模型能力需要外部 API 提供。这里我用 TaoToken 作为模型接入层它的 API 地址是https://taotoken.net/api兼容主流模型调用格式配置起来比较直接。为什么单独讲这一步因为/learn在蒸馏技能时需要模型对材料做归纳、提炼、结构化输出对上下文长度和指令遵循能力有要求。如果模型通道不稳定/learn跑到一半断掉生成的技能文档会残缺后面自动写 RD 文档时就会缺章节。所以前置配置值得认真做。你需要准备三样东西Base URL、API Key、Model ID。这三件套在 Hermes 的配置里对应模型提供方的接入参数。Base URL 填https://taotoken.net/apiAPI Key 在控制台的 API Keys 页面创建Model ID 按你实际要用的模型填。先到控制台创建 Key。打开https://taotoken.net/console/api-keys登录后新建一个 API Key复制保存。注意 Key 只在创建时完整显示一次丢了就得重建。然后确认你要用的模型。可以在模型对话页面先试一下目标模型是否可用地址是https://taotoken.net/models。选一个上下文窗口足够大的模型因为 RD 文档分析往往要读整个代码仓库的多个文件。配置写到哪里Hermes 的模型配置通常在项目根目录的配置文件里或者通过环境变量注入。以常见的settings风格配置为例你需要把三件套填进去{ model_provider: { base_url: https://taotoken.net/api, api_key: sk-你的Key, model_id: 你的模型ID } }如果你用的是 TOML 风格的配置对应写法是[model_provider] base_url https://taotoken.net/api api_key sk-你的Key model_id 你的模型ID这里有个容易踩的坑Base URL 末尾不要多加/v1或斜杠按https://taotoken.net/api原样填。有些框架会自动拼接路径多写了反而 404。API Key 不要提交到 Git 仓库用环境变量或本地配置文件并加进.gitignore。配置完成后先做一次最小验证在 Hermes CLI 里发一句简单对话确认模型能正常返回。如果这一步就报错先别急着跑/learn把模型通道修好再说。验证通过后再进入技能学习环节。关于接入的详细参数说明可以看接入文档https://taotoken.net/doc。文档里有不同框架的配置示例对照着改就行。3. 可复制配置用 /learn 把历史 RD 文档蒸馏成技能这一步是核心。你要让 Hermes 学会一套 RD 技能最直接的方式是拿一份真实的历史 RD 文档或 Word 模板喂给它。注意这里的学习材料最好是有真实内容的文档而不是空表格——空表格只能学到格式学不到内容组织方式。假设你有一份历史 RD 文档放在./docs/rd_template.docx或者已经转成 Markdown 放在./docs/rd_history.md。在 Hermes CLI 里执行/learn ./docs/rd_history.md如果你想让它学一整个目录里的多份 RD 文档直接给目录路径/learn ./docs/rd_samples/Hermes 会调用read_file和search_files读取这些文件然后按SKILL.md规范生成技能文档。生成的技能通常落在项目的 skills 目录下比如./skills/rd-doc-writer/SKILL.md。你可以打开检查重点看几个地方第一描述是否在 60 字以内且准确概括了技能用途。第二章节顺序是否和你历史文档一致比如「立项目的 → 核心技术 → 创新点 → 阶段性成果」。第三工具调用框架是否合理比如它是否知道要先分析代码仓库再写文档。如果生成的技能有偏差你可以直接编辑SKILL.md修正然后重新/learn或手动调整。技能文档本身就是 Markdown改起来没有门槛。这里给一份 RD 技能的核心配置片段参考你可以按自己团队的模板调整--- name: rd-doc-writer description: 根据代码仓库和历史RD模板自动生成研发项目申报文档 --- ## 输入要求 - 项目名称与活动名称 - 源代码仓库路径 - 起止时间 - 研发人员名单 - 阶段性成果描述 ## 生成步骤 1. 读取仓库目录结构识别核心模块 2. 分析关键源文件归纳技术实现 3. 按模板章节顺序组织内容 4. 输出 Markdown 文件到指定路径 ## 章节模板 ### 立项目的 ### 核心技术 ### 创新点 ### 阶段性成果这份配置的关键在于「生成步骤」和「章节模板」两部分。步骤决定了 Hermes 分析代码的顺序模板决定了最终文档的结构。你可以在/learn生成的基础上把团队特有的字段补进去比如「项目编号」「验收指标」等。还有一个实用技巧如果你希望技能能处理多种 RD 类型比如 rd01、rd02 对应不同申报类别可以在技能里定义多个模板分支或者干脆建多个技能用不同名字区分。/learn支持你反复学习、迭代技能不必一次到位。技能生成后建议做一次「干跑」验证让 Hermes 用这个技能处理一个你已经写过的旧项目对比它生成的文档和你手工写的差异。如果结构对得上、技术点没漏说明技能可用。如果漏了关键章节回到SKILL.md补上对应步骤。4. 验证请求与成功结果驱动技能自动编写新 RD 文档技能准备好后就可以让它自动写新文档了。假设你最近开发了一个地址匹配服务代码在./ai/address_matching需要写一份 rd01 文档。在 Hermes chat 里你只需要给出关键信息剩下的交给技能。实际操作时对话大概是这样hermes chat然后在对话里输入我要写一个rd01保存文件到 ./mywiki/design/rdip/rd01.md 活动名称地址匹配服务技术研究与应用 先写一个rd01.md文件吧 这个项目的源代码和文档仓库是 ./ai/address_matching 对这个仓库里所有源代码和目录进行分析、归纳总结 然后根据rd模版来编写立项目的、核心技术、创新点 起止时间2026-01-01 ~ 2026-03-31 研发人员XXX 取得的阶段性成果在XXXXX分析系统中使用了本技术提供的服务很好地解决了用户各种地址格式识别和匹配Hermes 会加载你之前/learn生成的 RD 技能按技能里定义的步骤先读取./ai/address_matching的目录结构和关键源文件归纳出地址匹配的核心技术点再套用模板章节生成./mywiki/design/rdip/rd01.md。生成完成后打开文件检查。一份合格的输出应该包含立项目的里说清楚了地址匹配要解决什么问题用户输入地址格式五花八门、不合格核心技术里描述了匹配算法或服务架构创新点里点出了和现有方案的差异阶段性成果里对应了你给的实际应用场景。如果结果不理想常见原因是技能里的「生成步骤」不够具体。比如它可能只读了目录没读源文件导致技术点空泛。这时候回到SKILL.md把步骤改成「读取 src 目录下所有 .py 文件提取类名和函数注释」这类明确指令再重新生成。验证成功的标志是生成的文档你只需要微调措辞不需要重写结构。我实测下来基于真实代码仓库生成的 RD 文档在技术描述上比手工写的更完整因为它不会漏掉代码里实际存在的模块。这里还要提一个方法论AI coding 尽量不要用 vibing coding 那种口水化的方式全程编程。vibing coding 做做事后小 bugfix 还可以大规模功能实现一定要用 spec coding预先写好功能细节描述和实现细节规定。当你在usecase.md里留下了丰富的文本内容之后用 AI 自动处理文档就方便得多因为它是基于真实数据的。RD 文档、IP 相关文档都是这个逻辑——输入越结构化输出越可靠。5. 本篇常见错排查401、local proxy failed、reading choices 与 OAuth 报错跑/learn和自动写文档的过程中有几类报错出现频率很高。这里按真实报错信息对照排查帮你快速定位。401 Unauthorized。这个最常见基本是 API Key 问题。检查三处Key 是否复制完整有没有漏字符、Key 是否已过期或被删除、配置里api_key字段有没有写错位置。如果你用的是环境变量确认变量名和代码里读取的一致。还有一种情况是 Base URL 填错比如填成了https://taotoken.net/api/v1导致请求路径不对也会返回 401 或 404。按https://taotoken.net/api原样填。local proxy failed。这个报错通常出现在网络层说明请求没发出去。先确认你的网络能正常访问 API 地址可以用curl测一下连通性。如果是在公司内网检查是否有防火墙拦截。注意这里不要引入任何网络代理工具直接用正常网络环境测试即可。如果curl能通但 Hermes 报这个错检查 Hermes 的配置文件里有没有残留的旧代理设置清掉再试。reading choices 相关报错。这类错误一般出现在模型返回结构不符合预期时比如返回体里没有choices字段。原因可能是模型 ID 填错了请求发到了不支持的模型上也可能是 API 返回了错误信息但被框架当成正常响应解析。排查方法先用模型对话页面单独测一下你配置的 Model ID 是否能正常返回地址https://taotoken.net/models。如果那边正常问题就在 Hermes 的解析配置上检查是否有自定义的响应解析逻辑。OAuth 相关报错。如果你用的是需要 OAuth 授权的接入方式报错通常和 token 刷新有关。检查授权是否过期重新走一遍授权流程。如果你用的是 API Key 方式一般不会遇到 OAuth 报错如果遇到了说明配置里混入了 OAuth 相关字段把它移除统一用 API Key。还有一个非报错但很常见的问题/learn生成的技能文档章节缺失。这不是报错但结果不可用。原因是学习材料本身结构不清晰或者材料太长超出了模型上下文。解决办法是把历史文档拆成更小的片段分批/learn或者手动在SKILL.md里补齐章节模板。排查时记住一个原则先验证模型通道用最小请求测再验证技能生成看SKILL.md最后验证文档输出看生成文件。逐层定位不要一上来就改一堆配置。6. 把 RD 文档工作交给可复用技能接入与长期使用建议走到这里你已经完成了从/learn学习 RD 技能到自动生成文档的完整闭环。回顾一下关键动作用历史 RD 文档喂给/learn生成技能检查并修正SKILL.md然后在 chat 里给出项目信息驱动技能自动写文档最后验证输出质量。如果你打算把这个流程长期用起来有几个建议。第一把SKILL.md纳入版本管理团队共享。每次 RD 模板有变化更新技能文档并重新/learn保证所有人用的是同一套标准。第二把常用的项目信息做成模板片段比如起止时间、研发人员名单减少每次对话的重复输入。第三对生成的文档做抽样人工复核尤其是创新点和阶段性成果部分确保没有夸大或失实。对于需要长期跑编码和 Agent 任务的团队可以考虑用 Coding Plan 来获得更稳定的调用额度地址是https://taotoken.net/coding-plan。如果只是偶尔生成文档按量使用 API 就够了。接入配置和 API Key 管理分别看这两个入口接入文档https://taotoken.net/docAPI Keyshttps://taotoken.net/console/api-keys。模型选择可以先在模型对话页面试https://taotoken.net/models。最后说一个实操细节/learn学到的技能是可以复用的不止用于 RD 文档。你完全可以用同样的方法把 IP 文档、技术方案、验收报告等重复性文档工作都沉淀成技能。核心逻辑是一样的——找到一份高质量的历史样本让 Hermes 学一次之后每次调用技能自动生成。省下来的时间留给真正需要创造力的工作。