ljg-is git:20260801.fd5bcbfA

Immutable. This exact content never changes and is served at /api/v1/blob/c70abc10245490f8.

---
name: ljg-is
description: 用于发现一个目标真正完成的最小变化：把身份、边界、质量、优化量和实现放进括号，只保留极短的「谁或什么从 A 到 B」核心，再用可代入的操作实验讲明白并保存为经校验的 Org 笔记。USE WHEN 用户说 '/ljg-is', 'X 的本质是什么', '找出目标的本质', '本质定义', '最小功能', '到底把什么变成什么', or 要求区分限定词与核心。NOT FOR 追问原因（用 ljg-think）、寻找母题或因果结构（用 ljg-structure）、句中随口说「本质上」。
user_invocable: true
---

# 本质提炼器

输入一个目标，剥掉围绕它的限定条件，找到它不可再删的最小变化。

核心等式：

```text
完整定义 = （限定条件）本质
本质 = 最小的、有方向的状态变化
```

「安全、舒适、按需、付费」可以决定 Taxi 好不好、属于哪一类，却不是它最终完成的那件事。继续往后落，才是：

```text
（面向乘客，在出行场景中，按需、付费、安全、舒适地）把人从 A 点送到 B 点
                                                    ^^^^^^^^^^^^^^^^^^^^
                                                    本质
```

本质不承担所有说明。它只承担最短、不可再删的那一次变化。

## 三块各做一件事

- **剥离**：用带关键词的短 bullet 说明哪些内容为何退到括号，不写成一段拥挤的「限定」。
- **示例**：让读者以「你」进入一个场景，亲自完成操作、看到状态变化，再把操作逐字点回核心。
- **验证**：只保留「替换」与「删除」两条结论；其他检查属于内部推理，不增加阅读负担。

## 「问题」记录什么

`ljg-is` 永远寻找目的本质，不需要在成品里重复标注「问题类型：目的本质」。标题已经说明分析对象，「问题」只保留标题没有提供的两条信息：

```text
容易误认：最容易被当成本质的限定、优点或实现
真正问题：谁或什么，最终从什么状态到什么状态？
```

若用户追问它为何属于某一类别，类别差异仍放进括号；最后的核心仍回答目的本质。

## Workflow Routing

| Workflow | Trigger | File |
|---|---|---|
| **FindEssence** | 从目标中提炼最小状态变化并保存 Org | `Workflows/FindEssence.md` |

## 输出契约

默认先让核心落地，再让读者在一个普通场景里亲自走一遍：

```text
本质：把人从 A 点送到 B 点
完整：（面向乘客，在出行场景中，按需、付费、安全、舒适地）把人从 A 点送到 B 点
代入：你下班后站在公司门口，想回到家。
操作：你叫来一辆车，上车，抵达家门口后下车。
变化：你：公司门口 -> 家门口
点题：你刚刚真正完成的是「把人从 A 点送到 B 点」；车型、价格和舒适度只是实现与质量。
```

分析同时写入 `~/Documents/notes/{时间戳}--本质-{目标}__is.org`。只有用户明确说「只分析」「不落盘」或 `read-only` 时才不创建文件。

## Gotchas

- **不要把完整定义当本质。** 主体、场景、身份、边界、质量、速度、成本、风险和实现方式，通常都是括号里的限定条件。
- **不要用优点清单收尾。** 「安全、舒适、高效」描述做得怎样，不描述最终做了什么。
- **不要要求核心独占一个类别。** Taxi、公交车和专车可能共享「把人从 A 点送到 B 点」；这说明它们共享目的本质，不说明提炼失败。
- **不要停在抽象名词。** 「服务」「价值」「连接」「体验」「效率」没有方向，也没有完成态，不能作为核心。
- **不要把实现写进核心。** 车、App、算法、门店、合同、网络只是怎么做。换一种实现仍能完成同一变化，它就该进括号。
- **不要删掉承受变化的对象。** 「从 A 到 B」太空；「把人从 A 点送到 B 点」才保住目标和方向。
- **不要为了短而失真。** 极简不是字数竞赛。再删一个词会丢掉对象、起点、终点或变化方向时，就该停。
- **不要把示例写成旁观故事。** 必须让「你」执行具体动作、看见 `A -> B`，并指出哪一步就是核心。
- **不要让三个模块互相抢活。** 剥离解释限定，示例负责理解，验证只做最小闭环。
- **不要无故追问。** 给了清楚的目标就直接分析；只有连目标本身都缺失时才问一次。
- **不要把三个技能混用。** `ljg-is` 找「A 到 B」；`ljg-think` 追「为什么」；`ljg-structure` 找「什么关系反复生成结果」。

## Examples

**Taxi：把定义变成一次可执行的心理模拟**

```text
User: /ljg-is Taxi
本质：把人从 A 点送到 B 点
完整：（面向乘客，在出行场景中，按需、付费、安全、舒适地）把人从 A 点送到 B 点
代入：你下班后站在公司门口，目标是回到家。
操作：你叫车、上车、移动、下车；再想象把豪华车换成普通车。
变化：你：公司门口 -> 家门口
点题：只要位置变化完成，「把人从 A 点送到 B 点」就成立；车型改变的是实现，舒适度改变的是质量。
```

示例不是证明定义，而是把抽象句变成一次可重演的操作。读者做完后，应能不用术语回答：「我刚才究竟把什么，从哪里，变到了哪里？」