اگر امروز از هوش مصنوعی برای کدنویسی استفاده می‌کنید، احتمالاً در «تله‌ی سرعت» گیر افتاده‌اید؛ ابزار در چند ثانیه راهکار را می‌نویسد، اما باگ‌هایی ایجاد می‌کند که رفع آن‌ها ساعت‌ها زمان می‌برد. در ۱۰ ژوئن ۲۰۲۶، یک معماری عملیاتی مفصل در وب‌سایت dev.to منتشر شد که نشان می‌دهد چگونه می‌توان Claude Code را از یک ابزار عجول «پرامپت-و-ارسال»، به یک شریک مهندسی منضبط تبدیل کرد.
بسیاری از توسعه‌دهندگان با دستیارهای هوش مصنوعی مثل یک پنجره‌ی چت ساده برخورد می‌کنند و همین باعث ایجاد توهمات فنی (Hallucinations) و گسترش بی‌رویهٔ محدودهٔ پروژه (Scope Creep) می‌شود. دستیارهای کدنویسی سریع هستند — به‌شدت سریع. آن‌ها اغلب پیش از درک کامل مسئله کد می‌زنند، فایل‌هایی را تغییر می‌دهند که از آن‌ها نخواسته‌اید و پیش از تایید واقعی عملکرد، تکلیف را «تمام‌شده» اعلام می‌کنند. سرعت بدون انضباط، بهره‌وری نیست؛ بلکه راهی سریع‌تر برای تولید باگ است.
این سیستم جدید با هوش مصنوعی مانند یک کارمند حرفه‌ای رفتار می‌کند که یک دفترچه راهنمای استخدامی سخت‌گیرانه و یک توالی عملیاتی ۹ مرحله‌ای اجباری دارد. به‌جای پنجره‌ی چت، Claude Code در ترمینال شما اجرا می‌شود، فایل‌ها را می‌خواند، تست‌ها را اجرا می‌کند و مانند یک همکار واقعی در داخل پروژه عمل می‌کند. در اینجا تمرکز از سرعت تولید خام به «صحت قابل‌راستی‌آزمایی» تغییر می‌کند.
لایه‌ی حاکمیتی (The Governance Layer)
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل دقیق روی ورودی‌ها و خروجی‌ها تنها راه کاهش ریسک در محیط‌های عملیاتی است. در این سیستم، زیربنای همه چیز فایل CLAUDE.md است که در مسیر ~/.claude/CLAUDE.md قرار دارد. این فایل درست مانند دفترچه راهنمای تازه‌واردان است که در ابتدای هر جلسه به‌طور خودکار بارگذاری می‌شود، صرف‌نظر از اینکه پروژه چه باشد. این فایل به کلود می‌گوید با چه کسی کار می‌کند، چگونه رفتار کند و چه کارهایی مطلقاً ممنوع است.
به نقل از مستندات این متدولوژی، برای جلوگیری از رایج‌ترین اشتباهات هوش مصنوعی، چهار اصل غیرقابل‌مذاکره در این دفترچه تعریف شده است:
- تفکر پیش از کدنویسی: کلود با کمال میل راهکار اشتباه را به‌طور کامل پیاده می‌کند. این قانون او را مجبور می‌کند پیش از نوشتن حتی یک خط کد، پیش‌فرض‌های خود را بیان کند و سؤالات شفاف‌ساز بپرسد.
- سادگی در اولویت: مدل‌های هوش مصنوعی به‌طور پیش‌فرض تمایل به جامع بودن دارند. اگر دکمه‌ای خواستید، ممکن است دکمه به‌همراه وضعیت بارگذاری، مرز خطا، انیمیشن و پوشش دسترسی‌پذیری تحویل دهد. این قانون او را مجبور می‌کند حداقل کد لازم برای حل مسئله را بنویسد و هیچ کد حدسی یا اضافی اضافه نکند.
- تغییرات جراحی‌گونه: کلود اگر اجازه یابد، تمام کد شما را بازسازی می‌کند. قانون این است که فقط بخش‌های مورد نیاز برای تکلیف را تغییر دهد و هرگز کدهای غیرمرتبط را بهبود نبخشد.
- هدف‌محوری: هوش مصنوعی باید یک معیار موفقیت قابل‌راستی‌آزمایی تعریف کند و تا زمانی که از آن عبور نکند، در یک حلقه تکرار بماند. او نمی‌تواند تکلیف را تمام‌شده اعلام کند مگر اینکه هدف تأیید شده باشد، نه اینکه صرفاً فرض کند هدف محقق شده است.
لایه‌بندی مدل‌ها و کنترل هزینه
چون مدل‌های کلود بر اساس توکن (Token) — که شبیه برش‌های کوچک یک کیور طولانی است و مدل متن را تکه‌تکه می‌خورد — هزینه می‌گیرند، استفاده از قدرتمندترین مدل برای هر تکلیف، مانند استخدام یک معمار ارشد برای مرتب کردن حروف الفبای فایل‌های شماست. برای جلوگیری از سوختن بودجه، این گردش‌کار از استراتژی سه-لایه بر اساس پیچیدگی تکلیف استفاده می‌کند:
- Haiku (ارزان‌ترین): برای زیر-تکالیف «خسته‌کننده» رزرو شده است. این شامل جستجوی فایل‌ها، اجرای بررسی‌ها، لینتینگ (Linting) و ویرایش‌های ساده در یک فایل است.
- Sonnet (میان‌رده): اسب بارکش اصلی است. این مدل توانمند و مقرون‌به‌صرفه است و برای بخش اعظم کارهای واقعی کدنویسی استفاده می‌شود.
- Opus (قدرتمندترین): فقط برای مسائل معماری با پیچیدگی بالا یا مشکلاتی که واقعاً Sonnet از پس آن‌ها برنمی‌آید، فراخوانی می‌شود.
گردش‌کار ۹ مرحله‌ای جلسه
طبق گزارش dev.to، حیاتی‌ترین بخش این سیستم، «گیت‌های توالی» (Sequential Gate System) است. این سیستم مانع از آن می‌شود که برنامه‌نویس بدون داشتن نقشه، شروع به دیوارکشی کند. نادیده گرفتن هر یک از این مراحل، اجازه می‌دهد دسته خاصی از شکست‌ها به محیط عملیاتی (Production) برسد.
مراحل اجرای گردش‌کار:
۱. گام اول (/status): تایید اینکه کدام مدل بارگذاری شده و در چه سطح تلاش (Effort Level) قرار دارد.
۲. گام دوم (/cost): ثبت یک عکس لحظه‌ای از هزینه توکن فعلی برای ایجاد خط مبنا پیش از شروع کار.
۳. گام سوم (/plan): طراحی راهکار. این مرحله راهکارهای غلط را پیش از نوشتن هرگونه کد شناسایی می‌کند.
۴. گام چهارم (Code): مرحله پیاده‌سازی واقعی کد.
۵. گام پنجم (pnpm test): این یک گیت «مسدودکننده» است. تمام تست‌ها باید بدون هیچ استثنایی پاس شوند. شکست‌ها باید در همین مرحله رفع شوند پیش از آنکه ادامه یابد.
۶. گام ششم (/cost): بررسی تغییرات هزینه (Delta) برای اطمینان از اینکه بودجه شما با بررسی کدهای خراب هدر نمی‌رود.
۷. گام هفتم (/code-review): هوش مصنوعی کد تغییر یافته (Diff) را به‌طور خاص برای یافتن باگ‌ها و مشکلات طراحی بررسی می‌کند.
۸. گام هشتم (/simplify): هوش مصنوعی کدهای شلوغ را پاک‌سازی می‌کند. این مرحله فقط برای خوانایی است، نه برای شکار باگ.
۹. گام نهم (/code-review --comment): یافته‌های بررسی به عنوان کامنت‌های درون‌خطی در Pull Requestهای گیت‌هاب ارسال می‌شوند.
هر گیت یک شکست متفاوت را شکار می‌کند: برنامه‌ریزی راهکارهای غلط را می‌گیرد، تست‌ها باگ‌های منطقی را می‌گیرند، بررسی کد باگ‌های طراحی (مسائل امنیتی و موارد خاص/Edge Cases) را می‌گیرد و ساده‌سازی بدهی‌های خوانایی را رفع می‌کند.
نرده‌های حفاظتی جهانی و مهارت‌ها
این سیستم استانداردهای امنیتی و دسترسی‌پذیری سخت‌گیرانه‌ای را اعمال می‌کند که بدون استثنا برای هر پروژه و هر جلسه اجرا می‌شوند.
قوانین غیرقابل‌مذاکره:
- هرگز
.envرا کامیت نکنید: از آنجایی که فایل‌های.envحاوی کلیدهای API و رمزهای عبور دیتابیس هستند، کامیت کردن آن‌ها مانند تحویل کلیدهای خانه به غریبه‌ها و ربات‌هاست. سیستم الزام می‌کند که یک فایل.env.exampleوجود داشته باشد که ساختار تنظیمات (نام کلیدها) را بدون مقادیر واقعی نشان دهد. - کامیت‌های متعارف (Conventional Commits): گردش‌کار نام‌گذاری‌های خاصی را می‌طلبد:
feat:برای جریان‌های جدید،fix:برای بررسی انقضای توکن یا باگ‌ها،chore:برای وابستگی‌ها وrefactor:برای میان‌افزارها (Middleware). این کار تاریخچه گیت را برای انسان‌ها خوانا می‌کند و اجازه می‌دهد خط لوله‌های CI روی ویژگی‌ها فعال شوند و کارهای متفرقه (Chores) را نادیده بگیرند. - دسترسی‌پذیری WCAG 2.1 AA: هر عنصر تعاملی رابط کاربری (UI) باید این استاندارد را رعایت کند تا صفحه‌خوان‌ها بتوانند پیمایش کنند، کاربران فقط با کیبورد بتوانند عمل کنند و کنتراست رنگ‌ها کافی باشد. این موضوع هم به عنوان یک خط قرمز اخلاقی و هم یک الزام قانونی تلقی می‌شود.
- قفل محدوده (Scope Lockdown): کلود از دست زدن به کدهایی خارج از محدوده تکلیف منع شده است. این کار از بازسازی‌های «سودمند» در کدهای مجاور یا تغییر نام متغیرهایی که درخواست نشده بود جلوگیری می‌کند و Diffها را قابل بررسی نگه می‌دارد.
پلی‌بوک‌های تخصصی (Skills):
برای جایگزینی بداهه-کاری، گردش‌کار از «مهارت‌ها» استفاده می‌کند؛ پلی‌بوک‌های ساختاریافته‌ای که کلود در موقعیت‌های خاص فراخوانی می‌کند تا از پرش مستقیم به پیاده‌سازی جلوگیری شود:
- ویژگی‌های جدید: مسیر «طوفان فکری $
ightarrow$ تصمیم معماری $
ightarrow$ برنامه مکتوب $
ightarrow$ انتظار برای تایید» را دنبال می‌کند. - شکار باگ: یک مهارت عیب‌یابی سیستماتیک را فعال می‌کند.
- تغییرات UI: مسیر «طراحی فرانت-اند $
ightarrow$ ممیزی دسترسی‌پذیری $
ightarrow$ بررسی عملکرد» را طی می‌کند. - وابستگی‌ها (Dependencies): همیشه ابتدا یک ممیزی امنیتی را فعال می‌کند.
مهارت /brainstorming به‌ویژه حیاتی است؛ زیرا کلود را مجبور می‌کند رویکردهای جایگزین و نقاط قوت و ضعف (Trade-offs) هر کدام را بررسی کند تا مطمئن شود هوش مصنوعی راهکار فنی درستی برای مسئله‌ی غلط ارائه نمی‌دهد.
حافظه و بهداشت توکن
حافظه جلسه کلود مانند RAM است؛ محدود است. برای مبارزه با محدودیت فراموشی در جلسات، سیستم از پوشه‌ای از فایل‌های Markdown برای ذخیره درس‌های بلندمدت استفاده می‌کند که در تمام گفتگوهای آینده باقی می‌مانند.
درس‌های آموخته شده در حافظه:
- تست دیتابیس: «هرگز دیتابیس را در تست‌ها شبیه‌سازی (Mock) نکنید.» این درس پس از آن آموخته شد که تست‌های شبیه‌سازی شده پاس شدند اما مهاجرت واقعی دیتابیس در محیط عملیاتی شکست خورد، چون Mockها رفتار واقعی DB را منعکس نمی‌کردند.
- بهینه‌سازی: «به‌طور پیش‌فرض از useCallback/useMemo استفاده نکنید.» بهینه‌سازی زودهنگام باعث ایجاد نویز می‌شود. Memoization تنها پس از آنکه یک Profiler مشکل رندر مجدد (Re-render) را تایید کرد، اضافه می‌شود.
- نردبان مدیریت وضعیت (State Management): یک سلسله‌مراتب سخت‌گیرانه:
useState(وضعیت محلی UI) $
ightarrow$Zustand(وضعیت مشترک کلاینت مانند پرچم‌های مودال) $
ightarrow$TanStack Query(هر چیزی که از سرور می‌آید). این کار از باگِ «داده‌های قدیمی سرور که در استور کلاینت زندگی می‌کنند» جلوگیری می‌کند. - ساختار پوشه‌ها: ساختار مبتنی بر ویژگی (مثلاً
/features/auth/) که در آن فرم، تست‌ها، هوک‌ها و تایپ‌ها در کنار هم قرار دارند و حذف یک ویژگی را ساده می‌کند.
مدیریت عملکرد
برای سریع نگه داشتن پاسخ‌ها و پایین آوردن هزینه‌ها، سیستم از بهداشت توکن استفاده می‌کند:
- .claudeignore: مانع از خواندن دایرکتوری‌های حجیم مانند
node_modules/،dist/،.git/،*.log،coverage/،.next/وbuild/می‌شود. خواندنnode_modules/به تنهایی می‌تواند پنجره متنی را با میلیون‌ها خط کد غیرمرتبط شخص ثالث هدر دهد. - دستور
/compact: پس از جلسات طولانی، این دستور تاریخچه را خلاصه کرده و فضا آزاد می‌کند؛ شبیه به بستن تب‌های مرورگر برای افزایش سرعت دستگاه. - خوانش‌های هدفمند: کاربر باید کلود را به فایل‌های خاصی ارجاع دهد، به‌جای اینکه از او بخواهد کل کدبیس را اسکن کند.
این رویکرد منضبط باعث می‌شود سرعت اولیه توسعه هر ویژگی در مقایسه با پرامپت‌نویسی خام کمتر شود. با این حال، نویسنده اشاره می‌کند که نرخ نقص‌ها به‌شدت کاهش می‌یابد، کد قابل نگهداری می‌ماند و هیچ چیز شکسته به محیط عملیاتی نمی‌رسد زیرا هیچ گیت تستی نادیده گرفته نشده است.
برای کسانی که قصد پیاده‌سازی این سیستم را دارند، گام بعدی ممیزی PRهای فعلی خود برای شناسایی «گسترش محدوده» (Scope Creep) است — همان تغییرات کوچک و درخواست‌نشده‌ای که اغلب باعث بروز رگرسیون (Regression) می‌شوند.
گام بعدی شما
- بررسی PRهای اخیر خود برای شناسایی «گسترش محدوده» یا تغییراتی که از شما خواسته نشده بود.
- ایجاد یک فایل
CLAUDE.mdدر ریشه پروژه برای تعریف قوانین رفتاری مدل. - پیاده‌سازی گیت تست (
pnpm test) به عنوان یک مرحله اجباری پیش از هر کامیت.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو