大家好，我是测试员周周，这是【踩坑】系列的第一篇：每天推送的 AI 资讯，全是假的！我扒了 OpenClaw 的底，后续会把我真实踩坑经历陆续分享

导读

：每天定时推送的技术资讯，连续几天内容一模一样？我深入排查，发现 OpenClaw 生成的脚本全是硬编码的假数据。本文完整记录从发现问题到彻底解决的全过程。

---

📖 开篇：一个 suspicious 的发现

事情要从几天前说起。

我每天早上都会收到 Hermes 定时推送的技术资讯，从 6:30 到 9:10，一共 12 个时段，涵盖 7 种不同类型的内容：

• 类型 A：技术趋势预警

• 类型 B：完整资讯汇总

• 类型 C：行业赋能专题

• 类型 D：市场洞察分析

• 类型 E：海外动态追踪

• 类型 F：职业发展机会

• 类型 G：大厂工具速递

看起来非常完善，对吧？

直到有一天，我突然发现：这已经是连续第 3 天收到一模一样的内容了。

TEXT复制

❌ 第 1 天：项目 X Stars 133,440
❌ 第 2 天：项目 X Stars 133,440  （没变？）
❌ 第 3 天：项目 X Stars 133,440  （还是没变？）

作为一个测试老兵，我的职业敏感度告诉我：这不对劲。

GitHub 的 Stars 数怎么可能 3 天一动不动？而且每天推送的论文标题也完全一样。

只有一个可能：这些数据是假的。

---

🔍 第一步：定位脚本位置

我首先找到了这些定时任务的脚本位置：

BASH复制

/home/zhou/morning_ai/
├── 630_type_a.sh
├── 700_type_b.sh
├── 715_type_c.sh
├── 725_type_d.sh
├── 740_type_e.sh
├── 800_type_f.sh
├── 810_type_g.sh
├── 815_type_c_2.sh
├── 825_type_d_2.sh
├── 840_type_e_2.sh
├── 900_type_f_2.sh
└── 910_type_g_2.sh

一共 12 个脚本，对应 12 个时段、7 种不同类型的推送（部分类型有早晚两个时段）。

---

🔬 第二步：分析脚本内容

我让Hermes打开了其中一个脚本（8点25的），想看看它是怎么抓取数据的。

然后我震惊了。

BASH复制

#!/bin/bash
<h1>7:40 - 类型 E 内容</h1>
<h1>Auto-generated by OpenClaw for morning tech news automation</h1>

export PATH="/home/zhou/.npm-global/bin:$PATH"

<h1>Output the 7:40 content directly to stdout</h1>
cat << 'EOF'
🕐 <strong>7:40 - 类型 E 内容</strong>

<h2>🔥 热门技术追踪</h2>

<h3><strong>项目 A</strong> ⭐ NEW!</h3>
<ul>
<li><strong>简介</strong>: 新兴开源框架</li>
<li><strong>热度</strong>: GitHub Trending 前列，社区讨论活跃</li>
<li><strong>特点</strong>: 技术创新明显</li>
</ul>
<h3><strong>项目 B</strong> ⭐ HOT!</h3>
<ul>
<li><strong>简介</strong>: 多智能体框架</li>
<li><strong>热度</strong>: GitHub Star 快速增长</li>
</ul>
...（省略）

EOF

看到了吗？整个脚本就是用 cat << 'EOF' 输出的硬编码文本！

我立刻检查了其他 11 个脚本，结果让人大跌眼镜：

脚本	内容来源	是否有真实 API 调用
630_type_a.sh	硬编码	❌ 无
700_type_b.sh	硬编码	❌ 无
715_type_c.sh	硬编码	❌ 无
725_type_d.sh	硬编码	❌ 无
740_type_e.sh	硬编码	❌ 无
800_type_f.sh	硬编码	❌ 无
810_type_g.sh	硬编码	❌ 无
815_type_c_2.sh	硬编码	❌ 无
825_type_d_2.sh	硬编码	❌ 无
840_type_e_2.sh	硬编码	❌ 无
900_type_f_2.sh	硬编码	❌ 无
910_type_g_2.sh	硬编码	❌ 无

12 个脚本，全部是假的。

---

📊 第三步：验证假数据

为了确认我的判断，我让Hermes写了一个简单的 Python 脚本来验证：

import subprocess

<h1>检查所有脚本是否包含真实 API 调用</h1>
scripts = [
    "/home/zhou/morning_ai/700_type_b.sh",
    "/home/zhou/morning_ai/740_type_e.sh",
    # ... 其他脚本
]

 

for script_path in scripts:
    with open(script_path, 'r') as f:
        content = f.read()

    has_curl = 'curl' in content
    has_wget = 'wget' in content
    has_heredoc = "cat << 'EOF'" in content

    print(f"{script_path}:")
    print(f"  - 硬编码内容：{'✅ 是' if has_heredoc else '❌ 否'}")
    print(f"  - curl 请求：{'✅ 是' if has_curl else '❌ 否'}")

