开篇先聊个现实的场景你是一家做工程装饰或者办公设备供货的小公司老板团队五六个人没有专职销售去盯市场。每天上午负责业务的同事要把各个公共资源交易中心、政府采购网翻一遍把跟公司资质沾边的招标公告复制进Excel再手动筛掉那些已经过期、区域不符、预算太小的单子。这一套下来两三个小时没了还经常漏。我接手过的团队里这是最常见的状态。所以当我用Coze扣子搭出一套“自动盯标”的工作流之后第一个反应是为什么没早点搞这个。这套东西不需要你会写复杂的爬虫代码Coze扣子本身把很多底层能力封装好了你只需要把逻辑串起来告诉大模型你要什么。这篇文章我就把整个搭建过程、踩过的坑、调优的思路全部摊开讲尽量让一个只登录过扣子官网的人也能照着复现。1. 项目整体拆解招标信息自动化的核心思路1.1 传统人工盯标的问题到底出在哪我见过很多企业不是不想获取商机而是获取商机的成本实在太高。招标信息的来源极度分散省市级的公共资源交易平台、采购网、行业垂直网站加上一些企业自有的电子采购系统信息格式五花八门。有的网站有RSS订阅有的只有HTML网页有的连个搜索框都做得极其难用。人工操作的情况下一个人一天能盯住五六个网站已经算高效信息覆盖面和及时性根本没法保证。另一个被忽视的问题是信息判断。招标公告里真正对你有用的核心信息就那么几项招标人、项目名称、预算金额、投标截止时间、资质要求、代理机构联系方式。但公告正文里这些信息往往埋在几百字的背景描述、采购需求、申请人的资格要求里。人看当然能看懂可是每天看几十份上百份注意力一分散关键信息就漏了。更别提那些需要跨省、跨区域去评估的商业机会人工判断的主观性太强容易出现“我觉得这个项目不靠谱”就放弃的情况而实际上数据分析下来机会很大。1.2 为什么用Coze扣子来做这块Coze扣子现在对大多数人来说已经不陌生字节出的智能体开发平台核心卖点是低代码和生态集成。放在这个项目里它有几个天然优势是传统开发方案比不了的。第一个是插件生态和内置能力。你要去抓一个网页上的招标公告传统做法是写Python、配代理、处理反爬麻烦不说维护成本极高。Coze里直接有HTTP请求插件、URL采集插件、RSS订阅插件、公众号监控这些现成节点拖过来配置URL参数就能用。即使公告页面结构变了改个XPath或者重新指定一下内容提取规则就行不用动整个程序。第二个是工作流的可视化编排。Coze的工作流画布就是拖拉拽连线把“定时触发”“爬取信息”“解析文本”“大模型分析”“输出结果”这些节点连成一条线跑起来之后每个环节的输入输出都能看得到。这种透明性对调试太友好。我在传统代码方案里排查一个数据解析问题可能要打半天日志在这里直接在节点上点开结果面板就看明白了。第三个是大模型节点和代码节点可以混合使。做商机评分的时候不能光靠大模型“拍脑袋”最好结合规则约束比如预算低于10万直接淘汰、区域不在经营范围内直接淘汰。Coze里可以用代码节点写过滤逻辑再用大模型节点做语义判断和摘要生成链路清晰可控性也好。2. 工作流整体设计从信息源到商机报告2.1 信息源的选择与分层做这套工作流的第一步不是急着搭节点而是梳理信息源。我做的时候把信息源分成三类核心源、补充源、备用源。核心源是公司主要经营区域内政府公共资源交易中心的公告列表页这类网站优先级最高每天定时爬取频率设成一小时一次。补充源是行业垂直平台比如医疗设备采购、教育装备招标这类专题网站虽然信息重复度高但偶尔会有核心源覆盖不到的。备用源就是RSS订阅和企业官网的公告栏用于捕捉一些不在公共平台发布的采购信息。这里要提醒一个关键点别一上来就贪多。我一开始加了二十几个信息源结果每天的重复信息能占六成大模型处理token费用高还会把分析结果稀释得很严重。后来砍到七个核心源加三个补充源效果反而好很多每条公告的覆盖率也没下降。2.2 工作流的核心链路设计整个工作流我用Coze的Workflow模式搭大体分四层触发层、采集层、分析层、输出层。触发层用的是定时触发器Coze里可以设置每天在固定时间点运行目前支持cron表达式我设置的是周一至周五早上8点半、中午12点、下午5点跑三次。上午8点半这次覆盖前一天夜间和当天凌晨更新的公告中午12点这次覆盖上午新发布的信息下午5点是收尾避免错过半天内新增的项目。如果预算允许跑得更频繁一点效果更好但三到四次已经能覆盖大多数网站的更新节奏。采集层我用了两类节点。一类是URL采集插件直接抓取招标公告列表页把HTML内容转化成Markdown文本方便后续解析。另一类是RSS插件用于支持RSS订阅的网站返回结构化的XML数据解析起来比HTML稳定得多。分析层是大头的部分先经过一个“数据清洗”代码节点把采集到的原始文本去掉广告、导航链接、页脚信息去掉HTML标签残渣再截断超长文本。然后进入一个“信息提取”大模型节点用结构化的Prompt告诉大模型提取哪些字段。到这一步原始文本会变成一个规范化的JSON。输出层根据使用场景做了多路分发。一部分进飞书群机器人推给全员看筛选后的项目摘要一部分写入Coze的表格存储方便每周复盘去重统计本周捕获了多少有效商机还有一部分是大模型生成的日报总结每天下班前汇总当天所有项目的核心看点。2.3 为什么选择工作流而不是单个Bot对话很多人第一次接触Coze习惯先搞一个Bot在对话里让它去查信息。这在临时用一用没问题但要稳定地定时执行、自动化分发必须走工作流。核心原因有三点。一是工作流的状态可追踪。哪个节点失败了、失败原因是什么在日志里一目了然。普通Bot对话里大模型一时兴起给你编一个链接也不是没可能出了问题很难溯源。二是工作流的运行效率和成本可控。Bot对话每次要走完整的对话链路上下文一长token消耗直线上升。工作流里每一步输入输出都按需传递分析环节只截取必要字段喂给大模型成本能低很多。三是工作流可以叠加代码节点做精确处理。比如数字解析、日期格式转换这些逻辑用大模型做既慢又不稳定工作流里写几行Python就解决而且可复现。3. 核心节点详解每个关键环节的实现要点3.1 定时触发器与运行频次设计定时触发器大家都会配但运行频次这个东西深挖下来有讲究。太频繁了信息源还没更新空跑浪费时间太稀疏了可能错过当天下午发布的公告等第二天早晨看到留给准备标书的时间就少了。我实测下来的经验是政府公共资源交易平台的公告发布时间高度集中在工作日上午9点到11点、下午2点半到4点半。所以定时任务设置在工作日12点和17点各跑一次周末不跑基本能覆盖95%以上的有效更新。如果你担心漏掉企业采购平台的信息可以把企业采购类的信息源单独做一个高频工作流每30分钟跑一次因为企业平台的发布时间普遍不规律。3.2 采集节点的信息源配置技巧采集节点是这套工作流里最容易出问题的地方也是最需要耐心调的地方。以URL采集插件为例你给它的URL直接决定能不能拿到有效信息。我踩过最大的坑是拿“公告列表页的URL”当“详情页URL”用。比如在政府采购网上列表页的地址是一串搜索参数每个参数对应的条件变了页面内容完全不同。如果直接用列表页URL做采集拿回来的是整个页面框架和一堆无关列表真正的公告详情一条都看不着。正确的做法是先确认目标网站有没有纯文本版或者移动版很多政府网站有WAP入口页面结构干净很多。如果没有就去详情页抓真实链接结构。再不行就在采集节点后面接一个“二次跳转”逻辑先用列表页拿到每条公告的详情链接再逐个抓详情页。Coze里可以用循环节点实现批量抓详情页只不过对并发数量有限制不要一次性跑超过20个。另外一个技巧是设置User-Agent和请求头。部分网站会拦默认的官方采集UACoze的采集插件里可以自定义请求头把UA伪装成普通浏览器能规避一部分拦截。3.3 正文提取与HTML清洗细节从网页抓回来的内容一般是HTML格式里面夹杂着大量无关标签导航菜单、侧边栏推荐、底部版权、JS脚本、CSS样式。直接喂给大模型一是浪费token二是干扰判断。我的清洗节点里做了这几件事。第一步过滤标签。写一个Python节点用正则或简单的HTML解析库把script、style、header、footer、nav这些标签内容直接去掉。第二步提取主内容区域。招标公告这类页面主内容通常在article或者class含detail的div里可以针对目标网站写几套提取规则做个映射表。第三步压缩空白字符。把连续的换行和空格缩成一个换行让最终文本紧凑可读。这里贴一段我当时写的粗略清洗逻辑参考import re import html def clean_html(content: str) - str: # 去掉脚本和样式 content re.sub(r(?s)script.*?/script, , content) content re.sub(r(?s)style.*?/style, , content) content re.sub(r(?s)!--.*?--, , content) # 去掉标签保留文本 content re.sub(r[^], \n, content) # 处理HTML实体 content html.unescape(content) # 压缩空白 content re.sub(r\n{2,}, \n, content) content re.sub(r[ \t]{2,}, , content) return content.strip()这段代码不复杂但效果很明显。原始的一页HTML大约2万字符清洗后通常只剩4000到8000字符如果公告正文短甚至只有1000字符左右。对后续大模型分析来说这个长度很合适。3.4 大模型信息提取节点的Prompt设计信息提取节点是整个工作流的大脑提取准不准全靠Prompt写得细不细。我试过直接丢给大模型一句“提取这篇公告的关键信息”效果惨不忍睹字段对不上、格式不稳定、漏字段家常便饭。后来我改成“输出固定格式 给例子 给字段要求”的三段式Prompt效果稳定多了。具体是你是一个招标信息结构化解析助手。请阅读以下招标公告原文提取以下字段并输出JSON格式project_name项目名称tenderer招标人/采购人agency招标代理机构无则填未知budget_amount预算金额人民币元无法识别填0deadline投标截止时间格式YYYY-MM-DD HH:MMregion项目所在省市区县qualification_requirements主要资质/资格要求最多三条contact联系方式电话/邮箱summary100字以内项目摘要规则如果公告中没有明确写预算金额不要猜测填0。截止时间以公告正文中明确描述的为准优先取“投标文件递交截止时间”。如果原文没有提供代理机构信息填“未知”。只输出JSON不要输出任何解释文字。加了这个约束之后大模型输出基本是稳定合法的JSON后面接一个JSON解析节点直接转成结构化对象供下游使用。注意JSON解析节点一定要加异常处理逻辑大模型偶尔会有输出瑕疵解析失败不能整个流程宕掉。4. 从零实操在Coze扣子平台完整搭建一次4.1 创建项目与第一步预备动作打开Coze扣子平台后先不要急着点“创建工作流”。我的习惯是先在“资源库”里建一个项目分组把后续会用到的数据表、知识库、素材都归拢进去。比如建一张“招标信息库”数据表字段设计好公告标题、来源网址、发布时间、项目名称、预算金额、截止时间、区域、摘要、状态待跟进/已跟进/已放弃。这些准备动作看着不起眼实际上对后期维护至关重要。否则工作流跑了一周数据表里字段乱了想去重、去统计结果全都对不起。4.2 工作流节点的具体连接步骤进入工作流编辑器后左侧是节点库按类别分组触发、插件、大模型、代码、逻辑、数据库、消息、变量。新建一个空白工作流我给它命名为“商机雷达-招标信息采集分析”。第一步拖入“定时触发器”节点配置cron表达式0 30 8,12,17 * * 1-5含义是每周一至周五的8点30分、12点、17点整点触发。如果你所在地区有节假日的因素比如法定节假日官网基本不更新可以在触发逻辑后加一个判断节点检查当天是否工作日非工作日直接结束。第二步拖入“URL采集”插件节点填写要监控的信息源URL列表。这里我建议在插件节点前加一个“数组”节点把URL列表用参数的形式传进去而不是在每个采集节点里写死。这样后续要增删信息源只要改数组节点就行不用动采集逻辑。第三步把采集回来的HTML文本接入“代码节点”做清洗。这段Python的核心代码上面已经给过你只需要把参数映射好input字段绑定上游采集节点的输出即可。第四步清洗后的文本接入“大模型节点”。模型我选的是Coze平台上的一个通用大模型具体参数如下模型: 豆包・通用大模型或等价可用的长文本模型温度: 0.2低温度保证输出稳定性最大token: 2000Prompt模板: 使用上节提到的三段式第五步大模型输出的JSON字符串经过一个“JSON解析”代码节点转成真正的对象。如果解析失败可以用一个分支节点把失败记录单独存到一个“异常日志表”里方便排查。第六步加入“逻辑判断”节点做初步过滤。过滤条件我用的是如果预算金额 0 且 预算金额 50000则标记为“小额商机”可以选择不推送如果截止时间和系统当前时间差小于2天标记为“紧急商机”如果区域不在设定的业务范围内直接丢弃。这一步能大幅减少噪音。第七步接入“飞书群机器人”消息节点配置Webhook地址推送格式做成这样【紧急商机】XX市XX局办公设备采购项目 预算金额85.00万元 投标截止2026-02-28 09:30 资质要求ISO9001认证本地化服务能力 摘要本项目采购办公电脑、打印机等设备…… 详情链接xxxx第八步最后加一个“数据表写入”节点把结构化JSON写入前面建好的投资信息库带一个“推送时间”字段记录首次推送时间后面人工跟进的时候会产生状态变更。4.3 运行调试与Prompt微调的心得工作流搭好之后第一次跑几乎必然要调。我的调试路径是这样的先单独跑“采集节点清洗代码”看拿回来的文本质量。如果发现文本太乱先固定一个源网站针对它的页面结构调整清洗规则。然后再接入大模型节点跑两条真实数据仔细看提取的JSON。这个阶段我通常会来回改Prompt三四轮。一个典型的调Prompt场景原始提示词里没有规定“budget_amount”的格式结果中文数据串和数字混在一起比如“人民币85万元整”。后来我在规则里加上“必须转成阿拉伯数字单位为人民币元”模型输出就规范了。还有一次提取“deadline”时模型把开标时间当成了投标截止时间。我在规则里明确写了“优先取投标文件递交截止时间没有才取开标时间”问题解决。这类问题你试过一轮就能摸清关键是每次调试后要把教训沉淀成规则加到Prompt里。5. 常见问题与排查实录5.1 采集不到内容或者采集到的是乱码这是我被问得最多的问题。先检查三件事URL对不对、请求头够不够仿真、页面内容是否依赖JavaScript动态加载。政府网站大多还是服务端渲染URL采集插件能直接拿到内容。但有些地方的公共资源交易平台是单页应用内容要通过JS异步刷新普通采集拿不到。针对这种情况我目前的做法是优先找该站的RSS输出或者API接口。很多平台虽然网页用JS渲染但后端有JSON接口直接请求接口比模拟浏览器简单太多。Coze里的HTTP请求插件同样能胜任。如果遇到乱码十有八九是编码问题。部分老旧的政府网站用的是GB2312或者GBK编码Coze插件默认可能按UTF-8解码。遇到这种在代码节点里用response.content.decode(gbk, errorsignore)处理一下就行。所以清洗节点最好保留处理编码的入口。5.2 预算金额识别不准预算金额这个字段大模型经常翻车因为公告里的写法五花八门有的写“预算金额80万元”有的写“项目估算投资约120.5万元”有的写“最高限价为人民币玖拾叁万元整”大写金额还有的干脆不提钱。我的解决思路是分层处理。先用代码做第一层匹配通过正则把常见的“预算金额”“采购预算”“最高限价”后面的数字和单位提取出来再统一换算成“元”。第二层才交给大模型只处理代码层没抓到的情况。这样算下来预算金额的识别准确率能到九成以上关键是大模型不用费力气做算术转换稳定性上去不少。替换这个代码逻辑其实不难核心就是用正则把公告文本里的金额片段抠出来比如import re text 本项目预算金额为人民币柒拾伍万元整 # 括号里加入大写金额映射简化处理时先替换中文大写 upper_to_num {壹:1,贰:2,叁:3,肆:4,伍:5,陆:6,柒:7,捌:8,玖:9,拾:10} for k,v in upper_to_num.items(): text text.replace(k, str(v)) m re.search(r(\d(?:\.\d)?)\s*(万元|元), text) if m: value float(m.group(1)) if m.group(2) 万元: value * 10000 print(int(value))注意不同公告写“万元”“亿元”“元”的单位差异换算系数别写错。这个错误我犯过一次把“0.8亿”算成“8000元”差点把一个大商机当垃圾数据丢掉。5.3 大模型分析结果不稳定同一个公告今天跑出来预算金额是80万明天变成了8000这种问题我遇到过不止一次。后来分析下来根因基本是模型温度和Prompt约束不足。温度参数非常重要。我在信息提取这个场景里把温度调到了0.2或者更低让模型更倾向于保守生成。另外在Prompt里明确写“不要猜测”“不确定填未知”模型的状态会稳定很多。还有一个隐藏因素上下文长度。如果公告原文太长被模型截断尾部信息比如投标截止时间就可能丢失。我的清洗节点里专门加了一段逻辑检测到文本超过6000字符时优先保留包含“截止”“递交”“开标”“资格要求”“预算”“金额”的关键段其余部分删掉。这样既控制token又不丢核心信息。5.4 运行频率受限与资源配额免费版Coze对每小时运行次数有限制如果你的工作流跑得特别频繁很容易触发限制。我当时的策略是把信息源拆成两组分配两个不同的工作流一组跑高频30分钟一组跑低频每天3次这样单条工作流的配额消耗不会太集中。还有一点是尽量把多个信息源放进一个采集节点减少总节点运行次数。Coze是按节点调用量计费的同样的信息源分散在十个节点里跑和集中在一个节点里循环跑费用差异很大。6. 商机评分机制如何让工作流自己判断“值不值得跟”聊完基础搭建我想再分享一个进阶用法也是这套工作流真正从“信息聚合工具”变成“商机雷达”的关键——给每条商机打分。最开始我的工作流只做信息抓取和摘要推送结果推送群里每天十几条信息大家看着看着就麻木了重要商机反而被淹没。后来我加了一个“商机评分”大模型节点把评分规则前置让工作流自己判断这条公告的“质量分”和“匹配度”。评分维度我设计了三种区域匹配度项目所在地区是否在公司主营业务覆盖范围内范围内打1分范围外打0分。金额吸引力预算金额与公司过往中标金额中位数的比值越接近1分越高。比如公司过去中标的中位数是50万那一个80万的项目分数就比20万的高。资质匹配度把公司拥有的资质关键词和公告里的“投标人资格要求”对比命中越多分越高。这三个维度的原始计算我用代码节点来算避免大模型算数。最后让大模型只做一件事基于这三个分数给出一个综合评级A/B/C并输出推荐理由。规则是综合分高于2.5且资质命中数大于等于2评级为A。加了这个机制之后我推送群里每天的信息量骤降到三四条全部是A级和B级商机团队成员早上打开飞书看一眼就能决定今天要跟进哪几个效率和体验完全不同。评分代码也不复杂关键是要把三个维度统一标到0到1区间我简单用线性归一化处理# 区域匹配度 region_score 1.0 if region in service_areas else 0.0 # 金额吸引力假设最近一年中标金额中位数是500000 amount_score min(1.0, budget_amount / 500000) if budget_amount 0 else 0.0 # 资质匹配度 qualification_score len(hit_qualifications) / len(required_qualifications) if len(required_qualifications) 0: qualification_score 0.5 # 没有明确资质要求时给中间分 total_score (region_score * 0.4 amount_score * 0.3 qualification_score * 0.3) grade A if total_score 0.65 and qualification_score 0.5 else B这个权重不是拍脑袋定的我是结合了团队过往项目复盘得出的结论区域是硬门槛只要做不了金额再大也白搭所以给了0.4金额和资质各0.3。如果你所在的行业更看重资质门槛可以把资质权重往上调。试运行两周之后再根据实际跟单情况微调权重模型会越来越贴合你的业务。7. 我自己的经验与后续扩展思路这套工作流上线跑了将近两个月最大的变化不是省了多少人工而是团队对市场的敏感度完全不一样了。以前是“不知道外面发生了什么”现在每天早上能看到一份自动生成的“商机早报”哪些区域有匹配度高的项目、哪些项目快截止了需要立刻决策心里有数。供应商、联合体、代理机构这些关系链也同步更新了因为我们给代理机构加了一个信息源有它参与代理的项目会被单独标记出来。如果你也想搞一套我的建议是先不要追求大而全挑一个最核心的信息源把链路先跑通。哪怕每天只盯一个网站把“采集→清洗→提取→推送”走顺了再逐步加源、加评分、加输出渠道。一上来就铺二十个源每天光处理报错就够你头疼。后续我觉得可以从三个方向去扩展这套工作流。第一个是增加知识库能力把历史中标公告、企业资质、过往项目经验存入Coze的知识库让大模型在分析商机时能参考历史情况给出更贴近实际的投标策略建议。第二个方向是加入更多样的输出渠道比如推送到钉钉、邮件、甚至短信针对紧急商机单独设置短信提醒。第三个方向是让工作流生成更完整的“标前分析报告”包括竞争格局分析、自身优劣势、报价区间建议这些虽然不能完全替代专业的标书团队但能大幅减少前期调研的时间。说到底Coze扣子这类平台的意义是把过去要请开发写一套系统才能做到的事压缩到一个人一个下午就能搭出雏形。工具门槛降低之后比的不再是谁会写代码而是谁更理解自己所在行业的业务逻辑。把这层想清楚你的商机自动化之路基本就成功一半了。 
长河君 · 2026/9/17 4:27:26 · 阅读 1.2k Coze扣子实战：搭建招标信息自动化监控与商机分析工作流
开篇先聊个现实的场景你是一家做工程装饰或者办公设备供货的小公司老板团队五六个人没有专职销售去盯市场。每天上午负责业务的同事要把各个公共资源交易中心、政府采购网翻一遍把跟公司资质沾边的招标公告复制进Excel再手动筛掉那些已经过期、区域不符、预算太小的单子。这一套下来两三个小时没了还经常漏。我接手过的团队里这是最常见的状态。所以当我用Coze扣子搭出一套“自动盯标”的工作流之后第一个反应是为什么没早点搞这个。这套东西不需要你会写复杂的爬虫代码Coze扣子本身把很多底层能力封装好了你只需要把逻辑串起来告诉大模型你要什么。这篇文章我就把整个搭建过程、踩过的坑、调优的思路全部摊开讲尽量让一个只登录过扣子官网的人也能照着复现。1. 项目整体拆解招标信息自动化的核心思路1.1 传统人工盯标的问题到底出在哪我见过很多企业不是不想获取商机而是获取商机的成本实在太高。招标信息的来源极度分散省市级的公共资源交易平台、采购网、行业垂直网站加上一些企业自有的电子采购系统信息格式五花八门。有的网站有RSS订阅有的只有HTML网页有的连个搜索框都做得极其难用。人工操作的情况下一个人一天能盯住五六个网站已经算高效信息覆盖面和及时性根本没法保证。另一个被忽视的问题是信息判断。招标公告里真正对你有用的核心信息就那么几项招标人、项目名称、预算金额、投标截止时间、资质要求、代理机构联系方式。但公告正文里这些信息往往埋在几百字的背景描述、采购需求、申请人的资格要求里。人看当然能看懂可是每天看几十份上百份注意力一分散关键信息就漏了。更别提那些需要跨省、跨区域去评估的商业机会人工判断的主观性太强容易出现“我觉得这个项目不靠谱”就放弃的情况而实际上数据分析下来机会很大。1.2 为什么用Coze扣子来做这块Coze扣子现在对大多数人来说已经不陌生字节出的智能体开发平台核心卖点是低代码和生态集成。放在这个项目里它有几个天然优势是传统开发方案比不了的。第一个是插件生态和内置能力。你要去抓一个网页上的招标公告传统做法是写Python、配代理、处理反爬麻烦不说维护成本极高。Coze里直接有HTTP请求插件、URL采集插件、RSS订阅插件、公众号监控这些现成节点拖过来配置URL参数就能用。即使公告页面结构变了改个XPath或者重新指定一下内容提取规则就行不用动整个程序。第二个是工作流的可视化编排。Coze的工作流画布就是拖拉拽连线把“定时触发”“爬取信息”“解析文本”“大模型分析”“输出结果”这些节点连成一条线跑起来之后每个环节的输入输出都能看得到。这种透明性对调试太友好。我在传统代码方案里排查一个数据解析问题可能要打半天日志在这里直接在节点上点开结果面板就看明白了。第三个是大模型节点和代码节点可以混合使。做商机评分的时候不能光靠大模型“拍脑袋”最好结合规则约束比如预算低于10万直接淘汰、区域不在经营范围内直接淘汰。Coze里可以用代码节点写过滤逻辑再用大模型节点做语义判断和摘要生成链路清晰可控性也好。2. 工作流整体设计从信息源到商机报告2.1 信息源的选择与分层做这套工作流的第一步不是急着搭节点而是梳理信息源。我做的时候把信息源分成三类核心源、补充源、备用源。核心源是公司主要经营区域内政府公共资源交易中心的公告列表页这类网站优先级最高每天定时爬取频率设成一小时一次。补充源是行业垂直平台比如医疗设备采购、教育装备招标这类专题网站虽然信息重复度高但偶尔会有核心源覆盖不到的。备用源就是RSS订阅和企业官网的公告栏用于捕捉一些不在公共平台发布的采购信息。这里要提醒一个关键点别一上来就贪多。我一开始加了二十几个信息源结果每天的重复信息能占六成大模型处理token费用高还会把分析结果稀释得很严重。后来砍到七个核心源加三个补充源效果反而好很多每条公告的覆盖率也没下降。2.2 工作流的核心链路设计整个工作流我用Coze的Workflow模式搭大体分四层触发层、采集层、分析层、输出层。触发层用的是定时触发器Coze里可以设置每天在固定时间点运行目前支持cron表达式我设置的是周一至周五早上8点半、中午12点、下午5点跑三次。上午8点半这次覆盖前一天夜间和当天凌晨更新的公告中午12点这次覆盖上午新发布的信息下午5点是收尾避免错过半天内新增的项目。如果预算允许跑得更频繁一点效果更好但三到四次已经能覆盖大多数网站的更新节奏。采集层我用了两类节点。一类是URL采集插件直接抓取招标公告列表页把HTML内容转化成Markdown文本方便后续解析。另一类是RSS插件用于支持RSS订阅的网站返回结构化的XML数据解析起来比HTML稳定得多。分析层是大头的部分先经过一个“数据清洗”代码节点把采集到的原始文本去掉广告、导航链接、页脚信息去掉HTML标签残渣再截断超长文本。然后进入一个“信息提取”大模型节点用结构化的Prompt告诉大模型提取哪些字段。到这一步原始文本会变成一个规范化的JSON。输出层根据使用场景做了多路分发。一部分进飞书群机器人推给全员看筛选后的项目摘要一部分写入Coze的表格存储方便每周复盘去重统计本周捕获了多少有效商机还有一部分是大模型生成的日报总结每天下班前汇总当天所有项目的核心看点。2.3 为什么选择工作流而不是单个Bot对话很多人第一次接触Coze习惯先搞一个Bot在对话里让它去查信息。这在临时用一用没问题但要稳定地定时执行、自动化分发必须走工作流。核心原因有三点。一是工作流的状态可追踪。哪个节点失败了、失败原因是什么在日志里一目了然。普通Bot对话里大模型一时兴起给你编一个链接也不是没可能出了问题很难溯源。二是工作流的运行效率和成本可控。Bot对话每次要走完整的对话链路上下文一长token消耗直线上升。工作流里每一步输入输出都按需传递分析环节只截取必要字段喂给大模型成本能低很多。三是工作流可以叠加代码节点做精确处理。比如数字解析、日期格式转换这些逻辑用大模型做既慢又不稳定工作流里写几行Python就解决而且可复现。3. 核心节点详解每个关键环节的实现要点3.1 定时触发器与运行频次设计定时触发器大家都会配但运行频次这个东西深挖下来有讲究。太频繁了信息源还没更新空跑浪费时间太稀疏了可能错过当天下午发布的公告等第二天早晨看到留给准备标书的时间就少了。我实测下来的经验是政府公共资源交易平台的公告发布时间高度集中在工作日上午9点到11点、下午2点半到4点半。所以定时任务设置在工作日12点和17点各跑一次周末不跑基本能覆盖95%以上的有效更新。如果你担心漏掉企业采购平台的信息可以把企业采购类的信息源单独做一个高频工作流每30分钟跑一次因为企业平台的发布时间普遍不规律。3.2 采集节点的信息源配置技巧采集节点是这套工作流里最容易出问题的地方也是最需要耐心调的地方。以URL采集插件为例你给它的URL直接决定能不能拿到有效信息。我踩过最大的坑是拿“公告列表页的URL”当“详情页URL”用。比如在政府采购网上列表页的地址是一串搜索参数每个参数对应的条件变了页面内容完全不同。如果直接用列表页URL做采集拿回来的是整个页面框架和一堆无关列表真正的公告详情一条都看不着。正确的做法是先确认目标网站有没有纯文本版或者移动版很多政府网站有WAP入口页面结构干净很多。如果没有就去详情页抓真实链接结构。再不行就在采集节点后面接一个“二次跳转”逻辑先用列表页拿到每条公告的详情链接再逐个抓详情页。Coze里可以用循环节点实现批量抓详情页只不过对并发数量有限制不要一次性跑超过20个。另外一个技巧是设置User-Agent和请求头。部分网站会拦默认的官方采集UACoze的采集插件里可以自定义请求头把UA伪装成普通浏览器能规避一部分拦截。3.3 正文提取与HTML清洗细节从网页抓回来的内容一般是HTML格式里面夹杂着大量无关标签导航菜单、侧边栏推荐、底部版权、JS脚本、CSS样式。直接喂给大模型一是浪费token二是干扰判断。我的清洗节点里做了这几件事。第一步过滤标签。写一个Python节点用正则或简单的HTML解析库把script、style、header、footer、nav这些标签内容直接去掉。第二步提取主内容区域。招标公告这类页面主内容通常在article或者class含detail的div里可以针对目标网站写几套提取规则做个映射表。第三步压缩空白字符。把连续的换行和空格缩成一个换行让最终文本紧凑可读。这里贴一段我当时写的粗略清洗逻辑参考import re import html def clean_html(content: str) - str: # 去掉脚本和样式 content re.sub(r(?s)script.*?/script, , content) content re.sub(r(?s)style.*?/style, , content) content re.sub(r(?s)!--.*?--, , content) # 去掉标签保留文本 content re.sub(r[^], \n, content) # 处理HTML实体 content html.unescape(content) # 压缩空白 content re.sub(r\n{2,}, \n, content) content re.sub(r[ \t]{2,}, , content) return content.strip()这段代码不复杂但效果很明显。原始的一页HTML大约2万字符清洗后通常只剩4000到8000字符如果公告正文短甚至只有1000字符左右。对后续大模型分析来说这个长度很合适。3.4 大模型信息提取节点的Prompt设计信息提取节点是整个工作流的大脑提取准不准全靠Prompt写得细不细。我试过直接丢给大模型一句“提取这篇公告的关键信息”效果惨不忍睹字段对不上、格式不稳定、漏字段家常便饭。后来我改成“输出固定格式 给例子 给字段要求”的三段式Prompt效果稳定多了。具体是你是一个招标信息结构化解析助手。请阅读以下招标公告原文提取以下字段并输出JSON格式project_name项目名称tenderer招标人/采购人agency招标代理机构无则填未知budget_amount预算金额人民币元无法识别填0deadline投标截止时间格式YYYY-MM-DD HH:MMregion项目所在省市区县qualification_requirements主要资质/资格要求最多三条contact联系方式电话/邮箱summary100字以内项目摘要规则如果公告中没有明确写预算金额不要猜测填0。截止时间以公告正文中明确描述的为准优先取“投标文件递交截止时间”。如果原文没有提供代理机构信息填“未知”。只输出JSON不要输出任何解释文字。加了这个约束之后大模型输出基本是稳定合法的JSON后面接一个JSON解析节点直接转成结构化对象供下游使用。注意JSON解析节点一定要加异常处理逻辑大模型偶尔会有输出瑕疵解析失败不能整个流程宕掉。4. 从零实操在Coze扣子平台完整搭建一次4.1 创建项目与第一步预备动作打开Coze扣子平台后先不要急着点“创建工作流”。我的习惯是先在“资源库”里建一个项目分组把后续会用到的数据表、知识库、素材都归拢进去。比如建一张“招标信息库”数据表字段设计好公告标题、来源网址、发布时间、项目名称、预算金额、截止时间、区域、摘要、状态待跟进/已跟进/已放弃。这些准备动作看着不起眼实际上对后期维护至关重要。否则工作流跑了一周数据表里字段乱了想去重、去统计结果全都对不起。4.2 工作流节点的具体连接步骤进入工作流编辑器后左侧是节点库按类别分组触发、插件、大模型、代码、逻辑、数据库、消息、变量。新建一个空白工作流我给它命名为“商机雷达-招标信息采集分析”。第一步拖入“定时触发器”节点配置cron表达式0 30 8,12,17 * * 1-5含义是每周一至周五的8点30分、12点、17点整点触发。如果你所在地区有节假日的因素比如法定节假日官网基本不更新可以在触发逻辑后加一个判断节点检查当天是否工作日非工作日直接结束。第二步拖入“URL采集”插件节点填写要监控的信息源URL列表。这里我建议在插件节点前加一个“数组”节点把URL列表用参数的形式传进去而不是在每个采集节点里写死。这样后续要增删信息源只要改数组节点就行不用动采集逻辑。第三步把采集回来的HTML文本接入“代码节点”做清洗。这段Python的核心代码上面已经给过你只需要把参数映射好input字段绑定上游采集节点的输出即可。第四步清洗后的文本接入“大模型节点”。模型我选的是Coze平台上的一个通用大模型具体参数如下模型: 豆包・通用大模型或等价可用的长文本模型温度: 0.2低温度保证输出稳定性最大token: 2000Prompt模板: 使用上节提到的三段式第五步大模型输出的JSON字符串经过一个“JSON解析”代码节点转成真正的对象。如果解析失败可以用一个分支节点把失败记录单独存到一个“异常日志表”里方便排查。第六步加入“逻辑判断”节点做初步过滤。过滤条件我用的是如果预算金额 0 且 预算金额 50000则标记为“小额商机”可以选择不推送如果截止时间和系统当前时间差小于2天标记为“紧急商机”如果区域不在设定的业务范围内直接丢弃。这一步能大幅减少噪音。第七步接入“飞书群机器人”消息节点配置Webhook地址推送格式做成这样【紧急商机】XX市XX局办公设备采购项目 预算金额85.00万元 投标截止2026-02-28 09:30 资质要求ISO9001认证本地化服务能力 摘要本项目采购办公电脑、打印机等设备…… 详情链接xxxx第八步最后加一个“数据表写入”节点把结构化JSON写入前面建好的投资信息库带一个“推送时间”字段记录首次推送时间后面人工跟进的时候会产生状态变更。4.3 运行调试与Prompt微调的心得工作流搭好之后第一次跑几乎必然要调。我的调试路径是这样的先单独跑“采集节点清洗代码”看拿回来的文本质量。如果发现文本太乱先固定一个源网站针对它的页面结构调整清洗规则。然后再接入大模型节点跑两条真实数据仔细看提取的JSON。这个阶段我通常会来回改Prompt三四轮。一个典型的调Prompt场景原始提示词里没有规定“budget_amount”的格式结果中文数据串和数字混在一起比如“人民币85万元整”。后来我在规则里加上“必须转成阿拉伯数字单位为人民币元”模型输出就规范了。还有一次提取“deadline”时模型把开标时间当成了投标截止时间。我在规则里明确写了“优先取投标文件递交截止时间没有才取开标时间”问题解决。这类问题你试过一轮就能摸清关键是每次调试后要把教训沉淀成规则加到Prompt里。5. 常见问题与排查实录5.1 采集不到内容或者采集到的是乱码这是我被问得最多的问题。先检查三件事URL对不对、请求头够不够仿真、页面内容是否依赖JavaScript动态加载。政府网站大多还是服务端渲染URL采集插件能直接拿到内容。但有些地方的公共资源交易平台是单页应用内容要通过JS异步刷新普通采集拿不到。针对这种情况我目前的做法是优先找该站的RSS输出或者API接口。很多平台虽然网页用JS渲染但后端有JSON接口直接请求接口比模拟浏览器简单太多。Coze里的HTTP请求插件同样能胜任。如果遇到乱码十有八九是编码问题。部分老旧的政府网站用的是GB2312或者GBK编码Coze插件默认可能按UTF-8解码。遇到这种在代码节点里用response.content.decode(gbk, errorsignore)处理一下就行。所以清洗节点最好保留处理编码的入口。5.2 预算金额识别不准预算金额这个字段大模型经常翻车因为公告里的写法五花八门有的写“预算金额80万元”有的写“项目估算投资约120.5万元”有的写“最高限价为人民币玖拾叁万元整”大写金额还有的干脆不提钱。我的解决思路是分层处理。先用代码做第一层匹配通过正则把常见的“预算金额”“采购预算”“最高限价”后面的数字和单位提取出来再统一换算成“元”。第二层才交给大模型只处理代码层没抓到的情况。这样算下来预算金额的识别准确率能到九成以上关键是大模型不用费力气做算术转换稳定性上去不少。替换这个代码逻辑其实不难核心就是用正则把公告文本里的金额片段抠出来比如import re text 本项目预算金额为人民币柒拾伍万元整 # 括号里加入大写金额映射简化处理时先替换中文大写 upper_to_num {壹:1,贰:2,叁:3,肆:4,伍:5,陆:6,柒:7,捌:8,玖:9,拾:10} for k,v in upper_to_num.items(): text text.replace(k, str(v)) m re.search(r(\d(?:\.\d)?)\s*(万元|元), text) if m: value float(m.group(1)) if m.group(2) 万元: value * 10000 print(int(value))注意不同公告写“万元”“亿元”“元”的单位差异换算系数别写错。这个错误我犯过一次把“0.8亿”算成“8000元”差点把一个大商机当垃圾数据丢掉。5.3 大模型分析结果不稳定同一个公告今天跑出来预算金额是80万明天变成了8000这种问题我遇到过不止一次。后来分析下来根因基本是模型温度和Prompt约束不足。温度参数非常重要。我在信息提取这个场景里把温度调到了0.2或者更低让模型更倾向于保守生成。另外在Prompt里明确写“不要猜测”“不确定填未知”模型的状态会稳定很多。还有一个隐藏因素上下文长度。如果公告原文太长被模型截断尾部信息比如投标截止时间就可能丢失。我的清洗节点里专门加了一段逻辑检测到文本超过6000字符时优先保留包含“截止”“递交”“开标”“资格要求”“预算”“金额”的关键段其余部分删掉。这样既控制token又不丢核心信息。5.4 运行频率受限与资源配额免费版Coze对每小时运行次数有限制如果你的工作流跑得特别频繁很容易触发限制。我当时的策略是把信息源拆成两组分配两个不同的工作流一组跑高频30分钟一组跑低频每天3次这样单条工作流的配额消耗不会太集中。还有一点是尽量把多个信息源放进一个采集节点减少总节点运行次数。Coze是按节点调用量计费的同样的信息源分散在十个节点里跑和集中在一个节点里循环跑费用差异很大。6. 商机评分机制如何让工作流自己判断“值不值得跟”聊完基础搭建我想再分享一个进阶用法也是这套工作流真正从“信息聚合工具”变成“商机雷达”的关键——给每条商机打分。最开始我的工作流只做信息抓取和摘要推送结果推送群里每天十几条信息大家看着看着就麻木了重要商机反而被淹没。后来我加了一个“商机评分”大模型节点把评分规则前置让工作流自己判断这条公告的“质量分”和“匹配度”。评分维度我设计了三种区域匹配度项目所在地区是否在公司主营业务覆盖范围内范围内打1分范围外打0分。金额吸引力预算金额与公司过往中标金额中位数的比值越接近1分越高。比如公司过去中标的中位数是50万那一个80万的项目分数就比20万的高。资质匹配度把公司拥有的资质关键词和公告里的“投标人资格要求”对比命中越多分越高。这三个维度的原始计算我用代码节点来算避免大模型算数。最后让大模型只做一件事基于这三个分数给出一个综合评级A/B/C并输出推荐理由。规则是综合分高于2.5且资质命中数大于等于2评级为A。加了这个机制之后我推送群里每天的信息量骤降到三四条全部是A级和B级商机团队成员早上打开飞书看一眼就能决定今天要跟进哪几个效率和体验完全不同。评分代码也不复杂关键是要把三个维度统一标到0到1区间我简单用线性归一化处理# 区域匹配度 region_score 1.0 if region in service_areas else 0.0 # 金额吸引力假设最近一年中标金额中位数是500000 amount_score min(1.0, budget_amount / 500000) if budget_amount 0 else 0.0 # 资质匹配度 qualification_score len(hit_qualifications) / len(required_qualifications) if len(required_qualifications) 0: qualification_score 0.5 # 没有明确资质要求时给中间分 total_score (region_score * 0.4 amount_score * 0.3 qualification_score * 0.3) grade A if total_score 0.65 and qualification_score 0.5 else B这个权重不是拍脑袋定的我是结合了团队过往项目复盘得出的结论区域是硬门槛只要做不了金额再大也白搭所以给了0.4金额和资质各0.3。如果你所在的行业更看重资质门槛可以把资质权重往上调。试运行两周之后再根据实际跟单情况微调权重模型会越来越贴合你的业务。7. 我自己的经验与后续扩展思路这套工作流上线跑了将近两个月最大的变化不是省了多少人工而是团队对市场的敏感度完全不一样了。以前是“不知道外面发生了什么”现在每天早上能看到一份自动生成的“商机早报”哪些区域有匹配度高的项目、哪些项目快截止了需要立刻决策心里有数。供应商、联合体、代理机构这些关系链也同步更新了因为我们给代理机构加了一个信息源有它参与代理的项目会被单独标记出来。如果你也想搞一套我的建议是先不要追求大而全挑一个最核心的信息源把链路先跑通。哪怕每天只盯一个网站把“采集→清洗→提取→推送”走顺了再逐步加源、加评分、加输出渠道。一上来就铺二十个源每天光处理报错就够你头疼。后续我觉得可以从三个方向去扩展这套工作流。第一个是增加知识库能力把历史中标公告、企业资质、过往项目经验存入Coze的知识库让大模型在分析商机时能参考历史情况给出更贴近实际的投标策略建议。第二个方向是加入更多样的输出渠道比如推送到钉钉、邮件、甚至短信针对紧急商机单独设置短信提醒。第三个方向是让工作流生成更完整的“标前分析报告”包括竞争格局分析、自身优劣势、报价区间建议这些虽然不能完全替代专业的标书团队但能大幅减少前期调研的时间。说到底Coze扣子这类平台的意义是把过去要请开发写一套系统才能做到的事压缩到一个人一个下午就能搭出雏形。工具门槛降低之后比的不再是谁会写代码而是谁更理解自己所在行业的业务逻辑。把这层想清楚你的商机自动化之路基本就成功一半了。