Claude Code正在重塑内容工作流的起点——从信息抓取到知识沉淀的完整链路。这款工具不仅能自动化完成公众号文章抓取、长报告速读、播客转录处理等繁琐任务，更通过结构化归档、场景抽取和选题转化，将零散信息转化为可直接用于写作、培训和咨询的素材资产。本文揭秘如何用技术手段解决内容创作者最头痛的'弹药库'问题。
上一篇讲的是内容创作。
但真正做内容的人都知道，写作只是后半段。前半段更麻烦的是：素材从哪里来？公众号文章怎么抓？小红书评论怎么拿？GitHub 项目怎么读？长报告怎么消化？几百篇文章怎么分类？这些东西如果都靠人工复制、阅读、整理，基本不可能长期坚持。
所以第二篇，我想讲 Claude Code 的第二大类应用：内容抓取与素材处理。
这部分解决的不是“怎么写文章”，而是“怎么把外部信息变成自己的内容弹药库”。
我把它分成四段：
内容创作的上游，是信息输入。
以前看到一篇好文章，我最多是收藏一下，或者复制到文档里。问题是收藏之后很少再看，复制也经常格式乱、图片丢、正文不完整。后来我开始让 Claude Code 直接抓取、清洗、总结、归档。
这是我用得非常多的一个场景。
原来看到一篇公众号文章，想快速判断有没有价值，一般要自己点开读完。遇到几千上万字的长文，还要自己摘重点。如果想保存正文，还要复制粘贴，格式很容易乱，标题、作者、发布时间也经常漏掉。
现在我会直接把公众号链接丢给 Claude Code。
输入是：一个或多个公众号文章 URL。
输出通常有两类：第一类是抓取下来的正文，包括标题、作者、发布时间、正文内容，保存成 JSON 或 Markdown；第二类是结构化总结，包括核心论点、关键洞察、案例数据、对我业务的启发。
如果是多篇文章，我还会让 Claude Code 横向对比：哪些观点重复，哪些文章值得看，哪些可以转成选题，哪些对我的三条业务线有用。
这里真正省心的地方是：我不需要一篇篇复制，也不需要自己先完整读完。Claude Code 先帮我把正文抓下来，再压缩成我能快速判断的结构。文章如果值得深入看，我再继续读；如果不值得，就只保留摘要。
这一步很像内容创作的“入口”。外部文章先被抓下来，才有可能进入后面的素材库、选题库和知识库。
除了公众号，我也经常会看一些资讯网站、产品经理社区、投资纪要网站或行业文章页。
原来处理这类网站也很烦。我要么手动复制正文，要么在站内搜索关键词，然后一个个点开结果，把标题、作者、日期、链接保存下来。做一次还行，多做几次就很浪费时间。
现在我会让 Claude Code 直接访问页面或做站内搜索。
输入是：一个文章链接，或者一个网站加一个关键词。比如让它在某个产品经理网站里搜索 “Claude Code”，提取前几篇相关结果。
输出可以是文章正文，也可以是搜索结果列表，包括标题、作者、日期、URL 和简短说明。
这个场景里，Claude Code 做的不是复杂研究，而是把原本要人工点网页、复制链接、整理表格的动作自动化。特别是站内搜索这类动作，人工做起来很碎，交给它会省不少时间。
它的价值在于：普通网页也能进入我的内容工作流，不会停留在浏览器收藏夹里。
有些材料不是单篇文章，而是几万字的行业报告、白皮书或长文。
原来我拿到这类材料，第一反应通常是先收藏，等有时间再看。但实际情况是，大部分长报告收藏之后就不会再打开。因为完整读一遍成本太高，不读又不知道里面有没有价值。
现在我会先让 Claude Code 做速读总结。
输入是：一份长报告全文，可能是几万字的文本，也可能是 PDF 或 Markdown。
输出是：按原报告结构整理出的摘要、核心判断、关键数据、重要案例、值得引用的观点，以及“这份报告对我有没有用”的判断。
比如一份文化产业和生成式 AI 相关的长报告，Claude Code 可以帮我按章节梳理：报告讲了什么问题，哪些数据最关键，哪些观点适合引用，哪些内容和我的企业 AI 转型业务有关。
这件事省心的地方是：我不用先完整读完报告，Claude Code 先帮我把骨架拆出来。后面我要写文章、做 PPT、做培训时，可以直接从摘要里挑可用材料。
它不是替代深读，而是降低判断成本。先知道这份报告有没有价值，再决定要不要深入看。
有些素材来自播客、访谈或视频转录稿。
原来音视频内容最大的问题是不好检索。听的时候觉得有价值，听完之后很难再找回某个观点。即使已经转成文字，如果只是放在那里，也很难复用。
现在我会让 Claude Code 对已经转好的播客或视频文本做二次提炼。
输入是：播客转录文本、访谈稿、视频口播稿，或者 docx 格式的长文本。
输出是：节目摘要、核心观点、金句、对我业务有用的启发、可以转成文章的选题，以及归档到 Obsidian 或飞书知识库的结构化内容。
这里的重点不是转文字本身，而是把文字稿变成可用知识。比如一段访谈里提到 AI 产品、组织转型、知识管理，我会让 Claude Code 按主题拆出来，并标记哪些观点适合写公众号，哪些适合放进培训课件，哪些适合做客户沟通素材。
这件事的价值是：播客和视频不再只是听过就忘，而是能变成可检索、可复用、可二次创作的素材资产。
单篇抓取解决的是“拿下来”。
但内容一多，真正的问题就变成了：怎么归档？怎么去重？怎么命名？怎么放进知识库？怎么让后面写文章的时候还能找回来？
这一部分，Claude Code 更像一个内容资料管理员。
有时候我不是抓一篇文章，而是一次性给 Claude Code 十几个公众号链接，或者要求它把我自己公众号里的历史文章全部迁移到知识库。
原来做这件事很麻烦。每篇文章都要打开、复制、保存、改标题、补日期、放到对应文件夹。文章一多，很容易重复、漏抓、格式不统一。
现在我会让 Claude Code 批量处理。
输入是：一批公众号链接，或者一个公众号历史文章列表，外加目标知识库路径和命名规则。
输出是：每篇文章对应的 Markdown 文件，按 YYYY-MM-DD_标题.md 命名，正文前面带元信息，比如标题、作者、公众号、发布时间、原文链接。文件会自动放进 Obsidian 的指定目录。
如果中间有部分文章抓取失败，它会用浏览器自动化或登录态方式兜底。迁移自有公众号文章时，它还会按账号名去重，避免把同一篇文章重复保存。
这件事省心的地方是：我不用手动复制粘贴几十篇文章，也不用逐篇整理格式。外部文章和自己的历史文章，都可以变成统一格式的知识库文件。
这一步对长期做内容很关键。因为你过去写过什么、收藏过什么、看过什么，只有进入知识库，后面才可能被重新调用。
还有一种更重的场景：把某个公众号的历史文章尽可能全量抓下来。
比如我研究一个 AI 财务博主，想看他过去一年到底写了哪些内容，哪些文章和财务有关，哪些和 AI 有关，能不能从中整理出财务 AI 场景。
原来这种事人工根本做不了。一个公众号几百篇文章，靠手动打开复制，不现实。
现在我会让 Claude Code 改造爬虫，把文章列表和正文抓下来。
输入是：公众号账号信息、抓取配置、cookie 和 token、目标保存路径。
输出是：文章元数据 CSV，包括标题、摘要、发布时间、链接等；以及每篇文章正文对应的 Markdown 文件。后续还可以按月份、来源或主题分文件夹保存。
比如抓取某个公众号 260 多篇文章后，Claude Code 可以先生成 wechat_articles.csv，再把 CSV 转成 Markdown，一篇篇放进 Obsidian。
这件事的价值是：一个公众号可以从“只能在线浏览的信息源”，变成“本地可检索的知识库”。后面要做分类、打标、提取场景、分析选题，全都有了底料。
有些网页很长，比如一个 AI Agent 项目合集，一个 Google Agent 落地案例页面，或者 GitHub 上几百个开源项目的 README 汇总。普通抓取经常会被截断、反爬，或者只拿到前面一小段。
原来遇到这种情况，很容易只看摘要，或者随便列几个案例就算了。但如果我要做咨询素材或白皮书素材，只看几个案例是不够的。
现在我会让 Claude Code 尽量抓完整内容。
输入是：网页链接、GitHub 仓库链接、希望提取的内容范围、目标保存路径。
输出是：完整正文、结构化解析后的 Markdown 文件，或者按行业、项目类型、应用场景拆好的知识库文档。
比如一个页面里有几百上千个 Agent 案例，Claude Code 会通过浏览器自动化、CDP、GitHub API 等方式尽量拿到完整内容，再解析成可读的结构。最后保存到本地知识库里，而不是只给我一个简短摘要。
这件事最重要的教训是：做资料沉淀时，先全量抓下来，再做摘要。不要拿几个片段冒充全量。对企业 AI 咨询来说，案例库越完整，后面做方案和培训时越有底气。
我也会把一些已经购买的付费专栏内容整理到飞书或本地知识库里。
原来小报童这类付费专栏很难整理。内容在网页里，可能需要登录态，图片还会懒加载，手动复制会丢格式、丢图片。如果有几十篇文章，人工搬运非常麻烦。
现在我会让 Claude Code 借助浏览器登录态，把已购买内容完整提取出来。
输入是：付费专栏链接、文章链接列表、目标飞书文档或知识库路径。
输出是：完整文章正文、图片、文章链接列表，必要时直接写入飞书文档，并尽量保持图文顺序。
这个场景里，Claude Code 做的不只是复制文本。它会打开网页，滚动加载内容，提取正文和图片，再通过飞书文档工具写入知识库。如果是核验任务，它还可以确认哪些文章可访问，哪些链接失效，哪些内容已经成功提取。
这件事的价值是：我购买过的内容不再散落在平台里，而是能沉淀到自己的学习库中，后面可以检索、总结、引用和二次加工。
当内容抓下来以后，新的问题出现了：资料太多，怎么用？
几百篇文章放在知识库里，如果没有标签、分类、摘要和场景抽取，本质上还是一堆文件。Claude Code 在这里的价值，是把“内容堆”变成“结构化素材库”。
比如我抓了一个财务博主 260 多篇文章，想知道哪些是财务，哪些是 AI，哪些是财务 AI，哪些都不相关。人工逐篇读，一天都不一定够。
原来这种分类工作很无聊，也很容易标准不一致。今天觉得某篇算 AI，明天可能又觉得不算。
现在我会把文章切成多个 batch，让 Claude Code 并行打标。
输入是：每批文章的标题、摘要、正文节选和分类标准。分类标准会写清楚：财务包括会计、报表、税务、预算、ERP 等；AI 包括大模型、Agent、自动化、AI 工具等。
输出是严格 JSON 数组。每篇文章都会标注 财务、AI、财务AI 或 都不相关，必要时还会附一句理由。
这件事省心的地方是：几百篇文章可以分批并行处理，最后再用程序回收结果。分类标准写死以后，多批处理的口径也会比较一致。
这里有一个关键点：不能只靠关键词匹配。比如标题里没有“AI”，但正文里讲的是智能体、自动化分析，也可能属于 AI；标题里有“智能”，但实际只是规则系统，也未必算 AI。Claude Code 的语义判断在这类任务里比简单脚本更好用。
文章分类之后，我还会进一步抽取场景。
比如从几十篇“财务 AI”文章里，提取出 AI 到底能在财务里干什么：发票审核、费用报销、对账、预算预测、现金流分析、报表生成、税务检查、制度问答等。
原来人工读文章时，只能边看边摘，最后很容易变成一堆零散笔记。想整理成“15 大场景、75 个具体用法”，工作量很大。
现在我会让 Claude Code 逐篇提取。
输入是：每批 8 篇左右的财务 AI 文章，以及明确的提取规则。
输出是结构化 JSON。每篇文章会输出标题，以及其中真实提到的场景和 AI 用法。如果文章里没有具体场景，就标记“无具体场景描述”。
这个场景里，我会特别强调：只提取文章里确实写到的，不脑补，不扩展，不把 RPA 或普通规则引擎强行算成 AI。
这条规则很重要。因为场景库一旦掺入 AI 自己脑补的内容，后面做培训、白皮书、客户方案时就会失真。
这件事的价值是：几百篇文章不只是被收藏，而是被压缩成可检索、可复用的“场景-用法”清单。后面我要做财务 AI 培训，就可以直接从里面选案例、选场景、选用法。
有些真实需求不在正式文章里，而在小红书评论区里。
比如我想研究“AI 在财务场景到底有没有真实需求”，光看公众号文章不够，还要看真实用户怎么说。他们吐槽什么，觉得哪里有用，哪里不靠谱，哪些问题每天都在发生。
原来小红书内容最难处理。正文可以看，但评论很多是折叠的，还有一级、二级、三级回复。人工翻评论非常累，也很容易漏。
现在我会让 Claude Code 走浏览器登录态，把笔记正文和多级评论完整抓下来。
输入是：小红书笔记链接、搜索关键词，或者几条指定笔记。
输出是结构化 JSON，包括标题、作者、正文、赞藏数、评论，以及多级嵌套回复。后续 Claude Code 还可以继续把评论整理成场景分类表，比如数据查询、自动化、审核合规、票据处理等。
这件事的价值是：我可以从真实用户评论里提取一手需求。公众号文章更像作者观点，小红书评论更像用户现场。两者结合，做出来的场景判断会更接近真实市场。
比如有人在评论区说“每天都在对账”“发票审核很麻烦”“系统导出的表格式乱”，这些都可能变成后面的培训案例、Demo 方向或产品场景。
有时候我抓了一批行业文章，不一定马上写，但需要快速判断哪些能变成我的选题。
原来我会打开文件夹，一篇篇看标题和开头，大概判断有没有用。看完之后如果不马上写，很快又忘了。
现在我会让 Claude Code 批量读这些文章，并给每篇补一个“曾俊视角”。
输入是：一个文件夹里的多篇公众号文章，或者一个月度素材目录。
输出是：每篇文章的标题、来源公众号、核心主题、2 到 3 个关键点，以及“对曾俊的潜在选题角度”。
比如一篇文章讲 AI Agent，Claude Code 不只是摘要，还会帮我判断：这篇文章可以怎么转成“企业 AI 培训”的选题，怎么转成“智能体定制”的选题，怎么转成“老板认知”的选题。
这件事省心的地方是：看文章不再只是看文章，而是看完就能沉淀选题。它把外部素材和我的业务线接起来。
这一步对持续写公众号特别有用。因为素材很多，但真正能写成自己文章的角度，需要结合自己的定位重新解释。
除了分析内容本身，我也会分析数据。
比如抓取几个 AI 博主的文章数据，看哪些主题点赞、分享、阅读更好，再反过来验证我的选题判断。
原来我对“什么内容容易火”的判断更多靠感觉。觉得某些标题好，某些主题有用，但没有数据支撑。
现在我会让 Claude Code 结合 Python 做数据分析。
输入是：多个博主的公众号文章 Excel，里面包含标题、发布时间、点赞、分享等数据；或者我自己素材库里几千个标题。
输出是：高互动主题规律、TOP 文章主题分布、全量主题占比、标题类型分析、可写选题推荐。
比如我可以验证一个假设：“对用户有帮助”是不是爆款的充分条件。分析后可能会发现，有帮助只是基础，真正拉开数据的还包括低门槛、热点、场景感、首发、情绪表达等因素。
这件事的价值是：选题不再完全靠拍脑袋。Claude Code 可以帮我把标题、互动数据、主题标签放在一起看，找出哪些方向值得继续写，哪些只是我自己觉得重要但读者不一定关心。
素材库越用越大，也会越来越乱。
有些文件是 AI 相关，有些不是；有些文章已经过时，有些重复；有些自己过去写的内容，其实可以拆出很多课程素材，但如果不重新整理，就一直躺在文件夹里。
原来清理素材库是一件很烦的事。人工一个个打开判断，效率很低。只看标题又不准确，因为有些标题看不出内容是不是相关。
现在我会让 Claude Code 做素材库摸底和清理。
输入是：一个公众号文章文件夹、一个 Obsidian 目录，或者自己历史文章链接。
输出可以有几类：第一类是删除或标记无关内容；第二类是按主题整理已有素材；第三类是从自己历史文章里提炼可复用技巧；第四类是把几十篇运营技巧文压缩成速查摘要。
比如我以前写过一篇“29 条提示词技巧”，Claude Code 可以抓取正文后，从里面挑出适合做进阶课、培训案例或文章选题的条目。这样历史文章就不只是发布过的内容，也能重新变成课程素材。
这件事省心的地方是：素材库可以持续维护，旧内容也可以被重新激活。长期做内容，最怕素材越积越多但越来越不可用。Claude Code 可以定期帮我做清理、归类和复用。
抓取和整理最终还是要服务创作、培训、咨询和产品判断。
所以第二大类最后一部分，不只是“把内容存起来”，而是把内容加工成我后面能直接用的东西：选题、流程图、产品判断、场景清单、培训素材。
有些文章讲的是一个产品流程或工具方案，只读文字不够直观。我会让 Claude Code 把它拆成流程图，再继续追问产品逻辑。
原来我看到一篇讲产品拆解的文章，只能自己边读边想：这个产品到底怎么跑？核心价值是什么？成本在哪里？是不是软文？有没有真实壁垒？
现在我会让 Claude Code 先抓文章，再画流程图。
输入是：一篇产品拆解文章，或者一个工具介绍链接。
输出是：按照文章内容整理出的 Mermaid 流程图，以及后续产品分析，比如核心流程、关键环节、可能的技术实现、成本结构、产品壁垒和可疑点。
比如一篇文章讲某个视频工具，Claude Code 可以先把 Hunt、Analyze、Recreate 这样的流程画成图。接着我继续追问：它核心价值到底是不是多了个搜索？用的可能是什么模型？成本是不是很高？文章是不是偏推广？
这件事的价值是：我不只是“读懂文章”，还能快速形成产品判断。流程图帮助我看结构，追问帮助我识别文章里没讲清楚的地方。
对我这种既做内容又做企业 AI 方案的人来说，这类能力很有用。它可以把一篇软文拆成一个可判断的产品逻辑，而不是被文章表述牵着走。
如果只看单个场景，好像都是一些抓取、总结、分类、归档的小动作。
但把它们串起来之后，意义就不一样了。
它解决的是内容生产的上游问题：素材从哪里来，怎么拿下来，怎么变成知识库，怎么分类，怎么提取场景，怎么反哺选题和业务判断。
我现在更像是在搭一条内容输入和素材加工流水线。
前面有公众号、网页、GitHub、小红书、播客、视频、付费专栏这些信息源。中间有抓取、清洗、归档、去重、分类、摘要、抽取。后面有选题、培训素材、场景库、流程图、产品判断和文章写作。
这套体系里有几个关键原则。
1. 不要只收藏，要抓下来
收藏夹里的内容，大多数最后都不会再看。真正有用的内容，应该进入自己的知识库，变成可检索、可总结、可复用的文件。
2. 不要只抓正文，要保留结构
一篇文章只有正文还不够。标题、作者、发布时间、来源链接、摘要、标签、主题分类，都应该一起保留。这样后面做检索和引用时，才不会变成一堆无来源文本。
3. 批量内容必须结构化
几百篇文章如果只是存成 Markdown，价值有限。必须继续做分类、打标、摘要和场景抽取。结构化之后，内容才会从“资料堆”变成“素材库”。
4. 素材要和业务线接起来
我抓文章不是为了单纯囤资料，而是为了服务后续写作、培训、咨询和产品设计。所以每篇文章最好都能回答一个问题：它能变成什么选题？能支持哪个观点？能进入哪个案例库？能不能变成客户方案里的一个场景？
5. Claude Code 更适合做素材工程
普通 AI 聊天工具也可以总结一篇文章。但 Claude Code 更适合做完整素材工程：抓网页、读文件、跑脚本、批量处理、生成 JSON、写入 Obsidian 或飞书、再反过来支撑写作。
这也是我越来越明确的一点：内容创作的前提是内容资产化。没有稳定的素材输入和整理流程，后面的写作一定会越来越虚。
本文由人人都是产品经理作者【Aaron】，微信公众号：【曾俊AI实战笔记】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。