chanpinhsd/agent/skills/ude_diagnosis/SKILL.md

name	description
UDE 诊断	基于 TOC 约束理论，从 VOC 消费者数据中提取并校验 UDE（不良效果），通过因果推导收敛到核心问题

UDE 诊断（Undesirable Effects Diagnosis）

什么是 UDE

UDE（Undesirable Effect）= 系统中当前正在发生的、阻碍系统实现目标的、可观测的负面现象。

UDE 是症状，不是病因，也不是解决方案。多个 UDE 之间的因果关系指向隐藏的核心问题——通常是一条不被质疑的政策或假设。

---

第一步：从 VOC 数据提取 UDE 候选

如果已有 VOC 研究数据（通过 voc_research 技能采集并标注），优先从标注数据中提取 UDE 候选：

数据来源映射

VOC 标注维度	对应 UDE 线索
tonbs_barrier（消费障碍）	🔴 最直接的 UDE 来源 — 消费者正在经历的阻碍
compensatory（代偿行为）	🟡 UDE 的佐证 — 消费者"不得不"的替代方案说明需求未被满足
sentiment = negative	🟡 负面情绪集中的领域可能隐藏 UDE
tonbs_need（未满足需求）	🟢 辅助验证 — 需求与障碍的对应关系

操作方法

如果有 VOC 研究 ID，通过 API 查询 Barrier 排名：

source ~/.copaw/workspaces/mafia-expert/.env
curl -sS "https://brand.brainwork.club/voc/api/research/${RESEARCH_ID}/chat" \
  -H "Content-Type: application/json" \
  -H "X-TikHub-Key: $TIKHUB_API_KEY" \
  -d '{"message": "请列出 tonbs_barrier 的 Top 10 分布及每个值的典型原声"}'

将返回的高频 Barrier 转写为 UDE 候选句。

无 VOC 数据时

直接引导用户从自身经验出发列举。不要用预设框架（如"战略/业绩/营销"等维度），而是问：

"站在你的客户/消费者的角度，他们当前持续承受着哪些让他们不满意、阻碍他们更好地完成任务的问题？尽可能多地列出来。"

---

第二步：UDE 陈述规范校验

每条 UDE 候选必须通过以下 7 条规范。不合格的退回修改，不能凑合使用。

#	规范	检查问题	常见错误 → 正确写法
1	完整陈述句	是否是完整的句子？	❌ "响应慢" → ✅ "客户投诉响应时间持续超过48小时"
2	现在时态	是否描述当前正在发生的事？	❌ "去年产能曾经不足" → ✅ "当前产能利用率低于70%"
3	只描述效果，不含原因	是否混入了因果分析？	❌ "因为人手不足所以发货延迟" → ✅ "发货持续延迟"
4	不是伪装的解决方案	是否暗藏了"应该做X"？	❌ "我们需要更多员工" → ✅ "生产产能不足以满足当前需求"
5	单一实体	一条只描述一个问题？	❌ "利润下降，而且客户流失" → 拆为两条
6	客观可验证	利益相关方能否达成共识？	❌ "我觉得客户不够忠诚" → ✅ "回头客比例同比下降15%"
7	在影响范围内	组织/团队可以采取行动改善？	❌ "全球经济下行" → 删除（不可控）

「伪装的解决方案」速查表

这是最常犯的错误——以下都是不合格的 UDE：

❌ 伪装的解决方案	✅ 正确的 UDE
"需要新的 ERP 系统"	"关键数据难以检索，决策持续滞后"
"应该增加广告预算"	"品牌知名度持续低于主要竞品"
"需要引进高端人才"	"核心技术岗位长期空缺，项目交付延期"
"应该做消费者调研"	"产品开发决策缺乏消费者需求依据"
"需要开拓线上渠道"	"线下渠道增速放缓，新客获取成本持续攀升"

输出格式

对每条 UDE 输出校验结果：

#### UDE-[编号]：[UDE 描述]

| 规范 | 通过？ | 备注 |
|------|-------|------|
| 1. 完整陈述句 | ✅/❌ | [如不通过，说明原因和修改建议] |
| 2. 现在时态 | ✅/❌ | |
| 3. 不含原因 | ✅/❌ | |
| 4. 不是方案 | ✅/❌ | |
| 5. 单一实体 | ✅/❌ | |
| 6. 客观可验证 | ✅/❌ | |
| 7. 影响范围内 | ✅/❌ | |

**结论**：✅ 合格 / ❌ 需修改：[修改建议]

---

第三步：构建因果链（简版 CRT）

将校验合格的 UDE（建议精简到 5-10 条）用「因为…所以…」链接，寻找因果关系。

方法

1. 取任意两条 UDE，问：「A 是否会导致 B？B 是否会导致 A？还是两者没有直接关系？」
2. 用箭头标注因果方向：A → B 表示"因为 A，所以 B"
3. 找到被最多箭头指向的 UDE = 上层效果（症状）
4. 找到发出最多箭头的 UDE = 候选核心问题（根因方向）

朗读测试

用以下句式朗读每条因果链：

• 从下到上：「因为 [原因 UDE]，所以 [效果 UDE]」
• 从上到下：「[效果 UDE] 是因为 [原因 UDE]」

如果听起来不合逻辑，检查是否缺少中间环节或隐含假设。

输出格式

### 因果链

UDE-3（根因方向）
  → UDE-1
    → UDE-5
    → UDE-7（上层症状）
  → UDE-2
    → UDE-6（上层症状）

### 核心问题候选
UDE-3：[描述] — 它直接或间接导致了 [X] 条其他 UDE

---

第四步：核心问题验收（CLR 检验）

对核心问题候选进行 3 项严格验收：

① 充分性检验

• 该原因单独足够导致那些效果吗？
• 还需要什么其他条件同时成立？
• 如果需要，补充缺失的联合原因

② 预测效果检验

• 如果这个核心问题真的存在，还应该产生什么其他效果？
• 那些预测的效果在现实中存在吗？
• 存在 → 验证通过；不存在 → 因果关系可能有误

③ 同义反复检验

• 核心问题是不是在用不同的话重复某个 UDE？
• 如果是 → 不是真正的核心问题，需要继续向下追溯

输出格式

### 核心问题验收

**核心问题**：[描述]

| 检验项 | 结果 | 说明 |
|--------|------|------|
| 充分性 | ✅/❌ | [该原因是否足够导致那些效果] |
| 预测效果 | ✅/❌ | [预测的其他效果是否存在] |
| 同义反复 | ✅/❌ | [是否只是换了说法] |

**验收结论**：✅ 确认为核心问题 / ❌ 需要继续追溯

---

完成标志

当以下条件全部满足时，此技能完成：

• UDE 候选已从 VOC 数据和/或用户经验中收集
• 所有 UDE 通过 7 条陈述规范校验
• 精简到 5-10 条合格 UDE
• 构建了因果链，识别出核心问题候选
• 核心问题通过 CLR 三项验收
• 用户确认核心问题

完成后，将核心问题和 UDE 清单传递给下一步：冲突图构建。

关键提醒：核心问题的筛选标准是「导致最多 UDE 的根因」，不是「跟我们的产品最相关的」。产品/方案如何注入到核心问题上，是后续冲突图和惯例打破要解决的事。