Hotspot Article

热点深度文章 Pipeline

这不是“一次提示词写长文”，而是一条有证据链和退出门槛的编辑流水线：

三轨机会池 → 需求优先评分 → 技术到业务桥接 → 多源研究 → 多视角提纲 → 实测 → 成稿 → 事实/技术/文风审校 → 质量门

对标腾讯云“内容精选”时，先读 docs/recipes/tencent-selected-benchmark.md，再按内容类型选质量档，不能用一个固定篇幅处理所有文章：

• selected-analysis：重大事件或行业变化，6,000–12,000 有效字符；
• selected-framework：架构、组织或决策框架，5,500–11,000 有效字符；
• selected-hands-on：产品实测或项目实战，4,500–9,000 有效字符。

三类都控制在 5–9 个 H2。重量来自攻击链、分类框架、真实输入输出、失败修复、架构图和明确取舍，不来自拆出更多章节。selected-sharp 只用于技术短稿，不计入腾讯云精选批次；selected 保留为兼容旧稿。

机器分只衡量可审计的下限，不能把 8.6/10 直接解释为审美或洞察得分。最终发布仍需人工主编确认。

触发条件

• “追一下今天的 AI 热点，写成深度文章”
• “从客户项目和业务难题里找一个值得写的选题”
• “对标精选文章，做一篇 8–9 分的长文”
• “运行 hotspot-article”

如果用户没有给主题，同时扫描近期大事件、真实需求和常青决策三条线。默认周内容组合为：时事 30%、需求/解决方案 50%、常青框架 20%。选题先补齐业务场景，再按当前组合缺口选择；热度很高但说不清“谁在什么情况下要做什么决定”的内容，只进简报，不写精选文章。

把选题与评分写入 brief.md，不中断执行等待确认；如果涉及政治、医疗、金融、法律或未成年人等高风险主题，则停在选题报告，等待用户确认。

文件约定

ROOT=.prax/vault/hotspot-articles/<YYYY-MM-DD>/<topic-slug>

$ROOT/
├── brief.md
├── topic-candidates.json
├── opportunity-report.json
├── business-bridge.json
├── demand-brief.md
├── research-notes.md
├── source-index.json
├── outline.md
├── evidence.json
├── evidence/
├── draft.md
├── fact-check.json
├── fact-check.md
├── editorial-review.md
├── quality-report.json
└── publish-ready.md       # 只有全部门槛通过后才创建

新文件使用 Write；修改已有文件使用 Edit。保留中间稿和失败报告，不覆盖研究证据。

Step 0：读取项目配置

可选配置 .prax/article.yaml：

audience: 中文开发者与技术决策者
topics: [AI Agent, LLM, RAG, 开源工具]
exclude: [纯融资传闻, 无原始出处的爆料]
lookback_hours: 48
candidate_limit: 20
tone: 克制、清晰、证据优先
target_mix:
  event: 0.30
  demand: 0.50
  evergreen: 0.20

没有配置就使用以上默认值。当前日期和时区必须写入 brief.md。

Step 1：构建三轨机会池

每个候选标注一个 track：

A. 时事线 event

• 当天 .prax/vault/ai-news-hub/<DATE>/；
• 先运行 python3 -m prax.article_integrations probe，把可用和缺失的适配器写入 brief.md；
• TRENDRADAR_OUTPUT 存在时，用 python3 -m prax.article_integrations ingest-trendradar 归一化其 Markdown、JSON 或 SQLite 输出；
• AutoCLI 可用时，通过 collect-autocli 抓登录态平台；扩展或登录态失败只跳过该源；
• 官方博客、GitHub Trending、Hacker News、行业媒体；
• 正文优先使用 Crawl4AI；未安装时适配器会遵守 robots.txt 并退回公开 HTTP 抓取。

B. 需求线 demand

• 客户项目 brief、售前/客服问题和交付复盘（先脱敏）；
• 搜索词、站内搜索无结果、相关问题与持续出现的长尾查询；
• GitHub Issues/Discussions、技术社区中反复出现的“怎么做/怎么选/为什么失败”；
• 招聘 JD、岗位能力变化、培训与管理难题；
• 产品使用数据、试用流失、工单和销售异议；
• 文章评论中请求方案、补充案例或表达自身痛点的内容。

C. 常青线 evergreen

• 架构取舍、成本模型、迁移指南、排障手册；
• 每季度仍会遇到的采购、合规、团队协作和人才培养决策；
• 旧文章中持续带来搜索、收藏、咨询和内部转发的问题。

每个候选保存标题、来源、时间、平台指标和抓取时间。平台不可比的点赞、排名不得直接相加。单张截图或发布一小时内的高评论率只能触发进一步研究，不能直接证明“热门”或“真实需求”；尽量保存 1h / 6h / 24h 快照，并把评论分成方案询问、真实案例、反驳讨论和普通互动。

Step 2：先补业务场景和技术桥，再算机会分

每个候选必须回答：

缺少两个以上字段的候选不能进入精选长文。不要编造客户、预算、工单或业务结果。

再建立一条不能跳步的技术到业务链：

来源信号 → 技术变化 → 受影响流程 → 业务决策 → 验证方法 → 成功指标 → 不适用条件

七项必须全部存在。事件再热，只要还停留在产品功能介绍、发布会复述或技术名词解释，就把 editorial_route 设为 daily-digest，不能进入精选长文。需求或常青题缺桥时设为 research-brief，先补现场证据。

再过一道“题目重量门”。至少满足以下三项中的两项：

• 会改变预算、权限、架构、岗位或跨团队流程中的一项；
• 能用一个真实或明确标注的参考业务流程，从触发走到验收和失败处置；
• 决策错误会带来可说明的交付、成本、安全或组织后果。

