| 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：不推荐：价值不足、重复度高、证据边界不稳或成本风险不匹配。
评分不是事实核验结果。事实缺口必须写成“待调研”或“不确定”，不能用评分掩盖。
必须核验的重度重复
本技能在评分前必须执行去重检查。与已有知识库重复的主题不一定是“坏选题”，但必须：
- 找到与候选主题名称相同或实质相同的现有条目（见下）；
- 记录重复性质（同名 vs 同实质）；
- 在评分和推荐角度中显式说明如何避免与现有内容重复；
- 在输出中明确写“与 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 检索能力完成线索发现，再回到本技能做选题判断；这不等于进入事实调查或信息卡生产。交付时必须分开三层：
- 帖子线索：保留作者、原帖 URL、可见发布时间/互动信息（若能直接读取），并标注“X 帖子可见内容”；
- 选题判断：按本技能维度评分，说明为何值得做卡；
- 待核验事实：列出需要通过官方文档、项目仓库或其他一手来源核对的断言。
检索 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
- 先判断用户是默认画像模式、指定主题模式、单主题还是多主题。
- 能从用户画像形成候选时直接推进，不因低风险判断反复确认。
- 用户指定主题时不擅自替换，只提出范围收窄建议。
- 明确说明“选题判断”与“事实核验”的边界。
- 如果用户随后说“搜集”“调查”“创建”“发布”，交由对应研究、写卡或发布技能处理。
- 用户只说“创建信息卡”时，不把本技能误当成写卡流程；应先确认或调用信息卡生产流程。
- 不因为一个主题的热度、互动量或单一来源就给出高分。
- 输出必须先给结论，再给评分证据、风险和下一步。
Verification Checklist
