The user gives a scenario, and you deliver an analogy that first lets people see the picture, then recognize the relations, and finally understand the original scenario a little better. The objects can be far apart, yet the relations line up closely. Novelty cannot offset distortion; familiar objects can also carry unexpected relations.
Terminology direction is fixed:The scenario the user wants to understand is the target domain; the scenario borrowed to aid understanding is the base domain. The search starts from the target domain to find the base domain, and knowledge transfer goes from the base domain back to the target domain. When the user's wording is reversed, work according to the actual intent, and do not interrupt the creation for terminology.
Workflow Routing
| Request | Handling |
|---|---|
| Give a scenario and look for an analogy or metaphor | Deliver one main analogy according to the finished-product standards below |
| Compare two objects, products, or mechanisms | Use a shared relational framework while preserving both commonalities and key differences |
| Specify the audience, domain, style, or ask for just one sentence | Preserve the structural constraints and comply with the user's presentation requirements |
| Want multiple options or a comparison of existing candidates | Compare different relational focuses, point out the recommendation and the trade-offs |
Gotchas
- "Both are complex," "both are networks," and "both require balance" apply too broadly and cannot support an analogy on their own. The relations must make clear who does what to whom, which conditions constrain it, and how it produces a result or forms a layout.
- Pairing multiple objects is only a dictionary. Prioritize preserving relations governed by the same causal, constraint, proportional, or spatial structure; the number of commonalities cannot serve as systematicity.
- "Higher-order" refers to relations between relations; it does not mean more abstract or more grand, nor is it limited to causal chains. Proportional, spatial, and emotional relations can also bear weight.
- Within one mapping, roles must remain stable; do not let the same object secretly change identity just for the convenience of the next sentence. When different aspects really need to be compared, make it clear that a different mapping has been switched to. Surface attributes do not transfer automatically along with relations.
- The base domain is found; the facts of the target domain are given by the user. Do not add motives, causality, or endings to the target domain just to make the comparison hold; missing items can only appear as explicit assumptions.
- An analogy yields candidate inferences; it cannot prove that the target domain must be so. In particular, do not infer the inevitability, legitimacy, or someone's intention behind social behavior from natural processes.
Is the input sufficient
At minimum, you can recognize what happens in the scenario and the relations the user wants to illuminate. When there is only one word and no identifiable situation, ask one question that could change the choice of analogy; when a word has multiple common referents, first confirm what it refers to, and the options in the question must not presuppose one meaning. When a usable scenario already exists, work directly. If no audience is specified, default to ordinary Chinese readers, prioritizing everyday scenarios that can be imagined with little explanation.
Align the analogy with the comprehension task the reader currently needs to complete: identify what, distinguish what, or predict which kind of change. Purpose, composition, operation, and experience are different explanatory focuses; if the reader asks how two things differ, summarizing their purposes separately may miss the point. Choose the focus based on the question and existing context, and when necessary, clarify with a sentence such as "Here we focus on...", without turning this check into asking the user an additional question every time.
Goals, power differences, timing, and constraints emphasized by the user must not be erased during abstraction. Version and state are also part of object identity: when new evidence changes roles, processes, or dependencies, re-examine the framing and the main analogy. If the original candidate can no longer preserve the load-bearing relations, replace it; do not merely append a sentence about version differences at the end.
What kind of analogy is worth delivering
Task fit. The mapping preserves the relations the reader needs to understand this time. An analogy may explain one feature of an object and still be irrelevant to the problem at hand; the key is whether it improves the current identification, distinction, or understanding.
The relations hold. The same informative relational skeleton exists on both sides. The reader can place people or objects back into their respective roles one by one and check the direction of effect, order of events, dependency conditions, and feedback. Explaining only part is allowed, but a vague "it's just an analogy" must not be used to cover up load-bearing relations that are reversed.
The relations connect. There is a mutually supporting set of correspondences, not similarities collected just to fill a quota. If a change in one place affects another, explain how this dependency recurs on both sides. When a simple proportion or spatial correspondence is already sufficient, there is no need to force in causality or fill out the number of relations.
The picture can stand on its own. The base domain has concrete objects and actions, and an ordinary reader can understand it without first hearing the new theory. Constructed scenarios explicitly marked as "suppose" may be used; natural mechanisms, historical events, or celebrity stories must not be fabricated as facts.
It reveals a little more. The analogy makes at least one previously inconspicuous relation visible: a blind spot, constraint, cost, consequence, or condition that distinguishes two judgments. This increment must be derivable from the mapping. When evaluating an explanatory analogy, use a small scenario not directly copied from the original description to check whether it helps the reader identify differences, infer outcomes, or choose the next step; candidates that can only restate names and features remain weak. This is an internal content check; it does not require posing a question to the user every time, nor is it equivalent to reader testing. Literary metaphors can change how readers see a relation, and do not require imposing an operational test or scientific experiment.
The candidate withstands comparison. When different candidates all seem plausible, compare them using the same comprehension task: which preserves the more critical relations, which supports more specific distinctions or inferences, and which requires less additional explanation. If only the vehicle nouns differ while the relational skeleton is the same, that does not count as another structure. Relational credibility and audience comprehensibility are the baseline; a familiar near-domain correspondence may be better than a novel far-domain one, and distance itself does not count as quality. Candidate exploration stays internal; unless the user asks, deliver only the strongest option; if there is no qualified candidate, state the specific gap.
The boundary is specific. Point out which striking feature of the base domain cannot be carried over, or which change in a target-domain condition would break the correspondence. Do this in one sentence relevant to this analogy, and avoid generic disclaimers.
When comparing two objects
Prefer finding a set of scenarios within the same familiar domain, using the same set of roles and relationships to describe both sides, so that commonalities remain comparable and key differences stand out clearly. Finding fitting images for A and B separately is still not enough to explain how A and B differ; what can be borrowed is a set of distinct operational relationships. If spanning two base domains is more accurate, the shared basis for comparison should still be preserved, and one should not force it into the same domain.
Check whether the two correspondences have discriminating power: after swapping the vehicles, if they can still be easily reconciled without changing the load-bearing relationships, they may have hit only shared attributes. Put a new input or changed condition into both sides, and the reader should be able to see from the analogy how each handles it and what difference emerges. If the different answers depend entirely on separately writing in facts about the target domain, the vehicle itself has not provided enough help. Merely replacing nouns according to the original text, or stuffing labels of superiority and inferiority into the analogy, cannot replace this check either.
How the finished product should be stated
By default, deliver directly in the conversation, without automatically creating notes, images, or files. Usually use a few paragraphs to explain one main analogy thoroughly, with length flexing according to the scenario:
- First give the analogy itself. Use one vivid sentence in Chinese so people immediately know what is being compared to what. Bring the truly load-bearing relationship into this sentence, and avoid a vague "X is like Y."
- Let the correspondence run. Explain the concrete situation in the base domain clearly, then connect it back to the user's scenario. For complex correspondences, a short table may be used, and the table should state "how the relationships correspond," not merely fill in noun-to-noun pairs.
- Land back on the newly added understanding. Clearly state which point of the original scenario this analogy makes clearer, and which point is most easily misled past. Do not merely replace words and restate the opening.
The above are information requirements, not a fixed heading template. If the user wants only one sentence, deliver only one sentence; if the user wants a finished draft that can be quoted directly, first give the clean finished draft, and do not stuff acceptance language into the main text. A metaphor may omit "like," but the structural correspondence must still hold.
Boundary between theory and fact
This skill borrows Gentner's (1983) relational mapping and systematicity principles. Understanding the task, two-object comparison, candidate elimination, audience familiarity, cognitive increment, and concrete boundaries are design standards added for the creative task, and are not claimed to come from the paper or to have been verified by it.
When you have questions about definitions, non-causal relationships, metaphor, or theoretical extrapolation, read Theory.md. When maintaining or trial-running, use EvalCases.json; these use cases only define inputs and acceptance criteria, and do not prescribe a single correct analogy.
Constructing everyday scenarios does not require internet access. If the final analogy depends on some uncertain scientific, historical, or industry fact, first verify primary materials with currently available retrieval tools; if it cannot be verified, switch to a base domain with reliable facts, or explicitly limit it to a hypothetical scenario.
Examples
- "I've saved many articles, but when I actually run into a problem I can't find them. Give me an ingenious analogy." The finished product should illuminate the relationship between storing and retrieving, and map it to a concrete situation; it must not merely praise the quantity with "treasury of knowledge."
- "Both tools can complete tasks. One has me arrange sessions item by item, while the other receives requirements from the main session and dispatches and reports back. Use an analogy to explain the difference clearly." The finished product should preserve the differences in entry point, routing, and coordination; do not broadly divide the two into an execution tool and a material container, and do not presuppose a single correct vehicle.
- "After being away from home for many years, hearing a line of local accent makes me feel someone is waiting for me. Just one metaphor." The finished product should preserve the structure of sound, belonging, and relationship being evoked, give only one sentence, and not automatically add a table or action checklist.