Horizon 科技新闻画像（tech-news）评分体系全解：从评估目标到 AI 分析管线的落地实现-平芜编程栈

人工智能
AI 应用
MCP 服务
网页爬虫

【免费下载链接】Horizon

📡 Your own AI-powered news radar. Generates daily briefings in English & Chinese. | 用 AI 构建你专属的新闻雷达

项目地址：https://gitcode.com/gh_mirrors/horizon39/Horizon

Horizon 是一个用 AI 构建的"新闻雷达"项目，它把抓取到的内容按画像（profile）路由、评分、筛选并最终生成为中英文日报。本文以 profiles/tech-news/analysis.md 为骨架，完整拆解内置tech-news（科技新闻）画像的评估目标、0–10 分评分标准、评估要求与标签规则，并结合仓库源码说明它在分析管线、配置阈值与下游内容增强中的实际作用。读完本文，你将掌握该画像的评分语义、如何读懂一条科技新闻为什么被打 8 分或 3 分，以及如何在data/config.example.json中为它配置过滤阈值并理解输出契约。

一、tech-news 画像在 Horizon 管线中的位置

在 Horizon 中，每个抓取到的内容条目（ContentItem）都会先被解析出来源类型（GitHub、Hacker News、RSS、Reddit、Twitter、GDELT 等，见 src/models.py），然后经历一条"分类 → 分析 → 过滤 → 选择 → 增强 → 渲染"的处理链路：

画像解析（Profile resolution）：根据来源配置中的显式profile字段，或由 AI 匹配match.md提示词，为条目选定一个画像。
内容准备：按画像的content.analysis_max_chars与content.sampling截取正文。
画像分析：用该画像的analysis.md提示词评估条目，返回 0–10 分、理由、一句话摘要与标签。
校验与重试：JSON 输出契约校验失败时自动修复。
画像过滤：若配置了threshold，低于阈值的条目被丢弃。
日报选择：画像内主题去重、可选类目配额与总数上限，决定哪些条目进入增强阶段。

上述管线在 docs/scoring.md 中有完整叙述。tech-news是仓库默认的画像——tests/test_profiles.py 直接以"tech-news"作为ProfileRegistry.load的default_profile参数，验证内置画像可正常加载。

二、评估目标（Evaluation Goal）：为谁评分、评什么

tech-news画像的评估目标（见 analysis.md）原文如下：

Evaluate the importance of timely technology news for readers interested in software engineering, artificial intelligence, machine learning, computer systems, hardware, open source, and the technology industry.

要点拆解：

对象是"及时的科技新闻"（timely technology news），不是长文论述或教程，这决定了它与tech-blog画像的边界（详见下文第五节）。
受众画像明确：软件工程、人工智能、机器学习、计算机系统、硬件、开源与科技行业的读者。评分本质上是在回答"这条新闻对这批读者重不重要"。
关键词是 importance（重要性），而不是热度或传播量。

这条目标会被注入分析系统提示词，作为 AI 每次评分的总纲。src/ai/prompting/analysis.py 中的ANALYSIS_RULES明确要求：分析只能基于条目本身及其元数据，不得使用训练记忆中的外部信息（UNTRUSTED_INPUT_RULE），并且要"一致地应用画像的评估策略"（Apply the profile's evaluation policy consistently）。

三、评分标准（Scoring Rubric）：五档量表的完整语义

analysis.md给出的评分量表是整篇文章的骨架，必须原样掌握：

分数	档位	含义
9–10	Groundbreaking（开创性）	重大突破、范式转移、广泛使用技术的重要大版本、重要研究成果，或改变行业格局的公告
7–8	High value（高价值）	值得立即关注的重要进展，包括技术深度解析（technical deep-dives）、新颖方法、有洞察力的分析，以及有价值的工具或库
5–6	Interesting（有趣）	渐进式改进、实用教程、中等程度的社区关注，或者值得了解但并非紧迫的进展
3–4	Low priority（低优先级）	例行更新、常识性内容、浅层处理，或以推广为主的内容
0–2	Noise（噪音）	垃圾信息、离题内容、琐碎更新，或纯粹宣传性内容

这份量表在 docs/scoring.md 中被再次引用，作为内置tech-news画像的标准刻度。理解它需要抓住三个分层逻辑：

新颖性与范式级别决定能否上 9 分——"重大突破""范式转移""行业级公告"是硬指标；
对从业者的可迁移价值决定 7–8 分——深度技术解析、新方法、值得收藏的工具都在此列；
紧迫性与增量大小决定 5–6 分与 3–4 分的分界——渐进改进、教程属于"值得知道但不急"，例行更新与常识则滑向低优先级。

四、评估要求（Evaluation Guidance）：七个考量维度的实操解读

analysis.md的评估要求原文为：

Consider technical depth, novelty, likely impact, source quality, relevance to software engineering and AI systems, and concrete supporting details. Treat substantive community debate as additional evidence of value, but do not equate popularity with technical importance. Do not reward exaggerated headlines.

