پرامپت‌نویسی برای ساخت نرم‌افزار: چطور به هوش مصنوعی کار سفارش بدهیم

بیشتر ما با دستیار هوش مصنوعی طوری حرف می‌زنیم که با یک همکار خوش‌برخورد: یک جمله می‌نویسیم، جواب می‌گیریم، جمله‌ی بعد. برای پرسیدن یک سؤال همین کافی است، اما پرامپت‌نویسی برای ساخت نرم‌افزار مهارت دیگری است؛ اینجا دارید بخشی از یک سیستم را برای کسی توصیف می‌کنید که کد شما را ندیده، قرارهای نانوشته‌ی تیم‌تان را نمی‌داند و هر جای خالی را با پیش‌فرض‌های خودش پر می‌کند.

تفاوت اصلی در جنس خروجی است. جواب یک گفت‌وگو می‌تواند ناقص باشد و باز هم به کار بیاید؛ کد یا اجرا می‌شود یا نمی‌شود. کدی که تقریباً درست است اغلب از هیچ بدتر است، چون باید وقت بگذارید و آن تکه‌ی غلط را پیدا کنید — و پیدا کردن اشکال در کدی که خودتان ننوشته‌اید، از نوشتنش کندتر است.

هر جای خالی، تصمیمی است که کس دیگری می‌گیرد

«یک فرم ثبت‌نام بساز» یک درخواست نیست، یک آرزوست. مدل برای اینکه چیزی تحویل بدهد باید ده‌ها تصمیم را خودش بگیرد: زبان، فریم‌ورک، جای ذخیره‌ی داده، نام فیلدها، شیوه‌ی اعتبارسنجی، شکل پیام خطا، و اینکه بعد از ثبت موفق چه اتفاقی بیفتد. چون روی رایج‌ترین کدهای دنیا آموزش دیده، رایج‌ترین جواب را می‌دهد: معمولاً یک کامپوننت React با Tailwind و یک آرایه‌ی توی حافظه.

اگر پروژه‌ی شما وردپرسی است و داده باید در جدول خودتان بنشیند، آن خروجیِ بی‌عیب کاملاً بی‌فایده است. مدل اشتباه نکرده؛ شما نگفته‌اید کجا ایستاده است. قانون ساده این است: هر چیزی که نگویید، به‌جای شما تصمیم‌گیری می‌شود.

چهار تکه‌ای که یک پرامپت کاری را می‌سازد

فرقی نمی‌کند در چت کار می‌کنید یا در یک ابزار عامل مثل Claude Code و Cursor؛ درخواستی که واقعاً نتیجه می‌دهد تقریباً همیشه علاوه بر خودِ خواسته، این چهار تکه را دارد:

پرامپت‌نویسی برای ساخت نرم‌افزار با این چهار تکه طولانی‌تر می‌شود، ولی طولانی بودن هدف نیست. هدف این است که خروجی قابل رد کردن باشد؛ یعنی بتوانید بدون بحث بگویید این جواب درست است یا نه.

زمینه یعنی مسیر فایل، نه توصیف کلی

نوشتن «پروژه‌ی من ری‌اکتی است» تقریباً هیچ اطلاعاتی اضافه نمی‌کند. «Next.js نسخه‌ی ۱۵ با App Router، استایل با Tailwind، داده‌ها از یک API لاراولی روی مسیر /api/v1» یک زمینه‌ی واقعی است. نسخه، معماری و مسیر — همین سه تا بیشترین سوءتفاهم‌ها را حذف می‌کنند.

در ابزارهای عامل، به‌جای کپی کردن صدها خط کد، بگویید کدام فایل‌ها را بخواند: «قبل از نوشتن هر چیزی این سه فایل را بخوان و بگو ساختار فعلی را چطور فهمیدی.» همین یک جمله بیشترین کاهش را در حدس‌زدن مدل ایجاد می‌کند، چون اول واقعیت پروژه را می‌بیند و بعد می‌نویسد.

