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

青龙面板跑京东相关的自动化脚本，圈内已经不是什么新鲜事了，签到、开卡、领豆的脚本满天飞。但"商品自动评价返京豆"这块，能讲清楚原理、能自己改脚本的人并不多。我去年把一套评价脚本从零写好，放到青龙面板上稳定跑了大半年，中间经历过接口变动、账号风控、评价被拒等各种状况，最后都一一解决了。这篇就把完整的方案拆开揉碎讲清楚，从面板部署到脚本编写，再到问题排查，全部覆盖，照着做就能用。

1. 内容整体设计与思路拆解

1.1 自动评价返豆的底层逻辑

京东的京豆体系里，"商品评价返豆"是最稳定的日常获取渠道之一。规则大致是这样：订单确认收货后，在评价有效期内（不同商品类目窗口期不同，常见是60天），发表符合平台规范的评价内容，系统会返还一定数量的京豆，金额越大、评价越详细，返豆越多。

听起来简单，但真要手动操作，问题就来了：一个账号一个月可能有好几笔待评价订单，每个订单要选星级、填文字、传图片，整套流程走下来一分钟都算快的。如果手里不止一个号，或者订单量稍微大一点，这种机械重复的动作纯属浪费时间。脚本的价值就在这里——把"定位待评价订单、生成评价内容、提交评价"这三个步骤自动化，让机器代替人去做那些无意义的重复点击。

整个流程的核心思路是：

登录京东账号，维持一个有效的会话
拉取所有待评价订单
识别哪些订单符合返豆条件
按预设模板生成评价内容
提交评价并确认返豆结果

这个链路里最难的其实不是自动化本身，而是"如何稳定维持登录态"和"如何模拟出真实用户的评价行为"。后面这两点我会重点展开。

1.2 为什么选青龙面板作为运行环境

在讨论脚本之前，先回答一个基本问题：为什么要把这个脚本放到青龙面板里跑，而不是本地电脑的定时任务？

青龙面板本质是一个定时任务管理平台，专为跑脚本而生，支持cron表达式、依赖管理、运行日志查看、多脚本并发调度。评价脚本这类任务有几个特点，恰好是青龙面板的优势区域：

需要定时触发：平台一般有评价时间窗口，在合适的时间段集中提交，比半夜三更提交成功率更高。青龙面板的定时配置可以精确到分钟。
需要日志留存：返豆不是即时到账，可能需要数小时甚至数天才会入账。你得能回溯某次评价提交时发生了什么，青龙面板的日志记录功能正好满足。
需要低资源运行：评价脚本是轻量级HTTP请求任务，不需要浏览器模拟，资源占用极低，放到家里的软路由、NAS或者任何一台常开的迷你主机上都毫无压力。
多账号集中管理：一个青龙面板实例可以管理多个环境变量，每个环境变量对应一个账号的Cookie，切换、禁用、查看状态都非常方便。

另外，青龙面板自带依赖管理功能，装Node.js依赖包就是一个命令的事，不用自己折腾环境。

1.3 脚本方案选型：Node.js还是Python

目前青龙面板上主流的京东脚本基本是JavaScript（Node.js）和Python两种语言写的。两者都能实现同样的功能，但我在这个项目里选择了Node.js，原因有几点：

青龙面板本身就是Node.js写的，对JS脚本的原生支持最好，日志输出、异常堆栈、依赖安装都更顺畅
京东的接口返回基本都是JSON，Node.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-js

axios是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_key=xxx;pt_pin=user1; pt_key=yyy;pt_pin=user2; pt_key=zzz;pt_pin=user3;

脚本运行时会读取这个环境变量，先按行拆分账号，再从每行拆分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会过期、接口会变动、平台会风控、网络会抖动，把这些都当成常态来设计，脚本才能长期稳定运行。这与写普通业务代码非常不同，跑批任务的代码，健壮性优先级永远高于代码优雅度。

其次是"可观测性"。你的自动化脚本跑在无人值守的环境里，它的一次执行成功与否、失败原因是什么，都必须有完整的日志和通知机制。没有日志的脚本等于黑盒，出了问题你只能干瞪眼。我在初始化阶段就把通知渠道配好，就是为了让异常能主动找我，而不是等我想起来了再去翻日志。

再者是"渐进迭代"。第一版脚本我没有一上来就做多账号、带图评价、返豆核验这些功能。而是先把"拉取订单、生成评价、提交评价"这条主链路跑通，确认接口可用、评价能成功、返豆能到账，然后才逐步加上辅助功能。事实证明这个节奏很对，每一步的目标都很明确，出了问题也容易定位。

如果你想把这套能力扩展到别的场景，比如自动签到、自动预约、自动下单，思路是一样的：分析业务流程、抓取接口请求、编写脚本、部署到青龙面板、配置定时和通知。框架都是现成的，你只需要替换业务逻辑。这也是为什么我建议花时间弄懂青龙面板的运行原理，而不是单纯依赖某一份脚本——一旦掌握方法，就拥有了搭建任意自动化任务的能力。