كيف تراجع ما يغيّره وكلاء الذكاء الاصطناعي في ملاحظاتك

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

وهذه أخطاء تتكرر كثيرًا:

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

والحل من شقّين: أن ترى كل تغيير قبل أن تعتمده، وأن تدوّن من راجع ماذا. يشرح هذا الدليل كيف تفعل الأمرين يدويًا باستخدام git وبضعة حقول في frontmatter، ثم يبيّن بعد كل خطوة كيف يتولاها Knowtarium. فقد بنينا Knowtarium لهذا تحديدًا: كل تغيير يجريه وكيل فيه موقَّع ويمكن التراجع عنه افتراضيًا، ومراجعة التغيير قبل اعتماده خيار تفعّله لكل مجلد على حدة.

أفضل أداة مجانية لهذه المهمة هي git. إن كانت ملاحظاتك مجلدًا من ملفات markdown، فضعها في git ونفّذ commit قبل كل جلسة مع وكيل. هكذا يصبح كل ما يفعله الوكيل فروقات (diff) تقرؤها، فتحتفظ ببعضها أو تتخلص منها كلها.

# مرة واحدة، في مجلد ملاحظاتك
$ git init$ git add -A && git commit -m "Notes before agents"
 
# قبل كل جلسة مع وكيل: نقطة بداية نظيفة في فرع مستقل
$ git switch -c agent/2026-09-26-cleanup

والعمل في فرع مستقل يُبقي سجلّك الرئيسي نظيفًا: إن كانت الجلسة كلها خطأ، فارجع إلى الفرع الرئيسي واحذف هذا الفرع. وحين ينتهي الوكيل، اقرأ ما غيّره:

# ما الملفات التي تغيّرت، وكم تغيّر فيها
$ git status$ git diff --stat
 
# اقرأ التغييرات كلمةً كلمة، فهذا أنسب للنصوص من مقارنة أسطر كاملة
$ git diff --word-diff
 
# احتفظ بالأجزاء التي توافق عليها (y = احتفظ، n = تخطَّ، s = قسّم، e = عدّل)
$ git add -p$ git commit -m "Keep claude-code edits to pricing notes"
 
# تخلّص من كل ما لم تحتفظ به
$ git restore .
 
# عُد إلى main وادمج ما وافقت عليه
$ git switch main$ git merge agent/2026-09-26-cleanup

أما ما يجعل هذه مراجعة حقيقية فهو git add -p: يعرض عليك كل جزء تغيّر واحدًا تلو الآخر، فتضيفه أو تتخطاه. وهكذا تحتفظ بالملاحظة الجديدة وتستبعد إعادة كتابة لم تطلبها لملاحظة قديمة. اضغط s لتقسيم جزء كبير إلى أجزاء أصغر، وe لتعديل جزء بنفسك.

واكتب اسم الوكيل في رسالة commit، فيخبرك git log بعدها أي جلسة كتبت ماذا، ويعرض git log -p -- path/to/note.md السجلّ الكامل لملاحظة واحدة.

في Knowtarium

في Knowtarium، يُحفظ كل تغيير يجريه وكيل نسخةً جديدة موقَّعة بمفتاح الوكيل نفسه، فيعرض سجلّ الملاحظة كل نسخة ومن أنشأها ومتى، ويعرض See changes تعديل الوكيل على شكل diff، ويعيد Undo النسخة السابقة. وللمجلدات التي تريد أن تقرأ ما يتغير فيها أولًا، فعّل المراجعة («Ask me first»): تنتظر تغييرات الوكلاء فيها على شكل diff حتى توافق عليها، أو ترفضها مع تعليق.

(تُفتح بحجمها الكامل في علامة تبويب جديدة) (تُفتح بحجمها الكامل في علامة تبويب جديدة)

إن كنت تستخدم Claude Code، ففيه ثلاث ميزات تساعدك. لا تغني أيٌّ منها عن git، لكنها تكشف المشكلات مبكرًا.

أوضاع الصلاحيات

يحدد وضع الصلاحيات ما يفعله Claude دون أن يستأذنك. في وضع Manual (قيمته في الإعدادات default) يستأذن قبل تعديل الملفات. ووضع acceptEdits يتيح له التعديل دون سؤال، وتقترحه Anthropic حين تفضّل أن تراجع باستخدام git diff بعد ذلك. ووضع plan يجعل Claude يبحث ويقترح التغييرات دون أن يجريها حتى توافق على الخطة. اضغط Shift+Tab للتنقّل بين الأوضاع خلال الجلسة. والإصدارات الحديثة تبدأ الجلسات التفاعلية في وضع auto، وفيه يراجع مصنِّفٌ الإجراءات بدلًا منك، فانتقل إلى وضع Manual أو plan حين تعمل على ملاحظات تهمّك.

نقاط الاستعادة

ينشئ Claude Code نقطة استعادة (checkpoint) قبل كل طلب ترسله. شغّل /rewind، أو اضغط Esc مرتين وحقل الطلب فارغ، لاستعادة الملفات أو المحادثة أو كليهما. لكن اعرف حدودها: لا تتتبّع نقاط الاستعادة الملفات التي تغيّرت بأوامر الطرفية مثل mv أو rm، ولا تستعيد عادةً التعديلات التي أجراها الوكلاء الفرعيون، وتُحذف بعد نحو 30 يومًا افتراضيًا. وتقولها وثائق Anthropic صراحةً: نقاط الاستعادة ليست بديلًا عن نظام التحكم في الإصدارات.

قواعد الصلاحيات

بالقواعد في .claude/settings.json تمنع التعديل في مجلدات محددة أو تشترط له الإذن. وقواعد المنع تتقدم على كل ما سواها وتسري في كل الأوضاع:

{
  "permissions": {
    "ask": ["Edit(/decisions/**)"],
    "deny": ["Edit(/journal/**)", "Edit(/people/**)"]
  }
}

هنا لا يستطيع Claude تعديل journal/ أو people/، وعليه أن يسأل قبل أن يلمس decisions/. تغطّي قواعد Edit أدوات الملفات المدمجة في Claude وأوامر الملفات التي يتعرّف عليها في الطرفية، لكنها لا تغطي سكربتًا يفتح الملفات بنفسه. ولمن يريد ضمانًا قاطعًا، تحيل Anthropic إلى بيئتها المعزولة (sandbox).

يقرأ معظم الوكلاء ملف تعليمات قبل أن يبدؤوا: AGENTS.md لـCodex وCursor وكثير غيرهما، وCLAUDE.md لـClaude Code. ضع قواعد التحرير هناك، واجعلها قصيرة ومحددة بحيث يسهل التحقق منها:

## تغيير المستندات
 
- لا تحذف مستندًا أبدًا. ضع `status: deprecated` واذكر السبب.
- لا تعدّل أي ملف في journal/ أو people/.
- لا تُعِد كتابة فقرة لم يطلب منك أحد تغييرها.
- وقّع كل مستند تكتبه في `generated`، باسمك وإصدارك.
- لا تضف أبدًا مدخل `human:` إلى `verified`. هذا يفعله الإنسان وحده.
- اختم الجلسة بقائمة تضم كل ملف أنشأته أو غيّرته أو نقلته.

والقاعدة الأخيرة هي الأنفع للمراجعة: قائمة بكل ملف مسّه الوكيل، تقارنها بنتيجة git status. فإن اختلفتا، فدقّق أكثر.

التعليمات سياق، لا قفل. فوثائق Anthropic تصف ملف CLAUDE.md بأنه شيء يقرؤه Claude، لا إعدادات يُلزَم بها، ولهذا وُجدت قواعد الصلاحيات التي رأيتها أعلاه. وفي دليلنا إلى AGENTS.md وCLAUDE.md لقاعدة المعرفة قالب كامل.

وعلى macOS وLinux يمكنك أيضًا أن تجعل مجلدًا للقراءة فقط بالأمر chmod -R a-w journal/. لكنه عائق يبطئ الوكيل لا أكثر: فالوكيل الذي يشغّل أوامر الطرفية يستطيع أن يعيد الصلاحيات كما كانت.

تخبرك الفروقات بما تغيّر اليوم، لكنها لا تخبر من يقرأ الملاحظة بعد شهر هل راجعها أحد. لذلك اكتب هذه المعلومة في الملاحظة نفسها. وفي Open Knowledge Format (OKF)، وهي مواصفة مفتوحة نشرتها Google Cloud، حقول وُضعت لهذا الغرض بالذات:

---
type: Decision
title: تحويل الفوترة إلى خطط سنوية
generated: { by: claude-code/2.1, at: 2026-09-26T09:12:00Z }
verified:
  - { by: human:maya, at: 2026-09-26T11:40:00Z }
stale_after: 2027-03-31T00:00:00Z
---

• generated يذكر من كتب المحتوى الحالي ومتى. يوقّع الوكلاء بصيغة name/version، والناس بصيغة human:name.
• verified يسرد كل من راجعه بعد ذلك، مع وقت المراجعة. فالمستند الذي لا مدخل فيه هو unverified، والذي راجعه وكلاء أو عمليات فقط هو machine-confirmed، والذي راجعته جهة human: هو human-reviewed.
• stale_after هو الموعد الذي لا يعود الاقتباس من المستند بعده آمنًا.

والطريقة بسيطة: يكتب الوكيل ويوقّع في generated، ولا يقترب من verified أبدًا. وتراجع أنت الفروقات، ثم تضيف مدخلك في verified. وبهذا يكفيك أمر واحد لتجد كل ما لم يراجعه أحد:

# مستندات لم يراجعها أحد بعد: لا يوجد فيها سطر verified أصلًا
$ grep -rL "^verified:" --include="*.md" .

