Kimi Code لا تسأل أبدًا: الأوضاع والأوامر الخطرة

في Kimi Code، يوافق وضع لا تسأل أبدًا (/auto) على كل شيء تلقائيًا: سينفّذ rm -rf وshutdown وreboot من دون أي سؤال. لا يستأذن الوكيل قبل هذه الأوامر إلا في الوضعين الآخرين: اسأل دائمًا واسأل عند الحاجة.

أعمل بنفسي في Claude Code مع تفعيل خيار «السماح بكل شيء»؛ وإلا لقضينا وقتنا في النقر: نعم، نعم، نعم.

حتى النموذج الشخصي الأولي قد يكشف ملفات وبيانات اعتماد قيمة. استخدم نسخة معزولة أو حاوية بأذونات محدودة ونسخة احتياطية مختبرة؛ ولأنظمة العملاء، امنح الوكيل أيضًا هوية قاعدة بيانات مستقلة بالوصول المطلوب فقط. وهكذا، حتى لو أراد حقًا حذف قاعدة البيانات، فلن يستطيع.

لنلقِ نظرة على ما يفعله كل وضع من أوضاع Kimi Code، والمواضع التي تعمل فيها الحماية، وكيفية إعداد حظر. لنبدأ.

للاطلاع على معلومات حول استخدام الخدمة، راجع وثائق Ailoot.

ما الفرق بين أوضاع Kimi Code الثلاثة؟#

إذا كنت قد ثبّت Kimi Code بالفعل، فلا بد أنك رأيت لوحة الموافقة: يريد الوكيل تعديل ملف أو تشغيل أمر، فينتظر منك أن تقول «نعم». كانت الأوضاع تُسمّى Manual وYOLO وAuto، ولذلك ما زالت تستخدم الأوامر القديمة: /yolo و/auto.

اسأل دائمًا. هذا هو الوضع الافتراضي. يقرأ الوكيل الملفات دون استئذان، لكنك تؤكد كل تعديل وكل أمر على حدة. وهذا أبطأ الأوضاع.

اسأل عند الحاجة. يُفعّل باستخدام /yolo. يوافق الوكيل بنفسه على التعديلات والأوامر العادية، لكنه يستأذن قبل الوصول إلى .env (الملف الذي يحتوي على كلمات مرور المشروع ومفاتيحه) ومفاتيح SSH للخادم، وقبل الأوامر الخطرة مثل shutdown (إيقاف تشغيل الكمبيوتر) وrm -rf (حذف مجلد كامل مع تجاوز سلة المهملات)، وقبل مغادرة وضع التخطيط. ويمكن للوكيل أيضًا أن يطرح عليك سؤالًا بنفسه.

لا تسأل أبدًا. يُفعّل باستخدام /auto. تتم الموافقة على كل شيء تلقائيًا، بما في ذلك الوصول إلى الملفات الحساسة ومغادرة وضع التخطيط. لا يطرح الوكيل عليك أسئلة، ويقرر كل شيء بنفسه.

يُفعّل وضع التخطيط بشكل منفصل باستخدام Shift-Tab أو /plan: يكتب الوكيل خطة أولًا وينتظر موافقتك، ثم يتعامل مع الملفات.

متى أعمل بنفسي دون طلب تأكيد#

في Claude Code، يكون خيار «السماح بكل شيء» هو الإعداد الافتراضي لدي، وأفعّله في كل محادثة جديدة. ومن دونه، يصبح البرمجة بأسلوب vibe بطيئة جدًا. فالشخص الذي يبرمج بأسلوب vibe لا يعرف الكثير أصلًا، ثم عليه أن يواصل الضغط على الأزرار: نعم، نعم، نعم، لا، لا، لا.

لكن في هذا الوضع، يمكن للوكيل أن يفعل أي شيء متهور، بما في ذلك مسح قاعدة بيانات. ثم سيقول «آسف، أعتذر»، لكن قد يستحيل أحيانًا إصلاح ما فعله. لذلك فهذا الوضع لمن لا يخشون العواقب، وأنت المسؤول عنه.

