Good Ask：给一个行业，提出真正值得问的问题

这个 skill 是干什么的

输入一个行业，输出 5-8 个"好问题"，每个问题配一段理由，说明它为什么好、依据是什么。不给答案，不给解法，不做分析报告 —— 这是选题阶段，不是解题阶段。好问题本身就是稀缺资源：大多数人一上来就想答案，但如果问题本身很平庸（虚构的、太窄的、非黑即白的），答得再好也没意义。这个 skill 的价值就在于帮用户先把"问对问题"这一步做扎实。

什么是"好问题"：七条标准

把这七条当作一个打分清单，逐条对照每个候选问题，而不是笼统地"感觉好不好"。每一条都对应一个具体的失败模式，理解了失败模式才知道怎么避免：

1. 狗皮膏药 或 近期热点，二选一：问题要么是这个行业长期甩不掉的老大难（多年了没人真正解决），要么是最近确实在发生、正在被讨论的事。避免那种"理论上存在但其实没人在意"的问题——如果一个问题既不是老毛病也不是新事件，它大概率是凭空想出来的伪问题。

2. 要真实，不要虚构：每个问题背后必须能指向真实存在的现象、事件、数据或主体（具体公司/政策/数据/新闻），不能是"听起来很像那么回事"但编出来的。这一条是硬约束——虚构问题看起来聪明，但经不起追问，会让整个输出显得不可信。这意味着必须做真实检索，不能凭训练知识里的印象编问题，尤其是"近期热点"这一类，必须核实真的是近期发生的。

3. 覆盖广泛关联主体：好问题应该牵连足够多的人或行业——不只是行业内部玩家，还包括上下游、监管方、从业者、消费者/用户、甚至看似不相关但被波及的邻近行业。判断标准很简单：如果这个问题解决与否，只有一小撮人关心，它的公共讨论价值就有限。

4. 要深刻，不容易解决：如果一个问题稍微搜一下就能找到公认的标准答案，或者随便一个从业者都能三言两语说清楚该怎么办，那它不够格。好问题往往涉及多方利益冲突、结构性矛盾，或者"看似简单实则有隐藏成本"的取舍。

5. 够得着，不要假大空：深刻不等于遥不可及。要避免那种"除非重构整个人类社会/彻底修改法律体系"才能回答的问题——这类问题听起来深刻，实际上无法推进任何真实讨论。好问题应该是：经过认真思考和调研，能看到至少一条可能的解法方向，哪怕这条路很难走。可以用一个简单的自检——"如果找一个懂行的人认真想两小时，能不能勾勒出一个哪怕不完美的解法？" 如果答案是"完全无法想象"，说明问题定得太大太空。

6. 有话题性，能引发讨论：问题不能是非黑即白、选择题式的（比如"XX 到底是好是坏"），而应该是那种不同立场的人会给出不同答案、且各自都有道理的问题。判断标准：如果你能立刻想到一个"标准答案"，这个问题就不够有话题性；如果你能想到至少两派立场都站得住脚的观点，它就合格。

7. （隐含标准）问题要具体、可讨论，不能大而化之：一句话能让人立刻明白在问什么、涉及谁。避免"XX行业未来会怎样"这种漫无边际的问法，尽量让问题带有具体的场景、主体或冲突点。

工作流程

第一步：确认行业范围

如果用户给的行业名称比较宽泛（比如"互联网行业"），可以直接开始，但在最终产出时要注意让问题落在具体的细分场景里，不要停留在行业名称这一层。不需要为此专门打断用户提问澄清——除非行业名称本身有歧义（比如"苹果"是指公司还是水果种植业），这种情况下才需要向用户确认一次。

第二步：真实检索（这一步不能省）

必须用 web_search（以及需要时 web_fetch 深入阅读）做两条线的检索，因为标准 1 和标准 2 都要求问题有真实依据：

• 老大难线：搜索该行业"痛点"、"难题"、"顽疾"、"多年未解决"、"行业通病"等关键词，找那些反复出现、多年被讨论但没被真正解决的结构性问题。
• 近期热点线：搜索该行业最近（近1-3个月内，注意结合当前日期）的新闻、政策、事件、数据发布、舆论争议，找真正"正在发生"的事。今天是 2026 年 7 月 2 日，搜索时要用真实的当前时间去构造查询词，避免用训练知识里过时的"最近"。

