article-batch

十篇文章批处理

这个技能负责吞吐，不降低 hotspot-article 的证据和质量门。十篇文章使用十个独立工作区，任何一篇失败都不能污染其他文章。

目标与边界

• 默认 count=10，允许 2–10；
• 默认组合：event 30% / demand 50% / evergreen 20%；
• 每篇都要有完整业务场景和七段技术到业务桥；
• 每篇先过题目重量门；小版本、小功能和局部技术点直接降级，不占十篇精选名额；
• 每篇独立维护来源、实测、事实核验和质量报告；
• 不为了凑十篇复制角度、来源或段落；
• 不自动发布。当天未通过的文章保留草稿和失败原因。

Step 1：检查开源适配器

python3 -m prax.article_integrations probe --format json

按可用性使用：

1. TrendRadar：聚合公开热榜与 RSS，读取 TRENDRADAR_OUTPUT；
2. AutoCLI：抓取需要 Chrome 登录态的平台；
3. Crawl4AI：把公开文章转成研究用 Markdown；缺失时使用遵守 robots.txt 的 HTTP 回退；
4. GPT Researcher：并行生成研究线索；需要本地包、模型和检索凭据；
5. STORM：读取 STORM_OUTPUT 中已有报告，补充视角和追问。

外部研究报告不是事实来源。必须回到其中列出的原始 URL。

Step 2：建立至少 12 个候选

十篇批次至少准备 12 个候选，避免一个题失败后整批停住。候选写入：

.prax/vault/article-batches/<DATE>/topic-candidates.json

候选必须符合 hotspot-article 的 business_case 和 business_bridge schema。只复述发布会或产品功能的题目不得进入批次。

Step 3：创建十个隔离工作区

python3 -m prax.article_batch \
  ".prax/vault/article-batches/<DATE>/topic-candidates.json" \
  --count 10 \
  --date "<DATE>" \
  --out-root ".prax/vault/article-batches/<DATE>/run"

生成：

run/
├── batch-manifest.json
├── calibration-gate.json
├── 01-<topic>/
│   ├── brief.md
│   ├── business-bridge.json
│   ├── research-plan.json
│   └── status.json
└── 10-<topic>/...

batch-manifest.json 没有 complete: true 时，不开始写作；先补候选。重复运行必须显式使用 --resume，避免误覆盖批次状态。

Step 4：先用一篇做校准门

批次创建后只推进 calibration-pilot，其他目录保持 waiting-for-calibration。首篇必须完整走到来源、实测、事实审校、去 AI 腔编辑和质量门，再把实际暴露的问题写入 calibration-gate.json：

• 机器分在哪些地方虚高或误判；
• 哪些来源只进研究池、没有真正进入正文；
• 计划验证与实际运行之间还差什么；
• 哪些段落虽然过门，读起来仍像模板；
• 题目是否足以改变一个真实业务决策，还是被篇幅硬撑成“大文章”；
• 已经修改了哪些 prompt、规则或 hard gate。

只有首篇 hard gates 通过、编辑七项均至少 4/5、证据明确写出局限，并且上述改动已经落地，才把 status 改为 released、remaining_slots_released 改为 true。不能先批量生成十篇再统一返工。

Step 5：校准后按两条并发泳道推进

不要十篇同时抢浏览器和检索限额。最多同时研究两篇：

1. 泳道 A 研究第 1 篇时，泳道 B 研究第 2 篇；
2. A 进入写作后，再把第 3 篇放入研究；
3. 每完成一个阶段就更新该目录的 status.json；
4. 单篇失败只标记 blocked，继续下一篇。

建议状态：

planned → researching → outlined → drafting → fact-checking → quality-gate → ready