Part 1: 灵感来源

我在的一个学VibeCoding的高质量社群（AI黄叔的群），每天都会有人分享有价值的链接。GitHub 项目、飞书文档、技术文章……我曾经花了半天搞了个可以提取微信文章到数据库的一个工具，唯一没有自动化的是，文章链接要自己一个个复制，大概每天5-10分钟。

但第二天我就没有继续更新了，我突然意识到一个问题——有些事操作很简单能做，但我就是不想每天做。

复制链接很简单，但很难每天坚持。一旦断了，就不想继续了。没爬楼的内容找不到，看过也不等于记得，看群反而加重了信息负担。

我想做这个skill的初心其实很简单：

• 从源头（聊天记录）自动提取

• 一键完成所有事情

• 支持搜索（知识库的核心价值）

有了大概的思路，正好有个做 skill 的比赛，我就想如果能跑出来，就用这个参赛。

其实核心思路就是搞到聊天记录，然后文本分析提取链接，清洗数据，然后生成报告

Part 2: 整体流程

我从 10000 多条聊天记录里提取信息，发现整体的工作流可以是这样的：

第一步：聊天记录导出

微信群聊的导出，需要有点黑科技，不过还好我在GitHub找到一个项目解决了。导出格式是 JSON，里面包含了每条消息的发送者、时间戳、内容、链接等信息。

第二步：解析和提取

从 JSON 里解析出有链接的消息，提取所有的 URL，因为有部分单条文本是有好几个链接的。这里要注意 URL 的清洗——不然数据肯定会漏。

第三步：抓取内容

批量抓取链接的内容。有些链接需要登录，有些是 JS 渲染的，有些直接失效。需要分轮处理。

第四步：AI 分析

生成标题、总结、分类、优先级评估。这里有个关键发现——飞书自己就有 AI 分析功能，可以直接用。

第五步：同步飞书

把所有数据同步到飞书多维表格，形成可搜索的知识库。

第六步：生成报告

生成 HTML 可视化报告，带筛选、搜索功能的卡片展示。

整个流程跑通后，从聊天记录到可视化报告，全自动完成。

Part 3:  内容抓取的bug

内容抓取这块，一开始我以为挺简单的。

之前做过微信文章的抓取，以为这次也会比较顺利。结果跑起来发现——有些链接需要登录，有些链接是 JS 动态渲染的，有些链接直接就失效了。

CC 一开始就是吭哧吭哧干活，一跑就是十几分钟没有反馈。等了半天，第一批数据跑出来了，成功率只有 60%。

剩下的 40% 怎么办？继续跑第二轮？还是换 Playwright 上？

折腾了一轮，发现这样"一轮到底"的思路有问题：没有反馈，不知道进度，跑完才发现有问题，再调整策略，再跑一轮。太低效了。

第一轮跑完，10 分钟就能看到 80% 的结果。然后再根据失败的情况，决定要不要跑第二轮。

不是"一轮到底"，而是"逐步逼近"。

我后来总结得很到位：AI 容易吭哧吭哧干活，没有分批的概念。如果没有提前沟通，干一大段黑盒时间没有反馈，发现一直错。分几轮提取，第一轮解决 80%的问题，第二轮再解决，比一轮解决更好。

Part 4: 渐进性思考，逐步执行

这次 skill 创作最大的收获，其实就一句话——渐进性思考，逐步执行。

什么叫渐进性思考？

就是不追求一次到位，先解决 80%，再处理剩下的 20%，最后接受那 5% 的客观限制。

链接抓取就是典型例子。CC 一开始吭哧吭哧干活，一跑就是十几分钟"黑盒时间"，跑完才发现只有 60% 成功率。

后来调整成三轮迭代：

• 第一轮：requests 快速抓取，解决 80%

• 第二轮：Playwright 处理反爬，再解决 15%

• 第三轮：剩下的 5% 标记为失败

不要追求 100%，先解决大部分问题，剩下的逐步优化。

什么叫逐步执行？

就是"一段一段执行，执行完及时复盘迭代经验。

这个模式本来是用于写文档的，但后来发现——写代码、调参数、改配置，其实也都应该这样。

最后生成HTML 报告，也发生了很多问题，我提了几个问题，结果直接改出了"布局溢出"，就是因为一次性改太多：8 种配色、4 列布局、5 列布局、Hover 特效、响应式设计……结果全乱了。

我当时直接说：“太可怕了，整个布局都是乱的，你现在马上要返回上一个版本。”

如果当时能分步骤来，每一步都验证，就不会出现这种状况。

不要一条路走到黑

筛选功能不工作的时候，CC 改了 5 个版本：HTML 格式、事件绑定、标签关联、CDN……但还是不行。cc不断让我看代码截图给他，结果连续改了10次，还是一样加载不出链接卡片。

