research-topic-compiler

产品研究编译器（research-topic-compiler）

中文速查

• 中文名：产品研究 / 证据与决策输入
• 英文稳定名：research-topic-compiler
• 分类：研究学习 / Obsidian 知识编译
• 你可以这样叫我：系统研究这个主题、帮我整理到 Obsidian、做一个深度专题、研究行业最佳实践、概念解读、概念源流、PM 技术评审提问脚本、行业演进看板、把这个大白话拆成研究目标
• 适合：围绕产品问题做多渠道证据收集、竞品与替代方案比较、用户/市场信号、证据矩阵、阶段结论、候选池、研究看板和应用转化；也适合把用户的大白话、模糊主题或 Roadmap 前置想法转成研究目标、研究问题和输出要求
• 默认学习型 HTML：当用户要逐步理解、深入解释、对比自身现状并落到行动时，使用 learning-report-html，不要把研究控制面直接投影成 Dashboard。
• 不适合：创建或评审 Skill；普通新闻搜索或一次性摘要；明确要“选一个 / 给最终推荐 / 排除其他方案”时改用 decision-research

Overview

使用这个 Skill 把一个研究主题编译成可学习、可追溯、可继续扩展、并能按用户画像转化为实际工作判断的 Obsidian Research Project 或聊天内研究报告。

核心原则：

• 先把用户原话转成明确研究目标、研究问题和输出要求，再判断研究深度、渠道和样本量。
• 研究框架不是固定报告目录：先识别 Research Job，分别维护 Evidence/Explanation Framework；V0 只是可修订假设，最终报告必须从证据更新后的 Framework Vn 重新编译。
• 先解析用户画像，再决定解释方式、案例选择、实践任务和应用转化。
• Seed Corpus 是线索和初始假设来源，不默认是权威证据；二手核心 Claim 要追溯原始来源或披露无法追溯的影响。
• Normal Research 和 Application 围绕最高价值证据缺口迭代；每轮只执行一个能降低关键不确定性的 Next Best Evidence Action。
• Research 只拥有证据覆盖、来源、矛盾、置信度和残余 gap；最终推荐、排除逻辑、方案设计和 readiness 属于其他 owner。
• Obsidian 是内部基线和默认沉淀位置，不是唯一研究渠道。
• 外部渠道动态选择，不默认全开；根据主题类型、证据缺口、时效性和可信度要求启用。
• 需要扩源时把 Pre-Research Source Expansion 作为候选发现策略：用公开搜索、垂直 API、RSS、产品/市场目录等渠道寻找能关闭当前 Gap 的来源，再筛选进入正式证据矩阵。
• 结论必须能回到证据矩阵；05_研究报告 是第一阅读入口，02_证据与卡片 是按需深挖层。
• 系统学习不是重型课程仓库；默认保持轻量，只有触发条件满足时才建议独立学习包文件。
• 当研究会影响产品策略、商业化、工作台/连接器设计、企业 adoption 或其他高成本决策时，默认按高门槛应用研究处理，读取 references/applied-business-research-contract.md。
• 轻量概念解构属于本 Skill 的研究模式，不再单独使用独立概念看板 Skill；它适合快速建立概念源流、语义漂移、范式阶段和 PM 决策问题。
• 用户画像只影响解释深度、案例选择、输出结构和实践任务，不覆盖用户当前明确要求。
• 研究必须能转成行动：判断、方案、模板、任务、PRD、Workflow、Eval、Checklist、SOP、路线图或实践练习。
• 用户补充的新渠道可以进入渠道库，但要先判断适用主题、访问条件、证据强度和风险。
• 微信公众号、X、私域社区、付费库等渠道默认只能做公开候选发现；任何登录态读取、客户端转发、发送到 Obsidian 同步号或第三方服务的动作，都需要当前 run 的明确授权和可见确认点。

Input / Context Intake

启动研究前先收集或推断这些上下文；不要问本地文件能发现的信息，只在答案会改变研究范围、访问权限或写回位置时追问：

• 原始意图：用户原话、业务愿望、想产出的材料、隐含的后续动作。
• 研究主题：主题名称、用户要解决的决策或学习目标、是否已有种子资料。
• 预期产物：聊天内报告、Obsidian Research Project、更新已有专题、还是长期雷达。
• 深度约束：用户期望的速度、深度、样本量、是否需要 L4/L5 级外部扩展。
• 内部基线：是否扫描 Obsidian、哪些 Vault/目录可用、是否只读 笔记同步助手。
• 渠道偏好：必须看的渠道、明确排除的渠道、是否需要产品研究、GitHub、官方文档、论文、社区或 X。
• 访问边界：登录、API token、付费报告、私密社区、公司内部资料和引用限制。
• 写回边界：目标目录、命名规则、是否允许新增渠道到 channel-registry.md。
• 用户画像：角色、领域、技术深度、目标类型、输出偏好、应用场景和最终决策需求；先按 User Context Resolution 解析，不要默认每次追问。