Back to Details

ljg-is

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

本质提炼器

Essence Extractor

输入一个目标，剥掉围绕它的限定条件，找到它不可再删的最小变化。这个变化是唯一中心；The One 只把它压成可迁移结构，不另找一个更玄的「本质」。
核心等式：
text
完整定义 = （限定条件）本质
本质 = 最小的、有方向的状态变化
The One = 本质的最小可迁移结构式
「安全、舒适、按需、付费」可以决定 Taxi 好不好、属于哪一类，却不是它最终完成的那件事。继续往后落，才是：
text
（面向乘客，在出行场景中，按需、付费、安全、舒适地）把人从 A 点送到 B 点
                                                    ^^^^^^^^^^^^^^^^^^^^
                                                    本质
本质不承担所有说明。它只承担最短、不可再删的那一次变化。
Input a target, strip off the qualifying conditions around it, and find the minimal change that cannot be further deleted. This change is the sole center; The One only compresses it into a migratable structure, not seeking a more abstract "essence".
Core Equation:
text
Complete Definition = (Qualifying Conditions) Essence
Essence = Minimal, directional state change
The One = Minimal migratable structural formula of essence
"Safe, comfortable, on-demand, paid" can determine how good a Taxi is and which category it belongs to, but it is not the ultimate thing it accomplishes. Dig deeper, and you get:
text
(For passengers, in travel scenarios, on-demand, paid, safe, and comfortable) move people from point A to point B
                                                    ^^^^^^^^^^^^^^^^^^^^
                                                    Essence
Essence does not bear all explanatory responsibilities. It only carries the shortest, non-deletable change.

四块各做一件事

Four Modules, Each with One Task

  • 剥离：用带关键词的短 bullet 说明哪些内容为何退到括号，不写成一段拥挤的「限定」。
  • 示例：让读者以「你」进入一个场景，亲自完成操作、看到状态变化，再把操作逐字点回核心。
  • 结构迁移：先用最弱但足够的符号关系压缩同一核心，再到远域逐项映射对象、起点、终点、方向与完成态。
  • 验证：只保留「替换」与「删除」两条结论；其他检查属于内部推理，不增加阅读负担。
  • Stripping: Use short bullet points with keywords to explain which content is moved to parentheses and why, instead of writing a crowded paragraph of "qualifications".
  • Example: Let the reader enter a scenario as "you", personally complete operations, observe state changes, and then map the operations back to the core word by word.
  • Structural Migration: First compress the same core with the weakest yet sufficient symbolic relationship, then map the object, starting point, end point, direction, and completion state item by item in a distant domain.
  • Validation: Only retain the two conclusions of "replacement" and "deletion"; other checks are internal reasoning and do not add reading burden.

「问题」记录什么

What to Record in "Issue"

ljg-is
永远寻找目的本质，不需要在成品里重复标注「问题类型：目的本质」。标题已经说明分析对象，「问题」只保留标题没有提供的两条信息：
text
容易误认：最容易被当成本质的限定、优点或实现
真正问题：谁或什么，最终从什么状态到什么状态？
若用户追问它为何属于某一类别，类别差异仍放进括号；最后的核心仍回答目的本质。
ljg-is
always seeks the essence of purpose, so there is no need to repeatedly mark "Issue Type: Purpose Essence" in the finished product. The title already indicates the analysis object; "Issue" only retains two pieces of information not provided by the title:
text
Easy Misidentification: The qualifications, advantages, or implementations most easily mistaken as essence
Real Issue: Who or what, ultimately changes from what state to what state?
If the user asks why it belongs to a certain category, the category differences are still put in parentheses; the final core still answers the essence of purpose.

Workflow Routing

Workflow Routing

WorkflowTriggerFile
FindEssence从目标中提炼最小状态变化并保存 Org
Workflows/FindEssence.md
WorkflowTriggerFile
FindEssenceExtract minimal state change from target and save as Org
Workflows/FindEssence.md

输出契约

Output Contract

