حذف‌کننده اصطلاحات تخصصی: مستندات فنی متراکم را به چیزی قابل‌استفاده برای غیرمهندس تبدیل کنید
چرا این پرامپت اهمیت دارد
Sales reps who can't accurately explain technical safeguards either underclaim value and lose the deal to a competitor with a slicker pitch, or overclaim capabilities the system doesn't actually have — creating a support and legal liability once the client discovers the gap after signing. Teams without a fast way to translate documentation end up pulling an engineer into every sales call, or losing deals to less-technical, better-explained competitors.
ما از آن برای چه استفاده می‌کنیم
A backend engineer just shipped documentation for a new authentication API covering JWT rotation and idempotent retries. The sales team needs to explain these safeguards to a healthcare client asking pointed questions about session security and duplicate-charge protection during a live demo call in two hours — and they can't parse terms like “idempotent” or “token rotation” fast enough to answer confidently.
پرامپت
Role: Act as a technical communication specialist who translates engineering documentation for non-technical stakeholders without losing accuracy or introducing false confidence. Context: - Source documentation: [PASTE TECHNICAL DOCUMENTATION HERE] - Original audience this was written for: [E.G., "backend engineers integrating with our API"] - Target audience who now needs to understand it: [E.G., "the sales team and a non-technical product manager"] - What the target audience needs to DO with this understanding: [E.G., "explain the feature's security guarantees to a healthcare client on a live call, without overpromising"] Task: 1. Identify every term, acronym, or concept in the documentation that would likely be unfamiliar to [TARGET AUDIENCE]. 2. For each one, write a one-line plain-English definition, using an analogy from the target audience's own domain where possible. 3. Rewrite the full documentation in plain English, preserving every accuracy-critical detail. Do not oversimplify to the point of being factually wrong. 4. Separately flag any place where a technical nuance is important enough that glossing over it could cause [TARGET AUDIENCE] to make a costly mistake (overpromise a capability, misstate a limit, or reassure a customer incorrectly). Constraints: - Do not delete information just because it's hard to explain — find a way to explain it instead. - Do not add marketing language, hype, or claims that are not present in the original documentation. - Keep the plain-English rewrite roughly the same length as the original, or shorter. - Preserve exact numbers, limits, versions, and thresholds precisely as given — do not round or approximate them. Output Format: 1. **Glossary** — term → one-line plain-English definition, one per line. 2. **Plain-English Rewrite** — the full rewritten documentation. 3. **Where to Be Careful** — a bullet list of the accuracy-critical nuances identified in Task step 4, phrased as "don't say X, say Y" where useful.
نتیجه
Glossary
- JWT (JSON Web Token): A digital ID badge your app carries around to prove it's allowed to make requests, without logging in again every time.
- Token rotation: The system automatically swaps old ID badges for new ones on a schedule, so a stolen badge only works for a limited window.
- Idempotent retry: If a request accidentally gets sent twice (like during a network hiccup), the system recognizes the duplicate and processes it only once.
- Refresh token: A longer-lived backup badge used only to request a new short-lived ID badge, never to make actual requests directly.
Plain-English Rewrite
Our authentication system issues each connected app a temporary access badge (JWT) that expires every 15 minutes. Instead of forcing a full re-login every 15 minutes, apps use a separate, longer-lived refresh badge to quietly request a new access badge in the background — customers never notice the swap happening.
If a customer's action, like submitting a payment, gets sent to our servers twice because of a shaky internet connection, our system recognizes it's the same request and only processes it once. This means customers can safely retry an action that seems to have failed without worrying about being double-charged or creating a duplicate order.
Where to Be Careful
- Don't say retries are “instant” — there's a brief window, usually under two seconds, where a retry landing in that exact window could still create a duplicate. Say “extremely reliable,” not “guaranteed.”
- The 15-minute token expiry is fixed and cannot be extended per customer request. If a prospect asks for longer sessions, the answer is no — not “we can configure that.”
- Refresh tokens can be revoked instantly (for example, if a device is reported stolen), but the currently active access token will still work for up to 15 minutes after revocation. Don't promise instant logout across every device.
مستندات فنی و افرادی که باید بر اساس آن عمل کنند معمولاً دو مخاطب متفاوت هستند، و اکثر تلاش‌های ترجمه به یکی از دو روش قابل‌پیش‌بینی شکست می‌خورند: یا آنقدر ساده می‌شوند که از نظر فنی نادرست می‌شوند، یا هر جزئیات را حفظ می‌کنند و در نهایت به همان اندازه اصل متراکم می‌مانند. این پرامپت برای اجتناب از هر دو حالت شکست ساخته شده است.
چرا این ساختار اهمیت دارد
بخش واژه‌نامه وجود دارد چون اصطلاحات ناآشنا اولین چیزی هستند که باعث می‌شوند خواننده تسلیم شود. بازنویسی به زبان ساده عمداً تقریباً در همان طول متن اصلی محدود شده: مدل‌های هوش مصنوعی بدون محدودیت تمایل دارند توضیحات را با پرکننده‌های اطمینان‌بخش پر کنند.
بخش سوم، «کجا باید مراقب بود»، بخشی است که اکثر تلاش‌های ساده‌سازی به‌طور کامل از آن صرف‌نظر می‌کنند، و احتمالاً مهم‌ترین بخش است. ساده کردن یک توضیح فنی تقریباً همیشه به معنای از دست دادن برخی جزئیات است.
چرا فیلدهای زمینه‌ای داخل کروشه اهمیت دارند
پرامپت مخاطب هدف و کاری که باید با این اطلاعات انجام دهد را می‌خواهد، نه فقط اینکه چه کسی هستند.
کجا این پرامپت ارزش خود را ثابت می‌کند
این پرامپت برای مستندات API، گزارش‌های امنیتی و انطباق، راهنماهای زیرساخت، و هر مشخصات فنی داخلی که یک تیم غیرفنی باید بدون انتظار برای توضیح زنده یک مهندس بر اساس آن عمل کند، بسیار مفید است.