很多人以为在 Obsidian 里做图文写作只要把素材丢给 AI、让它“看着办”就行。但当你真正把流程跑起来会发现最烧钱的不是 AI 的创意而是那些不断堆叠的历史上下文。我最近把原来一套基于 Workflow 编排的写作流水线整个改造成了 Skill 驱动的模式单篇图文卡片的 Token 消耗从平均 2.8 万左右降到了 8 千出头算下来成本直接降了 70%。这篇就把我的改造思路、实测数据和踩过的坑一次性说清楚给也在 Obsidian 里折腾 AI 写作的朋友一个参考。1. 从Workflow到Skill我为什么在Obsidian里做这场减法先说明一下背景。我日常在 Obsidian 里做图文写作主要产出的是那种“一张图配一段观点”的卡片式内容以及小篇幅的科普短文。之前为了保证输出稳定我搭过一版非常完整的 Workflow 编排素材收集、主题拆解、文案初稿、配图建议、风格润色每一步都串成流水线。当时觉得这样才是“工业化生产”结果月底一拉账单人傻了。1.1 我原本的 Workflow 编排长什么样这套 Workflow 的逻辑很直白就是让 AI 按固定顺序走完五道工序。每一道工序完成之后下一道工序会把前面所有产出和历史对话记录一起当作输入继续往下做。以我写一篇“某工具使用技巧”的图文卡片为例当时的流程是这样的第一步导入三条原始素材链接和两段笔记摘录第二步让 AI 提炼核心观点第三步要求 AI 生成 200 字左右的文案初稿第四步请 AI 给配图建议第五步做最后的风格统一和排版优化。单看每一步好像都没问题。问题出在第二步到第五步之间每一步的请求里都背着前一步的完整历史甚至包括我们中途删掉的一句话、改过的一个词。等到第五步跑完AI 已经把从原始素材到初稿再到修改意见的整段上下文反复读了好几遍。1.2 头疼的账单Token到底被谁吃掉了我截了一份当时的调用记录以一篇 800 字左右的图文卡片为样本工序输入 Token 量说明第一步6200原始素材 拆解指令第二步8900携带第一步全部历史第三步11500继续携带前两步历史第四步13700上下文进一步膨胀第五步16200全链路历史 润色要求合计约 5.65 万产出仅约 2000 Token可以看到真正用于“干活”的 Token 占比其实很少大头全花在反复搬运旧内容上。而我用的是按量计费的模型接口五步跑下来单篇成本比预期高了好几倍。这个数字让我开始怀疑 Workflow 这种“逐步推进”的模式是否真的适合高频、小体量的创作场景。1.3 转变的契机一次偶然的 Skill 尝试真正促使我动手改的是一次偶然的测试。那时我正在研究 Obsidian 里的 Skill 类插件——稍微解释一下这里的 Skill 和 Workflow 不同它本质上是一个“能力封装包”把固定套路、提示词模板、参数约束都写在配置里调用的时候只需要告诉 AI 当前这一篇的核心目标它就能直接给出成稿而不需要把过去的每一步对话都重新复述一遍。我当时抱着试一试的心态把“图文卡片写作”从 Workflow 里抽出来做成了一个只有一份 YAML 配置加一条触发指令的 Skill。结果第一轮测试就跑出了让我眼前一亮的数字整篇文案从开始到结束输入 Token 不到之前五步流水线的三分之一而稿子的质量并没有明显下滑。从那之后我开始系统性地做替换把能 Skill 化的场景全部 Skill 化Workflow 只保留给那些真的需要分阶段确认的复杂任务。下个月账单出来之后图文写作这一块的 Token 成本正好降了 70% 左右。2. 对比两种模式的底层消耗逻辑Token差距是怎么拉开的很多朋友第一反应是“Skill 不就是把提示词写长一点吗那上下文不是更长了”这其实是个很大的误解。我一开始也是这么想的直到我真正对比了两套结构的调用记录才搞明白 Skill 省钱省在哪儿。2.1 Workflow是流水线搬运Skill是肌肉记忆用生活化的比喻来解释Workflow 像一条流水线每一道工序的工人都要重新看一遍前一道工序的全部文件甚至包括废纸篓里的草稿。Skill 则像给一个熟手配了一份操作手册——手册一次性放在桌上之后他只需要看你递过来的那一个便签就能判断现在该做什么、怎么做。放到 AI 调用里差异就体现在输入内容的结构上。Workflow 模式下AI 面对的是“一段连续的多轮对话”每一轮都包含之前所有的消息。Skill 模式下AI 面对的是“技能定义 当前任务描述”技能定义本身是固定不变的不管这篇要写什么它的长度都恒定不会随着调用次数增长。我实测对比过同一个文案任务两种模式首轮请求的 Prompt 大小差距大约在 4.5 倍。Workflow 因为带着完整链路首轮请求就已经很肥Skill 因为只带固定技能描述和增量信息首轮请求非常“瘦”。2.2 长上下文场景下的Token计量规则这里必须说一个很多人忽略的细节大多数按量计费的模型接口输入 Token 是按照请求里的全部文本计算的而且多轮对话中过往轮次的内容也会被反复计入。也就是说你聊得越长、轮次越多后面每一轮的“搬运费”就越高。Skill 模式之所以能降本不是因为它压缩了模型能力而是因为它把“可变成本”压到了最低。技能定义那几百个 Token 是固定成本每次调用都在但它是高度结构化的没有冗余真正浮动的只有你当前输入的那一小段任务描述。这样每轮请求就都维持在一个很经济的规模上不会像 Workflow 那样层层加码。2.3 关键结论压缩的是“上下文冗余”不是“能力”做这个对比还有个意外收获我意识到 Workflow 里的大量中间步骤其实是在“重复表达同一个意图”。比如“风格统一”“语气自然”这些话在每道工序里都出现了一遍。Skill 把这些约束写死在配置里AI 每次都能看到但只看到一个副本而不是五份。所以 Skill 化真正的核心价值在于把固定的、重复的、可以模板化的内容从对话流里抽出去单独做成能力定义把变化的、具体的、每篇不同的内容留在对话里。这样一来Token 消耗和内容复杂度就真正实现了解耦。这也就是为什么我能做到“素材变多、产出变长但成本基本不变”。3. 实操把图文写作Skill从0到1搭起来理论部分讲完了直接上干货。如果你也想在 Obsidian 里做类似的改造下面是我踩平了路之后总结出来的完整步骤。我假设你已经装好了 Skill 类插件也有一台能正常调用模型接口的环境。3.1 先建目录和配置文件Skill 插件的目录结构不复杂核心就是“一个 Skill 一个文件夹里面至少有两个文件配置文件和技能正文”。配置文件通常用 YAML 格式后缀是.yaml或.yml。我习惯这样组织目录名skills/ copy-card-writer/ skill.yaml prompt.mdskill.yaml存放技能的元信息比如名称、描述、触发词、参数定义、模型设置prompt.md存放具体的技能正文也就是每次触发时会被加载进上下文的那段固定指令。有一点要提醒配置文件的编码一定用 UTF-8别用 GBK 之类的本地编码否则插件在匹配触发词的时候很容易出现乱码、匹配失败这类问题。我遇到过好几次 Skill 死活不触发最后发现是文件编码不对。3.2 完整示例一个图文写作Skill的YAML配置下面是我现在正在用的一份精简示例你可以直接复制改写name: copy-card-writer description: 用于将素材改写成带观点的图文卡片文案。输入素材片段输出 150-300 字的正文建议。 triggers: - 图文卡片 - 写卡片 - 卡片文案 model: default variables: max_length: 300 tone: natural has_image_advice: true prompt_file: prompt.md我在prompt.md里写的正文大概是这样只摘录核心结构你是一名图文卡片文案撰写专家。请根据用户提供的素材完成以下任务 1. 提取核心观点不要复述素材原文 2. 用口语化、有信息增量的方式写成 150-300 字正文 3. 如果素材不足请明确指出缺失信息不要编造 4. 在文案末尾以“配图建议”为前缀给出一条构图建议。 始终使用简体中文输出。这里最关键的是description字段。别小看这一句话Skill 插件在触发匹配时很大程度靠它决定是否把当前任务路由给这个 Skill。描述写得越精准误触发的概率越低描述写得越笼统AI 就越容易把不相关的任务也塞给这个 Skill导致输出质量下降然后你还得反复纠正Token 又烧回去了。3.3 在Obsidian里触发Skill的三种方式Skill 配置好之后接下来就是怎么调用的问题。目前主流 Skill 插件至少支持三种触发方式斜杠命令在输入框打出/输入技能名称或触发词选择后直接调用文本触发在正文里写一句包含触发词的句子AI 自动识别并调用对应 Skill比如我写“请用图文卡片技能处理下面这段素材”它就会命中手动指派从插件面板的技能列表里直接选择某个 Skill再粘贴素材。我个人建议日常写作时优先用第三种——手动指派。原因是图文写作这种场景素材长短不一、结构差异大如果完全依赖自动触发偶尔会把一篇长分析也误判成卡片文案跑出来的结果还得返工。手动指派多一次点击但可控性高很多。另外触发词不要设得太“泛”。比如你设了“写作”俩字当触发词那基本每次对话都会撞上它Skill 反而会变成一种干扰。我后来把所有触发词都改成了带场景特征的词比如“图文卡片”“知识卡片”“短文配图”命中率明显提升。3.4 从Workflow迁移到Skill的具体改写思路如果你已经有了一套 Workflow想迁移到 Skill不要一股脑把整个流程塞进去。我建议按这个顺序来第一步拆分“固定动作”和“当前任务”。固定动作指那些每篇都一样的约束、格式、改写规则当前任务指每篇不同的素材和写作方向。第二步把固定动作写成 Skill 正文尽量用“清单式”表达让 AI 一看就知道该做什么。第三步把当前任务放到调用时的输入内容里。调用格式固定为“[触发词]素材如下……写作方向……。”第四步先跑 5 篇测试样本对比 Skill 模式和原来 Workflow 模式的输出质量与 Token 用量不达标就微调prompt.md。迁移过程中最常见的错误是试图在 Skill 里塞入“多轮交互”。比如要求 AI 先问用户问题、再一步步给出结论。这种事在 Skill 里做很容易把上下文又拉长重新变成 Workflow 的消耗逻辑。Skill 更适合单轮完成的“开箱即用”型任务一旦你的任务需要反复问答那还是老老实实用 Workflow。4. 成本实测70%的降幅是怎么测出来的数据不能只看感觉必须用工具记录。我改造完之后做了一轮很正经的对比测试把同一天内写的十篇图文卡片素材分别用两种模式跑了一遍统计每篇的全部输入 Token 和输出 Token。4.1 同一篇图文素材两种模式各花了多少Token这里拿其中一篇做代表素材是一段 900 字左右的资料摘录加三条补充笔记要求产出一张配图建议和 250 字左右的正文。指标Workflow 模式Skill 模式总输入 Token约 28400约 8300总输出 Token约 2200约 2100输入输出比约 12.9 : 1约 3.95 : 1估算成本基准线约为基准线 31%按这个数据成本降幅刚好在 69% 左右接近标题里说的 70%。注意输出 Token 基本没变也就是说“干活量”是一样的省下来的几乎全部都是输入侧的搬运成本。4.2 模型版本差异下的数据波动这里必须补充一句70% 这个数字不是恒定不变的。它受模型类型、上下文窗口大小、模型供应商计费策略的影响很大。我分别用两家不同的模型接口跑了同一批测试其中一家的多轮对话会重复计算全部历史另一家会对历史做一定程度的缓存压减。结果后者的 Workflow 模式也没有想象中那么贵Skill 模式的降幅就缩到了 50% 左右。所以你在参考我的数据时最好以自己模型接口的实际计费为准。不过有一点是具有普适性的只要你的模型接口按完整请求文本计费那么 Skill 模式因为请求体本身更小、更固定在长期使用上几乎一定比多轮 Workflow 便宜。差距的大小取决于你到底用哪一家的服务。4.3 追踪Token消耗的方法要把这种降本做实光靠“感觉便宜了”是不够的。你得有一套能持续观察 Token 消耗的方法。我目前的做法是每次调用后把模型接口返回的usage字段记录进一个独立的 Markdown 表格每周汇总一次按“输入/输出/单次调用次数”三个维度统计给每个 Skill 建一个单独的统计文件方便对比不同 Skill 的成本表现。这样一旦某个 Skill 的 Token 开始异常上升你能很快定位到是“技能定义写得太啰嗦”还是“调用时塞了太多无关素材”。我有一次发现某篇卡片成本突然翻了倍一查原因是素材里混进了一大段整页复制的网页文本里面全是没用但占 Token 的导航代码和广告词。清理掉之后成本立刻回到正常区间。5. 踩坑实录token失效、403和服务配置问题降本增效的过程不是一帆风顺Skill 化之后我遇到了不少和 token 相关的坑其中有一类特别影响体验调用过程中突然报 token 失效、token 交换失败、甚至 403 错误。这里把排查链路分享出来帮你少走弯路。5.1 token exchange failed / 403 的排查链路有一次我正写一篇长文写了一半让 AI 调用 Skill 做润色结果对话框直接弹出一句token exchange failed: token endpoint returned status 403 forbidden后边还跟着一串 URL 参数。当时以为是网络问题重试了几次还是一样。后来我冷静下来按下面的顺序排查了一遍先看认证服务配置。OAuth 2.0 流程里 token exchange 是拿临时授权码换访问令牌的环节如果应用配置里的回调地址和实际不一致服务端就会拒绝再看 refresh token 是不是过期了。很多服务的 access token 有效期只有一小时左右refresh token 有效期长一些。如果 refresh token 本身失效了客户端就无法静默续期只能重新登录检查系统时间。JWT 续签依赖时间戳校验如果你的设备时间和服务器差太多token 就算没过期也会被服务端判为无效最后检查 API 权限范围。有时你申请的是只读权限却在调用需要写权限的接口服务端也会返回 403。我那次的问题出在 refresh token 上——因为换了台机器用 Obsidian本地的凭据缓存没迁移过去旧 token 已经失效了。重新走了一遍登录授权流程之后就好了。这里建议你不要在设备间直接拷贝插件的缓存文件夹而是重新登录一遍省去一堆诡异的认证错误。5.2 JWT续签与过期策略说到 token 续签Skill 插件里的认证机制一般也和 JWT 脱不开关系。如果你自己搭过服务应该对这套逻辑不陌生客户端拿一个短期 access token 请求接口快过期时再用 refresh token 换取新 access token。我在配置自己的本地测试服务时遇到过一个典型问题换出来的新 token 依然在很短时间内失效。后来查代码发现是签发 JWT 的时候把exp字段设成了秒级时间戳加固定偏移但本地和服务器的时间基准差了五分钟导致新 token 一签发就当下了。如果你也遇到“token 续签了但还是反复失效”的情况优先检查这三点客户端和服务端的时钟是否同步refresh token 是否有轮换逻辑是否在首次使用后立即作废并返回新 refresh tokenJWT 的iat和exp字段是否基于同一时间基准生成。这类问题排查起来确实烦人但基本都能通过仔细读服务端日志定位。5.3 Skill编码冲突193/194/247是怎么回事再聊一个 Obsidian Skill 生态里特有的坑——编码冲突。热词里频繁出现的“skill编码193”“skill编码194”“skill编码247”这些数字其实就是社区在为 Skill 分类时用的编号类似图书馆分类号。我在一次批量安装技能包时发现有个旧版技能编码 193 的画图技能和一个新装的技能编码 194 的文字排版技能在同时触发时会出现互相覆盖的情况。因为它们的触发词里都包含“生成”两个字AI 一时间不知道路由给谁。解决办法不复杂但很容易被忽略安装新技能包之前先查看已有技能的触发词避免撞车真撞了优先修改后装的技能包的触发词尽量不要动正在稳定使用的技能如果技能包之间本身有从属关系比如 247 依赖 193 的能力那你得把被依赖的包放在前面加载或者直接合并成一个更大的技能。这类冲突最大的坏处不是报错而是让输出质量变得不稳定。同一句话今天触发的是画图技能明天触发的是排版技能结果完全不一样。所以定期审查技能列表保持触发词的“唯一性”是每个 Skill 使用者都该养成的习惯。6. 什么场景继续用Workflow什么场景必须上Skill改造完成后我并没有把 Workflow 一棍子打死。经过这段时间的实测我总结了一套自己的判断标准区分哪些情况继续用 Workflow哪些情况坚决用 Skill。6.1 我的判断标准重复度、结构化程度、交互频率判断依据就三条任务是否高频重复、输出是否有稳定结构、是否需要多轮人工确认。判断维度适合 Skill适合 Workflow重复度每周至少使用 3 次以上偶尔使用、每次结构都不同结构化程度输出格式稳定模板清晰输出不可预期需要探索式回答交互频率一次调用直接出结果需要中途多次修改与确认拿我自己的场景举例写图文卡片、给短文配图建议、生成代码片段注释都是典型的高频、结构化任务全换成了 Skill。而那种“我需要你帮我分析这组素材、给三版方案、我再挑一版继续改”的事情就必须保留 Workflow因为它天然需要多轮交互硬塞进 Skill 反而会损失质量。6.2 混合模式Skill内部嵌套轻量步骤还有一个玩法值得推荐——混合模式。Skill 不是只能做“单轮问答”你可以在技能正文里写清晰的分步逻辑让 AI 在单轮里完成多个子步骤。还是以图文卡片为例我的 Skill 里就内嵌了三个连续动作判断素材是否足够支撑观点生成正文生成配图建议。这三个动作不是人工分步发起的而是写在技能正文里让 AI 自己排顺序。这样既保留了 Skill 的成本优势又能处理稍微复杂一点的任务。复杂度和成本之间是可以精细调节的关键看你怎么组织技能正文。6.3 给新人的建议最后给刚开始折腾 Obsidian Skill 的朋友几句实在话。第一不要一上来就追求“全场景 Skill 化”。选一个你最高频、最痛的任务先做出来跑两周把配置、触发、成本统计这一套流程走顺了再复制到其他任务上。第二Skill 不是“越短越好”也不是“越长越好”。关键是描述精准、步骤清晰、约束明确。我看到有人为了省 Token 把技能正文压缩到只剩几个词结果 AI 频繁输出质量不稳定的内容反复返工反而更贵。第三务必给自己做一个“基线数据”。在哪一天、用哪个模型、跑哪类任务、消耗多少 Token全部记录下来。没有基线你根本说不清楚改造到底省了多少钱后面优化也没有参照物。我自己就是从一月中旬开始建表的到现在每个技能的 Token 趋势都清清楚楚。我现在的日常已经变成了打开 Obsidian输入素材选中图文卡片 Skill回车等结果。不会再被 Workflow 那套哗啦啦翻历史的消耗方式绑架了。如果你也在 Obsidian 里用 AI 写图文强烈建议花一个下午试试 Skill 化等看到月底账单的时候你会回来感谢自己的。