默认先让核心落地，再让读者在一个普通场景里亲自走一遍：
text
本质：把人从 A 点送到 B 点
完整：（面向乘客，在出行场景中，按需、付费、安全、舒适地）把人从 A 点送到 B 点
代入：你下班后站在公司门口，想回到家。
操作：你叫来一辆车，上车，抵达家门口后下车。
变化：你：公司门口 -> 家门口
点题：你刚刚真正完成的是「把人从 A 点送到 B 点」；车型、价格和舒适度只是实现与质量。
结构式：(X, S0) -> (X, S1)
变量：X=承受变化的对象；S0=起点状态；S1=完成状态
迁移：文件：目录 A -> 目录 B；对象、方向和完成测试逐项对应
边界：只迁移「对象的位置改变」；不迁移乘客身份、付费关系、舒适度或运输载体
分析同时写入 
~/Documents/notes/{时间戳}--本质-{目标}__is.org
。只有用户明确说「只分析」「不落盘」或 
read-only
时才不创建文件。
By default, first ground the core, then let the reader go through an ordinary scenario personally:
text
Essence: Move people from point A to point B
Complete: (For passengers, in travel scenarios, on-demand, paid, safe, and comfortable) move people from point A to point B
Scenario: You stand at the company gate after work, wanting to go home.
Operation: You call a car, get in, and get off after arriving at your doorstep.
Change: You: Company gate -> Home doorstep
Pointing out the core: What you truly accomplished just now is "move people from point A to point B"; vehicle type, price, and comfort are just implementations and quality metrics.
Structural Formula: (X, S0) -> (X, S1)
Variables: X=Object undergoing change; S0=Starting state; S1=Completed state
Migration: File: Download directory -> Archive directory; object, direction, and completion test correspond item by item
Boundary: Only migrate "change of object's position"; do not migrate passenger identity, payment relationship, comfort, or transportation carrier
The analysis is simultaneously written to 
~/Documents/notes/{timestamp}--Essence-{Target}__is.org
. Only when the user explicitly says "analyze only", "do not save" or 
read-only
will no file be created.

Gotchas

Gotchas

  • 不要把完整定义当本质。 主体、场景、身份、边界、质量、速度、成本、风险和实现方式，通常都是括号里的限定条件。
  • 不要用优点清单收尾。 「安全、舒适、高效」描述做得怎样，不描述最终做了什么。
  • 不要要求核心独占一个类别。 Taxi、公交车和专车可能共享「把人从 A 点送到 B 点」；这说明它们共享目的本质，不说明提炼失败。
  • 不要停在抽象名词。 「服务」「价值」「连接」「体验」「效率」没有方向，也没有完成态，不能作为核心。
  • 不要把实现写进核心。 车、App、算法、门店、合同、网络只是怎么做。换一种实现仍能完成同一变化，它就该进括号。
  • 不要删掉承受变化的对象。 「从 A 到 B」太空；「把人从 A 点送到 B 点」才保住目标和方向。
  • 不要为了短而失真。 极简不是字数竞赛。再删一个词会丢掉对象、起点、终点或变化方向时，就该停。
  • 不要把示例写成旁观故事。 必须让「你」执行具体动作、看见 
    A -> B
    ，并指出哪一步就是核心。
  • 不要让四个模块互相抢活。 剥离解释限定，示例负责近场理解，结构迁移负责远场压力测试，验证只做最小闭环。
  • 不要为了显得深而伪数学。 结构式是关系签名，不是经验定律；
    (X, S0) -> (X, S1)
    足够时，不添加积分、求和或比例符号。
  • 不要把相似当同构。 迁移必须逐项对齐对象、起点、终点、方向和完成测试，并明确「只迁移什么 / 不迁移什么」。
  • 不要让迁移反客为主。 远域案例用于检验结构；若它迫使核心改成另一个问题，回到原目标重写结构式。
  • 不要无故追问。 给了清楚的目标就直接分析；只有连目标本身都缺失时才问一次。
  • 不要把三个技能混用。 
    ljg-is
    找「A 到 B」；
    ljg-think
    追「为什么」；
    ljg-structure
    找「什么关系反复生成结果」。
  • Don't confuse the complete definition with the essence. Subject, scenario, identity, boundaries, quality, speed, cost, risk, and implementation methods are usually qualifying conditions in parentheses.
  • Don't end with a list of advantages. "Safe, comfortable, efficient" describes how well something is done, not what is ultimately done.
  • Don't require the core to occupy a single category. Taxi, bus, and private car may share "move people from point A to point B"; this means they share the essence of purpose, not that the extraction failed.
  • Don't stop at abstract nouns. "Service", "value", "connection", "experience", "efficiency" have no direction or completion state and cannot be used as the core.
  • Don't write implementations into the core. Cars, Apps, algorithms, stores, contracts, and networks are just how things are done. If changing an implementation can still accomplish the same change, it should go into parentheses.
  • Don't delete the object undergoing change. "From A to B" is too vague; "move people from point A to point B" preserves the target and direction.
  • Don't distort for brevity. Minimalism is not a word-count competition. Stop when removing one more word would lose the object, starting point, end point, or direction of change.
  • Don't write examples as spectator stories. Must let "you" perform specific actions, see 
    A -> B
    , and point out which step is the core.
  • Don't let the four modules overlap in responsibilities. Stripping explains qualifications, examples are for near-field understanding, structural migration is for far-field stress testing, and validation only forms a minimal closed loop.
  • Don't use pseudo-mathematics to seem profound. Structural formulas are relationship signatures, not empirical laws; when 
    (X, S0) -> (X, S1)
    is sufficient, do not add integrals, sums, or proportion symbols.
  • Don't confuse similarity with isomorphism. Migration must align object, starting point, end point, direction, and completion test item by item, and clearly state "what to migrate only / what not to migrate".
  • Don't let migration overshadow the core. Distant-domain cases are used to verify the structure; if it forces the core to change to another problem, go back to the original target and rewrite the structural formula.
  • Don't ask unnecessary questions. Analyze directly when given a clear target; only ask once if the target itself is missing.
  • Don't mix the three skills. 
    ljg-is
    finds "A to B"; 
    ljg-think
    asks "why"; 
    ljg-structure
    finds "what relationship repeatedly generates results".

