infocard-topic-selection

name	infocard-topic-selection
description	Use when selecting or evaluating information-card topics from the user's profile or explicitly supplied themes; judge value and visual expression potential without choosing a concrete infocard theme or publishing.
version	2.0.0
author	Hermes Agent
license	MIT
metadata	{"hermes":{"tags":["infocard","topic-selection","editorial","user-profile","ranking"],"related_skills":["any2card","infocard-publish-sop","hupan-copy-editor"]}}

信息卡选题判断

Overview

本技能只负责判断“什么值得做成信息卡”，不负责外部资料搜集、事实核验、HTML/Markdown 写作、发布或发送。

默认选题来源是用户已表达的内容偏好、长期关注方向和既有信息卡主题；用户也可以显式指定一个主题、链接、项目、人物、事件或候选列表，覆盖默认画像。

When to Use

• 用户说“按我的偏好找选题”“给我推荐信息卡主题”。
• 用户给出一个主题，询问是否值得做卡。
• 用户给出多个候选主题，要求比较、排序或淘汰。
• 用户要求建立信息卡选题池，但尚未进入调研或写卡阶段。

不要用于：

• 搜索或核验外部事实；
• 直接创建信息卡、调查报告或发布 bundle；
• git 提交、push、网页发布或外部发送；
• 把社交平台帖子中的宣传语当作已验证事实。

Input Modes

1. 默认用户画像模式

当用户没有指定主题时，依据其稳定内容偏好生成候选题。当前画像优先级：

• AI Agent、Agent Skills、MCP、Claude Code、Codex、自动化工作流；
• 开源项目、工具链、CLI、开发者生产力；
• 复杂系统的结构拆解、方法论、调查复盘和证据边界；
• 能形成架构图、流程图、时间线、对比表或操作手册的主题；
• 有明确一手材料、可验证、对中文读者有实际帮助的主题。

画像只用于发现和排序，不替代用户当前的明确指令。

2. 指定主题模式

用户明确给出主题时，以指定主题为主，不擅自改换方向。可以补充相邻角度，但必须标注为建议，不得替代原题。

3. 单主题模式

对一个主题进行深度判断，输出：

• 选题结论：推荐 / 有条件推荐 / 不推荐；
• 综合评分（0—100）及评分依据；
• 核心切入角度；
• 目标读者；
• 推荐信息卡结构；
• 视觉表达潜力（如时间线、流程图、对比表或架构图），不输出具体主题名；
• 主要风险与缺口；
• 是否建议进入调研阶段。

4. 多主题模式

对候选主题横向比较，输出：

• 综合排名；
• 每个主题的维度评分；
• 推荐做卡 / 备选 / 淘汰；
• 排名理由；
• 是否适合合并；
• 后续调研优先级。

Evaluation Framework

对每个主题按以下维度评分，默认使用 0—10 分，再换算为 100 分制：

维度	权重	判断重点
信息价值	20%	是否存在值得解释的核心问题或机制
事实基础	15%	是否预期能找到稳定、可信的一手材料；这里只做可得性预判，不实际搜索
独特性	15%	是否避免与已有信息卡重复
读者价值	15%	是否帮助读者理解、决策或行动
视觉潜力	10%	是否适合时间线、架构图、流程图、对比表等
时效性	10%	是否具有当前价值，或是否容易快速过期
制作成本	5%	调研、核验和设计的预期成本；成本越低分越高
风险边界	10%	证据不足、侵权、误导、诽谤、平台依赖等风险；风险越低分越高

结论阈值

• 80—100：推荐：具备明确价值，可优先进入调研。
• 65—79：有条件推荐：需要限定范围、补足证据或改变叙事角度。
• 0—64：不推荐：价值不足、重复度高、证据边界不稳或成本风险不匹配。

评分不是事实核验结果。事实缺口必须写成“待调研”或“不确定”，不能用评分掩盖。

必须核验的重度重复

