给定一个行业,围绕该行业提出若干个"好问题"(只提问、不给答案,但每个问题要配"为什么这是个好问题"的理由)。触发条件:用户提到"帮我想几个好问题"、"这个行业有什么值得问的问题"、"帮我出选题"、"行业狗皮膏药问题"、"行业老大难问题"、"近期热点问题"、"帮我策划几个话题"、"这个行业值得深挖的问题有哪些"、"good ask"、"提问清单",或者在准备写行业分析/公众号文章/辩论/调研之前想先找到几个真正值得问的问题。即使用户只说"帮我想想XX行业能问点啥"或"XX行业有哪些值得讨论的问题",也应使用本 skill。本 skill 只产出问题和理由,不产出答案、不产出解决方案,如果用户还想要答案/深度分析,应在问题清单产出后提示可以用 multi-expert-analyzer、bug-hunter、red-blue-debate、industry-insight-writer 等 skill 继续深挖。
Install with the open skills CLI (global, non-interactive — available in every Claude Code session):
npx skills add digoal/blog --skill "good-ask" -g -a claude-code -yOr manually — copy the SKILL.md below into:
~/.claude/skills/good-ask-digoal-2/SKILL.md---
name: good-ask
description: 给定一个行业,围绕该行业提出若干个"好问题"(只提问、不给答案,但每个问题要配"为什么这是个好问题"的理由)。触发条件:用户提到"帮我想几个好问题"、"这个行业有什么值得问的问题"、"帮我出选题"、"行业狗皮膏药问题"、"行业老大难问题"、"近期热点问题"、"帮我策划几个话题"、"这个行业值得深挖的问题有哪些"、"good ask"、"提问清单",或者在准备写行业分析/公众号文章/辩论/调研之前想先找到几个真正值得问的问题。即使用户只说"帮我想想XX行业能问点啥"或"XX行业有哪些值得讨论的问题",也应使用本 skill。本 skill 只产出问题和理由,不产出答案、不产出解决方案,如果用户还想要答案/深度分析,应在问题清单产出后提示可以用 multi-expert-analyzer、bug-hunter、red-blue-debate、industry-insight-writer 等 skill 继续深挖。
---
# 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
# [行业名称] · 好问题清单
## 问题一:[具体、有场景感的问题]
**类型**:狗皮膏药 / 近期热点
**理由**:[结合真实检索到的信息,说明这个问题为什么符合"真实、覆盖广、深刻、够得着、有话题性",点出至少两种可能的立场分歧]
## 问题二:...
(依此类推)
```
如果用户希望保存为文件,按照惯例输出到当前项目 markdown/ 目录,文件名使用"行业名+好问题清单+日期"的中文命名方式;如果只是想在对话中看一眼,直接在回复里给出即可,不必强行落盘。
## 注意事项
- **只给问题和理由,不给答案**。哪怕理由里提到"可能的解法方向",也只能点到为止(一两句话),不能展开成解决方案,一旦展开成解决方案就偏离了这个 skill 的定位,应该提示用户换用 multi-expert-analyzer / bug-hunter / red-blue-debate 等 skill 继续深挖。
- **拒绝黑白分明的问题**。写完之后自己读一遍每个问题,如果脑子里立刻蹦出一个"标准答案",说明这个问题不合格,要么换掉要么改写得更有张力。
- **拒绝假大空的问题**。同样自检一遍,如果这个问题大到"没法想象任何解法路径",也要换掉或者收窄。
- **理由必须落地到具体信息**,不能写"业内普遍认为"、"很多人反映"这种空泛表述而不给出具体依据——这正是"真实性"标准要卡住的东西。
- 涉及版权的检索结果转述时遵循一贯的规范:不逐字大段引用,用自己的话转述即可。
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when executing implementation plans with independent tasks in the current session