تصور کنید یک پرامپت بینقص، فاجعهای ایجاد کند که در ظاهر کاملاً درست به نظر میرسد. این هسته مرکزی یادداشتی است که در ۲۶ سپتامبر ۲۰۲۶ در وبسایت dev.to منتشر شد و ادعا میکند وسواس فعلی صنعت روی مهندسی پرامپت (Prompt Engineering) — که شبیه تلاش برای یادگیری جادوی کلمات برای متقاعد کردن یک غول است — در واقع دنبال کردن مهارت اشتباهی است.
سالهاست توسعهدهندگان با پرامپتنویسی مثل یک سواد جدید برخورد میکنند. آنها کتابخانههایی از پرامپتهای «۱۰ برابر ساز» جمع میکنند و مهندسی زمینه (Context Engineering) را طوری میخوانند که انگار یک قلعه دفاعی برای شغلشان است. نویسنده از پوشهای در نشانهها (Bookmarks) با ۴۱ تب میگوید که عناوینی مثل «۱۲ پرامپت برای ۱۰ برابر کردن بازدهی مهندسی»، «مهندسی زمینه برای عاملها، به زبان ساده» و «پرامپت سیستمی که نحوه عرضه محصول من را تغییر داد» دارد. برخی حتی تا ساعت ۱ بامداد دورههای آموزشی میگذرانند، با این باور که اگر فقط یاد بگیرند چطور درستتر بپرسند، خروجی بالاخره درست خواهد بود.
این طرز فکر فرض میکند که پرسش بهتر به حقیقت بهتر منجر میشود. اما در واقعیت، با هر بهروزرسانی مدل، فاصله بین یک مبتدی و یک متخصص در پرامپتنویسی کمتر میشود، چون آزمایشگاههای هوش مصنوعی در حال بهینهسازی مدلها برای استنباط قصد کاربر (Intent Inference) هستند. همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، تکیه بر رفتارهای سطحی مدلها ریسکهای پنهانی دارد. نویسنده این وضعیت را به ساختن یک گیتهاب پر از مخازن مرده تشبیه میکند؛ یعنی شما متقاعد شدهاید مهارتی که همه دارند به شما میفروشند، همان مهارت کمیاب است، در حالی که در حقیقت، مهارت در پرامپتنویسی یعنی مهارت در چیز اشتباه.
فرض کنید در حال ساخت یک سیستم پیچیده هستید. از یک مدل سطح بالا برای تولید یک قطعه کد حیاتی استفاده میکنید. خروجی تمیز است، ساختار آن در سطح یک مهندس ارشد است و تمام تستهایی که به ذهنتان رسیده را پاس میکند. کد را ادغام میکنید و سیستم در محیط عملیاتی شکست میخورد، چون یک «شرایط رقابتی» (Race Condition) وجود داشت که هوش مصنوعی به آن فکر نکرده بود. یک پرامپت بهتر شما را نجات نمیداد؛ بلکه فقط کد را متقاعدکنندهتر میکرد و باعث میشد باگ سختتر شناسایی شود.
سه باور غلط درباره پرامپتنویسی
به نقل از تحلیل dev.to، هیچکس بدون دلیل وقت خود را صرف راهنماهای پرامپت نمیکند. توسعهدهندگان تحت تأثیر سه باور خاص هستند که همگی هدف اشتباهی را نشانه گرفتهاند:
- باور اول: خروجی را بهتر میکند. منطق این است که «پرامپت بهتر، کد بهتر. بدیهی است.» در حالی که این کار ساختار تمیزتر و اشتباهات ظاهری کمتری تولید میکند، اما هیچ کمکی به صحت (Correctness) واقعی کد نمیکند.
- باور دوم: من را استخدامپذیرتر میکند. این باور که «AI-native» بودن یا «مهندس پرامپت» بودن، یک قلعه دفاعی حرفهای ایجاد میکند.
- باور سوم: این سواد جدید است. این ایده که این مهارت بنیادی عصر است و عدم تسلط بر آن به معنای عقب ماندن از جریان است.
تله متقاعدکنندگی
طبق این گزارش، یک گسست بنیادی بین «متقاعدکننده بودن» یک پاسخ و «درست بودن» آن وجود دارد. پرامپتنویسی سؤال را بهینه میکند، اما باگ در پاسخ زندگی میکند. این دو پیچ تنظیم — متقاعدکنندگی و صحت — هرگز به هم متصل نبودند.
- پارادوکس صیقلخوردگی: پرامپتهای بهتر، کیفیت ظاهر خروجی را ارتقا میدهند. این یعنی «پوشش» یا ماسک روی خطا بیشتر میشود. یک پاسخ صیقلخوردهتر و مقتدرانهتر، وقتی غلط باشد، در واقع سختتر شناسایی میشود. خروجی کاملاً با درخواست مطابقت دارد و زیبا خوانده میشود، اما همچنان خراب است.
- شکاف بازبینی: صحت در زمان بازبینی (Review time) تعیین میشود، نه زمان پرسش (Ask time). این تصمیم در سمت میز شماست که آیا میتوانید به یک تغییر کد (Diff) تمیز و مطمئن، «نه» بگویید یا خیر.
- مغالطه بازیابی: مهندسی پرامپت در واقع همان بازیابی (Recall) — مثل حفظ کردن فرمولهای ریاضی برای حل مسئله — با یک کلاه جدید است. برای ۲۰ سال، کدنویسی ترکیبی از بازیابی (سینتکس، سطوح API، ترتیب فلگها و وردهای خاص) و قضاوت (دانستن اینکه چه چیزی ساخته شود، به چه چیزی بیاعتماد باشیم و چه چیزی ساعت ۲ صبح وقتی یک انسان واقعی کاری عجیب میکند میشکند) بود. هوش مصنوعی اول بازیابی را بلعید. حالا پرامپتنویسی فقط بازسازی بازیابی در سطحی بالاتر است؛ یعنی حفظ کردن «کلمات جادویی»، «الگوهای زمینه» و «وردهای پرامپت سیستمی» برای فعال کردن رفتارها.
کاهش نیمهعمر مهندسی پرامپت
از آنجا که پرامپتنویسی اساساً نوعی بازیابی سطح بالا است، نیمهعمر آن در حال کاهش است. نویسنده اشاره میکند که هر نسخه جدید از مدلها، قصد کاربر را بهتر از نسخه قبلی استنباط میکند. این یعنی فاصله بین پرامپت یک مبتدی و یک متخصص با هر آپدیت کمتر میشود.
بستن این شکاف دقیقاً همان چیزی است که آزمایشگاههای AI برای آن بهینهسازی میکنند. در نتیجه، توسعهدهندگان روی مهارتی وقت میگذارند که تامینکننده در حال حذف فعال آن است. شما نمیتوانید روی قابلیتی که تامینکننده در آپدیت فصل آینده آن را به صورت استاندارد عرضه میکند، قلعه دفاعی شغلی بسازید.
تنها مهارتی که ارزش سرمایهگذاری دارد
نویسنده استدلال میکند که تنها مهارتی که ارزش تمرین دارد، «بدبینی» (Distrust) است. این یک موضع بدبینانه یا سینیکی نیست، بلکه یک عضله حرفهای است که از طریق شکست به دست میآید. این همان رفلکسی است که باعث میشود به یک کد مطمئن نگاه کنید و بپرسید: «ساعت ۲ صبح وقتی ورودیها خصمانه باشند، اینجا چه اتفاقی میافتد؟»
این «بدبینی نهادینه شده» تنها بخشی از پشته هوش مصنوعی است که تامینکننده نمیتواند آن را به عنوان یک قابلیت عرضه کند. در حالی که هزینه پرسیدن به سمت صفر میرود، ارزش «رد کردن» — یعنی گفتن «نه» به یک پاسخ محتمل اما غلط — تبدیل به تمامِ شغل شما میشود. این مهارت با آموزش یا عبارتهای بهتر به دست نمیآید؛ بلکه با ارسال یک پاسخ مطمئن به کاربر واقعی، دیدن شکست آن، تحمل پیامدهایش و تبدیل آن زخم به تجربهای برای هر بازبینی بعدی به دست میآید.
یک شکست عینی: باگ تایید پیش از ذخیره
برای روشن شدن موضوع، نویسنده تجربهای شخصی را به اشتراک میگذارد: او مسیری برای نوشتن دادهها منتشر کرد که درخواست را تایید میکرد (Ack) پیش از آنکه داده واقعاً در پایگاهداده ذخیره (Persist) شود. پرامپتی که برای تولید کد استفاده شده بود تمیز بود و کد نهایی شبیه نوشته یک مهندس دقیق بود. در دمو، در تستها و روی ماشین محلی، همه چیز بینقص بود.
اما در محیط عملیاتی، یک تلاش مجدد (Retry) در لحظهای اشتباه رخ داد. سیستم تایید (Ack) را فرستاد اما ذخیره انجام نشد. در نتیجه، یک مشتری پرداختکننده از حساب خود بیرون انداخته شد بدون اینکه رکوردی از عملیاتش باشد.
هیچ مقدار مهندسی پرامپتی نمیتوانست جلوی این اتفاق را بگیرد؛ یک پرامپت بهتر فقط کد را تمیزتر و متقاعدکنندهتر میکرد و شک کردن به آن را سختتر میساخت. فقط رفلکس انسانی آموزشدیده میتوانست متوجه شود که «تایید پیش از ذخیره» در زمان Retry میشکند. این رفلکس تنها خطی در رزومه است که ارزش یک مصاحبه کامل را دارد، اما هیچ دورهای آن را نمیفروشد چون قابل آموزش نیست، بلکه باید «کسب» شود.
معماری شکاکیت
این فلسفه به نحوه ساخت عاملهای هوش مصنوعی (AI Agents) تعمیم مییابد. نویسنده که پلتفرم xenition را میسازد، میگوید صنعت فعلاً «نویسنده» (چیزی که تولید میکند) را میپرستد. اما نویسندهای که خروجی زیبا میدهد، فارغ از درست بودن آن، زیبا مینویسد.
برای مقابله با این موضوع، xenition از تفکیک سه لایه استفاده میکند:
۱. نویسنده: مدلی که کد را تولید میکند. هرچقدر میخواهید پرامپت بزنید، اما او بدترین داور برای کار خودش است چون به خروجیاش «افتخار» میکند.
۲. شکاک: یک فرآیند یا مدل مجزا که تنها وظیفهاش تلاش برای شکستن کد است، نه تحسین آن. این یعنی تبدیل «نه» به یک جایگاه مستقل.
۳. انسان: دروازهبان نهایی روی دکمه ادغام (Merge) که میتواند اثرات واقعی در دنیای واقعی (Blast Radius) را ببیند، چیزی که مدل قادر به دیدنش نیست.
با جدا کردن نویسنده از شکاک، تضمین میکنید کسی که پاسخ را تولید کرده، همان کسی نیست که آن را تایید میکند. پرامپت فقط هزینه ورودی ارزان است؛ اما «نه» گفتن، محصول واقعی است.
فراتر از کتابخانه پرامپتها
این تغییر تمرکز، توسعهدهنده را از یک «مهندس پرامپت» به یک «بازبین سختگیر» تبدیل میکند. پرامپتنویسی اکنون مثل بلد بودن تایپ با کیبورد است؛ لازم است، اما به عنوان یک تمایز شغلی ارزشش صفر است چون ابزارها در حال بستن این شکاف هستند.
اگر شنبههای خود را صرف صیقل دادن کتابخانه پرامپتها میکنید، در واقع دارید روی قابلیتی سرمایهگذاری میکنید که آزمایشگاههای AI در حال حذف فعال آن هستند. تنها راه رشد عضله بدبینی، ارسال کد برای مردم واقعی، دیدن شکست آن و تبدیل پیامدها به تجربه است. بدبینی بدون تجربه، مهارت نیست؛ بلکه یک شعار است.
کاربرد عملی: حمله به پاسخ
برای ساخت این عضله، نویسنده تغییری در رفتار پیشنهاد میکند: بعد از پاسخ AI و قبل از پذیرش کد، به جای تحسین خروجی، فعالانه سعی کنید آن را بشکنید. این کار شامل پرسیدن سوالات خاص و خصمانه است:
- این کد در زمان یک Retry چه میکند؟
- ساعت ۲ صبح چه رفتاری دارد؟
- وقتی ورودی خصمانه باشد چه اتفاقی میافتد؟
- وقتی مشتری «احمقانهترین کار ممکن» را بکند چه میشود؟
هدف این است که چیزی غیر از نویسنده، نقش شکاک را ایفا کند. تنها راهی که پاسخهای غلط واقعاً برای شما هزینه داشته باشند، ارسال آنها برای کسی است که بتواند به شما آسیب بزند. این هزینه تنها چیزی است که عضله بدبینی را رشد میدهد. هدف دیگر یافتن کلمات جادویی نیست، بلکه ایجاد زخمهایی است که به شما اجازه میدهد فاجعهای پنهان در یک قطعه کد زیبا را شناسایی کنید.
گام بعدی شما
- به جای تحسین خروجی AI، فعالانه سعی کنید آن را بشکنید.
- از خود بپرسید: «اگر ورودی خصمانه باشد یا کاربر احمقانهترین کار ممکن را بکند، این کد چه میکند؟»
- در معماری سیستمهای خود، لایه «شکاک» را از لایه «تولیدکننده» جدا کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو