پل مفهومی: هر موضوع فنی را با نگاشت به دانش پیشین خود فوراً بیاموزید
Why this prompt matters
Standard technical documentation is written for people who already understand adjacent concepts in the same field. If you're a database engineer learning ML, those resources assume the wrong baseline. Anchoring new concepts to your existing mental models is measurably faster — cognitive science research on analogical transfer consistently shows 3–5x better retention when learners map new information to known structures. The prompt also forces the AI to identify where the analogy breaks, which is where most self-taught understanding fails silently.
What we use it for
You've been handed a task involving a technology you've never touched: a backend engineer suddenly needs to understand transformer attention mechanisms, a product manager needs to grasp distributed consensus before a 10am meeting, or a lawyer needs a working mental model of blockchain before a client call. You have 30 minutes and need genuine intuition, not a textbook overview.
Prompt
Act as a master teacher and domain translator. Your job is to explain [CONCEPT YOU WANT TO LEARN] entirely through analogies drawn from [DOMAIN YOU ALREADY KNOW WELL] — without using direct technical jargon from the new concept until after it has been introduced through analogy. Context: I have deep expertise in [DOMAIN YOU ALREADY KNOW WELL] and I am trying to build an intuitive mental model of [CONCEPT YOU WANT TO LEARN]. I do NOT want a standard textbook explanation. I want to understand it the way a colleague who knows my domain deeply would explain it over coffee. Task: Explain [CONCEPT YOU WANT TO LEARN] by: 1. Creating a Core Mapping — a table that maps each key component of the new concept to its closest equivalent in [DOMAIN YOU ALREADY KNOW WELL] 2. Walking through 2–3 concrete scenarios using only the language and mental models of [DOMAIN YOU ALREADY KNOW WELL] 3. Identifying clearly where the analogy breaks down — the specific points where my intuition from [DOMAIN I KNOW] will mislead me about [CONCEPT YOU WANT TO LEARN] 4. Ending with 3 self-check questions I can ask myself to verify I genuinely understood it and not just pattern-matched the words Constraints: - Do NOT open with a Wikipedia-style overview — go straight into analogy - Every technical term must be introduced via its analogy before being named - The breakdown section must be honest and specific, not just "the analogy isn't perfect" - Keep the full response under 800 words Output Format: ## The Concept Bridge: [CONCEPT] through the lens of [DOMAIN] ### Core Mapping [Table: New Concept Term | What It Maps To In Your Domain] ### How It Works (in your domain's language) [2–3 scenarios told entirely in the language of [DOMAIN YOU ALREADY KNOW WELL]] ### Where the Analogy Breaks Down [Specific, honest limitations — the places your intuition will lie to you] ### 3 Questions to Test Your Understanding [Self-check questions that require real understanding, not recall]
Result
The Concept Bridge: Transformer Attention through the lens of SQL Databases
Core Mapping
| Transformer Concept | Database Equivalent |
|---|---|
| Token | Row in a table |
| Attention weight | JOIN relevance score / query selectivity |
| Query vector (Q) | The SELECT + WHERE clause you're searching with |
| Key vector (K) | The indexed column being searched against |
| Value vector (V) | The actual data returned when a row matches |
| Multi-head attention | Running 8 parallel queries on the same table, each asking a different question |
| Context window | The table size limit — only rows within it can be JOINed |
How It Works (in database language)
Scenario 1: A single attention head. Imagine you're running: "Find all rows most relevant to the current row I'm processing." Every token simultaneously acts as both the query (what am I looking for?) and a potential result (am I relevant to others?). The attention weight is the relevance score — like a fuzzy full-text search rank rather than an exact JOIN.
Scenario 2: Multi-head attention. You run 8 different queries on the same dataset in parallel. One asks "which words are grammatically connected?", another asks "which words share meaning?", another asks about position. Each returns its own ranked result set. The outputs are then concatenated — like a UNION ALL followed by a final aggregation.
Scenario 3: The context window as table size. Your database can only hold 128,000 rows in memory at once. Any row outside that window simply doesn't exist for the current query — it can't be JOINed against or referenced. This is why context length matters: it's your working table size.
Where the Analogy Breaks Down
Weights are learned, not declared. In SQL, you define your schema and indexes explicitly. The Q, K, V matrices — the "query structure" — are learned from billions of examples. There's no schema designer.
All rows query all rows simultaneously. In SQL, you write one query at a time. In attention, every token is simultaneously acting as a query against every other token in one parallelized matrix multiplication — N² comparisons at once.
There's no primary key. A word's "identity" as a key shifts based on what surrounds it, unlike a database row with a fixed ID.
3 Questions to Test Your Understanding
- If you doubled the context window from 64K to 128K tokens, what happens to computational cost — and why? (Hint: think N².)
- Why can't a transformer "look up" information from a document it wasn't given in context, even if trained on it?
- In multi-head attention, each head learns different patterns. What would be the database equivalent of a head that specializes in long-range dependencies?
بیشتر توضیحات فنی برای افرادی نوشته میشوند که مفاهیم مجاور در همان حوزه را از پیش میدانند. اگر یک مهندس پایگاه داده باشید که میخواهید نحوه کار Attention در Transformer را بفهمید، آموزشهای استاندارد به مفاهیم جبر خطی و شهودات Machine Learning ارجاع میدهند که شما ندارید. پرامپت «Concept Bridge» این وضعیت را برعکس میکند – هوش مصنوعی را وادار میکند مفهوم جدید را کاملاً از طریق حوزه تخصصی شما توضیح دهد و سپس صادقانه مشخص کند که این قیاس در کجا از کار میافتد.
چه چیزی این پرامپت را مؤثر میکند
این پرامپت بر سه انتخاب ساختاری بنا شده است که بیشتر پرامپتهای «X را ساده توضیح بده» از آنها چشمپوشی میکنند:
نگاشت اصلی (Core Mapping) در ابتدا قرار دارد. پیش از هر توضیح روایی، هوش مصنوعی باید جدولی ارائه دهد که هر کلیدواژه مهم در مفهوم جدید را به نزدیکترین معادل آن در حوزه شما نگاشت کند. این کار به شما واژگانی پیش از داستان میدهد – بنابراین وقتی قیاسها پیچیده میشوند، یک نقطه مرجع برای لنگر انداختن دارید.
بخش فروپاشی (Breakdown) اجباری است. بیشتر توضیحات مبتنی بر قیاس این بخش را حذف میکنند، به این معنا که شما با یک مدل ذهنی که بیصدا اشتباه عمل میکند، خارج میشوید. این پرامپت از هوش مصنوعی میخواهد دقیقاً مشخص کند که شهود شما در حوزه تخصصیتان در کجا شما را گمراه خواهد کرد. این همان جایی است که بیشتر درک خودآموخته فنی شکست میخورد – نه در سطح، بلکه در لبههایی که قیاس دیگر برقرار نیست.
سؤالات خودآزمایی از فهم استفاده میکنند، نه بازگویی. سه سؤال پایانی طوری طراحی شدهاند که نیازمند استدلال واقعی با مدل ذهنی باشند، نه صرفاً تکرار آنچه گفته شده است. اگر بتوانید با استفاده از زبان حوزه خود به آنها پاسخ دهید، مفهوم را فهمیدهاید. اگر نتوانید، دقیقاً میدانید کجا باید عمیقتر حفاری کنید.
نحوه استفاده
[CONCEPT YOU WANT TO LEARN] را با هر چیزی جایگزین کنید: مکانیزمهای Attention در Transformer، اجماع توزیعشده (Raft/Paxos)، Smart Contract، ساختار داده CRDT، رمزنگاری همومورفیک، زمانبندی Kubernetes. [DOMAIN YOU ALREADY KNOW WELL] را با قویترین تخصص موجود خود جایگزین کنید: پایگاه داده SQL، مهندسی برق، حقوق مدنی، تئوری موسیقی، حسابداری، لجستیک.
مدل زمانی بهترین عملکرد را دارد که فاصله بین حوزهها زیاد باشد – یک وکیل که Blockchain را یاد میگیرد، یک مهندس بکاند که Machine Learning را یاد میگیرد، یک مدیر محصول که سیستمهای توزیعشده را یاد میگیرد. هرچه شکاف بیشتر باشد، پل مفیدتر است. از این پرامپت برای مفاهیم مجاور که منابع استاندارد در همان سطح شما هستند استفاده نکنید.
نکات مربوط به مدل
Claude Opus 4.8 غنیترین قیاسها و صادقانهترین بخشهای فروپاشی را تولید میکند – این مدل بهویژه در تشخیص جایی که قیاس گمراه میکند خوب است، نه صرفاً گفتن «قیاس محدودیت دارد». GPT‑4o یک جایگزین مطمئن با جدولهای اندکی ساختاریافتهتر است. از مدلهای کوچکتر برای این پرامپت اجتناب کنید؛ آنها تمایل به نگاشتهای سطحی دارند که درست به نظر میرسند اما جزئیات مکانیکی را که فهم در آن نهفته است از دست میدهند.