从需求到Skill：30分钟完整创作闭环

🎯 核心概念

先说结论：AI 时代最核心的能力，不是使用工具，而是"创造工具"。

具体来说，就是把重复性需求封装成可复用的 skill，建立个人工具库。

这是用两小时完成的工作流：在 X 发现素材 → 手动整理到 Obsidian → 用 Claude Code 整理成表格 → 用 xlsx skill 导出 Excel → 导入飞书多维表格 → 用 skill-creator 封装成 skill → 用 cta skill 写成公众号文章。

这个流程不仅完成了任务，还沉淀了两个可复用的技能：

这就是"创作自动化闭环"。

🔍 流程拆解

第一步：从发现到整理

昨天我在 X 看到一条推文，列了"全球AI最有影响力的15个人"。评论区又有网友补了5个。

我手动把它们汇总到一起，复制粘贴到 Obsidian，整理成了一个 Markdown 文件。

说实话，这个过程挺机械的——选中、复制、粘贴、调整格式。但我当时没多想，就觉得"只是个小任务，手动弄吧"。

这里有个关键点——

很多人会止步于此，认为任务完成了。但真正的价值在于：你能从这个一次性任务中，提炼出可复用的模式吗？

第二步：表格化

我先让 Claude Code 把 Markdown 文件整理成表格，第一列是链接，第二列是简介。

几秒钟就搞定了。

说实话，这一步我本来也打算手动弄的——不就是加几行 | 分隔符吗？但当 AI 帮你做完时，你才会意识到"原来可以这么快"。

真正的价值不是省时间，而是建立"可自动化"的意识。

第三步：导出 Excel

然后我想，能不能把这个表格直接导入飞书多维表格？

我打开了飞书官网，首页赫然写着：“一键导入 Excel”

我只需要把 markdown 文件转成 Excel 就行了。可怎么实现呢？

这时，我发现了 Claude Code 的 xlsx skill。

我让 xlsx skill 把 Markdown 文件导出成 Excel——表头蓝底白字、列宽自动调整、超链接保留。

真的是一键生成。

第四步：导入飞书

有了 Excel 文件后，我让 Claude Code 写了个 Python 脚本，调用飞书 API 把数据导入多维表格。

需要提供飞书应用配置（APP_ID、APP_SECRET）和多维表格配置（BASE_ID、TABLE_ID）。
这些在飞书开放平台和表格 URL 里都能找到。

导入成功。20 条记录，一条不落！

第五步：封装成 skill

到这一步，任务已经完成了。

但我突然想到：下次再有类似需求，难道要重新走一遍流程？

Claude Code 有个 skill-creator skill，可以把工作流封装成可复用的 skill。

我让 skill-creator 把整个流程打包成一个新的 skill，命名为 "md-to-feishu-bitable"。

现在，以后再有 Markdown 表格需要导入飞书，直接调用这个 skill 就行。一步到位。

第六步：写成文章

任务完成后，我用自己创造的 cta skill 把整个过程写成了一篇文章。

知识沉淀——从实践到方法论

没错，就是你现在看到的这篇文章。

build in public, learn in public 实践版

💡 三层技能系统

这个流程的核心，是理解"技能"的三个层次：

    ┌─ 三层技能系统 ─┐
⭐⭐⭐⭐⭐ 元技能（Meta-Skill）
    ├─ skill-creator：封装工作流为 skill
    ├─ cta：生成画伞风格文章
    └─ 特点：创造其他技能的能力

⭐⭐⭐⭐ 流程型技能（Workflow Skill）
    ├─ md-to-feishu-bitable：Markdown → 飞书
    ├─ extract-to-obsidian：网页素材 → 知识库
    └─ 特点：封装完整业务流程

⭐⭐⭐ 工具型技能（Tool Skill）
    ├─ xlsx：Excel 文件处理
    ├─ pdf：PDF 操作
    └─ 特点：解决特定文件格式/API

这就是技能复利：每封装一个 skill，你的"个人工具库"就增长一点。
累

积下来，你就是工具创造者，而不是工具使用者。

🤔 什么时候该封装 Skill？

不是所有需求都值得封装。这里有个简单的决策树：

┌─ 封装决策树 ─┐
这个任务会重复出现吗？
│
├─ 否 → 手动完成或用通用方案
│
└─ 是 → 需要定制化逻辑吗？
    │
    ├─ 否 → 用现有 skill（xlsx、pdf 等）
    │
    └─ 是 → 需要多步骤协作吗？
        │
        ├─ 否 → 写单次脚本
        │
        └─ 是 → 封装成 skill

判断标准：

案例对比：

✅ 值得封装：

❌ 不值得封装：

🛠️ 核心设计模式

这个流程体现了几个重要的设计模式。

模式一：渐进式封装

不要一开始就想封装成完美的 skill。

正确顺序：

手动操作 → 验证流程可行
    ↓
写脚本 → 固化步骤
    ↓
封装 skill → 便于调用
    ↓
分享为 .skill → 可分发给他人

为什么？

模式二：失败降级

自动化流程最怕"卡死"。

双层降级设计：

核心原则：

完成比完美更重要。自动化应该加速流程，而不是成为新的瓶颈。

模式三：Prompt 模块化

cta skill 使用了 "Style × Type" 的模块化架构：

┌─────────────────────────────────────────────────────────────┐
│                    PROMPT MATRIX                             │
├─────────────────────────────────────────────────────────────┤
│   Style Layer (Who + How)  ×  Type Layer (What + When)      │
│   ┌─────────────────┐      ┌───────────────────────────┐   │
│   │ styles/huasan.md│  ×   │ types/learning.md          │   │
│   │ (Role, Tone)    │      │ (Deep Dive - 深度践行)     │   │
│   └─────────────────┘      └───────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

正交性设计：

好处：

🧠 总结

核心洞察

1. 小需求也值得自动化

不是时间成本问题，是"意识"问题。

手动复制 20 条记录可能只要 10 分钟，但如果你每个月都要做一次呢？一年就是 2 小时。

更重要的是：每次手动操作时，你都在重复同样的思考过程——这是对认知资源的浪费。

2. Skill 是时间的容器

封装 skill 不是为了"显得专业"，而是为了把一次性投入转化为长期资产。

每个 skill 都是你"时间的容器"：

3. 双轨迭代

一边做项目，一边沉淀方法论。

两条轨道互相促进：项目提供素材，方法提升效率。

可执行清单

【当下可做】

【本月目标】

【长期方向】

一句话心智模型

"每个重复性的任务，都值得自动化。每个自动化需求，都可以变成一个 skill。每个 skill，都是你个人工具库的一部分。"

积累下来，你就是工具创造者。

📎 用到的 skills