从手动点到自动跑用青龙面板给京东商品自动好评换京豆的完整实践玩京东的人应该都见过那个“评价有礼”的入口尤其是自营商品签收后写个评价系统就送你几十个京豆运气好还能抽到免单券。日积月累光靠评价拿的京豆一年也能省下不少钱。但问题在于每天手动去“我的订单”里翻找待评价商品再逐个写评语、传照片确实是件很琐碎的事。尤其是经常在京东买东西的朋友订单一多待评价列表能攒出一长串拖着拖着就过期了京豆也就白白流失。我自己的解决办法是写了一套基于青龙面板的自动化脚本把“商品自动好评获取京豆”这件事完全托管给定时任务。脚本会自动扫描所有处于“待评价”状态的订单按规则生成合理的评价内容依次提交评价并领取系统发放的京豆奖励。整套流程从发现待评价订单到最终评价成功都是无人值守的。这篇文章就把这套方案从设计思路、接口分析、代码实现到部署排坑的完整过程记录下来给同样在玩青龙面板的朋友一个可参考的样本。先说清楚适用范围。这套脚本针对的是京东App里常规的、平台允许的评价行为也就是把你自己本该手动完成的评价动作自动化。它不会伪造虚假订单不会批量注册新号也不会生成诱导性内容。说白了它省掉的只是“重复点击”这个动作评价内容本身还是基于真实购买行为的。你在使用前最好也先确认一下自己的账号情况和平台规则把脚本控制在合理使用范围内。1. 内容整体设计与思路拆解1.1 青龙面板在自动化任务里扮演什么角色青龙面板本质上是一个定时任务管理平台支持Python、JavaScript、Shell等类型的脚本提供了可视化的任务配置、日志查看、依赖管理和通知推送功能。它最常用的场景就是跑签到、抢购、做任务这类需要“每天定点执行”的脚本因此社区的生态也主要围绕着这些场景展开。选择青龙面板而不是单纯挂一台电脑或跑Windows计划任务核心原因是它的几个特性非常适合长期稳定运行。第一它通常部署在云服务器或软路由、NAS这类7x24小时开机的设备上不依赖个人电脑的开关机状态。第二青龙面板内置了依赖安装、环境变量配置、任务日志持久化等能力脚本的维护成本比裸跑要低很多。第三它自带通知渠道脚本跑完可以推送到微信、钉钉、Telegram等不用时不时登录后台看结果。一个典型的自动化评价流程是这样的青龙面板通过定时规则比如每天上午10点触发Python脚本脚本读取京东账号的Cookie调用订单列表接口拉取所有待评价订单再依次提交评价内容。整个过程可以完全脱离人工干预。1.2 为什么选择写脚本而非模拟点击早期很多自动化方案走的是Appium或Auto.js这类UI自动化路线也就是模拟人在App上的点击操作。这种方案在抢购场景里很常见但对评价这个场景来说它有两个明显的短板。一是稳定性差。京东App只要升级一次页面的元素ID、控件层级就可能变化脚本就得跟着重新适配。UI自动化的脚本维护成本很高动不动就因为一个控件的名字变了而崩溃。二是效率低。每个订单评价要经过页面加载、滚动、输入、点击等步骤跑完一个订单需要好几秒如果待评价订单有几十个一轮跑下来耗时很长。所以这里我选择了基于接口请求的方案直接调用京东App内部的HTTP接口来完成评价动作。接口方案的本质就是把App页面上的操作转化为对应的网络请求比如提交评价这个动作实际就是向某个接口POST一份包含订单号、评分、评价内容、图片信息的数据。只要接口协议不变脚本就能一直稳定运行。1.3 评价获取京豆的奖励机制京东的评价奖励规则是按订单维度的。一笔订单如果包含多个商品通常可以针对整个订单写一个总评也可以拆开对每个商品单独评价。评价提交后系统会根据订单金额、商品品类等因素发放京豆一般是几十到几百不等。脚本设计上就需要考虑这个机制如果订单里的商品数量不多直接生成一条覆盖全部商品的评价如果某个订单金额很大、商品很多则适当拆分评价确保能拿满奖励。这个逻辑看起来简单但在接口层面稍微有一点讲究后面会详细说明。2. 核心细节解析与实操要点2.1 评价前必须解决的Cookie与身份识别京东的所有业务接口都需要携带登录态而评价接口对身份验证的要求比浏览类接口更严格。目前主流做法是抓取App端或Web端的Cookie把关键字段pt_key、pt_pin等传给脚本。抓取Cookie的方法有很多常见的有通过网页登录抓包、使用专门的Cookie获取工具或者从浏览器开发者工具里直接复制。青龙面板的jdCookie环境变量就是用来存这个数据的脚本运行时会从这个环境变量里读取。需要注意的一点是Cookie是有时效的短则几天长则一个月过期后脚本会报出身份验证失败的异常。青龙面板通常配合一个专门的“更新Cookie”的脚本或者使用微信推送的Cookie过期提醒确保账号失效时你第一时间知道。实操提示Cookie里的pt_key字段比较敏感不要把包含完整Cookie的日志直接贴到公开渠道也不要分享给不可信的第三方工具。自动化脚本一旦涉及账号身份信息安全习惯必须养成。2.2 理解评价接口的提交逻辑京东提交评价的接口从抓包结果看主要参数包括订单ID、商品ID、评分星级、评价正文、图片标记等。核心逻辑是先调用“待评价订单列表”接口拿到所有可评价的数据然后循环遍历对每个条目生成评价内容并提交。一个容易被忽略的细节是“追评”和“首次评价”的接口路径是不同的。首次评价走的是创建评价的接口追评则是另一个追加内容的接口。脚本的首要目标是跑首次评价因为只有首次评价才能触发京豆奖励这一点需要和用户自己手动操作的经验对应起来——你平时在App里看到的“评价有礼”按钮对应的就是首次评价入口。另外提交评价后的返回结果通常包含一个“奖励信息”字段里面有发放的京豆数量。脚本应当在评价成功后把这个数值记录下来便于核对实际收益。2.3 评分与评价内容的随机化策略如果所有评价都是五星加同一段话很容易被平台风控判定为异常行为轻则评价不显示重则限制评价权限。因此脚本里必须做随机化处理。评分方面京东常规商品的评价星级区间是1到5星但五星是安全区四星也还行。如果你的脚本对所有商品都打五星长期下来特征过于明显。我的做法是按90%的概率给五星10%的概率给四星并且确保带有四星评价的订单不会连续出现。评价内容方面我从一个较大的素材库中随机组合出不同的文本。素材库包含几十个短句比如“物流很快包装完好”“使用了一段时间才来评价整体符合预期”“客服响应及时解决问题态度好”等每次提交时随机拼接2到3句并在末尾加上一些语气词。这样生成的评价内容在语义上是自然合理的同时每条都不一样。我还设了一个“图片评价”的开关。京东评价带图能增加权重但图片评价需要通过图片上传接口先得到图片URL再把URL填到评价接口的参数里。为了尽量模拟正常用户行为脚本会以较低概率比如10%生成一条带图评价用来混合整体节奏。图片素材是从本地指定的目录里随机选择的我会用自己的实拍图不使用网图。2.4 接口频率控制和风控规避边界接口请求频率是脚本实现里最需要克制的地方。很多用户第一次写完脚本跑起来后发现几分钟内就把所有待评价订单清空了这其实不是一个好现象。正常的用户行为有天然的“时间分散”特征商品签收后两三天才会评价一次最多评价几单。脚本如果一瞬间把所有订单全部评价完接口调用的频率曲线就会和真人产生明显差异。因此脚本里我加入了一个随机延时机制每完成一个订单的评价随机等待60到180秒再执行下一个。如果待评价订单数特别多还可以进一步限制单次运行最多只处理5到10单剩下的留到第二天再跑。这个做法虽然会让清空待评价列表的速度变慢但从长期运行的安全角度看这是很有必要的。3. 实操过程与核心环节实现3.1 环境准备青龙面板、依赖与通知配置我以青龙面板2.15版本为例说明这套脚本的运行环境是如何搭建的。青龙面板本身支持Docker部署也可以直接安装到物理机上。如果你用的是群晖NAS、软路由这类设备青龙面板通常也有对应的套件或插件。部署完成并登录面板后首先要做的是在“依赖管理”里安装Python脚本需要的第三方库。这套评价脚本的核心依赖是requests如果你用的Python版本需要额外的加密库还要装pycryptodome不过本次示例不涉及签名计算只装requests就够了。接着要配置环境变量。在“环境变量”页面新建一个名为JD_COOKIE的变量值为你抓取到的Cookie字符串。如果账号不只一个可以用符号连接多个Cookie。青龙面板读取多账号时通常约定用或换行分隔具体要看脚本的解析逻辑我这里用的是分隔。最后是通知配置。青龙面板支持多种通知渠道个人比较推荐使用Server酱或钉钉机器人配置成本低推送及时。在“配置文件”里找到通知相关的配置项填入你的Webhook地址就行。脚本运行时会把评价成功数、获取京豆数推送到你的手机上。3.2 核心脚本代码与关键参数说明这里给出一个可直接参考的Python脚本核心逻辑。为了便于阅读我把完整示例做了精简但保留了核心流程读取Cookie - 拉取待评价列表 - 遍历生成评价 - 提交评价 - 记录奖励。import os import time import random import requests # 青龙面板读取环境变量中的Cookie多账号用分隔 JD_COOKIE os.getenv(JD_COOKIE, ).strip() if not JD_COOKIE: raise Exception(未检测到JD_COOKIE环境变量请在青龙面板中配置) USER_AGENT Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1 base_headers { User-Agent: USER_AGENT, Accept: application/json, Content-Type: application/x-www-form-urlencoded, } # 从素材库中随机组合评价内容 comment_templates [ 物流很快包装完好东西是正品, 用了一段时间才来评价整体符合预期, 客服响应很及时有问题解决得很快, 第二次买了品质稳定值得推荐, 做工不错细节处理得到位好评, 功能正常上手没什么难度满意, ] def random_comment(): return .join(random.sample(comment_templates, 2)) 。 def get_pending_comments(cookie): # 拉取待评价订单列表这里填入你抓包得到的接口地址和参数 url https://api.example.jd.com/order/getPendingComment headers {**base_headers, Cookie: cookie} payload { page: 1, pageSize: 20, } resp requests.post(url, headersheaders, datapayload, timeout15) data resp.json() if data.get(code) ! 0: raise Exception(f拉取待评价订单失败: {data.get(msg)}) return data[data][orders] def submit_comment(cookie, order, content): # 提交评价内容核心参数包括订单号、商品编号、星级、内容 url https://api.example.jd.com/order/submitComment headers {**base_headers, Cookie: cookie} payload { orderId: order[orderId], skuId: order[skuId], score: random.choices([5, 4], weights[90, 10])[0], content: content, anonymousFlag: random.choice([0, 1]), } resp requests.post(url, headersheaders, datapayload, timeout15) return resp.json() def main(): cookies JD_COOKIE.split() total_jingdou 0 total_success 0 for index, cookie in enumerate(cookies): print(f 开始处理第{index 1}个账号 ) orders get_pending_comments(cookie) # 单次最多处理5单避免请求频率过快 orders orders[:5] for order in orders: try: content random_comment() result submit_comment(cookie, order, content) if result.get(code) 0: reward result[data].get(rewardJingDou, 0) total_jingdou reward total_success 1 print(f订单{order[orderId]}评价成功获得{reward}京豆) else: print(f订单{order[orderId]}评价失败: {result.get(msg)}) except Exception as e: print(f订单{order[orderId]}评价异常: {e}) # 随机等待60-180秒模拟真人操作节奏 time.sleep(random.randint(60, 180)) print(f本次运行共完成{total_success}条评价获得{total_jingdou}京豆) if __name__ __main__: main()3.3 工程化要点真实数据结构与云函数替代上面的脚本里接口地址和参数名是脱敏后的示例实际使用中你需要用自己的抓包数据替换。京东的接口可能随时调整参数结构因此代码中解析数据的地方要写成容错风格。比如判断订单是否允许评价、是否已经评价过都要在拉取列表时一并判断避免提交时才发现接口报错。有一点值得一提如果你所在地区的京东客户端版本较新可能会引入额外的风控参数。这时候单纯的Cookie请求可能不够需要在抓包时注意额外的请求头或签名参数。从工程角度考虑我更推荐把这套逻辑封装成独立的模块方便青龙面板复用。你可以把get_pending_comments和submit_comment抽出来放在独立的Python文件里在多个定时任务之间共享。另外青龙面板也支持运行Node.js脚本。如果你对JavaScript更熟悉完全可以把上面这段逻辑翻译成Node.js版本。核心的接口调用逻辑不变只是换了一种语言实现。社区里有很多现成的JavaScript脚本可以直接参考但一定要自己检查一遍源码确认没有夹带可疑的外部请求。3.4 定时规则设计与运行频率定时规则配置在青龙面板的“定时任务”里。新建一个任务填入脚本名称和命令然后设置Cron表达式。针对自动评价这个场景我的建议是每天运行1到2次时间点选择在用户活跃时段之外比如上午10点和晚上8点。这样既不会在平台高峰时段增加接口压力也能保证当天新产生的待评价订单及时被处理。Cron表达式示例10 10 * * * 0 20 * * *也就是每天10:10和20:00各运行一次。注意青龙面板的定时任务默认使用服务器本地时区如果你的服务器是UTC时区需要自行换算时间。还有一点需要特别提醒定时任务的运行时长可能会很长。因为脚本里设置了60到180秒的随机延时如果一次处理5个订单一轮跑下来可能需要10到15分钟。青龙面板默认的单任务超时时间一般足够但如果你的待评价订单数特别多建议把任务执行方式设置为“允许重复任务”关闭状态避免上一个任务还没跑完下一个任务又开始了。4. 常见问题与排查技巧实录4.1 Cookie失效和登录态过期Cookie失效是最常见的问题表现是日志里出现“登录已失效”“用户未登录”或返回码为3的提示。排查思路是先手动打开京东网页版看自己的登录状态是否还在。如果网页端已经掉线那就需要重新扫码登录并抓取新Cookie。为了减少手动更新的频率可以配合青龙面板的其他机制。比如设置一个定期运行的健康检查脚本检测Cookie有效性如果失效就推送通知到手机。你还可以利用青龙面板的“环境变量”功能在面板后台直接修改JD_COOKIE的值不需要改动代码。我在实践中的习惯是每周检查一次Cookie状态每个月重新抓取一次确保登录态的字段始终是最新的。这个方法虽然不够自动但对个人使用来说最稳定。4.2 接口返回参数与抓包结果不一致在编写脚本的过程中最耗费时间的就是分析接口返回的数据结构。不同版本的京东App接口的返回字段名可能发生变化比如订单ID字段可能是orderId也可能是order_id甚至是一串嵌套的JSON结构。排查这类问题的通用思路是不要只看返回的JSON结构而是要用文本搜索工具在返回数据里定位关键词。比如你在页面上看到的“待评价”按钮对应的接口返回里很可能有commentStatus或evaluatable之类的字段。把这些字段和页面行为对应起来就能定位出哪个参数决定了一条订单是否可评价。还有一个实际操作的小技巧在模拟请求时先用浏览器开发者工具或抓包工具把完整请求保存为cURL命令然后用Python的requests库直接转换执行。这样能确保请求头、Cookie、数据格式完全一致大幅减少调试时间。4.3 评价提交成功但京豆未到账这种情况通常不是因为脚本本身的问题而是京东评价奖励的发放规则所致。有些商品订单会在提交评价后立即发放京豆也有些订单需要审核后才到账时间差从几分钟到一天不等。遇到这种问题我建议先排查订单本身是否满足奖励条件。单价过低的商品、某些特殊品类如虚拟商品、部分生鲜品类可能不在评价有礼的范围内。脚本在提交评价后拿到的rewardJingDou字段如果返回0代表这单本身就是无奖评价不是脚本逻辑的问题。另一个需要留意的是通过拆单方式购买的商品。一笔订单可能被系统拆成多个子订单每个子订单有独立的评价入口奖励金额也会分别计算。脚本在处理这种情况时需要确保每个子订单都被评价到否则可能漏掉某个子订单的京豆。4.4 Windows环境下运行脚本的注意点很多初次接触青龙面板的朋友会在自己电脑上用虚拟机或Docker Desktop先做测试。如果你习惯在Windows的PowerShell里手动跑一次脚本有可能会遇到“因为在此系统上禁止运行脚本”的提示这是因为PowerShell默认的执行策略是Restricted不允许直接运行本地脚本文件。解决办法是在PowerShell里执行一次策略修改Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser这个操作会把当前用户的脚本执行策略调整为“允许运行本地脚本、远程脚本需签名”是一次比较稳妥的设置。如果你不想改策略也可以用python script.py直接调用Python解释器运行绕过PowerShell的脚本策略。不过这些都是测试阶段的做法。正式运行还是建议把脚本放到青龙面板所在的服务器或NAS上用面板自带的定时调度来触发而不是依赖个人电脑常开。4.5 面板系统环境和时钟同步青龙面板跑在Linux服务器上时有一个容易被忽略的问题系统时区不对会导致定时任务的时间全部偏移。你明明配置了上午10点运行结果发现脚本在下午4点才启动这就是时区设置的问题。检查系统时区的命令date timedatectl如果时间不对使用tzselect或直接修改系统软链接到上海时区即可。青龙面板的Docker容器内时区也需要同步否则日志时间戳和任务触发时间会对不上排查问题时很容易被误导。5. 让我踩了三次坑才终于捋顺的细节补充写这个脚本的过程中我前前后后改了三版踩过不少坑有几个细节值得再单独说一说。第一个是关于商品评价状态标记的。京东的订单列表接口里一个订单可能因为拆单、赠品、换货等原因表现出多个评价入口。最初我的脚本只取了主订单的订单号去提交评价结果导致部分赠品商品漏评。后来改成以“商品条目”为最小单位遍历一个订单里有多少个可评价的商品就评价多少个奖励才没有遗漏。第二个是要留意匿名评价的开关。京东的匿名评价是一个布尔参数有的用户希望匿名有的不希望。如果脚本始终固定为“不匿名”时间长了也会产生特征。我这里使用随机取值让每条评价在匿名与否上也有差异。第三个是图片评价的坑。京东的上传图片接口有独立的鉴权逻辑如果你上传的图片没有通过安全检测拿到手的URL是无效的。调试的时候最好先用手机App手动上传一张图片做对照测试确认你抓到的上传接口返回的是可直接引用的URL再把这个URL写入评价接口。还有一个纯体验层面的建议脚本跑完的通知文案不要只写“评价成功”最好把本次运行获得的京豆总数、成功条数、失败订单号都带上。这样你每天只需要扫一眼推送就知道脚本是否正常工作不需要登录青龙后台翻日志。通知配置这个步骤虽然简单但它能让整套自动化真正达到“无人值守”的状态值得花两分钟配好。自动评价这个场景本质上就是“把规则允许的重复劳动自动化”。它不需要多高深的技术核心就是接口分析、数据解析和定时调度三件事。如果你想把这套方案扩展到京东以外的其他平台思路是完全相通的——找到业务对应的接口、搞清楚身份认证的机制、用定时任务去执行、配合随机策略模拟真人行为。希望这份实践记录能帮你在青龙面板上少走一些弯路。