可以拆成七条可执行准则：

技术深度（technical depth）：内容是否讲清了机制、原理与权衡，而非停留在 announcement 层面。
新颖性（novelty）：是首次发布的新东西，还是老话题的重复报道。
可能影响（likely impact）：影响面有多大、影响谁。
来源质量（source quality）：是官方公告、代码仓库、论文，还是二手转述与营销稿。
与软件工程 / AI 系统的相关性（relevance）：对照第二节的受众画像判断。
具体支撑细节（concrete supporting details）：有版本号、数字、可用性、兼容性等可核验细节的加分。
社区讨论是补充证据，热度不是：实质性社区争论（substantive community debate）可作为额外证据，但"popularity ≠ technical importance"，传播量不能等价于技术重要性。

最后一条在输出契约与增强阶段都有呼应：enrichment.md明确要求"Engagement counts are not evidence of consensus"（互动数不是共识的证据），并且在写community_discussion板块时须区分观点与既定事实。

关于标题的硬性规则：评估要求最后一句是 "Do not reward exaggerated headlines"——夸大其词的标题不得加分。这直接约束了后续增强写作：enrichment.md要求标题不超过 15 个单词、不得使用标题党（clickbait），且禁止"marks a major milestone""will reshape the industry"这类空泛套话，除非有具体、实质的证据支撑。

标签规则：评估要求末尾指定 "Use three to five specific topic tags"——每条条目必须给出3–5 个具体主题标签（如ai-tools、security-incident这类粒度，而非宽泛的tech）。标签在ContentAnalysis模型中以tags: List[str]承载（见 src/models.py），并会成为后续类目分组与主题去重的依据。

五、边界判定：什么内容该走 tech-news（match.md）

评分标准之上，还有一个"该不该用这个画像"的前置判断，由 profiles/tech-news/match.md 定义：

适用：软件工程、AI/机器学习、计算机系统、硬件、开源与科技行业中及时的进展（timely developments）。典型条目包括：实质性版本发布（substantial releases）、研究突破、安全事件、行业公告、与近期事件绑定的技术分析、能带来实操洞见的社区讨论。
不适用：以完整长文论证、逐步教程、完整学术论文为主要价值的内容；以金融/市场视角优先的内容（这类应走 finance-news）；例行更新；无实质信息的推广材料。

该边界直接对应分类器逻辑：src/ai/classifier.py 中，条目可携带显式profile字段（source_override）或"auto"（AI 用全部match.md匹配），也可传入候选画像列表限定范围。若 AI 分类失败，则回退到默认画像tech-news。这与docs/scoring.md描述的 Profile resolution 步骤一致。

六、输出契约：JSON 结构、校验与自动修复

analysis.md只定义了"评什么分"，而"返回什么格式"由 src/ai/prompting/analysis.py 中的analysis_system_prompt输出契约规定：

{ "score": 0.0, "reason": "concise explanation", "summary": "one-sentence summary", "tags": ["tag1", "tag2", "tag3"] }

四个字段的含义与约束：

score：0–10 的数字，对应第五节量表；
reason：简明理由，解释为什么给这个分数；
summary：一句话摘要，供日报直接使用；
tags：3–5 个具体主题标签（第二节已述）。

实际调用链：ContentAnalyzer._analyze_item（src/ai/analyzer.py）先通过分类器解析画像，组装 user prompt（标题、来源类型、作者、URL、正文切片、评论区与互动元数据），然后请求模型返回 JSON。响应经_validate_analysis_response校验：必须能解析为 JSON 对象，且能被ContentAnalysis模型（score 限 0–10）验证。若首次校验失败，会自动用temperature=0重发一次修复请求（repair attempt）；仍失败则以score=None兜底存入，避免整条管线崩溃。AI 调用本身还套了 tenacity 指数退避重试（3 次，2–10 秒等待）。

交互元数据的注入细节值得注意：analyzer.py会把score、descendants（评论数）、favorite_count、retweet_count、reply_count、views、bookmarks、upvote_ratio等来源元数据拼入讨论段（discussion section），这正好服务于analysis.md"以社区争论为补充证据"的要求——但模型只会把它当作证据输入，不会因数量自动加分。

七、内容准备：多少正文进入模型（analysis_max_chars 与 sampling）

评分质量依赖喂给模型的文本质量。tech-news的analysis_max_chars默认 1000 字符，sampling默认prefix，这些字段的 schema 定义在 src/processing/profiles.py：

analysis_max_chars: int = Field(default=1000, ge=500, le=100_000) sampling: Literal["prefix", "head-middle-tail"] = "prefix"

prefix：只取文章开头部分；
head-middle-tail：从开头、中间、结尾各取片段，适合正文较长时保留全文信息骨架。

analyzer.py通过split_content拆分正文与评论，再用select_content按上述参数采样，随后把"Comments（≤1500 字符）+ Engagement 指标 + Discussion URL + Community Note"追加进讨论段。也就是说：评分不是基于全文，而是基于一个受控的采样窗口——这是控制成本与延迟的关键设计。

