当笑话不好笑或幽默显得生硬时，用系统化诊断方法定位并改进笑点

把笑话当作可工程化的连接系统，诊断幽默失效的原因并给出具体改进方案

适用场景

解决思路

1. 把幽默视为概念、框架或参照点之间连接的建立与解决，将笑话当作具有可测量属性的系统来分析
2. 检查九个系统属性是否失衡：连接距离（语义差距，太明显则无聊、太隐晦则困惑）、连接密度（强化连接的数量，单线笑话显得单薄）、解决满足感（理解后的认知奖励，牵强或不合逻辑的包袱会失败）、具体性优化（细节精度，泛泛描述缺乏冲击力）、反讽层次（嵌套矛盾，扁平反讽缺乏深度）、观众共创空间（留给观众完成连接的空间，过度解释会扼杀笑声）、压缩优化（连接与字数之比，臃肿铺垫会失去势头）、连接韧性（跨知识领域是否有效，依赖特定知识则失败）、真实性共鸣（与创作者声音的一致性，生硬或通用则失败）
3. 诊断状态 H1 太明显：症状是可预测、观众提前看到包袱、连接距离太短；问自己什么意外的框架转换能增加惊喜；干预方式是延长连接距离同时保持连贯
4. 诊断状态 H2 太隐晦：症状是观众听不懂、引用太专业、连接差距太大；问自己什么脚手架能帮助理解而不过度解释；干预方式是添加上下文线索或创建平行连接路径
5. 诊断状态 H3 低密度：症状是笑话单薄、单一连接点、没有层次；问自己哪些元素能在多个框架中发挥多重功能；干预方式是添加循环反讽、递归连接或嵌套荒谬
6. 诊断状态 H4 过度解释：症状是包袱被陈述而非暗示、没有观众参与空间；问自己保留连接的前提下能删掉什么；干预方式是策略性省略——在完整表达之前稍早结束
7. 诊断状态 H5 声音生硬：症状是语言不自然、笑话不符合创作者视角；问自己这个人会如何自然地描述这个情境；干预方式是让语言和框架适配真实的声音模式
8. 诊断状态 H6 压缩臃肿：症状是铺垫太长、包袱前失去势头、连接与字数之比低；问自己哪些元素对核心连接没有贡献；干预方式是移除解释性元素，用隐含替代明确
9. 按六步诊断流程操作：倾听症状（具体哪里没落地）、追踪连接路径（意图连接在哪里）、测量属性（哪些系统属性失衡）、识别状态（匹配上述诊断状态）、推荐干预（具体调整）、演示转化（如有帮助展示前后对比）
10. 运用关键连接类型：矛盾（共享框架内元素相互对立）、框架转换（在不同框架下重新诠释）、双联（连接先前无关的概念框架）、模式违反（建立然后打破认知模式）、隐含连接（故意不说明以让观众完成）
11. 用密度增强模式提升连接密度：循环反讽（元素形成矛盾的闭环反馈）、递归连接（自我强化的连接）、多重角色分配（元素在不同框架中发挥不同功能）、自指系统（笑话结构映射自身内容）、嵌套荒谬（层层递增的不切实际相互叠加）
12. 运用反讽梯度：高投入→低重要性、高精度→错误目标、完美执行→不必要任务、复杂系统→简单需求
13. 用压缩技巧减少臃肿：保留服务多重连接功能的元素、移除解释而非创造连接的元素、用结构性暗示替代明确陈述、保持能增强多重连接的具体性、为观众共创创造策略性空间
14. 用评估矩阵检查：连接距离（低效：太明显或太隐晦；高效：意外但可理解）、连接连贯性（低效：牵强或不合逻辑；高效：清晰、令人满意的解决）、连接密度（低效：单一线性连接；高效：多重强化连接）、认知平衡（低效：太简单或太复杂；高效：适当的挑战）、完成缺口（低效：过度解释或不可能；高效：可实现的共创）、压缩（低效：连接与字数之比低；高效：连接与字数之比高）、韧性（低效：缺乏特定知识就失败；高效：跨领域有效）、真实性（低效：通用或生硬的声音；高效：自然的视角）
15. 参考示例转化：原句“告诉孩子看电视会烂脑子的婴儿潮一代，现在用有线电视新闻烂了自己的脑子”属于低密度加臃肿；增强版“我那限制我们屏幕时间到‘30分钟，否则你脑子会变成布丁’的婴儿潮老爸，现在需要我给他的新闻应用做儿童锁，因为又一次凌晨3点的补剂恐慌购买，来保护那个他正积极证明不存在的脑子”增加了角色反转、循环系统、具体细节、隐含连接和反讽梯度
16. 把该框架应用到笑话之外的场景：创意写作（隐喻、类比）、广告（难忘联想）、公开演讲（有冲击力的轶事）、用户体验（直观连接）、叙事设计（令人满意的故事节拍）
17. 按输出持久化要求操作：检查项目中的 context/output-config.md，找到本技能条目，未找到则询问用户保存位置，建议 writing/humor/ 或 explorations/writing/；主要输出包括诊断状态、属性分析、转化前后版本及理由、连接映射；文件命名模式为 {project-name}-humor-{date}.md
18. 用 Oracle 验证：可高置信度验证状态识别和属性测量，中置信度验证连接映射；幽默是否落地、声音是否真实、语境是否合适需要人类判断；Oracle 无法评估幽默是否会落地或预测观众笑声
19. 建立反馈循环：按 context/output-config.md 保存诊断状态、属性分析和转化；检查该项目先前的幽默工作，基于对这位创作者和观众有效的经验继续构建，失败的笑话为属性校准提供信息
20. 避免反模式：不要过度工程化随意幽默（把完整诊断框架用于每个随口俏皮话，应保留给有意创作的材料）；不要不惜一切代价追求密度（添加连接层直到笑话崩溃，应优化连接与困惑之比而非最大连接数）；不要解释隐含内容（让所有连接明确以确保观众理解，应信任观众，在完整表达前稍早结束，太难理解则加脚手架而非解释）；不要抹除声音（重写成“最优”结构却剥离创作者真实视角，应在创作者声音内优化）；不要单一指标优化（只关注一个属性而忽略对其他属性的影响，应诊断真正的瓶颈并监控相关属性）

适用边界 · 注意事项

• 随意的即兴幽默或日常俏皮话——过度分析会破坏幽默的轻松感和自然流动
• 文化敏感语境下的幽默——应转交 sensitivity-check 处理
• 需要发展个人幽默声音的场景——应转交 voice-analysis 处理