简介面向论文写作者与文案创作者这份AI降重资源将浏览器插件工具与多种提示词模板合为一体可在降低文本重复率的同时提升原创度。压缩包内共19个文件总体积约28KB包含6个Markdown提示词文档、6个JavaScript逻辑脚本、2个HTML页面以及CSS样式、JSON配置和bat一键安装脚本其中md文件覆盖润色、风格个性化、写作指导等场景js与html构成插件核心功能bat便于快速部署。已有405人学习浏览。借助无限注册续杯机制用户可持续获取使用权限插件源码完整可自行修改调整还能根据提示词模板灵活适配论文、自媒体等不同创作需求适合需要长期降重且希望兼顾效率与原创度的学生和文案从业者。1. AI 降重「无限注册 续杯」解决的不只是省钱把一段几百字的初稿丢进某个降重工具弹窗告诉你今天还剩三次免费机会换一个入口登录次数变了但总量没变。更多人遇到的是第二种情况服务按天重置免费额度登录一次、点一次「领取」就又能跑一段文本。于是「AI 降重无限注册续杯」成了大家既想蹭又不完全搞得清边界的技术关键词——它背后其实是一套完整工程批量创建真实可用的邮箱身份把注册流程自动化再用插件或定时任务把每天的免费额度接住最终由一批精心调过的提示词去完成「降重」这个动作。这篇文章从一个常写自动化脚本的工程师视角把注册、续杯、提示词、本地验证四段链路一次讲透适合已经在折腾 AI 工具和提示词工程但不想整天手动刷新网页的人。2. 注册链路的自动化和“无限账号”的边界先说清楚所谓「无限注册」最常见落地路径不是对抗验证码而是掌握一个能批量产生真实收件地址的渠道再用浏览器自动化把「填表 → 收信 → 激活」这个环节跑成无人值守。真正被忽略的是账号池的另一端——服务商用什么识别你、续杯的逻辑挂在哪个字段上这决定了你的脚本是十分钟写完还是折腾一整天。2.1 先看清降重服务的身份识别链路大部分网页版降重工具本质是「包了一层壳的 LLM API」前端把文本连同改写提示词发给后端后端调大模型计费前端靠登录态标记身份。常见的识别方式有三类识别方式典型表现续杯脚本要做什么Cookie Session注册后种一个 session id保持 Cookie 上下文续杯时直接复用JWT / Token登录后返回 access_token定期调 refresh 或重新登录换新 tokenAPI Key用户在控制台自取密钥续杯即重置次数不需要处理登录态动手写脚本前我会先开浏览器 DevTools 看一遍注册后的网络请求仔细在 Local Storage 里看到的是一个 JSON 格式的 token还是请求头里自动带上的 Cookie。前者意味着续杯时可以直接用requests调接口后者意味着要用 Playwright 这类带有完整上下文的工具单纯复制 Cookie 经常被后端追加上下文校验顶回来。2.2 用自建域名 catch-all 实现可持续的注册邮箱「无限注册」的技术底座一般是自建域名的邮件路由。只要在域名服务商那里开启 catch-all也就是把所有任意前缀yourdomain.com的邮件统一转发到一个真实收件箱就能做到注册一个、新造一个邮箱前缀且每个地址真实可收信。常见做法是给 Cloudflare Email Routing 写一条Catch-all - 你的常用邮箱规则没有成本也不用维护邮件服务器。注册脚本只是把邮箱发出去还不够激活链接通常回在邮件正文里所以脚本还要具备读信能力。下面这段用 IMAP 拉取验证链接的逻辑我在多个项目里复用很稳定import imaplib import email import re from email.header import decode_header IMAP_SERVER imap.example.com ACCOUNT youexample.com PASSWORD your-app-password def fetch_verify_link(subject_keyword: str, since_days: int 1) - str | None: conn imaplib.IMAP4_SSL(IMAP_SERVER) conn.login(ACCOUNT, PASSWORD) conn.select(INBOX) # 搜索最近一天内标题包含指定关键词的邮件 status, messages conn.search(None, f(SUBJECT {subject_keyword})) if status ! OK or not messages[0]: return None # 取最新一封避免读到历史注册邮件 latest_id messages[0].split()[-1] _, msg_data conn.fetch(latest_id, (RFC822)) raw msg_data[0][1] msg email.message_from_bytes(raw) # 兼容邮件编码先从标题里拿到激活字符串 subject decode_header(msg[Subject])[0][0] if isinstance(subject, bytes): subject subject.decode(utf-8, errorsignore) for part in msg.walk(): content_type part.get_content_type() if content_type in (text/plain, text/html): body part.get_payload(decodeTrue).decode(utf-8, errorsignore) match re.search(rhttps://[^\s\]?activate[^\s\]*, body) if match: return match.group(0) return NoneIMAP 脚本有两个地方要特别注意。一是邮件到达有延迟注册后不能立刻拉取要配合后面的轮询逻辑间隔 510 秒重试二是很多域名邮箱服务要求单独开应用专用密码明文密码做双因素校验时会直接登录失败。把since_days收窄到 1 天也是为了避免账号池里老邮件干扰新验证链接的提取。2.3 用 Playwright 把注册页面流程跑通邮箱链路解决以后注册动作本身用 Playwright 最省事。它的好处是能真实渲染前端页面遇到 Vue/React 这类动态渲染表单比用requests去猜接口参数靠谱得多。from playwright.sync_api import sync_playwright REGISTER_URL https://xxx.example.ai/register EMAIL abc-20250408yourdomain.com with sync_playwright() as p: browser p.chromium.launch( headlessTrue, args[--disable-blink-featuresAutomationControlled], ) context browser.new_context( localezh-CN, timezone_idAsia/Shanghai, viewport{width: 1280, height: 800}, ) page context.new_page() page.goto(REGISTER_URL, wait_untilnetworkidle) page.fill(#email, EMAIL) page.fill(#password, Aa123456!) page.check(input[nameagreement]) page.click(button[typesubmit]) # 注册成功后会跳转到控制台或触发弹窗 page.wait_for_selector(text注册成功, timeout15000) token page.evaluate(() localStorage.getItem(access_token)) print(拿到 token:, token) browser.close()这段代码里值得细看的是new_context的参数。每个账号都建一个独立 context避免 Cookie 串号timezone_id和locale保持和账号主体一致能降低被风控单独标记的概率。--disable-blink-featuresAutomationControlled是去掉 WebDriver 标记比较通用的做法但注意它只能处理一部分特征更严格的服务还会探测屏幕尺寸、Canvas 指纹、字体列表那种场景需要再套一层指纹伪装已经属于对抗范畴这里不展开。注册链路里最容易卡住的三处按出现频率排第一验证码目前没有通用解法我的建议是先选风控没那么强的服务调通整个流程第二邮箱验证时效很多服务 10 分钟内不使用激活链接就失效所以 IMAP 轮询要放在注册逻辑里一起跑第三重复注册检测品牌邮箱域名比如gmail.com高重复率时极易被拉黑自建域名会好很多但同一个域名注册超过十来个账号后还是要观察发现被限流就换域名前缀。3. 续杯的自动化油猴插件、定时任务和账号状态机「续杯」本质是定期告诉服务端「我还在、额度给我重置」。如果降重服务没有开放 API最直接的方式就是写一个跑在浏览器里的插件如果服务有 JSON 接口则可以用定时任务直接调接口。两者解决的问题不同插件解决「人在电脑前不想手动点」定时任务解决「人不在了额度也能自动续」。3.1 用油猴插件做手动刷新场景下的续杯大部分网页版工具在免费次数用完以后会有「明天再来」或「每日领取」这类按钮点击后额度重置。这种场景写 Tampermonkey 用户脚本比做独立浏览器扩展快得多。下面是我常用的一套通用模板匹配策略靠按钮文字适配性很强// UserScript // name AI降重复刷助手 // namespace local.refill.tool // match https://xxx.example.ai/* // grant none // /UserScript (function () { use strict; const triggerTexts [立即领取, 免费续杯, 每日重置]; function tryRefill() { const candidates document.querySelectorAll(button, a, [rolebutton], span); for (const el of candidates) { const text el.innerText?.trim() || ; if (triggerTexts.some((t) text.includes(t))) { el.click(); console.log([续杯] 已点击:, text, new Date().toLocaleString()); return true; } } return false; } // 每 10 分钟检查一次不抢服务端资源 setInterval(() { tryRefill(); }, 10 * 60 * 1000); // 页面刚加载时也立即执行一次 window.addEventListener(load, tryRefill); })();这里用setInterval而不是MutationObserver是因为按钮可能在点击后动态隐藏再重新渲染定时轮询的代码更简单也不容易被框架内部的状态更新搞乱。triggerTexts是核心维护点不同家服务的文案差异基本都在这里实际部署时建议把常用文案都放进数组。3.2 账号池的数据结构和状态机注册和续杯凑在一起以后账号就不再是单个字符串而是一个要持续维护状态的对象。我一般用 SQLite 存数据比 JSON 文件更抗并发字段设计如下CREATE TABLE accounts ( id INTEGER PRIMARY KEY AUTOINCREMENT, email TEXT UNIQUE NOT NULL, token TEXT, token_expires_at DATETIME, quota_left INTEGER DEFAULT 0, state TEXT DEFAULT idle, -- idle / active / exhausted / banned last_used_at DATETIME, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );账号状态流转闭环是idle表示可用进入续杯任务后先拉一次当前额度额度不足就把state改成exhausted等待下一个轮询周期如果额度恢复就改回active并记录可用次数。banned状态是给注册频繁或接口调用异常的账号兜底避免同一个坏账号反复拖累整个池子。3.3 用 cron 或 systemd 定时跑续杯任务账号池建好以后续杯就是一套离线任务。最省力的方式是写一个 Python 脚本挂在 cron 里每天定时执行# 每天凌晨 0 点 5 分跑一次续杯日志追加到独立文件 5 0 * * * /usr/bin/python3 /opt/refill/refill_loop.py --config /opt/refill/config.json /var/log/refill.log 21脚本内部的核心逻辑概括起来就是一个带重试和随机延迟的循环import time, random, sqlite3 def refill_all_accounts(): conn sqlite3.connect(accounts.db) rows conn.execute(SELECT id, email, token FROM accounts WHERE state IN (idle, exhausted)).fetchall() for account_id, email, token in rows: try: quota query_quota(token) # 查询当前剩余次数 if quota 1: refill(account_id, token) # 执行续杯请求 time.sleep(random.uniform(2, 6)) # 随机间隔避免打满服务端频率 except TokenExpiredError: refresh_login(account_id) # 见 5.2token 过期时回退到重新登录 except RequestTooFrequentError: time.sleep(random.uniform(30, 60)) # 被限流时退避refresh_login(account_id)是这套体系里最容易被忽略的坑大多数服务给 token 设置的寿命短几天后就不可能通过同一个 token 续杯。此时稳住整个账号池的关键是让脚本里持有 2.3 那套 Playwright 登录代码检测到 401 就触发一次完整登录流程再拿新 token。并发控制在 4 个账号以内连续注册和续杯地写在一遍循环里多数轻量服务不会恶意针对。4. 降重提示词模型怎么用比用什么模型更重要无限注册和续杯只解决「有没有额度」的问题真正影响博客质量的还是提示词。很多人在 VS Code 插件或者 Cursor 这类 AI 编程环境里调过提示词很容易发现换个大模型同一个降重模板的输出风格差异很大。「提示词工程」在这里的目标不是让模型写出多惊艳的金句而是稳定地输出「重复度低、信息不丢、AI 味淡」的改写文本。4.1 基础模板实现「一次改写」我在这里写一个最常用、能直接复制到任何聊天助手里的降重提示词模板你现在是资深中文编辑帮我将下面文本进行降重改写。要求 1. 保留所有数字、专有名词和核心事实不能篡改数据 2. 尽量避免“然而”“此外”“值得注意的是”这类高频连接词 3. 打乱原句的修饰语位置和主谓顺序短句和长句交替出现 4. 不要输出任何解释或前缀直接输出改写后的正文。 原文 {把需要降重的段落粘贴在这里}这个模板看起来简单三条约束各有用途。第 1 条是防止大模型为了降低重复度用数字替换的方式偷懒要知道对技术文档来说一个版本号被改错比重复度高更严重。第 2 条是针对中文 AI 文风的高频词做负向约束这类词是构成 AI 检测器「机器味」的重要特征。第 3 条则直接改变句法结构这是降重最核心的处理手段。4.2 面向多轮降重的进阶提示词策略一次改写往往不够真正需要提交到严格的查重系统里通常会跑两到三轮。多轮降重里容易犯的错是同一模型反复用同一个 prompt 改同一段话改出来的结果只是换了部分词句式骨架没动。我的做法是把每一轮的目标拆开比如第二轮只看句式第三轮专门处理 AI 味第二轮只调整句式不换同义词。 把原文里所有长句拆成短句把原文里的短句合并为带有插入语的长句 保持每一句的信息顺序不变。 第三轮去掉 AI 痕迹。 把以下文本中的连接词(然而、此外、因此)删掉或换成口语化表达 适当增加但是其实、说实话这类真实写作中常见的小转折。 输出结果不要解释直接给文本。多轮提示词之间可能会产生语义漂移即越改离原意越远。所以在批量跑完三轮以后我建议把原文和输出交给一个简单相似度检查超过阈值就重新用初版再跑一次相关实现放在下面第 5 章。降重策略对重复率的影响副作用适用场景同义词替换降低有限容易变成生僻词堆砌快速过一遍调整句式语序降低明显长句容易读不通技术文档、论文摘要插入连接/口语词降低一般字数明显膨胀需要控制篇幅时慎用删除模板连接词降低 AI 味个别上下文会显得突兀面向 AI 生成检测4.3 批量调用时提示词与模型参数怎么配合自动化场景里不可能每次手动粘贴原文一般用兼容 OpenAI Chat Completions 的接口封装一层。下面代码把提示词模板独立存成文件改 prompt 时不用动主程序逻辑from openai import OpenAI import pathlib client OpenAI( base_urlhttps://api.example.com/v1, api_keysk-your-key, ) PROMPT_TEMPLATE pathlib.Path(refine_prompt.txt).read_text(encodingutf-8) def refine_text(original: str): resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: PROMPT_TEMPLATE}, {role: user, content: original}, ], temperature0.8, presence_penalty0.3, frequency_penalty0.2, max_tokens2048, ) return resp.choices[0].message.contenttemperature、presence_penalty、frequency_penalty这三个参数是按降重场景调过的。temperature0.8让模型在保留原意的同时有足够随机性presence_penalty0.3提高新词组出现的概率避免整段沿用原文短语frequency_penalty0.2比较保守防止模型反复使用同一个替代词。max_tokens设置为原文长度的 1.52 倍文本长时如果卡到上限会出现截断导致后半段没有处理。提示词模板单独放文件还有一个好处你可以拿同样一段测试文本只改 prompt 文件内容来跑回归测试不需要每次改 Python 代码。我在本地项目里会同时维护refine_v1.txt、refine_v2.txt两个版本对比它们在同样参数下的输出择优上位。5. 每次续杯前先在本地量化“降重率”并让账号池自动换新令牌这一章不用写多但两个技巧能做到「精准续杯、不好不续」一是用文本相似度作为降重效果的本地量化标准二是当账号 token 失效时自动回退到注册脚本重新登录把账号池盘活。5.1 用 TF-IDF 余弦相似度快速检验降重率在没有查重系统可用时我先用 TF-IDF 算原文和改稿的余弦相似度作为降重效果的参考指标。这个指标不能完全替代专业查重系统但用来做 A/B 测试和 prompt 优化已经足够from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity def similarity_score(original: str, rewritten: str) - float: vec TfidfVectorizer(tokenizerlambda t: list(t.split( ))) matrix vec.fit_transform([original, rewritten]) return round(cosine_similarity(matrix[0:1], matrix[1:2])[0][0], 4) score similarity_score(original_text, rewritten_text) if score 0.7: print(降重不充分需要调整提示词后再跑) else: print(输出可用交给账号池发放)中文按空格分词做不了太细的切分简单场景可以把句子用jieba替代空格分词。实践上原始重复率在 0.85 以上的文本经过 4.1 的模板一轮处理后如果得分还在 0.75说明提示词中的句法约束没有生效优先检查和 prompt 里的第 3 条是否被模型忽略而不是盲目加参数。5.2 令牌失效后的自动“再登录”回路续杯任务跑一阵子以后会出现一种典型故障账号被踢下线请求返回 401脚本里如果没有兜底逻辑这个账号会一直卡在exhausted状态。正确的做法是把 2.3 里的 Playwright 登录逻辑封装成一个可被调度器调用的函数def refresh_login(account_id: int, email: str, password: str) - str: # 这段是老逻辑见 2.3 节 token playwright_login(email, password) # 更新数据库里的 token 和过期时间 update_token(account_id, token) return token需要注意refresh_login的触发次数越多账号被判风险的概率也越高。我会在 SQLite 里给refresh_count建一个字段当单个账号的登录刷新次数在一周内超过 5 次就把它降到idle并通知提醒换新身份而不必持续重试同一个受伤账号。把「401 → 重新登录 → 更新 token」这个回路接进 3.3 的续杯循环账号池才能实现长时间不人工干预的稳定运转。本文还有配套的精品资源点击获取 AI降重自动化实战：无限注册、续杯与提示词工程
简介面向论文写作者与文案创作者这份AI降重资源将浏览器插件工具与多种提示词模板合为一体可在降低文本重复率的同时提升原创度。压缩包内共19个文件总体积约28KB包含6个Markdown提示词文档、6个JavaScript逻辑脚本、2个HTML页面以及CSS样式、JSON配置和bat一键安装脚本其中md文件覆盖润色、风格个性化、写作指导等场景js与html构成插件核心功能bat便于快速部署。已有405人学习浏览。借助无限注册续杯机制用户可持续获取使用权限插件源码完整可自行修改调整还能根据提示词模板灵活适配论文、自媒体等不同创作需求适合需要长期降重且希望兼顾效率与原创度的学生和文案从业者。1. AI 降重「无限注册 续杯」解决的不只是省钱把一段几百字的初稿丢进某个降重工具弹窗告诉你今天还剩三次免费机会换一个入口登录次数变了但总量没变。更多人遇到的是第二种情况服务按天重置免费额度登录一次、点一次「领取」就又能跑一段文本。于是「AI 降重无限注册续杯」成了大家既想蹭又不完全搞得清边界的技术关键词——它背后其实是一套完整工程批量创建真实可用的邮箱身份把注册流程自动化再用插件或定时任务把每天的免费额度接住最终由一批精心调过的提示词去完成「降重」这个动作。这篇文章从一个常写自动化脚本的工程师视角把注册、续杯、提示词、本地验证四段链路一次讲透适合已经在折腾 AI 工具和提示词工程但不想整天手动刷新网页的人。2. 注册链路的自动化和“无限账号”的边界先说清楚所谓「无限注册」最常见落地路径不是对抗验证码而是掌握一个能批量产生真实收件地址的渠道再用浏览器自动化把「填表 → 收信 → 激活」这个环节跑成无人值守。真正被忽略的是账号池的另一端——服务商用什么识别你、续杯的逻辑挂在哪个字段上这决定了你的脚本是十分钟写完还是折腾一整天。2.1 先看清降重服务的身份识别链路大部分网页版降重工具本质是「包了一层壳的 LLM API」前端把文本连同改写提示词发给后端后端调大模型计费前端靠登录态标记身份。常见的识别方式有三类识别方式典型表现续杯脚本要做什么Cookie Session注册后种一个 session id保持 Cookie 上下文续杯时直接复用JWT / Token登录后返回 access_token定期调 refresh 或重新登录换新 tokenAPI Key用户在控制台自取密钥续杯即重置次数不需要处理登录态动手写脚本前我会先开浏览器 DevTools 看一遍注册后的网络请求仔细在 Local Storage 里看到的是一个 JSON 格式的 token还是请求头里自动带上的 Cookie。前者意味着续杯时可以直接用requests调接口后者意味着要用 Playwright 这类带有完整上下文的工具单纯复制 Cookie 经常被后端追加上下文校验顶回来。2.2 用自建域名 catch-all 实现可持续的注册邮箱「无限注册」的技术底座一般是自建域名的邮件路由。只要在域名服务商那里开启 catch-all也就是把所有任意前缀yourdomain.com的邮件统一转发到一个真实收件箱就能做到注册一个、新造一个邮箱前缀且每个地址真实可收信。常见做法是给 Cloudflare Email Routing 写一条Catch-all - 你的常用邮箱规则没有成本也不用维护邮件服务器。注册脚本只是把邮箱发出去还不够激活链接通常回在邮件正文里所以脚本还要具备读信能力。下面这段用 IMAP 拉取验证链接的逻辑我在多个项目里复用很稳定import imaplib import email import re from email.header import decode_header IMAP_SERVER imap.example.com ACCOUNT youexample.com PASSWORD your-app-password def fetch_verify_link(subject_keyword: str, since_days: int 1) - str | None: conn imaplib.IMAP4_SSL(IMAP_SERVER) conn.login(ACCOUNT, PASSWORD) conn.select(INBOX) # 搜索最近一天内标题包含指定关键词的邮件 status, messages conn.search(None, f(SUBJECT {subject_keyword})) if status ! OK or not messages[0]: return None # 取最新一封避免读到历史注册邮件 latest_id messages[0].split()[-1] _, msg_data conn.fetch(latest_id, (RFC822)) raw msg_data[0][1] msg email.message_from_bytes(raw) # 兼容邮件编码先从标题里拿到激活字符串 subject decode_header(msg[Subject])[0][0] if isinstance(subject, bytes): subject subject.decode(utf-8, errorsignore) for part in msg.walk(): content_type part.get_content_type() if content_type in (text/plain, text/html): body part.get_payload(decodeTrue).decode(utf-8, errorsignore) match re.search(rhttps://[^\s\]?activate[^\s\]*, body) if match: return match.group(0) return NoneIMAP 脚本有两个地方要特别注意。一是邮件到达有延迟注册后不能立刻拉取要配合后面的轮询逻辑间隔 510 秒重试二是很多域名邮箱服务要求单独开应用专用密码明文密码做双因素校验时会直接登录失败。把since_days收窄到 1 天也是为了避免账号池里老邮件干扰新验证链接的提取。2.3 用 Playwright 把注册页面流程跑通邮箱链路解决以后注册动作本身用 Playwright 最省事。它的好处是能真实渲染前端页面遇到 Vue/React 这类动态渲染表单比用requests去猜接口参数靠谱得多。from playwright.sync_api import sync_playwright REGISTER_URL https://xxx.example.ai/register EMAIL abc-20250408yourdomain.com with sync_playwright() as p: browser p.chromium.launch( headlessTrue, args[--disable-blink-featuresAutomationControlled], ) context browser.new_context( localezh-CN, timezone_idAsia/Shanghai, viewport{width: 1280, height: 800}, ) page context.new_page() page.goto(REGISTER_URL, wait_untilnetworkidle) page.fill(#email, EMAIL) page.fill(#password, Aa123456!) page.check(input[nameagreement]) page.click(button[typesubmit]) # 注册成功后会跳转到控制台或触发弹窗 page.wait_for_selector(text注册成功, timeout15000) token page.evaluate(() localStorage.getItem(access_token)) print(拿到 token:, token) browser.close()这段代码里值得细看的是new_context的参数。每个账号都建一个独立 context避免 Cookie 串号timezone_id和locale保持和账号主体一致能降低被风控单独标记的概率。--disable-blink-featuresAutomationControlled是去掉 WebDriver 标记比较通用的做法但注意它只能处理一部分特征更严格的服务还会探测屏幕尺寸、Canvas 指纹、字体列表那种场景需要再套一层指纹伪装已经属于对抗范畴这里不展开。注册链路里最容易卡住的三处按出现频率排第一验证码目前没有通用解法我的建议是先选风控没那么强的服务调通整个流程第二邮箱验证时效很多服务 10 分钟内不使用激活链接就失效所以 IMAP 轮询要放在注册逻辑里一起跑第三重复注册检测品牌邮箱域名比如gmail.com高重复率时极易被拉黑自建域名会好很多但同一个域名注册超过十来个账号后还是要观察发现被限流就换域名前缀。3. 续杯的自动化油猴插件、定时任务和账号状态机「续杯」本质是定期告诉服务端「我还在、额度给我重置」。如果降重服务没有开放 API最直接的方式就是写一个跑在浏览器里的插件如果服务有 JSON 接口则可以用定时任务直接调接口。两者解决的问题不同插件解决「人在电脑前不想手动点」定时任务解决「人不在了额度也能自动续」。3.1 用油猴插件做手动刷新场景下的续杯大部分网页版工具在免费次数用完以后会有「明天再来」或「每日领取」这类按钮点击后额度重置。这种场景写 Tampermonkey 用户脚本比做独立浏览器扩展快得多。下面是我常用的一套通用模板匹配策略靠按钮文字适配性很强// UserScript // name AI降重复刷助手 // namespace local.refill.tool // match https://xxx.example.ai/* // grant none // /UserScript (function () { use strict; const triggerTexts [立即领取, 免费续杯, 每日重置]; function tryRefill() { const candidates document.querySelectorAll(button, a, [rolebutton], span); for (const el of candidates) { const text el.innerText?.trim() || ; if (triggerTexts.some((t) text.includes(t))) { el.click(); console.log([续杯] 已点击:, text, new Date().toLocaleString()); return true; } } return false; } // 每 10 分钟检查一次不抢服务端资源 setInterval(() { tryRefill(); }, 10 * 60 * 1000); // 页面刚加载时也立即执行一次 window.addEventListener(load, tryRefill); })();这里用setInterval而不是MutationObserver是因为按钮可能在点击后动态隐藏再重新渲染定时轮询的代码更简单也不容易被框架内部的状态更新搞乱。triggerTexts是核心维护点不同家服务的文案差异基本都在这里实际部署时建议把常用文案都放进数组。3.2 账号池的数据结构和状态机注册和续杯凑在一起以后账号就不再是单个字符串而是一个要持续维护状态的对象。我一般用 SQLite 存数据比 JSON 文件更抗并发字段设计如下CREATE TABLE accounts ( id INTEGER PRIMARY KEY AUTOINCREMENT, email TEXT UNIQUE NOT NULL, token TEXT, token_expires_at DATETIME, quota_left INTEGER DEFAULT 0, state TEXT DEFAULT idle, -- idle / active / exhausted / banned last_used_at DATETIME, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );账号状态流转闭环是idle表示可用进入续杯任务后先拉一次当前额度额度不足就把state改成exhausted等待下一个轮询周期如果额度恢复就改回active并记录可用次数。banned状态是给注册频繁或接口调用异常的账号兜底避免同一个坏账号反复拖累整个池子。3.3 用 cron 或 systemd 定时跑续杯任务账号池建好以后续杯就是一套离线任务。最省力的方式是写一个 Python 脚本挂在 cron 里每天定时执行# 每天凌晨 0 点 5 分跑一次续杯日志追加到独立文件 5 0 * * * /usr/bin/python3 /opt/refill/refill_loop.py --config /opt/refill/config.json /var/log/refill.log 21脚本内部的核心逻辑概括起来就是一个带重试和随机延迟的循环import time, random, sqlite3 def refill_all_accounts(): conn sqlite3.connect(accounts.db) rows conn.execute(SELECT id, email, token FROM accounts WHERE state IN (idle, exhausted)).fetchall() for account_id, email, token in rows: try: quota query_quota(token) # 查询当前剩余次数 if quota 1: refill(account_id, token) # 执行续杯请求 time.sleep(random.uniform(2, 6)) # 随机间隔避免打满服务端频率 except TokenExpiredError: refresh_login(account_id) # 见 5.2token 过期时回退到重新登录 except RequestTooFrequentError: time.sleep(random.uniform(30, 60)) # 被限流时退避refresh_login(account_id)是这套体系里最容易被忽略的坑大多数服务给 token 设置的寿命短几天后就不可能通过同一个 token 续杯。此时稳住整个账号池的关键是让脚本里持有 2.3 那套 Playwright 登录代码检测到 401 就触发一次完整登录流程再拿新 token。并发控制在 4 个账号以内连续注册和续杯地写在一遍循环里多数轻量服务不会恶意针对。4. 降重提示词模型怎么用比用什么模型更重要无限注册和续杯只解决「有没有额度」的问题真正影响博客质量的还是提示词。很多人在 VS Code 插件或者 Cursor 这类 AI 编程环境里调过提示词很容易发现换个大模型同一个降重模板的输出风格差异很大。「提示词工程」在这里的目标不是让模型写出多惊艳的金句而是稳定地输出「重复度低、信息不丢、AI 味淡」的改写文本。4.1 基础模板实现「一次改写」我在这里写一个最常用、能直接复制到任何聊天助手里的降重提示词模板你现在是资深中文编辑帮我将下面文本进行降重改写。要求 1. 保留所有数字、专有名词和核心事实不能篡改数据 2. 尽量避免“然而”“此外”“值得注意的是”这类高频连接词 3. 打乱原句的修饰语位置和主谓顺序短句和长句交替出现 4. 不要输出任何解释或前缀直接输出改写后的正文。 原文 {把需要降重的段落粘贴在这里}这个模板看起来简单三条约束各有用途。第 1 条是防止大模型为了降低重复度用数字替换的方式偷懒要知道对技术文档来说一个版本号被改错比重复度高更严重。第 2 条是针对中文 AI 文风的高频词做负向约束这类词是构成 AI 检测器「机器味」的重要特征。第 3 条则直接改变句法结构这是降重最核心的处理手段。4.2 面向多轮降重的进阶提示词策略一次改写往往不够真正需要提交到严格的查重系统里通常会跑两到三轮。多轮降重里容易犯的错是同一模型反复用同一个 prompt 改同一段话改出来的结果只是换了部分词句式骨架没动。我的做法是把每一轮的目标拆开比如第二轮只看句式第三轮专门处理 AI 味第二轮只调整句式不换同义词。 把原文里所有长句拆成短句把原文里的短句合并为带有插入语的长句 保持每一句的信息顺序不变。 第三轮去掉 AI 痕迹。 把以下文本中的连接词(然而、此外、因此)删掉或换成口语化表达 适当增加但是其实、说实话这类真实写作中常见的小转折。 输出结果不要解释直接给文本。多轮提示词之间可能会产生语义漂移即越改离原意越远。所以在批量跑完三轮以后我建议把原文和输出交给一个简单相似度检查超过阈值就重新用初版再跑一次相关实现放在下面第 5 章。降重策略对重复率的影响副作用适用场景同义词替换降低有限容易变成生僻词堆砌快速过一遍调整句式语序降低明显长句容易读不通技术文档、论文摘要插入连接/口语词降低一般字数明显膨胀需要控制篇幅时慎用删除模板连接词降低 AI 味个别上下文会显得突兀面向 AI 生成检测4.3 批量调用时提示词与模型参数怎么配合自动化场景里不可能每次手动粘贴原文一般用兼容 OpenAI Chat Completions 的接口封装一层。下面代码把提示词模板独立存成文件改 prompt 时不用动主程序逻辑from openai import OpenAI import pathlib client OpenAI( base_urlhttps://api.example.com/v1, api_keysk-your-key, ) PROMPT_TEMPLATE pathlib.Path(refine_prompt.txt).read_text(encodingutf-8) def refine_text(original: str): resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: PROMPT_TEMPLATE}, {role: user, content: original}, ], temperature0.8, presence_penalty0.3, frequency_penalty0.2, max_tokens2048, ) return resp.choices[0].message.contenttemperature、presence_penalty、frequency_penalty这三个参数是按降重场景调过的。temperature0.8让模型在保留原意的同时有足够随机性presence_penalty0.3提高新词组出现的概率避免整段沿用原文短语frequency_penalty0.2比较保守防止模型反复使用同一个替代词。max_tokens设置为原文长度的 1.52 倍文本长时如果卡到上限会出现截断导致后半段没有处理。提示词模板单独放文件还有一个好处你可以拿同样一段测试文本只改 prompt 文件内容来跑回归测试不需要每次改 Python 代码。我在本地项目里会同时维护refine_v1.txt、refine_v2.txt两个版本对比它们在同样参数下的输出择优上位。5. 每次续杯前先在本地量化“降重率”并让账号池自动换新令牌这一章不用写多但两个技巧能做到「精准续杯、不好不续」一是用文本相似度作为降重效果的本地量化标准二是当账号 token 失效时自动回退到注册脚本重新登录把账号池盘活。5.1 用 TF-IDF 余弦相似度快速检验降重率在没有查重系统可用时我先用 TF-IDF 算原文和改稿的余弦相似度作为降重效果的参考指标。这个指标不能完全替代专业查重系统但用来做 A/B 测试和 prompt 优化已经足够from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity def similarity_score(original: str, rewritten: str) - float: vec TfidfVectorizer(tokenizerlambda t: list(t.split( ))) matrix vec.fit_transform([original, rewritten]) return round(cosine_similarity(matrix[0:1], matrix[1:2])[0][0], 4) score similarity_score(original_text, rewritten_text) if score 0.7: print(降重不充分需要调整提示词后再跑) else: print(输出可用交给账号池发放)中文按空格分词做不了太细的切分简单场景可以把句子用jieba替代空格分词。实践上原始重复率在 0.85 以上的文本经过 4.1 的模板一轮处理后如果得分还在 0.75说明提示词中的句法约束没有生效优先检查和 prompt 里的第 3 条是否被模型忽略而不是盲目加参数。5.2 令牌失效后的自动“再登录”回路续杯任务跑一阵子以后会出现一种典型故障账号被踢下线请求返回 401脚本里如果没有兜底逻辑这个账号会一直卡在exhausted状态。正确的做法是把 2.3 里的 Playwright 登录逻辑封装成一个可被调度器调用的函数def refresh_login(account_id: int, email: str, password: str) - str: # 这段是老逻辑见 2.3 节 token playwright_login(email, password) # 更新数据库里的 token 和过期时间 update_token(account_id, token) return token需要注意refresh_login的触发次数越多账号被判风险的概率也越高。我会在 SQLite 里给refresh_count建一个字段当单个账号的登录刷新次数在一周内超过 5 次就把它降到idle并通知提醒换新身份而不必持续重试同一个受伤账号。把「401 → 重新登录 → 更新 token」这个回路接进 3.3 的续杯循环账号池才能实现长时间不人工干预的稳定运转。本文还有配套的精品资源点击获取