青龙面板部署京东自动评价返京豆脚本完整教程

青龙面板跑京东相关的自动化脚本圈内已经不是什么新鲜事了签到、开卡、领豆的脚本满天飞。但商品自动评价返京豆这块能讲清楚原理、能自己改脚本的人并不多。我去年把一套评价脚本从零写好放到青龙面板上稳定跑了大半年中间经历过接口变动、账号风控、评价被拒等各种状况最后都一一解决了。这篇就把完整的方案拆开揉碎讲清楚从面板部署到脚本编写再到问题排查全部覆盖照着做就能用。1. 内容整体设计与思路拆解1.1 自动评价返豆的底层逻辑京东的京豆体系里商品评价返豆是最稳定的日常获取渠道之一。规则大致是这样订单确认收货后在评价有效期内不同商品类目窗口期不同常见是60天发表符合平台规范的评价内容系统会返还一定数量的京豆金额越大、评价越详细返豆越多。听起来简单但真要手动操作问题就来了一个账号一个月可能有好几笔待评价订单每个订单要选星级、填文字、传图片整套流程走下来一分钟都算快的。如果手里不止一个号或者订单量稍微大一点这种机械重复的动作纯属浪费时间。脚本的价值就在这里——把定位待评价订单、生成评价内容、提交评价这三个步骤自动化让机器代替人去做那些无意义的重复点击。整个流程的核心思路是登录京东账号维持一个有效的会话拉取所有待评价订单识别哪些订单符合返豆条件按预设模板生成评价内容提交评价并确认返豆结果这个链路里最难的其实不是自动化本身而是如何稳定维持登录态和如何模拟出真实用户的评价行为。后面这两点我会重点展开。1.2 为什么选青龙面板作为运行环境在讨论脚本之前先回答一个基本问题为什么要把这个脚本放到青龙面板里跑而不是本地电脑的定时任务青龙面板本质是一个定时任务管理平台专为跑脚本而生支持cron表达式、依赖管理、运行日志查看、多脚本并发调度。评价脚本这类任务有几个特点恰好是青龙面板的优势区域需要定时触发平台一般有评价时间窗口在合适的时间段集中提交比半夜三更提交成功率更高。青龙面板的定时配置可以精确到分钟。需要日志留存返豆不是即时到账可能需要数小时甚至数天才会入账。你得能回溯某次评价提交时发生了什么青龙面板的日志记录功能正好满足。需要低资源运行评价脚本是轻量级HTTP请求任务不需要浏览器模拟资源占用极低放到家里的软路由、NAS或者任何一台常开的迷你主机上都毫无压力。多账号集中管理一个青龙面板实例可以管理多个环境变量每个环境变量对应一个账号的Cookie切换、禁用、查看状态都非常方便。另外青龙面板自带依赖管理功能装Node.js依赖包就是一个命令的事不用自己折腾环境。1.3 脚本方案选型Node.js还是Python目前青龙面板上主流的京东脚本基本是JavaScriptNode.js和Python两种语言写的。两者都能实现同样的功能但我在这个项目里选择了Node.js原因有几点青龙面板本身就是Node.js写的对JS脚本的原生支持最好日志输出、异常堆栈、依赖安装都更顺畅京东的接口返回基本都是JSONNode.js处理JSON非常自然现成的JS例子多不管是Cookie获取还是接口调用都有大量现成代码可以参照Python也不是不行但在这个场景下JS生态更省事。接口调用用的是axios库登录态管理靠手动维护Cookie整体代码量不大逻辑清晰。1.4 完整流程概览把整个方案串起来看大概是这么个流程部署青龙面板配置好基础环境在浏览器中登录京东账号抓取Cookie将Cookie写入青龙面板的环境变量编写评价脚本包含拉取订单、生成评价、提交评价、结果核验四部分在青龙面板中创建定时任务配置评价时间段运行后查看日志确认评价是否提交成功、返豆是否到账下面就从第一步开始一步步来。2. 环境部署与前置准备2.1 青龙面板的快速部署青龙面板的部署方式很多支持Docker、裸机安装、群晖套件等。最省心的还是Docker方式。假设你已经有一台常开的Linux服务器或者软路由执行以下命令就能拉起来docker run -dit \ --name qinglong \ --hostname qinglong \ --restart always \ -p 5700:5700 \ -v /path/to/ql/data:/ql/data \ whyour/qinglong:latest这里的-p 5700:5700是面板的Web访问端口-v是数据持久化目录一定要映射出来否则容器升级后配置和脚本就丢了。启动后用浏览器访问http://服务器IP:5700按提示初始化账号密码就完成了。如果不想用Docker官方也提供了一键安装脚本curl -fsSL https://get.whyour.cn | bash不过我还是推荐Docker方式升级回滚方便隔离性也好不会把宿主机环境弄乱。2.2 依赖安装与Node环境确认青龙面板部署好之后需要在面板的依赖管理中安装Script运行所需的依赖。在青龙面板后台进入依赖管理 - Node.js添加以下依赖axios crypto-jsaxios是HTTP请求库用来调用京东接口crypto-js用来做签名计算。虽然现在京东部分接口已经不需要手动计算签名但有备无患。安装依赖这个动作其实是在容器内执行npm install青龙面板只是帮你做了封装而已。安装完成后可以在脚本管理中新建一个测试脚本执行console.log(process.version)确认Node环境正常顺便看看版本号。一般青龙面板内置的Node版本都够用不需要额外升级。2.3 获取京东Cookie保持登录态的关键这是整个方案里最容易出错、也最关键的一步。京东的接口认证主要通过Cookie完成你需要从浏览器中提取登录后的Cookie字符串。具体操作步骤如下在Chrome或Edge浏览器中打开https://www.jd.com登录你的账号按F12打开开发者工具切到网络Network标签页刷新页面在请求列表里随便点一个jd.com域下的请求在请求头Request Headers中找到Cookie字段复制完整内容这里的关键是这个Cookie里必须包含pt_key和pt_pin两个字段这是京东认证体系的核心凭证。pt_key是会话令牌pt_pin是用户名标识。如果Cookie里没有这两个字段说明你没有登录成功或者复制错了请求的Cookie。注意Cookie是有有效期的。短的话可能几天长的话一个月左右。过期后脚本会报未登录或鉴权失败重新抓取Cookie更新到环境变量即可。我建议定时任务里加一个检查Cookie是否过期的辅助逻辑具体做法见后面的章节。2.4 Cookie写入青龙面板环境变量拿到Cookie后在青龙面板的环境变量中新建一个变量变量名JD_COOKIE变量值你复制的完整Cookie字符串如果你的服务器上跑了多账号每个账号一个Cookie可以按多行输入青龙面板会把每一行当作一个独立的账号。格式如下pt_keyxxx;pt_pinuser1; pt_keyyyy;pt_pinuser2; pt_keyzzz;pt_pinuser3;脚本运行时会读取这个环境变量先按行拆分账号再从每行拆分Cookie字段。这种多账号格式是目前京东脚本的通用标准后面写代码也照着这个格式来。3. 核心脚本设计与实现3.1 脚本整体结构与模块划分评价脚本不是一段简单的代码堆在一起而是按职责划分成几个清晰的模块配置模块读取环境变量、评价模板、频率控制参数接口模块封装所有京东接口调用包括拉取订单列表、提交评价评价内容生成模块根据订单信息生成符合平台规范的评价内容主流程模块串联整个评价流程处理异常和重试这样划分的好处是后面接口变动了只需要改接口模块评价模板调整只需要改内容生成模块互不干扰。以下是我使用的脚本目录结构jd_comment/ ├── config.js # 配置读取和环境初始化 ├── api.js # 京东接口封装 ├── comment.js # 评价内容生成 ├── index.js # 主流程入口 └── package.json # 依赖声明青龙面板的脚本管理支持目录结构直接新建这些文件即可。也可以把所有代码写在一个文件里但可读性和维护性会差不少。3.2 关键接口分析与调用京东的评价相关接口并不是公开文档化的目前我们实际使用的是两个核心接口拉取待评价订单列表提交评价内容拉取待评价订单列表的接口大致是这样// api.js const axios require(axios); async function getPendingComments(cookie) { const url https://club.jd.com/comment/pendingComment.action; const response await axios.get(url, { headers: { Cookie: cookie, User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://club.jd.com/ } }); return response.data; }这个接口的参数和分页逻辑需要结合返回的JSON结构相应调整。京东的接口偶尔会改参数名或返回结构所以脚本里要有对返回数据的基础校验不能盲目解析。提交评价接口相对复杂需要提交订单号、SKU ID、评分、评价内容、图片等字段。原理上跟手动提交时浏览器发送的请求保持一致的格式和顺序。实操心得第一次写的时候别凭猜构造参数。用浏览器开发者工具手动进行一次完整的评价提交把提交请求的Payload完整记录下来照着它构造脚本这样成功率最高。我踩过很多次以为字段对了实际提交后返豆失败的坑都是因为直接照抄网上过时的接口代码。3.3 评价内容生成真实性与多样性平衡返豆能否成功评价内容占了很大权重。如果所有订单提交的都是同一句好评平台的反作弊系统很容易识别出来轻则不返豆重则账号被限制评价功能。我的模板设计思路是把评价内容拆成几个可变的部分通过随机组合生成多样化的文本。变量部分包括商品名从订单数据中提取物流速度形容词很快还算快比预期好等随机选择商品质量形容词做工不错质感超出预期等随机选择客服态度形容词响应及时耐心等随机选择整体满意度总结会回购推荐整体满意等随机选择把多个随机部分拼装起来再加上偶尔插入的标点变化就能组合出大量不重复的评价模板。代码大概这样// comment.js function generateComment(order) { const productName order.productName || 这个商品; const logisticsWords [物流很快, 快递速度不错, 配送挺及时的, 物流比预期快不少]; const qualityWords [做工很细致, 质感不错, 用料扎实, 和描述一致]; const serviceWords [客服响应及时, 售后处理效率高, 沟通很顺畅]; const overallWords [整体很满意会考虑回购, 这次购物体验不错, 性价比很高值得推荐]; const pick (arr) arr[Math.floor(Math.random() * arr.length)]; return ${productName}收到啦${pick(logisticsWords)}。${pick(qualityWords)}${pick(serviceWords)}。${pick(overallWords)}。; }这种组合方式每次生成的评价都不一样而且读起来是正常的用户口吻不会出现明显的模板痕迹。如果你有配图的条件建议在评价中适当加入1-2张图片。带图评价的返豆大概率比纯文字高平台的规则里写得很清楚。但图片不能随便用建议从真实相册里挑一些与商品相关的实拍图放入脚本的图片目录中。图片上传走的是京东的图片上传接口代码里需要额外实现这个逻辑。3.4 主流程编排与异常处理主流程的编排逻辑是循环每个账号循环该账号下的每一笔待评价订单逐单提交每单之间加随机延时避免请求频率过高。伪代码如下// index.js const { getEnv } require(./config); const { getPendingComments, submitComment } require(./api); const { generateComment } require(./comment); async function processAccount(cookie, accountIndex) { const orders await getPendingComments(cookie); if (!orders || orders.length 0) { console.log(账号${accountIndex 1}: 没有待评价订单); return; } for (const order of orders) { const content generateComment(order); const result await submitComment(cookie, order, content); if (result.success) { console.log(账号${accountIndex 1} 订单${order.orderId}评价提交成功); } else { console.error(账号${accountIndex 1} 订单${order.orderId}评价提交失败: ${result.message}); } await sleep(3000 Math.floor(Math.random() * 5000)); } } async function main() { const accounts getEnv(JD_COOKIE).split(\n).filter(Boolean); for (let i 0; i accounts.length; i) { await processAccount(accounts[i], i); } } main().catch(err console.error(主流程异常:, err));这里有几个关键细节随机延时每次提交之间间隔3到8秒模拟真人操作节奏避免接口被限流单账号异常不影响整体如果某一个账号的Cookie失效或者接口报错不能导致整个脚本崩溃要捕获异常后继续下一个账号结果确认提交接口返回成功不代表返豆一定会到账后面还要有核验步骤3.5 返豆结果核验的辅助逻辑只提交评价但不去确认返豆是否到账这脚本是不完整的。我的做法是每天加一个定时任务读取京豆收支记录接口检查最近几天是否有评价返豆的入账记录。接口返回的数据中包含豆子变化类型其中评价返豆会有专属的类型标识。只要检测到对应类型的入账记录就说明返豆成功了。核验脚本可以单独写一个文件也可以跟主流程脚本放在一起。我建议拆开因为评价脚本可能一天跑一次而核验脚本可以每6小时跑一次频率不同拆开更方便配置定时规则。4. 青龙面板定时配置与运维心得4.1 定时任务配置的最佳实践青龙面板的定时任务配置非常简单。进入定时任务 - 新建任务填写任务名称、执行命令、定时规则。执行命令格式task jd_comment/index.js其中jd_comment/index.js是脚本在脚本管理中的相对路径。定时规则使用标准的cron表达式。这里补充一点cron表达式的基本知识方便你自己调整。cron表达式有5个字段分别代表分、时、日、月、周分 时 日 月 周举例30 10 * * *表示每天上午10点30分执行。评价任务的时间点设置我建议不要跟平台的整点高峰期重合比如618大促期间的整点、上午10点和下午2点这种领券高峰。选择在上午11点和下午4点左右服务器压力小一些成功率相对更高。一天跑几次我的建议是评价任务一天最多跑1-2次因为待评价订单不会短时间内新增很多频繁跑没有意义还增加风控风险。核验任务可以一天跑3-4次间隔拉长些没关系。4.2 Cookie过期检测与自动通知Cookie过期是不定期出现的最烦人的问题。一旦过期评价任务就会全部失败如果不及时发现可能连续好几天都在空跑。解决办法是在脚本里加一个Cookie有效性检测在开始处理账号之前先调一次用户信息接口如果返回未登录就跳过该账号并标记状态。更进一步青龙面板支持配置通知方式包括钉钉、企业微信、Telegram、邮件等。在环境变量中配置好通知相关的变量后脚本里调用青龙面板提供的通知函数即可。例如使用青龙面板内置的sendNotify模块// config.js const notify require(./sendNotify); async function sendMessage(title, content) { try { await notify.sendNotify(title, content); } catch (err) { console.error(消息通知发送失败, err); } }这样Cookie过期、评价失败率过高、返豆核验失败这些异常情况都能第一时间推送到手机上不用每天盯着面板看日志。4.3 日志查看与脚本排错的基础方法脚本出了问题第一件事就是看日志。青龙面板的任务日志会完整记录每次执行的stdout和stderr输出。我在脚本里比较注重日志的输出规范每个账号处理前输出账号索引每笔订单提交后输出订单号与结果每个异常捕获后输出完整的错误堆栈关键节点输出当前时间戳这样一旦日志里出现问题可以快速定位是哪个账号、哪笔订单、哪个环节出错了。一个排查技巧是先用测试模式运行。在脚本里加一个--dry-run参数只拉取待评价订单并打印不实际提交评价。这样既能确认Cookie有效、接口可通又不会误操作把不该评价的订单也提交了。task jd_comment/index.js --dry-run等dry-run确认订单列表准确无误了再正常运行脚本。这个习惯帮我避免了好几次误操作。5. 常见问题与排查技巧实录5.1 高频问题速查表以下是我实际运行过程中遇到频率最高的几个问题整理成表格方便对照排查问题现象可能原因解决方案日志提示未登录或鉴权失败Cookie过期或格式不对重新抓取Cookie确认包含pt_key和pt_pin拉取不到待评价订单订单不在评价窗口期或该商品不支持评价返豆确认下单时间确认商品类目支持评价评价提交后不返豆评价内容被平台判定为低质或重复丰富评价内容增加图片降低评价频率脚本运行卡住不退出接口响应超时未设置给所有axios请求添加超时配置如timeout: 10000多个账号中部分失败其中一个Cookie失效或账号被风控单独排查失败账号更新Cookie或暂缓处理5.2 风控规避的真实经验这个话题比较敏感但我还是想实实在在说几句。平台的风控机制不是针对脚本本身的而是针对异常行为模式。如果一个账号突然在很短时间内批量提交大量评价或者多个账号在同一IP下进行完全一致的操作触发风控是必然的。我的经验是控制频率单账号每天评价的订单数控制在个位数不要超过15单。真实用户不会一天评价几十单拉长间隔同一账号两次评价之间至少间隔3秒以上不同账号之间切换时也做延迟处理多元化评价内容必须多样化避免所有评价都是同一个句式。上面的随机模板已经实现了这一点IP维度如果多个账号共用一个出口IP建议控制同一IP下跑评价的账号数量最理想是不超过3个还有一点很重要不要用脚本去评价那些你根本没买过的订单。京东的数据库里有完整的物流信息和用户行为轨迹凭空出现的评价是最容易被识别的。脚本只应该处理真实存在的、确实收货了的订单。5.3 接口变动后的应对策略京东的接口调用谈不上什么稳定不变。实际上我运行这半年多就遇到过三次接口调整。每次调整后的表现不太一样有时候是返回字段名变了有时候是接口地址变了有时候是提交参数格式变了。应对的核心是不要让脚本逻辑跟接口耦合得太紧。在接口模块里做一层数据清洗把京东接口返回的各种字段统一转换成脚本内部使用的数据结构。这样即使京东改了字段名我只需要修改接口模块里的一个映射函数主流程代码完全不用动。另外脚本里对接口返回值要做充分校验。比如拉取订单列表时如果返回的不是预期的JSON结构就抛异常并打印原始返回值方便第一时间看到接口到底返回了什么。盲目用response.data.orders这种写法接口一改就是undefined排错效率极低。5.4 几个小技巧分享最后再分享几个提高脚本运行稳定性的小技巧任务超时保护。青龙面板默认任务没有超时限制但一个评价脚本如果跑了一小时还没结束多半是卡住了。在任务本身的脚本逻辑里我用Promise.race给整个主流程加了一个全局超时比如30分钟没跑完就强制退出并报错。比在面板侧配置超时更好用因为可以在日志里输出超时时正在处理哪个账号。评价前检查订单状态。有些订单虽然显示在待评价列表但可能因为售后、退款、投诉等原因暂时不能评价。提交前先调一次订单详情接口确认订单状态正常再提交能减少无谓的失败请求。保留历史记录。脚本每处理完一个订单就在本地持久化一个记录记录订单号和评价时间。下次运行脚本时先过滤掉已经评价过的订单避免重复提交。这个逻辑对平台风控和用户体验都很重要重复评价同一订单是最明显的脚本行为特征。备份配置。青龙面板有一个配置文件导出功能里面包含了环境变量和定时任务配置。每次调整完重要配置导出备份一下更换服务器或迁移部署时直接导入省去重新配置的麻烦。6. 从评价脚本看自动化任务的整体设计思路写完这个评价脚本回过头来看其实它不仅仅是个给京东商品刷好评的工具。这个项目里涉及到的很多设计思路对你跑任何自动化任务都有参考价值。首先是面向异常的设计。脚本在编写时我在每个环节都假设了一定会出错而不是一切顺利。Cookie会过期、接口会变动、平台会风控、网络会抖动把这些都当成常态来设计脚本才能长期稳定运行。这与写普通业务代码非常不同跑批任务的代码健壮性优先级永远高于代码优雅度。其次是可观测性。你的自动化脚本跑在无人值守的环境里它的一次执行成功与否、失败原因是什么都必须有完整的日志和通知机制。没有日志的脚本等于黑盒出了问题你只能干瞪眼。我在初始化阶段就把通知渠道配好就是为了让异常能主动找我而不是等我想起来了再去翻日志。再者是渐进迭代。第一版脚本我没有一上来就做多账号、带图评价、返豆核验这些功能。而是先把拉取订单、生成评价、提交评价这条主链路跑通确认接口可用、评价能成功、返豆能到账然后才逐步加上辅助功能。事实证明这个节奏很对每一步的目标都很明确出了问题也容易定位。如果你想把这套能力扩展到别的场景比如自动签到、自动预约、自动下单思路是一样的分析业务流程、抓取接口请求、编写脚本、部署到青龙面板、配置定时和通知。框架都是现成的你只需要替换业务逻辑。这也是为什么我建议花时间弄懂青龙面板的运行原理而不是单纯依赖某一份脚本——一旦掌握方法就拥有了搭建任意自动化任务的能力。