If you give only a definition, readers may remember the word but still not know how to recognize it. If you give only the verb, readers may know what it does but not clearly know what kind of thing it is or where its boundaries lie.
ljg-is Connect the two: the noun answers "what it is," letting the concept stand firm on the cognitive map; the verb answers "how it works," letting the concept move in reality. A truly completed understanding must go one step further: what judgment of the reader's does it rewrite, and how can they act the next time they encounter it.
它是什么，和什么不一样？
它靠什么动作产生结果？
知道这一点后，我不再怎样想？
下次遇到它，我先看什么、怎样做？
These four questions are a path to understanding, not four sections of the main text. The article should read like a person following their confusion and making the matter clear, not like answers filled into a table one by one.
Zhao Tingyang's idea of the "verb" remains important here, but it is a conditional lens. When facing institutions, platforms, roles, or norms, one can continue to ask who chose this practice and how it changes participants; when facing technical concepts such as objective functions or recursion, the verb is first of all the object's own operation and effect. If the material does not show social counteraction, do not forcibly drag a technical explanation into institutional critique.
Workflow Routing
| Workflow | Trigger | File |
|---|---|---|
| UnderstandInUse | Connect "what it is" and "how it works" into a recognizable, judgeable, actionable Org interpretation | Workflows/TraceCreation.md |
Finished-product standard
A qualified interpretation will produce four consecutive changes in the reader:
-
They can say in one plain sentence what category X belongs to, and how it differs from the object most easily confused with it. A definition must give boundaries; it cannot give only a metaphor or a use.
-
They can follow a real example to explain how X works. For technical concepts, explain the input, key actions, and result; for institutional concepts, explain the participants, how rules enter action, and the actual consequences. Write only the mechanisms the object truly has.
-
They can point out which of their previous views needs revision. The cognitive change must follow from the preceding definition and mechanism; do not start a separate project in pursuit of "depth."
-
They can use this understanding in a specific situation. Action guidance should make clear what to look at first, how to judge, when to adjust, and be able to explain why.
The main text enters from a confusion, misunderstanding, or usage scenario that an ordinary reader would really have; do not force the invention of character stories. Concepts should appear as early as possible; examples are responsible for verifying the explanation, not for creating drama.
It can end on a judgment, an action principle, or a real unresolved question. Which one is natural is decided by the preceding text; a question mark is not proof of depth.
Default write-in:
~/Context/{时间戳}--理解-{目标片段}__is.org
New finished products use the ljg-is-v5 schema. The main text uses two to four headings that arise from the content and four to ten natural paragraphs, and does not directly use "what it is / how it works / cognitive change / action guidance" as four sections.
Judgment boundaries
-
Definition and understanding are different. If the user only wants a formal definition, formula proof, or terminology translation, answer directly; only when they want to understand how a concept works, what it means, or how to use it does this skill come into play.
-
Verb does not equal social creation. Technical objects can function through computation, mapping, comparison, compression, or recursion, without the need to invent a creator story. Only institutional objects raise questions about the chooser, the rules, and countereffects.
-
Action guidance is not an operation manual. This skill provides handles for judgment; it does not replace a step-by-step tutorial for a particular piece of software, process, or industry.
-
Reasons cannot be fabricated. Distinguish facts supported by materials from the analyst's inferences. If you do not know, narrow the judgment; do not fill in motives on behalf of the people involved, and do not pass off general mechanisms as facts of a specific case.
Gotchas
-
Do not write a new contract as a new checklist. If "definition, mechanism, heuristic, recommendation" each occupy a column, the article will still be stiff. They should be like a line of reasoning: because X works this way, the original judgment is not accurate enough, and only then should it be done this way next time.
-
Do not give only use as definition. "The objective function is used for optimization" does not explain what it is; you need to add how it establishes a comparable relationship among candidate solutions, so that readers can distinguish it from constraints, metrics, or rewards.
-
Do not force concrete scenarios. A real confusion is often more natural than a fictional engineer or driver. Use a story only when the characters' actions genuinely carry the mechanism.
-
Do not force a Zhao Tingyang-style turn. Unselected possibilities, countermeasures, origins, and the future are not required fields. They enter the main text only when they can explain the object and have a basis in reality.
-
Do not suddenly escalate the scale at the end. If the preceding text discusses algorithms and the ending suddenly interrogates social justice, that is usually not profundity but a change of question. Cognitive change and action guidance must be traceable sentence by sentence to the mechanism already explained clearly.
-
Do not give all-purpose advice. If "stay attentive," "consider comprehensively," and "analyze specific problems specifically" still hold after deleting the concept names, it means they did not use the understanding from the preceding text.
-
Do not let metadata speak for the main text.
definition、operation、recognitionandguidanceare backend indexes; the main text may use more natural wording, but reading the whole text back must find the same content.
Examples
Objective function
不要写：目标函数是优化的灵魂，它最终会反过来支配设计者。
可以写：目标函数是一把供求解过程比较方案的尺子。它给每个候选方案一个
可比较的结果，让程序知道往哪边改进。因此看到「最优」时，先补问一句：
这是按照哪把尺子得到的最优？
Performance review
先讲清：它是组织定期判断工作表现并连接后续决定的一套正式做法。
再讲它怎样通过指标、叙述或评议进入奖金与机会。由此自然推出：考核不只
记录工作，也会改变人们接下来选择什么工作；设计考核时要检查它正在奖励的
行为，而不能只检查表格是否完整。
Boundary case
User: 请给出递归函数的形式化定义并证明这个定理。
→ 不调用 ljg-is；这是形式定义与证明任务。
User: 我知道递归是自己调用自己，但还是不懂它到底是什么，写程序时怎么判断该不该用？
→ 调用 ljg-is；这需要把定义、运作方式、认知修正与使用判断接起来。