基于 GitHub Actions 的情报过滤管线：概念验证与短期测试底稿

工程状态声明：本记录属概念验证（Proof of Concept, PoC）。作为无底层代码基础条件下的 API 拼装实验，该管线仅运行数日完成基础连通性验证后即告中止。当前架构未经过压力测试，缺乏长期运转的数据积淀，直接复用存在确凿的工程失效风险。

快速导航

一、实验目标与范式切换
二、对抗性 Prompt 约束
三、物理组件与拼装架构
四、交叉验证架构（PoC 未实现）
五、运行数据（短期切片）
六、已知缺陷与工程技术债
附录 A：核心配置底稿

一、实验目标与范式切换

1.1 一个普遍而尖锐的困境

在云基础设施、金融监管、半导体供应链这三个高度专业化的领域，每天的生产内容量远超任何个人的阅读能力边界。传统解决方案——RSS 阅读器、AI 摘要工具、邮件简报——本质上都在做同一件事：把 1000 字变成 200 字。但它们从未解决三个致命缺陷：

缺乏立场：AI 摘要默认站在信息发布者的立场，逐点罗列原文观点，事实与宣传混在一起；
缺乏判断：不具备对”这个动作背后到底是谁在获利”的追问能力；
缺乏风险意识：信息只在”发生了什么”层面流转，不触及”这可能带来什么副作用”。

1.2 从”阅读者”到”审计员”的范式切换

核心洞察：信息处理不应该止步于”读懂”，而应该推进到”审过”。

这个想法来自一个冷酷的事实：SEC 的监管文件中从不写”这一法规将增加合规成本”，Cloudflare 的博客也从不说”这个新功能的 adoption 代价很高”。信息是公关过的——这正是职业怀疑论（Professional Skepticism）的用武之地。

我们将 CFA/CPA 审计准则中的核心理念——“以质疑的思维方式和批判性眼光评价审计证据”——从金融审计移植到了信息审计。实验目标不是训练一个更好的摘要引擎，而是在 System Prompt 层面定义一个虚拟审计员的职业立场和工作边界。

二、对抗性 Prompt 约束

常规 LLM 的”摘要生成”动作会无条件继承原文的公关叙事立场。本管线通过以下硬编码约束执行信息清洗：

词汇黑名单：禁止生成 9 个高频公关词（增强、领先、突破、显著等），阻断模型生成公关话术。
动作剥离：事实陈述字段强制约束 80 字以内，仅保留”谁做了什么”的客观动作。
动机与代价提取：必须输出动作背后的利益驱动方与物理副作用、技术债。
信息熵阻断：0-100 评分，设定 10 分阈值。评分不足的条目和纯情绪宣泄内容自动丢弃，永不出现在输出中。

2.1 输出示意

维度	传统 AI 摘要	对抗性输出
事实摘要	”SEC 批准豁免令，预计将增强市场效率和流动性"	"SEC 发布有条件豁免令，允许客户对清算机构国债头寸进行跨保证金操作”
底层逻辑	—	“降低保证金占用成本，刺激国债市场流动性”
风险分析	—	“跨市场风险传导可能加剧系统性风险；清算机构风控压力未披露”

传统 AI 把 SEC 公告定位成”积极的市场进展”；对抗性输出把它拆解为”利益驱动 + 副作用”的组合。信息量相当，但立场完全不同。

三、物理组件与拼装架构

系统采用无服务器（Serverless）架构组合，执行逻辑隔离的单向数据流。

3.1 链路组件池

环节	组件	执行逻辑
调度与计算	GitHub Actions	定时（Cron）触发 Python 脚本，拉取 RSS/HTML 信源
文本推理	DeepSeek-V3 / SiliconFlow API	接收清洗后的纯文本，执行对抗性 Prompt 推理与 JSON 格式化输出
持久化与渲染	Quartz 4 (Node.js)	将输出结果覆写为 MD 文件，生成静态 HTML
边缘分发	Cloudflare Pages	检测目标项目状态，调用 Wrangler 投递至边缘节点

3.2 数据流图

信源层                         推理层                         分发层
┌─────────────┐        ┌─────────────────┐        ┌──────────────────┐
│ RSS 抓取     │ ───→  │ AI 审计          │ ───→  │ GitHub commit    │
│ HTML 抓取    │        │ (对抗性 Prompt)  │        │ Quartz build     │
│ HN API       │        │ 质量过滤 + 评分  │        │ Cloudflare Pages │
└─────────────┘        └─────────────────┘        └──────────────────┘

3.3 连通性修复记录

在组件拼装过程中，触发了以下基础连通性阻断并实施了干预：

问题	修复	工程原则
Git 推送冲突	`git pull --rebase` + `--force-with-lease`	防御性编程
Cloudflare 项目不存在	自检脚本：不存在则自动创建	自愈能力
空提交	`git diff --cached` 预检	幂等性

四、交叉验证架构（PoC 未实现）

这一节描述的是下一阶段应加入的架构，当前 PoC 管线中尚未实现。

4.1 当前架构的缺陷

