我有一个 Telegram 频道 @Lx_groups，定位是 AI 白嫖资讯——免费 API 额度、限时活动、开源项目、行业新闻，专注"真免费"，不推灰产和广告。它背后的引擎是一个 Cloudflare Worker：抓上游 TG 频道预览页 + GitHub atom + 大厂 RSS，KV 去重，再通过 Bot API 推送到频道。
抓取链路跑起来不难，难的是质量。上游论坛里鱼龙混杂：有真限免，也有灰产教程、拉人头邀请码、论坛灌水帖、还有上游转发残留的乱码碎片。一开始我只能每天早上手动翻一遍频道，眼睛过一遍昨天推的 20 条，挑出有问题的，再回去改 Worker 的过滤规则。这很累，而且容易漏。
第一步：把"每天早上手动翻频道"变成 cron
第一件事是让"审核"这件事本身自动化。我给 Hermes Agent 建了一个每天 5:30 跑的 cron job：它先 curl 频道预览页 t.me/s/Lx_groups，用一个 Python 脚本解析出最近 24 小时的每条消息（时间、链接、正文），再交给 agent 逐条判定，按一套固定标准分类：
- ✅ 正常：AI/大模型相关的免费额度、限免、开源、新闻、工具
- ⚠️ 广告/引流：邀请码拉人头、软广、品牌推广
- 🚫 灰产：盗版、破解、钻漏洞薅羊毛、封号风险操作
- 📝 乱码/碎片：论坛发帖通知碎片、灌水、格式乱码、上游转发残留
- ❓ 存疑：不确定的
agent 每天早上把报告发到我的 TG，我醒来直接看结论：今天 N 条，问题 Y 条，哪几条要删，哪几条要加黑名单关键词。审核这一步从此不再占用我的注意力。
第二步：审核报告不是终点，是改进的输入
但很快我发现一个问题：审核报告天天发，问题也天天有。今天报告说"有 4 条链接重复 6 次"，我手动改一下 Worker；明天报告又说"有论坛灌水帖漏网"，我再手动改一下。审核自动化了，改进还是手动的——这等于闭环断了一截。
于是我调整了流程：不再把审核报告当终点，而是把它当改进提示词的素材。攒了 6 天报告（8/9 ~ 8/14，共 120 条推送，40 条有问题）后，我把 6 天的问题扫一遍，按根因归类，整合成一份结构化的改进提示词，交给 Claude Code 去改 Worker。
整合不是简单堆砌。6 天 40 条问题归出来是 9 类，但并非每一类都适合用硬规则自动拦截。我做了一次人为筛选，这步很关键：
- 适合自动拦截的（交给 Claude Code）：链接重复、论坛元数据标签残留、论坛灌水帖碎片、重复推送去重失效、聚合拼接 bug、系统测试消息残留——这些有明确的机器特征，正则/去重逻辑能精确命中。
- 不适合自动拦截的（必须保留人工判断）：灰产加强、非 AI 内容过滤、付费产品软广。
为什么第二类不适合自动拦？因为它们会误杀真正有价值的信息源。举个真实例子：第一次整合提示词时，我把"灰产加强"和"非 AI内容过滤"也列进去了，想用关键词硬拦。但很快发现——这两类恰恰是频道最吸引人的文章信息源。一条讲"绕过模型隐藏推理保护"的帖子，关键词命中"绕过"会被当灰产拦掉，但它本质是 AI 技术研究，是读者爱看的深度内容；一条来自 nodeloc 的 eSIM 保号卡，不含 AI 关键词会被"非 AI 过滤"拦掉，但它背后指向的优惠方法和脚本套路，恰恰是白嫖圈最关心的实战情报。
硬规则一上，这些有争议但有价值的内容就没了。频道会变得"安全但无聊"。所以这一类我刻意从自动改进清单里拿掉，留给每日审核报告里我自己看一眼拍板——自动化的边界要划在"能精确判断"的地方，判断不了的留给人工。
第三步：提示词的形态
整合完的提示词我写成一个 md 文件放桌面，形态是纯指令式——不是给人看的散文，是直接可以复制粘贴给 Claude Code 的命令。结构是：
- 项目背景：路径、核心文件、部署命令、测试端点
- 已修复（禁止改动）：上一轮已经修好的（比如
dedupUrls函数）不许再动，防止重复劳动 - 待执行改进：每项含现象、样本、修复指令，按优先级 P0/P1/P2 排
- 硬约束：只改哪些文件、保留哪些机制不能删、部署+验证命令
- 执行顺序：编号步骤，最后必须部署+curl 验证+出报告
这种形态的好处是 Claude Code 拿到就能直接跑，不用我再口头交代"先做哪个后做哪个"“别忘了部署”。提示词里还显式标注了"不要中途问问题，一口气做完"——避免它每步都停下来问我。
闭环现状与下一步
现在的闭环是这样跑的：
闭环已经在跑，但还差最后一截：改进这一步还是我手动触发的——我要手动读报告、手动整合、手动筛、手动粘给 Claude Code。下一步是把这截也自动化：让 agent 攒满 N 天报告后自己整合、自己按"适合自动拦截 vs 保留人工"的规则筛、自己调 Claude Code CLI 跑改进、自己部署验证。我只在最后审核报告里看一眼"这轮改进修了什么"。
不过在那之前，有一个前提必须先解决：自动筛选的判断标准要足够稳。这次我手动筛掉了灰产加强和非 AI 过滤，是因为它们会误杀有价值的内容源。如果交给 agent 自动筛，agent 得能稳定复现这个判断——否则一旦 agent 把不该自动拦的也列进去，一轮"全自动化改进"跑完，频道最有价值的内容反而被自家系统清掉了，这就本末倒置了。所以下一步的真正顺序是：先把"适合自动拦截"的判断规则固化成可复现的 prompt 模板，验证几轮，再放开全自动。
闭环的意义不在于"全自动"这个标签，而在于每一环都有可验证的输出：审核报告是可读的、提示词是可复用的、改进是可部署验证的。每一步都能拿出来看对不对，不对就能回退。这比一上来就追求"全自动改进"要稳得多。
延伸阅读: