channinglua 热点深度文章 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：先补业务场景和技术桥，再算机会分
每个候选必须回答：
| 字段 | 要回答的问题 |
|---|---|
| actor | 谁正在遇到问题 |
| job_to_be_done | 他要完成什么任务 |
| trigger | 为什么现在必须处理 |
| current_workaround | 当前怎么凑合解决 |
| decision | 读完文章要做什么选择 |
| cost_of_inaction | 不处理有什么损失 |
| evidence | 客户 brief、工单、搜索、评论、Issue 等需求证据 |
缺少两个以上字段的候选不能进入精选长文。不要编造客户、预算、工单或业务结果。
再建立一条不能跳步的技术到业务链：
来源信号 → 技术变化 → 受影响流程 → 业务决策 → 验证方法 → 成功指标 → 不适用条件
| 字段 | 合格标准 |
|---|---|
| source_signal | 写清事件、客户问题或长期信号，并保留原始出处 |
| technical_delta | 说明能力、约束或架构相对之前具体变了什么，不写“效率提升”一类空话 |
| affected_workflow | 落到售前、研发、客服、运营、招聘、审计等具体流程节点 |
| business_decision | 决策人读完后要采用、延期、自建、采购、替换或停止什么 |
| validation_method | 给出可重复的对照、试点、回放、压测或失败注入方法 |
| success_metric | 使用业务方约定的质量、时延、成本、风险或人效指标 |
| no_fit_conditions | 明确哪些组织、数据或流程条件下不值得采用 |
七项必须全部存在。事件再热，只要还停留在产品功能介绍、发布会复述或技术名词解释，就把 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 条。实测路线不能用堆来源代替真实操作；分析路线也不能用一次配置检查代替技术纵深。优先顺序：
- 官方公告、产品文档、标准、代码仓库；
- 原始论文、数据集、基准报告；
- 有署名和编辑流程的专业媒体；
- 专家分析与社区讨论，仅用于观点或线索。
同一新闻的转载不算独立来源。每条来源必须读到支持主张的具体段落；只看搜索摘要不计入研究数。
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]。精确数字、日期、性能结论和直接归因必须紧邻引用。无法核验的精确数字应删除或明确标成估计。
Step 4：多视角提纲
先读 demand-brief.md 和 business-bridge.json。开头 300 字内要让读者看到具体角色、触发场景和待做决策；正文至少给出一张决策表、一个真实工作流或案例，以及不适用条件。时事只占背景所需篇幅，主线按“技术变化如何影响流程—有哪些选择—怎样验证”展开。
在 outline.md 中让四个角色分别提出问题，再删去与核心决策无关的问题，合并为一条叙事主线：
- 工程师：原理、实现路径、性能和复现条件；
- 产品负责人：用户场景、收益、采用成本；
- 安全/合规审稿人：攻击面、隐私、失败条件；
- 怀疑者：反例、替代解释、营销话术。
所有路线的 H2 控制在 5–9 个。相邻内容能在同一节回答就不拆节，但每个 H2 必须新增事实、机制、案例、产物或决策中的至少一项。
selected-analysis：现场 → 完整事实链 → 被忽略的技术细节 → 机制解释 → 企业影响 → 可执行方案 → 边界；selected-framework：真实问题 → 分类轴 → 分类矩阵 → 逐类决策 → 跨类场景 → 反例与边界；selected-hands-on：为什么测试 → 真实输入 → 运行过程 → 失败与修复 → 最终产物 → 瑕疵 → 适用人群。
Step 5：必须做一次真实验证
验证必须对应 business-bridge.json 中的 validation_method 和 success_metric，不能测了一个方便运行但与业务决策无关的指标。selected-hands-on 至少完成两个实际运行或案例；其他路线至少一次。验证可以是：
- 运行开源项目的最小复现；
- 调用公开 API 并保存响应；
- 对公开数据做可重复的计算；
- 对多个官方版本/参数做结构化对照。
不要编造终端结果。无法运行时，把原因写入 evidence.json 并停止在草稿状态，不能生成 publish-ready.md。
evidence.json 格式：
{
"runs": [
{
"name": "最小复现",
"method": "完整、可重复的方法",
"command": "实际执行的命令（若适用）",
"result": "观察到的结果和误差",
"limitations": "这次验证没有覆盖什么，结论不能外推到哪里",
"artifact": "evidence/run-01.txt",
"status": "passed"
}
]
}
Step 6：写初稿
draft.md 必须满足：
- 使用已经写入
brief.md的路线和对应篇幅，不靠长引用、代码和参考列表注水； - 5–9 个 H2，且每节有明确的信息增量；
- 开头让读者看见一个现场、冲突、真实测试动机或生产问题，不写背景综述；
- 只保留一个中心判断，用完整事实链、分类框架或真实项目把它撑住；
selected-analysis和selected-framework至少两张有效图表；selected-hands-on至少四张真实截图、对照、输出或图表；- 文中必须看得见作者做过什么：读出的原文细节、真实输入输出、失败修复、自己建立的模型或明确取舍；
- 明确区分事实、观察、推断和作者判断；
- 逐段使用
[Sxx]引用，不使用“据报道”代替来源； - 禁止“颠覆性、史诗级、秒杀、彻底改变”等无证据宣传语。
去 AI 腔编辑
初稿完成后单独做一轮“人味编辑”，不增加新事实，只改表达：
- 删除每节开头的套话和末尾重复总结，段落直接从事实、场景或判断进入；
- 不机械统计某一种句式；重点删除没有作者观察、对象和后果的模板段落；
- 不为凑排比强行写三点、四层、五个关键；只有真实顺序或互斥分类才编号；
- 标题使用自然判断或读者问题，不把所有标题写成“名词：解释”的同一格式；
- 长短句和段落长度要有变化，连续三个段落不能使用相同句式开头；
- 把“赋能、闭环、底层逻辑、生态、全面升级”等抽象词换成具体的人、动作、对象和后果；
- 允许作者做有证据的取舍和判断，不写四平八稳的“两边都有道理”；
- 大声读一遍；删掉读起来像演讲提纲、咨询报告或产品发布稿的句子。
Step 7：三次独立审校
审校时不要沿用写作者的自我评价。
7.1 事实审校
抽取至少 8 个关键主张写入 fact-check.json：
{
"claims": [
{
"id": "C01",
"claim": "正文中的可核验主张",
"source_ids": ["S01", "S03"],
"status": "verified",
"included_in_article": true,
"caveat": ""
}
]
}
verified/supported/qualified 为可接受状态。pending/unverified 主张若仍在正文，质量门失败。同步生成便于人工阅读的 fact-check.md。
7.2 技术审校
检查命令、版本、参数、因果关系、基准条件和术语。把“相关”误写成“因果”、把单次结果写成普遍结论，均需退回修改。
7.3 编辑审校
在 editorial-review.md 对 7 项各打 0–5 分并给证据：信息增量、推理深度、结构、清晰度、原创综合、读者价值、作者感与自然度。任何一项低于 4，修改一次；最多两轮，仍不达标就保留草稿并报告原因。
Step 8：运行硬质量门
在安装 Prax 的环境中运行：
python3 -m prax.content_quality \
"$ROOT/draft.md" \
--business-bridge "$ROOT/business-bridge.json" \
--sources "$ROOT/source-index.json" \
--fact-check "$ROOT/fact-check.json" \
--evidence "$ROOT/evidence.json" \
--profile "<selected-analysis|selected-framework|selected-hands-on>" \
--json-out "$ROOT/quality-report.json"
命令中的 profile 必须与 brief.md 一致。selected-sharp 通过也不能生成腾讯云精选批次的 publish-ready.md。
质量门只按正文实际引用的来源计算域名多样性；只放进研究池、没有进入正文的来源不能抬分。每次证据运行还必须写明 limitations，缺少外推边界时按未完成处理。
只有命令退出码为 0、所有 hard gates 通过、机器分至少 80/100，并且编辑审校七项都至少 4/5，才能用 Read + Write 生成 publish-ready.md。最多修订两轮，不得通过重复段落或虚构来源冲分。
Step 9：交付
向用户报告：
- 选题、热点分及选择理由；
- 技术到业务链、内容路由以及仍缺的桥接字段；
- 研究来源数、正文实际引用数、第一方引用数；
- 实测方法和证据路径；
- 机器可审计分、编辑七项分；
publish-ready.md或未通过时的draft.md路径；- 仍然存在的局限。
安全边界
- 不自动发布到网站、公众号或社交平台；
- 不绕过登录、付费墙、robots 或站点限制；
- 不把社区评论当作事实来源；
- 不伪造浏览、采访、运行结果或引用；
- 不为了达到篇幅门槛重复表达；
- 高风险领域必须有人类主编确认后才能进入发布态。