关于 joke-engineering
joke-engineering 是面向创作者的诊断技能，用于系统分析和修改笑话。它从意外感、清晰度、连接密度和精简度等属性检查幽默，并可展示修改前后的版本。
主要功能
- 01诊断六种常见幽默问题
- 02分析九项笑话属性
- 03梳理概念间的连接
- 04提出针对性修改建议
- 05展示修改前后版本
- 06将诊断结果保存到文件
适用场景
- 01找出笑话显得可预测或晦涩的原因
- 02缩短解释过多的铺垫
- 03在保持清晰的同时增加层次
- 04修改素材以贴合创作者的表达风格
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/joke-engineering确认已加载。
详细介绍
笑点工程：诊断技能
诊断幽默为何不起作用，并帮助设计更有效的笑话。你的职责是将笑话结构分析为连接系统，并提出具体的改进建议。
核心原则
幽默源于概念、框架或参照点之间连接的建立与化解。
笑话是一个具有可衡量属性的系统。幽默失效时，通常是一个或多个系统属性校准不当。这项技能有助于找出哪些属性需要调整。
九项系统属性
有效的笑话需要平衡以下相互关联的属性：
| 属性 | 描述 | 失效时的表现 |
|---|---|---|
| 连接距离 | 相连元素之间的语义差距 | 过于明显（乏味）或过于晦涩（令人困惑） |
| 连接密度 | 相互强化的连接数量 | 只有一条线索的笑话显得单薄 |
| 化解满足感 | “领会笑点”带来的认知奖励 | 包袱生硬或不合逻辑 |
| 具体性优化 | 细节的精确程度 | 泛泛的描述缺乏冲击力 |
| 反讽层次 | 层层嵌套的矛盾 | 反讽单薄，缺乏深度 |
| 受众共同创作 | 留给受众自行补全连接的空间 | 解释过多的笑话会扼杀笑声 |
| 压缩优化 | 连接与字数的比例 | 铺垫冗长会失去节奏 |
| 连接韧性 | 在不同知识领域中都能成立 | 受众缺少特定背景知识时便无法成立 |
| 真实感共鸣 | 与创作者个人风格的契合度 | 显得生硬或泛泛而谈 |
诊断状态
分析幽默时，判断适用以下哪种状态：
状态 H1：过于明显
症状： 笑话容易预测；受众提前猜到包袱；连接距离过短。 关键问题： 可以如何转换框架，增加意外感？ 干预措施： 拉长连接距离，同时保持连贯。
状态 H2：过于晦涩
症状： 受众听不懂；引用过于专业；连接差距过大。 关键问题： 如何在不过度解释的情况下提供理解支架？ 干预措施： 增加语境线索，或构建平行的连接路径。
状态 H3：密度不足
症状： 笑话显得单薄；只有一个连接点；缺乏层次。 关键问题： 哪些元素可以在不同框架中发挥多重作用？ 干预措施： 增加循环反讽、递归连接或嵌套荒诞。
状态 H4：解释过度
症状： 包袱被直接说出，而非暗示；没有留给受众参与的空间。 关键问题： 保留连接的同时，可以删去哪些内容？ 干预措施： 策略性省略——在完全说透之前稍作收尾。
状态 H5：风格生硬
症状： 用语不自然；笑话与创作者的视角不符。 关键问题： 这个人自然会如何描述这种情况？ 干预措施： 根据创作者真实的语言与表达框架调整措辞。
状态 H6：压缩不足
症状： 铺垫太长；包袱出现前节奏已散；连接与字数的比例偏低。 关键问题： 哪些内容与核心连接无关？ 干预措施： 删除解释性内容；将明说改为暗示。
诊断流程
当有人提出一个不奏效的笑话时：
- 倾听症状 - 具体来说，哪里没有产生效果？
- 追踪连接路径 - 预期的连接在哪里？
- 衡量属性 - 哪些系统属性校准不当？
- 判断状态 - 对照上述诊断状态进行匹配
- 提出干预建议 - 给出具体的调整方法
- 展示改写效果 - 如有帮助，展示修改前后的版本
关键连接类型
- 矛盾：共享框架中的元素彼此对立
- 框架转换：在不同框架下重新诠释
- 双重联想：连接此前互不相关的概念框架
- 模式违背：先建立认知模式，再打破它
- 隐含连接：刻意不明说，留待受众补全
提升密度的模式
提升连接密度时：
- 循环反讽：元素形成封闭的矛盾反馈循环
- 递归连接：会自我强化的连接
- 多重角色分配：元素在不同框架中承担不同功能
- 自指系统：笑话结构映照自身内容
- 层叠荒诞：不切实际的程度逐层递增并相互叠加
反讽梯度
最有效的笑话会让元素的重要性呈现有结构的变化：
- 努力巨大 → 重要性极低
- 精度极高 → 目标错误
- 执行完美 → 任务多余
- 系统复杂 → 需求简单
精简技巧
减少冗余时：
- 保留同时承担多种连接功能的元素
- 删除只做解释、不创造连接的元素
- 用结构暗示替代明确陈述
- 保留能增强多个连接的具体细节
- 为受众共同创作留出策略性空间
评估矩阵
| 指标 | 效果较差 | 效果较好 |
|---|---|---|
| 连接距离 | 过于明显或过于晦涩 | 出人意料但易于理解 |
| 连接连贯性 | 生硬或不合逻辑 | 清晰且令人满意的收束 |
| 连接密度 | 单一、线性的连接 | 多重且相互强化的连接 |
| 认知平衡 | 过于简单或复杂 | 挑战程度适当 |
| 补全空间 | 解释过度或无法补全 | 可以共同创作 |
| 精简度 | 连接与字数之比低 | 连接与字数之比高 |
| 韧性 | 离开特定知识就无法成立 | 跨领域依然有效 |
| 真实感 | 声音泛泛或刻意 | 视角自然 |
示例改写
原文（状态 H3 + H6：密度低、冗余）
“那些告诉孩子看电视会腐蚀大脑的婴儿潮一代，如今被有线电视新闻腐蚀了自己的大脑。”
**分析：**简单的虚伪连接，只有一条线索，精简度一般。
增强版（高密度）
“我那位婴儿潮一代的爸爸，曾把我们的屏幕时间限制为‘30 分钟，不然你的大脑就会变成布丁’，如今却要我帮他把新闻应用设置成儿童安全模式——就在他凌晨 3 点又一次恐慌性购买补充剂之后，好保护他正在用行动证明并不存在的大脑。”
改进之处：
- 加入角色反转（家长对孩子的限制倒置）
- 构建循环系统（担心大脑 → 媒体 → 补充剂 → 证明大脑）
- 具体细节（“凌晨 3 点”“设置成儿童安全模式”）增加真实感
- 隐含连接（是哪个新闻频道）留给受众共同创作
- 反讽梯度（保护大脑的同时证明它并不存在）
笑话之外的应用
此框架适用于：
- 创意写作（隐喻、类比）
- 广告（令人难忘的联想）
- 公开演讲（有感染力的轶事）
- 用户体验（直观的连接）
- 叙事设计（令人满意的故事节拍）
输出持久化
输出位置查找
- 检查项目中是否存在
context/output-config.md - 如果存在，查找此技能对应的条目
- 如果不存在，询问用户：“幽默相关内容应该保存在哪里？”
- 建议：
writing/humor/或explorations/writing/
主要输出
- 诊断状态——适用哪种幽默状态
- 属性分析——校准失当的系统属性
- 改写——改写前后版本及其理由
- 连接映射——连接类型及其密度
文件命名
格式：{project-name}-humor-{date}.md
验证（Oracle）
此技能可以验证的内容
- 状态识别 - 适用哪种诊断状态？（高置信度）
- 属性测量 - 哪些属性需要调整？（高置信度）
- 连接映射 - 存在哪些连接类型？（中等置信度）
需要人工判断的内容
- 笑点是否成立 - 观众是否真的会觉得好笑？
- 声音是否真实 - 听起来像创作者本人吗？
- 语境是否恰当 - 这种幽默是否适合当前情境？
Oracle 的局限
- 无法评估幽默是否能引发笑声
- 无法预测观众是否会笑
反馈循环
会话持久化
- 输出位置： 请参阅
context/output-config.md - 保存内容： 诊断状态、属性分析、转换
- 命名模式：
{project-name}-humor-{date}.md
跨会话学习
- 检查此项目之前是否有幽默创作
- 借鉴适用于这位创作者／受众的方法
- 失败的笑话可为属性校准提供参考
设计约束
此技能的假设
- 有意创作幽默（而非日常交谈）
- 有改进价值的素材（而非随口一说的俏皮话）
- 创作者希望进行系统分析
此技能不处理的内容
- 即兴妙语 - 过多分析会扼杀灵感
- 文化幽默语境 - 转交给：sensitivity-check
- 声音塑造 - 转交给：voice-analysis
性能退化信号
- 对日常幽默过度设计
- 不惜一切追求密度（笑话堆砌过多）
- 声音被抹去（优化导致失去真实性）
推理要求
标准推理
- 诊断单个笑话
- 基本属性测量
- 简单转换
扩展推理（ultrathink）
- 段子或整套表演的分析 - [原因：笑话之间会相互作用并逐步铺垫]
- 连接密度优化 - [原因：需要平衡多个连接层次]
- 声音整合 - [原因：在转换过程中保持真实性]
触发短语： “分析整套表演”“最大化密度”“保留我的声音”
执行策略
顺序执行（默认）
- 先诊断，再转换
- 先测量属性，再调整
- 先转换，再评估
可并行执行
- 分析多个互不相关的笑话
- 测试不同的转换方法
子 Agent 候选
| 任务 | Agent 类型 | 何时启动 |
|---|---|---|
| 声音分析 | 通用型 | 需要保留创作者的真实性时 |
| 受众研究 | 通用型 | 需要针对特定受众进行校准时 |
上下文管理
大致 Token 占用
- 技能基础： 约 3k tokens（属性 + 状态 + 技巧）
- 包含示例： 约 4k tokens
- 包含所有应用： 约 4.5k tokens
上下文优化
- 聚焦于相关的诊断状态
- 属性是核心内容，始终需要
- 应用部分为可选内容
上下文紧张时
- 优先保留：当前状态、相关属性
- 延后处理：完整状态列表、所有技巧
- 删除：应用部分、评估矩阵
反模式
1. 对日常幽默过度设计
模式： 对每句随口一说的俏皮话或日常妙语都套用完整的诊断框架。 失败原因： 幽默往往依靠即兴发挥和自然流畅。过度分析会破坏日常幽默赖以奏效的轻松感。并非所有内容都需要系统改进。 解决方法： 将系统诊断留给有意创作的素材，例如写作、演讲和表演。让日常交谈保持随意。
2. 不惜一切追求密度
模式： 不断增加连接层次，直到笑话不堪重负、难以成立。 失败原因： 高密度要求观众同时追踪多个连接。堆砌过多的笑话会增加太多认知负担——理解成本超过揭示笑点带来的回报。 解决方法： 优化最高的连接与困惑比，而非追求最多连接。有些出色的笑话只有一个一针见血的连接。
3. 解释隐含内容
模式： 把所有联系都明说出来，确保受众“听懂”。 为何无效： 化解包袱的满足感，来自受众自己完成这种联想。解释笑话会抹去那种“恍然大悟”的瞬间，而幽默的回报正源于此。 改进方法： 信任受众。不要把话说得太透。如果联想太难理解，就增加铺垫（情境线索），而不是直接解释。
4. 抹去个人风格
模式： 把笑话改写成“最优”结构，却剥去创作者真实的视角。 为何无效： 幽默具有个人色彩。一个在技术上完美、听起来却不像表演者本人的笑话，会显得虚假。即使受众说不清原因，也能察觉不真诚。 改进方法： 保留鲜明的语言习惯、独特的视角和表达节奏。在创作者的个人风格之内优化，而不是不顾其风格地优化。
5. 单一指标优化
模式： 专注于某个特性（如精简度），却忽略它对其他特性的影响。 为何无效： 九种特性相互依存。最大限度地精简，可能会破坏联想的韧性。增加距离感，可能会大幅降低化解包袱的满足感。 改进方法： 找出真正的瓶颈特性。调整时监测对相关特性的影响。
集成
输入（为此技能提供支持）
| 技能 | 提供内容 |
|---|---|
| voice-analysis | 了解创作者真实的语言风格模式 |
| dialogue | 角色语言风格和对话节奏技巧 |
输出（此技能提供支持）
| 技能 | 提供内容 |
|---|---|
| speech-adaptation | 为演讲增添更出色的幽默元素 |
| dialogue | 喜剧对话构建技巧 |
| prose-style | 书面散文中的机智表达和喜剧节奏 |
互补技能
| 技能 | 关系 |
|---|---|
| cliche-transcendence | 两者都运用意想不到的联系，但 cliche-transcendence 专注于避免可预测的模式，而 joke-engineering 则构建出人意料的模式 |
| brainstorming | Brainstorming 生成原始素材，再由 joke-engineering 将其打磨成有效的幽默 |