زمینه‌ای که هر بار تکرار می‌شود را در فایل دستور پروژه نگه دارید؛ بیشتر ابزارهای امروزی چنین فایلی دارند که خودکار خوانده می‌شود (اسمش بسته به ابزار فرق می‌کند). استک، سبک کدنویسی، کارهای ممنوع و محل فایل‌های مهم را همان‌جا بنویسید تا از پرامپت‌های روزمره بیرون بیاید.

محدودیت‌ها را قبل از دیدن خروجی بگویید

هر محدودیتی که بعد از دیدن خروجی به یادتان می‌آید، یک دور کامل کار را سوزانده است. پیش از زدن Enter یک بار از خودتان بپرسید: «اگر یک تازه‌وارد این متن را بخواند، چه کار عجیبی ممکن است بکند که من بدیهی فرض کرده‌ام؟» معمول‌ترین محدودیت‌هایی که ارزش نوشتن دارند:

• دست‌نزدنی‌ها: فایل‌ها، جدول‌ها یا امضای توابعی که نباید تغییر کنند.
• دامنه‌ی تغییر: «فقط همین یک فایل» — جلوی بازنویسی‌های ناخواسته را می‌گیرد.
• وابستگی‌ها: بدون نصب کتابخانه‌ی جدید، یا فقط از چیزی که در package.json هست.
• سبک: هم‌شکل با کد موجود همان پوشه، نه بازآراییِ سلیقه‌ای.
• رابط کاربری: متن‌ها فارسی، چیدمان راست‌به‌چپ، اعداد فارسی.
• مرزهای فنی: مثل «کوئری داخل حلقه نزن» یا «کلید API را در کد سمت کاربر نگذار».

محدودیت برخلاف تصور خلاقیت مدل را نمی‌کُشد؛ فضای جست‌وجویش را کوچک می‌کند و همین باعث می‌شود جواب اول به جواب قابل‌استفاده نزدیک‌تر باشد.

معیار پذیرش را با رفتار بنویسید، نه با صفت

«امن باشد»، «تمیز باشد»، «حرفه‌ای باشد» معیار نیستند، چون هیچ‌کس نمی‌تواند بررسی‌شان کند. معیار پذیرش جمله‌ای است که می‌شود اجرایش کرد و دید درست است یا غلط:

معیار پذیرش:
- با ایمیل تکراری، کد ۴۰۹ و پیام فارسی برگردد
- رمز کمتر از ۸ نویسه رد شود و فرم ارسال نشود
- بعد از ثبت موفق، کاربر به /dashboard برود
- توکن در localStorage ذخیره نشود

اگر پروژه‌تان تست دارد، دقیق‌ترین پرامپت ممکن این است: «این تست باید سبز شود، بدون تغییر دادن خودِ تست.» تست، معیار پذیرشی است که خودش را بررسی می‌کند و جای هیچ تفسیری باقی نمی‌گذارد.

روی شکست تکرار کنید، از اول شروع نکنید

وقتی خروجی خطا می‌دهد، وسوسه این است که چت را پاک کنید و پرامپت را از نو بنویسید. اگر بخش زیادی از کار درست است، این یعنی دور ریختن همه‌ی زمینه‌ای که با زحمت ساخته‌اید. بخش دشوارِ پرامپت‌نویسی برای ساخت نرم‌افزار همین‌جاست: برگرداندن شکست به مدل، به شکلی که قابل استفاده باشد.

یک بازخورد خوب سه چیز دارد: متن دقیق خطا (نه «کار نکرد»)، کاری که کردید تا خطا ظاهر شود، و چیزی که انتظار داشتید ببینید. اگر خودتان راهی را امتحان کرده‌اید و جواب نداده، آن را هم بنویسید تا دوباره همان پیشنهاد برنگردد.

تکنیکی که تفاوت محسوسی می‌سازد این است که پیش از اصلاح، تشخیص بخواهید: «کد را عوض نکن. اول بگو چرا این خطا می‌آید و دو احتمال را نام ببر.» وقتی مدل مستقیم سراغ اصلاح می‌رود، معمولاً چند تغییر پراکنده می‌زند تا یکی‌شان بگیرد؛ و کدی که این‌طور درست شود، هفته‌ی بعد دوباره می‌شکند.

