Windsurf حالا Devin Desktop است؛ راهنمای ارتقا و تنظیم امن Agentها
اگر Windsurf روی ویندوز دارید، این راهنما تفاوت نام جدید Devin Desktop، مسیر ارتقا، حفظ تنظیمات و روش امن استفاده از Cascade، Agentها و ترمینال را توضیح می‌دهد.
اگر برای دانلود Windsurf در ویندوز جست‌وجو کرده‌اید و به نام Devin Desktop رسیده‌اید، با دو محصول جدا روبه‌رو نیستید. صفحه رسمی محصول اعلام می‌کند Devin Desktop نام جدید Windsurf است و تجربه IDE، افزونه‌ها، تنظیمات و پروژه‌های در حال انجام در مسیر به‌روزرسانی حفظ می‌شوند.
با این حال، ارتقای یک ویرایشگر مجهز به Agent را نباید مثل تغییر ظاهر یک برنامه معمولی دید. این ابزار می‌تواند فایل تغییر دهد، فرمان ترمینال اجرا کند و به سرویس‌ها متصل شود. در این راهنما ارتقا را طوری انجام می‌دهیم که پروژه، تنظیمات و مسیر بازگشت زیر کنترل شما بماند.
Devin Desktop چیست و چه نسبتی با Windsurf دارد؟
Devin Desktop ادامه همان پایه IDE در Windsurf است، اما مدیریت Agentهای محلی و ابری، بررسی تغییرها و Agent Command Center را در مرکز تجربه قرار می‌دهد. Devin Local جانشین اصلی Cascade شده است؛ بنابراین کاربران نسخه جدید باید نام Devin Local را در پنل Agent ببینند. طبق FAQ رسمی، به‌روزرسانی برای کاربران Windsurf به شکل معمول OTA ارائه می‌شود و Plan، Pricing، Extensionها و Settingها منتقل می‌شوند.
| موضوع | قبل از ارتقا | پس از ارتقا |
|---|---|---|
| نام محصول | Windsurf | Devin Desktop |
| پایه ویرایشگر | IDE مبتنی بر پروژه | همان IDE همراه Command Center |
| تنظیمات و افزونه‌ها | فعال در پروفایل فعلی | طبق اعلام رسمی منتقل می‌شوند |
| Agentها | Cascade در نسخه قدیمی | Devin Local و مدیریت Agentهای محلی و ابری |
| کنترل انسانی | Review و Permission | همچنان ضروری |
اگر هدف شما فقط شناخت Agentهای برنامه‌نویسی است، ابتدا راهنمای AI Agent را بخوانید. برای مقایسه رویکردهای ترمینالی نیز آموزش GitHub Copilot CLI مفید است.
پیش از ارتقا از چه چیزهایی Backup بگیریم؟
اعلام رسمی درباره انتقال Settingها خبر خوبی است، اما Backup مستقل هنوز لازم است. هدف این نیست که همه پوشه‌های سیستم را کپی کنید؛ باید چیزهایی را نگه دارید که بازسازی آن‌ها زمان‌بر یا پرریسک است.
- همه تغییرهای مهم پروژه را Commit کنید و وضعیت Git را تمیز نگه دارید.
- Branch فعال و Remote صحیح را ثبت و Push موفق را کنترل کنید.
- نام Extensionهای ضروری، Keybindingهای سفارشی و Theme را یادداشت کنید.
- Ruleها، Workflowها و فایل
AGENTS.mdپروژه را در Repository نگه دارید. - متغیرهای محیطی را فقط از محل امن فهرست کنید؛ مقدار Secret را کپی یا Commit نکنید.
- از Database و فایل‌های Uploadشده جدا از تاریخچه کد Backup بگیرید.
یک Tag یا Commit مشخص با عنوانی مثل «قبل از ارتقای IDE» مسیر مقایسه را ساده می‌کند. اگر بعداً تغییری در فایل‌های پروژه دیدید، می‌توانید Diff را دقیقاً نسبت به همین نقطه بسنجید.
ارتقای Windsurf روی ویندوز
- Windsurf را از داخل برنامه به آخرین نسخه موجود برسانید و اعلان Restart to Update را بررسی کنید.
- پروژه‌ها را ببندید و مطمئن شوید Build یا Migration فعالی در حال اجرا نیست.
- به‌روزرسانی رسمی OTA را اجرا کنید؛ اگر نصب تازه لازم بود، فقط از صفحه رسمی محصول و Download استفاده کنید.
- بعد از اجرا، با همان حساب وارد شوید و Import خودکار تنظیمات را بررسی کنید.
- یک پروژه کم‌ریسک را باز کنید و Extension، Terminal، Git و Cascade را جداگانه آزمایش کنید.
مستندات شروع Windsurf برای ویندوز حداقل Windows 10 را ذکر می‌کند و امکان وارد کردن تنظیمات VS Code یا Cursor را توضیح می‌دهد. اگر نصب تازه انجام می‌دهید، انتخاب «Start fresh» برای سیستم آزمایشی امن‌تر است؛ Import را بعد از تأیید نسخه و حساب انجام دهید.
اگر هنوز نام Windsurf را می‌بینیم چه کنیم؟
تغییر نام و انتشار OTA ممکن است مرحله‌ای باشد. نسخه نصب‌شده، کانال Update و صفحه رسمی Download را کنترل کنید. از Installerهای بازنشرشده در سایت‌های متفرقه استفاده نکنید و برای دیدن نام جدید، برنامه ناشناس دیگری نصب نکنید.
Devin Local را از Cascade قدیمی تشخیص دهید
در نسخه‌های جدید، عامل اصلی محلی با نام Devin Local نمایش داده می‌شود و مدل Permission آن با Auto-execution قدیمی Cascade یکسان نیست. تنظیم‌های قدیمی را کورکورانه منتقل نکنید و مجوز فرمان‌ها را دوباره بازبینی کنید.
تنظیم Devin Local برای شروع کم‌ریسک
Devin Local عامل اصلی محلی در Devin Desktop است. در نخستین کار، از آن بخواهید فقط Repository را تحلیل کند و برنامه مرحله‌ای بدهد. پس از بازبینی برنامه، یک تغییر کوچک و قابل سنجش را روی Branch آزمایشی اجرا کنید.
| مرحله | درخواست مناسب | کنترل انسانی |
|---|---|---|
| تحلیل | فایل‌های مرتبط و ریسک‌ها را شناسایی کن | عدم تغییر فایل |
| برنامه | گام‌ها و معیار پذیرش را بنویس | تأیید Scope |
| اجرا | یک تغییر محدود روی Branch انجام بده | Diff، Test و Review |
Prompt اول باید Scope روشن داشته باشد: فایل‌های مجاز، معیار پذیرش، فرمان‌های ممنوع و الزام توقف پیش از نصب Package یا Migration. عبارت‌های کلی مانند «همه‌چیز را درست کن» دامنه تغییر را غیرقابل پیش‌بینی می‌کنند.
مجوزهای ترمینال Devin Local را چگونه تنظیم کنیم؟
صفحه رسمی Terminal توضیح می‌دهد سطوح قدیمی Disabled، Allowlist Only، Auto و Turbo به Cascade مربوط‌اند. Devin Local به‌جای آن مدل Permission مستقل با Ruleهای Allow، Ask و Deny دارد. برای Repository واقعی، رفتار پیش‌فرض را محافظه‌کارانه نگه دارید و فرمان‌های حساس را روی Ask یا Deny قرار دهید.
| Rule | رفتار | کاربرد پیشنهادی |
|---|---|---|
| Allow | فرمان مشخص بدون توقف اجرا می‌شود | فقط ابزارهای کم‌ریسک و محدود |
| Ask | پیش از اجرا تأیید می‌خواهد | نصب، Build، Git و عملیات محیط |
| Deny | اجرای فرمان مسدود می‌شود | حذف، انتشار مستقیم، Credential و Production |
Ruleهای Deny باید برای فرمان‌های حذف، انتشار، تغییر زیرساخت، Migration و دسترسی Credential در نظر گرفته شوند. Allow را با پیشوندهای بسیار کلی تعریف نکنید؛ مجاز کردن یک ابزار می‌تواند زیر‌فرمان‌های پرریسک آن را هم پوشش دهد.
Rules، Memories و AGENTS.md پس از مهاجرت
Memoryهای خودکار محلی‌اند و برای سیاست پایدار تیمی انتخاب مطمئنی نیستند. مستندات پیشنهاد می‌کند دستورهای ماندگار را در Ruleهای Workspace یا AGENTS.md Repository ثبت کنید. این فایل‌ها قابل Review، Version Control و اشتراک با تیم هستند.
- استاندارد Format و Test را در Rule نسخه‌پذیر قرار دهید.
- Secret، Token و اطلاعات مشتری را داخل Rule یا Memory ننویسید.
- Ruleهای Global را کوتاه و عمومی نگه دارید.
- Ruleهای زیرپوشه‌ای را نزدیک همان بخش کد قرار دهید.
- پس از ارتقا، فعال‌شدن هر Rule را در یک Task کوچک آزمایش کنید.
اگر از ابزارهای متصل استفاده می‌کنید، راهنمای اتصال امن MCP Server را ببینید. هر اتصال باید Scope حداقلی، مالک مشخص و مسیر Revoke داشته باشد.
Workflow را از Memory جدا کنید
Workflow برای فرایند چندمرحله‌ای تکرارشونده مثل Review Pull Request، اجرای Test یا چک‌لیست Release است و با Slash Command فراخوانی می‌شود. در نسخه جدید، مسیر ترجیحی فایل‌های Workspace برابر .devin/workflows/ است و مسیر قدیمی .windsurf/workflows/ برای سازگاری خوانده می‌شود؛ این فایل‌ها می‌توانند همراه Repository نسخه‌بندی شوند.
Workflow را مثل کد Review کنید. دستور Deploy، Push یا تغییر Database نباید بدون مرحله تأیید انسانی اجرا شود. بعد از ارتقا، یک Workflow فقط‌خواندنی مانند تحلیل خطا را اجرا کنید و سپس سراغ Workflowهای تغییردهنده بروید.
آزمون سلامت پس از ارتقا
- برنامه را باز و نسخه، حساب و Workspace درست را کنترل کنید.
- یک Branch آزمایشی بسازید و تغییر کوچک ایجاد کنید.
- Diff را بررسی و Revert همان تغییر را تمرین کنید.
- Terminal را با یک فرمان فقط‌خواندنی امتحان کنید.
- Rule و Workflow شناخته‌شده را اجرا و خروجی را مقایسه کنید.
- Extensionهای زبان، Linter، Debugger و Formatter را کنترل کنید.
- هیچ Secret را در Chat، Log، Diff یا فایل جدید باقی نگذارید.
اگر رفتار Agent با قبل فرق دارد، فوراً مجوز فرمان‌های حساس را روی Ask یا Deny بگذارید. سپس مدل، Mode، Ruleهای فعال و Extensionهای درگیر را یکی‌یکی بررسی کنید. تغییر هم‌زمان چند متغیر عیب‌یابی را دشوار می‌کند.
اشتباه‌های رایج در مهاجرت
- دانلود Installer از منبع متفرقه: نام‌گذاری جدید باعث سوءاستفاده فایل‌های جعلی می‌شود.
- ارتقا روی Branch کثیف: تشخیص تغییر Agent از تغییر قبلی دشوار می‌شود.
- فعال‌کردن Turbo در روز اول: فرمان ناخواسته فرصت بازبینی را از بین می‌برد.
- اتکا به Memory برای سیاست تیم: Memory محلی و کم‌قابلیت‌تر برای Review است.
- فرض حفظ Database با Git: تاریخچه کد جای Backup داده را نمی‌گیرد.
- دادن Prompt بدون Scope: Agent فایل‌ها و Dependencyهای بیشتری از نیاز تغییر می‌دهد.
جمع‌بندی
Devin Desktop نام جدید Windsurf است و مسیر رسمی ارتقا قرار است تنظیمات، افزونه‌ها و پروژه‌های جاری را حفظ کند. ارزش واقعی ارتقا زمانی دیده می‌شود که مدیریت Agentها ساده‌تر شود، نه اینکه کنترل توسعه‌دهنده کمتر شود.
پیش از Update یک نقطه سالم در Git بسازید، Rule و Workflowها را نسخه‌بندی کنید، اجرای خودکار Terminal را محافظه‌کارانه تنظیم کنید و همه قابلیت‌ها را ابتدا روی پروژه آزمایشی بسنجید. سپس مرحله‌به‌مرحله به Repository واقعی برگردید.
همین حالا پیش از ارتقا، وضعیت Git پروژه اصلی را تمیز کنید، مجوز فرمان‌های حساس را روی Ask یا Deny بگذارید و یک پروژه آزمایشی برای کنترل Extension، Terminal و Cascade آماده کنید.