很多人收藏了大量书、长视频和播客,最后只留下摘要,真正做事时仍然想不起该用哪条方法。cangjie-skill 的目标是把高价值内容转换成 Agent 可以在具体场景调用的 Skills,而不只是压缩成一篇读书笔记。
项目地址:kangarooking/cangjie-skill
快速答案
适合输入的材料包括:
- 书籍或完整章节;
- 有字幕或转写文本的长视频;
- 播客、访谈和课程文字稿;
- 方法论密集的长文和资料集。
如果材料只有观点、新闻或情绪表达,没有可验证、可迁移的操作方法,就不适合强行做成 Skill。
它和普通摘要有什么区别
普通摘要回答“这份内容说了什么”,Skill 还要回答:
- 什么场景应该触发;
- 应按哪些步骤执行;
- 哪些条件下不适用;
- 容易和什么方法混淆;
- 如何用测试证明它真的可用。
项目采用 RIA-TV++ 流程,包含整体理解、并行提取、三重验证、结构化构造、Skill 间链接、压力测试和最终交付。
一次完整转换会生成什么
典型输出不是单个 SKILL.md,而是一组文件:
| 文件 | 用途 |
|---|---|
BOOK_OVERVIEW.md |
整体结构与批判性理解 |
INDEX.md |
Skill 地图及相互关系 |
DIGEST.md |
面向读者的精华长文 |
GLOSSARY.md |
术语表 |
*/SKILL.md |
可独立触发的技能模块 |
test-prompts.json |
触发条件与压力测试 |
这套结构适合后续维护:更新原材料时,可以只重做受影响的 Skill,而不是重写整份摘要。
推荐工作流
- 先取得合法可用的原文、字幕或个人转写;
- 清理广告、重复片段和转写错误;
- 明确希望解决的真实问题;
- 让 cangjie-skill 提取候选方法;
- 删除常识、单一案例和无法验证的观点;
- 为保留的 Skill 增加触发条件与边界;
- 用容易混淆的测试题验证。
处理视频时,应先完成字幕提取或语音转写,再输入纯文本。不要让 Agent 仅凭标题和简介推断整段内容。
什么内容值得蒸馏
一份材料适合转成 Skill,通常具备以下特征:
- 包含可以重复执行的步骤;
- 给出了适用条件和反例;
- 方法能迁移到原案例之外;
- 原文有多处证据支持;
- 能回答“什么时候用”和“什么时候不用”;
- 可以设计测试验证结果。
纯新闻、个人感想、故事合集和缺少方法的观点文章,通常更适合摘要或笔记。强行 Skill 化会生成看似正式、实际无法触发的空壳规则。
输入材料怎样整理
书籍
尽量提供合法取得、结构完整的文本,并保留章节标题。扫描 PDF 应先做 OCR 抽查,修正页眉、脚注和断行,否则提取器会把噪声当正文。
长视频
优先使用官方字幕;没有字幕时再做语音转写。保留时间戳有利于回查来源,删除片头广告、重复口播和与主题无关的互动。
播客与访谈
标明说话人。方法论可能只代表某位嘉宾,不应被错误归因于主持人或整个节目。
资料集
记录每份来源的标题、作者、日期和许可。多来源内容尤其需要区分共同结论和互相冲突的观点。
RIA-TV++ 七个阶段详解
1. 整体内容理解
先做结构、解释、批判和应用四步拆解,生成 BOOK_OVERVIEW.md。这一步不是摘要比赛,而是建立后续提取所需的全局上下文。
2. 并行提取
分别寻找框架、原则、案例、反例和术语。多视角能减少只提取醒目金句、忽略边界条件的问题。
3. 三重验证
候选方法至少需要多处独立佐证、具有预测力,并且不是普通常识。大量候选在这里被淘汰是正常现象。
4. RIA++ 构造
保留原文依据,用自己的话解释,补充书中案例、未来触发场景、执行步骤和适用边界。一个可用 Skill 必须同时有做法和禁区。
5. Zettelkasten 链接
建立 Skill 之间的依赖、对比和组合关系,生成 INDEX.md。否则几十个孤立 Skill 只会变成另一种收藏夹。
6. 压力测试
设计正常题、边界题和诱饵题。测试不仅要证明该 Skill 会触发,也要证明在不适用时不会误触发。
7. 交付与安装
生成 DIGEST.md、术语表、Skill 模块和测试文件,再安装到 Agent 的技能目录。安装前仍要人工复查版权、触发范围和脚本权限。
一个好的 SKILL.md 应包含什么
至少应说明:
- Skill 名称和目标;
- 明确的触发条件;
- 不应触发的场景;
- 输入要求;
- 可执行步骤;
- 判断与停止条件;
- 输出格式;
- 来源与边界;
- 测试例子。
如果一个 Skill 只有一段“请认真分析并给出建议”的提示词,它仍然是泛化提示词,不是可靠的执行模块。
怎样设计测试题
正向触发
给出典型适用场景,检查 Agent 是否正确识别并按步骤执行。
负向触发
提供表面关键词相似、实际不适用的任务,确认 Skill 不会抢占其他方法。
边界条件
删除关键输入、制造证据不足或目标冲突,检查 Agent 是否会停止并请求补充信息。
跨 Skill 混淆
让两个相关方法都看似可用,检查 Agent 能否解释选择和组合顺序。
test-prompts.json 应记录预期触发、预期拒绝和验收点,而不是只保存几个演示问题。
安装到 Agent 前的审查
从书和视频生成的 Skill 也可能包含脚本或外部链接。安装前检查:
- 是否引用大段受版权保护内容;
- 是否把个人隐私写进示例;
- 是否要求读取过宽目录;
- 是否会上传原始材料;
- 触发描述是否会覆盖无关任务;
- 是否存在无法验证的作者归因;
- 测试是否包含失败路径。
版本管理和更新
原材料更新、字幕修正或方法论被新证据推翻时,需要知道哪些 Skill 受影响。建议在每个模块中保存来源定位和版本,并在 INDEX.md 维护依赖关系。
不要静默改写已经用于生产决策的 Skill。重要更新应记录变更内容、原因和重新测试结果。
常见失败模式
| 失败表现 | 原因 | 改进方法 |
|---|---|---|
| Skill 数量很多但都相似 | 抽取后没有严格筛选 | 合并同义候选,执行三重验证 |
| 只有摘要没有动作 | 没有 Execution 字段 | 补充步骤、输入和停止条件 |
| 到处触发 | 描述过宽 | 增加负向条件和诱饵测试 |
| 看似权威但无来源 | 丢失引用定位 | 保留章节、时间戳和证据 |
| 原文错误被放大 | 没有批判阶段 | 加入冲突证据和限制 |
| 无法公开发布 | 复制内容过多 | 改为方法抽取与必要短引文 |
常见问题
可以把整本书直接公开成 Skill 吗?
要考虑版权和许可。个人学习与公开分发是两回事。公开仓库应保留方法论抽取和必要短引文,避免复制大段受版权保护的原文。
为什么生成了很多 Skill,却没有一个好用?
通常是筛选不够严格。不是每个章节都值得变成 Skill。优先保留能跨场景迁移、具有明确步骤和边界的少数方法。
一次应该处理多长的材料?
取决于模型上下文、文本质量和结构。超长材料应按章节处理,同时保留全局 Overview;不能简单切块后让各块互不知情。
可以把多个作者的方法合成一个 Skill 吗?
可以,但要标明共同点、冲突和各自证据。不要把互相矛盾的方法强行平均成一句空泛原则。
生成的 Skill 可以直接用于重要决策吗?
不应未经验证直接使用。投资、医疗、法律和安全等高风险内容需要专业审核、最新资料和明确责任边界。
从一段视频做 Skill 的实际例子
假设输入是一段“如何复盘项目失败”的两小时访谈。不要直接要求生成十个 Skills,可以这样处理:
- 取得字幕并保留时间戳、说话人;
- 删除广告和重复寒暄;
- 先生成访谈结构和主要论点;
- 提取“失败分类”“证据收集”“行动复盘”等候选;
- 检查每个候选是否在访谈中有多处依据;
- 把单一人物经历降级为案例,不当作普遍规律;
- 为每个方法补充适用项目规模与停止条件;
- 设计“普通周报”“事故复盘”“员工绩效”等混淆题;
- 只保留能正确区分场景的模块;
- 生成索引、Digest 和来源定位。
最终可能只得到三个可靠 Skills,这比十五个缺少边界的提示词更有用。
交付前的质量评分
可以为每个候选按 0–2 分评估:
| 维度 | 0 分 | 1 分 | 2 分 |
|---|---|---|---|
| 证据 | 无定位 | 单一依据 | 多处独立依据 |
| 可执行性 | 只有观点 | 有部分步骤 | 输入、步骤、停止条件完整 |
| 迁移性 | 只适用原案例 | 相似场景可用 | 多场景可验证 |
| 边界 | 未说明 | 有简单限制 | 反例和禁用条件清楚 |
| 测试 | 没有 | 只有正向题 | 正向、负向和混淆题齐全 |
低分候选应回炉或删除,不要为了保持数量降低标准。
如何与原作者观点保持距离
Skill 应明确区分“原作者主张”“提取器解释”和“可验证操作”。有争议或时代背景明显的方法,要在边界中写明来源时间与反方证据。Agent 不应把一本书的观点包装成普遍事实。
总结
cangjie-skill 适合把“看过但用不起来”的内容改造成 Agent 工作流。质量关键不在生成数量,而在来源完整、验证严格、触发清楚,并且敢于淘汰不具备独立价值的候选 Skill。