本管线采用单次 AI 推理模式：一条 Prompt → 一次 API 调用 → 一份输出。这意味着：

缺少第二个视角：没有机制发现第一轮审计的遗漏或误判
无法检测幻觉：当模型为了满足”提取风险”指令而捏造风险时，系统不设防
不可信度量化：单次输出无法估算置信区间

4.2 交叉验证架构（设计）

信源原文
    │
    ├──→ AI-A 审计（当前对抗性 Prompt）
    │       输出A: {fact, logic, risk, score}
    │
    └──→ AI-B 复核（不同 Prompt 结构：侧重"遗漏了什么"）
            输出B: {fact, logic, risk, score}
                 │
                 ▼
         差异比较器
         ├── fact 字段冲突 → 标注"事实分歧" → 人工关注
         ├── AI-B 发现 AI-A 遗漏的风险 → 自动合并
         └── score 差异 > 30 分 → 标记"置信度低"
                 │
                 ▼
         结构化输出（含分歧标注）

角色	Prompt 方向	输出重点
AI-A 审计	”冷酷审计员，找风险、拆利益”	批判性输出
AI-B 复核	”你是不苟同的同行审稿人”	补漏、质疑

4.3 为什么 PoC 阶段没有实现

这是一个典型的功能与成本取舍：双倍推理意味着双倍 API 调用，在当时每日 9 篇 × 3 频道 = 27 次调用的规模下，成本仍在可接受范围（约 ¥0.006/日），但交叉验证的 Prompt 工程和差异比较器都需要额外开发。PoC 阶段的核心目标是验证”对抗性提取是否可行”，交叉验证属于 v2.0 路线图。

五、运行数据（短期切片）

以下数据仅代表测试期内（数日）的单日截面状态，不具备长期运营成本的参考效力：

指标	测试期切片数据
信源轮询量	20-40 篇/日
过滤后输出量	6-9 篇/日
Token 消耗	~20,000 Input / ~4,000 Output（单日）
日均并发时间	< 3 分钟（GitHub Actions）
日 API 费用	< ¥0.002（DeepSeek-V3）

六、已知缺陷与工程技术债

基于测试终止前的底稿，该架构存在以下结构性缺陷。若投入长期运行，必将导致系统失效或数据污染：

6.1 存储冗余失控（Git Bloat）

系统采用本地文件每日覆写与全量 Git Commit 策略。缺乏针对 .git 目录的历史记录清理机制（如 Shallow Clone），长期运行将导致仓库体积线性膨胀，最终触碰 GitHub 存储硬限额。

6.2 单点故障未熔断（网络层）

数据抓取脚本对外部信源的请求缺乏标准超时配置与指数退避重试机制。单源网络波动极易引发单进程阻塞，导致当日整个 Actions 实例执行失败。

6.3 推理格式失稳与幻觉补偿（逻辑层）

JSON 损坏：仅依赖 Prompt 声明要求返回 JSON，未在代码层构建正则修复或拦截机制。
虚假风险捏造：当输入文本信息密度极低时，模型存在为了满足”提取风险”指令而编造的风险。当前管线缺乏交叉验证来识别此类幻觉（参见第四章设计）。

附录 A：核心配置底稿

A.1 对抗性 System Prompt

你是一名冷酷的信息审计员，不是摘要助手。

强制规则：
1. 正文全部使用简体中文输出。
2. 禁止使用任何正面修饰词（增强、领先、卓越、有效、创新、突破、引领、显著、高效）。
3. 事实摘要：控制在80字以内，只准讲"发生了什么动作"。
4. 底层逻辑：必须挖掘该动作背后的"利益驱动"或"补救性质"。
5. 风险分析：严禁写好处！必须寻找副作用、潜在成本、技术债。
   如果没发现具体风险，写"由于数据披露不足，存在无法评估的合规暗箱风险"。
6. 如果内容没有实质性数据或是纯情绪宣泄，返回 null。

返回格式（JSON）：
{
  "title_cn": "中文标题翻译",
  "fact": "事实摘要（80字以内，只讲动作）",
  "logic": "底层逻辑（利益驱动或补救性质）",
  "risk": "风险分析（副作用/成本/技术债/审计盲点）",
  "score": <整数0-100>
}

A.2 数据流概要

fetch_all()
  ├── fetch_rss()      → 6 个 RSS 源（feedparser）
  ├── fetch_html()     → 1 个 HTML 源（BeautifulSoup）
  ├── fetch_hackernews() → HN Top 15（Firebase API）
  └── 分类入 channel

run_ai_audit()
  ├── 构造审计 Prompt
  ├── POST DeepSeek-V3 /chat/completions
  ├── 正则提取 JSON
  ├── 过滤 score < 10
  └── 返回结构化审计条目

main()
  ├── 每 channel 取 Top 3
  ├── 清理旧文件 → 写入新报告
  └── 输出审计摘要统计

概念验证阶段完成后，该管线未投入长期运营。源码归档于 github.com/alericzhu/daily-audit-pipeline。

DacAI 实验室

探索