---
name: li-public-issue-reframing
description: |
  公共问题升维与内容选题诊断。把一个私人、模糊的“我觉得不对劲”，还原成可观察现象，检验它是否具有公共性，挑战表面解释，找到更底层且有证据的机制，最后形成值得讨论的公共问题和一句可复述的嘴替话。用户说“这个现象值不值得讲”“我觉得不对劲但说不明白”“这事太私人了，怎么让更多人关心”“帮我把这个问题讲大”“个体现象怎么变成公共话题”“现象背后的机制是什么”时使用。不用于只有标题润色、纯情绪发泄、事实核查不足却要求强行拔高，或已经明确的公共事件复述。
---

# 公共问题升维

把“我觉得不对劲”的个体感受，推成有事实、有解释、能让更多人代入的公共问题。先判断题目是否成立，再谈如何表达；不要为了显得深刻而强行拔高。

## 参考材料

- 第一次使用、需要校准推导方式或查看完整示例时，读取 `references/case-study.md`。
- 用户信息充分时直接执行，不必读取案例。
- 案例仅用于理解方法，不得套用其中的现象、平台、机制或结论。

## 适用边界

适合：

- 用户看到一个具体事件、画面、评论区或行业现象，但说不清哪里不对。
- 话题现在过于私人、零散或局部，不知道别人为什么要关心。
- 用户已有直觉解释，但怀疑它只解释了表面。
- 用户想做“嘴替型”内容，需要找到可被更多人共同感知的问题。

不适合：

- 用户已有完整结论，只需润色、起标题或改开头。
- 只有情绪和立场，没有可核实的现象。
- 为追求传播，把单一个案硬说成普遍规律。
- 对公共事件中的人物动机、违法行为或因果关系作无证据断言。

涉及真人、企业、平台或公共事件时，把已知事实、用户观察和推断分开；证据不足就保留为待验证解释。

## 对话原则

1. 每次只问当前最影响判断的一个问题，已有信息不重复问。
2. 先抓具体观察，再检查公共性；公共性不成立时直接说明，不继续拔高。
3. 先列常见解释，再指出它解释不了什么；不要为了反常识而反常识。
4. 机制必须能解释多个具体细节，不能只是换一个更大的抽象词。
5. 形成暂定判断后，先让用户确认最不认同的部分，再生成完整内容框架。
6. 用户只要诊断时，停在诊断结果；只有用户继续要求时才写开头或整稿。

## 固定流程

### 第一步：还原现象

让用户说出触发感受的具体事件：谁做了什么、出现了什么变化、哪句话或哪组对比最反常。

如果用户只有“很怪、很虚伪、大家疯了”等评价，追问最近看到的一个具体画面或行为，不接受评价代替事实。

### 第二步：检验公共性

判断这个现象是否超出个人遭遇。至少满足下面一项，才继续升维：

- 多个人在相似情境中经历过。
- 同一机制在不同对象上反复出现。
- 即使没经历过，目标受众也能立刻识别其影响。

如果只有一个孤立案例，输出“目前不足以推成公共问题”，并说明还缺哪类对照或证据。

### 第三步：找出表面解释

用一句话写出用户和多数人最容易接受的解释。再问：它能解释哪些细节，又解释不了哪些细节？

只有当表面解释确实存在解释缺口，才进入下一步。不要先预设它一定是错的。

### 第四步：提出机制假设

从传播、算法、平台规则、商业激励、群体身份、情绪补偿、文化习惯或其他相关方向中，只选一个最能解释现象的主机制。

用人话描述因果链：

> 因为 {条件／激励}，人们更容易做出 {行为}，于是出现 {可观察结果}。

标明这是已证事实、用户观察还是工作假设。概念只能作为结尾标签，不能替代解释。

### 第五步：用例子验证

至少寻找两个具体细节或对照，检查主机制能否同时解释它们。例子可以来自用户提供的事实；需要外部事实时先核查来源，不得编造。

若机制只能解释一个例子，退回上一步修改，不急着下结论。

### 第六步：推出公共问题

把“某个人／某件事为什么这样”改写成“什么条件正在让一类人反复遇到什么问题”。

合格的公共问题应同时具备：

- 对象不再只指向单一个案。
- 与普通人的经验、选择或利益有关。
- 仍能被前面的事实和机制支撑。

### 第七步：收成嘴替话

用一句短、清楚、可复述的话压缩结论。它应让人拿走一个新判断，不靠辱骂、夸张或虚假普遍化制造力度。

### 第八步：确认后再扩写

先给用户看“现象—表面解释—主机制—公共问题—嘴替话”的暂定链路，并问：

> 这条链路里，你最不同意哪一步？

用户确认或补充事实后，再按需生成视频开头、内容结构或风险提示。

## 输出格式

# 公共问题升维结果

## 1. 已知现象与待核实信息
## 2. 这个现象是否具有公共性
## 3. 最常见的表面解释
## 4. 表面解释的缺口
## 5. 主机制假设与依据
## 6. 支撑机制的具体例子
## 7. 真正值得讨论的公共问题
## 8. 一句嘴替话
## 9. 下一步验证动作

只有用户需要继续创作时再补：

## 10. 适合的视频开头
## 11. 表达与事实风险

## 质量检查

- 是否从具体观察开始，而不是从抽象概念开始？
- 是否证明现象具有公共性，而不是把个人遭遇冒充普遍规律？
- 是否公平呈现表面解释，并指出真实的解释缺口？
- 主机制是否能解释至少两个具体细节或对照？
- 是否区分事实、观察与推断？
- 公共问题是否与更多人的经验、选择或利益有关？
- 嘴替话是否准确、可复述，并且没有虚假拔高？
- 是否在用户确认诊断前避免直接生成整稿？

## 内联案例库

### 典型案例：会员规则变化引发集体不满

> 用户观察到一家平台取消某项会员权益后，评论区不只在争论几元钱，而是在集中讲述过去多次规则变化。Skill 先确认这不是单个用户的退款纠纷，再比较“用户只是贪便宜”的表面解释与连续规则变化的事实，暂定主机制为“平台反复改变承诺，导致用户无法形成稳定预期”，最后把个案推成“数字服务为什么不断透支用户对长期承诺的信任”。

- 结构要点：具体规则变化是事实，信任被透支是待验证机制；用多次变化和多位用户的相似反应支撑，不从一条评论直接推出群体结论。

### 反面案例：从一条差评推出行业真相

- 问题：看到一位顾客投诉，就直接写“整个行业都在欺骗消费者”，既没有公共性证据，也没有机制和对照。
- 处理：先核查是否存在重复案例、共同条件和可验证影响；如果没有，就保留为个案，不强行升维。