مطالعهٔ موردی PromptForge: تبدیل ایدهٔ محصول به پرامپت بهتر برای ایجنت کدنویسی

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

برای همین در PromptForge پرامپت خروجی نهاییِ یک بریف است، نه وردی که در جعبهٔ بزرگ‌تری تایپ شود. محصول اول آدم را از میان سؤال‌ها عبور می‌دهد، بعد جواب‌ها را در یک پرامپت ساخت‌یافته برای ایجنت کدنویسی کنار هم می‌گذارد. این ترتیب مهم است؛ ابزارِ توسعه‌دهنده و ایجنت باید ورودی سیستم را بهتر کند، نه درخواست مبهمی را که رسیده فقط تزئین کند.

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

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

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

PromptForge استودیوی قالب و قالب‌های قابل استفادهٔ مجدد دارد، چون شکل خوب بریف نباید هر بار از صفحهٔ سفید دوباره کشف شود. هر محصول تأکید خودش را می‌خواهد، اما استخوان‌بندی تکرارشونده — زمینه، محدودیت، قابلیت، تکنولوژی و انتظار تحویل — می‌تواند حفظ و بهتر شود. قالب وقتی مفید است که سؤال‌ها را نگه دارد، نه وقتی فقط عبارت‌های مدروز تحویل بدهد.

PromptForge از همین‌جا از سمت مقابل به Sonobe می‌رسد. Sonobe از سمت فریم‌ورک برای انسان و ایجنت مستندات تولید می‌کند؛ PromptForge کمک می‌کند آدم پیش از شروع ایجنت، محصول را روشن بیان کند. این رابطه را در نوشتهٔ FastAPI و Sonobe هم باز کرده‌ام. در هر دو جهت هدف یکی است: به انسان و ماشین ساختاری بده که بشود بازرسی‌اش کرد، نه افسانه‌ای که مجبور باشند حدسش بزنند.

PromptForge را با React، TypeScript، Vite و Tailwind CSS ساختم و به‌صورت محلی کار می‌کند. برای ابزار ایده‌پردازی این مهم است: آدم باید بتواند شرح محصولش را شکل بدهد، بی‌آنکه اول حساب بسازد یا فکر ناتمامش را به سرور بفرستد. هستهٔ مفید کار — ساخت‌دادن به ایده و تولید پرامپت — ذاتاً بک‌اند لازم ندارد.

حساب کاربری و اشتراک‌گذاری و قابلیت‌های اجتماعی جنس دیگری‌اند و تعریفاً جمعی‌اند؛ برای آن‌ها بک‌اند اختیاری Serverless با PostgreSQL روی Neon وجود دارد. اختیاری ماندن این لایه معماری را صادق می‌کند: کار محلی محلی می‌ماند و قابلیت شبکه فقط جایی هست که همکاری واقعاً لازمش دارد. ترجیح می‌دهم این مرز را توضیح بدهم تا هر کلیدِ صفحه‌کلید برای ظاهر هم که شده به زیرساخت وابسته شود.

ابزار ساخت پرامپت با متنی سروکار دارد که آدم‌ها می‌نویسند، دوباره استفاده می‌کنند و شاید به اشتراک بگذارند؛ پس اعتبارسنجی و پاک‌سازی بخشی از محصول‌اند، نه کارِ بعد از محصول. PromptForge برای اعتبارسنجی داده از Zod و برای پاک‌سازی محتوا از DOMPurify استفاده می‌کند. یکی می‌پرسد داده شکل مورد انتظار را دارد؛ دیگری خطر سفر محتوای فعال به جایی که فقط متن دعوت شده را کم می‌کند. مسئله‌هایشان فرق دارد و قاطی کردنشان همان راه ساخته شدن حفره‌های قابل اجتناب است.

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

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

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