پروژهٔ پایانی: ساخت یک برنامهٔ کامل با هوش مصنوعی

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

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

این پروژه دربارهٔ ساختن یک برنامهٔ کامل و کوچک است، با روشی که در پروژه‌های بزرگ هم دوام می‌آورد.

بریف پروژه

یک برنامهٔ کوچک اما واقعاً کاربردی بساز که خودت از آن استفاده کنی. شرایط:

• بین ۳۰۰ تا ۸۰۰ خط کد — نه یک اسکریپت، نه یک پروژهٔ غول.
• حداقل سه بخش مجزا (مثلاً: خواندن داده، پردازش، نمایش خروجی).
• مدیریت خطاهای واقعی — نه فقط مسیر خوش‌بینانه.
• حداقل ده تست خودکار.
• یک فایل تصمیم‌ها که توضیح می‌دهد چرا چیزها این‌طور ساخته شده‌اند.

ایده‌های مناسب

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

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

مرحلهٔ ۱ — طراحی قبل از کد (۱ ساعت)

وسوسه می‌شوی مستقیم بگویی «این برنامه را بساز». نکن. اول این را بخواه:

نقش: مهندس نرم‌افزار ارشد.

می‌خواهم این برنامه را بسازم: [توضیح دو پاراگرافی]

کار تو — فعلاً هیچ کدی ننویس:

۱) پنج سؤالی که باید قبل از شروع جواب بدهم و
   هنوز به آن‌ها فکر نکرده‌ام.
۲) ساختار فایل‌ها و ماژول‌ها را پیشنهاد بده و برای هر
   ماژول در یک جمله بگو مسئولیتش چیست.
۳) سه تصمیم فنی مهم را نام ببر و برای هرکدام دو گزینه
   با مزیت و عیب بده. توصیه‌ات را هم بگو.
۴) کدام بخش‌ها احتمالاً پیچیده‌تر از آن‌اند که به‌نظر می‌رسند؟
۵) چه خطاهای واقعی ممکن است رخ دهد که یک تازه‌کار
   پیش‌بینی نمی‌کند؟

خروجی: پاسخ ساختاریافته، بدون کد.

بند پنجم معمولاً ارزشمندترین بخش است. مدل‌ها در فهرست‌کردن حالت‌های خطا بسیار خوب‌اند و همین چیزی است که کد آماتور را از حرفه‌ای جدا می‌کند.

فایل تصمیم‌ها را همین‌جا شروع کن

# تصمیم‌های فنی

## ۱. چرا [فناوری الف] و نه [فناوری ب]
دلیل: ...
هزینه‌ای که پذیرفتم: ...

## ۲. چرا داده را در [قالب] ذخیره می‌کنم
...

سه ماه بعد که برگردی، این فایل تنها چیزی است که نجاتت می‌دهد.

مرحلهٔ ۲ — ساخت ماژول‌به‌ماژول

هرگز نگو «کل برنامه را بنویس». به‌جایش، هر بار یک ماژول:

نقش: مهندس نرم‌افزار.

زمینه: این ساختار پروژه است: [ساختار مرحلهٔ ۱]
این ماژول‌ها از قبل نوشته شده‌اند: [کد ماژول‌های قبلی]

کار: فقط ماژول [نام] را بنویس.

مسئولیت این ماژول: [یک جمله]
ورودی: [نوع و ساختار]
خروجی: [نوع و ساختار]

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

ممنوع:
- تغییر ماژول‌های قبلی.
- نوشتن کد برای قابلیت‌هایی که نخواسته‌ام.

خروجی: کد ماژول + سه خط توضیح دربارهٔ تصمیم‌های مهمش.

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

قاعدهٔ فهم صد درصدی

بعد از دریافت هر ماژول، این را از خودت بپرس: آیا می‌توانم خط‌به‌خط توضیح دهم این کد چه می‌کند؟ اگر نه، قبل از رفتن به ماژول بعد بپرس:

خط [شماره] تا [شماره] را برایم توضیح بده.
چرا این‌طور نوشتی و اگر ننویسی چه می‌شود؟

کدی که نمی‌فهمی، بدهی است نه دارایی. این دقیقاً همان تفاوتی است که در توهم هوش مصنوعی توضیح داده‌ایم.

مرحلهٔ ۳ — تست، اما با روش درست

اشتباه رایج: «برای این کد تست بنویس». مدل تست‌هایی می‌نویسد که فقط مسیر خوش‌بینانه را چک می‌کنند و همیشه سبز می‌شوند. روش بهتر:

نقش: مهندس تست با ذهنیت خرابکارانه.

زمینه: [کد ماژول]

کار — به این ترتیب:

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

۲) بعد برای هر حالت بگو رفتار درست چه باید باشد.

۳) حالا تست بنویس. برای هر تست یک نام توصیفی بگذار
   که بگوید چه چیزی را می‌سنجد.

۴) در پایان بگو کدام حالت‌ها را نتوانستی تست کنی و چرا.

ممنوع: تستی که فقط تأیید می‌کند کد کار می‌کند.

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

مرحلهٔ ۴ — بازبینی امنیتی

حتی برنامه‌های کوچک شخصی هم مشکلات امنیتی دارند:

نقش: بازبین کد با تمرکز بر امنیت.

زمینه: [کل کد]

