توسعه نرم‌افزار با Cursor و AI؛ یک workflow حرفه‌ای از Specification تا Test

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

این متن گردش‌کار توسعه با Cursor است از مشخصات تا تست؛ نه فهرست میانبر و نه مقایسهٔ مدل‌ها. زاویهٔ NODE ساده است: هوش مصنوعی شتاب‌دهنده است، نه مالک تولید. مسئولیت رفتار در production با تیمی است که ادغام می‌کند، نه با چتی که پیشنهاد داده است.

نقش AI در کشف مسئله و هماهنگی محصول را با این گردش‌کار مهندسی قاطی نکنید. آن لایه را در نقش هوش مصنوعی در تیم محصول ببینید. اینجا فقط مسیر ساخت داخل مخزن است.

زمینه را قبل از باز کردن عامل آماده کنید

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

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

مخزن را برای عامل خوانا کنید: README کوتاه برای نحوهٔ اجرا و تست، نام‌گذاری یکدست، و پرهیز از فایل‌های تولیدشده در زمینه. راز را در چت نچسبانید. توکن، کلید درگاه و شناسهٔ گفت‌وگوی خصوصی حتی در مثال نباید واقعی باشند. اگر روی زیرساختی مثل درگاه امن Bot API در NodeGram کار می‌کنید، قرارداد عمومی مخزن را به عامل بدهید نه مقدار محیط production.

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

قوانین پروژه را بنویسید تا مدل حدس نزند

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

آنچه باید در قوانین باشد: پشته و نسخه، محل فایل‌های جدید، ممنوعیت‌ها (مثلاً راز در کلاینت، HTML خام بدون بررسی، مهاجرت دیتابیس دستی در production)، الگوی تست، و زبان کامنت. آنچه نباید باشد: مقالهٔ فلسفه و تکرار README. قانون طولانی که کسی نمی‌خواند، زمینه را اشغال می‌کند و رعایت نمی‌شود.

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

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

مشخصات را تا سطح پذیرش پایین بیاورید

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

• بازیگر و موقعیت
• جریان اصلی
• جریان خطا
• دادهٔ درگیر
• بیرون از محدوده
• معیار پذیرش قابل تست

معیار پذیرش باید مشاهده‌پذیر باشد. «بهتر شود» پذیرش نیست. «اگر درگاه زمان‌تمام شد، سفارش در وضعیت انتظار می‌ماند و صفحه پیام مشخص نشان می‌دهد» پذیرش است. اگر نمی‌توانید برای معیار تست بنویسید، مشخصات هنوز تمام نشده.

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

برای کار مبهم، اول اسپایک در شاخهٔ دورریختنی. اسپایک را با «کد نهایی» قاطی نکنید. خروجی اسپایک یادگیری است؛ خروجی اسپرینت کد با تست است.

حلقهٔ پیاده‌سازی را با مرز فایل و مسئولیت نگه دارید

عامل را روی یک برش راه بیندازید: یک مسیر API، یک کامپوننت، یک مهاجرت. بعد از هر برش، انسان تفاوت را می‌خواند. نخواندن تفاوت یعنی تفویض مالکیت تولید؛ این خلاف قرارداد NODE است.

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

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

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

تست دروازه است، نه تزئین بعد از سبز شدن رابط

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

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

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

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

بازبینی امنیتی را از بازبینی ظاهر جدا کنید

توسعه با کمک هوش مصنوعی سطح حمله را عوض می‌کند: کد بیشتر، چشم کمتر، وابستگی پیشنهادی بیشتر. بازبینی امنیتی یک مرحلهٔ صریح است نه حس خوب بعد از نمایش.

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

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

از مدل برای شکار آسیب‌پذیری در تفاوت خودتان هم استفاده کنید، اما یافته را مثل هشدار ایستا ببینید: باید بازتولید و تأیید شود. «ممکن است تزریق باشد» بدون مسیر اثبات، فقط نویز است. مسئولیت تأیید با انسان است.

انسان مالک انتشار است

شتاب‌دهنده بودن AI یعنی زمان نوشتن پیش‌نویس کم می‌شود، نه اینکه دروازهٔ انتشار برداشته شود. مالک کار همان کسی است که درخواست ادغام را تأیید می‌کند: می‌تواند رفتار را توضیح دهد، ریسک را نام ببرد، و در حادثه مسیر برگشت را بلد است. اگر نتواند، کد را نفهمیده و نباید ادغام کند.

پیام ثبت تغییرات و شرح درخواست را انسان نهایی می‌کند. متن مدل غالباً «چه تغییر کرد» است؛ برای تاریخچهٔ مخزن «چرا» لازم است. چرا را از مشخصات کپی کنید نه از فهرست فایل.

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

تهیهٔ ابزار را از مهندسی جدا نگه دارید

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

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

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

پرسش‌های متداول

آیا باید همهٔ کد را با عامل نوشت؟

خیر. کار کوچک با زمینهٔ روشن، یا کار تکراری با الگوی ثابت، بهرهٔ خوبی دارد. کار مبهم معماری، چرخاندن راز، و تغییر دادهٔ production مناسب عامل تنها نیست.

اگر تست‌ها را هم مدل بنویسد، هنوز انسان لازم است؟

بله. تست می‌تواند همان باگ را قفل کند. انسان معیار پذیرش را با اظهار مقایسه می‌کند و تست را روی ماشین واقعی اجرا می‌کند. مدل نویسنده است؛ دروازه با اجراست.

قوانین پروژه جایگزین بازبینی است؟

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

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