本技能在评分前必须执行去重检查。与已有知识库重复的主题不一定是“坏选题”，但必须：

1. 找到与候选主题名称相同或实质相同的现有条目（见下）；
2. 记录重复性质（同名 vs 同实质）；
3. 在评分和推荐角度中显式说明如何避免与现有内容重复；
4. 在输出中明确写“与 LLM Wiki 中 XXX 不同，切入口是 YYY”。

去重检查的目标（按优先级）：

检查位置	说明	检查方法
LLM Wiki entities/	具名实体页（项目/人物/产品）	精确名称匹配
LLM Wiki concepts/	概念页	实质相同则记录
LLM Wiki comparisons/	对比分析页	对比主题是否重叠
infocard-pub/_index.yaml	已发布信息卡索引	slug 和标题双重匹配
infocard-pub/index.html	已发布信息卡首页	全文搜索候选名称

去重不是排除：重复 ≠ 淘汰。常见情况：

• 同名重复：同一项目已有卡——除非有重大版本/功能更新，否则不推荐新卡；
• 同实质重复：主题虽不同但实质覆盖同一领域——必须调整切口，或合并到一张卡；
• 概念重叠但切口独立：虽有 Wiki 概念页，但信息卡的独特价值是“操作化、工具对比或速查手册”而非“概念阐释”——可以推荐，但需明确差异化。

用户强制约束："不能和llmwiki中内容重复"时，去重变为硬门禁：若候选主题在 LLM Wiki 中存在实质相同的 entities/ 或 concepts/ 条目，且无法通过独立切口区分，直接标记不推荐，不进入评分。

Topic Framing

优先把宽泛主题压缩为一个可回答的问题：

• 从“介绍某工具”改为“它解决了哪类工作流瓶颈”；
• 从“整理一堆资源”改为“如何按任务阶段选择工具”；
• 从“AI 很厉害”改为“它的架构、边界和真实使用条件是什么”；
• 从“某观点很流行”改为“观点背后的机制、证据和适用范围是什么”。

推荐输出 1—3 个标题草案，但不要写成最终发布文案。视觉潜力只描述信息组织形态；具体 style、候选池和主题选择统一交给 infocard-theme-assignment。

Source and Platform Boundary

候选可以来自用户提供的链接、标题、帖子或平台线索，但本技能只判断选题，不将这些材料自动升级为事实证据。

当用户明确要求“寻找 N 个 X 帖子并给出信息卡选题”时，默认通过现有 Chrome 登录态在 X 全站搜索页（/search?q=...）检索；默认交付 5 个中文候选，包含原帖链接、作者/时间、可见内容、差异化切口、评分和待核验事实。只有用户另行指定时才改用其他来源。

X 搜索页浏览器工具限制（重要）：

• browser_snapshot 在 X 搜索页上会超时（30s AX tree 遍历失败），不要使用。
• 正确方式：先 browser_navigate 到搜索 URL，再用 browser_console 执行带 setTimeout(4000) 的 JS 提取脚本。
• Jina Reader (r.jina.ai/URL) 对 X 返回 403 AbuseAlleviationError（DDoS 检测），不要作为 X 内容来源。
• 详见 x-bookmarks-manager skill 的 references/x-search-extraction-patterns.md。

允许先调用 X 检索能力完成线索发现，再回到本技能做选题判断；这不等于进入事实调查或信息卡生产。交付时必须分开三层：

1. 帖子线索：保留作者、原帖 URL、可见发布时间/互动信息（若能直接读取），并标注“X 帖子可见内容”；
2. 选题判断：按本技能维度评分，说明为何值得做卡；
3. 待核验事实：列出需要通过官方文档、项目仓库或其他一手来源核对的断言。

检索 X 时优先使用 X 原帖 URL，而不是搜索引擎转载；可用浏览器登录态搜索页，并通过 DOM/CDP 提取每条 article 的正文和 /status/<id> 链接。若帖子正文被截断、只有搜索摘要或无法确认作者/时间，不得补写缺失内容，应标为“部分可见”。

