شبیه‌ساز بازگویی فاینمن: شکاف‌های فهم خود را با توضیح‌دادن به یک تازه‌کار کنجکاو آشکار کنید
چرا این پرامپت اهمیت دارد
People systematically overestimate how well they understand something right after reading about it, a well-documented effect called the illusion of explanatory depth. Engineers ship code built on half-understood concepts constantly — the person who “read about” idempotency keys but never had to explain them out loud discovers the gap only when a duplicate charge hits a customer's card in production. A ten-minute teach-back session catches these gaps for free, before implementation; finding them in a postmortem costs hours of incident response, a rollback, and a damaged customer relationship.
ما از آن برای چه استفاده می‌کنیم
You just spent three days learning how OAuth 2.0's PKCE flow works before implementing it for your team's new mobile app, and you think you understand it — but you won't find out if you actually do until you're debugging it live in production. You need to stress-test your own understanding before that happens, not after.
پرامپت
Role: You are a curious, intelligent novice who knows nothing about [TOPIC OR CONCEPT] but is genuinely eager to understand it. You are not an expert checking my work — you are a smart person encountering this idea for the first time. Context: I am going to explain [TOPIC OR CONCEPT] to you in my own words, exactly as I currently understand it, without looking anything up. My goal is to find the gaps and shaky spots in my own understanding before I rely on this concept for [REAL STAKES — e.g. "implementing it in production code", "teaching it to my team", "making a decision based on it"]. Task: After I give my explanation, do the following in order: 1. Ask me 3 to 5 follow-up questions that a genuinely curious novice would ask — focus especially on the parts of my explanation that were vague, used jargon without defining it, or skipped a step. 2. For each question, after I answer, if the answer reveals a gap, name the gap specifically: what exactly am I unsure about, and why does it matter for [REAL STAKES]? 3. Once the question round is complete, give me a short "understanding report" with three sections: what I clearly understand (Solid), what I have a shaky grasp of (Shaky), and what I don't actually understand yet despite thinking I did (Missing). 4. Suggest one concrete next step to close the biggest gap — a specific resource, experiment, or question to investigate, not a vague "read more about it". Constraints: Do not simply validate my explanation or tell me it's correct unless you have genuinely tested it with probing questions first. Do not ask questions you already know the answer to just to be polite — ask questions that would actually expose confusion if I have it. Keep your questions in plain language, not jargon. Do not move to the understanding report until the question round is complete. Output Format: - Round 1: [3-5 numbered follow-up questions] - Gap Analysis: [one line per question, naming any specific gap revealed by my answer] - Understanding Report: [three short sections — Solid / Shaky / Missing] - Next Step: [one concrete, specific action] My explanation of [TOPIC OR CONCEPT]: [PASTE YOUR EXPLANATION HERE, WRITTEN IN YOUR OWN WORDS]
نتیجه
Round 1 — Follow-up Questions:
- You said the “code verifier” is a random string the app generates — what stops a malicious app on the same device from generating its own code verifier and intercepting the authorization code meant for you?
- You mentioned the code challenge is sent in the initial authorization request, and the code verifier is sent later when exchanging the code for a token — why does PKCE send two different values instead of just sending the same secret twice?
- You described the code_challenge_method as “usually SHA-256” — what would go wrong if an app just set the method to “plain” and sent the verifier directly as the challenge?
- If a user closes the app mid-login and reopens it, does the code verifier need to still be the same one from before, and where would the app have stored it?
- You explained this is mainly for “mobile apps and SPAs” — what is actually different about how a confidential, server-side web app handles its client secret that makes PKCE less essential there?
Gap Analysis:
- Q1: Your answer described the interception risk correctly but didn't explain why the attacker can't also just compute the correct code verifier — this suggests you're fuzzy on why the hashing step specifically, not just possessing some verifier, is what blocks the attack.
- Q2: You said “to be more secure” without explaining the mechanism. Real gap: you don't yet know why a hashed value in step one and the raw value in step two defeats a man-in-the-middle, specifically.
- Q3: You correctly identified this disables the protection but weren't sure why “plain” mode exists at all. Minor gap, not load-bearing for your implementation.
- Q4: You weren't sure. This is a gap worth closing before shipping — it directly affects your storage design decision.
- Q5: Solid answer — you clearly understand the confidential-client distinction.
Understanding Report:
Solid: You understand the overall request flow and why mobile apps can't hold a client secret.
Shaky: You can describe the hashing step but not derive why it specifically defeats interception — this is the core security property of PKCE and you're currently taking it on faith rather than understanding it.
Missing: Code verifier persistence across app restarts and backgrounding — you haven't thought through where this value lives between the authorization request and the token exchange on a mobile OS that can kill your app's memory at any time.
Next Step: Before writing the implementation, trace through what happens if iOS backgrounds and then kills your app between steps 1 and 2 — specifically, where the code_verifier needs to be persisted (Keychain, not just memory) for the flow to survive that. This is the single most common PKCE mobile bug in production.
بیشتر پرامپت‌های «این را برایم دوباره توضیح بده» به دلیلی قابل‌پیش‌بینی شکست می‌خورند: آن‌ها از هوش مصنوعی می‌خواهند که فقط ارزیابی کند آیا یک توضیح درست است یا نه، که یا تحسین عمومی تولید می‌کند یا اصلاح سطحی، و هیچ‌یک به فرد چیزی درباره عمق فهم خودش نمی‌گوید. این پرامپت به‌شکل متفاوتی کار می‌کند چون به هوش مصنوعی نقشی با ساختار انگیزشی درونی می‌دهد — یک تازه‌کار کنجکاو که هیچ نفعی در مهربان‌بودن ندارد و تنها وظیفه‌اش پرسیدن سؤالاتی است که یک فرد واقعاً گیج‌شده می‌پرسد. سردرگمی، برخلاف ارزیابی، ضعف‌های ساختاری را آشکار می‌کند که یک بررسی ساده «آیا این درست است؟» هرگز آن‌ها را نمی‌گیرد.
ترتیب به همان اندازه نقش اهمیت دارد. این پرامپت یک دور کامل پرسش را پیش از هر داوری تحمیل می‌کند، که مدل را از تطبیق‌الگوی «تقریباً درست به‌نظر می‌رسد، تأیید شد» پس از اولین پاسخ محتمل‌به‌نظر باز می‌دارد. هر پرسش نیز صریحاً به بخشی مبهم، تعریف‌نشده یا حذف‌شده از توضیح اصلی مرتبط است — این همان چیزی است که آن را از یک آزمون عمومی متمایز می‌کند، که درباره موضوع به‌طور کلی می‌پرسد نه درباره شکاف‌های خاص در روایت یک فرد از آن.
گزارش فهم سه‌سطحی — محکم، لرزان، غایب — وجود دارد چون این‌ها از نظر عملکردی مشکلات متفاوتی هستند که پاسخ‌های متفاوتی نیاز دارند. یک شکاف غایب یعنی شما چیزی را نمی‌دانید و باید پیش از تکیه بر آن آن را پیدا کنید. یک شکاف لرزان خطرناک‌تر است: بخشی است که می‌توانید به‌خوبی کافی توصیف کنید تا باصلاحیت به‌نظر برسید اما واقعاً آن را استخراج یا آزمایش نکرده‌اید، نوعی فهم که در یک گفتگوی معمولی دوام می‌آورد اما در اولین برخورد با یک حالت حاشیه‌ای که با مدل ذهنی شما تناقض دارد فرو می‌ریزد. ریختن این‌ها در یک سطل یکپارچه «نیاز به بازبینی»، همان‌طور که بیشتر پرامپت‌های خودارزیابی می‌کنند، دقیقاً همان تمایزی را پنهان می‌کند که برای تصمیم‌گیری درباره قدم بعدی اهمیت دارد.
محدودیت نهایی — یک قدم بعدی مشخص و عینی به‌جای یک «بیشتر درباره‌اش بخوان» مبهم — وجود دارد چون خروجی یک خودارزیابی اگر کاری را که در ده دقیقه بعد انجام می‌دهید تغییر ندهد بی‌فایده است. یک قدم بعدی خوب یک آزمایش، ردیابی یا پرسش خاص برای بررسی را نام می‌برد، نه یک دسته‌بندی کلی از مطالعه بیشتر.