هذه هي قواعدي. للمشاريع الشخصية والتجارب والنماذج الأولية، استخدم وضع عدم التأكيد داخل نسخة معزولة أو حاوية فقط، دون ملفات قيمة أو بيانات اعتماد إنتاج، وبأذونات محدودة ونسخة احتياطية. لا يحمي غياب العملاء ملفاتك الشخصية أو مفاتيحك؛ ويجب التحقق من العزل أيضًا. لكن إذا فعّلت هذا الوضع في المشروع نفسه الذي يملك صلاحية الوصول إلى خادم إنتاج، فقد يكفي prompt واحد لكي يحذف الوكيل قاعدة البيانات ليلًا وينشر تغييرات على الموقع المباشر.

لماذا لا يحميك الحظر المكتوب بالكلمات#

يكتب كثيرون في تعليمات الوكيل: «لا تلمس قاعدة البيانات». لا تراهن على أن هذا سيحميك. تقول له: يا صاحبي، لا تدخل إلى هنا. لكنه سيدخل على أي حال ويأخذ ما يحتاج إليه عندما يحتاج إليه. وينطبق ذلك على Kimi الصيني خصوصًا: فهو سينتهك أي حظر تضعه. أما النماذج الأمريكية، فهي مدرّبة بشكل أفضل بكثير على تجنب ذلك.

ما زلت أستخدم Kimi في عملي. يتميز Kimi K3 بالدقة؛ أستخدمه للتحقق من تسرب المفاتيح في المشاريع ولجمع المعلومات. وقد استنفدت كل حدوده ذات مرة خلال يومين. لا يعبث Kimi، وينفذ كل ما تطلبه. ولهذا تحتاج إلى العزل عند العمل معه. شرحت هنا كيف اختبرته على مهامي الخاصة.

تحتاج إلى شكلين من العزل:

1. قائمة حظر الأوامر في الإعدادات. تحظر استدعاءات الأدوات المطابقة؛ لكن نمطًا لتهجئة أمر واحد لا يشكل حدًا كاملًا ضد أدوات أخرى أو إجراءات مكافئة. استخدمها إلى جانب أذونات نظام التشغيل والحاوية وقاعدة البيانات.
2. صلاحية القراءة فقط لقاعدة البيانات. في قاعدة البيانات الحية، يكون للوكيل مستخدم منفصل بصلاحيات القراءة فقط. عندئذٍ، حتى في وضع لا تسأل أبدًا، لن يستطيع الوكيل مسح قاعدة البيانات.

أين تعمل الحماية من الأوامر الخطرة#

تكون الحماية المدمجة في Kimi Code من الأوامر الخطرة مفعّلة افتراضيًا. يطلب تأكيدًا قبل shutdown أو reboot (إعادة التشغيل) أو rm -rf في وضعي اسأل دائمًا واسأل عند الحاجة. أما في وضع لا تسأل أبدًا، فتُنفّذ هذه الأوامر دون توقف.

هناك استثناءان:

• يعمل rm -rf دون استئذان إذا كان يحذف محتويات المجلدين المؤقتين /tmp أو /temp فقط (منذ الإصدار 0.43.0).
• في وضع اسأل عند الحاجة، لا يستأذن Kimi Code بشأن أوامر الطرفية التي لا يستطيع تحليلها مسبقًا (منذ الإصدار 2.0.1).

في الإصدار 0.40.0، كان وضع Auto يحظر الأوامر الخطرة؛ وأُزيل هذا الحظر في الإصدار 0.41.0.

يمكنك تعطيل الحماية باستخدام dangerous_command_guard = false في قسم [permission] من ملف الإعدادات ~/.kimi-code/config.toml، أو باستخدام المتغير KIMI_CODE_DANGEROUS_COMMAND_GUARD=false. يوصي المطورون بفعل ذلك فقط في البيئات التي تُعترض فيها الأوامر الخطرة مسبقًا بوسائل خارجية.

كيفية إعداد حظر دائم في Kimi Code#

عندما يريد الوكيل تغيير شيء ما، يعرض Kimi Code لوحة موافقة:

