今天看到了什么

抓数时间:2026-09-18 09:00 CST(2026-09-18T01:00 UTC)。先说清楚口径:web_search 工具本轮仍返回 provider 不可用,未采信。以下信号全部来自 curl 直连实抓与本机实测,逐条给名次、数字与时间。

一、HN 榜上那条 325 分的帖子,是所有自己攒脚本的人的一面镜子。

curl 实抓 HN Algolia API front_page(2026-09-18T01:00 UTC,nbHits=30),第 5 位 325 pts、96 条评论:《My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it》(https://jakeasmith.com/blog/http-build-url/,发布于 2026-09-15T20:53 UTC)。我 web_fetch 抓了原文,几个数字值得抄下来:作者 2014 年为 AOL 的 CMS 写了 174 行 PHP 当作临时补丁(http_build_url),本以为「撑一两年就有人接替」,结果是——Packagist 累计安装 近 2000 万次,现在每月仍有 40 万次新增安装;WordPress 多语言插件 WPML 把它直接打进代码库,WPML 自称装在 150 万个站点 上;它还经由 idna-convert 进了 Debian 与 Ubuntu 的官方包。作者原话:「I never imagined it would go this far.」

这件事刺人的地方不是「临时代码活了十二年」,而是:它一直成功,所以一直没人问它还需不需要存在。直到作者把 deprecated 打上去,那 2000 万次安装里绝大多数使用者才第一次知道,自己跑着的这个东西,是一个 2014 年为了搬家临时写的补丁——而且它还有一个「把路径里所有字母 a 都吃掉」的 bug(原文提到的 GitHub issue)。跑得通 ≠ 该存在。

二、我把自己机器上的脚本扫了一遍,结果比预想难看。

不是引用别人家的数据,是本次现跑:遍历 workspace/scripts、money-plan/scripts、ops、/opt/skill-audit、/opt/backups-drill 五个目录(跳过 node_modules 与 .git),得到 37 个 .py/.sh 脚本、合计 7,564 行。再拿 crontab -l 做交叉比对:

  • 只有 7 个脚本名出现在 crontab 里,也就是还在被定时调用;
  • 30 个不在 crontab 里(占 81%),合计 5,709 行——它们既没被定时跑,也没被任何其他脚本 import 或调用(我做了二次引用计数,其中 13 个引用计数为 0,是真孤儿);
  • 其中 10 个超过 14 天没被改过,最老的一个 24 天;
  • 10 个脚本体内写死了旧站根 /var/www/zyker.cn/(排除 -static 新根):sync_site.py、gen_hot_topics.py、gen_yangxia_archive.py、gen_store.py、gen_sample_pdfs.py、sync_sample.py、deploy_site_pages.sh、verify_visitors.py、site_stats.sh、indexnow_submit.py。它们就算被触发,输出也落在一个 2026-09-10 迁移后已经没人读的目录里——在跑,但等于没跑;
  • 另有 5 条 crontab 条目已于 2026-09-17 被注释禁用(标记 # [ghost-disabled 2026-09-17]),脚本文件却一个没删,仍留在磁盘上等人误触发。

同一个时间窗口里还有个对照组:昨天 04:30 新建的 backup_drill.py 是真在干活的——/var/log/backup-drill/state.json 里 3 次运行全 pass,最近一次 2026-09-18-0430:172 文件 / 10.46 MB / 恢复演练一致 172、不一致 0、缺失 0,耗时 0.8 秒,临时还原目录已清理。一边是每天拿得出证据的新脚本,一边是 30 个不知道还在不在干活的旧脚本。

三、GitHub Trending 上,「让 AI 替你跑起来」的方向还在加速。

curl 直抓 GitHub Trending 网页版(2026-09-18T01:00 UTC,678,617 bytes,解析 20 条),并对 18 个仓库二次调用 GitHub API 核准总星数与描述原文。当日增量前排:第 2 cloudflare/security-audit-skill +3,607、第 1 alibaba/open-code-review +3,286(总 34,757★)、第 4 Tencent/BrowserSkill +1,302。而榜上同时挂着 n8n-io/n8n(总 204,998★,描述「Fair-code workflow automation platform with native AI capabilities」)、cline/cline(68,560★)、coder/coder(14,840★)、cilium/cilium(25,268★)、anthropics/claude-code(145,870★)。工具越来越容易加,但没人替你记「哪个还在用」。

四、中文热搜里也有一句同构的话。

本机七源实时热搜缓存(ts=2026-09-17T20:10,各源 ts 实测 20:10:02–20:10:04):头条实时热榜第 10《机顶盒将成为历史》、同榜第 9《200元以上的月饼礼盒为何卖不动了》。一个东西被静默淘汰时,通常不是它坏了,而是没人再需要它了,但也没人通知它。

谁会疼,疼在哪

疼的是所有「自己攒了一堆自动化」的人:用 cron + Python 脚本跑日报/备份/推送的独立开发者、用小服务器跑工作流的小团队、以及任何用 OpenClaw / n8n / Claude Code 攒过定时任务的超级个体。

具体疼在四处。第一,停了没人知道。 脚本失败会报错,但脚本被时代抛下不会报错——它照样退出码 0,照样写文件,只是写到了一个没人读的目录。第二,不知道该删哪个。 30 个孤儿脚本里,有真该归档的(sync_site.py 写死路径),也有偶尔要手搓一次的(indexnow_submit.py),一刀切删了会误伤,不删又一直占着认知带宽。第三,迁移后的「僵尸输出」最难查。 我把站从 Halo 迁到 Hexo 静态站之后,10 个脚本的输出目标瞬间作废——它们没崩,只是目的地消失了,这类问题不会出现在任何告警里。第四,盘点一次要半天人工。 我自己这次也是现写了遍历 + crontab 交叉比对 + 引用计数才出结果,没有现成工具。

一句话:备份解决「没了能不能回来」,技能包体检解决「还在但被动了知不知道」,而这一条解决的是最容易被忽略的第三问——「它还在干活吗,还是只是在跑?」

可以怎么做

不要重构、不要删库,只做一件事:给脚本做一次「还在不在干活」体检,产出一份清单,然后只处理清单上的异常项。

体检三条判据,都是能一条命令跑出来的机器判据,不靠人回忆:

  1. 有没有人调用 —— 脚本文件名是否出现在 crontab -l 中;不出现再查是否被其他脚本引用(引用计数)。两条都不成立 = 孤儿。
  2. 输出还有没有人读 —— 扫脚本体内的写死路径,是否指向已被迁移/废弃的目录(我这次的判据是 /var/www/zyker.cn 且非 -static)。命中 = 死输出,这类比孤儿更危险,因为它看起来还在工作。
  3. 最近还动过吗 —— mtime 距今天数。超过 14 天且无调用 = 老化,进归档候选。

产出物是一张三列表(路径 / 状态 / 天数),外加一句结论:「N 个在跑、M 个孤儿、K 个死输出」。处理动作分三档,且默认不动手:孤儿且老化的 → 移入 _archive/YYYY-MM-DD/(可恢复,不 rm);死输出的 → 改路径或明确废弃标注;还在跑的 → 像 backup_drill.py 那样补一个可公开的运行证据(日志 + 状态文件),让「在干活」变成可验证而不是靠相信。

第三步是把体检变成常态:把这份清单存进 git,每周 diff 只看新增异常,和 09-17 的技能包体检、每日 04:30 的备份演练放在同一天做。O(n) 的人工判断降为 O(新增量)。

怎么验证

不需要先建站点栏目,拿自己这台机器当第一个样本就够:

  • 样本已跑通:本次实测 37 脚本 / 7 在跑 / 30 孤儿 / 10 死输出 / 13 引用计数为 0,全程只读,未删改任何文件,10 分钟内可复现。
  • 判据要经得起反例:死输出正则会误报(09-18 技能包体检那次就遇到 rm -rf /opt/halo/... 被判高危,人工复核是误报),所以清单只做提示,不做自动处置——这是我这次唯一坚持的硬约束。
  • 对外验证:把这份真实清单(脱敏后)发到小红书/公众号,看 7 天内有没有「能不能帮我扫一遍」的私信。有 5 个以上真实询价再开交付,否则它就只是一篇教程。
  • 变现沿用先例:「自动化体检与加固」交付 500–2000 元/次,沿用 09-11「零/低 API 成本 AI 工作台」已定的同档定价(来源:内部推导,依据 IDEAS.md 历史条目)。

评分

维度 分 理由
需求真伪 4 无终端用户直接表达。但本机 37 脚本中 30 孤儿、10 死输出是实测暴露面而非推测;HN 第 5 位 325 pts「2000 万次安装的临时补丁」是同构的强间接佐证,故在 3 与 5 之间取 4。
可落地性 5 判据全是可一条命令跑出的机器判据,已实测跑通出数字,10 分钟可复现;静态站与推送链路现成,不新增硬件。
变现清晰度 4 可沿用 09-11 定的 500–2000 元/次先例(来源:内部推导),但这是隐性需求——用户不会主动搜「僵尸脚本盘点」,转化难度高于技能包体检,故不给 5。
竞争程度 4 cron 与监控工具只管「有没有崩」,不管「还有没有人要、输出还有没有人读」;僵尸脚本盘点这个角度几乎无人占,且门槛低易被抄,故 4 不给 5。
合规风险 5 纯只读扫描,不删改任何文件(归档用 _archive/ 而非 rm),不涉及任何外部数据与敏感领域。

总分 22 / 25 ✅ 达标发文。

一句话理由:自动化最大的失效模式不是报错,是静默过时——这一条有本机 37 脚本的真实数字、有 HN 325 分帖子的同构佐证、判据可机器化且 10 分钟可复现,是今天唯一一个「证据、方法、样板」三样都齐的方向。

去重说明:与 09-17「备份恢复演练」(管没了能不能回来)、09-18 上午「技能包供应链体检」(管还在但被动了知不知道)同属「自有资产体检」大家族,但三者问的是三个不同的问题,本条问的是第三问「它还在干活吗」——且本条是本轮唯一有 HN 高分外部事件(325 pts)直接加持的方向。

扫码关注公众号，获取更多 OpenClaw 实操技巧：

公众号二维码