مترجم کد برای سهامداران: یک Pull Request را به یک گزارش ریسک به زبان ساده برای غیرمهندسان تبدیل کنید
چرا این پرامپت اهمیت دارد
Teams that let PMs or execs approve irreversible changes based on a one-line Slack summary routinely discover the real risk only after an incident -- a “simple delete feature” that wipes dispute evidence, or a “quick migration” that corrupts production data. Post-incident reviews cost engineering teams dozens of hours and erode trust between product and engineering; a 3-minute plain-English briefing before approval is far cheaper than a retro after the fact.
ما از آن برای چه استفاده می‌کنیم
You're a product manager looped into a Slack thread where an engineer says “small PR, just a delete feature, should be fine to ship today” -- you need to decide within the next 10 minutes whether to approve it before the sprint deadline, without being able to read the diff yourself.
پرامپت
Act as [YOUR ROLE: e.g., a senior backend engineer] who is skilled at translating technical changes into language a product manager, executive, or client can act on without a computer science background. CONTEXT: - System/feature this code touches: [NAME OF SYSTEM OR FEATURE] - Who depends on it: [TEAMS/CUSTOMERS WHO USE THIS] - Business context for this change: [WHY WE ARE SHIPPING THIS -- bug fix, new feature, compliance requirement, etc.] Below is the pull request / code change to review: [PASTE DIFF, PR DESCRIPTION, OR CODE CHANGE HERE] TASK: Produce a plain-English risk briefing that a non-engineer stakeholder can read in under 3 minutes and use to decide whether to approve, delay, or ask more questions before this ships. CONSTRAINTS: - Do not use unexplained jargon. If you must use a technical term (e.g., "race condition," "database migration"), define it in one plain-language clause the first time it appears. - Do not minimize risk to sound reassuring. If the change touches payments, authentication, data deletion, or anything irreversible, say so explicitly even if the author's PR description downplays it. - Do not praise the code quality or offer a code review -- that is not the task. Stay focused on business-relevant risk and impact. - If the diff is incomplete or you can't determine what a function does, say what's unclear instead of guessing. - Keep the whole briefing under [MAX WORD COUNT, e.g., 400] words. OUTPUT FORMAT: 1. What changed -- 2-3 sentences, in plain English, no code terms. 2. Who is affected -- which users, teams, or systems feel this change, and how. 3. What could go wrong -- the 2-4 most realistic failure scenarios, ranked by how bad they'd be if they happened, each with a one-line explanation of why. 4. Reversibility -- can this be rolled back quickly if something breaks, or is it a one-way door (e.g., a data migration, a deleted table, a third-party API commitment)? 5. Recommendation -- one of: Safe to approve / Approve with monitoring / Needs more testing before approval / Needs a second technical opinion -- with one sentence of justification.
نتیجه
What changed
This pull request adds a new "Delete My Account" button to account settings that, when clicked, permanently erases a customer's profile, saved payment methods, and order history from the production database. Previously, deleting an account only deactivated the login -- the underlying records stayed in the system.
Who is affected
Any customer who clicks this button going forward. It also affects the Support team, who can no longer look up a deleted customer's past orders to resolve disputes or refunds, and Finance, since deleted orders will disappear from revenue reports for that customer's history.
What could go wrong
1. (Highest risk) A customer disputes a charge after deleting their account -- Support will have no order record to investigate it, because the deletion is immediate and irreversible, not a 30-day soft-delete.
2. A customer accidentally clicks "Delete" instead of "Deactivate" (the buttons are visually similar in this PR) -- there is no confirmation step requiring them to type their email or password.
3. The deletion runs inside the same database transaction as nine other tables. If one of those deletes fails partway through, the code does not roll back the whole transaction -- it could leave a customer in a partially-deleted, broken state.
Reversibility
This is a one-way door. There is no backup-before-delete step in this PR, and no "undo" window. Once a customer clicks delete, the data is gone from production immediately.
Recommendation
Needs more testing before approval. The missing confirmation step and the lack of a grace period before permanent deletion are launch blockers for a feature this irreversible -- not just nice-to-haves.
مشکلی که این پرامپت حل می‌کند
بسیاری از ابزارهای بازبینی کد و دستیارهای کدنویسی مبتنی بر هوش مصنوعی برای مهندسانی طراحی شده‌اند که کد مهندسان دیگر را بررسی می‌کنند. اما در عمل، بسیاری از تغییرات پرریسک توسط کسی تأیید می‌شوند که اصلاً diff را نمی‌خوانَد؛ مدیر محصولی که یک اسپرینت را تأیید می‌کند، بنیان‌گذاری که راه‌اندازی یک محصول را تصویب می‌کند، یا مسئول ارتباط با مشتری که تغییر یک تأمین‌کننده را می‌پذیرد. آن‌ها معمولاً فقط یک خلاصهٔ یک‌خطی در Slack دریافت می‌کنند («یک Pull Request کوچک است، فقط یک قابلیت حذف است») و باز هم باید تصمیم بگیرند. این پرامپت برای این ساخته شده که به آن فرد چیزی بهتر از یک حس شخصی بدهد.
چرا این ساختار کار می‌کند
این پرامپت به‌جای یک خلاصهٔ آزاد، پنج بخش ثابت را الزامی می‌کند؛ زیرا خلاصهٔ آزاد به هوش مصنوعی (یا حتی یک انسان) اجازه می‌دهد تا تنها جملهٔ نگران‌کننده را در میان یک پاراگراف دفن کند. بخش‌های «چه چیزی تغییر کرده» و «چه کسی تحت تأثیر قرار می‌گیرد» زمینه را بدون اصطلاحات فنی مشخص می‌کنند. بخش «چه چیزی می‌تواند اشتباه پیش برود» به دو تا چهار سناریوی واقع‌بینانه‌تر، رتبه‌بندی‌شده بر اساس شدت، محدود می‌شود؛ نه فهرستی جامع که ریسک واقعی را در میان فرضیات غیرضروری غرق کند.
بخش «قابلیت بازگشت» عمداً به‌صورت مستقل آمده است. مهندسان به‌طور طبیعی تفاوت میان یک فلگ تنظیمات که در پنج دقیقه قابل بازگشت است و یک migration پایگاه‌داده که ردیف‌ها را برای همیشه حذف می‌کند را می‌دانند؛ اما این تفاوت به‌ندرت در ترجمهٔ یک پیام Slack باقی می‌ماند. افراد غیرفنی باید این موضوع را به‌صورت یک پرسش بله/خیر مستقل ببینند، زیرا این مهم‌ترین عاملی است که باید میزان دقت بررسی پیش از تأیید را تغییر دهد.
چرا محدودیت‌ها اهمیت دارند
محدودیت «ریسک را برای اطمینان‌بخشی کم‌رنگ نکن» به این دلیل وجود دارد که توضیحات Pull Request را همان فردی می‌نویسد که می‌خواهد کدش ادغام شود؛ آن‌ها به‌طور پیش‌فرض خوش‌بین هستند، نه غیرصادق، اما خوش‌بین. دستیار هوش مصنوعی‌ای که این خوش‌بینی را بازتاب دهد، به‌عنوان یک ابزار بررسی بی‌فایده است. محدودیتی که از نظردادن درباره کیفیت کد جلوگیری می‌کند، خروجی را متمرکز نگه می‌دارد: این یک بازبینی کد نیست، بلکه یک گزارش تصمیم‌گیری برای کسی است که هرگز فایل را باز نخواهد کرد.
چگونه از آن به‌درستی استفاده کنیم
diff واقعی یا توضیحات Pull Request را وارد کنید، نه فقط عنوان آن؛ مدل نمی‌تواند ریسکی را که نمی‌بیند ارزیابی کند. مشخص کنید چه کسانی به سیستمی که تغییر می‌کند وابسته هستند؛ بخش «چه کسی تحت تأثیر قرار می‌گیرد» تنها به‌اندازهٔ زمینهٔ کسب‌وکاری‌ای که ارائه می‌دهید دقیق خواهد بود. و این توصیهٔ چهارگزینه‌ای را نقطهٔ شروع گفتگو با مهندس در نظر بگیرید، نه جایگزین آن؛ این پرامپت فیلتری برای تشخیص کدام Pull Requestها به پنج دقیقهٔ توجه بیشتر شما نیاز دارند است، نه رأی نهایی.