• موافقة: استخدم مفاتيح الأسهم وEnter، أو اضغط مباشرةً على 1 أو 2 أو 3.
• رفض: Esc أو Ctrl-C أو Ctrl-D.
• الموافقة لهذه الجلسة: تُوافق على الاستدعاءات من النوع نفسه حتى نهاية الجلسة.
• القواعد الدائمة: قاعدة سماح أو حظر دائمة في ملف الإعدادات.

تُكتب القواعد الدائمة في ملف الإعدادات ~/.kimi-code/config.toml ضمن كتل [[permission.rules]]. يتحقق Kimi Code من القواعد بالترتيب، ويُطبّق أول قاعدة مطابقة؛ لذلك ضع قواعد الحظر قبل قواعد السماح. لكل قاعدة قيمة decision: allow (السماح فورًا) أو deny (الرفض فورًا) أو ask (الاستئذان في كل مرة).

حظر rm -rf وطلب التأكيد قبل أي أمر آخر في الطرفية:

[[permission.rules]]
decision = "deny"
pattern = "Bash(rm -rf*)"

[[permission.rules]]
decision = "ask"
pattern = "Bash"

بالنسبة إلى أوامر الطرفية، يوضع النمط بين قوسين: Bash(command-pattern)؛ أما قراءة الملفات فتستخدم Read(path-pattern). لا يمكن حظر أدوات MCP وAgentSwarm وأدواتك الخاصة إلا بذكر أسمائها كاملةً.

إذا لم تكن متمرسًا تقنيًا ولا تريد فتح ملف الإعدادات، فما عليك سوى لصق prompt أدناه في الوكيل؛ وسيحدد بنفسه ما ينبغي تقييده. لكن اطلب منه أن يخبرك أولًا بمدى تأثير ذلك في سرعة عملك. إذا كنت معتادًا على العمل دون تأكيدات، فقد تتوقف بعض الأمور عن العمل بعد إضافة قواعد الحظر. إليك prompt الخاص بي:

حلّل مشروعي وأخبرني ما إذا كان بإمكانك الوصول إلى خادم الإنتاج وقاعدة بيانات التجهيز ومفاتيح الإنتاج. إذا كان بإمكانك ذلك، فأعدّ الحماية من الأوامر الخطرة: امنع حذف المجلدات بأكملها، والأوامر التي تعيد كتابة سجل التغييرات على نحو يتعذر التراجع عنه، والأوامر المباشرة الموجّهة إلى قاعدة بيانات الإنتاج. اعرض أولًا خطة بصيغة «قبل - بعد»، وأخبرني بصراحة بمدى تأثير ذلك في سرعة عملي.

شرحت كيفية إعداد الأمر نفسه في Claude Code في مقال منفصل. وألقِ نظرة أيضًا على كيفية تحقّق وضع Auto في Claude Code من إجراءات الوكيل.

أي وضع تختار؟#

• تريد رؤية كل خطوة يتخذها الوكيل: استخدم الوضع الافتراضي، اسأل دائمًا. تؤكد كل شيء باستثناء القراءة.
• مشروع شخصي أو نموذج أولي بلا عملاء حقيقيين: ابدأ بـ Always Ask أو Ask When Needed. فكّر في Never Ask لنسخة معزولة قابلة للتخلص منها فقط، بأذونات مقيدة ودون بيانات أو مفاتيح قيمة؛ فغياب العملاء لا يجعلها آمنة تلقائيًا.
• مشروع يضم عملاء حقيقيين وإمكانية الوصول إلى الخادم: لا تفعّل وضع لا تسأل أبدًا. أضف قواعد حظر deny في config.toml، وامنح الوكيل صلاحية القراءة فقط لقاعدة البيانات.

واحرص على نسخ قاعدة البيانات احتياطيًا إلى جهاز منفصل عن المشروع. جمعت قواعد السلامة الأخرى في مقال منفصل.

طابق وضع التأكيد مع صلاحيات الوصول في مشروعك، وتحقق من المواضع التي تحتاج فيها إلى قواعد حظر.

تعرّف على Ailoot.