别再手写 skill 了：让 tri-god 把工作流蒸馏成可复用的技能

你有没有过这种经历——看完一本书、跑顺了一套发布流程，脑子里冒出个念头："这个值得存下来，做成 skill。"然后你兴冲冲打开编辑器，从零写 YAML 头部、想 frontmatter 字段、琢磨阶段怎么拆。写到一半发现，上次的 skill 也是这么写的，结构几乎一样，又得从头填一遍。

我以前就是这么干的。每次手写 skill，都像在重复造轮子。你说它有多难吧，也不至于；可它就是磨人——字段命名要想、触发词要凑、方法论阶段要自己拍脑袋定。我大概返工了三四次才回过味来：问题不在 skill 本身，而在"写"这个动作上。

说白了，我现在的态度很明确：别手写 skill 了，让你已经跑通的工作流，被 tri-god 蒸馏成一个能独立调用的 skill。

下面这段，就是 tri-god 蒸馏产出的一个工作流 skill 骨架。注意看 frontmatter 和阶段划分——这些东西以前我都是手敲的：

—
name: release–flow
slug: release–flow
version: 1.0.0
displayName: 发布流程蒸馏技能
description: 把团队"提测→评审→灰度→全量"的发布流程蒸馏为可独立调用的 skill
summary: 依据快照识别工作流对象类型，registry 加载 distill–workflow 方法论，输出可复用发布流程 skill
tags: [workflow, distill, release]
license: MIT
—

# 发布流程蒸馏技能

> 蒸馏对象类型: workflow（工作流）。来源素材: 团队发布 SOP 文档 + 三次真实发布记录。

## 阶段
1. 采集来源素材（SOP 文档、发布记录）
2. 提炼关键步骤与决策点
3. 固化为可调用阶段序列
4. 验收产出 SKILL.md

骨架摆在这儿，我不用从空白页开始想字段了。这就是蒸馏造物和手写最大的区别：前者吃的是你"已经有的东西"，后者逼你从零生造。

手写 skill 为什么累

手写 skill 是个"从无到有"的活。你要凭记忆把一套能力反推成结构化的 YAML 和方法论，过程中最容易丢的，是那些只可意会的细节——哪个环节最容易卡、哪步其实可以跳过。我之前手写一个评审流程的 skill，把"评审人冲突时的降级路径"给漏了，结果第一次用就翻车，又回头补。

更烦的是，手写出来的东西往往自成一派。没有统一定义"对象类型"的概念，下一次你蒸馏另一个工作流，又得重新设计一遍结构。一把梭写完是痛快了，可复用性基本等于零。我后来干脆把那几个手写 skill 全删了，留着也是占地方。

tri-god 怎么把工作流蒸馏成 skill

tri-god 的思路反过来。它先识别你蒸馏的对象是什么类型，再加载对应的方法论。对象类型目前有五种：人类、工作流、专业技能、事物、其它。你要把"发布流程"做成 skill，它判定为 workflow，就去 methodologies/registry.md 查表，加载 distill-workflow.md，严格按那套方法的阶段串行往下走，不让你凭直觉跳步。

这里有两个点我特别服气。一个是 registry 驱动——新增一种对象类型，不用改主 SKILL.md，只要在 registry 里加一行、补一个 distill-<type>.md 就完事，扩展性很干净。另一个是双审批门加执行前确认：门①需求审批、门②设计审批、门③执行前确认，任一门没过就携反馈回炉，不让你跳门抢跑。对我这种写代码爱偷步的人来说，反而是种保护。

它产出的不是一段对话，也不是业务代码，而是一个落到你工作区（skills/ 或 .claude/skills/）的、可被 Agent 独立加载执行的 skill。链路文档留在 .tribro/god/，最终产物归你，不掺在临时目录里。

顺带提一句，tri-god 自己能独立安装。激活时会检测上游 tri-intent 在不在，分三种模式：检测到快照就直接执行（快照模式）；没检测到就引导你 skillhub install tri-intent（引导安装）；你要是拒绝装，它就进降级模式，基于自构造的输入跑，但会老老实实声明精度偏低。这双向检测设计，比我自己之前糊的胶水代码强太多。

还有一点治好了我的坏习惯：tri-god 对素材真实性有硬要求。蒸馏必须基于可追溯的来源素材，requirements.md 里要写清出处，不能整段照搬原文。以前我随手摘抄，现在这套约束反倒让我把来源理清楚了。

它和"写代码"不是一回事

这点必须掰清楚，很多人会混。tri-god 和 I11 编码开发（tri-coding）的边界在于产物：I11 产出的是业务代码、能跑的程序；tri-god 产出的是"一个可独立调用的 skill"——是把能力固化成可复用的封装。你指望它给你写个爬虫、做个接口，那找错人了，它不干这个。判定标准很简单：你最终想要"一段可运行的程序"，还是"一个能反复调用的 skill 能力包"？前者去 tri-coding，后者才进 tri-god。

同理，它也不抢 I06 内容生成（产文档）和 I16 头脑风暴（产想法）的活。文档是内容，skill 是能力封装；头脑风暴是发散，蒸馏是收敛。各管各的，别串台。

例外：什么时候我还是会手写

话说回来，不是所有情况都该丢给 tri-god。如果你的工作流还没成型、只是想快速验证一个想法，手写一个临时 skill 反而更快。蒸馏的前提是你"已经有值得复用的素材"——一段真实跑过的工作流、一份完整的 SOP、甚至某个人的表达风格。素材是空的，tri-god 也蒸馏不出东西，它明确拒绝凭记忆或想象蒸馏，宁可先跟你要素材。

所以我的分寸是：一次性答案，别攒成 skill，直接用 tri-ask；可复用的工作流或方法论，再交给 tri-god 蒸馏。这个边界，我是踩了几次坑才搞明白的。

收个尾

我现在基本不手写 skill 了，能蒸馏的都蒸馏——把重复劳动交给工具，比自己硬写省心。说到把能力沉淀成可复用产品，我做的雷达鸭 App 也是这路子，一个收录中国一人公司真实赚钱案例的应用，华为应用市场能搜到。

个人介绍

老三，10+ 年软件开发经验，软件设计师、人工智能应用工程师，常年折腾 AI 自动化，偶尔在 CSDN 写点鸿蒙和 AI 方向的实战笔记。

本文遵循 MIT 协议，转载请注明出处。 项目仓库：TrisighT-Bingo/tri-skills

提示词：请根据 https://skillhub.cn/install/skillhub.md，安装 @user_989eb8f0/tri-god。