لوحة ملاحظات لوكلاء الذكاء الاصطناعي: دع مستخدميك يكتبون الموجّه

يكتب إليك مستخدم في الحادية عشرة ليلاً: "زر التصدير لا يفعل شيئاً في Safari".

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

ثلاث كتابات للطلب نفسه. الأولى كانت مجانية وجاءت ممن اصطدم بالخلل فعلاً. والاثنتان الأخريان من عندك.

هاتان الكتابتان الثانية والثالثة هما الجزء من العمل الذي جعله الوكلاء عبثياً.

آخر ما لا تزال تكتبه بيدك

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

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

ما نفعله بدل ذلك هو أن نعامل ذلك النص بوصفه مادة خاماً تُعاد معالجتها، لأن الأداة التي جمعته والأداة التي تنفّذ العمل لم تكونا يوماً أداة واحدة. الملاحظات تعيش في منتج، والتذاكر في منتج ثانٍ، والوكيل يعمل في طرفية لا تعرف أياً منهما.

احذف الفجوة، فلا يبقى لخطوة إعادة الكتابة مكان تحدث فيه.

ما تصير إليه لوحة الملاحظات حين تستطيع اللوحة أن تنفّذ

السجل العلني صفحة يستطيع مستخدموك الوصول إليها. يبلّغون عن خلل، ويطلبون ميزة، ويصوّتون لما طلبه غيرهم، ويتابعون النقاش، ويرون الحالة تتغير. إلى هنا نتحدث عن لوحة ملاحظات، وهناك لوحات جيدة.

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

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

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

ثلاثة أبواب، لأن الناس يبلّغون من حيث هم

لا تنجح لوحة الملاحظات إلا إذا كان التبليغ أرخص من الشكوى في مكان آخر، ومعنى ذلك أن تلتقي الناس حيث وقعت المشكلة.

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

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

وإضافة Chrome هي الباب الثالث، وهي الأكثر تغييراً للسلوك. يحدّد مستخدمك النص المعطوب في أي صفحة، وينقر الإضافة، فتُسجَّل التذكرة والرابط والتحديد مرفقان بها سلفاً. ما تستلمه ليس "لا يعمل"، بل بلاغاً بإحداثيات.

وعند الوكالة، الباب الثالث هو العميل نفسه غالباً، ووضع بوابة العميل مقتصر على المدعوين: لوحة لكل عميل، لا يراها أحد سواه، وبلا اشتراك SaaS إضافي في الحزمة.

التوجيه، لأن "الوكيل المناسب" ليس وكيلاً واحداً

التذكرة الواردة ليست موجّهة إلى أحد بعينه، وهذه هي المشكلة العملية في أي صندوق وارد: على أحد أن يقرر من يتولاها.

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

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

الجزء الذي ينساه الجميع: ماذا يرى صاحب البلاغ في المقابل

جمع الملاحظات سهل، وإغلاق الحلقة هو حيث تخسر المنتجات الناس.

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

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

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

حيث تتوقف الأدوات التقليدية

ليس في هذا انتقاص من الرواد. Canny وFeaturebase وFider وUserVoice تحسن الجمع وإزالة التكرار والترتيب، ولها سنوات من الصقل في الأجزاء التي تهم فرق المنتج. وهي تتوقف في المكان نفسه للسبب البنيوي نفسه: بُنيت لمؤسسات تكون فيها الهندسة قسماً آخر لا يُبلَغ إلا عبر تصدير.

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

ما لا يحله هذا

لوحة ملاحظات موصولة بالوكلاء ليست طياراً آلياً، ومعاملتها كذلك تنتج بالضبط ما تتوقعه.

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

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

والحجم واقع. اللوحة العلنية الناجحة تصير صاخبة، وهذه مشكلة جيدة لها كلفة حقيقية. تُعلَّم التذاكر المكررة عند إرسالها، وتفصل الأصوات ما أراده شخص واحد عما أراده أربعون، وإغلاق تذكرة بسبب مكتوب أسرع من تركها تتعفن. لكن يبقى على أحد أن يقرأ صندوق الوارد.

الإعداد

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

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

AgentsRoom هو مركز القيادة الذي يعمل عليه هذا: لوحة مهام تصير فيها البطاقة وكيلاً يعمل، وصفحة ملاحظات علنية أو خاصة موصولة بها، وأداة قابلة للتضمين، وإضافة Chrome، وإشعارات للعملاء تنطلق حين يُشحن العمل فعلاً. يعمل مع Claude Code وCodex وOpenCode وAntigravity CLI وAider وGrok Build وMistral Vibe وKimi Code.

نزّل AgentsRoom وانشر لوحتك الأولى.

الأسئلة المتكررة

ما لوحة الملاحظات المخصصة لوكلاء الذكاء الاصطناعي؟

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

هل تستطيع تذكرة من مستخدم أن تطلق وكيل ذكاء اصطناعي وحدها فعلاً؟

الإطلاق يبقى فعلاً مقصوداً: شخص ينقل التذكرة إلى In Progress، فينطلق الوكيل والتذكرة هي موجّهه. ما يجري تلقائياً هو التوجيه، إذ تُرسَل التذكرة الواردة إلى الوكيل الذي يطابق تخصصه موضوعها. أما التنفيذ التلقائي الكامل لكل ما يكتبه غريب فليس ميزة، بل ثغرة أمنية.

بمَ يختلف هذا عن Canny أو Featurebase أو Fider أو UserVoice؟

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

هل يجب أن تكون خارطة طريقك علنية كي تستفيد من هذا؟

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

ما الذي يمنع لوحة علنية من الامتلاء بالضجيج؟

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