مترجم غیرفنی کد: هر تغییر در پایگاه کد را به یک گزارش ساده به زبان مدیران تبدیل کنید
Why this prompt matters
When engineers describe technical work in technical language, non-technical decision-makers either disengage entirely or approve budgets, headcount, and roadmaps based on a garbled mental model of what was actually built. That gap gets expensive in three specific places: incident postmortems executives can't follow, board meetings where a legitimate architecture investment gets mistaken for gold-plating and gets cut, and performance cycles where genuinely hard engineering work reads on paper as 'nothing visible shipped.' A five-minute plain-English briefing, prepared once with a structured prompt, prevents all three.
What we use it for
Your engineering team just finished a six-week rebuild of the checkout service, and tomorrow morning you present it to the VP of Product and two board members who have no engineering background. You have fifteen minutes to explain what changed, why it mattered, and what risk remains, and if you reach for words like 'idempotency' or 'horizontal scaling' you will lose the room in the first sentence.
Prompt
Act as a technical communication specialist who translates complex engineering work into clear, accurate briefings for non-technical audiences — executives, board members, product managers, and sales leaders who need to make decisions based on your explanation, not admire your vocabulary. CONTEXT: - System or change being explained: [DESCRIBE THE CODE, FEATURE, MIGRATION, OR INCIDENT — e.g. "rebuilt the checkout service's payment retry logic"] - Audience: [WHO YOU ARE BRIEFING — e.g. "VP of Product and two board members, no engineering background"] - Business stakes: [WHY THIS MATTERS COMMERCIALLY — e.g. "reduces failed payment retries that were costing ~$40K/month in lost orders"] - Known risks or open questions: [WHAT COULD STILL GO WRONG OR IS UNRESOLVED — e.g. "not yet load-tested above 3x current peak traffic"] - Meeting format: [LENGTH AND SETTING — e.g. "10-minute slot in a 45-minute board meeting, no slides allowed"] TASK: Produce a plain-English briefing with five parts: 1. A one-sentence executive summary stating what was done and why it matters, in language a non-technical reader understands on first read. 2. An explanation of what changed, built entirely around a real-world analogy (not a technical diagram or code reference). 3. Why it matters to the business — tie directly to cost, revenue, risk, or customer experience, using the business stakes provided above. 4. Remaining risks or unknowns, stated honestly — do not create false confidence where none exists. 5. Three questions this specific audience is likely to ask, each with a prepared, non-defensive answer. CONSTRAINTS: - No jargon, acronyms, or technical terms without an immediate plain-English definition in the same sentence. - No code snippets, architecture diagrams, or system names unless the audience specifically asked for them. - Total length under 400 words — executives lose patience past that. - Match tone and formality to the audience described above; a board gets more formal language than a product manager. - If something is genuinely uncertain or unresolved, say so plainly rather than papering over it with confident-sounding hedges. OUTPUT FORMAT: ## Executive Summary [1-2 sentences] ## What Changed [Analogy-based explanation, 2-4 sentences] ## Why It Matters [2-3 sentences tied to business stakes] ## Risks & Unknowns [Bulleted, honest, 2-4 items] ## Anticipated Questions Q1: [likely question] — A: [prepared answer] Q2: [likely question] — A: [prepared answer] Q3: [likely question] — A: [prepared answer]
Result
Example output — checkout service payment retry rebuild
Executive Summary
We rebuilt how the checkout system handles failed card payments, cutting lost sales from temporary payment glitches by an estimated $35,000-$40,000 per month, with no changes visible to customers.
What Changed
Think of the old system like a cashier who, when a card gets declined for a split-second network hiccup, just tells the customer "sorry, try again" and walks away — even though the card was actually fine. The new system is a cashier who quietly waits a moment, tries the same card again automatically up to three times using slightly different timing, and only gives up if the card is genuinely declined. Customers whose payments would have failed due to a brief network blip now go through without ever knowing there was a problem.
Why It Matters
Roughly 4% of checkout attempts were hitting these transient failures, and most of those customers didn't come back to try again — that's real revenue walking away over what was often a one-second network issue, not an actual declined card. Recovering even half of those failed attempts is worth well over $400,000 annualized, against an engineering cost of roughly six weeks of one team's time.
Risks & Unknowns
- We've tested this at up to 3x our current peak Black Friday traffic; we have not tested it at higher multiples, so a much larger-than-expected surge is still an open risk.
- The retry logic adds about 200 milliseconds to failed-then-recovered transactions — invisible to customers, but something to monitor if it ever creeps higher.
- We're relying on our payment processor's data to identify which failures are "transient" versus genuinely declined; if their classification is wrong in edge cases, we could occasionally retry a payment that should have been rejected outright.
Anticipated Questions
Q1: Could this accidentally charge a customer's card multiple times? — A: No. Each retry checks first whether the previous attempt actually succeeded before trying again, so a customer is never charged twice for one purchase.
Q2: Why did this take six weeks instead of two? — A: Four of the six weeks went into testing every failure scenario against our live payment processor in a safe sandbox environment, since a mistake here directly touches real money and real customers.
Q3: What happens during a real payment processor outage, not just a blip? — A: The system detects sustained failures and stops retrying after three attempts within ten seconds, falling back to the same "please try again" message customers saw before — so a genuine outage behaves exactly as it did previously, just with no downside risk added.
نمونه خروجی — بازسازی سیستم تلاش مجدد پرداخت سرویس پرداخت
خلاصه اجرایی
ما نحوه برخورد سیستم پرداخت با تراکنشهای ناموفق کارت را بازسازی کردیم و با رفع اختلالات موقتی، از ضرر حدود ۳۵,۰۰۰ تا ۴۰,۰۰۰ دلار در ماه جلوگیری کردیم، بدون آن که تغییری برای مشتریان محسوس باشد.
چه تغییری کرد
سیستم قدیمی را مانند صندوقداری تصور کنید که وقتی کارت به دلیل یک قطعی لحظهای شبکه رد میشود، فقط به مشتری میگوید «متأسفم، دوباره تلاش کنید» و کنار میرود — در حالی که کارت در واقع معتبر بوده است. سیستم جدید مانند صندوقداری است که لحظهای صبر میکند، همان کارت را تا سه بار بهطور خودکار با زمانبندی متفاوت دوباره امتحان میکند و تنها در صورت رد واقعی کارت صرفنظر میکند. مشتریانی که پرداختشان به دلیل یک قطعی کوتاه شبکه ناموفق میشد، اکنون بدون آن که متوجه وجود مشکل شوند، تراکنششان انجام میشود.
چرا مهم است
حدود ۴٪ از تلاشهای پرداخت با این شکستهای گذرا مواجه میشدند و بیشتر آن مشتریان برای تلاش مجدد بازنمیگشتند — این یعنی درآمد واقعی که به دلیل یک مشکل یکثانیهای شبکه از دست میرفت، نه رد واقعی کارت. بازیابی حتی نیمی از این تلاشهای ناموفق، سالانه بیش از ۴۰۰,۰۰۰ دلار ارزش دارد، در مقابل هزینه مهندسی حدود شش هفته زمان یک تیم.
ریسکها و موارد ناشناخته
- ما این سیستم را تا ۳ برابر ترافیک فعلی در اوج جمعه سیاه آزمایش کردهایم؛ اما در چندبرابر بالاتر آزمایش نشده است، بنابراین افزایش ناگهانی بسیار بزرگتر از حد انتظار همچنان یک ریسک باز است.
- منطق تلاش مجدد حدود ۲۰۰ میلیثانیه به تراکنشهای ناموفق سپس موفق اضافه میکند — برای مشتری نامرئی است، اما باید در صورت افزایش آن تحت نظر باشد.
- ما برای تشخیص شکستهای «گذرا» در مقابل رد واقعی به دادههای ارائهدهنده پرداخت متکی هستیم؛ اگر طبقهبندی آنها در موارد مرزی اشتباه باشد، ممکن است گاهی پرداختی را دوباره امتحان کنیم که باید مستقیماً رد میشد.
سوالات پیشبینی شده
س۱: آیا این کار ممکن است بهطور تصادفی کارت مشتری را چندین بار شارژ کند؟ — پاسخ: خیر. هر تلاش مجدد ابتدا بررسی میکند که آیا تلاش قبلی واقعاً موفق شده است یا نه، بنابراین مشتری هرگز برای یک خرید دو بار شارژ نمیشود.
س۲: چرا این کار شش هفته طول کشید نه دو هفته؟ — پاسخ: چهار هفته از شش هفته صرف آزمایش هر سناریوی شکست در مقابل ارائهدهنده پرداخت واقعی در یک محیط sandbox امن شد، زیرا هر اشتباهی مستقیماً پول واقعی و مشتریان واقعی را تحت تأثیر قرار میدهد.
س۳: در زمان قطعی واقعی ارائهدهنده پرداخت، نه فقط یک قطعی لحظهای، چه اتفاقی میافتد؟ — پاسخ: سیستم شکستهای مداوم را تشخیص میدهد و پس از سه تلاش ظرف ده ثانیه متوقف میشود و به همان پیام «لطفاً دوباره تلاش کنید» که قبلاً مشتریان میدیدند بازمیگردد — بنابراین یک قطعی واقعی دقیقاً مانند قبل عمل میکند، بدون افزودن ریسک اضافی.