我说：“你到底是卡在哪里了？你先总结一下经验再工作吧。我们其实对接了很多轮，就是我不希望你一条路走到黑，先停下来想想。”

后来我突然灵机一动——“类型 tag 应该在小标签上”，会不会是数据映射的问题。这句话让 CC 反应过来：dataset 应该在 .card 元素上。

解决这个问题只花了 5 分钟，但前面改了 5 个版本花了 4 小时。

我发现虽然我不如cc懂代码，但提供有效的思路有时比懂代码更轻易解决问题。

能用的部分不要改

卡片显示正确后，CC 又想调样式。

我说：“卡片现在能正确显示了，这个卡片这里你千万就不要动了。你要总结出经验的，不然的话，下一次还是会有问题的。”

后来 CC 写了专门的文档，记录了正确的替换逻辑，保存了可用的模板文件。

强制验证 > 建议阅读

还有个很深刻的教训：明明有经验文档，执行时还是踩坑。

“字段类型错误”——用了 type=15（多文本）导致 212 条更新全部失败。

如果在同步前能有个强制检查，验证失败立即 exit(1)，就不会浪费那 30 分钟了。

这次创作之后，CC 把经验沉淀成了“强制检查点”机制：每个阶段后验证，验证失败立即停止，脚本启动时自动提醒。

思路比技巧更重要

分轮迭代、渐进验证、停下来想想，这些朴素的思路，比复杂的代码技巧更有价值。

这就是 vibe coding 的魅力——不需要懂很多代码，但要知道怎么让 AI 高效地帮你干活。

Part 5: 最后说下这工具到底能干啥

前面讲了这么多踩坑和经验，最后简单说下这个工具实际用起来是什么样的。

输入很简单，就是微信 PC 端导出的聊天记录 JSON 文件。我那次是从一个高质量分享群里导出来的，10000 多条消息。

输出会得到三个东西：

1. 第一个是飞书多维表格，里面是所有链接的结构化数据——标题、总结、分类、优先级、学习价值、第一次提及时间、提及次数。这个表格就是我的知识库了，可以搜索、筛选、排序。

   

   
   

   
   

2. 第二个是 HTML 可视化报告，带筛选功能的卡片展示。可以按类型筛选（GitHub、飞书、微信、其他），可以搜索关键词，可以看到统计数字和 AI 洞察。

   
   

   

   
   

3. 第三个是 AI 洞察分析——自动分类、优先级评估、学习价值评分。这个可以使用规则配置结合AI设计。

整个流程从聊天记录到可视化报告，全自动完成，不需要手动干预。（最多给几个确认）

我第一次跑的时候，从导出聊天记录到生成 HTML 报告，大概花了 8个小时（包括各种调试）。现在经验沉淀下来了，应该能压缩到 1 -2小时内完成（关键是手动干预调bug的地方少了，大部分后台操作，知识库倒是不需要每天总结）。

最大的价值不是省时间，而是——把“知道要做但懒得做”的事情，变成了“全自动不用管”。

不用每天复制链接，不用担心漏掉内容，不用手动整理。聊天记录一导，脚本一跑，所有链接自动进入知识库，可以搜索、可以分类、可以看到 AI 总结。

这就是 vibe coding 的魅力——不需要懂很多代码，但要知道怎么让 AI 高效地帮你干活。

结语

这次 skill 创作最大的收获不是工具本身，而是——渐进性思考，逐步执行。

分轮迭代、渐进验证、停下来想想，这些朴素的思路，比复杂的代码技巧更有价值。

但还有两个更关键的发现。

发现一：从“每次写工具”到“斜杠命令”

之前我也遇到过类似的问题，每次都是重新写个脚本，跑完就丢在那了。下次再遇到，又要重新写。

这次不一样，我把整个流程沉淀成了 skill，现在只需要一个斜杠命令就能调用。

这个转变听起来很简单，但价值很大：从“一次性工具”变成了“可复用能力”。

发现二：优化 skill 的 skill

在调试这个 skill 的过程中，我发现——skill 本身也是需要优化的。

那“怎么优化 skill”这件事，能不能也沉淀下来？

于是我把“优化 skill 的思路”也做成了一个 skill。

这个听起来很绕，但其实就是个元技能：把你解决问题的思路，沉淀成可复用的方法。

简单，但很有用。

下次再做类似项目，应该能从 2 天压缩到 1 小时内完成。

因为经验已经沉淀下来了，不只是“文档”，而是“斜杠命令”、“强制检查点”、“执行前提醒”、“渐进式验证”这些机制。

这就是 vibe coding 的魅力——不需要懂很多代码，但要知道怎么让 AI 高效地帮你干活。