八、运行配置：阈值过滤与主题去重

评分完成后，tech-news是否放行取决于运行时配置中的阈值（threshold）。在 data/config.example.json 中：

"profile_settings": { "tech-news": { "threshold": 7.0, "topic_dedup": true } }

参数语义：

threshold：0–10 之间的数字，score >= threshold的条目继续进入日报选择，否则被丢弃；设为null或省略则只评分不过滤（docs/scoring.md有对应示例）。阈值可在 MCP 操作中按次覆盖配置值。
topic_dedup：是否在画像内做主题去重。默认true（tests/test_profiles.py 验证了ProfileSettingsConfig的默认行为）。

注意阈值的取舍：docs/scoring.md中的示例对 tech-news 用了 8.0（"只保留高价值以上"），而config.example.json用 7.0——二者都是合法取值，实际阈值应结合你的日报密度与噪音容忍度调整。若把阈值设得过高，7–8 分的"高价值但非开创性"内容（如优质深度解析、新工具发布）会被全部过滤掉；设得过低则噪音比例上升。

九、下游衔接：评分结果如何驱动增强板块（enrichment）

一条科技新闻通过阈值后，会被 profiles/tech-news/enrichment.md 定义的增强流程加工成日报条目。profile.json声明了四个板块（见 profiles/tech-news/profile.json）：

板块 ID	工具	必填/可选	职责
`summary`	无	必填（primary）	2–4 句完整句，先讲清"发生了什么、对谁有影响"，包含决定性技术细节（名称、版本、数字、可用性、兼容性、条件），并区分"已宣布的计划/厂商声明"与"已落地能力/独立测量结果"
`background`	`history_search`、`web_search`	必填	1–3 句，解释理解这条新闻所需的前置概念或前期进展；版本/事件/政策变化可用`history_search`找前因
`impact`	`web_search`	可选	只写一条有证据支撑的具体后果；若只是泛泛行业趋势则省略该板块
`community_discussion`	无	可选	1–2 句，总结评论中最有用的论点/分歧/一手经验，观点与事实分开表述；无实质讨论则省略

与评分标准的呼应关系非常清晰：

summary要求"区分宣布与实测"，正是analysis.md"source quality + concrete supporting details"的落地；
impact要求"证据支撑的具体后果"，与"popularity ≠ importance"一脉相承；
community_discussion要求"互动数不是共识的证据"，是评估要求第七条的直接执行。

历史上下文规则（enrichment.md的 Historical context 一节）同样值得注意：history_search返回的是 Horizon 历史日报摘要，最多引用两条，且必须能说明直接关联（同一产品的前一版本、同一事件的更早阶段、同一政策/价格/能力的已记录变更）。共同的公司、人物或"AI"这类宽泛主题不构成关联；引用历史时必须标注具体日报日期（如 "Horizon's April 1 digest reported…"），且历史摘要不能作为当前主张的独立确认。

在代码层面，src/ai/enricher.py 的_plan_and_execute_tools会先让模型基于板块声明生成工具计划，再校验：请求只能使用该板块声明的工具（否则抛错）、history_search每个条目最多调用一次、同一 (block, tool, arguments) 去重。工具返回结果会转化为source_refs引用并作为来源（sources）随日报输出。

十、测试验证：画像契约如何被守护

profiles/tech-news 目录的可加载性、完整性以及与其它画像的差异，都被测试覆盖：

tests/test_profiles.py 以tech-news为默认画像加载全部内置画像，断言match_prompt、analysis_prompt、enrichment_prompt均非空，并专门验证tech-news的impact板块optional is True；
同一个文件还测试了候选画像列表的合法性（空列表、重复、混入auto、未知画像均被拒绝）与提示词路径逃逸防护（src/processing/profiles.py 保证提示词文件不能指向画像目录之外）；
src/models.py 的ContentAnalysis将 score 约束在 0–10 且禁止 NaN/Inf，从数据模型层面守住评分量表的边界。

这些测试共同保证了：只要profiles/tech-news/analysis.md中定义的量表与规则被修改，管线行为会随提示词同步变化，且非法配置会在加载阶段（而非运行阶段）就被拦截。

小结：tech-news 画像的使用速查

判断是否该用：对照 match.md——及时的软件工程/AI/系统/硬件/开源行业进展适用；长文论述、教程、纯金融内容不适用。
理解分数：9–10 开创性、7–8 高价值、5–6 有趣、3–4 低优先级、0–2 噪音；热度不等于重要性，夸大标题不得加分，必须给出 3–5 个具体标签。
配置运行：在data/config.example.json的processing.profile_settings.tech-news中设threshold（0–10，可null）与topic_dedup；未配置阈值时只评分不过滤。
读懂输出：analysis.md的输出经 analysis.py 的契约校验后，驱动 enrichment.md 生成summary/background/impact/community_discussion四个板块，最终渲染为中英文日报条目。