مُزيل المصطلحات: حوّل الوثائق التقنية الكثيفة إلى شيء يمكن لغير المهندس استخدامه فعلاً
لماذا تهم هذه المطالبة
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، وتقارير الأمن والامتثال، وأدلة تشغيل البنية التحتية، وأي مواصفات تقنية داخلية يحتاج فريق غير هندسي للتصرف بناءً عليها دون انتظار شرح حي من مهندس.