Examples

Examples

Taxi：把定义变成一次可执行的心理模拟
text
User: /ljg-is Taxi
本质：把人从 A 点送到 B 点
完整：（面向乘客，在出行场景中，按需、付费、安全、舒适地）把人从 A 点送到 B 点
代入：你下班后站在公司门口，目标是回到家。
操作：你叫车、上车、移动、下车；再想象把豪华车换成普通车。
变化：你：公司门口 -> 家门口
点题：只要位置变化完成，「把人从 A 点送到 B 点」就成立；车型改变的是实现，舒适度改变的是质量。
结构式：(X, S0) -> (X, S1)
变量：X=承受变化的对象；S0=原位置；S1=目标位置
迁移：文件：下载目录 -> 归档目录；对象、方向和完成测试保持一致
边界：只迁移「对象从一个位置到另一个位置」；不迁移付费、安全、舒适或交通规则
示例不是证明定义，而是把抽象句变成一次可重演的操作。读者做完后，应能不用术语回答：「我刚才究竟把什么，从哪里，变到了哪里？」
强化学习：让结构式承载反馈关系，不冒充算法公式
text
User: /ljg-is 强化学习
本质：让过去的行动后果改善未来的行动选择
结构式：(A_past, C_past) -> A_next
变量：A_past=过去的行动选择；C_past=这些行动的后果；A_next=被经验改善的未来选择
迁移：团队复盘：(方案_past, 结果_past) -> 方案_next；反馈都改变下一次选择
边界：只迁移「后果反馈改善未来选择」；不迁移奖励定义、智能体、环境或优化算法
Taxi: Turn the definition into an executable mental simulation
text
User: /ljg-is Taxi
Essence: Move people from point A to point B
Complete: (For passengers, in travel scenarios, on-demand, paid, safe, and comfortable) move people from point A to point B
Scenario: You stand at the company gate after work, aiming to go home.
Operation: You call a car, get in, travel, get off; then imagine replacing a luxury car with a regular car.
Change: You: Company gate -> Home doorstep
Pointing out the core: As long as the position change is completed, "move people from point A to point B" holds; changing the vehicle type alters the implementation, while changing comfort alters quality.
Structural Formula: (X, S0) -> (X, S1)
Variables: X=Object undergoing change; S0=Original position; S1=Target position
Migration: File: Download directory -> Archive directory; object, direction, and completion test remain consistent
Boundary: Only migrate "object moving from one position to another"; do not migrate payment, safety, comfort, or traffic rules
Examples are not to prove the definition, but to turn abstract sentences into a repeatable operation. After completing it, the reader should be able to answer without jargon: "What exactly did I move, from where, to where?"
Reinforcement Learning: Let the structural formula carry feedback relationships, not pretend to be an algorithm formula
text
User: /ljg-is 强化学习
Essence: Let the consequences of past actions improve future action choices
Structural Formula: (A_past, C_past) -> A_next
Variables: A_past=Past action choices; C_past=Consequences of these actions; A_next=Future choices improved by experience
Migration: Team retrospective: (Plan_past, Result_past) -> Plan_next; feedback changes the next choice
Boundary: Only migrate "consequence feedback improves future choices"; do not migrate reward definition, Agent, environment, or optimization algorithm