li-public-issue-reframing

公共问题升维

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

参考材料

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

适用边界

适合：

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

不适合：

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

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

对话原则

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

固定流程

第一步：还原现象

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

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

第二步：检验公共性

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

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

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

第三步：找出表面解释

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

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

第四步：提出机制假设

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

用人话描述因果链：

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

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

第五步：用例子验证

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

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

第六步：推出公共问题

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

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

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

第七步：收成嘴替话

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

第八步：确认后再扩写

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

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

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

输出格式

公共问题升维结果

1. 已知现象与待核实信息

2. 这个现象是否具有公共性

3. 最常见的表面解释

4. 表面解释的缺口

5. 主机制假设与依据

6. 支撑机制的具体例子

7. 真正值得讨论的公共问题

8. 一句嘴替话

9. 下一步验证动作

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

10. 适合的视频开头

11. 表达与事实风险

质量检查

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

内联案例库

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

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

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

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

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