از پوشه خالی تا سایت مستقرشده با Claude Code

پاسخ کوتاه: با مشخصات مکتوب شروع کنید، نه با پرامپت. هدف، stack، قواعد غیرقابل‌مذاکره و دستورهای build و تست را در یک CLAUDE.md در ریشه مخزن بگذارید. اسکلت پروژه را با templateهای رسمی بسازید و بعد در گام‌های کوچک و بازبینی‌شده جلو بروید: برنامه بخواهید، تأییدش کنید، بگذارید Claude Code پیاده‌اش کند و build و تست را اجرا کند، diff را بخوانید، commit کنید. در هفته اول یک چیز واقعی مستقر کنید. هوش مصنوعی سریع تایپ می‌کند؛ کار شما کوچک، تست‌شده و فهمیده نگه داشتن هر گام است.

یک مثال واقعی: سایت یک کسب‌وکار کوچک

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

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

گام ۱: قبل از هر کدی مشخصات را بنویسید

پوشه و یک CLAUDE.md بسازید. کوتاه و مشخص نگهش دارید و درباره چیزهایی که اشتباه کردنشان آسان است:

# Shop site: rules for Claude

## Goal
Public site for the shop (fa + en), a weekly schedule, a repair-request form that emails the owner.

## Stack (decided)
.NET 10, ASP.NET Core Razor Pages, EF Core + SQL Server, hosted on Windows/IIS (Plesk).

## Never
- No secrets in the repo: connection strings and passwords come from environment variables.
- No CDN links: self-host every CSS/JS/font file.
- No feature work without a test for its rules.

## Commands
dotnet build
dotnet test
dotnet run --project src/Shop.Web

فهرست «Never» بیشترین کار را می‌کند. هر قاعده آن اشتباهی است که عامل دیر یا زود مرتکب می‌شد.

گام ۲: اسکلت را با template بسازید، نه با پرامپت

بگذارید templateهای رسمی کارهای تکراری را بنویسند؛ درست‌اند و هزینه‌ای ندارند:

dotnet new sln -n Shop
dotnet new webapp -n Shop.Web -o src/Shop.Web
dotnet new xunit -n Shop.Tests -o tests/Shop.Tests
dotnet sln add src/Shop.Web tests/Shop.Tests
dotnet add tests/Shop.Tests reference src/Shop.Web
git init && git add -A && git commit -m "Scaffold solution"

بعد claude را در همان پوشه اجرا کنید. CLAUDE.md و اسکلت را می‌خواند و از اولین پیام درباره پروژه شما حرف می‌زنید.

گام ۳: اول برنامه، بعد پیاده‌سازی

برای هر چیزی بزرگ‌تر از یک اصلاح یک‌خطی، قبل از کد برنامه بخواهید. Claude Code برای این کار یک plan mode دارد (Shift+Tab بین حالت‌ها جابه‌جا می‌کند) که بدون ویرایش فایل‌ها کاوش و پیشنهاد می‌کند. برنامه را مثل یک سند طراحی بازبینی کنید: مدل داده درست است؟ قواعد کجا زندگی می‌کنند؟ چه چیزی تست می‌شود؟ تغییرش دهید و بعد بگذارید پیاده‌اش کند.

درخواست‌های خوب باریک و قابل بررسی‌اند:

فرم درخواست تعمیر را اضافه کن: نام، تلفن، مدل دوچرخه، توضیحات (۳۰ تا ۲۰۰۰ کاراکتر). در دیتابیس ذخیره کن، صفحه تشکر نشان بده و برای قواعد اعتبارسنجی تست بنویس. فعلاً ایمیل نفرست.

گام ۴: بگذارید حلقه را اجرا کند، شما diff را بخوانید

مزیت واقعی عامل، حلقه است: کد نوشتن، اجرای dotnet build، خواندن خطا، اصلاح، اجرای dotnet test و تکرار. بگذارید انجامش دهد. وقتی گفت تمام شد:

1. diff را بخوانید؛ همه‌اش را.
2. برنامه را خودتان اجرا کنید و تغییر را امتحان کنید.
3. با پیامی commit کنید که می‌گوید چه چیزی و چرا تغییر کرد.

اگر diff به فایل‌هایی دست زده که ربطی به درخواست ندارند، ردش کنید و با محدوده تنگ‌تری دوباره بخواهید.

گام ۵: قواعد را به تست تبدیل کنید

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

گام ۶: در هفته اول مستقر کنید

اولین صفحه کارا را publish و مستقر کنید، نه سایت تمام‌شده را. هاست اشتراکی غافلگیری‌های خودش را دارد: نسخه runtime روی سرور، تنظیمات application pool، دسترسی فایل‌ها، web.config. پیدا کردنشان در روز سوم ارزان است؛ در روز افتتاح نه.

dotnet publish src/Shop.Web -c Release -o artifacts/publish

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

مزایا و معایب

مزایا

• برای بخش‌های پرتکرار، چند روز به‌جای چند هفته.
• حلقه build، تست و اصلاح بدون شما اجرا می‌شود؛ وقت شما صرف بازبینی و تصمیم می‌شود.
• CLAUDE.md به‌علاوه تست‌ها قواعد پروژه را صریح می‌کنند؛ به هر توسعه‌دهنده بعدی، آدم یا غیرآدم، کمک می‌کند.

معایب

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

نسخه کوتاه

اول مشخصات. template برای اسکلت. برنامه، پیاده‌سازی، خواندن diff، commit. قواعد به‌شکل تست. استقرار زود. فرق بین «هوش مصنوعی کمی کد نوشت» و «من با هوش مصنوعی یک سایت تحویل دادم» همین است.

سایت یا MVPی می‌خواهید که این‌طور ساخته شود و یک مهندس ارشد خط‌به‌خط بازبینی‌اش کند؟ ببینید چطور می‌توانم کمک کنم.