1. نفّذ commit، ثم أنشئ فرعًا للجلسة.
2. شغّل الوكيل في وضع Manual أو plan، مع قواعد منع للمجلدات التي يجب ألّا يقترب منها أبدًا.
3. أعطه مهمة واحدة، واطلب منه في النهاية قائمة بالملفات التي مسّها.
4. قارن تلك القائمة بنتيجة git status، ثم اقرأ git diff --word-diff.
5. احتفظ بما توافق عليه باستخدام git add -p، وأعِد الباقي إلى ما كان عليه.
6. أضف مدخلك في verified لكل ملاحظة راجعتها، ونفّذ commit تذكر في رسالته اسم الوكيل، ثم ادمج الفرع.

ولكل أداة ما تكشفه وما يفوتها:

مع بضع عشرات من الملاحظات ووكيل واحد، قد يكفيك git وهذا الروتين. لكنه يصبح مرهقًا حين يكتب الوكلاء كل يوم، أو حين يمسّ تغيير واحد عشر ملاحظات، أو حين يجعل تعديلٌ منك خمس ملاحظات أخرى خاطئة دون أن تنتبه. ولهذا بالذات بُني Knowtarium: كل تغيير يجريه وكيل موقَّع، وتكفي نقرة واحدة للتراجع عنه، وفي المجلدات التي تفعّل فيها المراجعة تنتظرك تغييرات الوكلاء، وتنتظر تعديلاتك أنت حتى تطلب من وكيل أن يراجعها.

يجمع Knowtarium الروتين السابق كله في قاعدة معرفة مشفّرة تشفيرًا تامًا بين الطرفين. يتصل وكلاؤك عبر MCP ويعملون على مستندات OKF نفسها، ويريك التطبيق ما فعلوه وما يحتاج بعدُ إلى نظرة منك. وللمراجعة درجتان: إمكانية التراجع عن كل تغيير افتراضيًا، والموافقة المسبقة حيث تطلبها.

كل تغيير موقَّع وقابل للتراجع

يُحفظ تغيير الوكيل افتراضيًا على الفور نسخةً تالية للمستند، موقَّعةً بمفتاح الوكيل نفسه. وتظهر نقطة في الشريط الجانبي بجانب كل مستند عدّله إلى أن تفتحه، ويذكر سطر تحت العنوان أي وكيل عدّله ومتى، مع رابط إلى التغييرات وزر Undo، وتسرد صفحة مساحة العمل ما عدّله الوكلاء في آخر 14 يومًا. يعيد Undo النسخة السابقة على أنها تغيير منك، ويحتفظ السجلّ بكل نسخة لتستعيدها متى شئت، للمدة التي تحددها (30 يومًا في البداية، وحتى سنة).

Ask me first: اطّلع على الفروقات، ثم وافق

فعّل المراجعة لمساحة عمل أو مجلد، فتنتظر تغييرات الوكلاء فيه على شكل اقتراحات بدلًا من أن تُحفظ فورًا. افتح أحدها لترى الفروقات مع ملخص كتبه الوكيل بنفسه واسم من اقترحه. وافق عليه، أو ارفضه مع تعليق، أو وافق على عدة اقتراحات دفعة واحدة. وموافقتك تضيفك إلى verified مع الوقت، وهو مدخل human: الذي كنت ستكتبه بنفسك لولا ذلك. ولأن اقتراح الوكيل يحمل مراجعته هو أصلًا، تصبح الملاحظة بعد موافقتك موثَّقة بالكامل (fully verified).

(تُفتح بحجمها الكامل في علامة تبويب جديدة) (تُفتح بحجمها الكامل في علامة تبويب جديدة)

وفي هذه المجلدات، تجمع قائمة انتظار واحدة كل ما ينتظر المراجعة:

• تغييرات اقترحها وكيل، تنتظرك؛
• تعديلات أجريتها، تنتظر أن يراجعها وكيل؛
• تعارضات اكتشفها وكيل أثناء المراجعة.

أما المستندات التي تجاوزت تاريخ stale_after، وتلك التي يقترب موعدها، فتجدها في صفحة Stale and expiring أينما كانت.

مراجعة في الاتجاهين

في المجلدات التي فعّلت فيها المراجعة، تسير المراجعة في الاتجاه المعاكس أيضًا. فحين تعدّل مستندًا بنفسك، يُوقَّع التعديل باسمك وينتظر في قائمة المراجعة حتى يقارنه وكيل بكل مستند مرتبط به. ولا يستدعي Knowtarium أي ذكاء اصطناعي من تلقاء نفسه: أنت تطلب من وكيلك أن يراجع تعديلات اليوم، فيسجّل مراجعته، أو يبلّغ عن تعارض حيثما وجد شيئًا لم يعد متّسقًا.

مستويات الثقة

في المجلدات التي فعّلت فيها المراجعة، لكل مستند مستوى ثقة:

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