前阵子我想入手一块显卡每天在几个平台之间来回切换比价手动复制粘贴到表格里折腾了两周还是没等到理想价格。后来索性写了一个跑在阿里云ECS上的定时任务用百炼平台上的Qwen模型自动汇总价格数据、生成比价报告每天早晨准时把分析结果推到群里。这套东西本质上就是“QwenWork定时比价并自动生成报告”核心是三点定时抓取数据、用大模型生成分析、自动产出可读报告。这篇文章我会从需求拆解讲起把整个项目的架构、数据采集、Qwen模型接入、定时调度、OSS归档这些环节完整过一遍每一步都附上能直接用的代码和参数说明。适合有一定Python基础、想用大模型做数据自动化分析的朋友也适合团队里负责“每日盯价”“竞品监测”这类重复劳动的人参考。看完你至少能搭出一套能跑的比价机器人换一换数据源和提示词还能扩展到行情监控、舆情摘要等场景。1. 需求梳理与整体设计思路1.1 原始需求与目标拆解“定时比价并自动生成报告”这句话拆开看其实包含三个独立能力定时、比价、自动生成报告。大部分踩坑的人上来就写爬虫脚本结果卡在“定时”和“报告生成”上说明没把需求拆到位。定时需要一个能长期稳定运行的环境和调度器每天或每隔几小时触发一次任务。本地电脑不是不能跑但关机、断网、休眠都会让任务失灵放在云服务器上才是正解。比价从目标平台获取商品价格、优惠信息并清洗成结构化数据。难点不在“获取”本身而在页面改版、反爬、字段缺失这些现实问题。自动生成报告把结构化价格数据变成人话。这里我选择了Qwen大模型直接把当日价格快照和历史波动喂给它让它输出对比表、趋势判断和购买建议省掉手写模板的硬编码逻辑。另外还有一个容易被忽略的隐性需求历史数据留档。只看今天的最低价格没有意义要知道价格是不是真的降了必须得有历史记录。所以这个项目里我额外加了SQLite存储和OSS归档每天抓完数据先落库再生成报告报告本身也上传到OSS保留备份。1.2 为什么选“阿里云ECS 百炼Qwen OSS”这套组合说实话这套组合并不是唯一选择但在我实际对比下来它是“部署成本”和“使用成本”都比较均衡的方案。ECS作为定时任务的载体一台2核2G的轻量实例就足够跑Python脚本和SQLite选阿里云主要考虑它的生态完整——OSS、短信、API网关、监控报警都能无缝对接后续要做通知提醒、备份、扩容都不用换平台。百炼上的Qwen模型负责报告生成Qwen系列的中文文本理解和总结能力在实际测试里表现不错尤其价格分析和购买建议这类需要“讲清楚原因”的输出。对比直接让代码拼模板LLM生成的报告明显更自然而且能针对数据差异给出更灵活的结论。OSS负责报告归档生成的报告传到一个私有Bucket需要的时候生成临时下载链接。这样比价报告有了历史版本后续要做月度趋势分析直接把OSS里的历史报告拉下来就行。热词里很多人搜“阿里云linux配置”“python阿里云镜像地址”其实就是在部署环节卡住了。我下面会把环境配置也写明白避免你倒在第一步。2. 数据采集与清洗比价的基础2.1 数据源选型与合规边界比价的数据源选什么决定了这个项目能走多远。我建议遵循几个原则只采集公开可访问的页面不碰需要登录才能看的信息控制请求频率不给目标站点造成压力优先选择有sitemap或结构稳定的页面。收藏夹里几十个商品链接真正值得天天盯的其实就那几个别一上来做全站采集数据量大了服务器成本也上去了。访问频率上我实测每6小时抓一次是合理区间。对普通电商页面来说这个频率不会触发反爬也能捕捉到一天内的价格变动。如果你的场景需要更细的粒度比如大促期间每小时盯一次建议用目标平台提供的官方API不要硬爬。2.2 用Python实现价格抓取抓取部分我用的是requests加BeautifulSoup轻量且够用。整体逻辑是读取商品SKU列表逐个请求页面解析标题、价格、促销信息最后输出结构化记录。完整代码大致长这样import requests import csv import datetime from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36, Accept-Language: zh-CN,zh;q0.9, } def fetch_price(sku: str) - dict: # 示例代码请按目标站点结构调整选择器 url fhttps://example.com/item/{sku}.html record {sku: sku, checked_at: datetime.datetime.now().isoformat(timespecseconds)} try: resp requests.get(url, headersHEADERS, timeout10) resp.raise_for_status() soup BeautifulSoup(resp.text, html.parser) record[title] soup.select_one(h1.item-title).text.strip() record[price] float(soup.select_one(span.item-price).text.replace(¥, ).strip()) record[promotion] soup.select_one(div.promotion-tag).text.strip() if soup.select_one(div.promotion-tag) else except Exception as exc: record[error] str(exc) return record def fetch_all(sku_ids: list) - list[dict]: return [fetch_price(sku) for sku in sku_ids] if __name__ __main__: skus [10001, 10002, 10003] rows fetch_all(skus) with open(prices.csv, a, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[sku, title, price, promotion, checked_at, error]) writer.writeheader() # 仅首次运行需要 writer.writerows(rows) print(rows)这个脚本有几个细节值得说。请求头里必须带上完整的User-Agent否则很多站点直接返回403。选择器要从实际页面里用开发者工具确认我上面写的是占位符。最关键是异常处理——单个SKU抓取失败不能让整个任务中断记录下来继续跑等告警邮件触发时再人工排查。数据清洗这块我的经验是只保留必要字段SKU、标题、价格、促销信息、抓取时间。不要贪多字段越多越容易在不同平台间出现格式不一致的问题。价格统一转成float时间统一用ISO格式后面喂给Qwen和存数据库都省事。2.3 历史数据的组织方式价格数据是典型的时序数据最好的形态是一行一快照。我直接用了SQLite理由是零配置、单文件、Python标准库支持不用额外装数据库服务。建表语句很简单CREATE TABLE IF NOT EXISTS price_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, sku TEXT NOT NULL, title TEXT, price REAL, promotion TEXT, checked_at TEXT NOT NULL );每次抓完数据就INSERT写入再查一下每个SKU最近30天的最高价、最低价、平均价传给后续的报告生成环节。这样Qwen在生成报告时手里不仅有今天的价格还有历史波动区间判断“当前价格是否值得入手”时更有依据。我踩过的一个坑是忘记加唯一约束导致同一天同一SKU可能重复写入。后来在插入前先查一次checked_at LIKE 2024-xx-xx%或者干脆用INSERT OR REPLACE问题就解决了。数据量大了之后可以定期清理90天前的旧快照只保留汇总统计节省空间。3. 接入阿里云百炼Qwen从数据到报告3.1 构建QwenWork的调用骨架报告生成是整个项目里最有“智能感”的部分实际实现却很简单把结构化数据转成文本拼进提示词调用百炼平台的API拿到模型输出后落盘。这就是标题里“QwenWork”的含义——让Qwen作为工作流里的“分析师”角色。先去百炼平台创建API Key开通模型服务。调用方式我试过原生SDK和OpenAI兼容接口个人推荐用dashscope这个Python SDK文档清晰、参数直观。安装和基础调用如下pip install dashscopefrom dashscope import Generation def call_qwen(prompt: str, api_key: str) - str: response Generation.call( modelqwen-plus, api_keyapi_key, promptprompt, result_formatmessage, max_tokens1200, temperature0.3, ) if response.status_code 200: return response.output.choices[0].message.content raise RuntimeError(fQwen API error: {response.code} {response.message})模型我用的qwen-plus综合能力和响应速度比较均衡。如果追求极致成本可以降级到qwen-turbo如果分析要求特别高再上qwen-max。我测试下来价格分析这种文本长度有限、逻辑要求中等的任务qwen-plus是最划算的。temperature设成0.3是为了让报告每次输出的风格相对稳定不会同一个数据今天说“建议买”明天说“不建议买”。需要注意API Key一定不要硬编码在脚本里尤其是这个项目要放ECS上长期跑。建议通过环境变量传入避免泄露。3.2 报告生成提示词设计提示词是决定报告质量的最关键变量比选哪个模型还重要。我现在的提示词结构分四层角色设定、输入数据、输出要求、风格限制。给你们一个可以直接套用的模板你是资深采购分析师。请根据今日抓取的商品价格数据和历史统计信息生成一份比价分析报告。 【今日价格数据】 SKU-10001: 某品牌显卡 4599元平台A无优惠券 SKU-10002: 某品牌显卡 4699元平台B满3000减200 SKU-10003: 某品牌显卡 4520元平台C限时秒杀 【近30天统计】 SKU-10001: 最高价4999最低价4399均值4650 SKU-10002: 最高价4999最低价4599均值4750 SKU-10003: 最高价4800最低价4520均值4620 【报告要求】 1. 用表格对比各平台到手价包含平台、价格、优惠说明、历史分位。 2. 指出哪个SKU当前相对历史处于低位哪个仍偏高给出理由。 3. 结尾给出“综合推荐购买”和“继续观望”两个结论各附一句话原因。 4. 全文250字以内中文输出语言简洁。这里有一个关键设计我把“要求”写得非常具体甚至指定了表格列名和结论结构。LLM生成报告时如果放任自由发挥输出格式会千奇百怪后续没法统一展示。如果你需要程序化解析报告比如提取推荐结论一定要在提示词里强制规定输出格式比如用JSON结构。我实际测试下来结构化输出比自由文本好用得多——报告可以直接被下游系统消费比如自动输入企业微信、飞书机器人等。如果你需要更严格的字段可以要求“只输出一个JSON对象包含summary、table、recommend三个字段”百炼的Qwen对这类指令遵循得不错。3.3 控制调用成本与超时调用大模型接口最怕两件事响应超时和成本失控。我在生成报告前会先估算输入token量。一次比价任务通常涉及3到6个SKU历史统计字段只输出汇总输入规模控制在1000 token以内用qwen-plus单次成本不到一分钱完全可以忽略。唯一要注意的是不要把原始HTML标签或者几十天的明细数据全塞进去那会迅速膨胀输入token成本上升且响应变慢。超时方面dashscope的默认超时时间我没仔细确认过但保险起见我统一设置了60秒连接超时。如果任务失败我会让脚本重试一次然后发告警避免半夜被一条失败消息打断。用大模型生成报告这件事不稳定是常态日志和重试是必需品。4. 定时调度与自动化部署4.1 使用crontab跑定时任务定时调度我用的最朴素的方式Linux的crontab。项目目录放在/opt/price-bot主入口是run.py它会依次执行抓取数据、写入SQLite、调用Qwen生成报告、上传OSS。完整命令是0 */6 * * * cd /opt/price-bot /usr/bin/python3 run.py logs/cron.log 21这行crontab表示每6小时的第0分钟执行一次。这里有个小坑crontab里的PATH环境变量和登录Shell不一样经常出现Python路径找不到、依赖模块ImportError的问题。我的解决办法是第一Python用绝对路径/usr/bin/python3第二在执行命令里先cd到项目目录确保相对路径不出错第三所有日志重定向到文件方便排查。如果你想更灵活地控制任务不用crontab也可以换成APScheduler在Python里定义时间表。但对这种固定周期的任务crontab已经足够可靠我不建议引入额外的常驻进程——省一个进程就是省一份维护成本。4.2 把报告存档到OSS报告生成在本地如果只是放在ECS上一旦实例重置数据就丢了。我把每份报告上传到OSS按日期分目录存储既能回溯历史也能生成临时链接分享给同事。这里的OSS操作也涉及很多热词里的“阿里云oss”,“阿里云oss”如何配置的问题我贴出核心代码import oss2 def upload_report(local_path: str, object_key: str) - str: auth oss2.Auth(os.environ[OSS_ACCESS_KEY_ID], os.environ[OSS_ACCESS_KEY_SECRET]) bucket oss2.Bucket(auth, https://oss-cn-hangzhou.aliyuncs.com, os.environ[OSS_BUCKET_NAME]) bucket.put_object_from_file(object_key, local_path) return fhttps://{os.environ[OSS_BUCKET_NAME]}.oss-cn-hangzhou.aliyuncs.com/{object_key}object_key的格式我建议用price-report/2024/06/15/report.md这样按时间路径自然分好了类。文件格式上我同时导出Markdown和HTML两个版本。Markdown方便在群里直接看HTML方便在浏览器里打开。对了如果想减少ECS流量费用可以把ECS和OSS放在同一个地域走内网Endpoint上传。比如ECS在广州Bucket也建在广州Endpoint用oss-cn-guangzhou-internal.aliyuncs.com就能免流量费。4.3 把报告推送到群机器人光生成报告还不够要让人“在正确的时间看到”主动推送才是自动化闭环的最后一环。我目前的做法是把报告摘要和下载链接通过Webhook推到钉钉群整个推送逻辑就是一个POST请求import requests import json def send_to_dingtalk(webhook_url: str, title: str, text: str): payload { msgtype: markdown, markdown: {title: title, text: text}, } requests.post(webhook_url, datajson.dumps(payload), headers{Content-Type: application/json})推送内容不要放全量报告太长阅读率反而低。我的习惯是只推三行今日最低价SKU、对比昨日涨跌幅、完整报告链接。大家有需要再点开链接看详细分析“定时简单提醒”的作用就达到了。5. 运行状态自检与常见问题5.1 部署时卡在依赖安装和镜像源热词里那么多人搜“python阿里云镜像地址”说明大家装Python依赖时都遇到过超时或拉不下来包的问题。ECS在国内网络环境下把pip源切换成阿里云镜像是最快的解法创建或修改~/.pip/pip.conf[global] index-url https://mirrors.aliyun.com/pypi/simple/ trusted-host mirrors.aliyun.com如果你用的是CentOS 7系统自带的源也可能因为网络问题变慢之前热词里也有“centos linux 7 rpm源 阿里云”的搜索。实际做法是把/etc/yum.repos.d/下的源地址改成阿里云镜像这个在阿里云官方文档有详细步骤不再赘述。依赖装好了整个部署流程就顺畅了一半。5.2 Qwen API返回超时和限流运行一段时间后遇到过几次百炼API返回限流错误。原因是免费或低配额度下的并发限制或者短时间内调用数过多。解决思路有三个增加重试机制对网络错误和限流错误做指数退避重试通常第2次或第3次就能成功。错峰调用比价报告这种任务对时效要求不高把调度时间从上午9点整改成9点15分避开高峰。降级模型遇到高峰期qwen-turbo往往比qwen-plus更容易成功而且单价更低只是分析深度稍微差点。我现在的代码里统一封装了一个带重试和退避的调用函数任何API异常都先重试两次再放弃效果明显。5.3 时间同步和日志定位定时任务有一个致命但容易被忽视的问题ECS实例的系统时间漂移。如果服务器时间差了十几分钟任务执行时间就可能从预期的“每天9点”变成“8点45”报告里的时间戳也跟着错。解决办法是开启NTP或chrony自动同步。阿里云默认自带时间同步服务我建议在任务脚本里增加一个启动时检查发现系统时间和真实时间偏差超过1分钟就告警避免数据时间戳混乱。日志这块我强烈建议每个环节都打印明确标记[2024-06-15 09:00:01] 开始抓取价格... [2024-06-15 09:00:03] 抓取完成共3条记录 [2024-06-15 09:00:10] Qwen报告生成完成耗时7秒 [2024-06-15 09:00:12] 报告已上传OSS: price-report/2024/06/15/report.md这样哪天任务失败看日志最后一行就知道卡在哪个环节。别问我怎么知道的——我曾经有整整一周没看日志结果爬虫选择器因为页面改版挂掉了那天“没有报告”在群里却没人注意到。5.4 页面改版和反爬比价脚本最怕的就是目标平台改版选择器一失效整个任务全挂。我的经验是给每个选择器加一个“存在性检查”解析时如果发现关键节点为空立刻记录异常并跳过该SKU不要抛出堆栈后中断任务。这样即使单条数据丢失其他SKU还能正常出报告。反爬方面只要能控制频率、带完整请求头、不抓敏感页面绝大多数公开页面都能正常访问。万一收到403或验证码不要硬刚直接减少频率或者换数据源。我在脚本里做了一级降级策略抓取失败时使用上次的数据并标注“数据更新于X小时前”保证报告不会因为单次抓取失败而空着。6. 扩展思路这套架构还能做什么6.1 从比价到行情报表比价只是这套架构的一个切片。把商品价格换成基金净值、加密货币行情、甚至企业招聘岗位数量逻辑完全一样——定时采集、存储历史、Qwen分析现状并生成报告。比如我后来把自选基金的净值也接进了同一套体系每天生成一张“定投日历提示”告诉我哪些指数处于近一年的低估区间。这就是把单一比价工具改造成了通用行情监控改动只需要换数据源和提示词。6.2 从价格分析到舆情摘要如果你把数据采集端换成新闻站点、社交媒体公开页或行业论坛再让Qwen对采集结果做“情绪判断”和“趋势总结”就变成了一个轻量的舆情监控工具。对个人来说可以用来追踪某个产品发布后的口碑变化对团队来说可以替代一部分付费舆情工具的初级功能。这些场景的架构完全不用动只改数据采集模块和报告提示词。6.3 从云服务器到本地有些数据源涉及内网数据或本地文件不适合放ECS上采集。我的折中方案是本地用脚本按小时抓数据并生成临时文件再通过OSS或对象存储同步到云端云端任务负责分析和生成报告。把“采集”和“分析”拆到两处既发挥了大模型的分析能力也避开了公网服务器的局限。最后的实操心得这套比价机器人从想法到落地前后花了一个周末。我个人最深刻的体会是大模型让报告生成变得极其简单但真正决定项目成败的其实是地基——数据抓取是否稳定、历史数据是否完整、定时调度是否可靠。Qwen能做到的是“把数据变成人话”但它不能帮你处理反爬、不能帮你修crontab的环境变量、不能替你发现日志里的异常信息。所以做这类自动化项目我建议先把地基打牢再上模型能力。另外还有个小技巧想分享报告不要只生成当天的让Qwen在生成当日报告时连续输出“与昨日对比”“与30日均线对比”两个视角比你手动算完再填进去省力得多而且模型基于数据给出的解释往往更耐读。这套项目后续我还在继续迭代准备把每日报告汇总成每周、每月的趋势分析再把推送渠道从钉钉扩展到邮件和企业微信。自动化这个东西一旦跑顺了是真的不想再回到手动比价的日子。