单个协议字段、局部版本变化、某个仓库去掉一层组件、厂商小功能更新，默认只做技术短帖。除非能证明它已经造成大范围迁移、真实客户损失或重大的采购决策，否则不得靠扩写升格为精选文章。

撞题门

在目标社区检查最近 30 天的精选内容。为每个候选记录：

• 已有文章是否覆盖同一事件或需求；
• 中心结论和业务落点是否相同；
• 本文新增的是原创运行证据、未被注意的原始材料、真实客户现场，还是只换了一种说法。

同题已有更完整文章时，候选必须降级或换题。不能因为已经做完研究就继续发布。

把候选写入 topic-candidates.json，信号均按 0–5 分：

{
  "portfolio_counts": {"event": 3, "demand": 4, "evergreen": 1},
  "target_mix": {"event": 0.3, "demand": 0.5, "evergreen": 0.2},
  "candidates": [
    {
      "id": "ai-search-build-or-buy",
      "title": "AI 联网搜索应该自建还是采购",
      "track": "demand",
      "signals": {
        "problem_frequency": 4,
        "decision_urgency": 5,
        "scenario_specificity": 5,
        "evidence_strength": 4,
        "audience_fit": 5,
        "attention_velocity": 3,
        "cross_source": 3,
        "depth": 5,
        "content_gap": 4,
        "risk": 1,
        "saturation": 3
      },
      "business_case": {
        "actor": "正在做企业搜索的技术负责人",
        "job_to_be_done": "给客户确定可交付的联网搜索方案",
        "trigger": "项目进入技术选型",
        "current_workaround": "逐个对比搜索 API 和开源框架",
        "decision": "自建、采购或混合",
        "cost_of_inaction": "错过交付期或持续产生错误答案",
        "evidence": ["脱敏客户 brief", "社区重复问题"]
      },
      "business_bridge": {
        "source_signal": "客户项目进入 AI 联网搜索选型",
        "technical_delta": "实时检索增加了新鲜度、引用、延迟和成本约束",
        "affected_workflow": "售前调研、方案架构、上线验收和质量回归",
        "business_decision": "采购搜索 API、开源自建或采用混合架构",
        "validation_method": "用固定查询集比较覆盖率、引用正确性、延迟和成本",
        "success_metric": "达到客户约定的质量、时延和预算阈值",
        "no_fit_conditions": "固定语料且不需要实时信息时不引入联网检索"
      }
    }
  ]
}

运行确定性评分器：

python3 -m prax.topic_opportunity \
  "$ROOT/topic-candidates.json" \
  --json-out "$ROOT/opportunity-report.json" \
  --bridge-out "$ROOT/business-bridge.json"

机会分由 真实需求 45%、注意力 20%、编辑价值 35% 组成，再扣传闻风险和内容饱和度。候选还必须满足：总分至少 65、证据强度至少 3、风险不高于 2、业务场景完整度至少 0.75、技术到业务桥完整度为 1.00。

评分器优先补齐周内容组合缺口。没有历史时先从 demand 线选择；需求线没有合格项才回退到其他轨道。评分结果同时给出 longform、daily-digest、research-brief 或 hold 路由。把入选主题扩写为 demand-brief.md，并让评分器生成 business-bridge.json；后者只复制候选中已经写明的链路，不替作者补造业务事实。纯新闻只能解释“发生了什么”时，进入日报而不是精选长文。

Step 3：研究，不先写正文

先验证需求本身。demand 轨道至少要有两类独立信号，例如“脱敏客户 brief + 重复搜索问题”或“工单 + GitHub Issues”；早期互动数字只能算其中半类。无法补足时，把文章降级为探索稿，不创建 publish-ready.md。

再逐段验证 business-bridge.json：

• source_signal 用原始材料确认，不拿转载标题代替；
• technical_delta 用文档、代码、论文或可复现结果说明“变了什么”；
• affected_workflow 用客户流程、工单、访谈或公开案例确认影响位置；
• business_decision 至少比较两个真实可选方案，不能预设产品必买；
• validation_method 和 success_metric 必须能在 Step 5 实际执行或观测；
• no_fit_conditions 要保留，即使它会缩小文章适用范围。

可选运行 GPT Researcher：

python3 -m prax.article_integrations research \
  "<主题 + 业务决策 + 六个研究问题>" \
  --out "$ROOT/research-leads.md"

它的输出只算研究线索。每个 URL 仍要单独读取并进入 source-index.json，不能把聚合报告自身拆成多个独立来源。STORM 已有输出可通过 STORM_OUTPUT 作为提纲和追问参考导入，仍不得跳过本文的来源、实测和事实门。

来源数量按路线确定：selected-analysis 研究至少 12 条，selected-framework 至少 8 条，selected-hands-on 至少 4 条。实测路线不能用堆来源代替真实操作；分析路线也不能用一次配置检查代替技术纵深。优先顺序：

1. 官方公告、产品文档、标准、代码仓库；
2. 原始论文、数据集、基准报告；
3. 有署名和编辑流程的专业媒体；
4. 专家分析与社区讨论，仅用于观点或线索。

同一新闻的转载不算独立来源。每条来源必须读到支持主张的具体段落；只看搜索摘要不计入研究数。

source-index.json 格式：

{
  "sources": [
    {
      "id": "S01",
      "title": "来源标题",
      "url": "https://example.com/original",
      "source_type": "official",
      "published_at": "2026-07-29",
      "accessed_at": "2026-07-29T16:00:00+08:00",
      "supports": ["关键主张 A"],
      "notes": "原文证据的准确释义"
    }
  ]
}

正文引用统一写作 [S01]。精确数字、日期、性能结论和直接归因必须紧邻引用。无法核验的精确数字应删除或明确标成估计。