یک قاعده‌ی سرانگشتی هم هست که ادعای علمی بودن ندارد ولی در عمل جواب می‌دهد: سه تلاش. اگر بعد از سه دور چیزی بهتر نشد و مدل بین دو راه‌حل غلط نوسان می‌کند، مشکل انتخابِ کلمه‌ها نیست، اطلاعات کم است. لاگ واقعی، شکل واقعی داده یا پاسخ خام یک درخواست را جلویش بگذارید؛ معمولاً همان دور بعد حل می‌شود.

و چیزی که این جسارت را ارزان می‌کند: قبل از هر تلاش پرریسک کامیت کنید. وقتی برگشتن به حالت سالم یک دستور فاصله دارد، می‌توانید بگذارید مدل چیز بزرگی را امتحان کند بی‌آنکه چیزی از دست بدهید.

کِی باید درخواست را تکه‌تکه کرد

شکستن کار همیشه بهتر نیست؛ یک تغییر کوچک که به پنج مرحله تقسیم شود فقط وقت می‌گیرد. اما این نشانه‌ها می‌گویند درخواست بزرگ‌تر از آن است که در یک رفت‌وبرگشت جا شود:

• بیش از دو سه فایل را لمس می‌کند.
• در جمله‌اش «و همچنین» دارید.
• تصمیمی در آن هست که خودتان هم هنوز نگرفته‌اید.
• هم‌زمان ساختار داده و رابط کاربری را عوض می‌کند.
• نمی‌توانید در یک جمله بگویید از کجا می‌فهمید تمام شده است.

ترتیب طبیعی شکستن هم معمولاً همین است: اول مدل داده، بعد منطق سمت سرور، بعد رابط کاربری، و آخر حالت‌های خطا و لبه‌ها. هر مرحله را اجرا کنید و ببینید واقعاً کار می‌کند، بعد بروید سراغ بعدی؛ مرحله‌ای که امتحان نشده باشد، بدهیِ پنهان است.

ساده‌ترین راه این است که اول نقشه بخواهید: «کد ننویس. فقط مرحله‌ها را فهرست کن، هر مرحله یک جمله، و مشخص کن هرکدام کدام فایل‌ها را عوض می‌کند.» نقشه را بخوانید، اصلاح کنید و بعد بگویید مرحله‌ی یک را اجرا کند. اصلاح یک فهرست ده‌خطی چند ثانیه طول می‌کشد؛ اصلاح چهارصد خط کد غلط، یک بعدازظهر.

قالبی که می‌توانید همین امروز به کار ببرید

زمینه: [استک، نسخه‌ها، فایل‌های مربوط، وضعیت فعلی]
خواسته: [یک جمله، فقط یک کار]
محدودیت: [چه چیزی دست نخورد، چه چیزی مجاز نیست]
معیار پذیرش: [دو تا چهار جمله‌ی قابل بررسی]

اگر چیزی مبهم بود، قبل از نوشتن کد بپرس.

خط آخر را حذف نکنید. اجازه‌ی سؤال پرسیدن، جلوی گران‌ترین حالت را می‌گیرد: مدلی که فرض غلطی کرده و با اطمینان کامل صد خط کد روی همان فرض نوشته است.

این قالب جادو نیست؛ فقط شما را وادار می‌کند پیش از مدل، خودتان بدانید چه می‌خواهید. پرامپت‌نویسی برای ساخت نرم‌افزار در عمل همین است: فکر کردنِ چند دقیقه‌ای به‌جای تایپ کردنِ سریع. اگر می‌خواهید این چرخه را روی یک پروژه‌ی واقعی و از صفر تمرین کنید، دوره‌ی ساخت سایت با هوش مصنوعی بدون کدنویسی دقیقاً همین مسیر را قدم‌به‌قدم می‌رود؛ برای موضوع‌های دیگر هم فهرست دوره‌ها و نوشته‌های بلاگ را ببینید.

محمدرضا حسینی

مهندس نرم‌افزار و مدرس وایب کدینگ. بیش از ۱۰ سال تجربه ساخت محصولات وب، و سه سال تمرکز روی ساخت محصول با ابزارهای هوش مصنوعی. تا امروز بیش از ۴٬۰۰۰ نفر در دوره‌هایش شرکت کرده‌اند.