بررسی کن:
- آیا کلید، رمز یا توکنی مستقیم در کد نوشته شده؟
- آیا ورودی کاربر بدون اعتبارسنجی جایی استفاده می‌شود؟
- آیا مسیر فایل از ورودی ساخته می‌شود بدون بررسی؟
  (خطر دسترسی به فایل‌های خارج از پوشهٔ مجاز)
- آیا داده‌ای در لاگ نوشته می‌شود که نباید؟
- آیا خطاها پیام‌های داخلی سیستم را به کاربر نشان می‌دهند؟
- آیا وابستگی‌ها از منابع معتبر می‌آیند؟

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

مرحلهٔ ۵ — عیب‌یابی حرفه‌ای

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

مشکل: [توصیف دقیق]
انتظار: [چه باید می‌شد]
واقعیت: [چه شد — با پیام خطای کامل]
شرایط بازتولید: [قدم‌به‌قدم]
چه چیزی امتحان کردم: [تا حالا چه کردی]
کد مرتبط: [فقط بخش مربوطه]

کار: سه علت محتمل را به‌ترتیب احتمال فهرست کن.
برای هرکدام یک تست کوتاه بگو که چطور تأیید یا ردش کنم.
هنوز کد اصلاحی ننویس.

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

مرحلهٔ ۶ — بازبینی نهایی و مستندسازی

نقش: مهندس ارشد که این پروژه را تحویل می‌گیرد.

زمینه: [کل کد + فایل تصمیم‌ها]

۱) کدام بخش‌ها را بعد از سه ماه سخت می‌فهمم؟
۲) کدام کد تکراری است و باید یکی شود؟
۳) کدام تابع بیش از یک مسئولیت دارد؟
۴) اگر بخواهم قابلیت [ایده‌ای در ذهنت] را اضافه کنم،
   کجای کد مقاومت می‌کند؟
۵) فایل تصمیم‌ها چه چیزی را توضیح نداده که باید؟

خروجی: فهرست اولویت‌بندی‌شده. فقط سه مورد اول را
با کد اصلاحی نشان بده.

و در پایان یک فایل راهنمای کوتاه بنویس: چطور نصب می‌شود، چطور اجرا می‌شود، چه تنظیماتی دارد، و چه محدودیت‌های شناخته‌شده‌ای دارد.

معیار ارزیابی پروژه

معیار	امتیاز
برنامه واقعاً کار می‌کند و استفاده‌اش می‌کنی	۱۵
طراحی قبل از کد انجام شد	۱۰
ساخت ماژول‌به‌ماژول، نه یک‌جا	۱۰
می‌توانی هر خط را توضیح دهی	۲۰
حداقل ده تست معنادار (نه فقط مسیر خوش‌بینانه)	۲۰
بازبینی امنیتی انجام و مشکلات رفع شد	۱۰
فایل تصمیم‌ها و راهنما کامل است	۱۵

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

پرامپت داور

نقش: بازبین کد سخت‌گیر در یک تیم حرفه‌ای.

زمینه: [کل کد + تست‌ها + فایل تصمیم‌ها]

کار: این پروژه را مثل یک درخواست ادغام واقعی نقد کن.

۱) کدام بخش‌ها نشانهٔ «کد تولیدشده و فهمیده‌نشده» دارند؟
   مثلاً پیچیدگی بی‌دلیل یا الگویی که با بقیهٔ کد نمی‌خواند.
۲) تست‌ها: چند درصدشان واقعاً می‌توانند شکست بخورند؟
   کدام تست‌ها فقط تزئینی‌اند؟
۳) کدام حالت خطای مهم پوشش داده نشده؟
۴) اگر این کد را به یک نفر تازه بدهم، کجا گیر می‌کند؟
۵) کدام تصمیم فنی احتمالاً اشتباه بوده و چرا؟
۶) اگر فقط یک ساعت وقت داشتم این پروژه را بهتر کنم،
   دقیقاً چه کار می‌کردم؟

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

سه سطح دشواری

سطح	دامنه	زمان
مقدماتی	۳۰۰ خط، دو ماژول، شش تست	۸ ساعت
استاندارد	بریف کامل بالا	۱۶ ساعت
پیشرفته	به‌علاوهٔ: رابط کاربری، اجرای خودکار تست‌ها در هر تغییر، و انتشار عمومی کد	۳۰ ساعت

پرسش‌های پرتکرار

اگر تازه‌کارم و زبان برنامه‌نویسی بلد نیستم؟
این پروژه برای کسی است که دست‌کم مبانی یک زبان را می‌داند. بدون آن، نمی‌توانی کد را بفهمی و کل ارزش پروژه از بین می‌رود. اول مبانی، بعد این پروژه.

چقدر از کد را خودم بنویسم؟
هرچقدر که راحتی. معیار، مقدار تایپ نیست؛ معیار این است که بتوانی هر خط را توضیح دهی و تغییرش دهی.

مدل مدام کدی می‌دهد که جای دیگر را می‌شکند.
دو علت رایج: زمینهٔ کافی نمی‌دهی (کد ماژول‌های مرتبط را پیوست نمی‌کنی) یا بند «ممنوع: تغییر ماژول‌های قبلی» را ننوشته‌ای. هر دو را رعایت کن.

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

جمع‌بندی

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

مسیر کامل را در نقشهٔ راه برنامه‌نویسی با هوش مصنوعی ببین و در @MrChatGPT_IR همراه ما باش.