حذفکننده اصطلاحات فنی: تبدیل مستندات مهندسی به توضیحی آماده فروش
Why this prompt matters
Sales and customer-success teams that can't accurately translate technical capabilities into plain language either oversell (creating support tickets and churn when reality doesn't match the pitch) or undersell (losing deals to a competitor whose team explained the same feature with more confidence). A single garbled technical explanation in an enterprise sales call can stall a deal by weeks while procurement seeks clarification from engineering directly.
What we use it for
Your engineering team just shipped a new rate-limiting change to the API, and your account executive has a call with a Fortune 500 procurement team in two hours who will ask what this means for their integration timeline and reliability.
Prompt
Act as a senior technical writer who specializes in translating complex engineering and product documentation for non-technical stakeholders without losing accuracy or making misleading simplifications. CONTEXT: Original document: [PASTE YOUR TECHNICAL DOCUMENT OR EXCERPT HERE] Original audience: [WHO THIS WAS WRITTEN FOR, e.g. "backend engineers" or "DevOps team"] Target audience: [WHO NEEDS TO UNDERSTAND IT NOW, e.g. "enterprise sales team" or "non-technical executives"] What they need to do with this information: [SPECIFIC GOAL, e.g. "explain this feature to a customer during a sales call" or "approve a budget request based on this capability"] TASK: Rewrite the document for the target audience above. Preserve every fact, number, and constraint from the original — you are translating the language, not the content. Where a concept genuinely requires a technical term, keep the term but add a one-line plain-English explanation next to its first use. CONSTRAINTS: - Do not oversimplify to the point where a follow-up question would reveal your explanation was misleading - Keep exact numbers, version numbers, dates, and technical thresholds unchanged - Do not use metaphors or analogies that break down under a single follow-up question — test each one mentally before using it - Do not remove caveats, limitations, or edge cases that were in the original — restate them in plain language instead - Target reading level: educated professional with zero domain-specific background, not a general consumer audience OUTPUT FORMAT: 1. **Rewritten Document** — the full translated version, same structure as the original (same headers/sections) 2. **Jargon Glossary** — a table with three columns: Original Term | Plain-English Explanation | Why It Matters (one line each) 3. **Questions This Might Raise** — 3-5 follow-up questions a non-technical reader would likely ask after reading, each with a one-sentence answer, so the target audience can pre-empt them in conversation Length target: [DESIRED LENGTH, e.g. "under 400 words" or "match original length"]
Result
Input (excerpt from an engineering doc): "The API implements token bucket rate limiting with a refill rate of 100 requests/minute and a burst capacity of 250. On 429 responses, clients should implement exponential backoff with jitter, starting at 500ms, capped at 30s, with a maximum of 5 retry attempts before surfacing a hard failure to the caller."
1. Rewritten Document:
Our API limits how many requests a customer's system can send us to keep the service fast and reliable for everyone. Think of it like a parking garage with 250 spaces: customers can burst in quickly up to that limit, but the garage only lets in 100 new cars per minute on average after that. If a customer sends requests too fast and gets turned away, their system is designed to automatically wait a moment and try again — starting with a half-second pause, and waiting longer each time it's turned away again, up to a maximum 30-second wait. After 5 tries, if it still hasn't gotten through, the customer's system will show an error instead of waiting forever. This means customers rarely notice rate limiting during normal use — it only becomes visible if they're sending an unusually high volume of requests at once.
2. Jargon Glossary:
| Original Term | Plain-English Explanation | Why It Matters |
|---|---|---|
| Token bucket rate limiting | A system that allows quick bursts of activity but caps the average rate over time | Customers can burst up to 250 requests instantly, not just 100/minute flat |
| 429 response | An error code meaning "you're sending requests too fast, please slow down" | This is expected behavior, not a bug — customers' systems should handle it automatically |
| Exponential backoff with jitter | Waiting progressively longer between retries, with small random variation | Prevents thousands of customer systems from all retrying at the exact same moment and overwhelming us again |
3. Questions This Might Raise:
- Will customers see errors during normal use? No — 250 requests in a burst covers virtually all normal usage patterns; this only triggers under sustained high volume.
- What happens after 5 failed retries? The customer's application shows a clear error rather than hanging indefinitely, so their team can investigate.
- Can we raise these limits for a specific customer? Yes, rate limits are configurable per API key — that's a conversation for the account team, not an engineering blocker.
- Does this slow down the API for everyone else? No — it protects overall system performance, which is why average response times stay consistent even during traffic spikes.
هر شرکت در حال رشد با یک مسئله ترجمه یکسان روبهرو میشود: افرادی که محصول را میسازند به زبانی متفاوت از افرادی صحبت میکنند که آن را میفروشند، پشتیبانی میکنند یا تأمین مالی میکنند. مستندات مهندسی دقیقاند اما برای یک نماینده فروش که بیست دقیقه دیگر تماسی دارد غیرقابلنفوذ هستند. متن بازاریابی خوانا است اما اغلب از آنچه محصول واقعاً انجام میدهد فاصله میگیرد. این پرامپت دقیقاً بین این دو حالت شکست ساخته شده است.
چرا این پرامپت اینطور ساختاربندی شده
دستور نقش — «نویسنده فنی»، نه «بازاریاب» یا «کپیرایتر» — بیش از آنچه بهنظر میرسد اهمیت دارد. یک بازاریاب برای هیجان بهینه میکند؛ یک نویسنده فنی برای دقتی بهینه میکند که یک غیرمتخصص هنوز بتواند آن را دنبال کند. همین تمایز است که خروجی را صادق نگه میدارد نه براق.
بخش زمینه چهار ورودی مشخص را الزامی میکند: سند منبع، چه کسی آن را نوشته، چه کسی اکنون باید آن را بخواند و با این اطلاعات چه خواهد کرد. رد کردن هرکدام از اینها خروجی عمومی و غیرقابلاستفاده تولید میکند. «این را ساده توضیح بده» بدون دانستن هدف مخاطب، توضیحی ساده اما بیپاسخ به سؤال واقعی خواننده تولید میکند.
بخش محدودیتها کار واقعی جلوگیری از خروجی بد را انجام میدهد. «بیشازحد ساده نکن تا جایی که یک سؤال بعدی نشان دهد توضیحت گمراهکننده بوده» مهمترین خط این پرامپت است — این همان چیزی است که مدل را از تولید استعارهای که تمیز بهنظر میرسد اما بهمحض پرسیدن سؤالی واقعی فرو میریزد، بازمیدارد. الزام به حفظ اعداد دقیق و ملاحظات در بازنویسی، از حالت شکست رایجی جلوگیری میکند که در آن یک توضیح سادهشده بیسروصدا استثنای مهم را حذف میکند.
چرا قالب خروجی شامل واژهنامه و سؤالات پیشبینیشده است
بیشتر پرامپتهای سادهسازی اصطلاحات فنی در پاراگراف بازنویسیشده متوقف میشوند. این پرامپت عمداً اینطور نیست، چون پاراگراف بازنویسیشده بهتنهایی کسی را برای یک مکالمه زنده آماده نمیکند. جدول واژهنامه به خواننده مرجعی سریع میدهد اگر اصطلاحی بعداً دوباره مطرح شود. بخش «سؤالاتی که ممکن است مطرح شوند» باارزشترین بخش خروجی است: پیشبینی میکند یک غیرمتخصص باهوش در ادامه چه خواهد پرسید و پاسخ را از پیش بار میکند، تا خواننده وارد جلسهای آماده شود نه اینکه زیر فشار بداههپردازی کند.
چگونه آن را تطبیق دهیم
این پرامپت برای هر شکاف مخاطبی کار میکند: مهندسی به فروش، حقوقی به محصول، مالی به همه. فیلدهای مخاطب هدف و هدف را جایگزین کنید، همان ساختار برقرار میماند. برای اسناد منبع بسیار طولانی، آن را بخشبهبخش اجرا کنید نه یکجا — مدل بخشهای متمرکز و کامل را قابلاعتمادتر از یک عبور واحد روی ده صفحه محتوای متراکم مدیریت میکند.