运行结果：

TEXT复制

7am_full_ai_news.sh:
  - 硬编码内容：✅ 是
  - curl 请求：❌ 否

740_overseas_trending.sh:
  - 硬编码内容：✅ 是
  - curl 请求：❌ 否

 

...（所有脚本都是同样结果）

实锤了。这些脚本没有任何网络请求，全是写死的假内容。

---

🛠️ 第四步：重写真实脚本

既然发现了问题，那就解决它。

我的目标是：让每个脚本都真实抓取实时数据。

4.1 创建公共数据抓取模块

当然这一套全让Hermes干完了。

4.2 批量重写所有脚本

时段	新脚本	数据源
6:30	630_type_a.py	GitHub API
7:00	700_type_b.py	ArXiv API + GitHub API
7:15	715_type_c.py	GitHub API
7:25	725_type_d.py	Hacker News + GitHub Issues
7:40	740_type_e.py	GitHub API
8:00	800_type_f.py	GitHub API + Hacker News
8:10	810_type_g.py	GitHub API
8:15	815_type_c_2.py	GitHub API
8:25	825_type_d_2.py	Hacker News
8:40	840_type_e_2.py	GitHub API
9:00	900_type_f_2.py	GitHub API
9:10	910_type_g_2.py	GitHub API

---

🧪 第五步：测试验证

重写完成后，我立即测试了所有脚本：

这次的数据是真实的了！ 

---

📤 第六步：更新定时任务

脚本重写完成后，需要更新 Hermes 的 cronjob 配置，让它们指向新的 Python 脚本。

我更新了所有 12 个定时任务：

PYTHON复制

<h1>示例：更新 7:40 的 cronjob</h1>
cronjob(
    action='update',
    job_id='b20c2bd290a2',
    prompt='执行 Python 脚本并原封不动转发完整输出到飞书。\n\n'
           '脚本路径：/home/zhou/morning_ai/740_type_e.py\n\n'
           '关键要求：\n'
           '1. 执行 python3 /home/zhou/morning_ai/740_type_e.py\n'
           '2. 禁止总结/截断 —— 完整展示脚本的全部 stdout 输出\n'
           '3. 脚本会真实抓取 GitHub 实时数据\n\n'
           '交付目标：origin'
)

---

🎯 最终测试：全部推送

最后，我执行了一次完整测试，把 12 个脚本全部运行并推送到飞书群：

PYTHON复制

scripts = [
    ("6:30", "/home/zhou/morning_ai/630_type_a.py"),
    ("7:00", "/home/zhou/morning_ai/700_type_b.py"),
    # ... 其他 10 个脚本
]

for time_slot, script_path in scripts:
    result = subprocess.run(['python3', script_path], ...)
    send_to_feishu(result.stdout)

推送结果：

TEXT复制

6:30:  ✅ 推送成功
7:00:  ✅ 推送成功
7:15:  ✅ 推送成功
7:25:  ✅ 推送成功
7:40:  ✅ 推送成功
8:00:  ✅ 推送成功
8:10:  ✅ 推送成功
8:15:  ✅ 推送成功
8:25:  ✅ 推送成功
8:40:  ✅ 推送成功
9:00:  ✅ 推送成功
9:10:  ✅ 推送成功

总计：12/12 推送成功

---

📈 改造前后对比

项目	改造前	改造后
数据来源	❌ 硬编码假数据	✅ 实时 API 抓取
GitHub Stars	❌ 编造的数字	✅ 真实 Stars 数
论文标题	❌ 编造的标题	✅ ArXiv 最新论文
更新时间	❌ 固定不变	✅ 每次执行都更新
网络请求	❌ 0 个	✅ 多次 API 调用
脚本语言	Bash	Python

---

💡 经验教训

1. 不要盲目相信自动化工具

OpenClaw 生成的脚本看起来非常完善，但实际上全是假数据。自动化可以提高效率，但不能替代人工验证。

2. 测试人员的职业敏感度很重要

如果不是我注意到"连续 3 天内容一样"，这个假资讯系统可能还会继续运行很久。保持怀疑精神，是测试人员的核心素养。

3. 数据真实性是底线

对于资讯类应用，数据的真实性是生命线。宁可少推送，也不能推送假数据。

4. 重构要彻底

发现问题后，我没有选择"打补丁"，而是彻底重写所有脚本。短期看工作量大了，但长期看避免了后续更多问题。

---

📢 下篇预告

下一篇，我会写《【踩坑系列2】删快照前必看！VirtualBox 报错 E_FAIL 的终极解决方案》，Hermes系列和评测系列明天会持续更新，这俩系列都是暂定10篇+，目前Hermes完成了6篇，评测系列完成了1篇； 

---

喜欢这篇文章吗？欢迎点赞、转发、关注！

你的支持是我持续创作的动力 💪

作者：测试员周周testzhouzhou，14 年测试经验，专注 AI+ 测试实战