最近我把一个一直靠人工复制粘贴才能完成的工作交给Coze工作流自动跑掉了输入一个文章链接代码节点自动抓取网页内容再由大模型按要求提炼出摘要、关键词和结构化要点。整个过程我几乎没有手写代码核心逻辑是直接在Coze代码节点里靠AI编程把爬取解析的脚本生成出来。这个实践非常适合刚开始接触Coze基础节点的人尤其是运营、产品、研究岗或者任何需要经常“读网页、存资料、整理内容”的朋友。今天这篇文章就把我从需求拆解、工作流搭建、代码调试到踩坑恢复的完整过程记录下来希望能帮少走一点弯路。1. 这个需求到底怎么拆解从链接到文章信息1.1 原始痛点为什么不能直接复制粘贴这个项目的出发点非常简单就是“给我一个链接自动吐出这篇文章的核心信息”。听起来像浏览器自带功能就能做到但当你需要稳定地、批量地、可定制地处理内容时人工复制粘贴的劣势就暴露了。举一个我经常遇到的实际场景收藏夹里有几十篇文章链接我需要把每篇的关键论点、数据案例、行动建议提取出来整理成周报。以前的操作是逐个打开链接、全选复制、粘贴到编辑器、删掉广告和无关模块、再手动调整格式。一篇两篇还行十几篇就会非常痛苦。更别提炼好的内容还经常因为格式问题从网页复制到Word时出现一堆换行符和表格乱码。所以本质上这是一个内容自动化预处理需求把不可控的HTML网页变成干净、结构化、可供下游任务摘要、分类、翻译、存储直接使用的文本。Coze工作流正好能承担这件事因为它不仅有现成的插件节点还有一个可编程的代码节点。后者给了我们极高的自由度可以根据自己的规则来抓取和清洗内容。1.2 方案对比网页阅读器插件 vs 代码节点Coze平台里其实有一个“网页阅读器”之类的插件能力或者是在Bot里直接粘贴链接让它自动阅读。那我为什么还要用代码节点自己做我当时的判断是这样的维度现成网页阅读器/插件代码节点自研上手难度低拖拽即用中需要一点Python/JS基础或会提提示词提取规则黑盒内部逻辑不可控可控可精准定位article标签或指定class输出格式通常返回整页文本可能包含广告可按需清洗输出纯净正文扩展能力弱基本只能“读”强可以顺便写摘要、转Markdown、转Word稳定性遇到反爬或动态渲染时也容易失效可以通过自定义Headers、超时、重试来优化这里不是否定现成插件而是说当你要把“读文章”这个动作嵌入到一条业务处理链中并且想对每一步负责时代码节点是更合适的底座。它给你的是“处理函数”而不只是一个“结果”。1.3 流程设计五个节点组成一条内容流水线我最终搭出来的工作流是一条很典型的Coze流水线五个节点各司其职开始节点定义入参只需要一个url字段。代码节点核心接收url请求HTML解析出标题和正文。大模型节点用提示词对正文做摘要、提取关键词、整理行动项。结束节点把处理后的结构化JSON返回给前端或Bot。可选的判断节点如果代码节点返回错误码则直接走失败提示分支。整体逻辑简单但不简陋。真正花时间的是第二步“代码节点”因为它决定了上游数据质量。如果抓回来的正文是乱码、半截、夹杂大量广告后面大模型再怎么聪明也白搭。所以下面有必要花大篇幅讲清楚代码节点怎么写、为什么这样写。2. 项目启动准备工作流环境与基础参数2.1 最小可用的Coze工作流长什么样如果你是第一次接触Coze工作流先别急着想复杂场景从最小闭环开始就行。进入Coze控制台创建一个空白工作流界面一般分三块左侧节点面板、中间画布、右侧参数配置区。在这个项目中我从“开始”节点里加了一个字段参数名我建议用url类型选String勾选必填。这样每次调用工作流时只需要传一个字符串链接比如https://example.com/some-article流程就能跑起来。有人会在这一步纠结要不要加title参数其实没必要因为标题可以通过代码自动从HTML里解析出来。2.2 开始节点一个url参数就够了为什么只定义一个参数因为职责单一输入越少工作流越容易复用。如果你把“来源类型”“是否深度阅读”“输出字数”这些也都做成参数后面使用起来会复杂很多。当然有些情况确实需要额外参数比如当目标网站需要登录Cookie时可以增加一个cookie字段再比如某些页面有不同版本可能需要传language。但初次实践不需要这些。把参数把守在最少的url让代码节点先跑通再逐步加参数这是非常推荐的节奏。2.3 代码节点的运行环境Python依赖配置在Coze代码节点里你会看到它支持Python和JavaScript两种语言我选Python。原因是Python在HTML解析这块生态太成熟了requests负责网络请求BeautifulSoup负责DOM解析两行代码就能完成80%的工作。不过要注意Coze代码节点并不是一个完全不受限的Python环境。你需要明确声明依赖包。通常节点上会有一个“依赖”或者“安装包”的区域在这里手动补充需要的第三方库。我的经验是网络请求requests简单、够用HTML解析beautifulsoup4正则清洗rePython内置无需额外声明至于lxml虽然BeautifulSoup搭配lxml解析速度更快但我在Coze节点里遇到过依赖冲突所以退回了默认的html.parser。对于单篇文章抓取性能差异几乎可以忽略。这里的原则是用最小依赖集实现功能能少一个包就少一个包避免在云端环境里给自己找麻烦。3. 代码节点实战AI生成抓取代码的完整过程3.1 让AI生成代码的提示词模板这是本篇标题里“AI编程”最关键的部分。所谓AI编程在这里不是指用Cursor写一个完整Web项目而是在Coze代码节点里用自然语言让大模型为你生成一段可直接运行的Python函数。我在实际操作时不是自己从头敲代码而是先打开一个AI对话把需求说清楚。经过几次调整我总结出一个比较可靠的提示词模板你可以直接搬运你是Python工程师。请帮我写一个Coze代码节点可运行的Python函数入口函数为main(args)。args是一个dict里面有一个属性url。函数需要完成这些任务判断url是否为空为空时返回错误码。使用requests请求该URL带上常见的浏览器User-Agent。处理中文网页乱码问题使用响应对象的apparent_encoding。用BeautifulSoup解析HTML优先提取article标签内正文如果没有article则提取body。移除正文里的script、style、nav、footer、aside、iframe标签。把正文文本按换行拼接压缩连续空行。如果正文长度超过8000字符截断。返回一个dict包含字段code、msg、title、content、length。请求出错时code为1msg为错误信息。请直接输出完整代码不要解释。这个提示词好在哪里它把输入、输出、异常分支、约束条件全部说清楚了。你不需要懂BeautifulSoup的每个方法只需要告诉大模型“优先article”“删掉干扰标签”“中文编码要处理”它就能生成相当可靠的脚本。3.2 完整代码与逐行解释AI当时生成的代码和下面这个版本高度相似。我后来手工微调过一些边界情况最终形成了一段我在Coze节点里稳定跑通的方案import requests from bs4 import BeautifulSoup import re def main(args: dict) - dict: url args.get(url, ) if not url: return {code: 1, msg: url为空, title: , content: } headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36 } try: resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() except Exception as e: return {code: 1, msg: f请求失败: {e}, title: , content: } resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, html.parser) title soup.title.get_text(stripTrue) if soup.title else url article soup.find(article) or soup.body if article is None: article soup for tag in article.find_all([script, style, nav, footer, aside, iframe]): tag.decompose() content article.get_text(\n, stripTrue) content re.sub(r\n{3,}, \n\n, content) max_len 8000 if len(content) max_len: content content[:max_len] return {code: 0, msg: ok, title: title, content: content, length: len(content)}我逐个环节说一下设计考量headers里的User-Agent伪装非常必要。很多网站会拦截不带UA的直接请求加了浏览器UA之后请求成功率高很多。timeout10是为了防止某个页面卡住整个工作流。云端节点通常有执行时间上限一个请求能把几秒钟全部耗尽所以超时一定要设。resp.encoding resp.apparent_encoding这行是处理中文乱码的关键。有些页面没有正确声明charset直接使用默认编码会得到一堆乱码。soup.find(article) or soup.body是“优先正文区域”的策略。多数内容型网站都有article标签但它不是HTML规范强制要求的没有时退回body再清洗。删除干扰标签时用了一个列表批量操作。decompose()会彻底移除节点避免后续文字拼接时混入广告和版权声明。用get_text(\n, stripTrue)把段落转成带换行的纯文本比直接.text更干净。最后截断到8000字符是为了给下游的大模型节点留出上下文空间。如果你的文章很长全部塞给大模型很可能导致超出限制或费用飙升所以在源头控制长度更合理。3.3 返回数据设计让大模型节点能直接消费代码节点处理完输出应该是一个JSON对象。Coze后续节点会通过类似{{代码节点名.content}}的方式引用内部字段。所以返回结构必须稳定。我返回的字段设计为{ code: 0, msg: ok, title: 文章的标题, content: 清洗后的正文文本, length: 3521 }code和msg为错误处理留下了空间。当请求失败时content会变成空字符串这样下游大模型节点也能正常处理而不是直接报错中断整条流。下游的大模型节点我建议这样接把“代码节点”的title和content引用到系统提示词里然后让模型输出请根据下面文章内容生成三段式摘要第一段用三句话说清楚核心观点第二段列出5个关键细节第三段给出可行行动建议。文章标题{{代码节点.title}}。正文{{代码节点.content}}。这样一条“链接进摘要出”的自动化流程就闭环了。4. 实测数据与参数调优从跑通到稳定4.1 首轮测试暴露的问题第一次运行我用了一篇比较规范的技术公开文章作为测试对象。结果是标题抓对了正文也抓到了但我立刻发现三个问题。第一个问题是某些页面返回的正文包含大量多余空行和版权信息。虽然代码里已经压缩了连续空行但“保留所有文本”策略会把页脚部分“上一篇推荐”“相关阅读”“关于我们”这类干扰信息也带进来。这是因为有的网站没有使用article标签直接从body提取自然会把页脚都算进去。第二个问题是编码。测试页面是UTF-8声明但resp.apparent_encoding在某些场景下返回的是ISO-8859-1导致中文乱码。后来我调整成了“优先看响应头里的charset其次用apparent_encoding都不行就强制utf-8”的处理逻辑虽然代码变复杂了一点但乱码问题基本消除。第三个问题更实际超时。Coze代码节点对单次执行时间有限制而有些文章页面图片很多、HTML体积巨大requests默认的下载时间完全可能耗时过长。我们需要在requests.get上显式设置timeout同时可以考虑用流式下载或只读取前几百KB的HTML文本避免下载整个大页面。4.2 关键参数的最佳实践经过几轮调试我把一些关键参数和取值记了下来形成了一张速查表后面再搭类似功能直接照抄参数项推荐取值说明timeout10秒兼顾等待时间和失败概率max_len8000字符避免下游大模型上下文溢出User-AgentChrome浏览器UA大幅降低被403拦截的概率编码方式响应头charset优先比无脑apparent_encoding更稳定依赖包requests beautifulsoup4够用且体积小解析器html.parser兼容性最好避免依赖冲突4.3 动态渲染页面怎么处理这是代码节点抓取方案的一个天然短板。如果目标页面是纯静态渲染这段代码很好用但如果页面是Vue、React这类前端框架通过JavaScript动态渲染内容那requests拿到的HTML里根本没有正文只有一个空的div idapp。我遇到这种情况的解决方案有三条按优先顺序说看有没有现成的接口。很多动态网站虽然页面是JS渲染但数据其实来自一个公开的JSON接口。用浏览器F12看Network面板找到返回真实数据的XHR请求直接请求这个接口比解析网页省事得多。换Coze里的浏览器节点或插件。有些插件能模拟真实浏览器渲染虽然是笨办法但在少量链接时非常可靠。让代码节点调用无头浏览器API。比如通过第三方云服务把URL渲染成静态HTML。这不是首选因为会引入额外成本和延迟。所以我现在的工作流里其实保留了一个分支判断静态页面走代码节点动态页面走浏览器插件。两个入口都能产出正文文本最终汇合到大模型节点。5. 常见问题速查我替你踩过这些坑5.1 高频报错与解决办法把我在Coze代码节点调试过程中遇到的典型问题整理成了一张速查表碰到相同现象可以直接对应处理问题现象可能原因解决方案返回url为空开始节点参数名与代码里key不一致把代码里args.get(url)改成和节点参数一致编码乱码页面charset声明错误用apparent_encoding或强制UTF-8请求超时页面过大或网络慢增加timeout提升到10秒对超大页面只取前部分被403拒绝网站反爬拦截添加UA和Referer必要时带上Cookie下载了很多HTML但content为空页面是JS动态渲染改用浏览器插件或找真实数据接口返回文本包含广告和页脚页面没有article标签从body提取了全部内容增加基于class/id的正文区域选择规则正文被截断max_len太小调大max_len或让大模型分段处理依赖找不到代码节点未声明第三方包在依赖配置中增加beautifulsoup4、requests连续运行被限流高频请求目标网站增加延迟或批处理间隔结果里title为空页面无标签/td td回退为URL或尝试h1标题/td /tr /tbody /table h35.2 内容抓取质量不稳定怎么办/h3 p如果你发现同一套代码抓A网站很干净抓B网站却带了一堆侧边栏内容别再盲目加通用清洗规则了。我的经验是strong对不同网站维护一套轻量级的“正文区域规则”/strong。/p p方法很朴素。在代码节点里引入一个可选的 codecontent_selector/code 参数允许调用方传入一个CSS选择器或class名。当传入规则时优先按照这个规则定位正文没有规则时才走默认的 codearticle/code 或 codebody/code 逻辑。这样既保持了通用性又能在处理重点网站时精准发力。/p pCoze代码节点里做选择器匹配可以用BeautifulSoup的 codeselect/code 或 codefind/code。比如传入 codediv.article-content/code代码就会去查找首个匹配该选择器的节点。这个字段在Bot对话里可以被用户直接填写灵活度很高。/p h35.3 合规与频率控制/h3 p这一点我必须单独强调无论工作流多方便都只应该处理你有权访问的页面并且要遵守目标网站的robots协议和服务条款。别把代码节点变成一台无休止抓取的爬虫机器那不仅可能给目标网站带来压力也可能让你的Coze账号被平台风控。/p p我在批量处理链接时会刻意在流程里加入间隔控制。如果一次任务要处理好几个链接我的习惯是用Coze的循环或等待节点让每次请求之间至少隔上几秒钟降低对源站的影响。这既是技术上的自我保护也是基本的互联网礼仪。/p h26. 把这个能力变成更多工作流扩展思路/h2 h36.1 一键把抓取的正文转成Word或PDF/h3 p代码节点抓取到的“干净文本”是非常优质的中转产物下游不只是可以接大模型还能接文档处理。/p p我参考网上很流行的“markdown转word工作流coze”思路做了一条升级版代码节点把正文清洗后交给大模型节点先生成Markdown格式结构化笔记再通过一个文档转换节点把Markdown转成Word。这样我就拥有了一条“文章链接 → 结构化笔记 → Word文档”的完整内容归档流水线。/p p实际体验下来这条流非常适合做会议纪要整理、课程讲义收集、竞品文章归档。以前要花20分钟做的事现在扔个链接进去不到两分钟就能拿到一份排版干净的Word稿。/p h36.2 批量处理链接列表与压力控制/h3 p有人问Coze能不能做压力测试这里所谓压力测试更多是指“能不能一次性丢几十个链接进去跑”。我的建议是不要在工作流里用并发直接暴力请求而是通过循环节点逐条处理每个循环内部加一个等待节点。/p p在Coze里可以用循环节点把 codeurl_list/code 一个一个喂给代码节点处理完一个就把结果追加到汇总数组里。由于循环天然是串行的请求频率会比较温和配合等待节点比自动并发更安全。虽然后者更快但触发限流或被目标站点封禁的风险也更大。/p h36.3 与本地AI编程工具的差异化/h3 p最后顺带说下“AI编程”这个话题。最近大家都在讨论Cursor、Windsurf、VS Code Copilot、Trae谁更强这些本地工具当然很强大但它们解决的是“在IDE里写代码”的场景。而Coze代码节点里的AI编程本质是“在云端流程里快速生成一段处理函数”它不追求工程级代码质量而是追求快速、可运行、可与其他节点拼装。/p p我个人的体会是两者并不冲突。复杂的算法和大型项目用Cursor这类本地工具搞定Coze工作流里这种50行以内的小函数直接让大模型生成反而更高效。连IDE都不用打开在节点配置界面里就能完成“提示词→代码→运行验证”的闭环这很符合自动化流程工具的定位。/p h27. 收尾一点真实体验/h2 p这个项目不大但它让我真正理解了AI编程在日常自动化里的价值。我以前遇到“要写个爬虫脚本”的第一反应是打开文档查requests和BeautifulSoup现在我会直接告诉大模型需求让它在几十秒内给我一版代码我再花几分钟检查边界情况比如空值、超时、编码。这种“AI生成初稿人类负责约束”的协作方式在过去是没法想象的。/p p我现在已经把这条工作流用在两个地方一个是整理了收藏夹里两百多篇长文做成摘要数据库另一个是把朋友发来的聊天式长文链接自动变成结构化行动清单。后面还打算把RSS订阅源接进去让内容整理真正变成一条无人值守的流水线。如果你也经常被“网页上的好内容怎么存下来”这件事困扰强烈建议照着我这套思路试一次Code节点用AI编程并没有想象中那么难跑通那一刻还挺有成就感的。/p
用Coze工作流+AI编程实现网页内容自动摘要与结构化提取
最近我把一个一直靠人工复制粘贴才能完成的工作交给Coze工作流自动跑掉了输入一个文章链接代码节点自动抓取网页内容再由大模型按要求提炼出摘要、关键词和结构化要点。整个过程我几乎没有手写代码核心逻辑是直接在Coze代码节点里靠AI编程把爬取解析的脚本生成出来。这个实践非常适合刚开始接触Coze基础节点的人尤其是运营、产品、研究岗或者任何需要经常“读网页、存资料、整理内容”的朋友。今天这篇文章就把我从需求拆解、工作流搭建、代码调试到踩坑恢复的完整过程记录下来希望能帮少走一点弯路。1. 这个需求到底怎么拆解从链接到文章信息1.1 原始痛点为什么不能直接复制粘贴这个项目的出发点非常简单就是“给我一个链接自动吐出这篇文章的核心信息”。听起来像浏览器自带功能就能做到但当你需要稳定地、批量地、可定制地处理内容时人工复制粘贴的劣势就暴露了。举一个我经常遇到的实际场景收藏夹里有几十篇文章链接我需要把每篇的关键论点、数据案例、行动建议提取出来整理成周报。以前的操作是逐个打开链接、全选复制、粘贴到编辑器、删掉广告和无关模块、再手动调整格式。一篇两篇还行十几篇就会非常痛苦。更别提炼好的内容还经常因为格式问题从网页复制到Word时出现一堆换行符和表格乱码。所以本质上这是一个内容自动化预处理需求把不可控的HTML网页变成干净、结构化、可供下游任务摘要、分类、翻译、存储直接使用的文本。Coze工作流正好能承担这件事因为它不仅有现成的插件节点还有一个可编程的代码节点。后者给了我们极高的自由度可以根据自己的规则来抓取和清洗内容。1.2 方案对比网页阅读器插件 vs 代码节点Coze平台里其实有一个“网页阅读器”之类的插件能力或者是在Bot里直接粘贴链接让它自动阅读。那我为什么还要用代码节点自己做我当时的判断是这样的维度现成网页阅读器/插件代码节点自研上手难度低拖拽即用中需要一点Python/JS基础或会提提示词提取规则黑盒内部逻辑不可控可控可精准定位article标签或指定class输出格式通常返回整页文本可能包含广告可按需清洗输出纯净正文扩展能力弱基本只能“读”强可以顺便写摘要、转Markdown、转Word稳定性遇到反爬或动态渲染时也容易失效可以通过自定义Headers、超时、重试来优化这里不是否定现成插件而是说当你要把“读文章”这个动作嵌入到一条业务处理链中并且想对每一步负责时代码节点是更合适的底座。它给你的是“处理函数”而不只是一个“结果”。1.3 流程设计五个节点组成一条内容流水线我最终搭出来的工作流是一条很典型的Coze流水线五个节点各司其职开始节点定义入参只需要一个url字段。代码节点核心接收url请求HTML解析出标题和正文。大模型节点用提示词对正文做摘要、提取关键词、整理行动项。结束节点把处理后的结构化JSON返回给前端或Bot。可选的判断节点如果代码节点返回错误码则直接走失败提示分支。整体逻辑简单但不简陋。真正花时间的是第二步“代码节点”因为它决定了上游数据质量。如果抓回来的正文是乱码、半截、夹杂大量广告后面大模型再怎么聪明也白搭。所以下面有必要花大篇幅讲清楚代码节点怎么写、为什么这样写。2. 项目启动准备工作流环境与基础参数2.1 最小可用的Coze工作流长什么样如果你是第一次接触Coze工作流先别急着想复杂场景从最小闭环开始就行。进入Coze控制台创建一个空白工作流界面一般分三块左侧节点面板、中间画布、右侧参数配置区。在这个项目中我从“开始”节点里加了一个字段参数名我建议用url类型选String勾选必填。这样每次调用工作流时只需要传一个字符串链接比如https://example.com/some-article流程就能跑起来。有人会在这一步纠结要不要加title参数其实没必要因为标题可以通过代码自动从HTML里解析出来。2.2 开始节点一个url参数就够了为什么只定义一个参数因为职责单一输入越少工作流越容易复用。如果你把“来源类型”“是否深度阅读”“输出字数”这些也都做成参数后面使用起来会复杂很多。当然有些情况确实需要额外参数比如当目标网站需要登录Cookie时可以增加一个cookie字段再比如某些页面有不同版本可能需要传language。但初次实践不需要这些。把参数把守在最少的url让代码节点先跑通再逐步加参数这是非常推荐的节奏。2.3 代码节点的运行环境Python依赖配置在Coze代码节点里你会看到它支持Python和JavaScript两种语言我选Python。原因是Python在HTML解析这块生态太成熟了requests负责网络请求BeautifulSoup负责DOM解析两行代码就能完成80%的工作。不过要注意Coze代码节点并不是一个完全不受限的Python环境。你需要明确声明依赖包。通常节点上会有一个“依赖”或者“安装包”的区域在这里手动补充需要的第三方库。我的经验是网络请求requests简单、够用HTML解析beautifulsoup4正则清洗rePython内置无需额外声明至于lxml虽然BeautifulSoup搭配lxml解析速度更快但我在Coze节点里遇到过依赖冲突所以退回了默认的html.parser。对于单篇文章抓取性能差异几乎可以忽略。这里的原则是用最小依赖集实现功能能少一个包就少一个包避免在云端环境里给自己找麻烦。3. 代码节点实战AI生成抓取代码的完整过程3.1 让AI生成代码的提示词模板这是本篇标题里“AI编程”最关键的部分。所谓AI编程在这里不是指用Cursor写一个完整Web项目而是在Coze代码节点里用自然语言让大模型为你生成一段可直接运行的Python函数。我在实际操作时不是自己从头敲代码而是先打开一个AI对话把需求说清楚。经过几次调整我总结出一个比较可靠的提示词模板你可以直接搬运你是Python工程师。请帮我写一个Coze代码节点可运行的Python函数入口函数为main(args)。args是一个dict里面有一个属性url。函数需要完成这些任务判断url是否为空为空时返回错误码。使用requests请求该URL带上常见的浏览器User-Agent。处理中文网页乱码问题使用响应对象的apparent_encoding。用BeautifulSoup解析HTML优先提取article标签内正文如果没有article则提取body。移除正文里的script、style、nav、footer、aside、iframe标签。把正文文本按换行拼接压缩连续空行。如果正文长度超过8000字符截断。返回一个dict包含字段code、msg、title、content、length。请求出错时code为1msg为错误信息。请直接输出完整代码不要解释。这个提示词好在哪里它把输入、输出、异常分支、约束条件全部说清楚了。你不需要懂BeautifulSoup的每个方法只需要告诉大模型“优先article”“删掉干扰标签”“中文编码要处理”它就能生成相当可靠的脚本。3.2 完整代码与逐行解释AI当时生成的代码和下面这个版本高度相似。我后来手工微调过一些边界情况最终形成了一段我在Coze节点里稳定跑通的方案import requests from bs4 import BeautifulSoup import re def main(args: dict) - dict: url args.get(url, ) if not url: return {code: 1, msg: url为空, title: , content: } headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36 } try: resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() except Exception as e: return {code: 1, msg: f请求失败: {e}, title: , content: } resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, html.parser) title soup.title.get_text(stripTrue) if soup.title else url article soup.find(article) or soup.body if article is None: article soup for tag in article.find_all([script, style, nav, footer, aside, iframe]): tag.decompose() content article.get_text(\n, stripTrue) content re.sub(r\n{3,}, \n\n, content) max_len 8000 if len(content) max_len: content content[:max_len] return {code: 0, msg: ok, title: title, content: content, length: len(content)}我逐个环节说一下设计考量headers里的User-Agent伪装非常必要。很多网站会拦截不带UA的直接请求加了浏览器UA之后请求成功率高很多。timeout10是为了防止某个页面卡住整个工作流。云端节点通常有执行时间上限一个请求能把几秒钟全部耗尽所以超时一定要设。resp.encoding resp.apparent_encoding这行是处理中文乱码的关键。有些页面没有正确声明charset直接使用默认编码会得到一堆乱码。soup.find(article) or soup.body是“优先正文区域”的策略。多数内容型网站都有article标签但它不是HTML规范强制要求的没有时退回body再清洗。删除干扰标签时用了一个列表批量操作。decompose()会彻底移除节点避免后续文字拼接时混入广告和版权声明。用get_text(\n, stripTrue)把段落转成带换行的纯文本比直接.text更干净。最后截断到8000字符是为了给下游的大模型节点留出上下文空间。如果你的文章很长全部塞给大模型很可能导致超出限制或费用飙升所以在源头控制长度更合理。3.3 返回数据设计让大模型节点能直接消费代码节点处理完输出应该是一个JSON对象。Coze后续节点会通过类似{{代码节点名.content}}的方式引用内部字段。所以返回结构必须稳定。我返回的字段设计为{ code: 0, msg: ok, title: 文章的标题, content: 清洗后的正文文本, length: 3521 }code和msg为错误处理留下了空间。当请求失败时content会变成空字符串这样下游大模型节点也能正常处理而不是直接报错中断整条流。下游的大模型节点我建议这样接把“代码节点”的title和content引用到系统提示词里然后让模型输出请根据下面文章内容生成三段式摘要第一段用三句话说清楚核心观点第二段列出5个关键细节第三段给出可行行动建议。文章标题{{代码节点.title}}。正文{{代码节点.content}}。这样一条“链接进摘要出”的自动化流程就闭环了。4. 实测数据与参数调优从跑通到稳定4.1 首轮测试暴露的问题第一次运行我用了一篇比较规范的技术公开文章作为测试对象。结果是标题抓对了正文也抓到了但我立刻发现三个问题。第一个问题是某些页面返回的正文包含大量多余空行和版权信息。虽然代码里已经压缩了连续空行但“保留所有文本”策略会把页脚部分“上一篇推荐”“相关阅读”“关于我们”这类干扰信息也带进来。这是因为有的网站没有使用article标签直接从body提取自然会把页脚都算进去。第二个问题是编码。测试页面是UTF-8声明但resp.apparent_encoding在某些场景下返回的是ISO-8859-1导致中文乱码。后来我调整成了“优先看响应头里的charset其次用apparent_encoding都不行就强制utf-8”的处理逻辑虽然代码变复杂了一点但乱码问题基本消除。第三个问题更实际超时。Coze代码节点对单次执行时间有限制而有些文章页面图片很多、HTML体积巨大requests默认的下载时间完全可能耗时过长。我们需要在requests.get上显式设置timeout同时可以考虑用流式下载或只读取前几百KB的HTML文本避免下载整个大页面。4.2 关键参数的最佳实践经过几轮调试我把一些关键参数和取值记了下来形成了一张速查表后面再搭类似功能直接照抄参数项推荐取值说明timeout10秒兼顾等待时间和失败概率max_len8000字符避免下游大模型上下文溢出User-AgentChrome浏览器UA大幅降低被403拦截的概率编码方式响应头charset优先比无脑apparent_encoding更稳定依赖包requests beautifulsoup4够用且体积小解析器html.parser兼容性最好避免依赖冲突4.3 动态渲染页面怎么处理这是代码节点抓取方案的一个天然短板。如果目标页面是纯静态渲染这段代码很好用但如果页面是Vue、React这类前端框架通过JavaScript动态渲染内容那requests拿到的HTML里根本没有正文只有一个空的div idapp。我遇到这种情况的解决方案有三条按优先顺序说看有没有现成的接口。很多动态网站虽然页面是JS渲染但数据其实来自一个公开的JSON接口。用浏览器F12看Network面板找到返回真实数据的XHR请求直接请求这个接口比解析网页省事得多。换Coze里的浏览器节点或插件。有些插件能模拟真实浏览器渲染虽然是笨办法但在少量链接时非常可靠。让代码节点调用无头浏览器API。比如通过第三方云服务把URL渲染成静态HTML。这不是首选因为会引入额外成本和延迟。所以我现在的工作流里其实保留了一个分支判断静态页面走代码节点动态页面走浏览器插件。两个入口都能产出正文文本最终汇合到大模型节点。5. 常见问题速查我替你踩过这些坑5.1 高频报错与解决办法把我在Coze代码节点调试过程中遇到的典型问题整理成了一张速查表碰到相同现象可以直接对应处理问题现象可能原因解决方案返回url为空开始节点参数名与代码里key不一致把代码里args.get(url)改成和节点参数一致编码乱码页面charset声明错误用apparent_encoding或强制UTF-8请求超时页面过大或网络慢增加timeout提升到10秒对超大页面只取前部分被403拒绝网站反爬拦截添加UA和Referer必要时带上Cookie下载了很多HTML但content为空页面是JS动态渲染改用浏览器插件或找真实数据接口返回文本包含广告和页脚页面没有article标签从body提取了全部内容增加基于class/id的正文区域选择规则正文被截断max_len太小调大max_len或让大模型分段处理依赖找不到代码节点未声明第三方包在依赖配置中增加beautifulsoup4、requests连续运行被限流高频请求目标网站增加延迟或批处理间隔结果里title为空页面无标签/td td回退为URL或尝试h1标题/td /tr /tbody /table h35.2 内容抓取质量不稳定怎么办/h3 p如果你发现同一套代码抓A网站很干净抓B网站却带了一堆侧边栏内容别再盲目加通用清洗规则了。我的经验是strong对不同网站维护一套轻量级的“正文区域规则”/strong。/p p方法很朴素。在代码节点里引入一个可选的 codecontent_selector/code 参数允许调用方传入一个CSS选择器或class名。当传入规则时优先按照这个规则定位正文没有规则时才走默认的 codearticle/code 或 codebody/code 逻辑。这样既保持了通用性又能在处理重点网站时精准发力。/p pCoze代码节点里做选择器匹配可以用BeautifulSoup的 codeselect/code 或 codefind/code。比如传入 codediv.article-content/code代码就会去查找首个匹配该选择器的节点。这个字段在Bot对话里可以被用户直接填写灵活度很高。/p h35.3 合规与频率控制/h3 p这一点我必须单独强调无论工作流多方便都只应该处理你有权访问的页面并且要遵守目标网站的robots协议和服务条款。别把代码节点变成一台无休止抓取的爬虫机器那不仅可能给目标网站带来压力也可能让你的Coze账号被平台风控。/p p我在批量处理链接时会刻意在流程里加入间隔控制。如果一次任务要处理好几个链接我的习惯是用Coze的循环或等待节点让每次请求之间至少隔上几秒钟降低对源站的影响。这既是技术上的自我保护也是基本的互联网礼仪。/p h26. 把这个能力变成更多工作流扩展思路/h2 h36.1 一键把抓取的正文转成Word或PDF/h3 p代码节点抓取到的“干净文本”是非常优质的中转产物下游不只是可以接大模型还能接文档处理。/p p我参考网上很流行的“markdown转word工作流coze”思路做了一条升级版代码节点把正文清洗后交给大模型节点先生成Markdown格式结构化笔记再通过一个文档转换节点把Markdown转成Word。这样我就拥有了一条“文章链接 → 结构化笔记 → Word文档”的完整内容归档流水线。/p p实际体验下来这条流非常适合做会议纪要整理、课程讲义收集、竞品文章归档。以前要花20分钟做的事现在扔个链接进去不到两分钟就能拿到一份排版干净的Word稿。/p h36.2 批量处理链接列表与压力控制/h3 p有人问Coze能不能做压力测试这里所谓压力测试更多是指“能不能一次性丢几十个链接进去跑”。我的建议是不要在工作流里用并发直接暴力请求而是通过循环节点逐条处理每个循环内部加一个等待节点。/p p在Coze里可以用循环节点把 codeurl_list/code 一个一个喂给代码节点处理完一个就把结果追加到汇总数组里。由于循环天然是串行的请求频率会比较温和配合等待节点比自动并发更安全。虽然后者更快但触发限流或被目标站点封禁的风险也更大。/p h36.3 与本地AI编程工具的差异化/h3 p最后顺带说下“AI编程”这个话题。最近大家都在讨论Cursor、Windsurf、VS Code Copilot、Trae谁更强这些本地工具当然很强大但它们解决的是“在IDE里写代码”的场景。而Coze代码节点里的AI编程本质是“在云端流程里快速生成一段处理函数”它不追求工程级代码质量而是追求快速、可运行、可与其他节点拼装。/p p我个人的体会是两者并不冲突。复杂的算法和大型项目用Cursor这类本地工具搞定Coze工作流里这种50行以内的小函数直接让大模型生成反而更高效。连IDE都不用打开在节点配置界面里就能完成“提示词→代码→运行验证”的闭环这很符合自动化流程工具的定位。/p h27. 收尾一点真实体验/h2 p这个项目不大但它让我真正理解了AI编程在日常自动化里的价值。我以前遇到“要写个爬虫脚本”的第一反应是打开文档查requests和BeautifulSoup现在我会直接告诉大模型需求让它在几十秒内给我一版代码我再花几分钟检查边界情况比如空值、超时、编码。这种“AI生成初稿人类负责约束”的协作方式在过去是没法想象的。/p p我现在已经把这条工作流用在两个地方一个是整理了收藏夹里两百多篇长文做成摘要数据库另一个是把朋友发来的聊天式长文链接自动变成结构化行动清单。后面还打算把RSS订阅源接进去让内容整理真正变成一条无人值守的流水线。如果你也经常被“网页上的好内容怎么存下来”这件事困扰强烈建议照着我这套思路试一次Code节点用AI编程并没有想象中那么难跑通那一刻还挺有成就感的。/p
