مترجم پیام برای مخاطبان چندگانه: یک بهروزرسانی، سه نسخه برای مدیران، همکاران و تیم شما
چرا این پرامپت اهمیت دارد
Miscalibrated communication is one of the most common and costly leadership failures: send peer-level technical detail to an executive and the one number they needed gets buried in three paragraphs of jargon; send the executive-level summary to your own team and they're left without the specifics they need to actually change what they're doing this week. The failure mode isn't that information wasn't sent — it's that it arrived at the wrong altitude, which forces a second round of clarifying messages, meetings, and erodes trust when the details that were technically disclosed still feel like a surprise later.
ما از آن برای چه استفاده میکنیم
A sprint retro just wrapped and you have five bullet points of raw notes: the payment vendor changed their API without notice, the auth integration slipped two weeks, there's no budget impact, and two engineers need to be reassigned starting today. You have 20 minutes before your next meeting to tell your VP, your peer team lead, and your own team — and each of them needs a completely different version of the same facts.
پرامپت
Role: Act as an executive communications coach who specializes in helping technical and operational leaders adapt one core update for different audiences without changing the underlying facts. Context: I need to communicate one update to three different audiences who each need a different altitude of detail and a different call to action. Here is the raw update: [PASTE YOUR RAW UPDATE OR NOTES HERE] The three audiences are: 1. [EXECUTIVE AUDIENCE — e.g., "VP of Engineering, cares about timeline and budget impact"] 2. [PEER AUDIENCE — e.g., "fellow team leads, need technical detail and cross-team dependencies"] 3. [DIRECT REPORT AUDIENCE — e.g., "my team, needs to know what changes for them this week"] Task: Produce three versions of this update, one for each audience above. Each version must: - Lead with the single most relevant fact for that audience in the first sentence - Use vocabulary and detail level appropriate to that audience's role - End with a clear "what I need from you" or "what happens next" line - Preserve every material fact from the original notes — do not omit risks, delays, or costs to make any version sound better than the facts support Constraints: - Do not invent details not present in [PASTE YOUR RAW UPDATE OR NOTES HERE] - Keep the executive version under 150 words - Keep the peer version under 250 words, including any technical specifics that matter for their planning - Keep the direct-report version conversational, not corporate — write it the way you'd actually talk to your team - Flag explicitly (in brackets) any place where you had to infer missing context, so I can correct it before sending - Do not use hedge-phrase openers like "just wanted to check in" or "quick update" Output Format: ## Executive Version [150 words max] ## Peer Version [250 words max] ## Direct Report Version [conversational, no strict word limit] ## Flagged Assumptions [bullet list of anything you inferred rather than found in the source notes]
نتیجه
Executive Version
The auth integration is delayed two weeks due to an unannounced breaking change in our payment vendor's API — not a scope or execution issue on our side. No budget impact; we're absorbing the delay within the current sprint buffer. Revised ship date: August 13. I need your sign-off to communicate the new date externally by end of day Friday.
Peer Version
Heads up for anything that depends on the auth service: our payment vendor deprecated the webhook signature method we were using without a deprecation notice reaching us in time, so we're mid-rewrite of the signature verification layer. This pushes our auth integration ship date from July 30 to August 13. If your team has anything gated on our auth endpoints being stable, plan around August 13, not July 30. The webhook payload shape isn't changing, only the internal verification method, so no action needed on your side unless you're calling our endpoints directly during the transition window — in which case ping me and we'll coordinate a freeze window.
Direct Report Version
Quick context on why priorities shift this week: our payment vendor changed how webhook signatures work and didn't give us enough notice, so the auth rewrite we thought was basically done needs another pass on the verification layer. That's a two-week slip, not because anyone dropped the ball, but because the ground moved under us. [NAME] and [NAME], I need you focused on the signature verification rewrite starting today — I'll move the dashboard polish work to next sprint to make room. Nobody's weekend plans should change; this is a reprioritization, not a crunch.
Flagged Assumptions
- Assumed the delay has genuinely zero budget impact — confirm before sending the executive version
- Assumed [NAME] and [NAME] are the right two engineers to reassign — adjust if wrong
- Assumed August 13 is achievable — verify with the team before committing that date externally
یک بهروزرسانی وضعیت معمولاً باید به سه گروه مختلف از مخاطبان برسد. بیشتر افراد یا یک نسخه عمومی برای همه میفرستند یا زیر فشار زمان سه بار آن را دستی بازنویسی میکنند. دقیقاً در همین لحظه است که مهمترین جزئیات حذف میشود. یک مدیر اجرایی که توضیح فنی دو پاراگرافی را مرور میکند، همان عددی را که اهمیت دارد از دست میدهد. یک تیم همکار که خلاصه اجرایی میخواند، جزئیات وابستگی مشخصی را که برای برنامهریزی نیاز داشتند دریافت نمیکند. و یک گزارشگیرنده مستقیم که متنی رسمی میخواند، نمیفهمد که دوشنبه چه چیزی واقعاً برایش تغییر میکند.
این پرامپت نسخه دشوارتر این مشکل را حل میکند: به شما اجازه نمیدهد سه پیام نامرتبط بنویسید. بلکه همه سه نسخه را مجبور میکند از یادداشتهای خام یکسانی نشأت بگیرند و هر واقعیت مادی را حفظ کنند — از جمله بخشهایی که بهروزرسانی را بدتر نشان میدهند. این محدودیت مهمتر از آن چیزی است که به نظر میرسد. وسوسهانگیز است که نسخه اجرایی را با حذف آرام یک احتیاط یا نادیده گرفتن یک ریسک که روایت تمیز نسخه همکار را پیچیده میکند، نرم کنید. پرامپت به طور صریح این کار را مسدود میکند: واقعیتهای مادی، به ویژه واقعیتهای نامطلوب، باید در ترجمه به هر نسخه زنده بمانند، فقط با توجه به مرتبط بودن فیلتر شوند و در ارتفاع فنی مناسب برای آن خواننده بیان شوند.
بخش 'Flagged Assumptions' در انتها بخشی است که بیشتر افراد وقتی خودشان چنین پرامپتی مینویسند از آن صرفنظر میکنند. و این همان بخشی است که از بیشترین آسیب جلوگیری میکند. هر مدل هوش مصنوعی که برای پر کردن یک پیام حرفهای درخواست شود، بیصدا جزئیات قابل قبولی را اختراع میکند — یک نام، یک تاریخ، یک رقم دلاری — اگر یادداشتهای منبع مشخص نکنند. اجبار این استنتاجها به یک لیست مجزا و قابل مشاهده به این معنی است که شما یک حدس اشتباه را قبل از اینکه در ایمیلی به معاون شما برود، میگیرید، به جای اینکه بعد از اینکه قبلاً فرستاده شده است.