cangjie-skill 怎么用:把书、视频和播客变成可执行 Agent Skills

介绍 cangjie-skill 如何把书籍、视频字幕和播客文字稿蒸馏成可调用、可组合、可测试的 Agent Skills。

很多人收藏了大量书、长视频和播客,最后只留下摘要,真正做事时仍然想不起该用哪条方法。cangjie-skill 的目标是把高价值内容转换成 Agent 可以在具体场景调用的 Skills,而不只是压缩成一篇读书笔记。

项目地址:kangarooking/cangjie-skill

快速答案

适合输入的材料包括:

  • 书籍或完整章节;
  • 有字幕或转写文本的长视频;
  • 播客、访谈和课程文字稿;
  • 方法论密集的长文和资料集。

如果材料只有观点、新闻或情绪表达,没有可验证、可迁移的操作方法,就不适合强行做成 Skill。

它和普通摘要有什么区别

普通摘要回答“这份内容说了什么”,Skill 还要回答:

  1. 什么场景应该触发;
  2. 应按哪些步骤执行;
  3. 哪些条件下不适用;
  4. 容易和什么方法混淆;
  5. 如何用测试证明它真的可用。

项目采用 RIA-TV++ 流程,包含整体理解、并行提取、三重验证、结构化构造、Skill 间链接、压力测试和最终交付。

一次完整转换会生成什么

典型输出不是单个 SKILL.md,而是一组文件:

文件 用途
BOOK_OVERVIEW.md 整体结构与批判性理解
INDEX.md Skill 地图及相互关系
DIGEST.md 面向读者的精华长文
GLOSSARY.md 术语表
*/SKILL.md 可独立触发的技能模块
test-prompts.json 触发条件与压力测试

这套结构适合后续维护:更新原材料时,可以只重做受影响的 Skill,而不是重写整份摘要。

推荐工作流

  1. 先取得合法可用的原文、字幕或个人转写;
  2. 清理广告、重复片段和转写错误;
  3. 明确希望解决的真实问题;
  4. 让 cangjie-skill 提取候选方法;
  5. 删除常识、单一案例和无法验证的观点;
  6. 为保留的 Skill 增加触发条件与边界;
  7. 用容易混淆的测试题验证。

处理视频时,应先完成字幕提取或语音转写,再输入纯文本。不要让 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 应包含什么

至少应说明:

  1. Skill 名称和目标;
  2. 明确的触发条件;
  3. 不应触发的场景;
  4. 输入要求;
  5. 可执行步骤;
  6. 判断与停止条件;
  7. 输出格式;
  8. 来源与边界;
  9. 测试例子。

如果一个 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,可以这样处理:

  1. 取得字幕并保留时间戳、说话人;
  2. 删除广告和重复寒暄;
  3. 先生成访谈结构和主要论点;
  4. 提取“失败分类”“证据收集”“行动复盘”等候选;
  5. 检查每个候选是否在访谈中有多处依据;
  6. 把单一人物经历降级为案例,不当作普遍规律;
  7. 为每个方法补充适用项目规模与停止条件;
  8. 设计“普通周报”“事故复盘”“员工绩效”等混淆题;
  9. 只保留能正确区分场景的模块;
  10. 生成索引、Digest 和来源定位。

最终可能只得到三个可靠 Skills,这比十五个缺少边界的提示词更有用。

交付前的质量评分

可以为每个候选按 0–2 分评估:

维度 0 分 1 分 2 分
证据 无定位 单一依据 多处独立依据
可执行性 只有观点 有部分步骤 输入、步骤、停止条件完整
迁移性 只适用原案例 相似场景可用 多场景可验证
边界 未说明 有简单限制 反例和禁用条件清楚
测试 没有 只有正向题 正向、负向和混淆题齐全

低分候选应回炉或删除,不要为了保持数量降低标准。

如何与原作者观点保持距离

Skill 应明确区分“原作者主张”“提取器解释”和“可验证操作”。有争议或时代背景明显的方法,要在边界中写明来源时间与反方证据。Agent 不应把一本书的观点包装成普遍事实。

总结

cangjie-skill 适合把“看过但用不起来”的内容改造成 Agent 工作流。质量关键不在生成数量,而在来源完整、验证严格、触发清楚,并且敢于淘汰不具备独立价值的候选 Skill。