检索时要有意识地覆盖不同的关联主体（对应标准 3）：企业/从业者视角的新闻、监管/政策视角的新闻、消费者/用户投诉或舆论、上下游产业链的报道。多角度搜索能帮你在后面自然地写出"覆盖广泛"的问题。

搜索建议：每个方向至少 2-3 次搜索，查询词要短（1-6 个词），可以从行业名+"痛点"/"顽疾"这类词开始，再逐步细化到具体的公司、政策、数据点。如果搜到了具体的名字、数字、事件，记下来——这些是后面写"理由"时用来证明问题真实性的素材（转述即可，不要大段引用原文，遵守版权规范）。

第三步：广泛头脑风暴候选问题

基于检索到的真实素材，列出 10-15 个候选问题，不要一上来就精挑细选。这一步的目的是有足够的候选池，故意让候选问题分散在不同的关联主体和不同的切入角度上（有的从企业视角问，有的从监管视角问，有的从用户视角问），这样才有筛选的空间。

第四步：用七条标准逐条筛选

对每个候选问题，快速过一遍七条标准，主要淘汰这几类:

• 找不到真实依据支撑的（淘汰，违反标准 2）
• 只有一小撮人关心的（淘汰，违反标准 3）
• 网上已有公认标准答案的（淘汰，违反标准 4）
• 大到没法想象任何解法路径的（淘汰，违反标准 5）
• 一句话就能给出黑白分明答案的（淘汰，违反标准 6）

筛完之后，保留 5-8 个最强的问题。如果筛选后不足 5 个，回到第三步继续挖掘，而不是降低标准去凑数——凑出来的平庸问题比少几个问题更伤害整体质量。

第五步：为每个问题写理由

理由不是简单复述标准名称（比如不要写"这个问题很深刻，也很有话题性"这种空话），而是要具体说明：

• 这个问题的真实依据是什么（哪个现象/数据/事件/主体，转述而非逐字引用）
• 它牵连了哪些不同的主体，为什么他们都被卷入
• 为什么它不容易解决——具体的利益冲突或结构性矛盾是什么
• 为什么它"够得着"——哪怕说一句可能的解法方向大致在哪
• 为什么它会引发争论——点出至少两种可能存在分歧的立场

输出格式

用 Markdown 输出，结构如下（问题数量 5-8 个为宜，具体行业信息、检索到的真实要点要体现在理由里）：

# [行业名称] · 好问题清单

## 问题一：[具体、有场景感的问题]
**类型**：狗皮膏药 / 近期热点
**理由**：[结合真实检索到的信息，说明这个问题为什么符合"真实、覆盖广、深刻、够得着、有话题性"，点出至少两种可能的立场分歧]

## 问题二：...
（依此类推）

如果用户希望保存为文件，按照惯例输出到当前项目 markdown/ 目录，文件名使用"行业名+好问题清单+日期"的中文命名方式；如果只是想在对话中看一眼，直接在回复里给出即可，不必强行落盘。

注意事项

• 只给问题和理由，不给答案。哪怕理由里提到"可能的解法方向"，也只能点到为止（一两句话），不能展开成解决方案，一旦展开成解决方案就偏离了这个 skill 的定位，应该提示用户换用 multi-expert-analyzer / bug-hunter / red-blue-debate 等 skill 继续深挖。
• 拒绝黑白分明的问题。写完之后自己读一遍每个问题，如果脑子里立刻蹦出一个"标准答案"，说明这个问题不合格，要么换掉要么改写得更有张力。
• 拒绝假大空的问题。同样自检一遍，如果这个问题大到"没法想象任何解法路径"，也要换掉或者收窄。
• 理由必须落地到具体信息，不能写"业内普遍认为"、"很多人反映"这种空泛表述而不给出具体依据——这正是"真实性"标准要卡住的东西。
• 涉及版权的检索结果转述时遵循一贯的规范：不逐字大段引用，用自己的话转述即可。