对于“找帖 + 选题”复合请求，输出仍然只停留在选题层：不创建 HTML/Markdown、不生成发布 bundle、不提交、不 push、不发布，也不把 X 帖子的一句话宣传直接写成信息卡事实。

输出中可以写“该线索提示了某个选题方向”，但不得：

• 宣称已完成外部调研；
• 编造作者、数据、项目能力或影响力；
• 把平台名称写入未来信息卡的事实来源，除非后续调研流程明确需要并验证；
• 因为互动量、热度或推荐位而直接判定内容有价值。

Output Templates

单主题模板

## 选题结论
- 结论：推荐 / 有条件推荐 / 不推荐
- 综合评分：__/100
- 建议：进入调研 / 先缩小范围 / 暂缓

## 核心判断
一句话说明为什么值得或不值得做卡。

## 评分
| 维度 | 分数 | 依据 |
|---|---:|---|
| 信息价值 | /10 | |
| 事实基础 | /10 | |
| 独特性 | /10 | |
| 读者价值 | /10 | |
| 视觉潜力 | /10 | |
| 时效性 | /10 | |
| 制作成本 | /10 | |
| 风险边界 | /10 | |

## 建议方向
- 核心问题：
- 目标读者：
- 标题草案：
- 推荐结构：
- 推荐风格：

## 待调研与风险
- 待核验事实：
- 可能的范围边界：
- 不应直接写成结论的内容：

多主题模板

## 排名
| 排名 | 主题 | 评分 | 结论 | 下一步 |
|---:|---|---:|---|---|

## 逐题判断
### 主题 A
- 核心价值：
- 优势：
- 缺口：
- 风险：
- 建议角度：

## 合并建议
说明哪些主题可以形成一张卡，哪些必须拆分。

## 调研优先级
1. 
2. 
3. 

User-profile default and explicit override

默认模式不是“凭空推荐”，而是从用户画像中提取稳定偏好，再生成候选：

• AI Agent、Agent Skills、MCP、Claude Code、Codex、自动化工作流；
• 开源项目、工具链、CLI、开发者生产力；
• 复杂系统拆解、方法论、调查复盘与证据边界；
• 适合架构图、流程图、时间线、对比表或操作手册的主题。

当用户指定主题或候选列表时，指定输入优先于画像默认值；画像只用于补充角度、目标读者和风格建议，不得擅自改题。

与主题分配的边界

本 skill 输出 topic_value、content_shape_hint 和 visual_expression_potential 即可，不输出 theme_primary、theme_fallback、具体 style 或主题权重。进入 authoring 前，由 infocard-content-types 确定内容结构，再由 infocard-theme-assignment 生成候选池并写入 theme-decision.json。选题判断不因主题偏好而替代内容价值判断。

Operating Rules

1. 先判断用户是默认画像模式、指定主题模式、单主题还是多主题。
2. 能从用户画像形成候选时直接推进，不因低风险判断反复确认。
3. 用户指定主题时不擅自替换，只提出范围收窄建议。
4. 明确说明“选题判断”与“事实核验”的边界。
5. 如果用户随后说“搜集”“调查”“创建”“发布”，交由对应研究、写卡或发布技能处理。
6. 用户只说“创建信息卡”时，不把本技能误当成写卡流程；应先确认或调用信息卡生产流程。
7. 不因为一个主题的热度、互动量或单一来源就给出高分。
8. 输出必须先给结论，再给评分证据、风险和下一步。

Verification Checklist

• 已识别输入模式：默认画像 / 指定主题 / 单主题 / 多主题。
• 已给出推荐、条件推荐或不推荐结论。
• 已使用八个评价维度或明确说明删减原因。
• 已区分选题判断、事实核验和信息卡生产。
• 未声称完成外部搜索或验证不存在的事实。
• 未创建文件、提交、推送或发布外部内容。
• 下一步仅建议进入调研，不自动越权执行。